Дизайн форми заявки: поля, помилки та мобільна клавіатура

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

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

Почніть із мети та одного сценарію

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

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

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

Поля форми: що запитувати і як перевіряти

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

Підписи, приклади та порядок полів

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

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

Мобільна форма заявки та правильна клавіатура

На телефоні основна частина взаємодії відбувається не з красивим макетом, а з клавіатурою, яка перекриває нижню частину екрана. Кожне поле має викликати доречний тип введення: телефонне — цифрову телефонну клавіатуру, email — клавіатуру з @, багаторядковий коментар — звичайну текстову. Це скорочує перемикання символів і зменшує шанс помилки.

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

Як має працювати попап із відкритою клавіатурою

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

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

Помилки у формах сайту: попереджати, пояснювати, не карати

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

Повідомлення повинно називати проблему й спосіб виправлення. «Некоректне значення» змушує здогадуватися; «Введіть номер телефону повністю» або «Додайте символ @ в email» дає конкретну дію. Не спирайтеся тільки на червоний колір: текстове пояснення необхідне, а помилкове поле має бути помітним без пошуку по всій формі.

Заповнений чекліст станів форми:

• Порожній стан: видимі підписи, зрозумілий текст кнопки, необов’язкові поля позначені коректно.
• Фокус: активне поле має виразний контур; на смартфоні воно не перекрите клавіатурою.
• Заповнений стан: введений текст не зникає, підпис лишається видимим, довге значення не ламає верстку.
• Помилка поля: є текст із причиною та інструкцією; помилка не зникає до виправлення значення.
• Помилка після відправлення: фокус або прокрутка веде до першої проблеми, а всі інші помилки лишаються видимими поруч зі своїми полями.
• Надсилання: повторне натискання кнопки не створює дублікати; стан очікування зрозумілий, але не блокує інтерфейс без пояснення.
• Успіх: замість форми з’являється конкретне підтвердження отримання заявки й зрозумілий наступний крок.
• Технічна невдача: дані не губляться без потреби; користувач бачить нейтральне пояснення та спосіб спробувати ще раз.

Навчальний приклад: форма до і після

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

Після. Для того самого навчального сценарію лишаються обов’язкові «Ім’я» та «Телефон або email», а «Коротко опишіть запит» — необов’язкове поле з прикладом. Над полями є сталі підписи; канал зв’язку обирається так, щоб не вимагати обидва контакти. Телефон викликає відповідну клавіатуру, попап прокручується до активного поля, а нижня кнопка доступна після закриття клавіатури. Якщо телефон введено не повністю, пояснення стоїть під цим полем. Після успішної відправки форма змінюється на екран підтвердження: заявка отримана, команда зв’яжеться обраним каналом.

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

Що передати дизайнеру та розробнику

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

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

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

Від чого залежить обсяг і бюджет

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

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

Фінальна перевірка перед запуском

1. Сформулюйте одну ціль форми та відповідальну наступну дію команди.
2. Приберіть усі обов’язкові поля, без яких неможливо зв’язатися або виконати цю дію.
3. Переконайтеся, що підписи не зникають після введення, а вимоги до формату зрозумілі.
4. Перевірте тип клавіатури для телефону, email і текстового коментаря.
5. Відкрийте форму на телефоні, сфокусуйте нижнє поле й переконайтеся, що попап прокручується, а контент не перекритий.
6. Спробуйте надіслати некоректні дані та оцініть, чи повідомлення пояснюють виправлення.
7. Перевірте стан успіху, технічну помилку, захист від повторного відправлення та надходження заявки до команди.

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