Дизайн екрана оформлення замовлення мобільного додатка
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), потрібен dropdown або окремий екран вибору. Карточки пунктів видачі—окрема історія: потрібна або карта, або список з адресами й часом роботи.
Способи оплати на 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 дні |
Вартість розраховується індивідуально після аналізу вимог.