Методи досліджень у дизайні, або Чому варто валідувати ідеї і не зупинятись лише на власному досвіді

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

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

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

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

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

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

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

Валідація рішень на актуальність

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

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

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

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

Що є в арсеналі дизайнера

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

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

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

Варто зазначити, що евристики Нільсена — не єдині у світі евристики. Наприклад, Wikipedia містить ще два переліки евристик. Перша від пані Джил Ґергардт-Повалз містить також 10 евристик, але подаються вони як один цілий робочий організм під так званим голістичним соусом. Друге зібрання авторства пані Сьюзен Вайншенк, спеціалістки з вивчення поведінки людей, та її підлеглого Діна Бейкера складається аж з 20 пунктів. Якщо подивитися на них, стає зрозумілим, що це ширше бачення рекомендацій, а саме категоризація порад для поліпшення вашого інтерфейсу.

А якщо копати ще глибше, то ми знайдемо також евристики авторства Сміта й Мойзера, Бастієна й Копіна, Коннела й Гамонда.

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

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

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

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

Свобода та контроль ситуації користувачем (різноманітність шляхів поведінки користувачів і можливість скасування дій):

• Після натиснення кнопки Add to cart («Додати в кошик») користувача перекине на сторінку з повідомленням про те, що товар додано в кошик, та кількома додатковими можливостями модифікувати це замовлення. Але без можливості видалити цей товар, якщо користувач зробив помилку. Також відсутня можливість змінити кількість одиниць товару, хоча саму кількість одиниць на сторінці зазначено.
  
• Продовжуючи обмеженість дій на попередньо вказаний частині системи, Amazon не дає мені пропозиції продовжити купівлю (що могло б принести додаткові заробітки системі), а лише пропонує переглянути безкоштовні додатки, які я можу встановити на... ще не куплений Apple Macbook.

Послідовність і стандарти (консистентність інформації, що дається користувачеві):

• На сторінці є певна кількість кнопок з однаковим формулюванням функції — Add to... («Додати в...»). Але зображення всіх трьох відрізняються, що може призвести до зупинки користувача перед натисканням, позаяк виникне питання: «Чи впевнений я в тому, що станеться?»
  
  
  
• У верхній частині екрана — два елементи зі стрілкою, яка позначає, що є вибір показуваних у списку елементів. Але сумно те, що кнопка вибору категорії відкривається лише натисканням, а функціонал вибору мови розгортається відразу після наведення. Така поведінка знову-таки лише позбавляє користувача стабільності. А в наш нелегкий час вона так потрібна...

  
  

Уникнення помилок (написати про помилку може будь-хто; але тільки гарна система робить так, щоб помилка не з’явилася).

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

Упізнаваність (полегшення навантаження на користувача шляхом створення логічних зв’язків та інструкцій).

Гнучкість (надання можливості налаштування дій, які часто використовуються).

Естетика та мінімалізм (мінімізування нерелевантних елементів та інформації на сторінці для фокуса на потрібному контенті).

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

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

Аналіз конкурентів

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

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

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

• оренда велосипедів;
• сервіси соціальних таксі (Uber, Bolt тощо);
• громадський транспорт (особливо, якщо це невелике місто).

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

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

Приклад № 1

Аналіз сильних і слабких сторін конкурентів.

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

Приклад № 2

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

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

Приклад № 3

Аналіз функціоналу конкурентних продуктів.

Такий аналіз годиться для аналізу прямих конкурентів, для пошуку своїх так званих killer features (ой, навіть не знаю, як гарненько це перекласти) і завоювання ними ринку.

Коридорне тестування

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

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

Тут вами можуть допомогти колеги чи друзі.

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

Як це працює. Провели ви евристичний аналіз (чому б не провести, адже ви тепер пам’ятаєте про його цінність), вивели перші гіпотези, створили перші макети з новими вирішеннями, зробили клікабельний прототип за допомогою вбудованого функціоналу Sketch, Figma або звичніших дизайнерам InVision чи MarvelApp; якщо ви зовсім крутий гік, то й за допомогою Framer X. А далі все те ж саме, що й зі справжніми користувачами, — тільки з вашими колегами, які сидять поруч; або друзями, перед келихом молока в барі: склали сценарії та попросили ними пройти.

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

