Завдання користувачів без персон: проектування для неюіксерів

Коли немає налагодженого процесу розробки і відсутній компетентний фахівець, зазвичай використовують такі хибні рішення:

Керівник компанії вважає, що повинні бачити користувачі.

Він по собі оцінює, що є зручним і привабливим. Однак цей підхід може бути вірним лише в одному випадку – коли головним користувачем продукту буде сам директор. В усіх інших випадках – це помилкове рішення, оскільки ЦА продукту зазвичай значно відрізняється віддиректора.

Також начальству часто буває складно суперечити, а значить, неможливо вести конструктивний діалог і, відповідно, ухвалювати зважені рішення.

Зовнішній вигляд і функціонал продукту – компіляція з рішень, «запозичених» у конкурентів.

Вивчати ринок і конкурентів потрібно, але наслідування «в лоб» фішок, які сподобалися, може принести безліч проблем. Головні з них: стати безликим клоном, а також скопіювати і помилки разом із хорошими рішеннями.

Віддавати інтерфейси на відкуп дизайнерам чи розробникам без досвіду проектування.

В цьому підході поганим є те, що людям з «профдеформацією» важко під час ухвалення рішень абстрагуватися від своїх уявлень про зручність і красу. Програмістів не лякають складні системи з налаштуванням, а дизайнери готові впроваджувати екрани і функції, що не мають ніякої користі, заради краси і анімації.

Гадаю, багато хто з вас зможе згадати інші проблемні шляхи створення інтерфейсів – їх тисячі. Але я щиро вірю, що, навіть не займаючись повноцінним проектуванням, можна дбати про своїх користувачів  і створювати продукти для людей.

В цій статті я буду розглядати класичний шлях проектування інтерфейсів, оскільки його неможливо коректно описати в рамках одної статті. Також намагатимусь обійтися без модної термінології, а-ля user centered design, empathy map, service design тощо. Оскільки запорука хорошого продукту – це здоровий глузд, розуміння цілей і завдань вашого бізнесу в рамках створюваного продукту і вміння відмовитися від амбіцій на користь щастя ваших користувачів. Описана методика допоможе командам стартапів, дизайнерам, розробникам і всім тим, хто не є UX-дизайнером, але хотів би поглянути на продукт, що розробляється, з точки зору його кінцевих споживачів.   

Додатково повторю, думаючи про користувачів, важливо відмовитися від особистих амбіцій. Це складніше, ніж здається на перший погляд. Коли команда не працює над проектом, а займається з’ясуванням, хто з них розумніший, кращий, досвідченіший – це сильно затримує терміни, погіршує результат, а що там насправді потрібно користувачам – нікого не хвилює.

Тепер продовжуємо. Дуже спрощений процес проектування досвіду взаємодії користувачів складається з трьох етапів:

  1. Гіпотеза (вирішується, що, для кого і навіщо створюється, визначаємо критерії ефективності)
  2. Реалізація (робота над створенням продукту)
  3. Перевірка (вимірюється ефективність і вирішується, що треба покращувати).

neux_2

На етапі гіпотези і відбувається проектування. Незалежно від пропрацьованості цього процесу важливо пам’ятати про наступне:

  1. Проектування завжди є першим етапом створення продукту.
  2. Проектування – це завжди про користувачів.
  3. Проектування – це не окремі екрани чи функції, це процес.

Починати проектування слід з визначення цільової аудиторії продукту.

Вдалим є те, що в більшості випадків створюється не унікальний продукт, а аудиторією є масовий споживач. Наприклад, створюючи інтернет-магазин, немає необхідності підлаштовуватися під індивідуальні особливості користувачів, важливо знайти універсальні рішення, зрозумілі для більшості.

Відповідно, в цьому випадку можна не створювати персони, а обмежитися складанням списку завдань.

Де взяти завдання:

  1. Спілкування зі знайомими. Люди, які потенційно можуть користуватися вашим продуктом або користуються продуктами конкурентів, можливо, наштовхнуть вас на цікаві ідеї.
  2. Служба підтримки. Якщо бізнес існував до створення продукту або була його попередня версія  - обов’язково поговоріть зі службою підтримки і менеджерами. Проблеми і питання користувачів (клієнтів) – це те, що треба врахувати обов’язково.
  3. Брейншторм з командою. Можна пропонувати найбезглуздіші завдання. Всі отримані завдання збираються в один список, схожі завдання об'єднуються в одне і, за можливістю, знеособлюються.

Наприклад, для сервісу доставки розливного крафтового пива завдання «хочу світлого пива» і «хочу темного пива» об’єднуються в завдання «хочу пива з певними параметрами». Однак до них не можна додавати завдання «хочу найгіркішого пива» - це вже завдання «хочу особливого пива».

