Проведение юзабилити-тестирования прототипов мобильного приложения

Почему юзабилити-тестирование мобильного приложения находят поздно

Первые секунды решают: если пользователь не понимает первый экран, дальше он просто не идёт. Узкие места первого экрана — неочевидная подпись на главной кнопке, обязательная регистрация до первого результата, лишний шаг между запуском и ценностью — стоят дороже всего, потому что отвал на онбординге случается раньше, чем приложение успело что-то показать.

Находят это поздно: сборка уже в магазинах, часть трафика ушла, а команда обсуждает симптом вместо причины. Аналитика показывает, на каком шаге люди закрывают приложение, но не отвечает, почему — цифры по событиям не объясняют, что именно в интерфейсе сбило человека с толку.

В спорных решениях без данных побеждает тот, кто громче настаивает: где основная кнопка, сколько полей в форме, какой текст на стартовом экране. Поздние правки интерфейса тянут за собой пересборку, повторную проверку в магазинах, регресс смежных сценариев и перестройку разметки событий — цикл растягивается, а уже пройденные проверки приходится повторять частично.

На прототипе та же ошибка стоит одного разговора: интерактивный макет, пять-восемь человек на типовых задачах, и узкое место видно до первой строки кода. Разбираем, как это закрывается в юзабилити-тестировании мобильного приложения и что именно проверяем на первой итерации.

Эффект от ранних правок: что меняется в разработке

Решение, которое стоит переписать в релизе, на прототипе стоит одного перерисованного перехода. Правка здесь занимает часы, а не недели — и не тянет за собой соседние экраны, аналитику и автотесты. Ниже — четыре эффекта, которые видно в метриках разработки, а не только в отчёте о тестировании.

Скорость итераций: круг правок за день

Цикл «гипотеза → кликабельный прототип → наблюдение → правка» укладывается в один-два дня, включая повторный прогон на новой выборке. Тот же цикл на этапе кода требует сборки, ревью, прогона регресса и повторной выкладки — и растягивается на неделю и больше. Чем раньше круг, тем дешевле следующая версия макета.

Класс дефектов интерфейса, который не рождается

Неточная зона нажатия, неочевидный возврат назад, потеря состояния при повороте экрана, тупик в форме — эти дефекты воспроизводятся уже на прототипе и закрываются до первой строки кода. Дальше они не переносятся в список задач с пометкой «потом»: под них не пишут обходные проверки и не расширяют обработку ошибок. Именно этот класс дефектов даёт основную долю переделок в релизных сборках.

Трудоёмкость доработок: одна правка вместо пяти связанных

Смена навигации в готовом приложении тянет экраны, состояния, логику возврата и тесты — от трёх до пяти связанных задач на одного инженера. На прототипе это один перерисованный переход, который проверяется в тот же день. Итог — переделок в релизе меньше, а освободённое время уходит на функциональность, которую нельзя проверить макетом.

Доля успешных сценариев как критерий приёмки

Замер до правок: сколько участников проходят ключевой путь без подсказки. После — повторный замер на сопоставимой выборке. Рост с примерно двух третей до девяти из десяти означает, что спор «нравится / не нравится» заменяется числом, а решение о заморозке макета принимается по метрике, а не по вкусу. Повторить замер можно на каждом новом прототипе — это встроено в процесс.

Как выбрать формат тестирования прототипа

Формат проверки выбирают не по удобству команды, а по вопросу, на который нужен ответ. Пока сценарий не зафиксирован, работают модерируемые сессии: модератор видит, где участник замирает на экране, и сразу выясняет причину — именно такие заминки не ловятся постфактум. Когда навигация уже стабильна, дешевле набрать объём немодерируемой проверкой: сценарий расходится по ссылке, записи собираются без наблюдателя, как в Maze, а на разбор уходит один проход по записям.

Форматы не заменяют друг друга, а закрывают разные этапы. Типовой порядок такой: эвристическая оценка и коридорный тест на раннем прототипе, затем модерируемые сессии на 5–8 участниках по критичным сценариям, и только потом немодерируемая проверка с аналитикой поведения на масштабе. На каждом шаге фиксируем, какие заминки считаем блокирующими, — иначе список замечаний растёт, а решение по макету не принимается.

Этапы работы: от аудита сценариев до передачи отчёта

