Ревью дизайна мобильного приложения: чек-лист перед релизом

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

Почему ревью мобильного приложения — не то же самое, что ревью сайта

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

Кто должен быть в ревью и когда его проводить

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

Чек-лист проверки макета перед передачей в разработку

Перед тем как макет уходит в разработку, пройдите по нему этим списком — большинство проблем находится именно здесь, а не на финальном релизе:

• Длинные тексты и имена пользователей не обрезаются некрасиво и не ломают сетку карточки
• Все интерактивные элементы остаются в пределах безопасной зоны экрана (safe area), а не заезжают под чёлку, вырез камеры или системную навигацию
• Для каждого ключевого экрана описаны состояния: загрузка, пустой список, ошибка сети — а не только «счастливый путь» с заполненными данными
• Контраст текста и фона проходит минимальный порог доступности, особенно в тёмной теме
• Критичные кнопки не привязаны жёстко к координатам, которые съедет на экране с другим соотношением сторон

Как собирать фидбек, чтобы правки не терялись между Figma и сборкой?

Главная причина потерянных правок — разрыв между местом, где оставили комментарий, и местом, где макет реализуют. Скриншот с кружком в мессенджере живёт отдельно от файла Figma и отдельно от задачи в трекере; через неделю никто не помнит, закрыта правка или нет. Рабочая альтернатива — комментарий прямо на макете, привязанный к конкретному элементу и состоянию экрана, с понятным статусом «открыто / в работе / закрыто». Тогда дизайнер, разработчик и заказчик смотрят на одну и ту же точку интерфейса, а не пересказывают её друг другу словами. Это не требует отдельного инструмента для каждого формата — комментарии по клику работают одинаково что для готового сайта, что для Figma-прототипа, что для скриншотов сборки приложения.

Юзабилити-тест перед финальным релизом

Чек-лист снимает технические проблемы, но не покажет, понятен ли интерфейс человеку, который видит его впервые. По наблюдениям Nielsen Norman Group, уже 5 пользователей в тесте вскрывают большинство проблем юзабилити — тестировать на 20 ради статистической полноты не обязательно. Поэтому перед финальным релизом стоит прогнать макет или прототип через короткий юзабилити-тест на 3–5 пользователях целевой аудитории: дать им конкретную задачу (оформить заказ, найти настройку, завершить регистрацию) и зафиксировать три метрики — сколько времени ушло на задачу, сколько было ошибочных действий и как пользователь оценивает процесс субъективно, своими словами. Даже пара таких сессий часто вскрывает проблему, которую команда, привыкшая к интерфейсу, перестала замечать: неочевидную иконку, кнопку не там, где её ищут, или шаг, который кажется логичным дизайнеру, но не пользователю.

Чек-лист готовности к релизу

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