Далі, щоб перевірити, чи враховані основні завдання, їх можна розбити на чотири групи:

  1. Емоційні формалізовані («Шукаю найближчий до мене ресторан із затишним інтер'єром»)
  2. Емоційні неформалізовані («Хочу почитати щось цікаве»)
  3. Раціональні формалізовані («Шукаю телефон з процесором на 8 ядер»)
  4. Раціональні неформалізовані («Шукаю подарунок для рибака»)

neux_3

Оптимально, щоб завдання рівномірно розподілялися за всіма чотирма групами. Якщо в одній з груп зібралося, наприклад, 10 завдань, а в інших по одній, то має сенс повторювати процес пошуку завдань з акцентом на менш наповнені групи.

Не варто думати, що ваш продукт унікальний, і йому не потрібні емоційні завдання. Навіть годинник на руці не лише показує час (раціональне завдання), але повинні подобатися і є частиною вашого іміджу (емоції).

Отже, отримано список основних завдань, для вирішення яких користувачі можуть звертатися до продукту і тим самим виконувати цільові дії для бізнесу.

Але це ще не все – слід врахувати супутні завдання, які виникають у користувачів у ході включення в процес вирішення основних завдань, взаємодії з продуктом. Наприклад, якщо користувач хоче купити товар на сайті, то у нього виникає необхідність дізнатися про умови доставки, оплати. Якщо користувач звернувся до білінгової системи і хоче здійснювати платіж, то його хвилює розмір комісії, безпеку даних.

Якщо у бізнеса є завдання, які не перетинаються із завданнями користувачів, то їх теж треба перерахувати. Наприклад, підвищити впізнаваність бренду.

Отже, ми маємо три списки завдань:

  1. Основні завдання користувачів.
  2. Супутні завдання.
  3. Завдання бізнесу.

Потім для кожного виду завдань у списку необхідно визначити пріоритет і те, як вона буде вирішуватись. Пріоритет дає можливість ранжувати завдання і визначити, які з них повинні вирішуватися найбільш просто, а процес рішення повинен бути максимально очевидним, а від яких завдань і взагалі можна відмовитися.

Пріоритет завдання формується з 3-х чинників:

  1. Важливість для бізнесу. Наприклад, завдання, яке приносить прямий прибуток (купівля товару), важливіше, ніж завдання, яке формує позитивний імідж компанії.
  2. Популярність у користувачів (чим більша кількість користувачів буде звертатися до продукту для вирішення цього завдання – тим вона важливіша)
  3. Блокуючі завдання – завдання, без вирішення яких ускладнено вирішення завдань із попередніх двох пунктів.

neux_4

Тепер важливо, хоча б для пріоритетних завдань, проаналізувати найкращі практики (бенчмаркінг), причому це можуть бути не лише продукти конкурентів, але і просто продукти зі схожим функціоналом або схожої тематики.

Якість конкурентного продукту визначається за рахунок вирішення з його допомогою ключових завдань вашого проекту. Отриманий досвід у вигляді проблем і рішень – те, що треба врахувати вже у своєму продукті. Важливо фіксувати знайдені інтерфейсні рішення і зіставляти їх із завданнями проектованого. Для завдань, які не тестувалися на продуктах конкурентів, можна просто вказати, за допомогою чого їх можна вирішувати (довідковий текст, пункт меню, певний функціональний елемент).

Потім для завдань, де це можливо, прописуються екрани, на яких вони будуть вирішуватися. Деякі завдання будуть потребувати декількох екранів (наприклад, процес переводу коштів з одної карти на іншу), а у деяких екрани будуть повторюватися.

Зібравши всю інформацію до послідовності «завдання-рішення-екран» створюється пул даних, на підставі яких можна починати практичну роботу над продуктом. Перелік екранів дає можливість сформувати інформаційну архітектуру продукту, а опис рішень – розуміти наповнення екранів і, відповідно, створювати прототипи і дизайн сторінок.

neux_1

Ключовий результат аналітичного опрацювання завдань користувачів – це усвідомлений підхід до створення проекту. Кожне рішення: функціонал, екран – мають обґрунтування у вигляді завдання користувача, а значить, у всіх учасників проектної команди буде розуміння, чому продукт саме такий. Також це дозволяє відійти від аргументів для рішень «подобається/не подобається» і перевести більшість дискусій у конструктивне русло.

 Стаття розміщена на ресурсі https://www.searchengines.ru/

Якщо ви хочете працювати з нами,
давайте почнемо з обговорення завдання

Обговорити задачу

Отримуйте новини інтернет-маркетингу

Тільки корисна інформація від експертів Promodo

Отримуйте новини інтернет-маркетингу