Процесс строим так, чтобы каждая сессия давала проверяемый результат, а не общие впечатления тестирующих. До первого респондента фиксируем гипотезы и метрики — иначе находки не с чем сравнивать и нечем обосновывать приоритет правок.

1. Аудит пользовательских сценариев. Разбираем прототип по экранам и выписываем ключевые пути: вход, первый заказ, повторное действие, возврат. Отмечаем рискованные места и формулируем гипотезы, которые проверим на людях.
2. Схема и подбор респондентов. Задаём задачи, критерии успеха и провала, роль модератора. В выборку берём людей по профилю аудитории, включая тех, кто не видел продукт — их поведение показывает проблемы интерфейса, а не память о прошлой версии.
3. Протокол сессии. Единый шаблон на все встречи: время на задачу, число ошибок, точки возврата, комментарии вслух. Общий протокол позволяет складывать наблюдения в одну таблицу и видеть повторяющиеся проблемы, а не единичные мнения.
4. Проведение сессий. Модератор не подсказывает и не защищает решение, только ставит задачу и уточняет, что пользователь думает в момент затруднения. Запись экрана подтверждает выводы фактами, а не пересказом.
5. Приоритизация находок. Каждой проблеме присваиваем частоту проявления, влияние на ключевой сценарий и трудоёмкость правки. Делим на блокирующие, мешающие и косметические — и в этом порядке отдаём в работу.
6. Критерии готовности и передача. Критерии задаём заранее: доля респондентов, проходящих сценарий без критичных ошибок, время на задачу, число обращений за подсказкой. Изменённые экраны прогоняем повторно, а на выходе отдаём отчёт с картой сценариев, записями сессий, списком правок и приоритетами.

Материалы на выходе: отчёт, записи сессий, реестр правок

Результат юзабилити-тестирования — не презентация с выводами, а набор рабочих артефактов, по которым команда правит прототип без дополнительных уточнений. Мы отдаём материалы в том виде, в котором ими удобно пользоваться: отчёт читает руководитель направления, реестр правок ведёт руководитель проекта, записи сессий смотрят дизайнер и разработчик, когда нужно увидеть поведение участника своими глазами.

• Отчёт о находках — по каждому сценарию: на каком шаге участник останавливался, что пытался нажать, сколько времени ушло на задачу и где решение принималось наугад.
• Записи сессий с таймкодами — привязка эпизодов к конкретным экранам, чтобы не пересматривать весь материал ради одного случая.
• Реестр правок — таблица «находка / критичность / участок интерфейса / владелец / статус», пригодная для ведения до релиза.
• Карты путей и тепловые карты по экранам прототипа — видно, куда участники смотрели и где проходили мимо нужного элемента.
• Сценарии, гайд модератора и согласия участников — исходники, чтобы повторить проверку на следующей итерации без переписывания методики.
• Регламент повторных проверок — какие сценарии перепроверяем после правок, на какой выборке и по каким метрикам считаем задачу закрытой.
• Передача материалов команде — разбор с дизайнером и разработчиками: проходим по реестру, отвечаем на вопросы по записям, фиксируем, что берём в ближайшую итерацию.

Доступы к записям и отчёту остаются у вас: материалы хранятся в вашем рабочем пространстве, а не у нас.

Кейс: сколько проблем нашли до разработки и что изменилось

Тестировали не готовое приложение, а кликабельный прототип: два ключевых сценария — первое оформление заказа и повторная покупка — прошли 12 участников, по 6 на каждой мобильной платформе. Сессии модерировали удалённо, часть — через Maze, чтобы не собирать людей в офисе и не растягивать сбор данных на недели. Фиксировали не мнения, а точки отказа: где участник замирал, откатывался на шаг назад или звал помощь.

Что показали сессии

Всего нашли 27 проблем, из них 9 критичных: неочевидный выбор адреса, потеря способа оплаты при возврате в корзину, отсутствие понятного выхода из формы. На прототипе каждая стоила правки макета, после релиза — переписывания логики экрана и повторной выкладки.

Что изменили

Переставили шаг ввода адреса до выбора товара, вынесли оплату на отдельный экран с явным возвратом, добавили подсказки на первом запуске. Повторное тестирование на тех же сценариях подтвердило: время прохождения сократилось вдвое, доля успешных задач выросла до 92%. Обращения в поддержку по навигации упали вчетверо — правки на прототипе обошлись заметно дешевле, чем те же исправления после релиза в магазинах приложений.

