UXPUB 🇺🇦 Дизайн-спільнота: Yaroslav Zhmykhov

Мінімально життєздатний продукт (Minimum viable product, MVP)

Yaroslav Zhmykhov — Mon, 02 Oct 2023 20:03:41 +0000

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

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

Мінімально життєздатний продукт (Minimum viable product, MVP) — це версія продукту із мінімальним набором функцій, яких є достатньо для підтвердження ваших ГІПОТЕЗ про продукт.

або

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

MVP є однією з ключових практик в Lean Startup.

Гіпотеза про продукт — це припущення, яке пов'язане з самим продуктом, його функціональністю, користувацьким досвідом або цінністю для користувача. Вона висувається щодо того, яким чином продукт може вирішувати певну ПРОБЛЕМУ, задовольняти певну ПОТРЕБУ або надавати певну ЦІННІСТЬ.

Правильний процес створення стартапу з використанням: MVP, Agile (Scum), Lean startup та Customer development.

The Top 12 Reasons Startups Fail by CBinsights | 2018

Хто використовує MVP?

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

Застосування концепції MVP допомагає стартапам: перевіряти ідеї, зібрати зворотній зв'язок, зменшити ризики та швидко вийти на ринок.

Компанія vs. стартап

Компанія — це бізнес-організація, яка продає продукт або послугу в обмін на дохід (revenue) та прибуток (profit).

Стартап - це тимчасова організація, створена з метою пошуку повторюваних | repeatable (наприклад, ми кожного дня робимо роботу, а не 1 раз в рік) та масштабованих | scalable (вклав $1, а отримав через місяць $2) бізнес-моделей (Це те, що шукають стартапи - працюючий BM).

Кожен стартап прагне стати повноцінною компанією.

Взято з книги «THE DESIGN THINKING PLAYBOOK». Уважно подивіться на процес пошуку Lean канви і на те, як вона перетворюється на BMC.

Як це працює?

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

Отже, як ви вже здогадалися, MVP зосереджений на швидкій перевірці гіпотези про продукт без затратного та тривалого процесу розробки.

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

Познайомтеся з 3-ма батьками MVP

Три батьки мінімально життєздатного продукту.

Френк Робінсон, співзасновник та президент компанії SyncDev. У 2001 році, він розробив концепцію «Minimum viable product». На жаль, нам недоступний сайт компанії, але у нас є доступ до сторінки компанії на LinkedIn та невелика кількість інформації з архівів.

Архівна версія сайту SyncDev.

Стів Бланк розвинув ідеї Френка Робінсона. У 2005 році, він написав книжку «The four steps to the epiphany», де представив методологію «Customer development, CD або CustDev».

Customer development та MVP — це 2-ві взаємопов'язані концепції (взаємодоповнюють одне одного).

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

Customer development є одним з ключових елементів методології Lean startup (базується на ідеях Стіва Бланка).

Процес Customer development для етапу «Search».

Ерік Ріс, співзасновник компані IMVU, а Стів Бланк, інвестор та консультант з 2004 року в цій же компанії. У 2011 році, Ерік Ріс популяризував концепцію MVP у своїй книзі «The Lean Startup».

В самому початку статті, я вказав, що одним з основних аспектів MVP є отримання зворотного зв'язку від реальних користувачів. Так от, методологія Lean startup базується на циклі зворотного зв'язку «Build (Створюй)-Measure (Вимірюй)-Learn (Вчись)». Lean startup є ітеративним процесом.

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

Цикл зворотного зв'язку «Build-Measure-Learn».

Приклад застосування Customer development, Lean startup та Agile для створення MVP

Давайте розглянемо стартап, який називатимемо «FoodFinder». Ідея (гіпотеза) полягає у створенні мобільного додатку, який допоможе користувачам знайти найближчі ресторани та кафе, а також замовляти їжу з доставкою.

Крок 1: Customer development (Customer discovery)

Визначення проблеми (розуміння цільової аудиторії): Проводимо дослідження та спілкуємося з потенційними користувачами, щоб зрозуміти їх потреби та проблеми, пов'язані з пошуком ресторанів та замовленням їжі.
Формулювання гіпотез про проблему та бізнес-модель: Базуючись на зборі інформації, ми формулюємо гіпотези про проблеми, з якими зіштовхуються наші цільові користувачі, а також про те, яка бізнес-модель буде найефективнішою для нашого продукту. Гіпотези про проблему допомагають нам зрозуміти, які потреби мають наші користувачі, а гіпотези про бізнес-модель визначають, як ми збираємося заробляти гроші на нашому продукті та яку цінність ми надаємо клієнтам.
Перевірка гіпотез та бізнес-моделі: Розробляємо прототип або wireframe додатка та проводимо тестування з декількома потенційними користувачами. Збираємо їх враження, фідбек та пропозиції щодо вдосконалення продукту. Одночасно оцінюємо ефективність нашої бізнес-моделі, з'ясовуючи, чи здатний наш продукт створити цінність для клієнтів та забезпечити комерційний успіх.”

Крок 2: Customer development (Customer validation)

Розробка MVP: На основі отриманого фідбеку та ідей збираємо команду розробників та дизайнерів і створюємо мінімально життєздатну версію нашого додатка «FoodFinder». Вона має базовий функціонал пошуку ресторанів та замовленню їжі.
Метрики та вимірювання: Встановлення метрик для визначення успіху продукту та збору даних щодо його використання та впливу на користувачів.
Випробування на ринку: Запускаємо MVP додаток на обмеженій кількості ринків або серед обмеженої аудиторії. Збираємо додатковий зворотний зв'язок від реальних користувачів та вносимо необхідні зміни.

У чому полягає роль Lean startup (Повторення та вдосконалення)?

Аналіз результатів: Аналізуємо дані з випробувань, зворотний зв'язок користувачів та метрики продукту для оцінки успішності та виявлення можливостей для поліпшення.
Вдосконалення продукту: На основі отриманої інформації та результатів аналізу вносимо необхідні зміни в продукт, додавши нові функції або виправивши проблеми.
Повторення циклу: Повторюємо цикл «Build-Measure-Learn» та ітерації Agile, постійно вдосконалюючи продукт і адаптуючись до змін потреб користувачів та ринку.

У чому полягає роль Agile?

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

Це загальний опис процесу, де кожен крок може включати більш детальні підкроки та дії. Застосування Customer development, Lean startup та Agile допомагає максимально зосередитись на потребах користувачів, ефективно використовувати ресурси та швидко реагувати на зміни, що робить процес розробки продукту більш гнучким та успішним.

Найкращі книги про Customer development та Lean.

Проблеми під час проєктування MVP

Зосередьтеся на пошуку правильної гіпотези замість маніакальної зосередженості на якості фічі та довгій розробці.
Слідкуйте за тим, щоб MVP виконував свою функцію на базовому рівні, тобто вирішував певну проблему користувачів, за які вони готові щомісячно платити гроші.
Якщо гіпотеза не підтверджується, розглядайте це як можливість для вдосконалення та набуття нових знань, а не як поразку.
Зберігайте всю інформацію, яка пов’язана з процесом створення MVP, наприклад, гіпотези, тести тощо.
Ретельно тестуйте цінність всього продукту, включаючи аспекти монетизації. Чому? Кожна бізнес-модель містить «Revenue streams». Важливо визначити, чи готові користувачі придбати ваш продукт за конкретну ціну, і чи будуть вони продовжувати платити за нього щомісячно. За це все відповідає — юніт-економіка (описує, скільки бізнес заробляє та витрачає на одного користувача) та аналітика продукту.

Близько 200 підписників достатньо для тестування юніт-економіки. Про це недавно писав мій колега Євген Олексюк. Прошу прочитати його статтю «Як керувати UX в стартапі».

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

Дивовижна історія однієї ідеї

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

Крім того, вони також мають платну підписку під назвою Unsplash+, яка розшюреє та додає деякі круті можливості.

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

Замість інвестування значних коштів та часу в розробку продукту з різноманітними функціями, такими як: профіль користувача, логін та реєстрація тощо, вони вирішили використати простішу стратегію. Команда створила блог на платформі Tumblr та придбала готову тему за $19. Потім, вони зареєструвалися в Dropbox, створили загальнодоступну папку та завантажили туди 10 високоякісних фотографій.

Перша версія Unsplash з темою Tumblr за $19.

За словами авторів, вони створили MVP за 3 години. Далі, фаундери представили Unsplash на Hacker News, інтернет-спільноту дизайнерів, розробників та підприємців, яка, на їх думку, може сподобатися Unsplash.

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

Електронний лист, який отримав Мікаель Чо від Dropbox після запуску Unsplash.

«Пишіть код тільки тоді, коли ви не можете придумати жодного іншого способу перевірити свою гіпотезу».

Марк Рендалл, головний стратег, віце-президент із креативності в Adobe.

Чому стейкхолдери не вірять чи не відчувають потреби в UX дослідженнях?

Yaroslav Zhmykhov — Mon, 13 Mar 2023 21:49:50 +0000

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

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

Стаття буде корисна:

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

Чому виникла ідея написати цю статтю?

Основне завдання UX дизайнера — це cпроєктувати цифровий продукт, який буде максимально ефективно вирішувати покладені на нього завдання.

Що це означає? Користувачі розпочинають користуватися вашим продуктом, тому що у них є певний список ПРОБЛЕМ та ПОТРЕБ, які вони прагнуть вирішити за допомогою якогось продукту.

Спочатку дозвольте розповісти вам невелику історію

До появи потужних цифрових музичних сервісів, можна згадати історію з Apple iPod (перше покоління побачило світ у 2001 році), який зробив революцію у свій час. Для тих, хто не знає, я коротко розповім про це. До цього фантастичного пристрою користувачі слухали піратську музику, яку завантажували з Інтернету (привіт Winamp плеєру). Проблема полягала не в бажанні платити за контент, а в банальній неможливості купити музичні треки (цілі альбоми) офіційно, і щоб куплений контент знаходився в одному місці, як це є зараз (Apple Music, Spotify, SoundCloud, Amazon Music, Deezer тощо).

На той час ще були популярні касети для плеєрів та оптичні диски (CD та DVD), і думка про те, що у вас може бути маленький пристрій, який поміститься в кишені та міститиме сотні ваших улюблених пісень, була просто недосяжною мрією. Компанія Apple побачила це, і зробила якісне рішення. Так і з’явився перший Apple iPod на який за допомогою програмного забезпечення iTunes Store можна було перенести усю вашу куплену бібліотеку.

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

Тепер змоделюємо ДУЖЕ просту ситуацію

Одного разу, гортаючи стрічку новин в Instagram, користувач побачив рекламу нового мобільного додатку для прослуховування музики, який надає доступ до понад 100 мільйонів треків з усього світу, і вирішив спробувати. Перейшов до Apple Store, завантажив його та відкрив. Для того, щоб розпочати користуватися ним, потрібно зареєструватися та оплатити щомісячну підписку в розмірі $5, що він і зробив (спочатку купи продукт, а потім користуйся — ми про це поговоримо пізніше).

