Когда команда смотрит макет, экран выглядит законченным: сетка ровная, цвета согласованы, кнопка на месте. Но это проверка работы автора, а не пользователя. Представьте, что человек впервые открывает карточку услуги и хочет записаться на вторник после 18:00. Он нажимает «Подробнее», возвращается, листает экран и спрашивает, где запись. Если показать нужную кнопку, путь завершится, но интерфейс ещё не выдержал проверку без автора. Для продукта такой тупик означает несостоявшуюся запись; для команды это спор о внешнем виде вместо проверки.
Проверить такой риск можно без лаборатории. Нужны один экран, одна правдоподобная задача, человек из вероятной аудитории и 15 минут наблюдения. Ниже вы получите сценарий, лист заметок и правило приоритета. Это микро-тест одной задачи на одного участника, а не аудит всего приложения: повторите сценарий с несколькими подходящими людьми, найдите паттерн, измените один барьер и проверьте снова.
Как проверить UX мобильного приложения: короткий ответ
Дайте вероятному пользователю одну конкретную и правдоподобную задачу, но не называйте кнопку или маршрут. Заранее определите, какой результат считается завершением. Пока человек действует, не объясняйте экран: запишите успех без помощи, неверные нажатия, возвраты, заметные паузы, вопросы и точный текст любой подсказки. После задачи уточните, что человек искал и чего ожидал.
Повторите тот же сценарий в отдельных сессиях с несколькими людьми из нужного сегмента. Если один барьер воспроизводится, сформулируйте гипотезу, измените один основной механизм, например подпись, иерархию или положение действия, и проверьте новую версию с другими участниками. Так вы диагностируете понятность одной задачи. Вы не доказываете качество всего приложения, распространённость проблемы или рост конверсии.
Почему вопрос «вам нравится?» не отвечает на вопрос о UX
Визуальное впечатление важно. Оно влияет на доверие, узнаваемость и субъективную удовлетворённость. Но ответ «красиво» не показывает, заметит ли человек главное действие, поймёт ли подпись и сможет ли восстановиться после ошибки. Обратное тоже верно: экран может быть понятным, но выглядеть неуместно для бренда. Это разные сигналы, их не нужно сталкивать.
Стандарт ISO 9241-11:2018 связывает удобство использования с заданными пользователями, целями и контекстом и рассматривает результативность, эффективность и удовлетворённость. Практический смысл простой: мнение о внешнем виде полезно, но оно не заменяет выполнение задачи в нужном контексте.
| Что спрашиваем или наблюдаем | Что узнаём | Чего не узнаём |
|---|---|---|
| «Вам нравится экран?» | Субъективное впечатление и предпочтения | Сможет ли человек пройти задачу без помощи |
| Одна нейтральная задача | Как человек ищет действие и где встречает барьер | Насколько проблема распространена во всей аудитории |
| Успех после подсказки | Какой помощи не хватило самому интерфейсу | Прошёл бы человек путь без автора рядом |
| Успешный путь без покупки | Что интерфейс понятен в этой задаче | Подходят ли цена, ценность, условия или предложение |
Сначала дайте человеку цель, а не маршрут
Хорошая задача описывает правдоподобную ситуацию и результат. Она не содержит название элемента, положение на экране или последовательность нажатий. Руководства GOV.UK и Digital.gov рекомендуют давать участнику ясную, реалистичную и ненаводящую задачу, а исследователю в основном наблюдать и слушать.
Наводящая формулировка
«Нажмите кнопку “Записаться” и выберите вторник после 18:00».
Нейтральная формулировка
«Представьте, что вы впервые открыли приложение и хотите записаться на услугу во вторник после 18:00. Покажите, как вы бы это сделали».
До встречи запишите конечный результат, то есть границу успеха. Например: человек без помощи запускает запись и доходит до подтверждения выбранного времени. Если у вас только статичный макет одного экрана, честная граница уже: вы проверяете первый выбор и ожидание следующего шага, а не весь путь записи.
Участник должен быть похож на актуального или вероятного пользователя и не знать макет. Дизайнер проекта, разработчик и близкий коллега помнят замысел и редко подходят для этой роли. Сегмент тоже важен: случайный новичок ничего не докажет о продукте для опытных операторов, а группа без пользователей вспомогательных технологий не отвечает на вопросы доступности.
Что подготовить до звонка или встречи
- одну версию экрана, прототипа или сборки на весь раунд;
- одну задачу и заранее записанный результат, который считается завершением;
- телефон или устройство, похожее на реальный контекст использования;
- таймер, лист наблюдений и код участника вместо лишних персональных данных;
- согласие на запись экрана и голоса, если вы планируете запись;
- резервную ссылку или способ продолжить, если тест идёт удалённо.
Во время задачи молчите и записывайте действия
В начале скажите: «Мы проверяем экран, не вас. Ошибки здесь дают информацию команде. Я в основном буду молчать. По возможности говорите вслух, что ищете и чего ожидаете». После этого дайте задачу дословно и включите таймер.
Самое трудное для модератора: не спасать знакомый экран. Если участник спрашивает «сюда нажать?», можно ответить: «Поступите так, как поступили бы, если бы меня рядом не было». Если без помощи продолжить невозможно, дайте минимальную подсказку и запишите её дословно. В отчёте это уже успех после помощи, а не успех без помощи. Такой разрыв предусмотрен и в формате отчётности NIST Common Industry Format.
Какие сигналы отмечать
- первое действие и экран, с которого оно сделано;
- неверные переходы, повторные нажатия и возвраты;
- просьбы о помощи и точный текст подсказки модератора;
- заметные интервалы пауз с точной отметкой времени;
- способ восстановления после ошибки;
- конечный исход: завершено без помощи, после помощи или не завершено;
- дословные слова участника, отдельно от комментария команды.
Пауза служит сигналом для уточнения, а не готовым диагнозом. Человек мог читать, ждать отклика или вспоминать условие задачи. Время тоже не является универсальным приговором: оно полезно в сравнении с заранее определённой целью и контекстом, а не как абстрактный норматив. Сначала смотрите, затем спрашивайте: «Что вы искали в этот момент?» и «Что ожидали после нажатия?»
Отделяйте факт от гипотезы
Факт: участник нажал «Подробнее», вернулся, пролистал экран и спросил, где запись.
Гипотеза: главное действие проигрывает вторичному по подписи или визуальной иерархии.
Изменение для проверки: дать главной кнопке ясный глагол и визуальный приоритет, затем повторить ту же задачу с новым участником.
Не пишите «пользователь не понял», если наблюдали только молчание. Не пишите «кнопка незаметна», если человек её увидел, но ожидал другой результат. Чем точнее факт, тем дешевле следующая гипотеза: команда меняет конкретный механизм, а не переделывает весь экран по впечатлению.
Как превратить заметки в приоритет исправлений
После одной яркой сессии легко броситься передвигать все кнопки. Сначала соберите заметки по одному сценарию и сравните их между участниками. Чтобы быстро расставить приоритеты, задайте три вопроса: мешает ли барьер завершить ключевую задачу, повторяется ли он в отдельных сессиях и может ли человек восстановиться без помощи. Это рабочая шкала команды, не отраслевой стандарт.
| Уровень | Наблюдаемый сигнал | Решение |
|---|---|---|
| Блокер | Без прямой помощи человек не доходит до заранее заданного результата | Разобрать первым; проверить подпись, порядок, доступность и отклик системы |
| Сильное трение | Ошибся, вернулся и восстановился, но путь стал длиннее или рискованнее | Исправлять после блокеров, особенно при повторении между сессиями |
| Неоднозначность | Заметная пауза или вопрос, после которого задача завершена без ошибки | Уточнить причину после задачи и искать повторяемость |
| Предпочтение | Человек предлагает другой цвет или стиль, но проходит путь чисто | Сохранить как мнение; не выдавать за барьер ключевой задачи |
Представьте: после первой сессии команда уже хочет переписать все подписи и переставить кнопки. Остановите переделку. Один эпизод помогает уточнить сценарий и сформулировать гипотезу, но приоритет появляется, когда вы сравнили факты из нескольких отдельных встреч.
Если один и тот же барьер проявляется у нескольких подходящих участников, измените один основной механизм. Не показывайте старую и новую версии одному человеку как независимое доказательство: он уже выучил маршрут. Новый раунд проводят на новой версии и с другими участниками. До него формулировка честная: «мы изменили экран по гипотезе о причине барьера, но ещё не доказали улучшение».
Что проверить на самом экране после наблюдения
Поведение участника подсказывает, где искать механизм. После сессии проверьте экран по нескольким направлениям. Это не замена наблюдению, а способ превратить его в проверяемое изменение.
- Подпись: называет ли главное действие результат, например «Записаться», «Выбрать время» или «Оплатить», вместо общего «Далее»?
- Иерархия: отличает ли человек главное действие от «Подробнее», «Поделиться» и других вторичных вариантов?
- Порядок: появляется ли действие там, где человек ожидает его после прочтения содержания?
- Отклик: понятно ли после нажатия, что система приняла действие, загружает данные или просит исправить ошибку?
- Состояния: различимы ли доступное, недоступное, выбранное, загрузка и ошибка?
- Доступность: хватает ли контраста, размера области нажатия, масштаба текста и альтернатив для людей с разными способами взаимодействия?
Платформенные рекомендации помогают отсеять базовые риски. В Apple Human Interface Guidelines ориентир для области взаимодействия начинается с 44 × 44 pt, а в рекомендациях Android по доступности для интерактивных элементов рекомендуется область не меньше 48 × 48 dp. Это разные единицы и общие ориентиры, а не доказательство того, что конкретная подпись и сценарий понятны вашей аудитории.
Когда 15 минут недостаточно
Микро-тест работает, когда вопрос узкий: найдёт ли подходящий человек главное действие на одном экране и поймёт ли ожидаемый результат. Если риск лежит за пределами этой рамки, добавьте нужный метод, а не расширяйте выводы одной сессии.
Допустим, на карточке человек без труда находит «Оплатить», но после нажатия сеть обрывается, банк просит подтверждение, а приложение теряет выбранный заказ. Один статичный экран здесь не воспроизводит риск. Нужна рабочая цепочка на устройстве с реальным вводом, состояниями загрузки и восстановлением после сбоя.
Длинный путь
Сеть, разрешения, ввод, оплата, ошибки серверной части и цепочка экранов требуют рабочей сборки и сквозного сценария.
Разные сегменты
Новички, постоянные клиенты, опытные операторы и люди, использующие вспомогательные технологии, проверяются по значимым группам.
Масштаб проблемы
Для частотности, доли успешно выполненных задач, сравнения вариантов и конверсии нужны количественная постановка и аналитика.
Высокая цена ошибки
Медицинские, финансовые и другие сценарии с высокой ценой ошибки требуют отдельной проверки безопасности и соответствия отраслевым требованиям.
Даже чисто пройденный путь не объясняет, почему человек не покупает. Причиной могут быть цена, ценность, доверие, условия или нерелевантный трафик. Для технической готовности к релизу используйте отдельный чек-лист качества мобильного приложения. Чтобы выбрать QA-контур по рискам, посмотрите виды тестирования приложений. UX-наблюдение дополняет эти проверки, но не заменяет стабильность, безопасность и проверку на устройствах.
Если задача относится к сайту, форме или оформлению заказа, используйте соседний разбор связи дизайна сайта, конверсии и бюджета. Там рассматривается путь до заявки на сайте; микро-тест этой статьи отвечает только за понятность конкретного действия в мобильном экране.
Карточка 15-минутной проверки одного экрана
Ниже дан рабочий сценарий на одного участника. Обычная полная модерируемая сессия длится дольше; здесь время сокращено потому, что вы проверяете ровно одну заранее заданную задачу. Разбор заметок и изменение макета происходят после ухода участника.
- 0–2 минуты: рамка и цель. Получите согласие на запись. Скажите, что проверяется экран, а не человек. Задайте один вопрос о контексте и дайте задачу дословно, не обучая интерфейсу.
- 2–10 минут: действие. Включите таймер, молчите и записывайте первое действие, ошибочные переходы, возвраты, паузы, вопросы, восстановление и завершение. Любую помощь фиксируйте дословно.
- 10–13 минут: уточнение. После завершения или остановки спросите: «Что вы искали?», «Что ожидали после этого нажатия?», «Что оказалось непонятным?», «Что помогло бы продолжить?»
- 13–15 минут: итог. Проверьте значение ключевой подписи и ожидаемый следующий экран, поблагодарите участника. После встречи отделите факты от гипотез и выберите одно изменение для нового теста.
Фраза на случай вопроса «сюда нажать?»: «Поступите так, как поступили бы, если бы меня рядом не было».
Главное правило: не обучайте участника во время задачи и не считайте повтор на том же макете независимой проверкой.
Лист наблюдений
В шапке укажите код участника, сегмент и релевантный опыт, устройство и ОС, версию прототипа, дословную задачу, конечный результат и согласие на запись. В строках записывайте только то, что произошло. Гипотеза получает отдельный столбец.
| Время | Экран / состояние | Наблюдаемое действие | Дословные слова | Результат / помощь | Гипотеза |
|---|---|---|---|---|---|
| 00:00 | Стартовая карточка | Получил задачу; смотрит на экран | «Ищу, где выбрать время» | Без помощи | Заполняется после задачи |
| 00:18 | Карточка услуги | Нажал «Подробнее», затем вернулся | «Думал, запись будет там» | Ошибочный переход; без помощи | Вторичное действие конкурирует с главным |
| 00:41 | Карточка услуги | Пролистал вниз, спросил о записи | «Где здесь записаться?» | Зафиксировать текст подсказки, если она дана | Проверить подпись, положение и иерархию главного действия |
Строки выше показывают условный пример формата. Подставьте фактические действия и точные отметки из своих сессий: демонстрационные время и выводы не заменяют наблюдение вашей команды.
Итог по задаче
- исход: успех без помощи / успех после помощи / не завершено;
- время до конечного результата, если скорость важна для сценария;
- ошибочные переходы, повторные нажатия, возвраты и просьбы о помощи;
- точные интервалы заметных пауз и способ восстановления;
- паттерн между отдельными сессиями, а не яркость одного эпизода;
- одно изменение-гипотеза и условие повторной проверки.
Источники и границы
Ссылки проверены 10 августа 2026 года. Они подтверждают понятия и практику наблюдаемого теста. При этом универсального объёма выборки нет, а 15-минутный формат служит рабочей рамкой только для одной узкой задачи.
- ISO 9241-11:2018: удобство использования в контексте заданных пользователей, целей и условий.
- GOV.UK Service Manual: конкретные правдоподобные задачи, нейтральная инструкция и наблюдение; полные сессии в руководстве длиннее микро-теста этой статьи.
- Digital.gov / GSA: вероятные пользователи, ненаводящие вопросы и синтез паттернов между участниками.
- NIST Common Industry Format: завершение, ошибки, время и разделение выполнения с помощью и без неё.
- Apple Human Interface Guidelines: purpose, simplicity, hierarchy, craft и delight рассматриваются вместе; красота не противопоставляется ясности.
FAQ
Можно ли проверить UX на статичном макете?
Да, но вывод будет узким. На статичном макете можно проверить, какой элемент человек выберет первым и что ожидает после нажатия. Нельзя считать это тестом полного пути, оплаты, ошибок ввода или реакции системы.
Кого приглашать на юзабилити-тест?
Приглашайте актуального или вероятного пользователя, похожего на аудиторию продукта и не знакомого с макетом. Автор интерфейса, разработчик, близкий коллега и случайный человек не заменяют нужный сегмент.
Сколько пользователей нужно для проверки UX?
Универсального числа нет. Одна сессия показывает конкретный эпизод и помогает улучшить протокол, но не доказывает проблему всей аудитории. Повторяйте одну задачу с несколькими подходящими людьми и смотрите, воспроизводится ли барьер.
Можно ли провести тест удалённо?
Да, если участник может открыть прототип или сборку на подходящем устройстве, показать экран и дать согласие на запись. Заранее проверьте ссылку, звук, права демонстрации и резервный способ подключения.
Может ли дизайнер сам модерировать тест?
Может, если использует нейтральный сценарий, не защищает решение и не подсказывает маршрут. Полезно передать ведение коллеге: автору труднее молчать и не объяснять знакомый экран.
Когда нужен полный UX-аудит вместо 15-минутной проверки?
Когда решение зависит от цепочки экранов, нескольких сегментов, доступности, реального ввода, сети, оплаты, ролей или количественной оценки масштаба. Короткий микро-тест диагностирует одну задачу, но не заменяет эти методы.
Проверьте один сценарий без спора о вкусах
Пришлите экран или кликабельный прототип и напишите точную задачу пользователя. Мы подготовим нейтральный сценарий и лист наблюдений. Если проводим сессии вместе, после них разметим фактический путь, выделим повторяющиеся барьеры и вернём три приоритетные гипотезы изменения. Начнём с одного изменения для проверки, без обещаний метрик до нового раунда.