Что делать, если прототип уже согласован и передан в разработку

Согласованный прототип проверяет логику экранов, но не поведение сборки: клавиатура перекрывает поле ввода, запрос разрешения появляется раньше, чем пользователь понял, зачем он нужен, а прерывание звонком возвращает приложение в неверное состояние. Поэтому проверка на позднем этапе не дублирует прежнюю — она отвечает на другой вопрос: удержится ли решение в реальных условиях.

Проверка готовой сборки идёт на живых пользователях и их устройствах, а не на макетах: 5–7 человек из целевого сегмента, не вопросы, а задачи — зарегистрироваться, оформить заказ, восстановиться после ошибки. Фиксируем время до первого осмысленного действия, долю пройденных сценариев, число возвратов назад. Места, где пользователь замирает, видны по паузам и лишним нажатиям точнее, чем по прямым жалобам.

Встраивание в текущий цикл не требует останавливать разработку. Достаточно двух режимов: сессия на предрелизной сборке перед выпуском и короткие регулярные проверки — раз в итерацию по 5 человек, с разбором результатов в течение пары дней, пока контекст свеж.

Исправить ещё можно многое: тексты и подписи кнопок, порядок шагов внутри экрана, размер и расположение зон нажатия, формулировки ошибок, состояния загрузки и пустые состояния, момент запроса разрешений, подсказки при первом входе. Навигационную структуру и сценарии оплаты целиком здесь не переделывают — такие правки дороже и уходят в следующую крупную версию сборки.

Проверка не заменяет проектирование, но снимает отказы, о которых пользователи не сообщают: они просто закрывают приложение и не возвращаются.

Технические сомнения: отвечаем на частые вопросы

Сомнения по юзабилити-тестированию прототипов касаются не метода, а доверия к результату: хватило ли выборки, не подсказал ли ведущий, воспроизведутся ли находки. Ниже — ответы на вопросы, которые чаще задают перед стартом.

Не исказит ли ведущий поведение участника?

Влияет, поэтому задачи даём как цель, без подсказок и названий кнопок. Фиксируем время до первого действия и число ошибок, а записи размечает второй наблюдатель — расхождения в трактовке выносим на разбор.

Дистанционные сессии дают тот же результат?

Дают, если участник работает на своём устройстве, а идёт запись экрана и лица. Сценарии с камерой, офлайн-оплатой или оборудованием выносим в выездные сессии — там физический контекст важен.

Как понять, что находки не разовые?

Наблюдения кодируем в единую схему, а не храним как заметки. В план правок идёт то, что встретилось у трёх и более участников из разных сегментов; после доработок прогоняем тот же маршрут и видим, что барьер снят.

Какой доступ к данным нужен от нас?

Достаточно тестового аккаунта с нужной ролью и обезличенных событий по ключевым экранам. Работаем в отдельном окружении, доступы выдаём на время и закрываем по завершении, на инженеров — соглашение о неразглашении.

Расскажите о прототипе — вернёмся с планом проверки

Чтобы вернуться с планом проверки прототипа, а не с общими соображениями, нам нужен минимум от вас: ссылка на прототип или набор экранов, какие сценарии использования в приоритете и какую гипотезу проверяем — где, по вашим ощущениям, пользователи спотыкаются. Этого достаточно, чтобы собрать схему сессий и распределить время под вашу задачу, а не по шаблону.

Что вы получите вместе с оценкой:

• план проверки прототипа: какие экраны и переходы смотрим, в каком порядке и что считаем провалом сценария;
• сценарии задач — формулируем под реальные цели пользователя, без подсказок в тексте задания и без наводящих вопросов в процессе;
• сроки сессий и расписание: длительность одного прогона, число прогонов на сценарий, отдельное время на разбор записей;
• состав участников — какие роли привлекаем, сколько человек даёт устойчивую картину и почему малая выборка здесь врёт;
• формат отчёта: таблица по задачам, записи сессий, разбор критичных мест с приоритетами правок — от блокирующих до косметических;
• протокол наблюдения: где человек останавливается, сколько шагов уходит до цели, какая доля задач закрыта без помощи ведущего.

Опишите задачу — вернёмся с оценкой, схемой сессий и планом проверки прототипа. Если прототип ещё не готов, разберём, что в нём должно быть к первой сессии, чтобы выводы не пришлось перепроверять на следующей итерации.