На мою думку, ця стаття є завершальною, якщо ми говоримо про можливість валідації інтерфейса БЕЗ залучення живих людей. Я захотів її написати щоб зробити логічне завершення до статей про Закони UX та Валідації БЕЗ користувачів.
А ще хочу акцентувати вашу увагу на тому, що стаття написана НЕ за допомогою ШІ, а пальчиками. Можливо стаття вийде не настільки стерильно-бездоганно, але як говорить нам японська філософія Вабі-Сабі «Ідеальність в неідеальності». Звісно, це трошки олдово, але якось чесно, адже ви це читаєте вашими аналоговими очима, тому я пишу це своїми аналоговими пальцями!
Дуже часто студенти питають «А що робити якщо замовник/стейкхолдер починає пітчити свої ідеї?» тому що йому нібито видніше і взагалі його візія є єдиновірною? Зазвичай ми починаємо батлити на цю тему і все зводиться до того що замовник знає гірше аніж його юзер. Звідси витікає тейк що «Дизайнер працює на клієнта клієнта» адже монетизує ендюзер.
А ще я люблю розповідати байку про одну компанію, яка в welcome package дизайнера клала футболку з написом ТИ НЕ Є ВАЛІДНИМ! То є нагадування що думки ані дизайнера, ані стейкхолдера, ані будь-кого з проєктної тіми не мають критичної ваги. І звісно ж, цей напис не є оригінальним — це є лише варіація одного з слоганів Nielsen Norman Group.
Зазвичай студенти і джуни, коли чують про слогани, одразу пожвавлюються і проявляють інтерес. Одразу давайте я вас трошки розчарую — нічого наднового і надцікавого в слоганах немає, але знати про них та тримати їх в голові варто як певні важливі пойнти.
До деяких слоганів я додавав також власні рефлксії, тож сподіваюсь вам буде цікаво. А під кожним слоганом є відео з оригіналом від NNG.
Тож давайте розберемось, що ж там такого цікавого в Слоганах від NNG. На момент написання статті, слоганів вже існує аж 19 штук — давайте розбиратись з ними по черзі:
UX Slogan #1: You ≠ User
Ти Не Є Користувач
Вперше цей слоган був сформульований в 1993 році в книжці Якоба Нільсена «Usability Engineering». Тут все кристально зрозуміло, але часом важко донести це до команди, адже всі вважають себе Mr.KnowItAll. Очевидно, всі члени вашої тіми матимуть свої погляди на те «ЩО і ЯК краще для користувача», але всі ці погляди засновані суто на досвіді та спотвореннях кожного конкретного члена команди, на їх бажаннях і візіях.
Наприклад представник бізнесу буде мати байєс пов’язаний з монетизацією, адже він розуміє концептуальну модель бізнесу і вона може бути сильно відмінна від ментальної моделі користувача.
Тим часом розробники забайєсині своєю експертизою в технології або платформі, а ще дуже часто вони не хочуть кастумізувати існуючі віджети і тому будуть пітчити якісь рішення, які будуть не сильно враховувати користувача, але будуть максимально прості і дешеві в імплементації.
Дизайнери (а також Проджект Менеджер, Продукт Менеджер, Бізнес Аналітик, Делівері Менеджер і тд) це взагалі максимально спотворені ролі і їх слухати категорично заборонено.
По-перше ці ролі мають завелику надивленість в інших продуктах, в той час як юзер може не мати цієї цифрової обізнаності (особливо якщо ЦА продукту відрізняється за багатьма атрибутами від дизайнера, ПМ, ДМ, БА).
По-друге ці ролі починають одразу накидати мільйони потенційних рішень на основі існуючих паттернів (дивитись попередній пункт) і не емпатують та не концентруються на потребі користувача.
По-третє ці ролі тісно пов’язані з ВСІЄЮ командою і тому можуть безпосередньо впливати на продуктові гіпотези, інтерфейсні рішення, їх імплементацію, тощо. Це іноді створює додаткові ризики менеджерської тиранії та нав’язування.
Тому думка користувача найважливіша! Хорошим рішенням є тримати у вільному доступі головні артефакти проєкту (опис юзер персони, CJM, перелік проблем користувача, можливо якісь канваси проєкта) — наприклад в мітінг румі або опенспейсі розвісити роздруковані артефакти і стікери на стіні, щоб в будь-який момент обговорення чи грумінгу можна було остудити голову тіммейта словами «Давай не забувати що ми не користувачі і просто глянемо, хто ж наша цільова»😉
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 десь такий: пам’ятайте, що ВИ НЕ Є ЮЗЕРОМ (просто дуже вже мені подобається цей слоган) і намагайтесь всіма вашими силами і знаннями покращити досвід ЦА!
П.С. Якщо вам сподобалась моя стаття і якщо вам хочеться віддячити і допомогти мені особисто — зробіть донат на ЗСУ. Я буду задоволений і знатиму, що витратив час не дарма!
Сподіваюсь моя стаття допоможе зробити вашу роботу більш осмисленою та виваженою, а ваш продукт прибутковим. Тож щасти і до нових зустрічей в рубриці #задротствозбородатим 😂❤️🇺🇦
Найстарші коментарі (0)