Специфікація дизайну сайту: стани інтерфейсу до початку розробки

На макеті форма заявки виглядає завершеною: поля, кнопка, акуратний заголовок. Але під час розробки з’ясовується, що ніхто не погодив повідомлення про помилку, очікування відповіді та повторне надсилання. Специфікація дизайну сайту потрібна саме для таких моментів: вона пояснює, як інтерфейс поводиться за різних умов, а не лише як виглядає в ідеальному випадку.

До початку програмування варто погодити набір сценаріїв, станів і правил переходу між ними. Тоді власник бізнесу розуміє межі замовленого, дизайнер передає рішення без прихованих припущень, а розробник не мусить самостійно визначати поведінку продукту. Нижче — практичний спосіб зібрати цей пакет без зайвої документації.

1. Відокремте дизайн-рішення від красивих екранів

Передача дизайну в розробку, або handoff, — це передача узгоджених правил інтерфейсу разом із макетами. Екран показує конкретну мить. Специфікація додає умови: що запускає дію, які дані потрібні, що бачить людина під час очікування і як продовжує роботу після невдачі. Для бізнесу важливо, щоб ці рішення не виникали випадково під час верстки.

Почніть із результату користувача: знайти послугу, порівняти варіанти, залишити заявку. Для кожного маршруту вкажіть початкову умову, наступну дію та ознаку завершення.

Цей документ не є запитом на вибір студії. Якщо ви ще порівнюєте виконавців, окремо стане в пригоді матеріал про RFI, RFP і RFQ для вибору підрядника. Тут ідеться про інше рішення: які саме відомості команда має отримати перед реалізацією вже визначеного дизайну.

2. Зберіть матрицю станів, а не колекцію копій

Стани інтерфейсу описують відповідь компонента на ситуацію. Для поля це порожнє значення, введення, фокус і помилка; для списку — завантаження, результат, відсутність результатів і збій. Не кожному блоку потрібні всі варіанти. Обирайте ті, що справді можуть виникнути у погодженому сценарії, і пояснюйте, чому решта не застосовується.

Розділіть вигляд і поведінку

Колір кнопки після наведення не пояснює, чи можна натиснути її під час запиту. Так само намальований індикатор очікування не визначає момент його зникнення. Поруч із візуальним варіантом запишіть три речі: подію входу в стан, доступні дії та умову виходу. Якщо відповідь залежить від сервера, позначте залежність для обговорення з розробником.

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

Не змішуйте різні причини порожнечі

«У вас ще немає збережених товарів» і «За цими фільтрами нічого не знайдено» потребують різних дій. У першому випадку доречний перехід до каталогу, у другому — зміна умов пошуку. Недоступні дані не варто показувати як нульовий результат: це інша причина, інший текст і, можливо, інша можливість повторити запит.

3. Запишіть повідомлення, фокус і повернення до роботи

Не залишайте тексти помилок на кінець проєкту. У специфікації потрібні реальні формулювання, місце показу та момент появи. Для поля електронної пошти корисніше «Вкажіть адресу у форматі [email protected]», ніж «Некоректне значення». При цьому формат перевірки має відповідати погодженим правилам даних, а не випадковому обмеженню макета.

У поясненні критерію WCAG 3.3.1 про ідентифікацію помилок W3C зазначає: автоматично виявлену помилку введення потрібно описати текстом і визначити проблемний елемент. Червона рамка може доповнювати пояснення, але не замінює його. Це конкретна вимога до помилки, а не підтвердження доступності всього сайту.

Окремо визначте поведінку клавіатурного фокусу — поточного елемента, з яким людина взаємодіє без миші. Куди він переходить після відкриття діалогу, закриття вікна або невдалого надсилання? У макеті покажіть видиме виділення, а в примітці опишіть очікуваний маршрут. Остаточне рішення перевіряють уже в реалізованому інтерфейсі.

Повідомлення «Збережено» чи «Нічого не знайдено» може з’являтися без переходу на іншу сторінку. WCAG 4.1.3 про статусні повідомлення пояснює, як такі зміни мають бути програмно доступними допоміжним технологіям без обов’язкового переведення фокусу. Не вимагайте однакового сповіщення для кожної зміни: спосіб оголошення залежить від контексту й важливості події.

На етапі дизайну достатньо позначити, яке повідомлення повинна отримати людина і чи має її робота перериватися. Розробник визначає технічний спосіб, а тестувальник перевіряє результат. Для ширшого контексту є матеріал GL.ua про дизайн із фокусом на доступність; специфікація станів охоплює лише частину цього завдання.

4. Пройдіть умовний приклад заявки на прорахунок

Умовний приклад: компанія приймає через сайт запити на прорахунок меблів. Відвідувач обирає тип виробу, залишає контакт і додає коментар. Бізнесова мета — отримати придатне для відповіді звернення. Це навчальний сценарій, а не опис клієнта чи результату GL.ua.

