UXPUB 🇺🇦 Дизайн-спільнота: Євген Олексюк

UX Slogans by NNGroup

Євген Олексюк — Sat, 06 Jun 2026 13:44:11 +0000

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

А ще хочу акцентувати вашу увагу на тому, що стаття написана НЕ за допомогою ШІ, а пальчиками. Можливо стаття вийде не настільки стерильно-бездоганно, але як говорить нам японська філософія Вабі-Сабі «Ідеальність в неідеальності». Звісно, це трошки олдово, але якось чесно, адже ви це читаєте вашими аналоговими очима, тому я пишу це своїми аналоговими пальцями!

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

А ще я люблю розповідати байку про одну компанію, яка в welcome package дизайнера клала футболку з написом ТИ НЕ Є ВАЛІДНИМ! То є нагадування що думки ані дизайнера, ані стейкхолдера, ані будь-кого з проєктної тіми не мають критичної ваги. І звісно ж, цей напис не є оригінальним — це є лише варіація одного з слоганів Nielsen Norman Group.

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

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

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

UX Slogan #1: You ≠ User

Ти Не Є Користувач

Вперше цей слоган був сформульований в 1993 році в книжці Якоба Нільсена «Usability Engineering». Тут все кристально зрозуміло, але часом важко донести це до команди, адже всі вважають себе Mr.KnowItAll. Очевидно, всі члени вашої тіми матимуть свої погляди на те «ЩО і ЯК краще для користувача», але всі ці погляди засновані суто на досвіді та спотвореннях кожного конкретного члена команди, на їх бажаннях і візіях.

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

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

Дизайнери (а також Проджект Менеджер, Продукт Менеджер, Бізнес Аналітик, Делівері Менеджер і тд) це взагалі максимально спотворені ролі і їх слухати категорично заборонено.

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

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

По-третє ці ролі тісно пов’язані з ВСІЄЮ командою і тому можуть безпосередньо впливати на продуктові гіпотези, інтерфейсні рішення, їх імплементацію, тощо. Це іноді створює додаткові ризики менеджерської тиранії та нав’язування.

Тому думка користувача найважливіша! Хорошим рішенням є тримати у вільному доступі головні артефакти проєкту (опис юзер персони, CJM, перелік проблем користувача, можливо якісь канваси проєкта) — наприклад в мітінг румі або опенспейсі розвісити роздруковані артефакти і стікери на стіні, щоб в будь-який момент обговорення чи грумінгу можна було остудити голову тіммейта словами «Давай не забувати що ми не користувачі і просто глянемо, хто ж наша цільова»😉

youtube.com

UX Slogan #2: Keep it Simple

Зберігай Простоту

Думаю всі ми знаємо абревіатуру KISS як Keep It Simple Stupid. По суті цей слоган нам говорить те саме — необхідно спрощувати все максимально. Ми вже говорили про таке поняття як «когнітивне навантаження» коли розбирались з Законами Хіка та Міллера в статті Laws of UX та на UX Break: Закони UX — теорія та практика.

В слогані #2 говориться звісно ж про перегружений інтерфейс і про те, наскільки легко або важко ним користуватись юзеру. Одразу згадуємо момент, коли ви вперше зайшли в Photoshop і нажахались всіх його фіч/функцій/можливостей. На початку своєї карєри, я працював в ФШ і це було пекло, адже весь функціонал не знав ніхто, половина функцій була взагалі не потрібна, а друга половина потрібна, але захована невідомо де. Перший макет я малював з відчуттям, ніби мене кинули в кабіну літака і сказали «нам треба летіти, натискай що завгодно, але ми МАЄМО летіти».

Але слоган нам говорить не суто про доступну реалізацію необхідного функціоналу, а й про необхідність надання юзеру певного конкретного функціоналу. Всі хто працював з дизайн-процесом (Design Thinking, Double Diamond, та інші дизайн-процеси), знає, що процес передбачає так звану сцепку «утилітарність + юзабіліті». Тобто коли ми говоримо про простоту, то охоплюємо також і момент утилітарності. Щоб продукт був потрібний юзеру, ми повинні дати йому саме те, за чим прийшов користувач і настільки зручно, наскільки це можливо.

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

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

Ну і в якості пруфів зрозумілості простого інтерфейсу — гляньте так звані one_button сайти — наприклад one-button.vercel. Або згадайте як виглядає домашня пошукова сторінка від Google. Ці сторінки прості як двері і в них важко заплутатись. 😆

UX Slogan #3: You Can’t Impose Joy

Ти Не Можеш Нав’язати Радість

Слоган #3 нам говорить про те, що не потрібно примушувати користувача кайфувати від вашого дизайну. Тут все досить просто — будь-який продукт закриває біль користувача. Тобто людина приходить на продукт з метою зробити ЩОСЬ ВАЖЛИВЕ, що її бентежить. І коли сайт (чи застосунок) починає гратись з юзером різними юайними приколясами (сплешскрінами, оверанімованим інтерфесами, тощо) то ці прікольчікі, скоріш за все, викличуть не посмішку, а роздратування користувача.

Знову ж так, давайте не забувати, що ЦА треба досліджувати і знати для чого юзер прийшов. Звісно, існують платформи-таймкіллери по типу crazygames.com, де можна просто погратись. Але коли ми говоримо про сайт, на якому юзер робить цільову дію, то підхід буде сильно відрізнятись. В цьому випадку оверюай може відволікати і напрягати. Наприклад bambukstudio.com — виглядає круто, показує як студія вміє вражати і робити креативні сайти, але багато елементів інтерфейсу відволікають і швидше заважають цільовій дії (мене особисто карпка-курсор почала напрягати десь через хвилину).

UX Slogan #4: Communication not Decoration

Комунікація, а Не Декорація

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

Коли дизайнер створює продукт, то в ньому всередині відбувається боротьба між креативщиком та юіксером-монетизувальником. Внутрішній креативщик шепоче «А давай зараз зробимо щось дуже дивне і космічне, візьмемо Red Dot, в портфоліо поставимо, буде про що в пабі друзям розповісти», а внутрішній юіксер починає кричати «Нє, так не буде — ми робимо зрозуміло, потім тестуємо, потім міряємо KPI і збільшуємо монетизацію». Зазвичай така боротьба відбувається більше в джунів-мідлів, якщо вони ще не награлись в «тягання пікселів».

Мій особистий тейк полягає в тому, що важливо знайти баланс — щоб дизайн був не нудним і цікавим для юзерів продукту і самому дизайнеру в процесі роботи. Але НЕ БІЛЬШЕ! Ну бо креативність буде оплачувати ваш замовник, який зацікавлений в збільшенні прибутку.

Тому давайте робити не діджитальний музей красот, а шукати баланс.

Ну і в якості поганих прикладів ЯК РОБИТИ НЕ ТРЕБА ось вам:

zentry.com з їх дивними кнопками і тяжким сайтом;
spylt.com також з дивними кнопками і паралаксами;
мій фаворит mew.xyz — взагалі не зрозуміло з чим можлива взаємодія, а з чим ні (а за ховер-стейт кнопок взагалі окреме дякую).

UX Slogan #5: Brevity = Brilliance

Лаконічність = Геніальність

Уявимо собі ситуацію — ви слухаєте промову якогось дуже класного спікера. Топік вам цікавий, але спікер розповідає дуже «багато літер», використовує дивні метафори, тощо. Скоріш за все, ви загубитесь в його думках і не сприймете інформацію. В письмі є термін «графоманія» — це є антипод лаконічності і, якщо в художній літературі пишність фраз автора допустима, то в інтерфейсі це зайве. Всі ми чули, що юзер не читає, а сканує сторінку, тому якщо ви навалили на ній тексту, то його шанси бути прочитаним обернено-пропорційні величині масиву цього тексту. Тому давайте будемо скорочувати наші інтерфейси. Цей слоган працює як доповнення до слогана #2 (Зберігайте простоту).

Ось вам антиприклад — www.discountbedsbelfast.co.uk — забагато текста і, як наслідок, нічого не зрозуміло. А за менюшку взагалі їм окремий антилайк😂

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

UX Slogan #6: «Why» Beats «What» in UX

«ЧОМУ» Важливіше Ніж «ЩО» в UX

Загалом заруба між Human Centered Design (HCD), Data Driven Design (DDD) та Tech Driven Design (TDD) ведеться вже дуже давно. Якщо ми говоримо про ефективний з точки зору монетизації дизайн, то тек-дрівен можемо взагалі відкинути, адже ризик зробити НЕ ТЕ що треба енд-юзеру (який заплатить продукту) в ньому максимальний. Окремі ж суперечки точаться між любителями даних і аналітики і адептами HCD. Звісно, сила в поєднанні HCD та DDD (згадуємо нашу улюблену триангуляцію кількісними якісних), але головний тейк саме цього слогана, про який нам розповідає Якоб Нільсен, полягає в тому що «суха дата» не є така ж важлива, як розуміння ЧОМУ все відбувається як відбувається.

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

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

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

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

п.с. Суто моя думка з цього приводу: слоган цікавий, але трошки не вірний, адже віддавати перевагу ЧОМУ або ЩО так саме не правильно, як спитати в дитини, кого вона любить більше — маму чи тата. Для дійсно якісної та коректної роботи дизайнера (і всього продукту загалом) необхідно значи і ЧОМУ і ЩО! Обидва питання важливі і обирати або віддавати перевагу тут не є доцільним.

UX Slogan #7: UX is People

UX Це Люди

Перед тим як розповісти про сам слоган, дозвольте трошки духоти і історії 😉

Є така штука як Human-Computer Interaction (HCI) — це така мультидисциплінарна галузь, яка вивчає, як люди взаємодіють із комп’ютерними технологіями, та фокусується на проектуванні, оцінці та впровадженні інтерактивних систем, що є зручними та ефективними для користувача. Тобто якщо UX-дизайн — це практична частина створення продукту (не завжди, але в контексті UX, саме цифрового), то HCI — це саме теоретична частина, на якому базується UX. То є саме науковий фундамент.

Існує також поняття «золотого трикутника» HCI:

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

Загалом HCI з’явився майже 100 років тому — в 1940-х роках, але то був дуже примітивний рівень, адже то була ера «Людина як оператор», де з комп’ютерами взаємодіяли спеціально-навчані люди за допомогою перфокарт. Прорив стався в 1970-х, коли XEROX розробили свій графічний інтерфейс, який вже «запозичили» спочатку Apple, а потім і всі інші виробники комп’ютерів.

Ось вам відео з рекламою того-самого першого пра-пра-компа 1972 року :

Доречі, саме тоді і з’явились поняття «робочого стола», «іконок», тощо. І аж в 1983 році Аллен Ньюелл, Стюарт Кард та Томас Моран видали в світ свою фундаментальну працю «The Psychology of Human-Computer Interaction», яка фактично і cтворила UX-дизайн. Звісно, вперше «UX» ввів в назву свого тайтла Дональд Норман аж в 1993 році, коли приєднався до Apple на посаду User Experience Architect, але це вже зовсім інша історія.

Історія про HCI тут для того, щоб нагадати, що в ланцюгу юзер-взаємодія-комп’ютер, можуть змінюватись комп’ютери (з’являтись нові девайси типу лептопа, смартфона, годинника чи планшета, VR чи AR, голосові помічники, тощо, компи можуть ставати сильніші щороку), може змінюватись взаємодія (в залежності від девайсу та існуючих паттернів), але незмінною ланкою тут є ЛЮДИНА.

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

Людина-користувач — тут мається на увазі саме юзер, для якого працює команда продукту;
Людина-UX-дизайнер — а тут вже ми говоримо саме про команду дизайнерів, які є передавальною ланкою. Мені особисто подобається вираз «Дизайнер це перекладач з людської мови на технічну і навпаки». Нюанс полягає в тому, що дизайнер в продукті це людина, яка не тільки малює макети, а й приймає певні рішення щодо функціоналу (разом з ПМ, БА, стейкхолдерами і тд). Тобто роль дизайнера передбачає безпосередній вплив на продукт, а отже і на користувача. Виходячи з цього, на UX впливають саме люди: користувачі і команда розробки. А отже UX є люди!

Вже можна відкривати вікна — здається тут було трошки душно 😎

UX Slogan #8: Make it Easy

Спрощуй

Якщо в слогані #2 ми говорили що потрібно Зберігати простоту, то слоган #8 нам наголошує саме на Спрощенні. Для кращого розуміння, давайте сформулюємо ці слогани англійською: Keep It Simple VS Make It Easy. Тобто слоган 2 нам підказує, що необхідно саме зберігати простоту, не збільшуючи складність, а в слогані 8 ми говоримо саме про спрощення — тобто зменшення складності як активну дію.

Якщо ми говоримо про зчіпку «утилітарність + юзабіліті», то «простота» та «спрощення» може відноситись до кожної з частин цієї зв’язки. З однієї сторони під «спрощенням» ми можемо розуміти пріоритизацію функціоналу вашого продукту та розміщення цього функціоналу релевантно частоті використання (або запиту користувачів — і тут відсилка до Fake Door тестування). Умовно — не варто вивалювати на кориситувача все, що вміє ваш продукт, а показувати лише найпопулярніший та/або найзатребуваніший функціонал. З іншої ж сторони «спрощення» можна розуміти як постійний-безкінечний-ітеративний процес покращення юзабіліті. Ви, як дизайнер, можете постійно спрощувати флоу на базі проведених юзабіліті тестувань.

В якості прикладу — ось вам дивний черговий one-button сайт з примітивною (хоча і непотрібною) дією clickclickclick.click (бажано зі звуком)

UX Slogan #9: Less is More

Менше — Це Більше

