Ошибки в прототипе, пропущенные до этапа разработки, увеличивают стоимость итерации верстки в 3–5 раз: исправление одного некорректного состояния кнопки в Figma занимает 2 минуты, в Android Studio — до 40 минут с учетом пересборки проекта. Качественный чек-лист превращает макет из «картинки» в техническое задание, сокращая количество уточняющих вопросов от разработчика на 40% за счет проработки краевых случаев.
Интерактивность и логика переходов
Проверка кликабельности — это не просто тест «нажимается ли кнопка», а аудит всех пользовательских путей (User Flows). В Android-приложениях критично проверить работу системной кнопки «Назад»: если в прототипе она ведет на главную вместо предыдущего экрана, пользователь покинет приложение. Обязательно настройте прототипирование сложных переходов в Android: настройка Smart Animate для навигационных меню позволяет разработчику понять тайминги анимации (обычно 200–300 мс для переходов и 100–200 мс для микровзаимодействий).
Кейс: в одном из финтех-проектов отсутствие макета состояния «Loading» для API-запроса привело к тому, что разработчик реализовал пустой экран. В итоге 15% пользователей посчитали приложение зависшим. Вывод: каждый экран с загрузкой данных должен иметь состояние скелетона или спиннера.
Сетка, адаптивность и Auto Layout
Android-рынок фрагментирован: разница в ширине экранов может составлять от 360dp до 480dp. Проверка макетов через создание адаптивных макетов под разные разрешения Android-экранов с помощью Auto Layout исключает «поехавшую» верстку на бюджетных устройствах. Проверьте, чтобы элементы не имели фиксированной ширины (Fixed width), а использовали Fill container или Hug contents.
Практика показывает, что использование жестких отступов вместо стандартных 8dp/16dp (сетка Material Design) замедляет верстку на 20%, так как разработчику приходится вручную подбирать значения. Мой вердикт: если в макете есть отступ 13px или 17px — это ошибка, которую нужно править до передачи в разработку.
Доступность (Accessibility) и контрастность
Соответствие стандарту WCAG 2.1 — это не прихоть, а требование для приложений с охватом более 100к пользователей. Минимальный размер области касания (touch target) для Android должен быть 48x48dp. Если иконка имеет размер 24x24dp, вокруг нее должен быть невидимый кликабельный контейнер. Проверьте контрастность текста: коэффициент 4.5:1 для обычного текста и 3:1 для крупного.
Пример: кнопка «Отправить» с серым текстом на светло-сером фоне проходит визуальный фильтр дизайнера, но проваливает тест доступности. В результате 5-7% пользователей с нарушением зрения не находят целевое действие. Вывод: используйте плагины типа Stark для автоматической проверки контрастности каждого экрана.
Состояния компонентов и валидация
Передача только «идеального» макета (Happy Path) — главная ошибка новичков. Каждый интерактивный элемент должен иметь 4 состояния: Default, Hover/Pressed, Focused и Disabled. Особое внимание уделите созданию интерактивных форм ввода для Android в Figma: валидация полей и состояния ошибок должны быть отрисованы явно. Текст ошибки должен быть контрастным и располагаться строго под полем ввода с отступом 4-8dp.
Сравнение: макет с одним состоянием формы требует от разработчика догадок, что приводит к 3-5 правкам после первого билда. Проработанная библиотека состояний сокращает время на стабилизацию UI-слоя на 25%. Мое мнение: макет без состояния ошибки (Error state) считается незавершенным и не должен приниматься в работу.
Техническая гигиена и экспорт
Разработчик не должен искать иконку среди 10 слоев с названием «Group 452». Оптимизация иконок для Android в Figma: экспорт в SVG и подготовка векторов для разработчиков включает именование по принципу category/icon_name (например, navigation/back_arrow). Проверьте, чтобы все иконки были обернуты в квадратный фрейм (например, 24x24), иначе при экспорте в SVG возникнут проблемы с центрированием в Android Studio.
Кейс: передача макетов с «грязными» слоями увеличила время подготовки ассетов с 2 часов до 2 дней. Вывод: используйте плагины для очистки слоев и проверьте, чтобы все стили текста и цвета были привязаны к локальным переменным или стилям Figma, а не были «raw» значениями.
Вывод
Идеальный прототип Android-приложения — это не набор красивых экранов, а детальная инструкция по поведению интерфейса. Начинайте проверку с Auto Layout и сетки, затем переходите к User Flows и Accessibility, и завершайте технической чисткой слоев. Избегайте передачи макетов без прорисованных состояний ошибок и пустых экранов (Empty states). Моя рекомендация: внедрите этот чек-лист как обязательный этап Definition of Ready (DoR) перед стартом спринта — это сэкономит до 30% бюджета на разработку фронтенда за счет исключения бесконечных правок «по ходу дела».