Дизайн экрана оформления заказа мобильного приложения
Checkout — самый ответственный UX-экран в eCommerce-приложении. Здесь теряется до 70% пользователей, которые уже решили купить. Почти всегда причина — не в технических проблемах оплаты, а в том, как спроектирована форма: сколько шагов, в каком порядке поля, насколько понятны ошибки валидации.
Одностраничный или многошаговый: это не вкусовщина
Основной выбор архитектуры экрана задаёт всё остальное. Одностраничный checkout (all-in-one scroll) — быстрее для пользователя, но требует умного управления фокусом клавиатуры. Когда пользователь тапает по полю «Улица», клавиатура поднимается и скрывает следующие поля — нужен KeyboardAwareScrollView (iOS) или WindowSoftInputMode.ADJUST_RESIZE с правильным scrollTo (Android). Если это не проработано в дизайне, разработчик делает это по-своему, и UX страдает.
Многошаговый checkout (Step 1: адрес → Step 2: доставка → Step 3: оплата) снижает когнитивную нагрузку. Прогресс-индикатор обязателен — пользователь должен знать, где он и сколько осталось. Навигация назад должна сохранять введённые данные — потеря данных при нажатии «Back» убивает конверсию.
Поля и валидация: где все ломается
Поле номера телефона: маска, формат, валидация — три отдельных задачи. Mask форматирования +7 (___) ___-__-__ реализуется через PhoneNumberKit на iOS или libphonenumber на Android. В дизайне должно быть показано: как выглядит поле в фокусе, как заполненное, как с ошибкой валидации, как с успешно подтверждённым номером.
Инлайн-валидация (сообщение об ошибке под полем, пока пишешь) vs валидация при потере фокуса — это дизайнерское решение с реальными последствиями. Инлайн раздражает, если срабатывает слишком рано. Оптимальный паттерн: показывать ошибку только после того, как пользователь коснулся поля и ушёл из него (onBlur в терминах React Native / Flutter).
Типичные поля и их нюансы:
- Email:
keyboardType = .emailAddress, автокапитализация выключена - Номер карты: группировка по 4 цифры,
keyboardType = .numberPad, маска ввода - CVV:
isSecureTextEntry = true, 3–4 символа максимум - Дата карты: mm/yy форматирование, автопереход между полями
- Имя на карте:
autocorrection = false,autocapitalization = .words
Каждое из этих полей — компонент с явными состояниями в Figma: empty, focused, filled, error, disabled.
Выбор способа доставки и оплаты
Способы доставки — radio-list с ценой и сроком для каждого варианта. Если вариантов много (>4), нужен раскрываемый список или отдельный экран выбора. Карточки пунктов выдачи — отдельная история: нужна либо карта, либо список с адресами и временем работы.
Способы оплаты на iOS в 2024: Apple Pay через PKPaymentAuthorizationController, карты, СБП (для российского рынка), постоплата (сервисы типа Dolami). Apple Pay должен быть первым в списке и иметь отдельную кнопку — согласно Apple HIG. На Android — Google Pay через PaymentsClient, аналогичная логика.
Сохранённые карты пользователя: отображение замаскированного номера **** 4242, тип карты (иконка Visa/Mastercard), возможность выбора и удаления. Tokenization происходит на стороне платёжного провайдера (Stripe, CloudPayments, ЮКасса), дизайн должен отражать это состояние корректно.
Экран подтверждения заказа
Финальный шаг часто делают небрежно. А это последнее, что пользователь видит в сессии — оно формирует впечатление от покупки. Обязательно: номер заказа, краткий состав, сумма, способ и срок доставки, кнопка «Продолжить покупки» и ссылка на отслеживание (если применимо). Анимация успеха — Lottie с простой иконкой галочки, без перегруза.
Процесс и сроки
Дизайн полного flow чекаута: анализ требований → прототип шагов → дизайн всех экранов с состояниями → передача в Figma Dev Mode.
| Объём | Срок |
|---|---|
| Одностраничный checkout, базовые поля | 1–1,5 дня |
| Многошаговый, выбор доставки + оплата | 2–3 дня |
| Полный flow с картой ПВЗ и нативными Pay | 3–4 дня |
Стоимость рассчитывается индивидуально после анализа требований.