Эти волшебные юзабилити-тесты
Некоторое время назад я помогал коллегам в продаже и планировании проекта. У заказчика был большой сервис, доступ через веб, много трафика, как покупного так и нативного — классика, короче.
Задачу озвучили как «провести фокус-группу, подтвердить гипотезы и увеличить конверсию». Именно в таких формулировках.
По факту оказалось, что под «фокус-группой» понималось юзабилити-тестирование.
В ходе общения раскопались интереснейшие залежи представлений, мифов и ожиданий от результатов работы. И я поймал себя на том, что всё чаще в последнее время встречаюсь с удивительными химеричными представлениями о проведении юзабилити-аудита и вообще пользовательских исследований. Это особенно интересно, потому как ситуация противоречивая: рынок развивается, слово «юзабилити» лезет изо всех щелей и только ленивый не стал супер-пупер-специалистом в UX/UI. Казалось бы, общий уровень знаний должен вырасти. А на деле — не так.
Для себя я объяснил это тем, что раньше никто ничего не знал и даже не делал вид, что знает: область юзабилити была совершенно новой и далёкой от интересов большинства. Сейчас же весь этот UX стал вроде как мэйнстримом, и ux-дизайнеры расплодились просто с невероятной силой. Причём по причинам, не всегда связанным с развитием в себе ux-экспертиз (не могу не вспомнить свой же доклад в Минске 2 года назад: https://vimeo.com/86022013).
И вроде как каждый должен что-то в этом понимать, но желания/возможности получить более-менее структурированную информацию нет. Вот и нахватываются по верхам, транслируют мифы друг другу, а признать, что не во всём разбираешься — уже не комильфо, UX же в тренде.
Мы стали разбираться, какие основные мифы и странности (для нас как для подрядчиков) в отношении юзабилити-тестов встречаются у клиентов. И я решил вытащить эти соображения наружу. Прекрасно, если меня дополнят и поправят где надо — всем польза.
Итак,
Основные мифы о юзабилити-тестах
Миф 1. Юзабилити-исследование (аудит) — конечный результат работы, который мистическим образом улучшит конверсию, увеличит удобство, вызовет счастье у директора и т.д.
На самом деле → Исследование — это диагностика, а не лечение. И в большинстве случаев найденные проблемы необходимо будет исправлять и тратить на это ресурсы. Иногда (о ужас!) по результатам исследования даже может быть непонятно, как именно исправлять проблему.
Что делать → Показывать этапы проекта в целом, обозначая исследование как первый этап. Даже если остальные этапы — не ваши. Более того, на этой стадии я бы даже не педалировал дальнейшие продажи.
Чем чревато → Клиент уйдёт, осознав, что запланированных ресурсов не хватит для конечного результата. И что всё не так, и быстрого/дешёвого результата не достичь.
Миф 2. Основной результат аудита — конкретные рекомендации, а то и прототипы/дизайны, в которых однозначно показано, что и как дальше делать. И эти рекомендации будут учитывать все ограничения и особенности платформы/реализации/команды/гороскопа.
На самом деле → Рекомендации должна давать команда, которая занималась проектированием и разработкой. А вот на входе у неё должен быть качественный перечень проблем, структурированный, отсортированный, с весами и рядом необходимых параметров.
Проведу параллель с медициной. Вспомните: исследования типа анализа крови, рентгена или МРТ делают одни специалисты , а лечение назначают, глядя на результаты, другие (врачи уже).
Внешняя команда может что-то упустить (ок, она БУДЕТ что-то упускать) из технологий, ограничений, решений и принципов работы. И для дизайнеров со стороны клиента эти рекомендации на 50% окажутся бесполезными, и более того — будут выглядеть просто идиотскими. Типа «да, каждый идиот понимает, что нужно выводить эту информацию, но платформа просто не позволяет».
Пример: пока несколько лет назад мы не влезли с головой в технологию заказа авиабилетов через метапоисковики, мы и не подозревали, что каждый запрос к базе (Amadeus, например) стоит денег. И чтобы сэкономить — результаты кэшируются. И если цена, показанная поисковиком, иногда меняется при переходе на сайт перевозчика — это не потому, что все вокруг уроды с кривыми руками. До сих пор периодически встречаю «аналитику с рекомендациями», где советуют убрать этот «баг» и давать точные цены. Да, очевидно, что лучше всегда иметь актуальные данные, но в условиях конкретных ограничений, которые известны тем кто «в теме», такие советы, особенно в безапелляционной форме, выглядят идиотскими.
Таких нюансов — масса. И все их учесть может только тот, кто делал продукт. Но это совсем не значит, что нельзя помочь решением, а не только диагнозом.
Что делать → Для начала явным образом выделять этап диагностики БЕЗ рекомендаций. После его завершения проводить дебрифинг, обсуждать возможные направления по корректировке проблем с разработчиками/дизайнерами со стороны клиента. И потом готовить рекомендации в связке с ними, как минимум — устраивая 1–2 согласования.
Чем чревато → Клиент пойдёт выбирать более «профессиональных» подрядчиков, которые сразу выдают решения и рекомендации в режиме «чёрного ящика». Которые не лезут в процессы и сценарии, а критикуют микродизайн. Такие при прочих равных дешевле.
Миф 3. Слепая вера в «статистику», требование точных цифр и их дальнейшее использование в качестве аргументов. Например, из юзабилити-теста мы должны понимать, что 72.65% аудитории тратит на выполнения ключевого сценария 4 мин. 33 сек.
На самом деле → Лабораторное юзабилити-тестирование — это качественный тест. И погрешность определенных величин в некоторых случаях может достигать десятков процентов. Тогда о каких сотых долях мы говорим? Это просто смешно.
Особенно странным выглядит желание делать выводы, опираясь на точность абсолютных величин. Время, например, или эффективность (привет Шнейдерману). Всё-таки юзабилити-тест — достаточно искусственный эксперимент. В нём и мотивация у респондентов не вполне естественна, и искажающих факторов море. Например, та же рефлексия и болтовня при методе Thinking Aloud отнимает заметное время.
При всём этом метрики — полезны, важны и могут дать множество полезной информации.
Что делать → С умом выбирать метрики и заранее согласовывать с клиентом. Знать основы статистики и правильно рассчитывать значения метрик. И помнить: как правило, относительные показатели полезнее абсолютных.
Чем чревато → Клиент может не захотеть менять свои убеждения относительно нужных метрик, и будет настаивать и раздражаться. Особенно если клиент маркетолог. Или укушен маркетологом.
Хотя справедливости ради — большинство прислушиваются к рациональным комментариям. У нас был клиент, который специально просил не показывать статистику, чтобы она не была инструментом продавливания того или иного решения (так как инструмент неточный). Но это была западная ux-компания. Которая, кстати, своему клиенту даже частотность проблем не показывала.
Миф 4. Фактически продолжение предыдущего пункта. Выбор традиционных показателей всегда и везде в качестве основных метрик. Среди таких — скорость работы или количество кликов, например.
На самом деле → Количество кликов не всегда важно, как и скорость выполнения операций. Вообще ключевые метрики зависят много от чего: типа сервиса, частоты сценариев, контекста, социального окружения, настроения в конце концов.
Сейчас с развитием скорости доступа, а также технологий типа AJAX, значимость количества кликов явно уменьшается. В мобильных интерфейсах кликов всё равно больше — так как квант интерфейса меньше. И ничего: можно жить, и даже быстрее жить.
То же самое с временем. Если я работаю в системе раз в полгода, и время не критично для самой конкретной операции — мне пофиг, сделаю ли я её за 3 минуты или за 5. Количество ошибок, например, или степень фрустрации могут быть куда важнее.
Что делать → Вполне очевидно — плясать от задач и сценариев и думать головой.
Чем чревато → Всё равно придётся мерить клики, если клиента не убедили. Хотя лучше мерить всё по-максимуму, информация полезна всегда. Главное — какие выводы потом из неё делать.
Куда страшнее, если потом оптимизировать продукт придётся под количество кликов, например, если критична безошибочность. Но это, как говорится, уже совсем другая история ;).
Миф 5. Тестируем функции продукта, а не сценарии пользователя и способы решения задач. Например, «найти проблемы в поиске с фильтрами».
На самом деле → Вообще-то главное, чтобы пользователь решил свои задачи и достиг цели. Потратив минимум ресурсов как своих, так и сервиса. Если он при этом не будет пользоваться поиском — ну что ж, значит ему удобнее по-другому. И если таких будет 10 из 10 — прекрасно, значит так удобно большинству. И как я узнаю проблемы поиска, если проблема в том, что поиск тут никому не нужен?
Конечно, я могу напридумывать искусственных сценариев, которые покажут, как люди работают с поиском. Но это ещё больше снизит точность эксперимента — им ведь это не надо на самом деле. Они будут пользоваться поиском лишь потому, что просит модератор.
Вообще это частая проблема, когда юзабилити-исследователей воспринимают примерно как технических тестеров. Вот вам набор функций и фич — скажите, что работает, а что нет. И почему. И что делать. И немедленно. Причём «работает» в техническом понимании, пусть и в связке с пользователем, а не в смысле «востребовано и эффективно» и «помогает достигать целей».
Что делать → Сперва согласовывать цели бизнеса относительно связки «сервис-пользователь», а уж потом переходить к заданиям. При подготовке и согласовании сценариев и заданий на тест последовательно спускаться от целей к задачам и сценариям. Тогда трудно будет порушить логику. Но возможно, к сожалению :).
Если у клиента многоуровневая система согласований и перечень функционала для тестирования спущен сверху и согласован заранее — беда-беда. Придется пробовать от сценариев подняться к целям. Иногда удаётся подсунуть эти цели заказчику так, что он примет их за собственное творение.
Чем чревато → Придётся тестировать поиск, которым никто не пользуется. Но это полбеды — из-за этого у нас может не хватить ресурсов протестировать действительно важные вещи.