Від натискання до підтвердження

До надсилання форма показує обов’язкові поля та підказки. Якщо контакт не заповнений, після спроби відправлення з’являється конкретне пояснення біля поля. Коментар залишається на місці. У рекомендаціях WAI щодо повідомлень у формах наведено підходи до загального переліку помилок і пояснень біля полів. Специфікація визначає потрібну комбінацію для цієї форми, а не копіює всі варіанти одночасно.

Якщо локальні перевірки пройдено, кнопка переходить у стан «Надсилаємо». У цьому умовному рішенні повторне натискання недоступне до завершення поточного запиту. Потрібно окремо погодити, чи можна змінювати поля під час очікування та які введені значення збережуться після невдалої спроби. Візуальний стан кнопки сам собою не визначає ці правила.

Якщо сервер підтвердив створення звернення, показуємо «Запит надіслано» й погоджений наступний крок. Якщо зв’язок перервався і результат невідомий, не пишемо «Заявку не створено»: інтерфейс цього не знає. Потрібен окремий текст про відсутність підтвердження та погоджений спосіб уточнити результат. Механіку повтору команда визначає разом із серверною частиною, а не лише в дизайні.

5. Перевірте контент і адаптивність до верстки

Макет із короткими заголовками не показує, що станеться з довгою назвою послуги або багаторядковою помилкою. Додайте приклади реального за структурою контенту: довге ім’я, відсутнє зображення, кілька повідомлень у формі. Для кожного складного блока погодьте перенесення, скорочення і спосіб прочитати приховане повністю.

Адаптивність описуйте як правила перебудови, а не лише пару «комп’ютер — телефон». Вкажіть, які елементи змінюють порядок, що залишається видимим і як поводяться таблиці та довгі списки. Точні межі ширини команда обирає під контент і компоненти. Окремо перевіряйте проміжні розміри: два погоджені екрани не описують усі ситуації між ними.

Для багатомовного сайту перевірте тексти різної довжини. Позначте джерело шрифтів, доступні накреслення та правила для іконок. Експортовані матеріали мають відповідати тим, які використано в макеті.

6. Погодьте пакет і пройдіть нумеровану перевірку

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

До початку розробки пройдіть перевірку прототипу нижче. Перед запуском сайту повторіть ті самі сценарії на реалізації: клікабельний макет не доводить, що повідомлення, переходи й робота з даними виконані правильно.

1. Пройдіть головний маршрут від початкової умови до підтвердженого результату.
2. Для кожної дії перевірте очікування, успіх і невдачу. Знайдіть стани без виходу.
3. Підставте довгі й відсутні значення та перевірте кілька помилок у формі одночасно.
4. Пройдіть маршрут на вузькому й проміжному екрані. На готовому сайті додатково перевірте клавіатуру та оголошення важливих повідомлень.
5. Зіставте макети, тексти й бібліотеку компонентів. Усуньте суперечності та зафіксуйте одну версію для реалізації.
6. Запишіть невирішені залежності й погодьте, які з них блокують старт. Перед публічним запуском перевірте їх закриття на робочому сценарії.

Для приймання вже готового продукту використовуйте окремий план. Матеріал про приймання корпоративного сайту стосується наступного етапу. Передача дизайну визначає очікуване, а приймання перевіряє фактичне; ці процедури пов’язані, але не підміняють одна одну.

7. Оцініть строки, вартість і ризик надмірної деталізації

Строк підготовки залежить від кількості різних сценаріїв, готовності контенту, складності компонентів і швидкості погоджень. Спершу з’ясуйте правила бізнесу, потім опрацюйте головний маршрут і винятки, після цього узгодьте адаптивність та пакет передачі. Паралельна робота можлива, але не варто фіналізувати повідомлення про результат, доки не визначено сам результат.

У вартості розділяйте дослідження сценаріїв, прототипування, візуальне оформлення, компоненти, тексти станів, адаптивні варіанти й перевірку з розробником. Окремо уточнюйте витрати на шрифти, ілюстрації або інструменти спільної роботи, якщо вони потрібні. Підтримка специфікації під час змін теж потребує часу. Без цього нижча оцінка може означати лише менший обсяг передачі.

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

Не потрібно креслити екран для кожної теоретичної комбінації. Інформаційній сторінці без форм може вистачити компактних правил компонентів і адаптивності. Детально опрацьовуйте місця, де людина вводить дані або може втратити прогрес.

Погоджений дизайн-пакет робить зміни видимими до програмування. Передайте GL.ua (Глянець) перелік головних сценаріїв і наявні макети, щоб обговорити розробку сайту та узгодити обсяг підготовки дизайну до реалізації.