Эти волшебные юзабилити-тесты • 2
Продолжение, начало смотрите здесь.
Миф 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% проблем остаются с прошлого раза.
Что делать → Если намечается регулярная поддержка продукта в виде теста — не пропадать на эти самые полгода-год, и не повторять потом стандартные тесты с одинаковыми заданиями. А попытаться договориться на более частые промежуточные экспертные экспресс-оценки и корректировку дизайна теста перед каждым запуском.
Чем чревато → Не каждый заказчик будет готов включить тебя в свой цикл разработки и поддерживать рабочий контакт. В итоге ему будет пофиг, и ты всё равно будешь тестировать продукт с теми же проблемами, что и в прошлый раз. Расслабься, мир не совершенен.
Резюме
В итоге, пожалуй, самый главный общий совет — помнить, что ты как подрядчик должен пушить проект, образовывать заказчика и предлагать ему оптимальные варианты. А не просто бездумно шпарить тесты и со всем соглашаться.
И если проект достаточно большой и/или нестандартный — стоит перед началом планирования (даже не фактической работы) попытаться договориться, и провести у заказчика мини-семинар на час-полтора, где рассказать, кто мы, что будем делать, для чего, как использовать результаты, и как развиваться в дальнейшем.
Этот список мифов, кстати, вполне можно использовать как частичный чек-лист для такой встречи.
