Представьте, что вы подготовили идеальные сценарии, отобрали методики, нашли респондентов… И тут заказчик говорит: «Тестировать будем не приложение, а вот этот макет в Figma». Знакомая ситуация? Если нет, то считайте, что вам повезло. Если да, ознакомьтесь с материалом — уверен, что он будет полезен и поможет не наломать дров.
Меня зовут Дунько Харитон и я специалист по тестированию в “Лаборатории качества”. В этой статье на своём реальном кейсе покажу, почему юзабилити-тестирование (далее - ЮТ) является не просто «посмотреть, удобно ли», а полноценным расследованием с элементами психологии, аналитики и жесткого менеджмента. И что делать, если реальность вносит коррективы в ваши планы. Также расскажу почему общение с респондентами целевой аудитории важнее, чем технический аудит.
Юзабилити — это про деньги
Да-да, ЮТ — это про деньги. Деньги, которые бизнес обязательно получит, если посмотрит на приложение глазами его пользователей.
Чем же ЮТ отличается от классического тестирования приложения? Если функциональное тестирование отвечает на вопрос: «Работает ли это так, как написано в ТЗ?», то юзабилити ищет ответ на другой: «Понятно ли это реальному, живому человеку и готов ли он за это платить?».
ЮТ специфический вид работ, который требует от тестировщика не только знания техник (вроде эвристик Нильсена или GOMS-анализа), но и насмотренности, понимания психологии и, что важнее всего, умения правильно интерпретировать поведение пользователя.
Плохой юзабилити интерфейс может привести к значительным финансовым потерям и оттоку клиентов. Вот например, есть такой показательный случай, когда компания столкнулась с негативными последствиями из-за игнорирования пользовательского опыта. В 2020 году сотрудники Citibank (один из крупнейших международных банков, дочерняя структура финансовой корпорации Citigroup) из-за запутанного интерфейса системы Flexcube случайно перевели кредиторам около 900 миллионов долларов вместо запланированных 7,8 миллиона долларов. Суд постановил, что банк несёт ответственность за ошибки, вызванные неудобным интерфейсом.
Да и в целом исследования показывают, что 50% клиентов отказываются от использования нового продукта, если не разберутся с ними за первые 10 минут.
Кейс: платформа ITE Connect и её новый раздел
В компанию обратился заказчик — крупный организатор выставок в Российской Федерации с собственной платформой ITE Connect.
Передо мной была поставлена простая, но заковыристая задача — провести ЮТ нового раздела их приложения. Функциональность раздела включала в себя систему рекомендаций, которая на основе анализа сканированных QR-кодов (со стендов, бейджей) предлагала участникам мероприятия наиболее релевантные деловые контакты.
Цель звучала просто: понять, насколько функциональность «зайдет» пользователям, решает ли она их задачи и нужны ли им подсказки. И, самое главное, необходимо ли далее тратить ресурсы на ее разработку и совершенствование.
Как уже опытный QA-инженер, я сразу разделил проект на три этапа:
1. Анализ бизнес-метрик, которые должны вырасти после внедрения доработок.
2. Техническая проверка по гайдлайнам и эвристикам.
3. «Полевой» этап — интервью с реальной целевой аудиторией.
Подготовка
К выбору методик я подошел скрупулезно. Из всего арсенала, применяемого в ЮТ, выбрал только то, что реально сработает в условиях специфики задачи:
- Think-aloud («Подумай вслух») — чтобы увидеть логику пользователя.
- Time to Done — замерить скорость выполнения ключевых сценариев.
- Cognitive walkthrough — оценить, насколько просто освоить раздел, когда пользователь видит и взаимодействует с ним впервые.
- Эвристики Нильсена, гайдлайны iOS/Android/Google — база для анализа интерфейса.
Инструменты — стандартный джентльменский набор: Google Meet, OBS для записи, Google-таблицы и Figma.
Борьба за качество и здравый смысл
И тут случилось то, что заставило меня пересобрать процесс. Заказчик сообщил: «Работать будем не с живым приложением, а с кликабельным прототипом».
Для тех, кто не в курсе отмечу: тестировать юзабилити на прототипе — все равно что выбирать машину по картинке на сайте. Это жестко ограничивает сценарии, не позволяет пользователю ошибаться и не дает увидеть реальное поведение системы в ответ на нестандартные действия. И, конечно же, не позволяло провести качественное и объективное ЮТ.
Пришлось объяснить заказчику все риски таких тестов. И здравый смысл восторжествовал — он доработал прототип до состояния, при котором ЮТ, хоть и в усеченном виде, но можно было проводить (добавились схемы переходов и логика состояний). Лишь после этого я смог приступить к проверке по эвристикам Нильсена и гайдлайнам.
К слову, о Нильсене. Из его 10 принципов часть (например, «помощь в исправлении ошибок») к разделу просто не могла применяться. В итоге подготовил чек-листы соответствия как эвристикам, так и гайдлайнам iOS/Android/Google.
И уже на этом этапе я отчетливо видел проблемные места нового раздела и пути решения этих проблем. В последующем мои предположения полностью подтвердились, когда прогонял сценарии на своих коллегах.
Целевая аудитория
Параллельно с технической проверкой начал готовиться к интервьюированию целевой аудитории. На мой взгляд, именно эта часть ЮТ наиболее важная и ответственная.
А вот поиск целевой аудитории тот еще квест и обусловлен рядом факторов (специфика приложения, опыт его использования, социально-демографические показатели и т.п.). Обычно целевую аудиторию подбирает исполнитель ЮТ. Но на этом проекте респондентов выбирали не мы.
Целевую аудиторию составляли люди, которые ранее пользовались приложением заказчика, а это как правило представители российского среднего и крупного бизнеса, в т.ч. представители иностранных компаний. Эту часть работы заказчик взял на себя и по поиску 10-12 реальных пользователей.
Моя же подготовка включала следующее:
1. Сценарии. Создал 26 ключевых вопросов-сценариев, которые покрывали все возможные действия в прототипе.
2. Пилот. Прогнал сценарии на себе и коллегах из моей компании. Это помогло отсечь лишнее и замерить тайминг.
3. Анкеты. Их создал три типа:
- «По словам» — пользователю после прохождения сценариев необходимо было выбрать пять слов, описывающих ощущения от интерфейса.
- «По удобству» — классическая оценка утверждений.
- «Субъективная» — только ответы «да» или «нет». Причём любой «нет» — красный флаг для приложения.
4. Памятка респонденту. Чтобы к началу интервью у всех всё работало, и технические проблемы не смазали картину.
Особое внимание уделил вводной части, где определил, что наше главное правило - расслабить респондента. А для этого перед интервью необходимо было четко проговорить, что у нас не экзамен, а я проверяю приложение, а не респондента. При этом ошибаться можно и нужно, так как именно это для нас самое ценное.
В итоге, процесс работы с целевой аудиторией был отлажен как часы: вступительная речь → проверка связи и записи экрана → предупреждение о записи → ссылка на прототип → 26 сценариев с комментариями «вслух» → три анкеты → благодарность и стоп записи.
Тренды и фишки из мира IT,
экспертные статьи и всё о тестировании.
Финальный аккорд (которого пока так и не случилось)
Я был готов (все сценарии выверены, анкеты сверстаны, записывающая аппаратура настроена) и горел желанием наконец-то поговорить с живыми людьми. И тут…
Заказчик сообщает, что не смог найти респондентов. Никто из целевой аудитории не захотел. Планы изменились и проект ставят на паузу. «Дорогой дневник, мне не передать ту боль…» — это был моя первая реакция. Весь объем подготовительной работы, чек-листы по эвристикам, наработки по анкетам — всё легло до времени на полку.
Итоги или to be continued?
Чему нас научил этот кейс?
1. Юзабилити — это про живых людей. Без них теряется смысл. Можно хоть сто раз проверить интерфейс по гайдлайнам, но только пользователь скажет, почему кнопка «Поделиться» бесит его до зубной боли.
2. Прототип — однозначно не замена приложению. Если вы тестируете на кликабельной картинке, вы не узнаете о проблемах с производительностью, вылетах или «залипаниях». Это тестирование гипотез, но не готового решения.
3. Бизнес непредсказуем. Даже при идеальной подготовке проект могут поставить на стоп-паузу. И это нормально. Ваша задача — сделать так, чтобы в момент «паузы» у заказчика на руках был максимально полный объем данных для размышления.
Наше сотрудничество с заказчиком по данному проекту приостановлено, но не завершено.
Я искренне надеюсь, что через время проект оживет и я всё-таки проведу те интервью, к которым так тщательно готовился. А пока я доволен проделанной работой. Это был бесценный опыт, который еще раз подтвердил: в тестировании в целом и в ЮТ в частности не бывает нерелевантного опыта. Всё, что вы знаете о людях, бизнесе и даже маркетинге с продажами, однажды сыграет вам в плюс.
Если вы узнали в этой истории свой проект и не хотите, чтобы он завис на полпути — приходите, поможем дойти до логического финала. А если вы пока только задумываетесь о юзабилити-тестировании, начните с главного вопроса: готовы ли вы услышать правду о своем продукте? Даже если она будет неудобной. Ведь сэкономив тысяч рублей (в т.ч. время, ресурсы и деньги) можно потерять миллион.
p.s. Я не стал специально углубляться в этой статье в дебри каждой из методик данного вида тестирования. Для этого потребуется еще не одна статья. Если хотите деталей — пишите в комментариях, разберем любую из них детально.