Round Bobby

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

Що вам треба:

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

Кожен аркуш поділено на 4 частини, кожна з яких має заголовок і коротке пояснення:

1. Проблема (опишіть проблему одним реченням).
2. Можливе усунення (вкажіть нестандартне розв’язання проблеми).
3. Критика розв’язання (вкажіть щонайменше дві причини, чому вищезазначене розв’язання може не спрацювати).
4. Фінальний концепт (проаналізуйте вищезазначену критику та створіть альтернативне розв’язання проблеми).

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

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

Таким чином, у підсумку у вас буде n варіантів усунення проблеми, де n — кількість учасників.

Хочу підкреслити, що загальний час такої сесії не перевищує однієї години.

Для прикладу візьмімо якусь реальну проблему.

• Проблема (опишіть проблему одним реченням).
  Компанія не знає, як проводити процес адаптації нових працівників у міру зростання розміру компанії.
• Можливе усунення (вкажіть нестандартне розв’язання проблеми).
  Створити 3D-тур офісом компанії, у процес проходження якого додати інформацію про кожен відділ, його функції, працівників і контакти. Зробити зручну навігацію та скоротити інформацію лише до найпотрібнішої. Також розглянути варіант VR- або AR-реалізації такого вирішення.
• Критика розв’язання (вкажіть щонайменше дві причини, чому вищезапропоноване розв’язання може не спрацювати).
  Для майбутнього пошуку певної інформації користувач буде змушений проходити непотрібні йому частини офісу.
  Розробка такого функціоналу може забрати багато часу, а нові працівники приходять уже сьогодні.
  Не всі працівники дуже добре розбираються на технологіях. У них можуть виникнути труднощі з такою системою.
  
• Фінальний концепт (проаналізуйте вищезазначену критику та створіть альтернативне розв’язання проблеми)....
  А спробуйте й ви тут знайти рішення. (Знаю-знаю, це не надто чесно. Але ж ми тут для того, щоб учитися, чи не так?)

Запити в службу підтримки

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

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

Запити до служби підтримки містять саме такі скарги.

Варто не забувати, що коли ви робите (ре-)дизайн додатку, який уже продається чи надається до завантаження в онлайнмагазині типу Play market або App store, то книга відгуків у вас є без обумовлення, бо в ній є можливість залишати відгуки. Беручи з практики, здебільшого вони не такі змістовні, як запити до служби підтримки, але часто з них можна взяти багато корисного.

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

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

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

Інтерв’ю з відділом продажу

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

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

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

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

Альтернативні інструменти якісних досліджень

Кажуть, були часи, коли UX-досліджень не існувало. Моторошно, чи не так?

Потім збагнули, що без них нікуди, і розробили певні методології. Але виникла нова проблема: бракувало інструментів.

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

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

Тестування інтерфейсу з користувачами тепер можна провести без вашої присутності чи навіть без наявності користувача, за допомогою сервісів, як-от UserZoom, VWO та їм подібні.

А eye-tracking-сесії стають усе доступнішими, бо вже не треба купувати дороге устатковання. Для прикладу є інноваційний продукт Hawkeye, що допомагає виконати дослідження напрямку зору користувача за допомогою звичайного iPhone (від моделі Х і вище).

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

Що почитати

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

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

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

Я справді поважаю те, що роблять ці хлопці й дівчата, бо:

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

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

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

• UX collective на Medium;
• сайти-портфоліо дизайнерів (такі приклади, між іншим, можуть допомогти молодим дизайнерам зробити власні портфоліо);
• блоги великих продуктних компаній, як-от InVision або Airbnb;
• буде круто, якщо ви створите своє портфоліо з case-studies і закинете його в коментарі до статті. Або, якщо воно у вас уже є, то ви знаєте, що із цим робити.

На завершення

Як каже Максим Ткачук (перепрошую, що трохи змінив текст), якщо ти дизайнер, що не проводить досліджень і тестувань, то можеш сміливо йти до дзеркала та маркером на лобі написати великими літерами «МИТЕЦЬ».

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