Вже через 10 хвилин після початку взаємодії з цим мобільним додатком, користувач помітив відсутність КРИТИЧНОГО для нього функціоналу:

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

Давайте розберемося, що ж пішло не так?

На мою думку, через те, що команда розробників не змогла донести до стейкхолдерів важливу думку про необхідність UX-дослідження і получився «сирий» продукт, який не може бути конкурентноспроможнім на ринку, бо весь процес проєктування базувався на СУБ’ЄКТИВНОМУ баченні команди розробників та стейкхолдерів.

Як ви вже зрозуміли, отриманий продукт не вирішує поставлених на нього задач, оскільки не було достатньо детально проаналізовано, які саме ПРОБЛЕМИ та ПОТРЕБИ має цільова аудиторія (ЦА, target audience). В продукт було додано купу непотрібного функціоналу, а критично важливий був проігнорований. Скажу більше, а можливо стейкхолдери відмовилися від UX-досліджень, бо стверджували, що вони досконало розуміють цільову аудиторію, і потрібно слухати тільки те, що кажуть вони? Зрештою, продукт помирає (можливо, він навіть не окупився), а стейкхолдери втратили гроші, які вони вклали в розробку. Подумайте над цим…

Я вже про це писав в минулих статтях, але нагадаю ще 1-н раз:

Стейкхолдери ≠ користувачам;
Команда розробників ≠ користувачам.

Відповідь містера Купера на моє питання можна прослухати з 1:12:19

Для початку давайте розберемося, чому компаніям складно продати UX-дослідження (експертизу)

Загалом, причин може бути багато:

Недостатнє розуміння важливості UX-досліджень. На мій погляд, компанії сприймають UX-дослідження, лише як додаткову послугою, яку можна запровадити, якщо на це будуть виділені гроші та час. Успіх проєкту — це гарантія того, що стейкхолдери будуть рекомендувати вашу компанію своїм колегам (сарафанне радіо, word-of-mouth marketing), а ви, в свою чергу, отримаєте хороший проєкт та безцінний досвід, який можна буде розмістити на сайті (з дозволу стейкхолдерів) у вигляді UX case study для залучення нових проєктів. Істинна є дуже проста: якщо проєкт не є успішний та стейкхолдери не є задоволені? Тоді вони не дадуть дозволу на публікацію проєкту до вашого портфоліо;
Велика конкуренція з іншими послугами компанії. Повертаючись до попереднього пункту. Ваша компанія може бути зацікавлена в тому, щоб продавати стейкхолдерам інші послуги, які є більш очевидними та зрозумілими для них, а не якийсь незрозумілий UX-дизайн;
Велика конкуренція між ІТ-компаніями. Вам необхідно відрізнятися від інших, оскільки багато компаній надають схожі послуги. Я б міг написати конкретні поради, але це буде вашим домашній завданням. Сподіваюся, ви зрозумієте, чому я нічого не написав;
Відсутність належних знань. Зараз такий час, що дуже важливо постійно розвиватися та вивчати нове. На мою думку, є багато компаній, які досі не до кінця розуміють етапи процесу проектування та активності, які будуть чи можуть відбуватися на них. Щоб вирішити цю проблему, необхідно найняти професіонала (це дорого, і ця людина не буде приносити прямий дохід компанії), який зможе навчити команду дизайнерів (це досить довгий процес);
Артефакти, які не мають цінності для бізнесу. На мій погляд, цей пункт є найважливіший. Поясню чому. Припустимо, що стейкхолдери нарешті отримали фінансування на MVP (minimum viable product) від інвесторів, яких дуже довго шукали. У них дуже обмежені терміни запуску продукту, чітка сума на повну розробку та є певний список зобов'язання перед інвесторами. Вони просять вас вирішити їхню проблему, і ви відповідаєте: «Добре, але спочатку потрібно провести UX-дослідження, і це буде коштувати певну суму та місяць часу». І тут виникає проблема. По-перше, стейкхолдери отримають велику кількість артефактів, а це точно не те, з чим можна йти до інвесторів. По-друге, якщо стейкхолдерам не пояснити всю суть (цінність) UX-досліджень та не попередити, що фінальний продукт без цього може провалитися, вони підуть в іншу компанію, яка обіцяла зробити все чудово без цього етапу;
Відсутність UX портфоліо. Я не кажу про візуальне портфоліо на Behance чи Dribbble, я маю на увазі — UX case studies. Це історія про те, як ви розробляли минулі проєкти. Зайдіть на Medium та пошукайте UX Collective, тому що там є хороші приклади.

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

Ствердження стейкхолдерів №1: Якщо ви професійний дизайнер, ви можете спроєктувати продукт без UX-досліджень, бо з дослідженням може будь-хто. Навіщо мені платити вам за «дослідження», якщо інші компанії обіцяють виконати проєкт без дослідження, бо у них є колосальний досвід?

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

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

Ствердження стейкхолдерів №2: Ми не будемо витрачати гроші на дослідження. Давайте спроєктуємо продукт, а користувачі навчаться користуватися інтерфейсом під час взаємодії.

