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