Как спроектировать UX мобильного приложения: от сценария до разработки

Красивые экраны ещё не означают, что приложение спроектировано

Иногда заказчик открывает Figma и видит почти готовый продукт: аккуратная главная, понятное меню, карточки, кнопки. Ощущение готовности исчезает на первой встрече с разработчиками. Что произойдёт, если код подтверждения устарел? Как перенести уже оплаченную запись? Что увидит человек, если данные не загрузились или он запретил доступ к геопозиции?

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

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

Начните с реальной задачи, а не с набора экранов

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

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

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

Выберите два-три главных пользовательских сценария

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

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

Сначала записывайте действия, а не названия экранов. «Выбрать замену, если товара нет» раскрывает больше решений, чем «корзина». «Восстановить доступ, не создавая второй аккаунт» полезнее, чем «экран пароля». Глаголы заставляют обсуждать поведение до того, как все привыкли к конкретному расположению кнопок.

Идеальный путь — только половина работы

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

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

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

Черновой макет нужен для спора, а не для красоты

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

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

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

Прототип должен отвечать на конкретный вопрос

Соединить экраны кликами недостаточно. До создания прототипа команда должна сформулировать, что именно хочет проверить. Отличает ли новый клиент разовое занятие от абонемента? Понимает ли пациент, что запись уже перенесена? Может ли курьер исправить случайно отклонённый заказ?

Нужно собрать ровно столько взаимодействия, сколько требуется для ответа. Иногда достаточно серых блоков. Иногда важны настоящие тексты, движение или привычное поведение iOS и Android, потому что неопределённость находится именно там.

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

Проверяйте выполнение задачи, а не вкус участника

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

Отмечайте паузы, неверные переходы, вопросы, ожидания и моменты потери доверия. Вопрос «Вам нравится этот экран?» легко получает вежливое «да». Гораздо полезнее спросить, что человек ожидал увидеть после своего действия.

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

Визуальный дизайн решает практические задачи

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

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

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

Спроектируйте состояния, которые редко попадают в портфолио

На красивой презентации списки заполнены, фотографии загружены, а операции всегда успешны. В настоящем приложении пользователь видит ожидание, пустые данные, частичный результат, ошибку, отсутствие сети, запрет разрешения и восстановление.

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

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

Первой версии не нужна огромная дизайн-система

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

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

Имена лучше давать по назначению. «Основное действие» переживёт смену фирменного цвета, а «синяя кнопка» — нет.

Разработчики подключаются до окончательной передачи

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

Нужно рано обсудить доступность данных, вход, разрешения, работу без сети, возможности устройства, различия iOS и Android и события аналитики. Дизайнер не обязан определять архитектуру. Но интерфейс не должен обещать мгновенную уверенность, если система способна сообщить только «проверяем».

Короткая совместная встреча по каждому основному сценарию полезнее одной огромной встречи в конце. Так правила и компоненты получают одинаковый смысл в макете и в коде.

Что должно войти в передачу для разработки

1. Оглавление сценариев со ссылками на экраны и прототипы.
2. Готовые тексты или указание, кто и когда их подготовит.
3. Значимые состояния каждого экрана и компонента.
4. Набор компонентов, вариантов, стилей и файлов изображений.
5. Правила для размеров устройств, клавиатуры, ориентации и платформ.
6. Описание жестов, переходов, разрешений, подтверждений и восстановления.
7. Требования к доступности и локализации.
8. Открытые решения с ответственным и сроком.
9. Критерии, по которым будет проверяться собранный сценарий.

Шаблон технического задания для мобильного приложения дополняет дизайн правилами бизнеса, данными и интеграциями. Макет показывает опыт пользователя, но не должен быть единственным местом, где хранится знание о продукте.

Проверяйте готовность сценария, а не «окончание дизайна»

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

Как Appfyl проводит этот этап

Сначала мы проверяем, образует ли первая версия цельный цикл ценности. Затем продукт, дизайн и разработка вместе разбирают главные сценарии. Черновые макеты обсуждаются до визуальной полировки, неочевидные взаимодействия проверяются прототипом, а работа сотрудников и админ-панель рассматриваются вместе с мобильной частью.

Мы не пытаемся навсегда зафиксировать каждый экран. Цель — убрать дорогую неопределённость и оставить место для выводов из работающего приложения. В статье про этапы разработки мобильного приложения показано, как проектирование пересекается с требованиями, программированием и тестированием. А шаблон запроса предложений поможет сравнить, что разные команды действительно включают в UX, проверку и передачу.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Частые вопросы