Відповідь: Це доповнення до попереднього пункту. Користувачі легко адаптуються до всього нового і мають схильність до навчання, незалежно від того, наскільки поганим є дизайн, але це забирає багато часу, нервів і зусиль, і це правило здебільшого працює з програмним забезпеченням (ПЗ), таким як Adobe Photoshop (реальні слова однієї вчительки: «Поки ми робили методичку для учнів з уроками, програма оновилася до іншої версії, і все стало по-іншому…». Для веб-сайтів (наприклад, Interaction Design Foundation) не існує такого поняття, як навчальний курс, а для цифрових продуктів (наприклад, Airbnb або Booking) було б дивно побачити 1-годинний курс на YouTube, перш ніж ви зможете ним користуватися.

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

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

Ствердження стейкхолдерів №3: Нам непотрібно проводити ніякі дослідження. Ми надали вам 2-ва сайти: Airbnb та Booking. Просто зробіть, як у них і все.

Відповідь: Це кардинально не правильний підхід. Ваші стейкхолдери ≠ Airbnb та Booking через велику кількість факторів. Ми маємо сприймати ці 2-ва сайти, як референси (best practices). Не все, що там є необхідно на вашому проєкті, і не все воно буде працювати. Необхідно добре проаналізувати конкурентів, зрозуміти хто є наша ЦА та які ПРОБЛЕМИ та ПОТРЕБИ мають саме ваші користувачі, і лише потім закрити їх за допомогою функціоналу.

Ствердження стейкхолдерів №4: Нам не потрібен на проєкті UX-експерт та «його» методи дослідження. Кожен із нас відповідає за користувацький дослід (UX).

Відповідь: Дійсно, всі члени команди повинні працювати над його покращенням, але коли відповідальність за щось лежить на всіх, це означає, що ніхто не несе відповідальності. Це означає, якщо стейкхолдери візьмуться за тестування інтерактивного прототипу, чи правильно вони проведуть модероване юзабіліті-тестування? За це повинен відповідати професіонал, оскільки це ключовий етап і ціна помилки є висока. Зрештою, якщо вся команда не є експертами в UX-дизайні (вони десь щось чули або читали), то продукт вийде не дуже якісним.

Ствердження стейкхолдерів №5: UX-дослідження — це не ІСТИНА в останній інстанції.

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

Тепер, аргументи, які дозволять вам переконати стейкхолдерів:

Аргумент №1: Із слів Якоба Нільсена (провідного спеціаліста в області користувацького досвіду та співзасновника Nielsen Norman Group) — проєкти в яких було витрачено 11% бюджету (середній показник) на UX отримали на 75% (середній показник) більше результату ніж проєкти, де не було застосовано UX дослідження.

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

Наприклад, продукт, надає певні послуги, є легким в користуванні, немає багів, адаптований під різні мобільні пристрої та має нормальну цінову політику, то користувачі будуть регулярно повертатися до нього і вирішувати їх ПРОБЛЕМИ та ПОТРЕБИ за допомогою нього. Також, рекомендувати його своїм друзям та колегам.

Аргумент №2: UX-дизайнеру не потрібно використовувати усі на світі методи дослідження, які знає людство. UX-дизайнер — це професіонал, який розуміє, який саме мікс-досліджень необхідний, щоб вирішити ту чи іншу проблему. Все дуже індивідуально і загального рецепту просто не існує. Дизайн — це не лінійний процес.

До прикладу:

Якщо вже є існуючий продукт, то варто за кілька тижнів до початку проєкту встановити Hotjar + Google Analytics, і налаштувати їх, щоб вже в перший день, UX-дизайнер міг отримати кількісні (метрики, карти кліків користувачів на кожній із сторінок веб-сайту тощо) та якісні дані (поведінку користувача через запис екрана, теплові карти тощо), і таким чином, UX-дизайнер буде мати набагато більше вихідної інформація, яка зекономить час та гроші;
Якщо ж розробляється MVP (minimum viable product), і про цільову аудиторію практично нічого не відомо, то на відміну від попереднього прикладу, де ми можемо подивитися дані про нашу цільову аудиторію (в загальних рисих), в цьому випадку нам прийдеться організувати воркшоп з стейкхолдерами для пропрацювання прото-персони (proto-personas).

Аргумент №3: Більшість UX-досліджень не коштують неймовірно багато грошей та часу. Ми живемо у світі, де є безліч дешевих сервісів для пошуку, проведення інтерв’ю та юзабіліті тестувань тощо.

Наприклад, немодероване юзабіліті тестування. Це не дешеве задоволення, але воно приносить неймовірний результат. Отже, розпочнімо:

Підготовка. Якщо певний розділ, який ми будемо тестувати в інтерактивному прототипі був спроєктований заздалегідь з усіма можливими користувацькими шляхами, то ви є молодець. Якщо ж ні, то щоб закрити цю проблему, в моєму середньостатистичному проєкті — необхідно до 4-х годин;
Розробка сценарію тестування (testing script). В середньому, на це йде до 4-х години + 1-на година на пілотне тестування (чи завдання є чіткі та усім зрозумілі);
Створення проєкту в певному сервісі та перенесення завдань. Ця частина ніколи не займала в мене більше ніж 2-ві години + 1-на година на тестування;
Розповсюдження посилання на тестування. Це може відбуватися через масову розсилку електронного листа або оформлення посту в соціальних мережах продукту — необхідно до 2-х годин + 1-на година на написання якісного тексту;
Аналіз данних та звіт. Це сама важка частина, яка потребує максимальної уваги. Усе залежить від кількості отриманих даних, але середня цифра — це 16-ть годин + 1-на година на довільне оформлення звіту тестування.

Ми отримали — 32 години. З відкритих джерел відомо, що 1-на година UX Senior Designer коштує стейкхолдерам ≈$30. Давайте порахуємо: 32*30=$960. Дорого? Це ще не все. Якщо результати є плачевні, то ми НЕ випустили у світ продукт, який не буде вирішувати поставлені на нього задачі, і тим самим ЗЕКОНОМИЛИ час та гроші стейкхолдерам, бо дальше нашого інтерактивного прототипу — це рішення не пішло. Але з отриманих даних, ми знаємо і бачимо, де є помилки та досить легко можемо їх виправити. Тепер, якщо результати є задовільні, то ми знову ЗЕКОНОМИЛИ час та гроші стейкхолдерам, і він може спати спокійно, що не втратить усе.

Результат

На мою думку, якщо тестування цілого інтерактивного прототипу обійдеться в ≈$3к, то це ціна юзабіліті, яка багаторазово окупиться після запуску продукту.

І наостанок, як доповнення до попереднього пункту, ще один гарний приклад, який ви можете використати при спілкуванні зі стейкхолдерами

Змоделюйте покупку нового iPhone 14 Pro Max, який коштує в США приблизно $1099. Людина, яка довго збирала гроші, щоб порадувати себе новою покупкою (іноді розробка складного продукту може коштувати понад $100 тис.), добре розуміє, скільки коштуватиме ремонт дисплея або заміна корпусу, якщо вона пошкодить смартфон.

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

Висновок

Згідно думки Якоба Нільсена, раніше користувачі спочатку платили гроші, а потім отримувати користувацький досвід, і компанії користувалися цим, оскільки гроші користувача вже були у їхніх кишенях. Зараз ситуація змінилася. Спочатку користувачі отримують свій UX, і тільки якщо він ефективний (вирішує їх ПРОБЛЕМИ та ПОТРЕБИ) компанії отримують гроші користувачів.

Іншими словами, спочатку ось тобі пробний період нашого продукту, спробуй його. Сподобався? Будь-ласка, а тепер заплати за повне користування. Я думаю, що думку ви зрозуміли.

🇺🇦 Бережіть себе та ваших близьких.

Донатьте на ЗСУ.

Продукти для транскрипції інтерв'ю

Yaroslav Zhmykhov — Tue, 24 Jan 2023 11:57:17 +0000

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

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

1. Google Meet (найкраще рішення)

Щоб використовувати цей спосіб вам необхідно мати корпоративний акаунт або преміум (більш детальніше про це тут).

Крок 1. Створіть зустріч та запросіть необхідних учасників.

Крок 2. Під час зустрічі вас слід натиснути на іконку із 3-ма крапочками, яка знаходиться внизу. У списку додаткових функцій, що відкриється, натисніть на «Manage recording».

Крок 3. Після цього, ви побачите новий екран, в якому вам слід натиснути на чекбокс «Also start a transcript (English only)».

Також, прийміть умови запису та транскрипції.

Крок 4. У верхньому лівому кутку екрана ви побачите 2-ва нові елементи інтерфейсу, які сигналізуватимуть про запис і транскрипцію зустрічі.

Крок 5. Після завершення зустрічі у вашому Google Drive з'явиться нова папка з назвою «Meet Recordings», де ви знайдете запис екрана та його розшифровку.

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

2. Otter

Веб-сайт: https://otter.ai/

Це рішення я рекомендую, якщо у вас вже є відео чи аудіо, яке потрібно розшифрувати. Продукт є дуже функціональний та якісно виконує свою роботу. Річна підписка коштує $99 (знімає всі обмеження). Безкоштовна версія має лише 30 хвилин на кожну транскрипцію, але всього Otter дає 300 безкоштовних хвилин в місяць.

Лайфхак: наприклад, якщо тривалість файлу 45 хвилин, то розділіть його на 2-ві частини (30 та 15 хвилин), щоб отримати транскрипцію.

3. Transcribe

Веб-сайт: https://transcribe.com/

Це дорогий продукт. Крім транскрипції, не має жодного іншого функціоналу, на відміну від Otter, який має багато інших сервісів. Річна підписка коштує $99, яка містить лише 5 годин транскрипції відео в місця, а кожна наступна година коштує $4.99.

4. Happy Scribe

Веб-сайт: https://www.happyscribe.com/

Окрім автоматичної транскрипції, яка коштує €0.20 за хвилину, він також містить і людську транскрипцію, яка коштує €2 за хвилину. Іншими словами, 1 розмова, яка тримає 1 год буде коштувати вам €12. Дорого? Вирішувати вам.

Мапа задачі та сценарію користувача

Yaroslav Zhmykhov — Fri, 30 Dec 2022 14:15:39 +0000

ЕТАП 5: ДИЗАЙН

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

Ціль мапи задачі користувача

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

Ціль мапи сценаріїв користувача

Допомагає описати послідовність дій користувача, а саме: початок (старт), можливі розвилки та кінець (виконання завдання).

Цінність для команди

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

Цінність для бізнесу

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

Тривалість:

Підготовка: до 30 хвилин
Діяльність: від 4 до 6 годин

Інформація про методи:

Зображення було взяте з статті «UX task flows vs. user flows, as demonstrated by pancakes». Автор: erika.

Мапа задачі користувача (task flow)

Мапа задачі користувача (task flow) є зосередженою у тому, як користувач переміщається платформою під час виконання конкретного завдання.

Важливо: мапа задачі користувача показує лише 1-н шлях і НЕ МІСТИТЬ В СОБІ розвилки чи точки прийняття рішень, як це може бути в традиційному сценарії користувача. Іншими словами, мапа є лінійною та послідовною, показує лише високорівневі кроки, які людина повинна зробити, щоб досягнути певних цілей або кінцевої точки. Як правило є простою, а не складною для розуміння.

Task flow є основою для проєктування потенційно складних user flows.

Task flow зосереджується на окремих завданнях (не на якомусь користувачеві, хоча можуть бути можуть бути вбудовані в user flow — приклад буде внизу), тоді як user flow, зосереджуються на конкретному користувачеві (тобто на певному сегменті або персоні).

Найкраще task flow застосовувати тоді, коли завдання виконується однаково всіма вашими користувачами.

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

Мапа сценарію користувача (user flow)

Мапа сценарію користувача (user flow) — це блок-схема, що складається з прямокутників (дії користувача), ромбів (умови для переходів) та стрілок (переходи). Мапа потрібна, щоб показати, які кроки здійснює користувач в рамках ПЕВНОГО сценарію для виконання якогось ПЕВНОГО завдання.

Важливо: якщо ви розумієте, що існують варіації того, що користувач може ще зробить (наприклад, користувач додає товар в кошик, то в нього з'являється наступний вибір дій: перейти в розділ з оплатою чи продовжити покупки в інтернет-магазині), ми обов'язково пишемо умову, щоб зрозуміти, в якому випадку та яким шляхом піде наш користувач в рамках ПЕВНОГО завдання.

1 мапа сценарію користувача вирішує лише ОДНУ конкретну користувацьку задачу.

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

Приклад мапи сценарію користувача для гри на мобільний додаток.

Важливо: обов’язково використовуйте легенду для ваших фловів! Без неї дуже важко читати інформацію.

Приклад легенди для мапи сценарію користувача.

Task flow vs. user flow

Приклад мапи задачі користувача для приготування млинців. Зображення було взяте з статті «UX task flows vs. user flows, as demonstrated by pancakes». Автор: erika.

Приклад мапи сценарію користувача для приготування млинців. Зображення було взяте з статті «UX task flows vs. user flows, as demonstrated by pancakes». Автор: erika.

Приклад мапи задачі користувача для пошуку рецепта млинців. Зображення було взяте з статті «UX task flows vs. user flows, as demonstrated by pancakes». Автор: erika.

Приклад мапи сценарію користувача для пошуку рецепта млинців. Зображення було взяте з статті «UX task flows vs. user flows, as demonstrated by pancakes». Автор: erika.

Інформаційна архітектура

Yaroslav Zhmykhov — Tue, 20 Dec 2022 12:24:35 +0000

ЕТАП 5: ДИЗАЙН

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

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

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

Ціль

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

Цінність для команди

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

Цінність для бізнесу

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

Тривалість:

Підготовка: до 30 хвилин
Діяльність: від 2 до 4 годин

Інформація про метод:

Інформаційна архітектура (information architecture, IA) — це дисципліна, яка дозволяє зробити інформацію доступною та зрозумілою для користувачів. Іншими словами, інформаційну архітектуру можна назвати практикою для ефективної організації контенту.

Ще визначення.

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

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

Якщо ви захочете збудувати будинок, то я впевнений на 99% (якщо ви ним не являєтеся), що ви звернетеся до архітектора, який спроєктує для вас дім під ваші потреби. В даному контексті — ви і є цей архітектор. Інформаційна архітектура використовується, як і в фізичному світі (наприклад, під час проєктування супермаркету), так і в діджиталі (веб-сайти чи мобільні додатки).

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

Чудова інформаційна архітектура заснована на: змісті (content), контексті (context) та користувачах (users).

Важливо: інформаційна архітектура НЕ ПОКАЗУЄ жодного сценарію, оскільки вона не існує в площині конкретної користувацької задачі (не описує дії користувача).

8-м принципів інформаційної архітектури (автор: Dan Brown)

Принцип об’єктів (principle of objects). Ставтеся до контенту, як до живої, дихаючої речі зі своїм життєвим циклом, поведінкою та атрибутами. Ви повинні починати ваш проєкт із визначення типів контенту, які будуть присутні (як у широкому, так і детальному масштабі). Наприклад, інтернет-магазин ROZETKA добре справляється з групуванням пов'язаного контенту, а також визначає поведінку та атрибути кожної групи;

Принцип вибору (principle of choices). Цей принцип каже, що вам необхідно пропонувати своїм користувачам осмислений вибір. Занадто великий вибір може приголомшити користувача та негативно вплинути на його враження від використання продукту. Наприклад, інтернет-магазин Houzz показує користувачам все, що тільки можна: Visually similar products, related products, people who liked this product also like, best seller products, frequently bought together, 4 stars and higher;

Принцип розкриття інформації (principle of disclosure). Покажіть користувачу стільки інформації, скільки потрібно, щоб допомогти йому зрозуміти, яку інформацію вони знайдуть, якщо «копнуть» глибше. Якщо користувач не зацікавлений або готовий обробляти інформацію, яку ви йому подаєте, по суті, ми це можемо назвати — «шумом». Основна ідея полягає у тому, щоб не перевантажувати користувача, намагаючись втиснути все на одну сторінку;

Принцип зразків (principle of exemplars). За допомогою прикладу, ви значно полегшуєте вашим користувачам розуміння того, що вони отримують. Це значно покращує користувальницький досвід (UX). Дана концепція заснована на психології того, як людський мозок класифікує елементи, щоб швидше та краще засвоювати інформацію;

Принцип вхідних дверей (principle of front doors). Ви повинні розуміти, що користувачі можуть потрапити на вас сайт не тільки з головної сторінки, але й з інших. Іншими словами, користувач повинен розуміти, де він знаходиться, і що він може рухатися далі. Наприклад, Google Ads, який завжди показує користувачу CTA кнопки в шапці сайту для подальших дій, і це не залежить від сторінки на яку потрапив користувач;

Принцип множинної класифікації (principle of multiple classification). Ваші користувачі повинні мати різні (альтернативні) способи перегляду контенту, тому що різні люди можуть використовувати різні методи пошуку інформації у вашому продукті. Наприклад, повернемося знову до інтернет-магазину ROZETKA. Перший тип користувачів захоче переглянути всі павербанки в розділі «Універсальні мобільні батареї», другий тип — лише з об’ємом більше ніж 20 тисяч мА/год, а третій тип — захоче сортувати продукти від дешевих до дорогих;
Принцип сфокусованої / ціленаправленої навігації (principle of focused navigation). Спроєктоване вами меню є основним (для більшості) методом пошуку контенту для користувачів. У багатьох випадках на сайті може бути кілька навігаційних меню, що забезпечують різні способи доступу до вмісту. Саме тому, Google Ads має різні стратегії (2-ва різні типи інформації) щодо HEADER та FOOTER;

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

Типи інформаційних архітектур

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

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

Глибокий (deep). Більш простіше меню, але вимагає більше кліків на шляху до мети. Наприклад, Walmart.

Іншими словами, це веб-сайти, які використовують довгі шляхи для доступу до певних сторінок сайту.

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

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

Тестування інформаційних архітектур

Card sorting (карткове сортування) — це техніка, яка допомагає зрозуміти, як користувачі розуміють (сприймають) і класифікують інформацію;
Tree testing (деревоподібне тестування) — це спосіб оцінки існуючої структури сайту (користувачам пропонують знайти сторінку чи розділ на основі існуючої структури).

Типи інформаційних архітектур:

Категорії (categories). Це найпоширеніший тип інформаційної архітектури. Переважно використовується в інтернет-магазинах;

Завдання (tasks). Переважно використовується в банках, оскільки за основу взято задачі, які користувачу необхідно вирішити;

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

Час (time). Мається на увазі інформаційна архітектура, котра буде змінюватися змінюється у часі. Наприклад, Gmail, Reddit чи стрічка новин у Facebook. Це дизайн, який є побудований на часі;
Люди (people). Це інформаційна архітектура, збудована на людях. Наприклад, Facebook. Дизайн цієї соціальної мережі обертається навколо якоїсь конкретної людини та її стосунків з іншими людьми.

Важливо: типи IA можна комбінувати! Наприклад, всередині кожного профілю компанія Facebook використовує систему категорій (для організації інформації ): фотографії, друзі, місця тощо.

Приклад інформаційної архітектури, яка є не зовсім зрозуміла саме мені (суб’єктивна думка)

Я вирішив замовити потужний павербанк в інтернет-магазині ROZETKA.

Цікаво: інформаційна архітектура цього магазину поєднує 2-ва типи: категорії та пошук (можливо я не правий, то ви підкажіть).

Отже, я відкрив «Каталог» та розпочав пошук категорії з павербанками, але не зміг знайти. Тоді я скористався пошуком. Сторінка з результатами дала зрозуміти мені, що павербанки все ж таки є, але я шукаю не там. Розібратися в даній проблемі мені допоміг функціонал з хлібними крихтами. Нарешті я зрозумів, що ROZETKA віднесла павербанки до розділів «Аксесуари до мобільних телефонів і смартфонів» > «Універсальні мобільні батареї». Особисто для мене павербанк не є аксесуаром для мобільних телефонів і смартфонів, оскільки я заряджаю свій ноутбук, годинник, навушники тощо саме за допомогою павербанку під час вимкнення світла.

Наприклад, інтернет-магазин MOYO відніс павербанки до розділів «Зовнішні акумулятори» > «Зовнішні акумулятори (Powerbank-и)». Я легко зміг знайти те, що хотів, оскільки навігація містить розділ «Електроживлення», який в собі має підрозділ «Powerbank (зовнішні акумулятори)».

Що я цим хотів сказати? У випадку з ROZETKA — я затратив набагато більше часу, і був вимушений скористатися пошуком (що не є дуже критично, оскільки проєктувальникам вдалося виправити ситуацію через дотримання принципу множинної класифікації (principle of multiple classification). У випадку з MOYO — я знайшов необхідний розділ дуже швидко.

Оформлення інформаційних архітектур в артефакт

Приклад інформаційної архітектури сайту tickets.ua

ПРИКЛАД

Важливо: обов’язково викоритовуйте легенду для ваших карт! Без неї дуже важко читати їх.

Приклад легенди для інформаційної архітектури

Приклад опису контенту

Важливо: обов’язково описуйте блоки та елементи інтерфейсу, які будуть на кожній сторінці. По-перше, вам буде легко запрезентувати структуру команді та стейкхолдерам, по-друге, стейкхолдери зможуть самостійно оцінити її та надати вам розширений фідбек.

Порада

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

Дизайнерські терміни, які повинен знати кожен

Yaroslav Zhmykhov — Tue, 22 Nov 2022 15:56:30 +0000

Сьогодні я поділюся термінами, котрі на мою думку повинен знати кожен дизайнер, оскільки це є фундамент. Я не претендую на істинну в останній інстанції, я лише ділюся своїм досвідом, який я отримав, працюючи дизайнером протягом 8-ми років.

Дизайн (design)

Це більше про те, як воно ПРАЦЮЄ і СПРОЄКТОВАНО, ніж те, як воно виглядає. Дослівно перекладається, як «проєктування».

“The design is not just what it looks like and feels like. The design is how it works” — Steve Jobs

Дизайнер (designer)

Це людина, яка вирішує ПРОБЛЕМИ бізнесу та користувачів за допомогою інтерфейсу.

Інтерфейс (interface)

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

Інтерфейси поділяються на 4-ри типи: людиноорієнтовані, машинні, програмні та графічні:

Нижче наведені визначення були взяті із статті «Що таке інтерфейс. Різновиди інтерфейсів» від CASES Media.

Людиноорієнтовані інтерфейси — це інтерфейси, котрі є призначені для взаємодії людини з якою-небудь іншою системою. Наприклад, кнопки ліфта чи дверна ручка вашої квартири;
Машинні інтерфейси допомагають взаємодіяти між собою машинам та механізмам. Наприклад, велосипедний ланцюг — це інтерфейс взаємодії педалей і колеса.
Програмні інтерфейси допомагають програмам взаємодіяти між собою (через API);
Графічні інтерфейси допомагають нам взаємодіяти з
з електронними пристроями. Наприклад, операційна система вашого смартфона.

За способом взаємодії інтерфейси бувають:

Голосові (наприклад, Siri або Hey Google);
Жестові (наприклад, за допомогою пальця, руки чи голови);
Тактильні або сенсорні (наприклад, сенсорний дисплей);
Візуальні (відслідковування руху очей);
Матеріальні (за допомогою клавіатури та мишки, джойстика тощо).

Користувацький інтерфейс (user interface, UI)

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

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

Досвід (experience)

Це знання, навички та вміння, котрі людина набула протягом певного проміжку часу (раніше).

Користувальницький досвід (UX, user experience)

Загальноприйнятого визначення «Що таке UX» не існує, але існують експерти.

Для того, щоб зрозуміти, що таке UX (user experience, користувальницький досвід), звернімося до слів Дона Нормана, співзасновника та консультанта Nielsen Norman Group та автора кількох книг про досвід користувача.

Він розповідає про те, як працював в компанії Apple, коли комп’ютери тільки починали з’являтися в продажі, і згадує, що в той момент вони думали про користувальницький досвід.

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

Перший комп’ютер від компанії Apple I.

Всі перелічені моменти вище тоді вважалися користувальницьким досвідом, тому що це все — точки дотику з продуктом, і кожен з цих моментів впливає на досвід користувача.

Будь-який досвід взаємодії користувача з продуктом є користувацьким досвідом.

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

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

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

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

Досвід користувача з'являється лише тоді, коли продуктом фактично починають користуватися.

Тобто, немає користувачі — немає UX.

Також, UX може навіть не бути безпосередньо пов’язаним з самим продуктом. Наприклад, коли ви розповідаєте комусь про продукт — ви ділитися своїм досвідом.

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

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

Досвід не можна намалювати, спроектувати чи розробити. Його можна лише отримати!!!

Команда розробників може лише створити ЗАСІБ отримування цього досвіду, наприклад, мобільний додаток.

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

Користувацький досвід — це сприйняття та реакції користувача, які є результатом використання (взаємодії) та/або очікуваного використання продукту, системи чи послуги.

Сприйняття та реакція користувачів включають: емоції, переконання, уподобання, сприйняття, комфорт, поведінку та досягнення користувачів, які виникають до, під час та після використання.

Погугліть, що таке ISO 9241-210:2019.

Приклад добре спроєктованого UX:

Ви: користувач квартири;
Проблема: немає світла в кімнаті;
Потреба: включити світло;
Ви взаємодієте з: одноклавішним вимикачем світла, який ставите в положення — вверх;
Ваші очікування: появиться світло;
Результат: в кімнаті появилося світло.

UX дизайн (UX design, UXD)

Це процес, за допомогою якого визначається, який досвід отримає користувач, використовуючи ваш продукт.

UX дизайн — це процес проєктування, єдиною метою якого є розробка системи, яка запропонує чудовий досвід користувачам.

UX дизайн охоплює такі дисципліни, як: дизайн інтерфейсу користувача, зручність використання, доступність, інформаційна архітектура і взаємодія людини з комп'ютером.

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

Дизайнер користувацького досвіду (UX designer) розуміє, хто їх користувачі, виявляючи та розставляючи пріоритети в тому, чого вони хочуть, а потім плануючи та створюючи досвід для ефективного, дієвого та приємного задоволення цих потреб – і все це при балансуванні бізнес-цілей.

UX designer = дизайн взаємодії + знання методик дослідження користувачів.

Процес проєктування користувацького досвіду (UX design process, UXDP)

Це інтерактивний процес, який переважно містити 4-ри основні фази: business/user research, design, testing та implementation. Дизайнер сам створює цей процес відповідно до задач, котрі перед ним ставлять.

Приклад UX дизайн процесу з Інтернету

Дизайн взаємодії (interaction design, IxD)

Це створення діалогу між користувачем та продуктом, системою чи послугою.

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

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

Дизайнер взаємодії (interaction designer) — проєктує взаємодію користувачів із інтерфейсом.

Дизайн взаємодії (IxD) є частиною дизайну досвіду користувача (UXD).

Words, Visual representations, Physical objects or space, Time та Behaviour — це 5-ть аспектів дизайну взаємодії.

UX design проти Interaction design

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

Зручність та простота використання або ступінь зручності використання (usability)

Це ступінь, в якому система, продукт чи послуга можуть бути використані ПЕВНИМИ користувачами для досягнення ПЕВНИХ цілей з ефективністю, результативністю та задоволенням у ПЕВНОМУ контексті використання.

Погугліть ISO 9241-210:2019.

Інтуїтивно зрозумілий інтерфейс

Це насправді просто рішення, яке попадає в ментальну модель користувача.

Ментальна модель (mental model)

Це особистий суб’єктивний попередній досвід, який відображає лише особисте відношення до об’єктів та процесів, і може не відповідати дійсності. Також, ментальна модель 1-ї людини може відрізнятися від інших людей.

Responsive проти Adaptive design

Pезиновий дизайн (responsive design) — це гнучкий підхід, де всі пропорції елементів інтерфейсу задаються в %. Тобто, велика версія сайту сама адаптується під розширення екрану користувача.

Адаптивний дизайн (adaptive design) — це «breakpoints» підхід, тобто дизайнер створює макети для певних розширень сайту. Наприклад, xs (<576px), sm (≥576px), md (≥768px), lg (≥992px), xl (≥1200px), xxl (≥1400px).

Карта подорожі покупця

Yaroslav Zhmykhov — Fri, 28 Oct 2022 10:16:00 +0000

ЕТАП 3: АНАЛІЗ

Це один з найпотужніших і найгнучкіших інструментів мапінгу (journey), який візуалізує всі точки дотику (контакту) покупця/клієнта (customer/client) з компанією, послугою (сервісом) чи продуктом. Даний артефакт ілюструє подорож покупця. Інструмент Human-centered design (HCD).

Я б хотів розпочати з того, що в Інтернеті, ви можете побачити наступні терміни: user journey map (UJM), customer journey map (CJM) або employee journey map (EJM).

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

Висновок: відповідно, шлях цих персон буде різний, і цілі теж різні.

Отже, даний метод мапінгу підходить як для опису поточної ситуації (as-is), так і для проєктування чогось нового (to-be). Цей інструмент в першу чергу, про сервіси та послуги, а користувальницький інтерфейс тут знаходиться на другому плані.

Ймовірно (ніде не знайшов достовірної інформації), першою використала термін «Customer journey map (CJM)» компанія IDEO (одна із найбільших компаній у світі, котра займаються сервісним дизайном та впровадженням інновацій), але це не факт, тому що чіткої інформації про це немає.

Карта подорожі покупця (customer journey map, CJM) – це інструмент (документ), в якому відображено процес вирішення задач користувачами через точки контакту з вашою компанією, послугою (сервісом) чи продуктом. Це свого роду часова шкала із важливими відмітками про користувацький досвід.

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

Наприклад, інтернет-магазин – це сервіс (сайт-каталог, доставка, служба підтримки 24/7, власний склад з товарами тощо). CJM такого сервісу буде містити все з моменту знайомства з брендом до отримання посилки у відділенні «Нова пошта» (або кур'єрська доставка додому).

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

Важливо: в минулій статті «Користувацькі персони» я описав детально наступні визначення: клієнт (client), покупець (customer або buyer), споживач (consumer) та користувач (user).

Приклад #1. Дизайнер – це користувач програми для проєктування Axure RP 10, а компанія, котра купила корпоративний акаунт для дизайн-команди – це і є покупець.

Приклад #2. Адміністратор онлайн-платформи Preply (додаток для вивчення мови та платформа електронного навчання) є користувачем, а студент, котрий шукає собі репетитора – покупець.

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

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

Коли цей артефакт не потрібно робити

Якщо ваш проєкт не містить сервісу та самого покупця;
Карта основана на суб’єктивній думці команди та стейкхолдерів (не робіть так), а повинна бути результатом попередніх досліджень (не вашої великої фантазії). Наприклад, користувацьке інтерв'ю, опитування чи спостереження (аналітика за допомогою Hotjar чи Google Analytics, польове дослідження (field studies) або щоденникове дослідження (diary study) та інші методи досліджень);
Якшо вам просто необхідно візуалізувати взаємодію користувача з інтерфейсом, то краще використовуйте: swimlane diagram, user flow або user tasks. Ці інструменти ідеально підійдуть, щоб описати процес взаємодії в рамках користувацького чи клієнтського завдання.

Чому так? CJM охоплює весь шлях клієнта (від і до), а не тільки «якусь» взаємодію користувача з вашим сайтом. Наприклад, якщо це інтернет-магазин (це сервіс), але ви все ж таки створите CJM, де користувач обере необхідний товар та замовить його, то це не буде являтися тим CJM про який ми так багато чули, оскільки така карта не охопить ВЕСЬ ШЛЯХ клієнта.

Існує кілька способів, щоб описати взаємодію користувача

Карта взаємодії (наприклад, user flow). Відображає інформацію про те, хто (яка роль) виконує завдання і в якій послідовності. Карта будується за результатами інтерв'ю;
Карта подорожі покупця (customer journey map). Це сценарій покупця, де основний фокус йде на те, що приведе людину до покупки та лояльності до сервісу;
Карта сервісного сценарію (service blueprint). Це карта, котра ще більше розширює карту подорожі покупця. Це сценарій роботи всього сервісу, де основний фокус йде на те, щоб показати взаємопов'язані дії всіх співробітників та системи, котрі приведуть до виконання користувацького запиту (не обов'язково покупця). Дуже часто містить офлайн процеси.

Карта подорожі покупця відрізняється від карти сервісного сценарію контекстом та фокусуванням на різних речах.

Коли цей артефакт потрібно робити

Це є сервісний інструмент (він ідеально підходить для business-to-consumer/client (B2C)), тому ви можете застосовувати його під час аналізу вашого існуючого сервісу;
Якщо це новий сервіс, і тільки на командному воркшопі.

Важливо: CJM не складається на самоті. Запросіть команду та стейкхолдерів.

Приклад проєкту, де треба розробка CJM (аналіз поточного сервісу):

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

Цінність для команди

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

Цінність для бізнесу

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

Тривалість:

Підготовка: до 30 хвилин
Діяльність: від 8 до 16 годин

Процес створення:

Ви можете піти 2-ма шляхами:

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

Важливо: суворої стандартизованої нотації (певна система умовних позначень, котра прийнята в якійсь галузі) у CJM немає. Тому, все залежить від ваших цілей. Кроки в CJM називаються – шарами (layers) з даними.

Рекомендую прочитити книжку «Mapping Experiences: A Complete Guide to Creating Value through Journeys, Blueprints, and Diagrams». Автор: Jim Kalbach.

Крок 1. Обираємо для якої персони (user persona) ми будемо будувати карту подорожі покупця

Важливо: 1 персона = 1 CJM!

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

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

Крок 2. Етапи (stages) та шлях покупця (сustomer journey)

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

Етапи (stages) – це дуже високорівневі кроки.

Приклад етапів для інтернет-магазину:
До замовлення, під час замовлення та після замовлення.

Шлях покупця (customer journey) – це одне з найважливіших речей, котрі ви повинні добре продумати.

Дуже важливо: шлях повинен починатися із знайомства з вашим сервісом!

Приклад шляху покупця для інтернет-магазину:

До замовлення (виникнення та усвідомлення потреби, пошук та інтернет-магазину);
Під час замовлення (пошук необхідного товару, ознайомлення з товаром, оформлення замовлення);
Після замовлення (очікування, отримання замовлення у відділення «Нова пошта», використання, відгук про куплений товар, рекомендація друзям, повернення до інтернет-магазину).

Крок 3. Точки дотику (touchpoints)

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

Рекомендація: не робіть дуже багато точок дотику.

Приклад точок дотику:

Загальні точки дотику: візитка, презентація, якась людина, будівля, офіс або дзвінок в службу підтримки, Інтернет, веб-сторінка, демо продукту тощо;
Точка дотику до підетапу «пошук інтернет-магазину»: Інтернет, знайома людина чи друг, реклама.

Дуже важливо: точки дотику та канали взаємодії можна об’єднати в один блок, але ви повинні розуміти, що це різні речі.

Може бути так, що точка дотику та канал – це одне і теж. Точки дотику легко можна переплутати з каналами.

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

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

Крок 4. Канали взаємодії (channels)

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

Приклад каналів:

Загальні канали: соціальні мережі, чат-бот, колл-центр, мобільний додаток, вебсайт, розмова з друзями або спілкування віч-на-віч тощо;
Канали для підетапу «пошук інтернет-магазину»: пошукова система (наприклад, Google search), живе спілкування, соціальна мережа (наприклад, Instagram).

Крок 5. Процеси (process)

Процеси бувають:

Linear | Non-linear time-based | Ongoing, non-linear or cyclic | Bi-directional

Лінійний (linear). Процес має наявність первного набору обов'язкових кроків, котрі повинні виконувати клієнт послідовно (один за одним). Клієнт не може перейти від А до С без B;
Нелінійний за часом (Non-linear time-based). Якщо лінійний процес – це чітка послідовність виконання дій, то нелінійний процес дає клієнту деяку свободу в у переході від точки А до С. Початкова та кінцева точка є відомі, але самий шлях може бути різний;
Циклічний нелінійний процес (ongoing, non-linear або cyclic). Процес повторюється час від часу;
Двонаправлений (bi-directional). Це лінійні процеси, де одне завдання спричиняє інше і клієнт може повернутися до попереднього кроку.

Крок 6. Дії (actions)

Вам потрібно вказати дії клієнта, котрі він повинен зробити (або робить) для досягнення своїх цілей.

Крок 7. Бар'єри, проблеми та обмеження (barriers, problems and restrictions)

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

Приклад бар'єру:
Оплата товару здійснюється виключно карткою Visa чи MasterCard (LiqPay).

Крок 8. Цілі та потреби (goals and needs)

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

Приклад цілей та потреб до підетапу «пошук інтернет-магазину»:
Знайти зручний та безпечний інтернет-магазин, котрий буде містити якісні товари з відгуками та помірними цінами, і швидкою доставкою по всій Україні.

Крок 9. Очікуваний результат (expected outcome)

Це те, що очікує побачити ваш клієнт після того, як зробить дію (action).

Приклад очікування до дії «Клієнт додає обраний товар в корзину»:

Система додасть обраний клієнтом товар і запропонує оформити замовлення.

Крок 10. Думки та почуття (thoughts and feeling)

Для кожної дії ви можете додати реальні думки та те, що вони відчували під час їх виконання. Ці дані повинні бути реальними. Не потрібно їх вигадувати.

Крок 11. Питання (questions)

У цьому розділі, ви можете вказати питання, які виникають у ваших клієнтів на кожному з підетапів.

Приклад питання під час пошуку інтернет-магазину:

Цікаво, який з інтернет-магазинів, які я знайшов у пошуковій системі Google, запропонує мені якісний товар за розумною для мене ціною?

Крок 12. Емоції (emotions)

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

Крок 13. KPI’s (key performance indicators)

Це показники, котрі допомагають оцінити взаємодію з компанією. Вибір KPI залежить від потреб вашої компанії, замовників та галузі.

Приклад KPI’s:
Загальна кількість сеансів (total sessions), середня тривалість сеансу (average session duration), показник відмов (bounce rate) тощо.

Крок 14. Ідеї та можливості (ideas and opportunities)

Ви визначили бар'єри, проблеми та обмеження, а тепер, ви повинні знайти рішення, як можна вирішити їх.

Приклад ідеї чи можливості:

Бар'єр: оплата товару здійснюється виключно карткою Visa чи MasterCard (LiqPay);
Ідея (технічне рішення): додати функціонал оплати під час отримання товару;
Організаційний момент (додаток до рішення): переглянути документацію чи це можливо реалізувати за допомогою існуючого модуля (плагіну), якщо ні, то знайти інше рішення.

Крок 15. Драйвери (drivers)

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

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

Бережлива канва

Yaroslav Zhmykhov — Mon, 03 Oct 2022 07:33:07 +0000

ЕТАП 1: БІЗНЕС-ДОСЛІДЖЕННЯ

Дуже потужний та іноваційний інструмент для опису та обговорення бізнес-моделі стартапу чи нового продукту.

Бережливий підхід (lean) — це філософія бережливого мислення, тобто свого роду підхід, котрий дозволяє економити ресурси та отримувати більш якісний та ефективний результат.

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

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

Бережливий підхід не є якоюсь методологією, він не містить ряд готових рішень, правил тощо, але є частиною філософії Agile, де відіграє важливу роль.

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

Методологія — це список певних принципів та прийомів. Якщо команда буде йти цим шляхом, то їй буде важко звернути не туди.

Такими методологіями можуть бути:

Agile. Інтерактивний підхід до керування проєктами та розробкою програмного забезпечення. Такий підхід дозволяє команді розробників пришвидшити доставку цінності до користувачів шляхом того, що замість розробки цілого продукту, команда розробників виконує роботу маленькими порціями, тобто спрінтами (sprints). Таким чином, користувач отримує цінність (наприклад, якесь оновлення) регулярно, а не один раз в рік;
Scrum. Методика, котра допомагає команді розробників вести спільну роботу. Команда проводить різні зібрання, використовує вузькоспеціалізовані інструменти тощо. Кожен учасник команди відіграє певну роль, щоб організувати роботу правильно та ефективно керувати нею;

Важливо: рекомендую прочитати книжку «Scrum: The Art of Doing Twice the Work in Half the Time» by Jeffrey Victor Sutherland.

Kanban. Підхід до реалізації принципів Agile. Всі задачі візуально представлені на Kanban дошці, яка може складатися з наступних колонок: Stories > To do > In progress > Testing > Done.

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

Бережлива канва (lean canvas) — це канва бізнес-моделі (business model canvas), котра є просто адаптована для стартапів.

Бережлива канва — це в першу чергу набір гіпотез, які потребують валідації, а не лише бізнес-план або план дій.

Ash Maurya є автором бережлививої канви бізнес-моделі. Він замітив, що канва бізнес-моделі (business model canvas) не повністю зосереджена на головній причині провалу усіх стартапів — це не розуміння проблем та потреб цільової аудиторії (ЦА) продукту.

Тому, він адаптував вже існуючу на той момент BMC для стартапів. У своїй канві, він застосував принципи підходу бережливого стартапу (lean startup).

Важливо: рекомендую прочитати книжку «The Lean Startup» by Eric Ries.

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

Приклад:

Ви сконцентрувалися на певній проблемі користувачів;
Сформулювали продуктові гіпотези;
Запропонували користувачам рішення (інтерактивний прототип);
Отримали швидкий зворотній зв’язок;
Проаналізували фідбек та зрозуміли, куди рухатися далі (поетапно вдосконалюєте продукт).

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

Ціль бережливої канви

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

Цінність для команди

Допоможе команді зрозуміти продукт з усіх боків. Отримані гіпотези, ми зможемо використовувати на наступних етапах.

Цінність для бізнесу

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

Також, цей інструмент дасть відповідь на головне питання: чому ваш стартап чи продукт швидше за все провалиться? Канва містить всі ваші гіпотези котрі пов’язані з вашим продуктом, і дозволить вам визначити найризикованіші із них.

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

Тривалість:

Підготовка: до 30 хвилин
Діяльність: від 4 до 8 годин

Процес створення:

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

Більш детальніше про схожі блоки (вони є такими самими, як і в цій канві) ви можете прочитати в попередній моїй статті «Канва бізнес-моделі».

Крок 1. Проблема (problem)

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

Також, вкажіть чи існують альтернативні рішення (existing alternatives) проблем.

Вимоги до проблем:

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

Крок 2. Сегмент клієнтів (customer segments)

Вкажіть клієнтів у яких є проблема (проблеми) з 1-шо блоку.

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

В цьому ж блоці, ви можете вказати ранніх прихильників (early adopters). Це ті клієнти, для яких проблеми, котрі описані в 1-му блоці, є найбільш важливими. Тобто, це ті люди, котрі з радістю погодяться стати першими вашими клієнтами.

Крок 3. Унікальна ціннісна пропозиція (unique value proposition)

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

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

Високо рівнева концепція (high-level concept) — це по суті те, з чим ви себе асоціюєте. Вам необхідно чітко визначитися, з питанням: хто ви є такі? Наприклад, скажімо, ви фестиваль, але який саме фестиваль?

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

Крок 4. Рішення (solution)

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

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

Крок 5. Канали (channels)

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

Крок 6. Потоки доходів (revenue streams)

Вам необхідно зрозуміти, як бізнес буде генерувати дохід. Тобто, які є основні джерела доходів.

Вам чітко необхідно розуміти:

Хто буде платити за ваш продукт?
За що саме клієнти будуть платити?
Скільки це буде коштувати?
Як довго клієнти будуть платити?

Крок 7. Структура витрат (cost structure)

У цьому блоці вам необхідно вказали лише основні витрати на забезпечення роботи вашого продукту (наприклад, заробітна плата працівників, оренда приміщення, маркетингові та рекламні витрати, комп’ютери та програмне забезпечення тощо.

Це не фінансовий звіт. Не потрібно вписувати абсолютно всі витрати.

Крок 8. Ключові метрики (key metrics)

Вам необхідно вказати метрики, котрі повинні відповідати на наступні питання:

Чи рухається продукт до своїх цілей?
І якщо не рухається, то чому? Що не так?

Іншими словами, вкажіть основні показники успіху.

Крок 9. Нечесна перевага (unfair advantage)

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

Вам необхідно подумати над тим, що необхідно зробити, щоб завадити конкурентам скопіювати вашу ціннісну пропозицію хоча б на квартал?

Наприклад, ви використовуєте:

Іноваційні технології;
Унікальну інтелектуальну власність;
Ваша компанія має унікальні бізнес-контракти;
Ви маєте певні ліцензії або патенти тощо.

Шлях ітерації ризику (risk iteration path)

Ash Maurya розділяє в якому саме порядку необхідно заповнювати бережливу канву, і який є порядок перевірки гіпотез. Це дуже важливо.

Послідовність перевірки гіпотез щодо зняття ризиків бізнес-моделі — це і є шлях ітерації ризику (risk iteration path).

Автор виділив 3-ри типи ризиків:

Продуктовий ризик (product risk);
Клієнтський ризик (customer risk);
Ринковий ризик (market risk).

Важливо: всі 3-ри типи ризиків перевіряються одночасно!

Що це означає:

Проблема (problem) + сегмент клієнтів (customer segments) + альтернативні рішення (existing alternatives). Ми перевіряємо, чи є у сегмента клієнтів є проблеми, і як вони їх вирішують;
Рішення (solution) + ранні прихильники (early adopters) + готовність до покупки (revenue streams). Мається на увазі, чи ранні користувачі є готові придбати ваш продукт по необхідній вам ціні;

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

Унікальна ціннісна пропозиція (unique value proposition) + канали для залучення клієнтів (channels) + ціна продукту (revenue streams). Важливий крок. Вам необхідно провірити чи ціннісна пропозиція, яку надає ваш продукт буде залучати клієнтів з обраних вами каналів (наприклад, за допомогою реклами в соціальних мережах);
Ключові метрики (key metrics) + вхідні канали залучення клієнтів (channels) + структура витрат (cost structure). Мається на увазі, що вам необхідно провірити спроможність вашого продукту та обраної вами бізнес-моделі розвиватися на довгостроковий період.

Під словами «вхідні канали залучення клієнтів» мається на увазі, що ринок на який ви орієнтуєтеся буде знати та шукати ваше унікальне рішення. Наприклад, щоб забезпечити приплив клієнтів, вам необхідно, щоб сайт вашого продукту добре індексувався пошуковими системи (search engine optimization, SEO). Також, не забувайте про маркетинг у соціальних мережах (social media marketing, SMM).

Канва ціннісної пропозиції

Yaroslav Zhmykhov — Wed, 07 Sep 2022 20:22:25 +0000

ЕТАП 2: ДОСЛІДЖЕННЯ КОРИСТУВАЧІВ

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

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

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

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

Для початку я б хотів відійти трішки від основної теми та розповісти вам про 4-ри основні канви, котрі ви будете зустрічати під час роботи:

Канва бізнес-моделі (business model canvas) розроблена для перевірки життєздатності бізнес-ідеї (в основному для офлайн-компаній).

Важливо: цей інструмент існує для опису бізнес-моделі.

Бережлива канва (lean canvas) — це канва бізнес-моделі (business model canvas), але яка є адаптована на стартапи, котрі знаходяться на ранньому етапі розвитку.
Канва бережливого користувацького досвіду (lean UX canvas) розроблена для перевірки життєздатності продукту, послуги або функції, щоб допомогти підвищити цінність бізнесу.

Іншими словами, канва бережливого користувацького досвіду допоможе команді сформулювати бізнес-проблеми, котрі необхідно вирішити. Потім, ми перетворимо наші припущення на гіпотези та проведемо необхідні UX дослідження для перевірки самих життєздатних гіпотез.

Важливо: робота, котру ви виконаєте за допомогою канви бізнес-моделі, задасть контекст для обговорення, яке ви будете розвивати в рамках канви бережливого користувацького досвіду (lean UX canvas).

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

Важливо: це є виключно інструмент опису, а не створення цінності.

Внизу ви бачите стандартний дизайн-процес. Так-от, десь там і є ваші ціннісні пропозиції, котрі ви повинні знайти. Це є ваше випробування.

З розробленої раніше канви бізнес-моделі, ми візьмемо лише 2-ва необхідних блоки: ціннісну пропозицію та сегмент клієнтів.

Канва бізнес-моделі, яка поєднує основні елементи бізнес-стратегії в одній сторінці.

Канва ціннісної пропозиції, котра складається з 6-ти блоків, котрі є розбиті на 2-ві частини.

Приклад канви, яка є в книжці «Value Proposition Design: How to Create Products and Services Customers Want» by Alexander Osterwalder, Yves Pigneur, Alan Smith, Gregory Bernarda.

Ціль канви ціннісної пропозиції

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

Цінність для команди

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

Окрім всього вище сказаного, канва ціннісної пропозиції допоможе створити POVs, котрі ми перетворимо в питання «Як ми можемо …?» (HMW).

Також, непотрібно забувати за створення шаблону з прогалинами (ad-libs), щоб розгорнути вашу ціннісну пропозицію.

Цінність для бізнесу

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

Тривалість:

Підготовка: до 30 хвилин
Діяльність: від 2 до 8 годин на 1-ну канву ціннісної пропозиції та від 4 до 6 години на додаткові активності

Процес створення:

Канва ціннісної пропозиції (value proposition canvas) містить 2-ва блоки:

Карта цінності або карта ціннісної пропозиції (value proposition) структуровано та детально описує особливості конкретної пропозиції.

Цінність (сервіси та послуги, фічі, унікальні характеристики продукту) = вигода та користь для користувача.

Клієнтський профіль (customer segment) структуровано та детально описує певний сегмент користувачів або персону. Цей блок описує: користь (котру клієнт хоче досягти), клієнтські завдання (це все те, що клієнти намагаються досягти у своїй роботі та в житті) та болі (це бар’єри, котрі заважають досягти бажане).

Крок 1. Оберіть необхідний вам клієнтський сегмент або персону

Для початку вам потрібно вирішити, для кого ви будете розробляти або покращувати ціннісну пропозицію. Це може бути:

Клієнтський сегмент (customer segment) — це певна група людей, яких об’єднує спільна проблема чи потреба.

Більш детальніше про клієнтський сегмент, ви можете прочитати в попередній моїй статті «Канва бізнес-моделі».

Персона (persona) — це образ користувачів, який містить: їх мотиви, цілі, проблеми та поведінку.

Більш детальніше про персону, ви можете прочитати в попередній моїй статті «Користувацькі персони».

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

Крок 2. Клієнтський профіль: клієнтські завдання (customer jobs)

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

Завдання, котрі люди намагаються виконати та реалізувати.
Проблеми, які люди намагаються розв’язати;
Потреби, котрі люди намагаються задовольнити.

Давайте поговоримо детальніше про типи завдань:

Функціональні завдання. Це завдання чи розв’язок конкретної проблеми. Завдання можуть бути як особистими, так і професійними. Наприклад, покосити газон чи зробити річний звіт витрат компанії;
Соціальні завдання. Такі завдання пов’язані з формуванням бажаного іміджу в суспільстві. Наприклад, мати гарний зовнішній вигляд або займати високі посади на робочих місцях;
Особисті чи емоційні завдання. Це отримання певних емоцій. Наприклад, душевний спокій або відчуття безпеки у своєму будинку;
Допоміжні завдання. Це завдання, котрі допомагають клієнту досягати його мети.

Іншими словами, Jobs — це потреби вашого клієнта.

Важливо. Розставте пріоритети: від важливих до неважливих клієнтських завдань.

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

Крок 3. Клієнтський профіль: болі або проблеми клієнтів (pains)

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

Важливо. Розставте пріоритети: від нестерпного до помірного клієнтського болю.

Крок 4. Клієнтський профіль: переваги (вигоди) для клієнта (gains)

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

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

Які бувають переваги (вигоди):

Потрібна користь. Це вигода, без якої ваше рішення не буде працювати. Наприклад, людина, яка купує власний автомобіль, повинна мати водійські права;
Очікувані вигоди. Якщо коротко, то ваш клієнт очікує отримати ще щось окрім основної користі, але в принципі вони можуть і без цього обійтися. Наприклад, ви купуєте новенький BMW X5 xDrive45e (електропривід), і очікуєте, що цей автомобіль буде безпечним для всіх пасажирів, тому що, цей автомобіль отримав максимальні 5-ть балів у тестах Euro NCAP (європейська програма оцінки безпеки автомобілів);
Бажана користь. Це користь, що виходить за рамки очікуваного від нашого рішення, але якщо є можливість, то ми можемо додати її. Наприклад, замінити колір салону автомобіля;
Неочікувані вигоди. Це переваги (вигоди) вашого продукту чи послуги, що виходять за межі бажань та очікувань клієнта. Наприклад, після покупи автомобіля, офіційний дилер BWM в України подарує зимовий комплект коліс.

Важливо. Розставте пріоритети: від суттєвої користі до «добре було б мати».

Крок 5. Питання «Як ми можемо …?»

Після того, як ми створили клієнтський профіль, ми можемо почати формулювати POV (point of view) для створення рішення.

Пошук відповідей на питання «Як ми можемо …?» приведе вас до створення продукту, який буде містити цінність.

Більш детальніше про питання «Як ми можемо …?», ви можете прочитати в попередній моїй статті «Точка зору (POV) — Постановка проблеми та питання «Як ми можемо …?».

Приклад:

Як ми можемо допомогти [таксистам], які хочуть [підтримувати салон автомобіля в чистоті], тому що зараз його [необхідно прибирати] кожні 2 дні, щоб [клієнти були задоволені сервісом] та залишали хороші рейтинги?

Крок 6. Карта цінності: продукти й послуги (products & services)

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

Продукти й послуги можуть бути:

Матеріальні. Це вироблена продукція та послуги. Наприклад, мобільний додаток для дистанційного керування автомобілем;
Нематеріальна цінність. Це авторські права та ліцензії;
Цифрові чи віртуальні. Наприклад, завантажені фільми, музика чи книжки з Інтернету;
Фінансові. Лізинг, страхування, кредитування або різні інвестиції.

Важливо. Розставте пріоритети: від суттєвої актуальності до «добре було б мати».

Крок 7. Карта цінності: знеболювальні (pain relievers)

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

Важливо. Розставте пріоритети: від суттєвої доречності до «добре було б мати».

Крок 8. Карта цінності: створення переваг (gain creators)

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

Важливо. Розставте пріоритети: від суттєвої доречності до «добре було б мати».

Крок 9. Відповідність (fit)

Відповідність досягається тоді, коли ваша карта ціннісної пропозиції = клієнтському профілю.

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

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

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

Відповідності відбувається коли ви:

Ви розумієте завдання клієнта > вгамовуєте його нестерпний біль > створюєте суттєві переваги.

Більш детальніше про цілі, ви можете прочитати в попередній моїй статті «Бізнес-цілі та цілі користувачів».

Крок 10. Використовуйте шаблон з прогалинами (ad-libs), щоб розгорнути вашу ціннісну пропозицію

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

Цей шаблон — свого роду продовження POV, але вже із рішенням.

Приклад:

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

Що далі? Наприклад, можна піти ось таким шляхом:

VPC (на кожен із сегментів) > User story + Acceptance criteria > Story mapping (для пріорітизації) > Information architecture + User flows > UI > Testing

Бізнес-цілі та цілі користувачів

Yaroslav Zhmykhov — Mon, 22 Aug 2022 13:29:48 +0000

Етап 3: Аналіз

Надзвичайно важливий аналітичний етап. Шанси створити потрібний та життєздатний продукт на ринку є незначними без розуміння бізнес-цілей та цілей користувачів.

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

Дизайн (перекладається, як «проєктування») — це більше про те, як воно працює та є проєктовано, ніж те, як воно виглядає.

Design is not just what it looks like and feels like. Design is how it works. — Steve Jobs

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

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

Єдина умова — це правильне, професійне та обдумане застосування тих чи інших методів дослідження.

Дослідження — це обов’язковий процес, не пропускайте його. Якщо ваше рішення не базується на дослідженні користувачів, тоді воно не може називатися USER experience.

Аналогія

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

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

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

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

Підхід, який є орієнтований на користувача

Емпатія — це неймовірний інструмент в руках дизайнерів, але чому тоді нас називаються «Адвокатами користувачів»? Відповідь є досить проста — ми докладаємо усіх зусиль для задоволення користувачі, але забуваємо за бізнес-цілі та ставимо їх на задній план. Це є погано.

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

Підхід, який є орієнтований на бізнес

Про цю сторону медалі, давайте поговоримо детальніше. Я часто чую від клієнтів, що Senior UX designer — це професіонал, який знає і може абсолютно все, навіть спроєктувати якісний продукт без будь-яких досліджень, опираючись лише на власний досвід та суб’єктивну думку стейкхолдерів.

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

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

Ви, ваша команда та стейкхолдери ≠ вашим користувачам.

Ідеальна середина

Саме цю концепцію ми й будемо розглядати в цій статті. Якщо коротко, то нам необхідно дотримуватися балансу між бізнес-цілями та цілями користувачів.

Для запису даних скористаємося діаграмою Венна (англ. Venn diagram), що показує всі можливі логічні відношення.

Проста діаграма Венна. Зліва та справа — відмінності, а посередині — спільні цілі

Складна діаграма Венна. Зліва та справа — відмінності, внизу — технічні потреби, посередині — спільні цілі, а 1,2, 3 — це додаткові дані, які перетинаються

Цінність для команди

Проведення цього етапу дасть змогу підсумувати цілі, порівняти їх та зробити певні висновки. Можливо, доповнити бізнес-стратегію чи кардинально змінити її, якщо буде виявлено, що продукт не буде покривати основні цілі користувачів.

Цінність для бізнесу

Це ще один додатковий шанс зрозуміти, чи ваш продукт рухається в правильному напрямку.

Тривалість:

Підготовка: до 30 хвилин
Діяльність: від 2 до 4 годин

Процес створення:

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

Крок 1. Намалюйте необхідний вид діаграми Венна на аркуші фліпчарту, ватмані або оберіть електронний варіант

Крок 2. Обговоріть з командою та вирішіть з якого із 3-х областей ви будете починати

Крок 3. Описуємо бізнес-цілі (business goals)

Під час стартової зустріч та інтерв’ю з зацікавленими сторонами, ви повинні були зрозуміти:

Суть компанії та її місію;
Цілі, які перед вами ставить бізнес;
Який продукт чи послугу надаватиме цей бізнес?
Яку цінність буде мати для користувачів?
Що це за ринок та які конкуренти є на ньому?
Які існують обмеження?
Як бізнес буде заробляти гроші?
Інші інсайти.

Всю цю отриману інформацію необхідно перенести в розділ з бізнес-цілями.

Крок 4. Описуємо цілі користувачів (user goals)

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

Отже, ваше дослідження повинно було містити:

Воркшоп, де команда та стейкхолдери повинні були зрозуміти, хто є імовірна цільова аудиторія;

Результат: ви повинні були скласти прото-персону.

На основі прото-персони, необхідно було знайшли респондентів (в цьому вам міг допомогти опитувальник) та провели інтерв’ю з ними;

Результат: ви повинні були скласти довільний звіт для команди та стейкхолдерів.

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

Результат: ви повинні були проаналізувати дані та скласти довільний звіт для команди та стейкхолдерів.

Для кожного з респондентів ви склали карту емпатії;

Результат: ви повинні були проаналізувати користувацькі інтерв'ю та розмістити якісні дані на карту, яка складається з 9-ти блоків, а також виявити інсайти та перетворити їх в потреби.

На основі попередніх даних, ви виявили емпіричні персони.

Результат: саме з розділу «Goals» вам необхідно перенести цілі в нашу діаграму.

Крок 5. Описуємо технічні потреби (technical needs)

Мається на увазі, всі аспекти, які необхідні для того, що реалізувати ваш продукт.

Також в Інтернеті можна побачити, що цей блок може мати інші назви й, можливо, навіть значення:

Технічні міркування/аспекти (technical considerations);
Технічні обмеження (technical constraints);
Технології (technology);
Розробка (development);
Технічна можливість (technical feasibility).

Крок 6. Розділи 1,2 та 3

Це додаткові дані, які перетинаються.

Крок 7. Описуємо спільні цілі (Shared goals/Sweet spot)

Необхідно визначити, що є спільного між розділами. Це головна цінність цього етапу.

Рекомендую прочитати книжку «Sweet Spot UX: Communicating User Experience to Stakeholders, Decision Makers and Other Humans» by Mike Newman.

Точка зору (POV) — Постановка проблеми та питання «Як ми можемо …?»

Yaroslav Zhmykhov — Sat, 20 Aug 2022 14:41:19 +0000

Етап 2: Дослідження користувачів

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

Постановка проблеми (POV) — це короткий опис проблеми (або потреби), яку необхідно вирішити.

Питання «Як ми можемо …?» (HMW) — це короткі питання, які запускають процес генерації ідей та рішень.

Ціль постановки проблеми

Визначити та сформулювати проблеми, які ви будете вирішувати. Проблеми мають бути зосереджені виключно на цільовій аудиторії (users), їхніх потребах (needs) та ваших інсайтах (insights).

Ціль питань «Як ми можемо …?»

Допоможе розпочати генерувати інноваційні ідеї.

Цінність для команди

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

Цінність для бізнесу

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

Тривалість:

Підготовка: до 30 хвилин
Діяльність: від 8 до 16 годин

Процес створення:

Крок 1. Відкрити всі артефакти з попередніх досліджень

Освіжіть ваші спогади, та попросіть зробити це ж саме всю команду.

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

Крок 2. Поверніться до ваших карт емпатій, котрі ви робили

В них, ми шукали інсайти (insights), а вже на основі них виявили потреби (needs).

Приклад:

[Insight] Користувачі часто самі шукають способи оцінки своєї результативності у вивченні іноземної мови, оскільки викладачі не завжди звертають на це увагу, а іноді навіть пропускають такі розмови, а це дуже впливає на їхню мотивацію.

[Need] Користувачі повинні мати можливість отримувати звіти про роботу на уроці іноземної мови, а також успіхи за певний проміжок часу.

Крок 3. Запишіть ваші POVs за формулою

[User . . . (descriptive)] needs [Need . . . (verb)] because [Insight . . . (compelling)]

[User] — це наша емпірична персона (не прото-персона).

Приклад:

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

Крок 4. Переформулюйте POV задачу в HMW питання

Таким чином, ви підготуєте HMW питання, які допоможуть вам знайти інноваційні рішення на стадії «Ideation». Ви зможете використовувати різні техніки разом з вашою командою: Six thinking hats, Brainstorming або The Walt Disney Creativity strategy.

Приклад HMW питання:

[Як ми можемо] допомогти [користувачу] отримати відгук про його роботу на уроці та успіхи за певний проміжок часу?

Користувацькі персони

Yaroslav Zhmykhov — Thu, 18 Aug 2022 09:12:53 +0000

Етап 2: Дослідження користувачів

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

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

Містер Alan Cooper припустив, що підвищення емпатії до вашого користувача під час проєктування взаємодії — позитивно вплине на результат. Наприклад, Mac mini/Macbook Air підійде для користувачів з легкими задачами, iMac/Macbook Pro для кріейторів, Mac Studio/Mac Pro для дуже потужних задач тощо.

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

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

Існує 3 типи персон:

Marketing personas. Не підходить для UX дизайну, оскільки вони описують не поведінку, цілі та мотиви, а демографічні ознаки покупця (customer) продукту;
Proto-persona (non-empirical persona). Це той тип персони, з якого ми починаємо наше дослідження. Якщо казати коротко, то це образ майбутнього користувача, що базується тільки на припущеннях команди та не підтверджений результатами дослідження.

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

Persona (Empirical persona). Це саме той тип персони, який нам і необхідний. Тобто, це образ цільової аудиторії, який має спільну поведінку, цілі та мотиви, і є результатом виконаних досліджень.

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

Також, ви повинні розуміти відмінність ролі від користувацької персони:

Роль. Основана на доступах та необхідній функціональності. Іншими словами, це група користувачів у системі, яка об’днана певним набором прав доступа;
Персона. Будується на основі мотивів, цілей та проблем.

Для прикладу, давайте розглянемо сервіс Preply (зручний сервіс для вивчення мов).

На мою думку, сервіс містить наступні ролі: супер адміністратор, адміністратор, служба підтримки, викладач та студент.

За основу візьмемо роль студента. Гіпотетично, в результаті користувацького інтерв'ю, вони б могли виявити 4-ри наступні персони:

Студент, котрий не володіє англійською мовою, але хоче вивчити її з самого початку до хорошого розмовного рівня;
Студент, котрий вже вивчав англійську мову, має базові знання та хоче розвиватися далі;
Студент, котрий дуже добре володіє мовою на рівні B2, і хоче розвивати бізнес-мову для професійних цілей;
Студент, котрий володіє мовою на рівні С1/C2, але хоче позбутися акценту.

Кожен із цих персон є об’єднаний схожою поведінкою, цілями, мотивацією, потребами та проблемами.

Список деяких визначень, котрі ви повинні розуміти, оскільки вони дуже часто використовуються:

Персона (persona) та архетип (archetype). Функціонально вони є ідентичні, оскільки містять одні й ті ж самі дані та відомості про: поведінку, відношення, цілі та больові точки користувачів. Різниця між ними полягає в тому, що персона (persona) має фото, імʼя та біографію, а архетип користувача (user archetype) не є прив’язаний до конкретних імен чи осіб;

Клієнт (client) — це той, хто платить спеціалісту, компанії або організації за послуги чи поради (консультації). Особливістю клієнта є довгострокові тісні професійні відносини та персоналізація (long-standing closer professional relationships and personalization), а це значить, що з клієнтами можна співпрацювати роками, мати особливі відносини та індивідуальний підхід до вирішення їх проблем;

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

Покупець (customer) — це особа, яка відвідує фізичний магазин або онлайн-магазин з метою щось купити. Часто це є одноразовий продаж (one-time sale) чогось без побудови довгострокових відносин. Це просто бізнес, а саме обмін грошей на товар, послугу тощо;
Споживач (consumer) — це той, хто купив або безпосередньо буде користуватися вашим товаром чи послугою. Не обов’язково, щоб товар чи послугу купив сам споживач, це могли зробити за нього, а він лише буде користуватися. Наприклад, компанія купляє якийсь тарифний план сервісу InVision за $4 в місяць для дизайн-команди. В цьому випадку, компанія буде в ролі покупця (customer), а дизайн-команда в ролі споживача (consumer);

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

Client, customer та consumer терміни є описані в Кембриджському словнику.

Користувач (user) — це особа, котра взаємодіє з системою, продуктом або послугою.

Термін є описаний в ISO 9241–11.

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

Наприклад, користувачі пляжу скаржаться на те, що пляж є дуже брудний.

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

Ціль користувацької персони

Цей метод допоможе зрозуміти: цілі, бажання, потреби, страхи, почути історію та побачити релевантний досвід користувача.

Цінність для команди

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

Цінність для бізнесу

Окрім всього вищесказаного, розуміння користувачів значно зменшить ризики розробити невірний продукт чи сервіс.

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

Тривалість:

Підготовка: до 30 хвилин
Діяльність: від 2 до 5 годин на одну емпіричну персону

Процес створення:

Якщо ви вже зробили «Карту емпатії», тоді ви можете перенести існуючу інформацію в користувацьку персону, але я рекомендую повторно подумати з командою над усіма блоками, можливо ви зможете доповнити персону чимось новим.

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

Крок 1. Демографічні дані (demographics)

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

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

Крок 2. Історія

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

Мій арт-директор казав мені багато раз, що «Диявол криється в деталях».

Крок 3. Користувацькі цілі (user goals) та задачі (tasks)

Спочатку, додайте цілі респондентів, яких ви інтерв’ювали. Містер Alan Cooper поділяв їх на 3-ри види:

Мотив (motive) — це «experience goals». В криміналістиці теж використовують цей термін, і він дозволяє визначити, чому особа вчиняє злочин. Переважно, мотив є один, але дуже глобальний. Наприклад, жага до професійного саморозвитку;

Мотив — це сама сильна внутрішня рушійна сила, котра спонукає людину до дії. Тобто, це гігантський мотиватор.

Цілі (goals) — це «life goals». Цілі випливають із мотиву. Задайте собі питання: «Навіщо користувачу використовувати ваш продукт чи сервіс?». Уважно проаналізуйте відповіді респондента, і я є впевнений, що ви знайдете, як мінімум, 3–5 цілей;

Це означає, що якщо мотивом користувача є прагнення до професійного саморозвитку, тоді цілі будуть такими: мати високу заробітну плату, купити будинок для своєї сімʼї, харчуватися кращими продуктами, користуватися брендовою технікою, відпочивати з сім’єю за кордоном 2-ва рази в рік тощо.

Задачі (tasks) — це «end goals». Задачі випливають із цілей. Якщо казати коротко, то це конкретні завдання, які необхідно зробити користувачу, щоб виконати цілі. Тобто, 1-на ціль = кілька завдань. Для того, щоб знайти завдання задайте собі питання: «Як користувач може добитися своїх цілей?».

Це означає, що якщо ціль користувача — це мати високу заробітну плату, тоді завдання будуть такими: знайти в Інтернеті список всіх необхідних методологій, провірити їх якість та ефективність, посортувати за пріоритетом та вивчити.

Крок 4. Потреби, бажання та страхи

Потреби (needs). Це є бізнес-аспекти, який допомагає користувачу досягти цілей. Я їх переношу з «Карти емпатії», після того, як ми виявили інсайти та перетворили їх в потреби;

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

Бажання (wants) — зовнішнє середовище. Деколи, цей блок називають мотиватори (motivations) або драйвери (drivers). Тобто, це все те, що зробить досягнення цілей користувача більш приємними або підштовхне зробити перший чи наступні кроки;

Наприклад, наш користувач бажає отримувати все необхідне з одного достовірного ресурсу, в логічній послідовності та «без води».

Страхи (fears). Деколи, цей блок називають ризики (risks) або розчарування (frustrations). Якщо казати коротко, то це сильне побоювання або саме найгірше, що може статися з користувачем.

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

Крок 5. Очікування (expectations)

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

Ментальна модель (mental model) — це особистий суб’єктивний попередній досвід, який відображає лише особисте відношення до об’єктів та процесів, і може не відповідати дійсності. Також, ментальна модель 1-ї людини може відрізнятися від інших людей.

Нам потрібно перетворити ментальну модель в сюжет (storyframe).

Чому так важливо виявити ментальні моделі ваших респондентів? Бо в кінцевому результаті, у нас буде 2-ва варіанта розвитку подій:

Бавитися з командою в гру «Битва екстрасенсів», де ви будете думати самостійно над питанням: «А що зробив би Ярослав?»;
Або, задати респондентам декілька питань про те, як вони представляють собі взаємодію з майбутнім продуктом чи сервісом.

Отже, що необхідно зробити?

Оберіть головну ціль з секції «User goals»;
Обрана вами ціль повинна містити ряд задач;
Описуємо все крок за кроком.

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

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

Для розробки персон можна використати один із наступних інструментів: Google Docs, Xtensio, Userforge, UXPressia або Miro.