На цьому етапі статична верстка починає відповідати на дії. Форма підказує помилку до надсилання, кнопка не дає оформити замовлення двічі, екран чесно показує завантаження, а не завмирає. Саме тут користувач вирішує, чи зручно йому працювати з продуктом, і саме тут губляться заявки, якщо сценарій продумано лише для ідеального випадку.
Тут же закладається одна з найчастіших вразливостей у замовних продуктах: віра в те, що перевірка на клієнті щось гарантує. Нижче розбираємо, що входить у шостий етап стратегії розробки застосунку, скільки він коштує і де проходить межа між інтерфейсом і сервером.
Що відбувається на етапі
- Реалізація інтерактивних сценаріїв на JS/TS: покрокові форми, фільтри, пошук, кошики, календарі, конструктори.
- Інтерактивність форм, валідація та поведінка користувача: залежні поля, підказки, перерахунок сум у разі зміни параметрів.
- Стани завантаження, помилок і порожніх списків. Те, що зазвичай забувають намалювати, а користувач бачить щодня.
- Захист від повторних дій: блокування кнопки на час запиту, збереження введених даних у разі помилки.
Що Ви отримуєте на виході
- Інтерфейс, у якому сценарії з технічного завдання проходять від початку до кінця.
- Форми зі зрозумілими повідомленнями про помилки мовою користувача, а не «щось пішло не так».
- Екрани, які передбачувано поводяться за повільної мережі, порожніх даних і помилки сервера.
- Готові точки підключення до серверної частини, де правила перевіряються остаточно.
Скільки коштує логіка інтерфейсів
У прайсі Ingello етап логіки інтерфейсів коштує від $0 до $4700, ціну фіксуємо до початку робіт. Нижня межа означає, що в простому продукті з мінімумом інтерактивності окремий бюджет може не знадобитися. Верхня складається з кількох чинників:
- скільки сценаріїв і кроків у кожному з них;
- наскільки складні форми: залежні поля, розрахунки, завантаження файлів;
- скільки ролей бачать різні екрани й різний набір дій;
- чи потрібні оновлення в реальному часі та робота за поганого зв'язку.
Клієнтська валідація: це зручність, а не захист
Перевірка на клієнті потрібна, щоб користувач дізнався про помилку одразу, а не після надсилання. Але вона не захищає дані: будь-який запит можна надіслати в обхід інтерфейсу. Тому кожне правило, критичне для бізнесу, має дублюватися в серверній бізнес-логіці, а доступ до дій закриватися так, як описано в розборі безпеки.
Простий приклад розподілу. Інтерфейс показує таймер тимчасового бронювання місця в автобусі, як у нашій системі автобусного букінгу. Але вирішувати, чи вільне місце і коли бронь згорає, має сервер. Якщо це вирішує браузер, двоє пасажирів колись куплять те саме місце.
Як ми описуємо логіку до коду
Логіку інтерфейсу найдешевше виправляти в документі. У кейсі фітнес-застосунку FitProt у кожного поля анкети в ТЗ одразу вказано таблицю й колонку, плюс правило: у зріст і вагу лише цифри, не більше трьох знаків. Там же описано поведінку кнопки «Завершити тренування»: вона збільшує лічильник пройдених занять і закриває запис у журналі. Почав і закінчив в один день, запис оновлюється. Закінчив наступного дня, створюється новий.
Така деталізація здається надмірною, поки не почалася розробка. Потім вона заощаджує тижні суперечок про те, «як мало бути».
Другий приклад: конструктор резюме TempRes. Це реактивний застосунок поверх готового API на 27 ендпоінтів, описаних у Swagger. Користувач заповнює форму, а попередній перегляд резюме оновлюється поруч. API був готовим, тож якість продукту для користувача цілком визначала логіка інтерфейсу.
Ролі змінюють інтерфейс
Логіка інтерфейсу охоплює й те, кому що показувати. В адміністративній системі BusTicket власник, менеджер рейсів, перевізник-партнер, диспетчер і агент заходять в одну систему, але кожен бачить лише своє меню. Менше зайвих кнопок, менше випадкових помилок, простіше навчати нових людей. Водночас прихована кнопка лишається зручністю: саму дію закрито правами на сервері.
Що ламається, якщо заощадити
Продукт виглядає робочим і поводиться непередбачувано на межах:
- подвійне надсилання форми створює два замовлення або два платежі;
- втрата мережі лишає інтерфейс у стані вічного завантаження;
- помилка сервера стирає все, що людина вводила десять хвилин;
- повідомлення про помилку каже «щось пішло не так», і клієнт іде до конкурента;
- перевірки лише на клієнті пропускають у базу дані, які потім чистять вручну.
Для власника це виглядає як «заявок менше, ніж трафіку», хоча реклама працює.
Що потрібно від Вас
- Сценарії з ТЗ або прототипу із зазначенням, що вважається успішним завершенням.
- Правила полів: що обов'язкове, які формати, які обмеження.
- Тексти повідомлень про помилки або згода, що їх пишемо ми.
Куди далі
Далі інтеграції: платежі, CRM, карти та обмін у реальному часі. Попередній крок: верстка інтерфейсів. Карта всіх етапів у стратегії розробки застосунку.
Якщо інтерфейс уже є, але заявки губляться на формах, обговоримо це на безкоштовній консультації з архітектором. Після неї Ви отримаєте розрахунок ціни та строків за етапами.