Коли я вперше ознайомився з цим слоганом, я подумав «Та скільки вже можна про ту простоту — це ж було вже» (тут я мав на увазі слогани #2 та #8). Але коли розібрався, то побачив різницю. Коли ми говоримо про простоту зі слоганів 2 та 8, то маємо на увазі саме певний функціонал і якесь конкретне інтерфейсне рішення. І саме їх ми хочемо спрощувати та/або не ускладнювати. В цьому випадку простота стосується саме виконання користувачем цільової дії (тобто це флоу).

Впевнений, ви багато чули про той самий «безшовний досвід», який передбачає здійснення юзером певної цільової дії без зайвого тертя об інтерфейс. Дизайнер складає CJM, JTBD Timeline, Service Blueprint та інші мапінги, шукає bottleneck-и, вирішує точкові проблеми — і все це для легкого досягнення мети і закриття болю юзера. Зазвичай в якості ключового сценарію береться саме флоу монетизації, як головної цільової дії користувача в продукті. Дизайнер зацікавлений зробити цей шлях легким — щоб нічого не відволікало юзера, щоб всі сумніви і невпевненості були мінімізовані, а різкість негативної емоції була мінімальна, або взагалі відсутня. На своєму шляху користувач використовує інтерфейс, бере необхідну інформацію, споживає контент, взаємодіє з елементами інтерфейсу сторінки.

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

Мені особисто цей слоган віддалено нагадав вираз Голдена Крішни з його книги «The Best Interface is No Interface»:

Коли ми проектуємо інтерфейси, ми проектуємо бар’єри між людьми та їхніми цілями

Проводячи паралель між цим виразом і слоганом #9, можна сказати що чим менше бар’єрів в інтерфейсі ми робимо, тим краще!

UX Slogan #10: Users Are Not Lazy

Користувачі Не Ліниві

Всі ми чули жарт про юзабіліті-тестування: «Це не дизайн невдалий — це просто люди тупі!». Звісно, це жарт, але деякі дизайнери насправді так так думають. Напевне під час сесії тестування, вони говорять тихо «давай не лінись, пошукай особистий кабінет ще», або «давай но, не туйво, заповнюй всі 38 філдів реєстрації» або «давай но, проходь всі 27 стейджів онбординга».

Тут все просто як двері — користувачі не є лінивими — вони раціональні. Мені здається це пов’язано з когнітивним навантаженням. Адже коли в людини виникає проблема, вона починає думати, а мозок — найенерговитратніший орган (при вазі лише 2% від маси тіла людини, мозок споживає біля 20% енергії). Тож користувач не сильно любить напружуватись, а робота дизайнера не напрягати юзера зайвий раз.

В вищезгаданій книзі Голдена Крішни «The Best Interface is No Interface» є ще один цікавий вираз, який буде дуже валідно згадати тут:

Користувачі не є лінивими — вони просто хочуть отримати результат з найменшим спротивом

Сорі, але про «вибіркову увагу» або «інерцію пристрою» я не сильно бажаю рефлексувати, адже на мою думку, це є не суттєвим. Але якщо хочете — гляньте в відео нижче:

UX Slogan #11: If You’re Not Checking, You’re Guessing

Якщо Ти Не Перевіряєш — Ти Вгадуєш

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

NNG виділяють 3 причини, чому команди можуть відступати від необхідності формулювати свої продуктові гіпотези на основі досліджень:

Члени команди розробки та замовник в певній мірі є користувачами продукту і тому покладаються на власний досвід користування Тут одразу ремарка — згадуємо Слоган #1: Ти Не Є Користувач!
Команда і стейкхолдери вважають себе достатньо компетентними в домені, щоб приймати рішення суто на інтуїції, адже їх «експертна думка» завжди правильна Тут вже цікавіше — якщо продуктовий дизайнер працює в домені вже досить довгий час, він дійсно добре знає аспекти. Але мудрий працівник все-одно буде ставити під сумнів власні припущення. Вийшло занадто в дусі Сунь-Дзи, але так воно є. З іншої сторони — погано коли продукт працює суто на асампшенах дизайнерів та/або ПМ-БА, адже ці ролі напряму впливають на розвиток продукту, що зобов’язує їх мати велику надивленість. А часто оверкомпетенція та овернадивленість може завадити.
Команди вважають дослідження занадто дорогими і не сильно потрібними
Якщо проводити всі на світі активності, то в цьому випадку певна доля істини тут є, але якщо підходити до досліджень з розумом, то можна їх сильно здешевити. Завжди можна кастумізувати свій дизайн-процес, пропрацювати стратегію з мінімальними бюджетами і вставити в процес розробки ті UX-активності, які проект може собі дозволити.
Я особисто додав би ще одну причину:
Надмірне використання командою Штучного Інтелекту
Часто команда та замовник впевнені, що з однієї сторони UX-дослідження це дорого, а з другої сторони Штучний Інтелект (ШІ) може замінити дослідження. І оце масове захоплення ШІ наразі дуже шкодить, адже ШІ-шка вміє круто процесити, обробляти великі масиви даних, допомагати при деск-рісерчі, але в питаннях інсайтів, формулювання продуктових гіпотез або ідеації та валідації солюшенів, ШІ взагалі непридатний.
Існує цікава статистика основана на дослідженнях таких гігантів як Google, Microsoft та Netflix, що лише 10% продуктових гіпотез приносять якесь бізнес-велью. Це при тому, що компанії постійно проводять дослідження. Якщо ж будувати гіпотези на здогадках, то цей відсоток зменшується критично.

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

UX Slogan #12: More Choices More Trouble

Більше Вибору — Більше Проблем

Цей слоган дуже схожий на сформульований Уільямом Хіком та Рейем Хайманом в 1952 році Закон Хіка. Тому зекономлю ваш час на читання очевидних речей. Та і вкотре пояснювати кореляцію між кількістю варіантів та когнітивним навантаженням на користувача не сильно хочеться. Краще розповім чергову цікаву байку.

В 2002 році Баррі Шварц написав свою роботу «Maximizing Versus Satisficing: Happiness Is a Matter of Choice», де досліджував Парадокс вибору та наскільки сильно зростає роздратування покупця в залежності від опцій, між якими необхідно зробити вибір.
Але це дослідження не є першоджерелом, фундаментальним був експеримент Шини Айєнгар та Марка Леппера описаний в їх роботі «When Choice is Demotivating: Can One Desire Too Much of a Good Thing?» 2000 року. Саме їх експеримент з джемом став емпіричним підґрунтям дослідження Баррі Шварца. Просто нагадаю — в експерименті було 2 столика: з 6 видами джему та з 24 видами джему. За сценарієм експерименту, людині давали купон на знижку в 1$ для покупки собі джема та направляли до одного зі столів. Результати експерименту здивували всіх:

Зупинились біля столика (умовний аквізишн): 60% біля стола з 24 сортами джему та 40% біля стола з 6 сортами джему;
Скоштували джем (тріальна версія): — по 2 сорти біля кожного зі столиків;
Купили джем (конверсія в продаж): 3% в стола з 24 сортами джему і 30% в стола з 6 сортами джему;
Задоволеність покупців (сатісфекшен): була істотно вища в покупців в стола з 6 сортами джему.

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

UX Slogan #13: Design for Them Not for You

Дизайнь Для Них, Не Для Себе

Не розумію навіщо писати дубль слогана #1 «Ти Не Є Користувач» просто в іншому формулюванні?! Загалом в відео Сара Гіббонз вкотре розповідає про важливість не забувати про те, що дизайнер не є юзером. Тому, щоб не повторюватись, краще розповім вам про «Ефект хибного консенсусу», який згадується в відео.

В 1977 році Лі Росс провів дослідження з назвою «людина-сендвіч», в результаті якого і був сформульований «Ефект хибного консенсусу». Пан Лі з колегами запропонували групі студентів Стенфордського Університету (104 особи) взяти участь в «дослідженні технік комунікацій». Студентам пропонувалось добровільно вдягнути на себе рекламний щит (так званий «сендвіч» з написом на спині та животі) з рекламним слоганом «Їжте у Джо» та 30 хвилин ходити по кампусу. Студентам не обіцяли матеріальної винагороди, проговорювалась можливості відмовитись і наголошувалось на тому, що їх участь нібито дуже допоможе в дослідженні технік комунікацій.

В результаті дослідження були цікаві інсайти:

62% з тих, хто погодився, були впевнені що переважна більшість студентів вибірки погодяться. А тих, хто відмовиться характеризували «занадто сором’язливими», «егоїстичними» або «дивними»;
Лише 33% від тих, хто відмовився брати участь в експерименті, були впевнені що більшість погодяться. Тобто 67% (100% — 33%) вважали що більшість теж відмовиться і характеризували тих, хто погодиться «вискочками», «дурнями» або «тими, хто хоче привернути увагу». Це дослідження висвітлює власну пресуппозицію правоти та асоціації себе з користувачем і це дуже погано для дизайнера.

UX Slogan #14: It Depends

Це Залежить Від…(обставин)

Коли мені джуни або студенти кажуть фразу «Ну це залежить від…», я завжди відповідаю що It Depends — це завжди правильна відповідь на будь-яке питання. То є певна універсальна відповідь незалежно від поставленого питання😉

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

Утилітарність та Цінність Тут ми говоримо загалом про цінність вашого продукту саме для користувача і чи він здатний закрити біль (проблему) юзера, з якою той прийшов до вашого продукту.
Доступність та Інклюзивність Чи дозволяє продукт закрити біль всієї цільової аудиторії і чи не ігнорує людей з певними обмеженнями (щодо аксесабіліті є багато статей, тож на цьому я зупинятись не буду зараз). Але один аспект все ж виділю — не забувайте що ситуативна обмеженість трапляється з користувачами досить часто. Наприклад, людина під час стресу або в умовах обмеженого часу буває досить часто (особливо коли проживає в наш час в Україні), тож ці ситуації необхідно також враховувати.
Зручність використання (юзабіліті) та когнітивне навантаження Ну тут все ясно — продуктом повинно бути зручно користуватись (якщо це не ситуація з розряду монополії, олігополії, монопсонії), інакше юзер піде закривати свій біль на продукт-конкурент.
Бажаність як емоційний відгук користувача Хороший продукт завжди викликає в користувача довіру, позитивні емоції, консистентно спілкується з ним за допомогою мікроанімацій та tone of voice. Згадайте той самий monobank https://monobank.ua/ з його котиками. Люблю розповідати цю історію — колись ми з друзями літали в Копенгаген і в аеропорту десь загубили мого (тепер вже) кума. А він лише ходив в дьюті фрі щоб купити щось і відкрити чергового котика в МОНО. Андрюха, якщо ти це читаєш, дякую тобі за круту історію!
Бізнес логіка Тут все максимально просто — ваш продукт повинен бути не тільки самоокупним, а й прибутковим, тому команда завжди ретельно прораховує ROI та інші KPI.
Технічні особливості і обмеження Дизайнер повинен враховувати особливості технології, на якій написаний продукт. Тому бажано розуміти (хоча б мінімально) особливості використаного фреймворка/платформи/технології. Тоді імплементація дизайн-рішення буде коштувати дешевше крила літака.

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

Якщо вам потрібно враховувати обставини в яких знаходиться не користувач, а ВИ як дизайнер, то просто нагадую вам про Method • Reason • Price як метод підбору активностей.

Є ще цікавий нюанс про який нам розповідає відео від NNG — дуже часто дизайнери використовують бест практіси як сільвер булет — як щось, що працює завжди і в будь-якій ситуації. Звісно, бест практіси це вже перевірені дослідженням, часом і кейсами практики, вони є певним бенчмарком, але вони занадто загальні і ігнорують той самий контекст, тому не є оптимальними ЗАВЖДИ. Виходячи з цього, для забезпечення найкращих результатів (конверсії в щось важливе та інших KPI), бест практіси можна змінювати в залежності від того, в якій ситуації знаходиться юзер.

UX Slogan #15: Show Me the Data

Покажи Мені Дані або мені краще подобається Покажи Пруфи!

Дуже часто, коли команда обговорює якусь нову фічу, або лейаут, в обговорення прокрадається суб’єктивна думка ваших мейтів. Особливо дивно, коли розробники починають транслювати ЩО САМЕ потрібно користувачам, яка повинна бути кнопка чи чому макети погані. А дивно це тому, що то є суто думки ваших мейтів — вони є суб’єктивні і не підкріплені нічим. В цей момент мало просто нагадати слоган #1 «Ти Не Є Користувач», бажано ще додати «Покажи Мені Дані».

Якщо ми говоримо про продукт, який працює не суто на якісних дослідженнях, а й періодично проводить сурвеї, SUS і постійно міряє метрики з аналітики, то кількісні дані можуть легко підтвердити або спростувати асампшени ваших колег. Якщо ж це аутсорзний проект (без доступу до всього вищеперерахованого), то «відстрілювати рожеві поні» клієнта та мейтів, буде набагато важче (ми вже говорили трошки вище про HCD, DDD та TDD в слогані #6).

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

Саме тому на мою думку слоган #15 валідніше перекласти не як «Покажи мені дані», а як «Покажи пруфи!». Саме в наданні доказів і лежить суть слогану — тоді він допоможе знизити ризики прийняття невірного рішення.

UX Slogan #16: UX Researchers, We Like to Watch

Як UX-Дослідники, Ми Любимо Спостерігати

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

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

Юзер Інтерв’ю Касдев це найрозповсюдженіший метод дізнатись проблеми користувачів за допомогою спілкування з ними;
Модероване Юзабіліті Тестування Прекрасний метод якісного дослідження, що допомагає валідувати ваші інтерфейси;
Польові Дослідження Один з видів контекстного дослідження, під час якого дослідник може спостерігати за ЦА під час використання продукту;
Фокус-Групи Робота з групою користувачів. Зазвичай в фокус-групу беруть 6–10 людей (більше вже важко модерувати) і проводять якісь партисипативні активності;
Кард Сортінг / Трі Тестінг Класно допомагає пропрацювати інформаційну архітектуру і дає багато інсайтів;
Метод Виявлення Метафор Зальтмана (Zaltman Metaphor Elicitation Technique або просто ZMET) Цікава активність для отримання метафор та образів, які викликають у користувачів ваш продукт (бренд);
Метод Тріад Допомагає дізнатись відношення користувача до вашого продукту шляхом порівняння з продуктами-конкурентами;
Щоденникові Дослідження Чесно кажучи, от саме цього дослідження я ніколи не робив, але чув що крута штука. Юзерам видаються методи фіксації їх досвіду і протягом певного часу агрегуються інсайти. Очевидно, цей метод дослідження не дешевий і тому дозволити його собі можуть далеко не всі проекти.

UX Slogan #17: This is Too Easy to Understand

Це Занадто Легко Для Розуміння

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

Давайте на прикладі. Ви зараз читаєте статтю про дизайн (тож мені здається, що ви дизайнер) і якщо натрапите на вираз «перед проведенням A/B тестування буде валідно провести A/A тестування з метою рівномірного спліту трафіка», то ця фраза вас не злякає і буде зрозумілою. Але якщо сказати те саме фразою «перед тим як проводити A/B тестування, запевніться що трафік розділився рівномірно між варіантами», то ви також все зрозумієте. І проблем теж не буде.

Нічого поганого в спрощенні немає або як казала омеба «Навіщо все ускладнювати?»😂

п.с. Саме тому я використовую для написання статей саме такий стильок — імхо, пояснювати складні речі треба простими словами.

UX Slogan #18: Stop Solutioneering

Не Роби Рішення Зарано

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

Якщо говорити про цей слоган в рамках нашого дизайн-процесу (наприклад Double Diamond), то Solutioneering (solution engineering) — це нездорова схильність дизайнера одразу застрибнути на діамант вирішення (другий діамант), без розуміння самої проблеми (перший діамант). Дизайнер повинен бути скептиком і розбиратись в нюансах, адже диявол криється саме в деталях (тут також варто нагадати про Слоган #15 — Покажи Пруфи!).

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

Яку проблему ми сподіваємося вирішити?
Які в нас є докази того, що ця проблема існує?
Чому ми вважаємо, що саме це рішення допоможе?
Особисто я є апологетом Method-Reason-Price-Metric підходу, про який я вже писав вище і який мене поки жодного разу не підводив.

Але я б хотів проговорити ще один нюанс — можливо, коли ви читали про слоган #18, ви згадали про Lean, який передбачає створення продукту на припущеннях, кидання цього продукта в ринок і трекання респонду. Напевне ви подумали «Ей, але тут в нас припущення і ми не знаємо майже нічого про валідність проблеми». І ви десь навіть праві, але навіть, коли ви працюєте по ліновському процесу, робити рішення взагалі без розуміння проблеми — не є правильним. Хоча б базове розуміння проблем і болей користувачів ПОВИННО бути! Тож не ігноруйте проблематику і не поспішайте генерувати рішення.

UX Slogan #19: Clarify, Don’t Mystify

Прояснюй, Не Містифікуй або Роби Ясність, а Не Загадки

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

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

Якщо ж ми говоримо про проєкт (а не UX-процес в дизайн-тімі), то відмальований лейаут повинен бути очікуваним і виправдовувати припущення користувача. Саме для цього ми проводимо тестування наших макетів і так любимо використовувати різні Cognitive Walkthrough та Pluralistic Walkthrough.

Саме тому давайте «робити порядочек», а не загадки та несподіванки!

Перед висновками, давайте згадаємо всі слогани, які ми сьогодні згадали:

You ≠ User / Ти Не Є Користувач
Keep it Simple / Зберігай Простоту
You Can’t Impose Joy / Ти Не Можеш Нав’язати Радість
Communication not Decoration / Комунікація, а Не Декорація
Brevity = Brilliance / Лаконічність = Геніальність
«Why» Beats «What» in UX / «ЧОМУ» Важливіше Ніж «ЩО» в UX
UX is People / UX Це Люди
Make it Easy / Спрощуй
Less is More / Менше — Це Більше
Users Are Not Lazy / Користувачі Не Ліниві
If You’re Not Checking, You’re Guessing / Якщо Ти Не Перевіряєш — Ти Вгадуєш
More Choices More Trouble / Більше Вибору — Більше Проблем
Design for Them Not for You / Дизайнь Для Них, Не Для Себе
It Depends / Це Залежить Від…
Show Me the Data / Покажи Пруфи!
UX Researchers, We Like to Watch / Як UX-Дослідники, Ми Любимо Спостерігати
This is Too Easy to Understand / Це Занадто Легко Для Розуміння
Stop Solutioneering / Не Роби Рішення Зарано
Clarify, Don’t Mystify / Роби Ясність, а Не Загадки

Summary

В ПреСаммері (яке я став тут публікувати а лишив тільки на Медіумі) я планував розібрати по частинкам кожен слоган, адже думав, що всі вони будуть супер-сильно пов’язані між собою, корелювати з коммон сенсом, іншими законами UX, евристиками, критеріями юзабіліті і тд. Насправді мені стало нудно показувати взаємозв’язки і в певний момент я прийшов до висновку, що всі ці Слогани, евристики, правила — це все одне і те саме. Важко виділити НОВІ і оригінальні емпіричні тейки. Все занадто пов’язано між собою.

Тому мій особистий висновок зі Слоганів від NNGroup десь такий: пам’ятайте, що ВИ НЕ Є ЮЗЕРОМ (просто дуже вже мені подобається цей слоган) і намагайтесь всіма вашими силами і знаннями покращити досвід ЦА!

П.С. Якщо вам сподобалась моя стаття і якщо вам хочеться віддячити і допомогти мені особисто — зробіть донат на ЗСУ. Я буду задоволений і знатиму, що витратив час не дарма!

Сподіваюсь моя стаття допоможе зробити вашу роботу більш осмисленою та виваженою, а ваш продукт прибутковим. Тож щасти і до нових зустрічей в рубриці #задротствозбородатим 😂❤️🇺🇦

Як керувати UX в стартапі

Євген Олексюк — Thu, 27 Jul 2023 16:00:22 +0000

Нещодавно в мене була дуже цікава консультація на Projector Mentorship Platform. Думаю не варто розповідати хто і навіщо приходив на розмову, але я хотів би поділитись тими висновками, які я зробив з цієї консультації. Я зрозумів, що в дуже багатьох UX/UI/Product дизайнерів є знання про базовий дизайн процес, але не завжди люди вміють комбінувати активності, щоб отримати бажаний результат дослідження. І головне — не завжди розуміють які саме артефакти зʼявляться при тому чи іншому дослідженні і як після проведення дискавері використати отримані результати для покращення свого продукту.

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

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

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

NOTE:
Синдром «гарячої руки» вперше сформулював Бен Коен в 2020 році в своїй книзі «Гаряча рука: загадка та наукові суперечки з приводу серій». Якщо коротко описати суть цього синдрома — то це впевненість гравця, що він всесильний, коли він «зловив кураж». Ніби закони фізики для нього змінились і він може все. Таке когнітивне спотворення існує не тільки в баскетболі і може бути в будь-якої людини, коли вона «ловить кураж». Це дуже небезпечний байес, який може змушувати дизайнера проганяти будь-який проєкт за звичайним йому дивергентно-конвергентним процесом, використовувати ті самі активності і сподіватись що все як завжди буде СУПЕР. 😂

Тож уявімо, що ви — дизайнер, який довго працював на outsource і прийшов в продукт. Які ж активності будуть в такому випадку валідні і найкорисніші? Звичайно, можна упоротись і зробити всі на світі активності від мапування стейкхолдерів і аж до щоденникового дослідження і когортного аналізу. Але чи всі ці активності однаково корисні?! Чи за всі ці активності схоче платити ваш стейкхолдер?! Тут ще раз нагадаю, що в будь-якому разі, бенефіціаром та людиною, яка оплатить вашу роботу буде саме стейкхолдер — ваш замовник. Тому бажано вміти обирати активності. І знову ж таки тут вам стане в нагоді «Method • Reason • Price Approach».
Скоріш за все вам доведеться обирати, що саме необхідно використовувати в роботі, які активності дадуть вам найбільше велью та допоможуть бізнесу максимально ефективно.
Тож давайте пройдемось по активностям, які варто зробити в вашому стартапі. Звичайно, це може бути моя суб’єктивна думка, але, якщо вам є що додати — feel free прийти в коментарі та сказати вашу думку 👍
На самому початку, давайте домовимось, який саме продукт можна вважати стартапом, а який — дорослим мачюрним гігантом. Особисто я чув декілька класифікацій:

Згідно виводу продукту на Inintial Public Offering (IPO) Якщо продукт ще не вийшов на IPO, то він стартап, якщо ж його акції вже випустили та продають всім бажаючим — то це вже «здоровань» 👍
Згідно кількості працівників Тут все більш розмито: якщо ви стартап — в вас працює мало людей, якщо ж ви вже дорослий продукт — в вас працює багато людей. Але скільки це «багато» і «мало» — грець його знає.
Згідно часу продукту на ринку Якщо ви працюєте мало часу на ринку — ви стартап, якщо ж багато років — дорослий продукт.
Згідно величини залучених інвестицій / отриманих прибутків і т.д. Теж розмиті категорії. Адже скільки інвестицій або прибутків треба для переходу в «дорослий продукт» — не відомо.

Особисто мені всерівно, як саме ви називаєте свій продукт — «стартап» чи «дорослий мачюрний гігант». Для себе (а я нагадую що я дизайнер і тому дивлюсь на класифікацію виключно з боку дизайнера) я визначив «стартапом» будь-який продукт, в якому дизайнеру треба думати що робити, які активності потрібні тут / зараз і головне — треба «продати» цю активність стейкхолдеру. Щоб він погодив утилізацію вашого часу на цю конкретну запропоновану UX-активність.
Якщо приймати запропоновану мною різницю між стартапом та продуктом, то звідси легко можна прйти до висновку, що в стартапі дизайнер має більше зобов’язань, вищий рівень відповідальності та більше впливу на кінцевий результат. Звичайно ж, якщо стейкхолдери/власники стартапу адекватні люди і готові слухати працівника 😂.
Ну і звичайно, коли ти працюєш в стартапі, ти знаходишся набагато ближче до стейкхолдерів і бізнесу як такого. Тому треба відповідати потребам бізнесу, розуміти їх та думати не тільки про користувача (тут ми вкотре згадуємо твердження, що «дизайнер це адвокат користувача»), а і про бізнес. Тобто в продукті/стартапі дизайнер повинен покривати всі три спота «табурета Нормана». А щоб покривати і бізнесові реквайрменти, бажано розібратись що саме и як продає стартап, на чому він заробляє, де маржа, які доходи та витрати має і іноді відстрілювати «рожевих єдинорогів» стейкхолдерів, коли вони починають фонтанувати непідтвердженими продуктовими гіпотезами. Це класна можливість для розвитку в T-Shaped або Paint-Drip спеціаліста.

Тож давайте вже до справи. Які дизайн-активності (окрім стандартних активностей на кшталт User Interview, User Persona, CJM та інших) принесуть стартапу найбільшу користь?

Business Model Canvas (далі BMC)

BMC — це один з інструментів опису, візуалізації, оцінювання, стратегічного управління та зміни бізнесу. Розробив цю канву Олександр Остервальдер (компанія Strategyzer) в 2005 році як темплейт для опису бізнесу. Фактично BMC — це скорочена таблиця, в якій викладена основна інформація про бізнес, його основні складові та бізнес-процеси. Це дуже сильно економить час і спрощує розуміння бізнесу, тому що при заповненій ВМС не потрібно лазити за необхідною вам інформацією в безліч різних документів (бізнес-план, стратегія, різні дизайн-артефакти, КБ-шки, тощо).

Канва являє собою таблицю, що складається з 9 блоків, що логічно поділені в 4 групи:
1. Інфраструктура (Infrastructure) — тут описується як компанія виробляє той продукт чи послугу, який потім отримує клієнт. Ця група складається з блоків:

Ключові Види Діяльності (Key Activities) — описує найважливіші заходи, за допомогою яких компанія може зробити свою бізнес-модель;
Ключові Ресурси (Key Resources) — описує найважливіші активи, потрібні для того, щоб бізнес-модель запрацювала;
Ключові Партнерства (Partner Network) — описує мережу постачальників і партнерів, які допомагають бізнес-моделі функціонувати;
2. Пропозиція (Offering) — тут знаходиться опис безпосередньо самого продукту, що пропонується покупцям. Ця група складається з одного блоку:
Ціннісна пропозиція (Value Proposition) — описує пакет продуктів і послуг, які пропонують цінність для конкретного клієнтського сегмента
3. Клієнти (Customers) — тут знаходиться опис бізнесу в розрізі його цільової аудиторії та методів взаємодії з нею. Група складається з блоків:
Сегменти Клієнтів (Customer Segments) — визначає різні групи людей або організацій, яких підприємство прагне залучити й обслуговувати
Канали (Channels) — описує, як компанія взаємодіє із сегментами клієнтів, щоб запропонувати й надати ціннісну пропозицію
Відносини з клієнтами (Customer Relationships) — описує типи відносин, які компанія встановлює з конкретними сегментами клієнтів
4. Фінанси (Finances) — опис фінансової сторони бізнесу. Складається з блоків:
Структура витрат (Cost Structure) — описує всі витрати, потрібні для роботи бізнес-моделі
Потоки доходів (Revenue Streams) — включає кошти, які компанія генерує від кожного клієнтського сегмента (щоб отримати прибуток, слід від доходів відняти витрати)
В класичній ВМС часто ще наводять послідовність заповнення темплейту, але насправді головним саме для заповнення канви є отримання релевантної та повної інформації про бізнес. А як ви будете її заповнювати — це вже вторинне. Крім того, якщо канву ви заповнюватимете під час установчої зустрічі зі стейкхолдерами (так званий кік-оф) або під час воркшопу з стейкхолдерами, дуже часто важко втримати порядок заповнення, адже ваш замовник може не мати в голові чіткої структури інформації. Тож не бійтесь відійти від послідовності, але бійтесь не отримати важливої інформації.

Дуже важливо розуміти, яку цінність несе BMC для вашого проєкту (в нашому випадку стартапу). Головне велью — це агрегування всієї головної інформації в супер-скороченому вигляді на одному листочку. Навіть на цьому етапі ви зможете вирішити 2 проблеми:

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

Якщо ви додатково триангулюєте BMC іншими дослідженнями, то буде взагалі шикарно 👍
Найчастіше ВМС складається бізнес-аналітиком та дизайнером. Якщо ж ви джуніор або мідл дизайнер, то бажано вміти хоча б читати канву і знати як з нею працювати.
Більше про ВМС, ви можете прочитати в книжці Ів Піньє , Александер Остервальдер «Створюємо бізнес-модель».
Звісно, найкраще розбиратись з канвасами на практиці, але якщо в вас такого досвіду ще немає, а вам кортить навчитись працювати з BMC, можна переглянути приклади заповнених канвасів для всесвітньо відомих брендів.

І всім класна Business Model Canvas, але є в неї один великий мінус — вона круто описує реальні види бізнесу (кав’ярня, продуктовий магазин, тощо), а от для діджитальних продуктів вона вже не супер-крута і має певні недоліки. Саме для того, щоб адаптувати BMC для цифрових продуктів (особливо на стадії стартапу), вила складена інша канва — Lean Canvas.

Lean Canvas (LC)

LC — це односторінковий шаблон опису бізнесу, який було в 2010 році розроблено Ешем Морійа, як адаптацію та оптимізацію Business Model Canvas Остервальдера, але вже для стартапів та більше діджітальних продуктів.

Головними перевагами LC є:

Швидкість — на відміну від написання бізнес-стратегії, бізнес-плану, яке може тривати тижнями та місяцями, LC можна скласти протягом одного дня. Особливо швидко це робиться за допомогою воркшопу зі стейкхолдерами.
Зручність в використанні (Портативність) — очевидно, що односторінковий артефакт легше шейрити зі своїми колегам і таким чином алайнитись в розумінні важливих аспектів бізнесу.
Лаконічність — LC дозволяє швидко виділити важливо і пояснити все стейкхолдеру за кілька секунд. Все тезово і максимально зрозуміло.
Ефективність — канва дозволяє швидко та доступно презентувати та контролювати прогрес. Як і Business Model Canvas, Lean Canvas являє собою певну графічну канву, заповнивши яку ви зможете швидко замапити бізнес і швидко зрозуміти всі переваги та недоліки. LC складається з 9 блоків, деякі з них мають ще додаткові блоки — тому загальна кількість всіх блоків складає 12 блоків і описує про бізнес ВСЕ!

Блоки Lean Canvas:

Проблема (Problem) — Цільова Аудиторія, з якою ви плануєте працювати, матиме певний набір проблем, які вони хочуть вирішити. Тож в відповідному блоці необхідно вказати від 1 до кількох проблем ЦА, яку/які ви хочете вирішити за допомогою вашого продукту. Важко уявити, що продукт може бути успішним та потрібним, якщо не знайшов потреби та проблеми своєї ЦА, тож це дуже важливий блок!
Існуючі Альтернативи (Existing Alternatives) — Тут ви описуєте які є альтернативи на ринку, за допомогою ваша ЦА може вирішити свої проблеми. Тут вам стане в нагоді Аналіз прямих та другорядних конкурентів.
Рішення (Solution) — Цей блок найкраще пояснює саму суть Lean Startup — тут повинно бути зафіксоване рішення проблеми вашої ЦА. Нормально, якщо це рішення не буде на поверхні, до нього потрібно прийти. Тут дуже вчасно згадати вислів Стіва Бланкса (хрещеного батька Lean підходу) «Щоб це зрозуміти — необхідно вийти назовні«» (анг. What you need to do is Get Out The Building). Щоб зрозуміти рішення, необхідно вийти з офісу, адже працювати в вакуумі в цьому випадку буде категорично не вірно — треба йти до людей і ставити питання.
Ключові Метрики (Key Metrics) — тут ви описуєте, які саме метрики ви вимірюватимете, щоб фіксувати динаміку розвитку продукту. До питань метрик ми ще повернемось трошки пізніше в цій статті.
Унікальна Ціннісна Пропозиція (Unique Value Proposition) — УЦП це, напевне, найголовніший блок LC, адже він показує обіцянку вашого продукту виконати біль користувача. Це і є основна причина, чому ЦА буде купувати продукт у вас, а не у конкурентів. Звичайно, цей блок повинен бути заповнений обов’язково!
Високорівневий Концепт (High-Level Concept) — В цей блок ви поміщаєте певну фразу/речення/вислів, яким можете коротко описати вашу УЦП. Це потім може навіть стати слоганом вашого продукту. Головним тут є коротко і зрозуміло показати, про що ваш продукт. Приклади таких високорівневих концептів відомих продуктів є: «The Smartest Way to Get Around» — UBER «The Experience IS the Product» — Apple iPhone «Be More Productive at Work with Less Effort» — Slack
Несправедлива Перевага (Unfair Advantage) — В цьому блоці ви фіксуєте ті переваги компанії замовника, які важко/неможливо забрати або скопіювати. Сюди можуть відноситись різні переваги: технічні (наприклад ваш продукт написаний на якійсь дуже класній технології), людські (наприклад маєте потужну команду дизайнерів, аналітиків та менеджерів, які майстерно працюють з продуктовими гіпотезами), бізнесові (маєте партнерські угоди з постачальниками, офіційне представництво, можливість демпінгувати ринок, маючи високу маржу) та інші (наприклад ваш продукт є монополістом на ринку, чи давно працює, чи отримав велику базу контрагентів).
Канали (Channels) — Цей блок відображає інформацію, як саме ви взаємодіятимете з вашою ЦА? Які канали зв’язку використовуватимете? Lean підхід передбачає швидкий неперервний цикл «Створення/Вимірювання/Навчання», тож для отримання постійного і швидкого фідбеку вашої ЦА, потрібно розуміти через які канали з людьми можна говорити.
Клієнтські Сегменти (Customer Segments) — В цьому блоці важливо розписати вашу ЦА, проблеми якої вирішуватимете. Без розуміння вашого користувача, важко буде зробити успішний бізнес, тож, навіть якщо ви використовуєте Jobs To Be Done, розуміння хто є вашим користувачем повинно бути! Також важливо розуміти, що навіть, якщо ваш стейкхолдер знає краще всіх кому потрібен його продукт, не зайвим буде валідувати його гіпотезу, тому що прото-канва вам користі багато не принесе.
Ранні Користувачі (Early Adopters) — Тут ви описуєте ту категорію користувачів, які першими будуть користуватись вашим продуктом і фактично, стануть вашими євангелістами та адептами. Звісно якщо ви їм сподобаєтесь😉 Але якщо все в вас складеться, то ви матимете справжніх фанатів — вони рекламуватимуть вас всюди.
Структура Витрат (Cost Structure) — Тут все як і в BMC — ви описуєте витрати компанії на здійснення своєї діяльності.
Джерела Доходів (Revenue Streams) — Аналогічно до BMC — описуєте основні джерела отримання доходу.

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

Value Proposition Canvas (VPC)

VPC — це ще одна канва Олександра Остервальдеара. Вперше була розроблена в 2008 році як доповнення до BMC, за допомогою якої ви можете контролювати, наскільки продукт закриває вимоги ЦА.
Перевагами VPC є:

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

Клієнтський профіль структуровано й детально відображає певний сегмент користувачів. Він поділений на 3 сегменти:

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

В свою чергу карта цінності (або карта ціннісної пропозиції) структуровано й детально описує особливості конкретної пропозиції. Вона розбиває ціннісну пропозицію на 3 сегменти:

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

Як і у випадку Business Model Canvas та Lean Canvas, Value Proposition Canvas може бути заповнена зі стейкхолдерами в форматі воркшопу, але знову ж таки, це буде прото-канва. Щоб Value Proposition Canvas стала справжнім артефактом, яким показуватиме всі необхідні та важливі аспекти вашого продукту, необхідно провести серію юзер інтервью, які валідують Сегмент користувачів та нададуть повне розуміння, яких саме послуг, переваг та пейнреліферів бракує вашому продукту, щоб повністю метчити запит цільової аудиторії. Тут вам, доречі, може стати у нагоді Карта Емпатії (Empathy Map) юзера.

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

Unit Economics (UE)

UE- це певний метод обліку, аналізу та планування фінансових показників діджитального продукту. Нажаль я не зміг знайти коли була розроблена UE, але з власного досвіду можу сказати, що ще в 2016 році вона вже існувала і її юзали по повній програмі. 😂
Юніт Економіка існує для того, щоб «вдарити» дизайнера і всю команду об реальність, змістити акцент з почуттів юзерів на цифри, які та люблять і розуміють стейкхолдери.
Так що ж таке за звір ця Юніт Економіка? UE це певний метод розрахунку доходів та витрат конкретної бізнес-моделі (бізнесу) по відношенню до певної одиниці. Звісно для кожного бізнесу, «одиницею» (юнітом) буде певний базовий елемент, що піддається кількісній оцінці і залежить від самої бізнес-моделі, її монетизації та багатьох інших факторів. Наприклад для авіа-компанії цим юнітом буде слугувати проданий квиток на авіапереліт, для служби таксі — продана клієнту його фрахт (переміщення) і так далі. Насправді все дуже просто. Якщо ви трошки розумієтесь в фін. теорії, то напевно знаєте що таке бухгалтерський баланс.

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

Головними перевагами використання UE є:

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

Так от, Unit Economics це тотожне поняття Балансу, але саме в контексті саме цифрових продуктів. Вона оперує такими метриками (поняттями) як:

Lifetime Value (LTV) — це середня сума грошей, яку ви заробляєте з одного клієнта протягом усього періоду його відносин з вами. У SaaS це сума грошей, яку ви заробляєте з моменту реєстрації до моменту, коли вони скасовують підписку і більше до вас не повертаються. Обчислення LTV може багато розповісти про ваш бізнес, тож це є одною з найголовніших метрик.
Customer Acquisition Cost або Вартість залучення клієнта (CAC) — загальна сума грошей, яку витрачає компанія на продажі та маркетинг задля залучення одного клієнта. Якщо ви витрачаєте занадто мало, ви не отримуєте нових клієнтів. Якщо ж витрачаєте забагато, то зменшуєте таким чином маржу і як наслідок — отримуєте менше прибутку. Виважена сума витрат безпосередньо пов’язана з вашим LTV, тому обчислення та розуміння вашого CAC надзвичайно важливе.
Churn Rate або Показник Відтоку (CR) — це відсоток ваших клієнтів, які скасовують свою підписку протягом певного періоду. Так як ваш стартап прагне розвиватись, то важливо відслідковувати динаміку, тому Показник Відтоку може бути важливою метрикою, яка вкаже на зміни як в короткостроковій, так і в довгостроковій перспективі.
Retention Rate або Рівень утримання (R). Рівень утримання є протилежністю Рівню Відтоку. Це відсоток клієнтів, які повертаються в продукт, залишаючись підписаними протягом певного періоду.
Average Customer Lifetime або Середня тривалість життя клієнта (ACL) — це середній проміжок часу, протягом якого клієнт залишається користувачем продукту або сервісу. Очевидно, що ACL є ключовою складовою при розрахунку LTV.
Number of Customers або Кількість клієнтів (C) — це загальна кількість клієнтів продукту протягом певного періоду часу.
Number of Transactions або Кількість транзакцій (T) Не кожному клієнту виставляються рахунки з однаковою частотою, тож цей показник охоплює фактичні транзакції, здійснені протягом певного періоду.

Total Revenue або Загальний дохід (TR) це загальна сума грошей, яку ваш продукт заробив за певний період.
Gross Profit або Валовий прибуток (GP) це загальний дохід продукту мінус вартість продажів.
Average Order Value або Середня вартість замовлення (AOV) це загальний дохід, поділений на кількість замовлень (транзакцій).
Average Gross Margin або Середній валовий прибуток (AGM) це валовий прибуток продукту, поділений на його загальний дохід.

Є 2 методи розрахунку Юніт Економіки:

Визначення Юінту як «Одиниця проданого товару або послуги» В цьому випадку ви розраховуєте Маржинальний прибуток віднімаючи від вартості Юніту витрати на продаж. UE = Price per Unit — Costs per Sale
Визначення Юніту як «Один Клієнт» Тобто в цьому випадку ви прив’язуєте розрахунки вже не до продажів, а до самого кастумера. В цьому випадку Юніт Економіка розраховується як відношення Життєвої Вартості Клієнта (LTV) до Вартості Залучення Клієнта (CAC) UE = LTV/CAC

В цьому випадку вам необхідно прорахувати LTV. Для його прорахунку існує також 2 методи: предиктивний та гнучкий.

Предиктивний LTV допомагає вам прогнозувати дії (а отже і дохід) клієнта на майбутнє. Він розраховується таким чином:
Predictive LTV = (T x AOV x AGM x ALT) / кількість клієнтів за певний визначений період
Тут:

T (середня кількість транзакцій): Загальна кількість транзакцій поділена на вказаний проміжок. Таким чином ви отримуєте кількість транзакцій за необхідний вам період часу.
AOV (середня вартість замовлення): Визначається діленням загального прибутку на кількість замовлень (проданих товарів або послуг) — таким чином ми отримуємо СЕРЕДНЄ значення вартості замовлення.
AGM (середній валовий прибуток): Для розрахунку ми віднімаємо собівартість продажів (CS — Cost of Sales) від загального доходу (TR — Total Revenue). Рівняння буде таке: AGM = ((TR-CS) / TR) x 100.
ALT (середня тривалість життя клієнта). ALT дорівнює коефіцієнту відтоку (CR — Churn Rate) поділеному на 1. ALT = CR/1 В свою чергу Коефіцієнт відтоку визначається порівнянням кількості клієнтів на початку звітного періоду (CB — Customers at the Beginning of a given period) до кількості в кінці (CE — Customers at the End). Churn rate = ((CB-CE)/CB) x 100.

Очевидно, що предективний LTV націлений саме на передбачення та прогнозування фінансових метрик, але у випадку стартапів, необхідно мати більш гнучку LTV-метрику, яка буде швидко реагувати на зміни ринку та позиціонування продукту на ньому. Тому існує так званий «гнучкий LTV».
Flexible LTV = GML x (R/(1 + D — R))
Тут

GML (середній прибуток з одного клієнта — average gross margin per customer lifespan) це сума прибутку, отримана вашим бізнесом від одного клієнта за період його користування вашим продуктом. Вона вимірюється: GML = GM x (TR / С) Тут: GM — Валовий прибуток TR — Загальний дохід C — Кількість клієнтів за певний період
D (Discount rate): Ставка дисконтування вимірює ставку повернення інвестицій (ROI — Return on Investment). Це валідно якщо ваш стартап має залучені інвестиції.
R (Retention rate): Ретеншен, або коефіцієнт повернення юзерів буде детальніше описано в наступній активності, але для цієї формули він обраховується як R = ((CE — CN) / CB) x 100 Тут: CB — Кількість активних користувачів, які неодноразово здійснили покупку на ПОЧАТКУ звітного періоду CE — Кількість активних користувачів в КІНЦІ періоду CN — Кількість залучених користувачів.

Також дуже важливою метрикою Юніт Економіки є вартість залучення користувачів — CAC — cost of acquisition. Вона показує наскільки доцільні маркетингові витрати та наскільки інвестиції в рекламу та інші джерела залучені добре справляються з отриманням нових лідів в вашому продукті. CAC обраховується супер-просто:

CAC = SMC / CN
Тут:

SMC — Sales and Marketing Costs — Витрати на продажі, рекламу та маркетинг
CN — Number of Acquired Customers (New Customers) — Кількість залучених користувачів.

Логічно, що всі ці заміри та прорахунки потребують часу, щоб відслідковувати їх в динаміці. І очевидно, що для стартапів періодичність прорахунків та замірів повинна бути досить мала, щоб швидко реагувати на будь-які зміни ринку.
І логічно, якщо в вас в голові зараз з’явилось питання «Бородатий, все це круто і цікаво, але це все рахувати пальчиками на папірці? Важко ж!». Звісно, ніяких пальчиків і механічних прорахунків. Звичайний Microsoft Excel вам допоможе — треба лише один раз налаштувати документ і він все зробить за вас. Там же і графіки пробудуєте і динаміку слідкуватимете.
А цифри для прорахунків вам надасть фінансовий відділ та звичайнісінька Google Analytics, тож не бійтесь, а мершій рахуйте.

AARRR: Pirate Metrics Framework (PMF / AARRR)

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

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

Залучення або Acquisition (A) — цей етап взаємодії відповідає за залучення нових відвідувачів вашого продукту. Тут ви можете опрацьовувати методи, за допомогою яких люди дізнаватимуться про ваш сервіс. Можливо ви чули теорію «7 доторків». Вона широко використовується як в продажах, так і в політиці і стверджує, що потенційний клієнт повинен почути про вас не менше 7 разів, щоб запам’ятати і зацікавитись. Звичайно, число 7 не є константою, але воно показує, що залучення нових клієнтів — не така проста задача, як здається. І саме цим ви займаєтесь на етапі Аквізішену.
Активація або Activation (A) — на цьому стейджі ви працюєте над активацією користувача. Головна ціль етапу це переведення звичайного відвідувача в активного користувача.
Повернення юзерів або Retention (R) — очевидно, що через певний час користувачі можуть забути про ваш продукт або сервіс. Тут стане в нагоді саме ретеншен для того, щоб перевести юзера зі сплячого режиму в режим активного користування. Адже нас, як дизайнерів, цікавить крім класного досвіду користувача, ще забезпечення отримання постійного прибутку. Тому давайте повертати юзерів і мотивувати їх і далі користуватись ним.
Рекомендації або Referral (R) — цей етап взаємодії відображає наскільки користувачі готові рекомендувати вас своїм друзям та знайомим. Класно коли ваші користувачі настільки задоволені, що стають адептами вашого сервісу та рекламують вас на всіх форумах, в соцмережах, тощо. Якщо це так, то допоможіть їм в цьому і вони залучать вам нових юзерів за допомогою реферальних програм, реферальних кодів, тощо.
Дохід або Revenue (R) — очевидно, що цей пункт відповідає на питання «наскільки користувачі готові вам платити», скільки грошей вони приносять, тощо. В роботі на цьому стейджі вам стане в пригоді згадана раніше Юніт Економіка.

Для кожного з етапів взаємодії про які я вже вам розповів (Залучення/Активація/Повернення/Рекомендації/Дохід) ви повинні пропрацювати 2 важливих моменти:

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

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

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

Service Blueprint (SB)

Майже всі дизайнери вміють працювати з досвідом користувача за допомогою Customer Journey Map (CJM), яку винайшли в 1985 році Чіп Бел та Рон Земке. Потім CJM перекочував з маркетингу в дизайн і зараз це одна з найбільш популярних дизайн-активностей, а сама складена CJM є певне найпопулярнішим та найкориснішим артефактом роботи UX-дизайнера.
Очевидно, що CJM це обов’язкова активність, за допомогою якої UX дизайнер фіксує проблеми взаємодії користувача та продукту. Але в стартапі важливо бачити ВСЮ картину глобально. Тобто не тільки дії користувача, ай й дії продукту, адже під капотом сервісу можуть відбуватись важливі події, які впливатимуть і на досвід користувача. І дуже часто саме на стороні продукту може бути проблема. Саме для таких ситуацій стане в нагоді Service Blueprint.

SB — це техніка, що використовується в сервіс дизайні. Цю техніку винайшла та вперше описала в Harvard Business Review в далекому 1984 році банкір та інвестор Лін Шостак. А сьогодні цим інструментом, як надбудовою над вищезгаданим CJM, вже користуються UX дизайнери у всьому світі. Так що ж за Сервіс Блюпрінт — давайте розбиратись разом.
Головними перевагами використання SB є:

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

Як я вже згадав вище, SB це надбудова над CJM. Тож він має кілька ключових елементів:

Дії Користувача Тут описуються дії юзера для проходження його основного флоу в вашому продукті. Звісно основними флоу можна вважати ті, які пов’язані з монетизацією та залученням користувача. В класичному Service Blueprint під діями користувача розуміється саме флоу — тобто кроки с вашої CJM, хоча на мою особисту думку, оптимальним є використання всього CJM на цьому кроці, так як він віддасть вам повну інформацію (тобто затягуйте в ваш SB ще дії, думки, слова користувача та можливості покращення на кожній фазі). Щоб трошки краще розібратись що я маю на увазі, я вам нагадаю Офіційний темплейт для складення CJM від NNGroup.
Frontstage Actions Сорі за чергові англіцизми, але під Фронтстейджем маються на увазі дії продукту, які може бачити користувач безпосередньо. Якщо ми говоримо про цифровий продукт, то сюди можуть бути враховані взаємодія «людина-людина» або «людина-компьютер». До дій людина-людина відносяться взаємодії користувача з контактною особою продукту (наприклад в ресторані ви взаємодієте з офіціантом, який є представником бізнесу). А до дій людина-компьютер, очевидно, взаємодія з технологією (наприклад апка на мобільному телефоні, банкомат, ibox, тощо). Наприклад при замовленні піци чи суші, ви (як клієнт) взаємодієте з сайтом або апкою (де робите замовлення) та курєром. Це і є Фронтстейдж — ви бачите як кур’єр привозить вам суші і сприймаєте його як представника сервісу.
Backstage actions На етапі Бекстейджу відбуваються вже ті процеси сервісу, які приховані від користувача. Тобто те, чого юзер побачити не в змозі. Ніби залаштунками. У прикладі з суші — це обробка вашого замовлення, приготування вашого сету, його пакування, тощо. Ви, як користувач, здогадуєтесь що хтось робить цю роботу, але не знаєте точно. Але якщо ви є дизайнером в такому продукті, вам бажано описати ці процеси, так як вам вони доступні. І ще особиста порада-лайфхак від мене: якщо ваш проект надає товар або послугу, після того як складете Service Blueprint зі слів всіх задіяних служб, спробуйте скористатись вашим сервісом як користувач. Таким чином ви побачите недоліки особисто, адже ваші мейти могли трошки прибрехати ідеалізувати певні процеси, а це може заафектити досвід користувача, а як наслідок і бізнес.
Процеси Це певні додаткові сервіси та взаємодії, які відбуваються для підтримання працездатності Backstage та Frontstage. Ці сервіси можуть бути як інхаузні (внутрішні) так і зовнішні сервіси. Наприклад для нормальної роботи продукту може бути необхідним маркетинговий відділ — він не задіяний напряму в надання послуги, але без цього конкретного відділу робота продукту неможлива. Це є прикладом внутрішнього сервісу підтримки. Також вам може знадобитись служба інкасації — цю послугу вам надасть ваш банк-контрагент і це є прикладом зовнішнього сапорту.
Evidence Це певні свідчення взаємодії користувача з компанією або сервісом, точки взаємодії, тощо. Сюди відносяться артефакти взаємодії (чек про оплату, квитанція, заявка на товар, тощо) та точки взаємодії (сайт, лист, мобільний застосунок, тощо).
Час Для кожного етапу вашого Service Blueprint бажано проставляти час взаємодії юзера з продуктом. Звісно, якщо ви тільки розробляєте продукт, то цей час буде дуже приблизний та розрахований теоретично, але якщо сервіс вже запущений, то час бажано фіксувати реальний, роблячи періодичні контрольні тестові закупки.
Метрики На кожному етапі взаємодії користувача можна вимірювати певні метрики, які демонструватимуть успішність того чи іншого етапу. І тут вам знову ж таки стане в нагоді AARRR.

Після мапування продукту за допомогою Service Blueprint, ви як дизайнер отримаєте максимально повну інформацію про взаємодію користувача з вашим продуктом і тому раджу періодично оновлювати складені вами артефакти через кілька завершених спринтів. Звичайно, не завжди реліз кардинально змінює UX вашого продукту, але коли це відбувається, намагайтесь зафіксувати ці зміни в оновленому артефакті, щоб потім була можливість порівняти динаміку змін. Саме тому дуже корисно буде завести в вашій Jira певний спейс, де знаходитимуться всі дизайнерські артефакти, з якими ви працюватимете.

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

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

П.С. Якщо вам сподобалась моя стаття і якщо вам хочеться віддячити і допомогти мені особисто — зробіть донат на ЗСУ. Я буду задоволений і знатиму, що витратив час не дарма!

ATTENTION
Більше цікавих статей ви можете почитати на моєму персональному Medium та на XD Community Medium.

Презентація: Як бути почутим

Євген Олексюк — Fri, 19 May 2023 09:37:17 +0000

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

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

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

Висновок простий — крім того, що дизайнер повинен вміти робити дослідження, малювати гарну UI та взаємодіяти з командою, супер-важливим скілом є саме вміння класно презентувати результати роботи. Як каже один мій знайомий дизайнер “Треба продати ідею”. І як саме її продати, пропоную сьогодні розібратись, як ми любимо — по-задротськи. 🥸

Якщо ви не хочете читати статтю далі, то ось вам головна теза:
Щоб змусити людей вас слухати, треба їм говорити правду у вигляді історії та супроводжувати все віжуалом!

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

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

Щоб донести свою думку, вам необхідно говорити та показувати, адже:

Правда привертає увагу слухача;
Історія викликає розуміння та дозволяє емпатувати;
Графічна частина утримує фокус слухача та не дозволяє відволіктись.

💡 ПРАВИЛО 1: Говоріть правду!

Ми пізнаємо правду не тільки розумом, а й серцем.
Блез Паскаль

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

Інтелектуальна правда — Наша голова каже: “Я думаю, що це правда”
Емоційна правда — Наше серце каже: “Я вірю, що це правда”
Фактична правда — Інформація, яка в нас є, каже: “Факти підтверджують, що це правда”

Не всі види правди є рівноцінними, адже речі, у які ми ВІРИМО, важливіші за речі, які ми ЗНАЄМО і найменш важливими є саме ФАКТИ. Тому:

Вдала презентація дає змогу ділитися новою інформацією
Прекрасна презентація змінює те, що ми знаємо
Надзвичайна презентація змінює те, у що віримо

Як дизайнери, ми вже знаємо, що в будь-якому продукті завжди є цільова аудиторія з своїм певним набором pains/gains. Це ті люди, до яких ми апелюватимемо і чию увагу намагатимемось захопити, чиї проблеми будемо закривати за допомогою продукту. Тож коли ми готуємось до презентації, варто використати цей підхід і зрозуміти, хто буде наша ЦА під час презентації. Хто вони — ті люди, яким ми розповідатимемо, що їм важливо і чого вони очікують? Тут вам стане у нагоді ваша мапа стейкхолдерів і опис кожної ключової особи.

Дуже доречним тут буде нагадати, щодо кількох психологічних особливостей, які треба приймати до уваги, коли ви досліджуватимете вашу ЦА:

Люди не люблять, коли їм вказують, що робити, але всі люблять, коли їх ідеї підтримуються. Тож не будьте занадто наполегливим, а “ведіть аудиторію за ручку” і мʼяко підштовхніть до потрібних висновків. Це дуже схоже на роботу психолога — хороший психолог не скаже вам, що треба робити — він поставить вам потрібні питання та ви самі прийдете до необхідних і правильних висновків.
Не йдіть на поводі ваших стейкхолдерів. Не намагайтесь їм догодити і підтвердити всі тези замовника, а мʼяко пояснюйте та донесіть свою думку, адже саме для цього презентації і відбуваються.
Не презентуйте, якщо вам немає чого розповісти нового. Очевидні речі, звичайно ж, проговорювати корисно, але скликати мітинг на 20 людей для цього — не логічно.

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

Усі презентації враховують 3 головні елементи:

Моя ідея: думки, враження, факти, історії, ідеї, проблеми…
Тут важливо розуміти що саме ви хочете сказати? Яка моя ідея?
Я: моя мета, мої надії, погляди, тривоги, відкриття…
Тут важливо — як мене сприймають? Яке враження мені потрібно справити?
Моя аудиторія: склад, досвід, уміння, навички, приховані цілі, мрії, невідомі чинники…
Тут важливо зрозуміти: Хто моя цільова аудиторія? Про що думають люди, які мене слухатимуть? Що їх цікавить?

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

💡 ПРАВИЛО 2: Розповідайте історію!

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

Кожна презентація по суті є оповіддю. А в оповіді є 3 простих правила:

Вона не може тривати нескінченно
Вона не заплутує слухача
Вона не містить випадковостей

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

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

Звіт За допомогою звіту ми змінюємо ту інформацію, яка є в аудиторії. До звітів можна віднести:

Нарада з поточних питань
Фінансовий звіт
Квартальний звіт
Презентація проекту

Пояснення За допомогою пояснення ми даємо аудиторії нові знання та можливості. До пояснень відносяться:

Наукова робота
Кулінарне шоу
Лекція в університеті

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

Співбесіда
Комерційна пропозиція
Запуск нового продукту

Драма За допомогою драми ми змінюємо погляди нашої аудиторії. Драма мотивує та впливає на емоції. Прикладами драми є:

Напутня промова
Проповідь
Виступ на TED Talks

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

Як побудувати оповідь?

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

ЗВІТ

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

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

Чому
Хто і Що
Де
Коли
Як
Скільки

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

ПОЯСНЕННЯ

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

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

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

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

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

ПРОПОЗИЦІЯ

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

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

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

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

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

ДРАМА

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

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

Структуру драми легко зрозуміти, згадавши будь-яку голівудському пригодницьку стрічку:

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

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

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

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

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

Не перевантажуйте слайд інформацією. Ідеальний слайд містить:

Заголовок
Графічне зображення
Короткий текст
Нічого більше

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

💡 ПРАВИЛО 3: Нехай історія буде з картинками!

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

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

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

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

Виходячи з логіки ми бачимо, що важливими атрибутами візуалізації є:

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

Хто / Що відображається за допомогою Портрета
Скільки відображається за допомогою Діаграм
Де відображається за допомогою Карт
Коли відображається за допомогою Часової шкали
Як відображається за допомогою Блок-схем
Чому відображається за допомогою Рівностей

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

Фотографії
Фотографії — це найпростіший метод візуалізації — їх легко найти на різних сайтах накшталт unsplash, pexels, shutterstock. Але їх проблема в тому, що оригінальні фото знайти дорого, вони будуть відволікати аудиторію, а головне — вам важко буде підтримувати консистентність презентації.
Графіка
Ілюстрації більш вдалий вибір — їх достатньо легко знайти на безкоштовних та платних стоках. Тут вам в нагоді стануть freepik та shutterstock. Але проблемами графіки є: відсутність консистентності, обмежений вибір класних сетів іллюстрацій.
Малюнки
Це найкращий варіант. Складність полягає в тому, що не кожен UX дизайнер вміє малювати, але завжди можна спробувати і отримати живу класну картинку, або ж попросити допомоги в UI дизайнера або ілюстратора. Тоді ваша презентація буде приємна, не відволікати від слів спікера та головне — малюнки не будуть виглядати штамповано та попсово. І при цьому малюнок буде передавати необхідну емоіцію.

Ідеальне зображення — це проста візуалізація вашої ідеї в легкій для сприйняття формі. Не більше і не менше!

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

💡 ПРАВИЛО 4: Не хвилюйтесь!

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

За шкалою страху, спікерів можна поділити на 3 групи:

Ізі-пізі спікер
Ви не відчуваєте дискомфорту. Виступити публічно для вас так саме легко, як зробити собі чай. Більше того, під час ви навіть кайфуєте. Вітаю, в вас немає проблем, адже ви природжений спікер.
Тривожний
Ви почуваєтесь невпевнено коли треба доносити свою думку, долоні пітніють, але при цьому ваш мозок може справлятись зі стресом. Для таких людей найкращою порадою буде — ПЛАНУЙТЕ. Планування та проговорення всіх ситуацій наперед (що і чому може піти не так) зменшить ваш страх і ви почуватиметесь впевнено.
Панікер
Ви категорично не хочете виступати публічно. Під час виступу ваш мозок працює дуже погано, ви не контролюєте ситуацію і відчуваєте дискомфорт фізично. Це складна ситуація і щоб полегшити ваш стан, робіть драй-рани — навчіть себе виступати. Адже практика дозволить вам набити руку і ви плавно перейдете з категорії “Панікер” в категорію “Тривожний” і потім в “Ізі-пізі спікер”.

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

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

Плануйте ваш виступ. Планування завжди знижує рівень тривоги.
Уявіть собі найгіршу ситуацію. Якщо ви можете змоделювати найгіршу ситуацію і знатимете як з неї виходити, то ви будете готові до цього. А якщо ця ситуація не відбудеться, то вам же буде краще.
Якщо вам важко опанувати свій страх — зізнайтесь в цьому на початку. Люди вас зрозуміють і будуть поблажливіші.
Якщо ви плануєте виступ оффлайн — прийдіть в локацію, перевірте там акустику, проектор, клікер, знайдіть комфортні місця на сцені (2–3 буде оптимально). Так ви будете вже знайомі з залом.
Якщо ваш виступ планується онлайн, перевірте ваш роутер, підключення, підготуйте мобільний телефон, щоб роздавати з нього інтернет в разі зникнення звʼязку, перевірте ZOOM або іншу платформу, в якій відбуватиметься мітинг.
Потренуйтесь перед презентацією. Вам буде значно легше, якщо ви проговорите презентацію зазделегідь.
Намагайтесь встановити зоровий контакт з аудиторією.
Дихайте. Не варто робити гіпервентиляцію, але глибоке дихання знизить ваш страх перед виступом.
Не тараторьте. Говоріть достатньо повільно, щоб ваша аудиторія встигала розуміти все, що ви розповідаєте.
Шуткуйте. Це зніме напругу в разі занадто довгого спіча, поверне аудиторію, якщо вона втомилась і просто підніме настрій. Але давайте будемо реалістами — зашкварні жарти відпускати не варто.

Сподіваюсь моя стаття допоможе зробити ваші презентації більш професійними, а вам відчувати менше страху під час та після презентації. Тож вдалих вам виступів і до нових зустрічей в рубриці #задротствозбородатим 😂❤️🇺🇦

В статті частково використані матеріали з книги Дена Роума “Говори та показуй”. Використання матеріалів письмово погоджено з видавництвом “Vivat” 09.05.2023.

ATTENTION
Більше цікавих статей ви можете почитати на моєму персональному Medium та на XD Community Medium.

Швидка оцінка вашого інтерфейсного рішення без залучення цільової аудиторії. Великий гайд

Євген Олексюк — Wed, 11 Jan 2023 08:15:41 +0000

Якщо ви щось вже знаєте про дизайн, то напевне вас не налякати такими словами як: “дизайн процес”, “дизайн-мислення”, “human centered design”, “дивергентно-конвергентний процес”, “double diamond” чи “lean UX”. Ви розумієте навіщо існує певний процес побудови продукту. Процес дуже простий і логічний: він зводиться до спроб та помилок.

Візьмемо такий улюблений всіма Double Diamond. Фактично, в цей процес зашиті всі базові активності, які є і в інших методологіях. І не важливо чим саме ви користуєтесь — Design-Thinking чи Double Diamond, загальний процес однаковий.

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

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

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

І все на світі треба пережити,
І кожен фініш — це, по суті, старт
Ліна Костенко

Це прям про ваш дизайн-процес. Усі активності треба пережити і кожен спрінт-реліз — це, по суті, старт 😂.

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

Але бувають ситуації, коли немає ресурсу на активності (а отже збільшується ризик):

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

І що робити в такому випадку? Треба дизайнити і терміново завдавати невиправної користі, а ресурсу прям взагалі нема.

Тут вам станеться в нагоді так звана оцінка юзабіліті БЕЗ КОРИСТУВАЧА! Non-User Usability Evaluation призначена для швидкої оцінки вашого інтерфейсного рішення без залучення цільової аудиторії. Звичайно ж, ніщо не замінить інтервью та тестування, але якщо відштовхнутись від твердження, що всі ми живі люди, то можна спробувати скласти певні правила, які однаково валідні для кожної людини.

Евристики Якоба Нільсена

Це найпопулярніший метод оцінки, про який знає кожен починаючий дизайнер. Остаточний список правил було складено в 2005 році Якобом Нільсеном — доктором наук наукового напрямку людино-комп’ютерної взаємодії Технічного університету Данії в Копенгагені, засновником компанії Nielsen Norman Group, “королем юзабіліті”, “гуру юзабіліті вебсторінок” та новим піонером медіа. Правила почали називати Евристиками через те, що вони є широкими імперичними правилами, валідними для більшості юзерів.

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

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

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

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

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

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

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

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

08. Естетичність та мінімалістський дизайн
Сторінки та діалогові вікна не повинні містити недоречної та зайвої інформації. Кожна додаткова одиниця інформації конкурує з потрібними одиницями інформації та понижує їхню відносну видимість.
Ця евристика не означає, що ви повинні використовувати лише flat design — вона про те, що ви зосереджуєте увагу користувача на головному. Переконайтеся, що візуальні елементи інтерфейсу відповідають основним цілям юзера.

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

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

🤓 На цьому напевне можна і зупинитись, адже Евристики Нільсена знають майже всі, але пропоную розібратись в темі до самого кінця. Тож погнали з бородатим UX-задротом в чудовий світ прагматичності та прискіпливості 😂

8 золотих правил Шнейдермана

Бен Шнейдерман — це американський вчений з інформатики та професор Університету Human-Computer Interaction Lab в Меріленд. Його роботи можна порівняти з іншими сучасними мислителями дизайну, такими як Дон Норман та Якоб Нільсен. В 1986 році в своїй популярній книзі «Проектування інтерфейсу користувача: стратегії ефективної взаємодії людини з комп’ютером» Шнейдерман розкриває свої 8 золотих правил дизайну інтерфейсу:

01. Прагніть консистентності
Прагніть консистентності, використовуючи знайомі іконки, кольори, ієрархію, call to action та юзер флоу під час розробки однакових та/або схожих ситуацій. Стандартизація способів передачі інформації гарантує, що користувачі зможуть застосовувати розуміння інтерфейсу в вашому продукі, без необхідності навчати юзерів як цим інтерфейсом користуватись. Консистентність відіграє важливу роль, допомагаючи користувачам ознайомитися з вашим продуктом, щоб вони могли легше досягати своїх цілей.

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

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

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

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

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

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

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

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

Критерії Юзабіліті

Згідно Міжнародної Організації зі Стандартизації [SOURCE: ISO 9241‑210:2010, definition 2.13]:

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

Якщо спростити, то найбільш зрозумілим і широковживаним є визначення юзабіліті від NNGroup: Nielsen Norman Group:

Юзабіліті — це якісний показник, що оцінює, наскільки інтерфейс є простим у використанні.

Юзабіліті визначається 5 компонентами:

Навченість (або здатність до навчання): наскільки легко користувачеві виконувати свої завдання, коли він вперше взаємодіє з інтерфейсом?
Ефективність (або результативність): як швидко користувач може виконати завданняв інтерфейсі?
Запам’ятовуваність: як швидко користувач відновить навичку взаємодії з інтерфейсом після певного періоду некористування ним?
Помилки: скільки помилок користувач робить, наскільки вони серйозні та як легко їх можна виправити?
Вдоволеність (або задоволеність): Наскільки юзеру приємно користуватися дизайном? Також важливо памятати про такий атрибут як Утилітарність (або корисність). Саме поєднання Утилітарності та Юзабіліті є важливим.

Утилітарність — визначає чи користувачеві надається потрібний/необхідний функціонал
Юзабіліті — визначає, наскільки легко та приємно використовувати запропонований функціонал
Користь = Утилітарність + Юзабіліті

Враховуючи все вищеперераховане, виділяють 6 основних критеріїв юзабіліті:

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

02. Ефективність (Efficient)
Даний критерій описує саме ефективність — як система підтримує користувачів у виконанні завдань. Цей критерій допомагає переконатися, що продукт виконує завдання таким чином, щоб мінімізувати час та інші ресурсовитрати користувача.

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

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

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

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

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

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

06. Безпечність (Safety)
Цифрові продукти повинні гарантувати безпеку користувача та не завдавати йому шкоди.

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

Також існує ще 2 додаткових (не основних) критерія:

🥸 Ергономічність (Ergonomics)
Цей критерій є додатковим і його виконання не є обовязковим. Під ергономічністю мається на увазі зручність та ергономічність самого пристрою, за допомогою якого користувач взаємодіятиме з цифровим продуктом. Наприклад, ви розробляєте мобільний застосунок — в такому разі максимально якісний безшовний експірієнс ваш користувач отримає при взаємодії з вашим застосунком через якісний ергономічний дивайс, що відповідає теперішнім вимогам ринку. Погодьтесь, що легше купити нові New Balance через апку на вашому останньому iPhone, аніж через квадратний Alcatel 2014 року виробництва 😂

🥸 Доступність (Accessibility)
Це окрема тема, з якою треба розбиратись окремо. Але якщо коротко — дизайн повинен бути доступним для всіх людей, в тому числі з певними обмеженнями. Дуже часто аксесабіліті передбачає, що якщо дизайн виконано з урахуванням вимог WCAG, то ним буде легко користуватись не тільки людям з вадами та обмеженнями, а і звичайним користувачам. Уявіть що ви купляєте кроси з прикладу вище ввечері, коли їдете в метро після роботи. Для ваших втомлених очей виконані вимоги з доступності будуть тільки приємним бонусом.

21 закон UX дизайну

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

Закон Якоба: Користувачі проводять більшу частину свого часу на інших веб-сайтах, і вважають за краще, щоб ваш сайт працював так само, як інші сайти, які вони вже знають
Закон Фіттса: Час, необхідний досягнення мети, залежить від відстані до мети та її розміру
Закон Хіка: Час, необхідний для прийняття рішення, збільшується зі зростанням кількості та складності наявних варіантів
Закон Міллера: Середньостатистична людина може зберігати у своїй робочій пам’яті лише 7 (±2) елементів
Закон Постеля (Принцип Стійкості): Будьте консервативними в тому, що ви робите, і будьте ліберальні в тому, що ви приймаєте від інших
Правило оцінки на піку та в кінці: Люди судять про свій досвід головним чином на основі того, що вони відчували на його піку чи в кінці, а не за підсумковою сумою або середнім значенням кожного моменту свого досвіду
Ефект естетики в юзабіліті: Користувачі часто сприймають естетично приємний дизайн як дизайн, який зручніший у використанні
Ефект фон Ресторфф: Коли є кілька схожих об’єктів, то швидше за все запам’ятається той, який відрізняється від інших
Закон Теслера (закон збереження складності): В будь-якій системі існує певний ступінь складності, який не можна зменшити
Поріг Доерті: Продуктивність зростає, коли комп’ютер та його користувачі взаємодіють у певному темпі (менше 400 мс), що забезпечує стан, при якому жоден з них не повинен чекати на іншого
Ефект градієнта мети: Тенденція наближення до мети зростає з близькістю мети
Закон загального регіону: Елементи, як правило, сприймаються як групи, якщо вони поділяють область з чітко визначеним кордоном
Закон близькості: Об’єкти, що знаходяться поруч або в безпосередній близькості один від одного, сприймаються користувачем як одна група
Закон Прегнанца: Люди сприймають та інтерпретують складні зображення як найпростішу можливу форму, тому що саме інтерпретація вимагає найменших когнітивних зусиль
Закон подоби: Людське око сприймає схожі елементи як цільну картину, форму або групу, навіть якщо ці елементи розділені
Закон рівномірної пов’язності: Елементи, які є візуально об’єднаними, краще сприймаються як пов’язані, ніж елементи без візуального зв’язку
Бритва Оккама: Серед конкуруючих гіпотез, слід вибрати ту, у якій найменша кількість припущень
Принцип Парето: Для більшості випадків 20% зусиль дають 80% результату
Закон Паркінсона: Будь-яке завдання буде збільшуватися доти, доки не буде витрачено весь доступний для її вирішення час
Ефект серійної позиції: Користувачі схильні найкраще запам’ятовувати перший та останній елементи в серії
Ефект Зейгарник: Користувачі запам’ятовують незавершені або перервані завдання краще, ніж завершені

7 принципів Дона Нормана

Дон Норман є одним з найбільших апологетів юзабіліті в світі. Він є співзасновником згаданої вище компанії Nielsen Norman Group, директором Лабораторії Дизайну в Каліфорнійському університеті в Сан-Дієго, дослідником, письменником та багато іншого. Більша частина робіт Нормана передбачає пропаганду розробки, орієнтованої на користувача. Так у всесвітньовідомій книзі, яка зараз є мастрідом будьякого дизайнера “The Design of Everyday Things” 1988 року видання, Норман сформулював 7 принципів дизайну:

Аффорданс (Affordance)
Концептуальна модель (Conceptual model)
Обмеження (Constraints)
Досліджуваність (Discoverability)
Зворотній Зв’язок (Feedback)
Мапінг / Картографування (Mapping)
Сигніфікатори (Signifiers)

01. Аффорданс
Аффорданс — це певна дія та/або властивість об’єкта, які допомагають нам визначити його функціонування. Дональд Норман стверджує: «Термін аффорданс стосується відносин між об’єктом та людиною». Наприклад, конструкція дверної ручки пов’язана з її передбачуваною дією; отже, форма слідує за функцією (Louis Sullivan: «Form Follows The Function»).

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

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

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

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

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

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

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

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

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

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

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

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

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

Норман описує хорошу досліджуваність так: «можна визначити можливі дії та поточний стан пристрою». Чіткі фокуси (call to action, зображення та текст); візуальна ієрархія (контент структурований та приорітезований); прозора навігація — все це забезпечує хорошу досліджуваність і розуміння дизайну.

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

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

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

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

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

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

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

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

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

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

07. Сигніфікатори
Сигніфікатори повідомляють користувачам, де повинна відбуватись дія. Дональд Норман пояснює: «Термін «сигніфікатор» стосується будь-якого візуального, звукового чи іншого помітного знаку, який взаємодіє з людиною».

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

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

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

Принципи Брюса Тогняцціні

Брюс “Tog” Тоньяцціні — американський юзабіліті консультант та дизайнер. Він є партнером в Nielsen Norman Group, який спеціалізується на взаємодії людини з комп’ютером. Чотирнадцять років він працював в Apple Computer, потім чотири роки в Sun Microsystems, потім ще чотири роки в WebMD. Брюс Тоньяцціні є автором двох книг: “Tog on Interface” та “Tog on Software Design” та публікує веб-журнал Asktog із слоганом «Interaction Design Solutions for the Real World».

Тог сформулював принципи, за допомогою яких можна оцінити юзабіліті:

01. Естетика
Принцип: Естетичний дизайн слід залишити тим, хто має освіту та має навички його застосування — графічним/візуальним дизайнерам

Принцип: Мода ніколи не повинна переважати над зручністю використання

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

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

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

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

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

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

03. Автономність
Принцип: Комп’ютер та інтерфейс «належать» користувачеві, але це не означає, що порібно відмовитись від правил та обмежень.

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

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

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

Принцип: Надавайте відповідальний контроль.

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

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

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

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

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

Принцип: Переконайтесь, що інформація про статус точна.

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

04. Колір
04.1. Дальтонізм
Принцип: Кожен раз, коли ви використовуєте колір для передачі інформації в інтерфейсі, ви також повинні використовувати чіткі вторинні підказки, щоб передати інформацію для людей з обмеженнями сприйняття кольорів.

Сьогодні більшість людей мають кольорові дисплеї. Однак приблизно 10% чоловіків і менше 1% жінок мають певну форму дальтонізму. Цей момент треба враховувати в проектуванні інтерфейсу!

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

Знайдіть час протестувати ваш веб-сайт на сервісах Enably та Colblindor.

04.2. Колір як життєво важливий елемент інтерфейсу
Принцип: Не нехтуйте кольором в інтерфейсі тільки тому, що не всі користувачі можуть їх бачити.

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

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

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

05. Консистентність
05.1. Рівні консистентності
Принцип: Дотримуйтесь консистентності згідно необхідного рівня.

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

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

05.2. Індукована неконсистентність
Принцип: Важливо бути візуально та інтерактивно послідовним.

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

05.3. Послідовність
Принцип: Прагніть до послідовності та неперервності в часі, а не консистентності.

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

05.4. Відповідність очікуванням користувачів
Принцип: «Найважливіша консистентність — це відповідність очікуванням користувачів» — Вільям Бакстон

06. Дефолти (Дії за замовчуванням)
Принцип: За дефолтом текст в полях повинен легко видалятись.

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

Принцип: Параметри за замовчуванням повинні бути «розумними» та швидко реагувати.

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

Принцип: Змінюйте вираз «за дефолтом» на більш зрозумілий користувачу термін.

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

Принцип: Текстовки та віжуал повинні відображати масштаби реверсії.

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

07. Досліджуваність
Принцип: Будь-яка спроба приховати складність призведе до її збільшення.

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

Принцип: Якщо користувач не може чогось знайти, значить цього не існує.

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

Принцип: Використовуйте активні нагадування, щоб направляти користувача.

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

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

Повідомлення може мати форму підказки «Чи знаєте ви…», яку ви показуєте під час запуску.

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

Принцип: Не існує жодного винятку щодо видимості.

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

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

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

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

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

Принцип: Прагніть балансу

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

Принцип: Завжди тестуйте ваші рішення щодо досліджуваності.

Будьяку помилку можна попередити, якщо провести коротке тестування, тож не нехтуйте тестами.

08. Ефективність користувача
Принцип: Слідкуйте за продуктивністю користувача, а не комп’ютера.

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

Принцип: Займіть користувача.

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

Принцип: Щоб максимізувати ефективність бізнесу, потрібно максимізувати ефективність усіх, а не лише ефективність ІТ-відділу.

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

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

Повідомлення про помилки повинні:

Пояснювати, що трапилось
Підказувати користувачеві, що як діяти далі

«Помилка №1264.А38» нічого не розповість користувачеві. Розмовляйте з користувачем користувацькою мовою та допомогайте.

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

Підказуйте та контролюйте юзерів, надавайте їм знаки, підказки та допомогу.

Принцип: Інколи потрібно забезпечити проторований шлях.

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

Принцип: Запропонуйте користувачам сигнали для відчуття «дому».

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

Принцип: Зробіть дії зворотними.

Принцип: Завжди дозволяйте «Відмінити».

Принцип: Завжди залишайте юзерам аварійний вихід.

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

10. Закон Фіттса
Принцип: Час, необхідний досягнення мети, залежить від відстані до мети та її розміру.

Принцип: Час, необхідний досягнення кількох цілей є сумою часу досягнення кожної окремої цілі.

Принцип: Закон Фіттса діє незалежно від типу пристрою чи цілі.

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

Принцип: Об’єкти інтерфейсу можна побачити, почути, відчути чи іншим чином сприйняти.

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

Принцип: Об’єкти інтерфейсу мають стандартний спосіб взаємодії.

Тут все просто — кнопки повинні натискатись, повзунки перетягуватись, тощо.

Принцип: Об’єкти інтерфейсу мають стандартну кінцеву поведінку.

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

Принцип: Об’єкти інтерфейсу повинні бути зрозумілими, самоузгодженими та стабільними.

Принцип: Використовуйте новий об’єкт, якщо ви хочете, щоб користувач взаємодіяв з ним якось по-новому.

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

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

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

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

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

Підтверджуйте всі взаємодії візуальним або звуковим відгуком протягом 50 мілісекунд;
Обʼєднуйте кілька натискань однієї кнопки чи об’єкта.

Принцип: Інформуйте користувача про затримку.

Принцип: Зробіть початок швидким.

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

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

Принцип: Обмежте компроміси.

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

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

Принцип: Уникайте тестування лише на навченість.

14. Метафори
Принцип: Обирайте метафори, що дозволять користувачам зрозуміти найдрібніші деталі концептуальної моделі.

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

Принцип: «Оживіть» метафори, звертаючись до сприйняття людей — зору, звуку, дотику, тощо.

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

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

Принцип: Якщо метафора обмежує вас, відмовтеся від неї.

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

15. Захищайте результати роботи користувачів
Принцип: Гарантуйте, що користувачі ніколи не втратять свої напрацювання.

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

16. Читабельність
Принцип: Текст, який необхідно прочитати, повинен мати високий контраст.

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

Принцип: Приорітизуйте текст за допомогою розміру.

Принцип: Меню та кнопки повинні містити спочатку ключове слово(а).

Принцип: Тестуйте всі проекти на вашій найстаршій цільовій аудиторії.

Принцип: Часто існує зворотний зв’язок між «красотою» шрифту та його читабельністю.

17. Простота
Принцип: Тримайте баланс між простотою встановлення та простотою використання.

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

Принцип: Уникайте «ілюзії простоти».

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

Принцип: Використовуйте Прогресивне Виявлення, щоб вирівняти криву навчання.

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

Принцип: Не спрощуйте за рахунок необхідного.

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

18. Відстежування станів
Принцип: Намагайтесь трекати та відстежувати стани за необхідності

Наші системи повинні «знати»:

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

Ця інформація допоможе в подальшій взаємодії з юзером.

Принцип: Інформація про стан повинна зберігатися в зашифрованому вигляді на сервері навіть після виходу з системи.

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

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

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

19. Наглядна навігація
Принцип: Зробіть навігацію видимою.

Більшість користувачів не можуть і не збираються будувати складні ментальні карти, і, як і очікується, вони загубляться або втомляться. Спростіть життя користувачам, організувавши зручну навігацію. Наприклад, ви можете використовувати хлібні крихти:
NN/g Home > AskTog > Interaction Design Section

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

Принцип: обмежте кількість екранів за допомогою оверлеїв.

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

👨‍💻 Брюс Тогняцціні склав прекрасний перелік правил. На мою особисту думку він максимально-повний та розширений поясненнями. Але для його використання, треба бути трошки задротом 😂

Принципи зниження когнітивного навантаження при проектуванні інтерфейса

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

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

Завелика кількість варіантів для вибору
Необхідність багато думати, щоб взаємодіяти з інтерфейсом
Неясність інтерфейсу

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

Питаннями когнітивного навантаження займався Джон Яблонські і в 2015 році оформив свої відкраиття в Принципи зниження когнітивного навантаження при проектуванні інтерфейса:

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

02. Використовуйте шаблони проектування
Використовуючи шаблонні рішення в проектуванні, ви говорите з користувачаим знайоми елементами інтерфейсу, які юзери вже бачили раніше і вже розуміють. Це, в свою чергу, зменшує когнітивне навантаження, таким чином дозволяючи їм рухатися правильно та наближатися до досягнення своєї цілі. Щоб краще орієнтуватись в існуючих вже рішеннях дизайну є Design Patterns на CodePen та Blueprint Archives на Codrops.

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

04. Мінімізуйте вибір
Раніше ми вже зробили висновок, що наша робоча пам’ять обмежена. Коли перед вами надто багато варіантів вибору, когнітивне навантаження зростатиме через так званий “параліч прийняття рішень”. Важливо, щоб ми звели до мінімуму вибір, який користувач повинен зробити в будь-який момент, особливо в таких місцях, як навігація, форми та спадаючі меню.

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

06. Прагніть читабельності
Зробити контент розбірливим недостатньо — потрібно зробити його читабельним! Це означає, що типографіка повинна бути естетично привабливою, відповідати вмісту та легко читатися, тоді як дизайн залишається відносно непомітним. Роблячи це, ми можемо забезпечити якомога менше відволікань для користувача, що призводить до кращого розуміння тексту користувачем.

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

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

Висновки:

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

Евристики Якоба Нільсена;
8 золотих правил Шнейдермана;
6 критеріїв юзабіліті;
21 закон UX дизайну;
7 принципів Дона Нормана;
Принципи Брюса Тогняцціні;
Принципи проектування для зниження когнітивного навантаження.

Особисто я раджу використовувати або принципи Брюса Тогняцціні (якщо вам стало терпцю з ними розібратись), або легший варіант — зв’язка Евристики Якоба Нільсена + базові закони UX дизайну.

Сподіваюсь моя маленька статейка виявилась для вас корисною і до нових зустрічей в рубриці #задротствозбородатим 😂❤️🇺🇦

ATTENTION
Більше цікавих статей ви можете почитати на моєму персональному Medium та на XD Community Medium.

Метод • Причина • Ціна. Підхід, який дозволяє зробити ваше дизайн-рішення більш свідомим та зменшити ризики

Євген Олексюк — Sun, 27 Nov 2022 10:22:08 +0000

Сьогодні хочу трошки розповісти про мій улюблений підхід, який особисто я використовую в роботі щодня. Я назвав це Method • Reason • Price підхід. Не можу сказати що авторство належить мені, але поки що я не знайшов опису цього методу деінде 😊

В дизайн комьюніті дуже популярне питання “Шоб шо?”. Адже дизайнер повинен розуміти навіщо робить той чи інший таск, яку проблему він вирішує і який результат хоче досягнути. Інакше, якщо цього не робити, дизайн зводиться до банального “тягання пікселів” в Figma. Тоді найкраще що ви можете зробити це гарний UI, який не факт, що буде вирішувати проблему бізнесу. Тож є великий ризик просто отримати гарну картинку, яка не працює і конверсія якої дорівнює нулю.

Тому для того, щоб зробити ваше дизайн-рішення більш свідомим та зменшити ризики, я намагаюсь використовувати Method • Reason • Price Approach.

Що це таке?

Підхід Method • Reason • Price складається з трьох частин:

Method - Метод Тут дизайнер повинен відповісти для себе на питання “Як саме можна вирішити проблему?”, “Які варіанти взагалі існують?”
Reason - Причина Тут головними питаннями є “Щоб ЩО?”, “Навіщо треба вирішувати дану проблему?”, “Звідки ми знаємо, що проблема існує?”
Price - Ціна Тут треба відповісти на питання “Скільки коштує дане конкретне вирішення?”, “Як дорого обійдеться імплементація цього рішення?”

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

Саме в цей момент вам стане в нагоді Method • Reason • Price. Особисто я намагаюсь для себе відповісти на всі питання по черзі.

Уявімо ситуацію, коли ви не маєте певної відповіді:

Припустимо, ви не знаєте, як вирішити проблему. Тоді саме час провести аналіз конкурентів, подивитись best practices, зібрати UI паттерни конкурентів та продуктів із суміжних доменів, провести користувацькі інтервью і спитати в юзерів, як вони вирішують проблему зараз.
Бувають ситуації, коли ви не знаєте причини, навіщо вам вирішувати проблему. Ця ситуація трапляється дуже часто, адже вам можуть поставити таск або зафреймити проблему до вас. Наприклад замовник вам скаже, що хоче сайт, щоб підвищити дохід. Але він насправді вам вже каже що робити - малювати сайт. Моя вам порада - не довіряйте і намагайтесь розібратись у всьому самостійно. Тут вам стануть в нагоді первинні якісні та кількісні дослідження. Сходіть до користувача, спитайте що болить, проведіть юзабіліті тестування, закиньте опитування або залізьте в аналітику і валідуйте ваші якісні дослідження кількісно. Якщо ви працюєте в існуючому продукті, ви можете використати HotJar і продивитись як користувачі себе поводять. Замапте процес в CJM і самі побачите, де саме проблема. Але не довіряйте вашим стейкхолдерам сліпо, адже вони можуть помилитись.
Якщо ви не знаєте ціни імплементації рішення - це може також бути проблемою. Перед тим як включити Figma, ви можете накидати швидкий прототип на папері та пояснити вашим розробникам, як він працюватиме. Можливо ваш макет важко і дорого імплементувати, можливо є дешевше рішення або взагалі є додаткові вимоги та обмеження платформи. А кастомізувати дорого і результат може бути не вартим вкладених ресурсів.

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

Згадайте себе, коли ви тільки прийшли в дизайн і не вміли нічого. Ви не знали як робити, навіщо, що буде далі, скільки коштує….. цілковита невизначеність. Це і є стан неможливості відповісти на 3 базові питання Method / Reason / Price: ЯК? / НАВІЩО? / СКІЛЬКИ КОШТУЄ?

Особисто я зробив ще маленьку надбудову до цього підходу: до Method • Reason • Price - додав ще питання “Tested?”. Таким чином ви переноситесь в третю точку Double Diamond - там, де закінчується другий діамант. Тоді ви знатимете:

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

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

А тепер давайте приклад

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

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

Варіант 2:
Ви розумничка, адже ви вирішили спробувати скористатись Method • Reason • Price.
Ви відповіли собі на питання ЯК і знайшли інші можливості - наприклад чат-бот, сайт на конструкторі (мінімальні витрати) чи продаж через соціальні мережі. 👍
Ви не змогли відповісти на питання НАВІЩО і зробили мінімальний research: кілька інтервью, сурвей, CJM і побачили, що в галузі є велика сезонність. Юзери купляють іграшки собі виключно під новий рік, а в інший час їх це не цікавить. Тож мобільний застосунок просто без діла буде валятись на смартфоні, або його видалять.
Ви порахували вартість варіантів і побачили, що розробити мобільний застосунок коштує кілька тисяч доларів США, чат-бот можна написати за 100$, написати сайт коштує також дорого, зібрати сайт на конструкторі і купити домен та хостінг коштує до 500$, реєстрація соцмереж та аккаунтів на маркетплейсах - бескоштовна.

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

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

От така сьогодні маленька, але важлива розповідь про очевидне. Тож користуйтесь #недякуйте. Сподіваюсь Method • Reason • Price стане вам в нагоді.

ATTENTION
Більше цікавих статей ви можете почитати на моєму персональному Medium та на XD Community Medium.

Коли та як проводити аналіз конкурентів в User Experience

Євген Олексюк — Thu, 24 Nov 2022 10:07:19 +0000

Кілька місяців тому на одному з івентів я запитав у знайомого дизайнера, які активності він робить, коли отримує новий проект. Серед активностей він назвав аналіз конкурентів і, коли я попросив розповісти про це більш детально, то зрозумів, що не всі знають що це таке, коли треба робити аналіз і головне — ЯКИЙ ПРОФІТ ВІН ДАЄ.

Уявімо ситуацію — вас хайрить певний стартап. Ви готові звертати гори, завдавати невиправної користі користувачам і тим самим збільшувати цінність продукту. Ви відмальовуєте супер-круту UI, потім разом з колегами розробниками це все пиляєте і релізите. І ось той день, коли ваші early users йдуть на ваш продукт, ви забігаєте почитати фідбеки, але там все погано. Буквально за кілька місяців до того зарелізався ваш конкурент (про існування якого ви чомусь не знали) і на фоні конкурента ви не цікаві, не корисні і тд.

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

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

Ви зараз це читаєте і певне думаєте: “Бородатий, ти сильно перебільшуєш і нагнітаєш”. Але нажаль це не так, адже за статистикою 90% стартапів вмирають, так і не доживши до IPO. Ще частина компаній півотяться. Наприклад через півоти проходили такі компанії як Slack, YELP, Shopify, Amazon, Netflix, Instagram, PayPal та багато інших.

Конкурентів треба знати і завжди памятати про них!

Для початку, давайте визначимось, що таке конкуренція. Згідно Wikipedia: Конкуре́нція (лат. concurrentia — збіг, узгодженість) — це економічний процес взаємодії та боротьби товаровиробників за найвигідніші умови виробництва і збуту товарів, за отримання найбільших прибутків.

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

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

Під Аналізом конкурентів в User Experience ми розуміємо аналіз конкурентних продуктів, що знаходяться на ринку та/або мають вплив на ваш продукт, визначення їх сильних і слабких сторін та забезпечення конкурентної переваги вашому продукту.

Для проведення цього аналізу, необходно зазделегідь знати деяку інформацію:

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

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

Хто на ринку вже вирішує проблему наших користувачів?
Тут нам знову ж таки допоможуть інтервью. Базову інформацію ви отримаєте в користувачів, стейкхолдерів та доменних експертів. Трохи далі ми ще зупинимось на цій темі більш детально. Але важливо розуміти, що БУДЬ-ЯКА ПРОБЛЕМА КОРИСТУВАЧІВ ВЖЕ ЯКОСЬ ВИРІШУЄТЬСЯ! Тож не будьте наївними — вакуума вже давно не існує, ваша ЦА вже якось тамує свої болі іншими продуктами.

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

Ризик походить від того, що ви не знаєте, що ви робите.
Warren Buffett

Коли проводити аналіз конкурентів?
Це питання дуже логічне і відповідь тут проста — ЗАВЖДИ. І ЧИМ РАНІШЕ, ТИМ КРАЩЕ 😊

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

Для прикладу давайте згадаємо наш улюблений дивергентно-конвергентний процес на прикладі Double Diamond:

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

Позиціонування продукту
Конкурентоспроможність
Необхідний і бажаний функціонал продукту
Стандарти домену
Бенчмаркінг
Конкурентні переваги
Тощо

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

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

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

1. Постановка задачі
Тут нам важливо розуміти навіщо взагалі ми робимо аналіз. Особисто мені тут дуже круто допомогає підхід Method • Reason • Price

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

Прямі конкуренти — це продукти, які вирішують той самий біль тими самим методами (Same pain, same method);
ПРИКЛАД: Ви дизайнер на Spotify, одже прямими конкурентами будуть: Apple Music, Deezer, YouTube Music. Ці продукти також є стрімінговими музичними сервісами.
Другорядні конкуренти — це продукти, які вирішують той самий біль, але вже іншими схожими методами (Same pain, other method);
ПРИКЛАД: Другорядними конкурентами в Spotify є: CD-диски, магнітні касети, платівки, радіоприймачі, Torrents. Вони також продають користувачеві музику, але вже не стрімінгову — ви можете її скачати, купити на аудіо-носієві, або взагалі слухати улюблену хвилю.
Непрямі конкуренти — це продукти, які вирішують інший біль та іншими методами, але мають вплив на ваш продукт і дуже часто змагаються за вашу цільову аудиторію (Other pain, other method, but it affects).
ПРИКЛАД: Непрямимих конкурентів в Spotify буде ще більше: книги, похід в кіно, YouTube, соцмережі, спортзал, прогулянки, тощо. Ці конкуренти взагалі не про музику, але вони боряться за час вашого користувача. І з цими конкурентами також можна досить успішно працювати — наприклад ваші маркетологи можуть розказати на сайті компанії, що музика спотіфай прекрасно поєднується зі спортом 😊

Енциклопедичним прикладом визначення конкурентів є KFC (Kentucky Fried Chicken):

Прямі конкуренти: McDonald’s, Burger King, Chick-fil-A, Wendy’s, Jack in the Box та Popeyes Louisiana Kitchen. Всі вони продають клієнту швидкий джанк-фуд.
Другорядні конкуренти: Kilogramm Sushi, Сільпо, ресторан, домашня їжа, тощо. Ці конкуренти тамують голод клієнта, але вже не мʼясним джанкфудом, а чимось іншим.
Непрямі конкуренти: Greenpeace (відра та упаковка для бургерів робиться з бумаги, отже дерева страждають, курчата мучаться і тд), Спілка лікарів гастроентерологів (вживання нездорої їжі, холестерин, гастрит, виразка), спортзал (бориться з ожирінням від нездорової їжі та насаджує людям салат замість бургера) тощо.

Але де ж шукати тих конкурентів, з якими нам треба конкурувати?

Насправді їх можна знайти:

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

Якщо замовник та/або користувачі дали вам перелік конкурентів, всеодно раджу додатково пошукати, щоб не пропустити конкурентів. Найпростішим способом пошуку є просто погуглити. Тут бажано використовувати advanced search — це допоможе знайти швидше і організувати відбір за всіма необхідними параментрами. А отже зекономить вам час пошуку.

Також конкурентів можна шукати через сервіс ProductHunt, де ви знайдете багато нових цифрових продуктів:

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

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

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

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

Як приклад, давайте проаналізуємо конкурентів Rozetka. Similarweb серед конкурентів вказує нам: Allo, Prom, Comfy, Hotline, Bigl, Epicentr, Citrus та інші. Хоча по факту Rozetka та Prom є маркет-плейсами, а Comfy — звичайним e-commerce.

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

Найголовнішим і найпопулярнішим методом аналізу є аналіз функціоналу конкурентних продуктів.
Цей вид аналізу заключається в тому, що для кожного конкурента ви виписуєте весь наявний функціонал і виділяєте так звані Points of Parity (PoP) та Points of Difference (PoD).

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

Points of Difference (PoD) — це функціонал, що виділяє продукт з поміж інших. Це і є та кіллер-фіча, яка запамятовується юзеру.

Давайте розберемо приклад: припустимо ви працюєте дизайнером в Figma. Тоді Points of Parity (PoP) буде можливість проектувати інтерфейс за допомогою текстів, зображень, ефектів, тощо. Цей функціонал буде в Figma, Sketch, Photoshop, XD і взагалі ВСІХ графічних редакторів (адже без цього функціоналу редактор не зможе виконати головне призначення — проектування інтерфейсу). Points of Difference (PoD) це можливість працювати в браузері, командна робота над макетами, зберігання макетів в клауді, голосовий чат, тощо. Тобто це ті функції, які змусять користувачів серед всіх інших продуктів обрати саме вашу класну, зручну і модну Figma.

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

Другим методом аналізу є Аналіз UI паттернів.

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

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

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

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

Евристики Якоба Нільсена;
8 золотих правил Шнейдермана;
6 критеріїв юзабіліті;
21 закон UX дизайну;
7 принципів Дона Нормана;
Принципи Брюса Брюс Тогняцціні.

Дуже багато з цих методів оцінки повторюються або доповнюють один одного — тому будь-який метод буде достатнім. Особисто я раджу використовувати звязку Евристик Якоба Нільсена та Законів UX Дизайну. На мою особисту думку це достатній пак для аналізу юзабіліті.

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

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

SWOT-аналіз
SWOT це абривіатура, яка розшифровується як:

S — Strengths — Сили
W — Weaknesses — Слабкості
O — Opportunities — Можливості
T — Threats — Загрози

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

Для проведення SWOT-аналізу складається таблиця і заповнюються відповідні чветрі:

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

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

На прикладі ви бачите SWOT-аналіз, складений для онлайн-сервісу з розміщення, пошуку та короткострокової оренди житла Airbnb.

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

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

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

Для цього аналізу ви можете використати PageSPeed Insights — один з сервісів Google, який показує вам швидкість завантаження вашого сайту, проблеми, які впливають на цю швидкість і навіть підказує, як можна підвищити швидкість.

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

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

Додатково ви можете проводити:

Аналіз трафіку конкурентів;
Аналіз бренду;
Аналіз аксесабіліті;
Аналіз принципу роботи;
Різні формативні та сумативні дослідження;
Value Proposition Canvas;
Business Model Canvas;
Бенчмарк аналіз;
Тощо.

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

До основних артефактів можна віднести:

Перелік Points of Parity;
Перелік Points of Difference;
Перелік функціоналу;
Вимоги до юзабіліті;
Існуючі UI паттерни;
SWOT таблиця;
Таблиця аналізу трафіка;
Перформенс вимоги та рекомендації щодо покращення.

Презентацію ви можете оформити в Figma, FigJam або Miro. Там ви зможете зручно все оформити та за необхідності залишати коментарі під час презентації.

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

Приорітизацію можна проводити за допомогою:

Матриці Кано;
RICE;
MoSCoW;
Матриці Ейзенхауера;
Тощо

Найпростіше використовувати Матрицю Ейзенхауера, яка складається з 4 блоків. Під час грумінга ви розташовуєте ваші таски в необхідних чвертях в залежності від того, наскільки таска є терміновою і важливою. Далі ви берете в роботу таски з чверті “Важливо/Терміново”, а останнє кладете в беклог.

Висновки
Давайте не забувати, що дизайнер це не просто людина яка “тягає пікселі”, а ще й додає цінність продукту. І вміння грамотно проводити аналіз конкурентів — це базова навичка User Experience дизайнера. Адже як то кажуть Know Your Enemy.

ATTENTION
Більше цікавих статей ви можете почитати на моєму персональному Medium та на XD Community Medium.

Письмо — це дизайн: Як слова створюють досвід користування (UX)

Євген Олексюк — Tue, 25 Oct 2022 18:57:35 +0000

Originally published @ Medium

Без слів додатки були б безглуздою сумішшю фігур та значків, а голосових інтерфейсів та чат-ботів просто не існувало б. Слова роблять програмне забезпечення орієнтованим на людину і вимагають не менше уваги, ніж брендинг та код. Книга “Writing Is Designing: Words and the User Experience” (2020 — Rosenfeld Media) розповідає, як проектувати текст інтерфейсів.

Книга написана двома авторами:

Энді Велфл — очолює команду контент дизайнерів в Adobe, у минулому працював у Facebook та Reusser Design, вирішуючи проблеми написання UX та інформаційної архітектури у вебі та додатках.
Майкл Дж. Меттс — навчає, як створювати якісніші продукти та послуги за допомогою дизайну, займається написанням інтерфейсів, побудові довірчих відносин з користувачами та виступає на галузевих конференціях з UX-райтингу та мікрорайтингу.

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

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

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

Для того, щоб інтерфейс був робочим та допомагав користувачеві, UX writer повинен пропрацювати текст цього інтерфесу по таких параметрах як:

Зручність — Чи спрощують слова користування інтерфейсом? Чи зрозумілі слова? Чи доступні слова аудиторії?

Під словом “зручність” мається на увазі ефект, який отримує користувач. Всі знають, що не варто писати на кнопці “Натисніть тут”. Користувач повинен розуміти, що він отримає при кліку.

Користь — Чи закривають слова інтерфейсу необхідності та біль користувача? Чи додають слова інтерфейсу щось корисне для користувача?

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

На прикладі нижче видно, який текст корисніший. В кінці списку уроків на Creative Cloud показаний текст:
ЗЛІВА: Не знайшли те, що шукали? Натисніть на іконку пошуку поруч з зображенням профілю!
СПРАВА: Використовуйте пошук, щоб знайти більше уроків.

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

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

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

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

Як ми вже зрозуміли, слова — це основна частина інтерфейсу, але крім веба та мобільних додатків, слова несуть інформацію через описи додатків в AppStore, Push-сповіщення, платіжні термінали, листи, смарт-годинник, фітнес-трекери, VR, AR та багато іншого. Крім цього, є ще голосові помічники (Привіт, Siri! ☺️), єдиним елементом інтерфейсу яких є текст.

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

Найлегше почати з опису стратегії за 4 пунктами:

Тип користувача
Потреба (біль) користувача
Користь для користувача
Користь для компанії

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

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

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

Голос бренду чи голос продукту? Їх плутати не слід.

Голос бренду — це послідовне, цілеспрямоване вираження бренду словами. Він служить для залучення аудиторії та мотивації аудиторії стати клієнтами (acquisition & activation). Це те, як бренд говорив і писав би користувачеві, якби був людиною.

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

У результаті опрацювання голосу його фіксують і затверджують.

ПРИКЛАД
Ось так описують свій голос Mailchimp:

Весело, але без дитячих пустощів

Весело, але без дурощів

Розумно, але без занудства …

ПРИКЛАД
Slack — один з прикладів продукта-друга, який турботливо онбордить вас:

Після опрацювання голосу UX writer визначається з тоном, яким продукт говоритиме з користувачем.

ПРИКЛАД

Вікно Facebook, яке ініціативним дружнім тоном запитує: “Що в тебе на думці, Енді?”

Окрема глава приділяється тому, як правильно оформляти голос, тон та інші артефакти, що стосуються листа. Наприклад, як це зроблено в системі Polaris від Shopify.

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

Одне з правил написання тексту — це не перекладати на нього відповідальність. Наприклад, якщо користувачеві показують повідомлення про проблему ПЗ, яким він користується, потрібно зробити це м’яко. Не потрібно показувати номер помилки, не потрібно натякати на проблему з клієнтом.

Взагалі існує 3 принципи написання текстів для error-stages:

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

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

Спробувати іще раз

Додати фото чека вручну.

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

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

ЗЛІВА: Користувачі можуть взаємодіяти лише з людьми з внутрішніх, довірених або внесених в білий список доменів. Ця дія також заборонить користувачам створювати публічні посилання на контент та користуватись публічними способами поширення. Ввімкнення даної опції деактивує всі існуючі посилання. Ви бажаєте продовжити?

СПРАВА: Всі існуючі публічні посилання будуть вимкнені і користувачі не зможуть створювати нові публічні посилання.

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

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

Яскравий приклад роботи з інклюзивністю та доступністю — це push, який отримують користувачі мобального додатку Lyft, коли сідають в автомобіль до глухонімого водія:

Lyft Ваш водій Lyft глухий або має порушення слуху. Будь ласка, пишіть повідомлення, а не телефонуйте. Натисніть, щоб дізнатись як сказати “Привіт” або “Дякую” мовою жестів.

Підсумок:
Відмінна книга про UX райтинг для дизайнера! Там дуже багато прикладів, є практичні частини та непогано розписана робота райтера в команді.

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

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

Laws of UX. Закони, які допомогають покращити користувацький досвід та збільшити цінність продукту

Євген Олексюк — Mon, 24 Oct 2022 11:43:49 +0000

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

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

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

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

Закон Якоба
Користувачі проводять більшу частину свого часу на інших веб-сайтах, і вважають за краще, щоб ваш сайт працював так само, як інші сайти, які вони вже знають
Вперше закон сформулював всесвітньовідомий експерт з юзабіліті Якоб Нільсен в 2000 році в своїй книзі “Кінець Вебдизайну”. Тут варто акцентувати увагу на рівні когнітивного навантаження, яке коричтувач змушений витримувати на сайті.

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

Саме тому, якщо придивитись, всі e-commerce сайти однакові. Вони зменшують когнітивне навантаження і таким чином збільшують шанси покупки товару на сайті. Усі інтернет магазини працюють майже однаково щоб, якщо ви колись вже зробили десь покупку, у вас склався паттерн “як купляти”, і наступного разу, вже на іншому сайті, ви мали розуміння як купити.

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

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

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

Ключові моменти:

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

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

В 1954 році Пол Фіттс сформулював формулу швидкого переміщення до цільової області. Варто підкреслити, що Закон Фіттса з’явився задовго до появи діджитала та інтерфейсів як таких, але з нього були виведені певні вимоги до площі торкання в Material Design та Human Interface Guidelines.

Крім величини обєкта взаємодії, також важливі відстань до обєкта та його положення на екрані. Наприклад, середній розмір подушечки пальця дорослої людини складає 10–14 мм2, а середніий розмір кінчика пальця — 8–10 мм2, тобто якщо обєкти знаходяться занадто близько, то може відбутись так званий місклік — випадкове натискання. Саме тому в Material Design існує відстань між обʼєктами у 8 пікселей.

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

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

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

Ключові моменти:

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

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

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

В цьому випадку, когнітивне навантаження є критичним. Коли юзер відчуває надмірне навантаження, так званий overload, його короткострокова память не має вільних слотів для запамятовування та інформація втрачається. Можете самі в цьому запевнитись — згадайте число Пі — скільки знаків після коми ви можете пригадати? 😊

Найкращим прикладом відображення Закону Хіка є пульти дистанційного контролю.

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

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

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

Щоб вирішити проблему великої кількості обєктів, завжди можна використати card sorting, згрупувати і відсортувати обєкти.

Ключові моменти:

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

Закон Міллера
Тепер давайте трошки про Міллера, і як наслідок Закон Хіка. 😊

Середньостатистична людина може зберігати у своїй робочій пам’яті лише 7 (±2) елементів
Закон Міллера з’явився в 1956 році зі статті когнітивного психолога, професора Факультета Психології Гарвардсього Університету Джорджа Міллера «Чарівне число 7±2: деякі обмеження нашої здатності обробляти інформацію».

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

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

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

Ключові моменти:

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

Закон Постеля (Принцип Стійкості)
Будьте консервативними в тому, що ви робите, і будьте ліберальні в тому, що ви приймаєте від інших
Закон було виведено американським вченим-компьютерщиком Джоном Постелем в 1981 році в його работі «RFC 793: Transmission Control Protocol». Джон Постель сформулював свій закон тоді таким чином:

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

«Бути ліберальним в тому, що ви приймаєте від інших» означає приймати дані від користувача у тому вигляді, в якому зручно ЮЗЕРУ, з тих пристроїв, на котрих працює ЮЗЕР! Дизайн повинен бути підлаштований в першу чергу під користувача! Дизайн не повинен обмежувати, а повинен бути гнучким та підлаштовуватись під юзера!

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

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

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

До прикладів ліберальності можна також віднести:

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

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

Загалом Закон Постиля допомагає подолати розрив між людиною та машиною!

Ключові моменти:

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

Правило оцінки на піку та в кінці
Люди судять про свій досвід головним чином на основі того, що вони відчували на його піку і в кінці, а не за підсумковою сумою або середнім значенням кожного моменту свого досвіду
Давайте згадаємо серіал ДРУЗІ. Думаю всі, хто дивився цей серіал памятають моменти про “Джоі не ділиться їжею”, момент, коли Фібі співає пісню “Smelly Cat” 😂 та коли друзі прощаються з квартирою Моніки в останній серії. Фактично це і є відображення Правила оцінки на піку та в кінці.

Вперше правило было приведено Дэниэлом Канеманом в статті «Більше болю — краще, ніж менше: додавання кращого завершення» в 1993 році.

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

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

Найяскравіший приклад — будь-який концерт або фестиваль — останнім виступає найкращий артист, який запамятовується надовго. Тому він і називається хедлайнером 😊

Як же дизайнер може використати це правило в своїй роботі?

Наприклад MailChimp дуже вдало використовують це правило — під час розсилки вони виводять повідомлення з позитивним підкріпленням.

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

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

Ключові моменти:

Звертайте увагу на найбільш напружені та заключні моменти “кінець” шляху користувача
Виявляйте моменти, коли ваш продукт найбільш корисний, цінний чи цікавий, та організуйте дизайн так, щоб радувати кінцевого користувача
Пам’ятайте, що люди згадують негативні переживання яскравіше, ніж позитивні

Ефект естетики в юзабіліті
Користувачі часто сприймають естетично приємний дизайн як дизайн, який зручніший у використанні
Коко Шанель казала: «У вас не буде другого шансу справити перше враження». Це дуже валідний вираз для дизайна, він чудово показує відношення користувача до інтерфейсу.

Вперше Ефект естетики в юзабіліті був описаний в 1995 році дослідниками Масаакі Куросу та Карі Кашимура в центрі дизайну компанії Hitachi. До цього взаємозвязок між красою, зрозумілістю та естетикою не був встановлений. Під час тестування компонування інтерфейсу банкомату (дослідники тестували 26 варіантів компоновки на більш ніж 250 респондентах), Масаакі Куросу та Карі Кашимура помітили кореляцію зручності та привабливості.

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

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

На мою думку, найкращим прикладом естетики дизайну є компанія Apple та її попередник — компанія BRAUN. Давайте не будемо забувати, що Стів Джобс та Джонні Айв, які сильно повпливали на дизайн Apple, були фанатами дизайнера компанії BRAUN — Дітера Рамса.

А сам Дітер Рамс свого часу ввів 10 правил хорошого дизайну:

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

Ключові моменти:

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

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

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

Даний ефект виявив німецький психіатр Хедвіґ фон Ресторфф в 1933 році. Звертаю вашу увагу — в 1933 році не було компьютерів і інтерфейсів ☺️. Вчений показував піддослідним масиви однорідних слів і помітив що люди помічали та запамятовували лише слова, які відрізнялись або за написанням, або за змістом, або за кольором.

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

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

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

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

Ключові моменти:

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

Закон Теслера
Закон Теслера (закон збереження складності) стверджує, що в будь-якій системі існує певний ступінь складності, який не можна зменшити
Закон був сформульований Ларрі Теслером — компьютерним спеціалістом XEROX PARC в 1980-х роках. В цей період компанія XEROX була чи не найголовнішою в сфері компьютерних інтерфейсів, адже це саме вони розробили графічний інтерфейс, який потім купили Apple і з якого ви щоденно працюєте на вашому ноутбуці.

Яскравим прикладом спрощення є написання листа в G-mail:

Ви створюєте новий лист, в ньому є поля відправник, одержувач, тема листа та тіло листа;
Ми можемо спростити — так як ви є відправником, система може поставити ваш E-mail і стане на одне поле менше;
Ми можемо ставити заздалегідь підготований темплейт теми листа — ще на одним полем менше;
Ми можемо виводити E-mail адресата за допомогою автозаповнення — це спростить нам життя і не потрібно буде тримати в голові зайві адреси;
Ми можемо зробити стандартний підпис в тілі листа — це зекономить нам час. *Але на цьому ми вже навряд можемо щось спростити чи зменшити складність. Це і є наш мінімум, який описаний Законом Теслера. *

Також ми можемо спрощувати взаємодію користувача при заповненні форм:

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

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

Ключові моменти:

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

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

Тут важливо згадати, що згідно HTTP Archive, “вага” середньостатистичної сторінки в 2011 році була 608 кБ, а в 2019 році — вже біля 2 мБ. Тобто лише за 8 років, сторінки погладшали втричі і ростуть далі. Звичайно, швидкість трафіку також збільшилась, але давайте не забувати, що:

взаємодія за швидкістю 100 мс (0.1с) сприймається людиною як миттєва;
взаємодія за швидкістю 100–300 мс — припустима і комфортна для користувача;
взаємодія за швидкістю 1000 мс (1с) і більше — людина сприймає як затримку, починає відволікатися, когнітивна навантаження зростає, через що користувач йде з вашого сайту 😕.

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

Пізніше це правило стало правилом 2-х секунд, яке в 1982 році було оскаржено співробітниками IBM Уолтером Доерті та Арвіндом Танаді. Вони довели, що коли поріг 400 мс, “продуктивність зростає більш ніж прямопропорційно зменшенню часу відгуку”.

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

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

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

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

Якщо процес завантаження триває більше 10 секунд, варто використовувати анімацію та вказувати час який залишився до повного успішного завантаження. Саме тому і зявились сноуболи, спінери, вейвери, прогресбари та інші елементи інтерфейсу, які допомогають користувачеві, втримують його і нагадують про 1 Евристику Якоба Нільчена — Повідомляють юзеру про стан системи.

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

Ключові моменти:

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

Існують ще також і інші закони UX. Ось їх формулювання і короткий опис:

Ефект градієнта мети
Тенденція наближення до мети зростає з близькістю мети

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

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

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

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

Закон рівномірної пов’язності
Елементи, які є візуально об’єднаними, краще сприймаються як пов’язані, ніж елементи без візуального зв’язку

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

Принцип Парето
Принцип Парето говорить, що для більшості випадків 20% зусиль дають 80% результату

Закон Паркінсона
Будь-яке завдання буде збільшуватися доти, доки не буде витрачено весь доступний для її вирішення час

Ефект серійної позиції
Користувачі схильні найкраще запам’ятовувати перший та останній елементи в серії

Ефект Зейгарник
Користувачі запам’ятовують незавершені або перервані завдання краще, ніж завершені

Тепер ви переконались, що навіть за відсутності дослідження, інтерфейс можна зробити кращим, якщо застосовувати Закони UX. Бажано робити це комплексно з Евристиками Якоба Нільсена, Золотими правилами Шнейдермана та використанням кращих практик в дизайні.

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

Більше цікавого на моєму Medium та Medium XD Community!