Економити час, і як наслідок, інші ресурси — природне прагнення кожної дизайн-команди, яка працює над продуктом. Ефективні дизайн-процеси — це відповідь. Часто вона проста, хоч і не очевидна. Микола Мельник, Design Team Lead в Product Development студії  Uptech, розповів про чотири дизайн процеси, яких не варто уникати. Адже вони займають значно менше часу, і приносять значно більшу користь продукту, ніж здається на перший погляд.

Процес перший. Створення Proto Persona

Щоб почати дослідження цільової аудиторії, не потрібно одразу ж організовувати інтерв’ю, виходити «в поле» тощо. Можна почати з протоперсони. На всіх проєктах, де є фаза діскавері, ми в Uptech так і працюємо: проводимо інтерв’ю з клієнтом, і на основі отриманої інформації робимо припущення щодо цільової. Клієнт зазвичай має достатньо даних, щоб команда почала формувати персону ще на етапі припущень.

Далі вже створюємо CJM (Customer Journey Map), удосконалюємо персону, збираємо цільову аудиторію на інтерв’ю.

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

Ми можемо створювати персону з моменту, коли маємо припущення щодо того, яка в нас цільова

Персона — досить популярний інструмент. І, наприклад, в Airbnb, персони завжди перед очима у команди:

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

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

Протоперсона впливає на:

1. набір функціоналу в продукті
2. тон комунікації продукту

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

Інколи персона трансформується через зміни у баченні продукту. Наприклад, в процесі роботи над продуктом Yaza, ми повністю оновили персону. Спочатку продукт планувався як тревел соцмережа (додаток для пошуку кафе, ресторанів та місць з розвагами; з мапою, чатом та релевантним контентом всередині — ред.), тому ми орієнтувалися на інфлюенсерів і тих, хто поглинав контент. Але потім додаток трансформувався до нішевої апки для рієлторів з відповідною аудиторією.

Процес другий. Тестування концепту

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

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

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

Як тестувати візуал:

1. Опитувальник асоціацій: збираємо асоціації, які викликає концепт в аудиторії. Можна робити опитування з варіантами відповідей, з відкритими відповідями, з оцінками від 1 до 5, зірочками, смайлами тощо.
2. Desirability studies: з переліку прикметників (близько 25) користувач обирає ті, що, на його думку, характеризують концепт. Серед прикметників є й бажані для продукту, і небажані. Користувач не знає, які характеристики є бажаними й обирає ті, які вважає найбільш точними. Ось тут є перелік слів, які в Microsoft рекомендують використовувати для таких тестувань.
3. Конкурентне тестування: концепт нашого продукту і продукти конкурентів порівнюються за характеристиками, які ми б хотіли мати у своєму продукті. Сайт/додаток має виділятись у своїй ніші, але водночас має бути в настрої цільової аудиторії. Детальніше як ефективно проаналізувати конкурентів розповідається тут.
4. Референсне тестування: користувачі обирають між варіантами дизайнів той, який їм подобається найбільше, виглядає найпростіше чи найсучасніше.

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

Як тестувати юзабіліті:

1. Тести першого кліка: якщо перший клік був «правильним», користувачі з імовірністю 87% пройдуть весь шлях, як задумали дизайнери. Якщо ж клікнули не туди, куди задумувалося, ця ймовірність падає до 46%.
2. Тест п’яти секунд: у продукту є не більше 8 секунд, щоб захопити увагу користувача, інакше він вийде з додатка протягом 10-20 секунд.

Тестування концепту не потребує багато часу. Головне, мати пул респондентів і підготувати документ, щоб розіслати його користувачам та отримати відповіді.

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

Процес третій. Паперове прототипування

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

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

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

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

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

«За кожною з перевірок має стояти певна гіпотеза. Ми проводимо юзабіліті тестування не просто з повітря. Головна цінність гіпотези: ми залишаємось у фокусі. Ми розуміємо навіщо нам тестування і дослідження».

Джерела гіпотез: клієнти, дослідження, конкуренти, саппорт

Процес четвертий. Канва ціннісної пропозиції

Канва ціннісної пропозиції (Value Proposition Сanvas) — це графічне представлення того, що турбує клієнтів/користувачів, і того, що може запропонувати продукт, щоб їхні проблеми/болі подолати. Цей фреймворк фокусується на фічах продукту, які мають для користувача найбільшу цінність.

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

Після розуміння цінності, яку продукт має нести для користувача, ми формуємо список фічей, які її забезпечать. Ці фічі перетворюються у функціонал.

Частково це можна зробити й через CJM. Але в системі координат CJM ми фокусуємося не на фічах, а на досвіді користувача. Вона більше про емпатію: зрозуміти шлях користувача, і які «роботи» на цьому шляху виникатимуть. Value Proposition Canvas дозволяє краще побачити, що саме болить користувачеві, з чим він мириться лише через те, що немає кращого продукту, і потенційно, що його зробить щасливим. І вже відносно цього ми формуємо фічі, які: 1) покриють базові потреби; 2) потреби понад базові.

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

Спочатку заповнюється профіль користувача, потім value proposition, customer jobs, pains та gains. Все, що потрібно для цього процесу: це інтерв’ю та user research, який був зроблений ще раніше.

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