На співбесідах із сініор-дизайнерами буває дивно, коли на питання про їхній дизайн-процес, я не чую у відповідь анічогісінько про фазу користувацького тестування. Тоді я засмучено, але все ще з надією пробую підвести їх до теми валідації своїх рішень.
Валідація? Користувацьке тестування? — Нєт, нє слишал. Яждизайнер! Ятаквіжу. Клієнт валідує, а хто ще? Головне, щоб клієнтові сподобалось! Клієнт же платить врешті-решт.
Десь так могло би бути... але не тут і не зараз. Не на ринку, де різноманітність така, що очі розбігаються, і де за кожного користувача треба боротися, щоб не стати аутсайдером. Не на ринку, де користувачі вже звикли, що може бути інший рівень обслуговування, і де, трапляється, що ти з превеликою приємністю розумієш: «Хтось думав про мене, коли оце дизайнив». Коли про тебе думають — це не просто приємно. Це дуже приємно, це підкуповує і є першою цеглинкою для побудови лояльності.
Як колись казав один з головних ентузіастів дизайн-мислення в Україні Олександр Акименко: «Те, що ти думаєш — круто, але вирішує користувач». Отак у лоб і безапеляційно — вирішує користувач. І крапка.
Ліричний відступ.
Якось ми з колегою дуже сильно сперечалися, як ліпше зробити щось там. Так сперечалися, що аж іскри летіли. І тут у мене останній аргумент: «А йдем протестуємо!». Він такий: «Ну... та.. йдем».
Ми пішли. Тестуємо. І що ви думаєте? Мій варіант провалився. Уявляєте? Я не мала іншого виходу, ніж визнати свою неправоту, бо користувач вирішує, не я і не мій колега.
Я вже писала про це, але дозволю собі повторитися:
«Balsamiq, Sketch й навіть Photoshop все стерплять, але користувачі не пробачають непродуманості».
Мета цієї статті — переконати тих, хто думає, що користувацьке тестування — це довго, дорого чи нереалістично. Якщо ваша цільова аудиторія — не пілоти винищувачів, супер високооплачувані адвокати чи фінансові аналітики, користувацьке тестування — це швидко, доволі просто і дешево. До того ж ці три атрибути не є взаємовиключними (за винятком описаних рідкісних трафунків).
Навіть якщо вам не пощастило і ваш користувач — унікум, який заробляє $500 за годину, то ця відмазка вас не порятує. Золоте правило людино-центрованого дизайну (HCD) — будь-яке тестування краще, ніж ніякого. Навіть якщо відкинути той цілий HCD, скажу вам як колишній тестувальник (сертифікований, до речі): там усе так само. Якщо нема часу на Regression Testing — робимо Smoke testing. Якщо не було часу зробити людські сценарії й прописати гарно тест-кейси — робимо Ad Hoc testing. Будь-яке тестування краще за його відсутність. Це підтвердить будь-який тестувальник. Навіть коли до релізу 3 години, а менеджер кричить: «Не тестуй, бо нема часу фіксати!». А якщо там блокер...?! Що тоді? А що, якщо блокер знайде клієнт?
Тепер детальніше про «будь-яке» та ідеальне тестування. Нещодавно мені трапилася гарна статейка, про те, що ідеально — це ніколи. Зовсім ніколи! Тому давайте вже забудемо про той клятий, але такий вигідний нашому внутрішньому прокрастинатору ідеал і спробуємо робити просто добре. А ідеально залишимо ідеальним людям в ідеальному світі.
Розглянемо основні види найпростішого користувацького тестування, яке доступне всім і кожному.
Коридорне тестування
Коридорне тестування — це ультрапросто. Тут ви, звісно, не можете покладатися на вашу цільову аудиторію (бо вона рідко ходить по тих самих коридорах, що й ви), але феєричні баги цей вид тестування допоможе виловити.
Отож, все просто. Берете свій дизайн на будь-якій фазі готовності (про них трохи нижче), ловите в коридорі свого офісу людину, яка хоча б віддалено схожа на представника вашої ЦА, і пропонуєте їй виконати наперед продуманий сценарій, що може бути пройдений по вашому дизайну.
Наприклад, працюючи над інтерфейсом бронювання кімнат в офісі, ви можете спитати: «Тобі треба зарезервувати кімнату № 213 для себе і ще п’ятьох колег. Сьогодні о 15:30 на 1 годину. Що будеш робити?».
Цей простий тестик допоможе зрозуміти, чи ясно, де шукати кімнату в інтерфейсі, вказувати діапазон часу і найголовніше — чи з опису кімнати зрозуміла її місткість.
Можна ще простіше: «Як думаєш, що буде, якщо ти натиснеш на цю іконку/кнопку/табку?». Якщо ви чуєте щось схоже на «Ем... Ну... Я не знаю... може... ну...», то я вас вітаю. Тест був успішний. Ви знайшли баг! Ура! Візьміть собі печенько. Ви його заслужили.
Скільки часу ви затратили? Скільки грошей це вартувало з бюджету вашого клієнта? Якщо ви тестували не вилизаний інтерактивний pixel perfect high fidelity протопип, то найбільше, що ви могли затратити — 5 хвилин. Хоча тут я трохи спростила. Щоб підтвердити баг, сценарій треба прокатати разів зо п’ять. Все як у звичайному тестування — баг має відтворюватися. Баг, який не відтворюється, не є багом. Те, що один користувач не дав собі раду з тест-кейсом (з вашим дизайном), — ще не причина бити в дзвони.
По суті, коридорне тестування є відповідником ad-hoc testing у світі Quality Assurance.
Переваги:
- швидко;
- дешево;
- результативно;
- не треба в клієнта вибивати узгодження часу і бюджету;
- ви впевнені, що ваше рішення працює насправді, а не ви так лише вважаєте. Або не працює :-)
- ви можете аргументувати клієнту чому так, а не інакше (тому що ось так я теж тестувала й отримала ось такі сумні результати).
Недоліки:
- тестування тицяє вас носом у ваші ж помилки (це дуже неприємно);
- дуже вірогідно, що доведеться кавалок роботи переробити, а робити зовсім не хочеться;
- ви тестували не на персоні (представнику ЦА), тому є нюанси.
5-ти секундне тестування
Цей вид юзабіліті-тестування допомагає зрозуміти, чи передає дизайн потрібне повідомлення, чи справляє потрібне враження, або (сюрприз-сюрприз) змушує зізнатися, що наш дизайн комунікує геть не те, що треба.
Ідея в тому, що протягом п’яти секунд ви показуєте статичну картинку потенційному користувачеві. Потім забираєте її та розпитуєте піддослідного, що він запам’ятав і яке враження на нього справила картинка.
Якщо це сайт, то корисно поцікавитись, для чого, на його думку, цей сайт міг би бути призначений. Який настрій він створює, яке повідомлення транслює. Після того, як отримаєте відповіді, запитайте себе, чи цього ви добивалися своєю роботою. Бо якщо ви робите сайт для заводу, щоб презентувати ентерпрайз-рішення, а ваш дизайн створює настрій повітряності, легкості й взагалі він «стільний, модний, молодьожний», то це трохи ніби не те...
Трохи детальніше про фази готовності
Пам’ятаймо, швидше — краще. Fail fast, як каже Agile. Будь-яка фаза готовності означає: скетчі, чорно-білі статичні вайфрейми, зроблені в дерев’яному Balsamiq, чорно-білі чорнові прототипи та high fidelity fully clickable prototypes looking so good you’ll want to lick them.
Останній варіант, до речі, не радять. І я не раджу. Поки ви намахаєтесь з тим всім, возлюбите свій дизайн, зростетеся з ним воєдино... і тут бац, а ні чорта не працює. Боляче... Вмикається опір, захисні механізми організму, інстинкт самозбереження. На цій фазі вже шкода і страшно тестувати. Стільки роботи вкладено, а ну ж завалиться. Та й взагалі, до дідька то тестування... Яждизайнер. Всьо буде працювати.
Я найчастіше роблю швидкі вайфрейми в Balsamiq, компоную сякий-такий протопип в InVision і того досить. Не треба сітки, не треба все вирівнювати по півгодини, не треба бавитися зі шрифтами та кольорами. Бігом тестувати. Бо однак доведеться переробляти...
Чому не варто створювати для тестування «high-fidelity fully clickable prototypes looking so good you’ll want to lick them»
Відповідь із сюрпризом. Ви вже стратили купу часу на вилизування картинок, тінюшечки і градієнтики, скруглення і тренди. І це все дуже навіть можливо треба буде викинути саме тому, що воно виглядає надто реалістично. Угу, саме через реалістичність, яка викликає у користувача завищені очікування.
Коли користувач бачить такий прототип, то сприймає його як готовий продукт і відповідно з ним поводиться. Тобто починає тицяти куди попало. Звісно, нічого ще не працює, бо ви прописали лише один-два інтерактивні сценарії. У результаті ви чуєте щось на зразок: «Ну... Та що це... Ой! Та воно, ой, та воно взагалі не працює!. Та що за дурня?!». І неважливо, що хвилину тому ви попередили, що це лише прототип.
Про організацію, настрій і процес сесії тестування
Отож, алгоритм дій:
1. У вас вже є готовий скетч/вайфрейм/прототип.
2. Ви зупинились на «коридорному тестуванні».
3. Берете прототип (паперовий, веб чи мобайл).
4. Готуєте сценарій (завдання), яке має виконати користувач. Бажано прописане на чистому аркуші паперу. Можна й усно, але якщо зафіксувати письмово, то буде гарантія, що всі
5. Ловите людину на коридорі/кухні/деінде:
— Дизайнер:Привіт-привіт. А маєш пару хвилиночок?
— Користувач:Так, кажи. Що там?
— Д.:Я зараз працюю над дизайном продукту, суть якого, згрубша, зводиться до [бронювання кімнат в офісі]. Ми зараз на фазі тестування. Хочу попросити тебе побути нашим користувачем і допомогти протестувати рішення.
— К.:Давай, цікаво. Тільки якщо не дуже довго.
— Д.:Ок. Це прототип. Це не готовий продукт, а лише картинки, склеєні докупи. Тому не все працює і не все клікається. Важливо, щоб ти розумів: ми тестуємо не тебе, а наш дизайн. Ти не можеш зробити щось неправильно.Якщо в тебе щось не виходить, то це означає, що ми десь припустилися помилки й ти допоміг нам її знайти. І ще! Я попрошу тебе думати «вголос». Якщо ти чогось не розумієш чи маєш питання — кажи все вголос. Це для нас дуже важливо. Ну що? Почнемо? Тобі треба зарезервувати кімнату № 213 для себе і ще п’ятьох колег. Сьогодні о 15:30 на 1 годину. Що будеш робити?
Увага! Останній абзац дуже важливий. Ви маєте переконатися, що донесли до користувача думку, що ви тестуєте не його. Інакше людина може скуто себе почувати та поводитися зі страхом помилитися. Це не найліпшим чином впливає на сесію тестування.
А далі ви — мавпочка, яка все бачить, все чує, але нічого нікому не підказує. Свербить язик підказати? — Вкусіть себе за нього. Вдихніть глибоко. Робіть будь-що, аби змовчати.
Відповідайте питаннями на питання користувача.
— К.: А що буде якщо я?.. А що це?
Пауза. Довга пауза. Вдихаєте. Видихаєте. Якщо користувач все ще не знайшов відповідь сам, відповідаєте йому питанням.
— Д.: А як ти думаєш? А чому ти так думаєш?
Все. Ма-а-аксимум, що ви собі можете дозволити, — це підбадьорити невпевненого користувача: «Спробуй, може, воно клікається».
Щодо процесу. Ідеально, якщо дизайнерів двоє. Один, власне, проводить і фасилітує тестування, а інший стоїть збоку, спостерігає, мовчить і все записує. В куражі і потоці ви можете упустити щось суттєве і цінне.
Після кожної сесії тестування робіть невеличку паузу і все нотуйте. Після п’ятої сесії все в голові буде плутатися. Не надійтеся на пам’ять. Найтупіший олівець є гострішим за найгострішу пам’ять.
Ще чому краще, щоб вас було двоє, — таким чином усуваємо шкідницький людський фактор. Тріангуляція даних: два і більше методів у дослідженні краще, ніж один.
Якщо я тестую свій дизайн, який, звісно ж, прекрасний, і я в нього, звісно ж, закохана, то я схильна захищати його всіма силами та фібрами душі. Я можу поставити результат тесту «±» там, де насправді ближче до «-». Я можу не змовчати й підказати користувачу праведний шлях у моєму заплутаному інтерфейсі, я можу ще якось накосячити. Якщо поруч зі мною мій колега, то він — моя совість, злий поліцейський і янгол-охоронець чесного користувацького тестування.
У дизайн-школі вчать, що ідеальний ідеал — це тоді, коли одна людина робить дизайн, зовсім інша його тестує, а третя аналізує результати тестування. В цьому ланцюжку усі максимально незаангажовані, бо над проектом працює лише перший дизайнер. Кажуть, таким чином можна максимально уникнути злого суб’єктивізму. Але, якщо чесно, я так ніколи не робила, тому власним досвідом не поділюся.
На скількох користувачах варто тестувати дизайн (один тест-кейс)
На п’ятьох. Якщо результати спірні (50 на 50) — додайте ще
Стів Круг каже, що
Помилки, яких варто уникати:
- Тестувати на дизайнерах. Ви отримаєте дизайн рев’ю, але не результати користувацького тестування.
- Тестувати прототип мобільного Android-рішення на iOS і навпаки.
- Тестувати прототип мобільного iOS-рішення на людині, яка користується щодень Android і навпаки.
- Тестувати веб-прототип для Mac на користувачі, який щодень користується Windows і навпаки.
- Тестувати не в контексті. Якщо це веб, то тестуємо сидячи за комп’ютером. Але якщо це мобайл, то стоячи. А якщо це планшет, який буде висіти на стіні, то тестуємо на планшеті, який висить на стіні. Якщо апка для водія таксі, який їздить по бруківці, то тестуємо в машині, під час руху по бруківці.
Що почитати на тему
Steve Krug «Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems». Прекрасна книжка, яка читається за час одного авіаперельоту (не Львів-Київ).
Що ще? — Нільсона.
Післямова
У цій статті я свідомо не розказую про інші види серйознішого тестування, яке передбачає рекрутинг автентичних користувачів під персони (BTW, You are not responsible for personas you created :-)), купівлю техніки і програмного забезпечення для eye-tracking, запис відео, аудіо і курсор-трекінг зі всіх можливих ракурсів і кутів і багато іншого. Чому? Тому що в такому випадку стаття не називалася б «Про користувацьке тестування, доступне кожному». І у вас була би купа відмазок, чому не тестувати, а я хочу забрати у вас ці відмазки :-)
Успіхів! У вас все вийде.
In God I trust, the rest I test :-)
І пам’ятайте: UX without users is not UX :-)