Привет, Хабр! Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.
У вас когда‑нибудь было такое: при оплате через мобильное приложение, оно трижды попросило ввести пароль, потом все‑равно сбросило сессию и завершилось с ошибкой «что‑то пошло не так»? Если да, то вы только что провели UX‑тестирование и нашли баг, который не видит ни один автоматический тест.
В этой статье мы поговорим о том, как оценивать пользовательский опыт мобильных приложений без специального софта, длительного обучения и команды адептов психологии. Только голова, пальцы и готовый чек‑лист, который можно применить сегодня к любому проекту — вашему или чужому.
Что такое UX‑тестирование и почему оно важно
UX‑тестирование — это проверка того, насколько приложение удобно, понятно и предсказуемо для живого человека. Не для тест‑дизайнера, не для разработчика, а для уставшего пользователя с маленьким экраном, большим пальцем и желанием решить свою задачу за три секунды.
В мобильной разработке цена плохого UX особенно высока. На десктопе пользователь чуть терпеливее — у него курсор, большие экраны и привычка разбираться. На телефоне каждое лишнее действие, непонятная иконка или зависший свайп сокращают время жизни приложения до следующего удаления. По данным аналитических агентств, большинство мобильных приложений теряют значительную долю пользователей в первые сутки после установки. И далеко не всегда виноваты баги — чаще виноват именно UX.
Разница между UI и UX: вопрос не в красоте
Самый частый вредный миф: «хороший UX — это красивый интерфейс». Нет. UI (User Interface) — это кнопки, цвета, шрифты, иконки и тени. UX (User Experience) — это то, что происходит, когда вы эти кнопки нажимаете.
Красивая кнопка, которая ничего не делает при нажатии — плохой UX. Уродливая кнопка, которая понятно реагирует на тап и мгновенно выполняет действие — хороший UX. Дизайнер отвечает за UI, а про UX думают все — от аналитика до тестировщика. И тестировщик здесь играет ключевую роль, потому что он первым видит приложение в действии с непривыкшими, «свежими» глазами.
Готовый чек‑лист: основные проверки UX
Далее давайте рассмотрим чек‑лист, который не требует инструментов. Только телефон, приложение и критическое мышление.
Навигация: как пользователь понимает, где он находится.
Пользователь никогда не должен гадать, на каком экране он оказался и как вернуться назад.
Проверьте, есть ли у каждого экрана понятный заголовок, отражающий его содержимое. Заголовок «Профиль» — понятно. Заголовок «Главная» — приемлемо. Отсутствие заголовка или иконка дома, которая ведет непонятно куда — проблема.
Аналогично проверьте кнопку «Назад». В Android она обычно системная — но приложение должно корректно на неё реагировать. Тап по ней не должен выкидывать на главный экран, если пользователь ждал возврата на предыдущий шаг формы. В iOS кнопка «Назад» всегда внутри интерфейса — проверьте, что она есть и что её текст соответствует предыдущему экрану, а не безликому «Назад».
Далее проверьте глубину навигации. Если для выполнения базового действия нужно пройти пять экранов — это плохо.
Исключение — сложные формы вроде оформления документов. Но даже там должна быть индикация шагов.
Проверьте, что пользователь не может попасть в тупик — экран, с которого нет выхода, кроме как убить приложение. Такое бывает после авторизации, если не настроили переход или если модальное окно заблокировало весь интерфейс.
Жесты: как приложение понимает касания
Мобильные приложения живут пальцами. Не мышкой, как на компьютере. Пальцем толстым, неточным и иногда влажным.
Проверьте размер интерактивных элементов. Кнопка, которая меньше 44 на 44 точек в iOS или 48 на 48 dp в Android — потенциальная боль пользователя. Нажимать на маленький текст или тонкую иконку неудобно физически.
Проверьте расстояние между кликабельными элементами. Если кнопки «Удалить» и «Сохранить» стоят вплотную — пользователь рано или поздно нажмёт не туда. Добавьте отступы или разделители.
Не забывайте о свайпах. Скролл должен работать плавно и предсказуемо. Свайп назад (из левого края экрана в iOS, из правого в некоторых Android‑оболочках) не должен конфликтовать с горизонтальной прокруткой внутри экрана. Если у вас есть carousel и свайп назад одновременно — протестируйте, куда поедет экран.
Проверьте долгие нажатия. Если в приложении есть меню по долгому тапу (контекстное меню), оно должно срабатывать предсказуемо — с вибрацией или визуальным фидбеком, с четким временем ожидания. Слишком короткое долгое нажатие будет путаться с обычным, слишком длинное — бесить.
Формы ввода: ад для пользователя
Формы — самое больное место мобильных приложений. Именно здесь UX‑ошибки вызывают мгновенную ярость.
Проверьте клавиатуру. При тапе на поле ввода номера телефона должна появляться цифровая клавиатура. На поле email — клавиатура с собачкой и точкой. На поле обычного текста — стандартная алфавитная. Это кажется очевидным, но каждый второй проект натыкается на эти грабли.
Далее проверьте автозаполнение. Поле пароля должно предлагать сохранённые пароли из системного менеджера. Поле адреса — автодополнение из карт. Если приложение хитро переопределяет стандартное поведение, велик шанс сломать этот системный механизм.
Затем, проверьте сокрытие текста в пароле. Глазик, показывающий и скрывающий введённые символы — это не опция, это обязательный элемент. Особенно важно на маленьких экранах, где пользователь физически не может закрыть экран рукой от соседа в метро.
Проверьте, что кнопка «Отправить» или «Далее» активна, только когда все обязательные поля заполнены корректно. Но при этом не блокирует возможность переключиться между полями, чтобы вернуться и исправить ошибку.
Также, убедитесь, что после отправки формы приложение не очищает все поля, если пользователю нужно отправить похожую форму повторно. Например, при добавлении товаров в корзину последовательно — каждый раз вводить название заново это пытка.
Сообщения об ошибках: как приложение говорит «нет»
Ошибки, при работе любого приложения неизбежны. Но UX разваливается тогда, когда ошибка не объясняет, что именно пошло не так.
Проверьте, что каждое сообщение об ошибке говорит на человеческом языке. «Соединение прервано» — понятно. «Ошибка 500» — бесполезно. «NullPointerException в строке 42» — издевательство.
Важно, чтобы ошибка была привязана к конкретному месту. Если поле email заполнено неправильно, подсветите красным именно это поле, а не показывайте общее сообщение «Проверьте введённые данные» вверху экрана. В мобильных приложениях пользователь может не заметить общее сообщение — экран маленький, внимание рассеянное.
Сообщение об ошибке дает понятное решение. «Пароль слишком короткий. Используйте минимум 8 символов» — решение есть. «Некорректный ввод» — решения нет, пользователь будет тыкать наугад.
Важно, чтобы ошибка не сбрасывала введённые данные. Особенно это важно для длинных форм — если после ошибки поле очистилось, пользователь скорее закроет приложение, чем заполнит всё заново.
Адаптивность: как приложение ведёт себя в реальном мире
В лабораторных условиях как правило, идеально всё. В реальности у пользователя разряженный телефон, трясущийся автобус, яркое солнце и звонок, который разрывает сессию.
Соответственно, важно проверить ориентацию экрана. Если приложение не поддерживает ландшафтный режим — это нормально для многих кейсов (например, ленты соцсетей). Но если оно принудительно переворачивается при повороте телефона и ломает вёрстку — это баг. Если поддерживает — проверьте, что все элементы помещаются и не наезжают друг на друга.
Проверьте поведение приложения при звонке. Нажмите кнопку «Домой» во время загрузки данных, затем вернитесь. Приложение должно продолжить работу или корректно перезагрузить состояние, но не упасть и не сбросить форму.
Протестируйте работу в условиях плохой сети. Отключите Wi‑Fi и мобильный интернет, попробуйте что‑то сделать. Приложение должно показать внятное сообщение «Нет соединения», а не крутить бесконечный лоадер или падать с непонятной ошибкой. Ещё лучше — если приложение сохраняет действия в кэш и отправляет позже.
Убедитесь в наличии возможности масштабирования шрифтов. В системных настройках телефона увеличьте размер шрифта до максимума и зайдите в приложение. Текст не должен вылезать за границы кнопок, обрезаться или накладываться на соседние элементы. Особенно это критично для приложений, которыми пользуются пожилые люди.
Типичные UX‑проблемы, которые не ищут функциональные тесты
Функциональное тестирование проверяет: «работает ли кнопка». UX‑тестирование проверяет: «понятно ли, что это кнопка, и что произойдёт после нажатия».
Вот топ проблем, которые вы никогда не найдёте, проверяя только «корректность работы»:
Проблема № 1: Иконочный ад. Дизайнер решил, что все знают, что означает абстрактная шестерёнка (настройки), домик (главная) и три точки (ещё). Но если в приложении появляется неизвестная иконка без подписи — пользователь не будет гадать. Он просто не нажмёт. Проверьте: любая иконка, не имеющая универсально понятного смысла, должна сопровождаться текстом хотя бы при первом появлении или в подсказке при долгом нажатии.
Проблема № 2: Бесконечный лоадер. Пользователь нажал кнопку, появился спиннер — и крутится уже 10 секунд, 20, минуту. Ни ошибки, ни прогресса, ни отмены. Функционально спиннер работает. UX‑проблема в том, что пользователь не знает: приложение зависло, сеть умерла или просто очень долгий запрос. Исправляется таймаутом с понятным сообщением и возможностью отменить действие.
Проблема № 3: Смертельный свайп. Приложение использует свайп для удаления элемента. Но не спрашивает подтверждения. Пользователь случайно провёл пальцем по экрану — и важный контакт, сообщение или файл исчез навсегда. Функционально свайп работает. Пользовательский опыт разрушен. Всегда добавляйте подтверждение на необратимые действия или кнопку «Отменить», которая появляется на несколько секунд.
Проблема № 4: Модальное окно ради модального окна. Приложение показывает обучающий тултип при первом запуске. Но он перекрывает половину экрана, его можно только закрыть крестиком в углу, а в тексте — очевидные вещи вроде «Нажмите на фото, чтобы увеличить». Пользователь раздражён ещё до начала работы. Проверьте: каждое модальное окно должно быть оправдано. Если информацию можно показать внутри интерфейса или в подсказке — покажите там.
Проблема № 5: Кнопка слишком близко к краю. На современных телефонах с изогнутыми экранами и чехлами нажать на кнопку, расположенную вплотную к левому краю, физически трудно — палец упирается в чехол. Тестировщик с голым телефоном этого не замечает. Пользователь с чехлом — замечает сразу. Делайте отступы от краёв хотя бы по 8–10 пикселей.
Как документировать UX‑баги и убеждать команду
Самая частая боль тестировщика — UX‑баг не считают багом. «Так задумано», «это требование бизнеса», «пользователи привыкнут» — знакомые отговорки?
Вот три способа превратить вашу UX‑проблему в задачу, которую возьмут в бэклог.
Способ первый: привязка к метрикам. Не пишите «неудобно». Пишите «при выполнении сценария А пользователю потребуется 5 действий вместо 2, что увеличит время на 30 секунд и повысит вероятность ухода с воронки на 40%». Цифры можно взять из общих исследований (например, каждый лишний клик на мобильных устройствах отсеивает определённый процент пользователей) — это убедительнее личных ощущений.
Способ второй: видео и сравнения. Снимите экран телефона. Покажите баг в действии. А рядом — как работает конкурент (банковское приложение, маркетплейс, соцсеть). Когда разработчик видит, что в условном «Альфа‑Банке» поле номера телефона автоматически подставляет +7, а в вашем приложении нет — он быстрее согласится, что это проблема.
Способ третий: боль конкретного пользователя. Если есть возможность, соберите одну запись реального юзабилити‑теста, где пользователь вслух ругается на баг. Несколько секунд мата или вздоха разочарования убедят команду лучше любого баг‑репорта. Нет возможности записывать — напишите стенограмму: «Пользователь кликнул пять раз в одно место, не понял, почему не работает, и закрыл приложение».
Как правильно оформить баг‑репорт на UX‑проблему:
В заголовке избегайте оценок вроде «плохо» или «неудобно». Пишите нейтрально‑технично: «Неожиданное поведение при свайпе влево в списке чатов» или «Отсутствует индикация загрузки при отправке формы из пяти полей». В описании обязательно укажите сценарий использования — кто этот пользователь, какую задачу он решает.
Добавьте шаги воспроизведения, ожидаемый результат (по стандартам Android или iOS, либо по здравому смыслу) и фактический результат. А главное — предложите решение. Не просто «это плохо», а «предлагаю добавить кнопку отмены на три секунды после свайпа, как сделано в Gmail».
Подводим итог
Этот чек‑лист — не мантра, а рабочий инструмент. И в завершении давайте посмотрим, как его внедрить без боли. Начните со своего рабочего приложения — того, которое вы тестируете каждый день. Пройдите по списку за один час. Отметьте проблемы и заведите три‑четыре самых критичных бага, затем покажите команде.
Не пытайтесь исправить всё сразу. UX‑проблемы лечатся итерациями: сначала навигация, потом жесты, потом формы ввода. Если попросите переделать всё за спринт — разработчики закроются и ничего не сделают. Выберите одну категорию из чек‑листа и договоритесь, что в следующей версии будет исправлено именно это.
Через два‑три цикла вы заметите, что команда сама начинает видеть UX‑проблемы — ещё до того, как вы их нашли. И вот тогда тестирование перестанет быть «ловлей багов» и станет настоящим улучшением продукта.
А теперь возьмите телефон, откройте любое приложение — и проведите тест. Уверен, первая же форма ввода вас удивит.
Провести первый UX‑тест действительно можно с любого приложения под рукой. Но чтобы такие проверки не сводились к личному «удобно / неудобно», нужен понятный чек‑лист: что смотреть в навигации, жестах, формах, ошибках и поведении приложения в реальных условиях.
На бесплатном уроке OTUS 30 июня в 20:00 разберем, как оценивать UX мобильных приложений без специального софта и длительной подготовки: какие проблемы чаще всего пропускают функциональные тесты, как фиксировать UX‑баги и как превращать наблюдения в полезные задачи для команды. Записаться
Статьи по теме:
Почему классический подход к QA больше не работает — как меняется роль QA, когда качество продукта уже нельзя сводить только к тестам перед релизом.
Процесс тестирования: от анализа до завершения — как выстраивать тестирование системно: от анализа требований до фиксации результатов.