Формы, которые не бесят: убираем поля, сохраняем данные
Каждое поле — это маленький налог на конверсию
Я переделал достаточно много форм оформления заказа, лид-форм и онбординг-визардов, чтобы знать этот сценарий наизусть: клиент открывает текущую форму, тычет пальцем в поле и говорит «это нужно для CRM». Умножьте это на пятнадцать полей — и вот у вас форма, заполнение которой занимает четыре минуты, процент отказов — 40%, а на выходе вы получаете именно те данные, которые запросил отдел продаж, — от тех 60% людей, что не бросили форму на полпути.
В этом и есть основное противоречие в дизайне форм. Каждое добавленное поле кем-то внутри компании обосновано — маркетингу нужен телефон, продажам — размер компании, финансистам — ИНН «на всякий случай». Никто на этом совещании не измеряет стоимость самого вопроса. А она реальна и накапливается: в целом ряде исследований (Baymard Institute, собственные исследования конверсии HubSpot, мои собственные A/B-тесты у клиентов) показано, что каждое дополнительное поле снижает процент завершения формы, причём эффект нелинейный — он резко усиливается после 7-8 полей.
Первая реакция большинства стейкхолдеров, когда конверсия падает, — добавить подсказывающий текст, полосу прогресса или кнопку посимпатичнее. Это косметика поверх структурной проблемы. Реальный рычаг — количество и тип полей, которые вы просите заполнить незнакомого человека, ещё не решившего, доверяет ли он вам. Эта статья — о том, как агрессивно давить на этот рычаг: обрезать форму до минимума, — но при этом незаметно не потерять те бизнес-данные, которые действительно нужны команде дальше по цепочке.
Вторая часть важна не меньше первой. Я видел и обратный провал: дизайнер урезает форму до «email + отправить», чтобы выиграть спор о конверсии, а через три недели отдел продаж в ярости, потому что 80% лидов неквалифицированные и никто не понимает, кому вообще стоит звонить. Сокращение полей — не самоцель. Задача — привести то, что вы спрашиваете, в соответствие с тем, что вам реально нужно, и осознанно решить, когда именно это собирать.
Сначала аудит, потом сокращение: три корзины для каждого поля
Прежде чем трогать интерфейс, я прогоняю каждое существующее поле через простую сортировку. Звучит элементарно, но почти ни одна команда этого реально не делала — формы обрастают полями годами, каждое добавлено разным стейкхолдером по разной причине, и никто ни разу не смотрел на весь список целиком.
Корзина первая: поля, необходимые прямо сейчас для завершения транзакции. Email — чтобы отправить подтверждение. Адрес доставки — чтобы что-то отправить. Данные карты — чтобы её списать. Здесь не о чем спорить, и это очевидно самому пользователю — он понимает, зачем вы это спрашиваете, а это уже половина дела в снижении ощущаемого трения.
Корзина вторая: поля, которые улучшают то, что происходит после отправки формы, но не нужны для самой отправки. Размер компании, отрасль, бюджет, «откуда вы о нас узнали». Они существуют, чтобы помочь продажам расставить приоритеты или персонализировать последующий контакт. Они полезны, но пользователь не получает никакой немедленной выгоды от ответа на них — и именно поэтому они ощущаются как трение: вы просите усилий без видимой отдачи.
Корзина третья: поля, которые никто не может объяснить. Такие находятся в каждом аудите форм. Поле «отчество» в форме подписки на рассылку. Выпадающий список «должность» из 40 вариантов в форме регистрации на бесплатный триал. Когда я спрашиваю, зачем оно там, обычно отвечают «оно всегда там было» или «кто-то из продаж попросил два года назад и уже уволился». Такие поля удаляются без разговоров, дальнейший анализ не нужен.
Правило, которым я пользуюсь: корзина один всегда остаётся в основной форме. Корзина три удаляется немедленно — это одно действие часто сокращает форму на 20-30%. А вот корзина два — это место, где начинается настоящая дизайнерская работа, и ей посвящён следующий раздел, потому что ответ здесь не «удалить», а «собирать иначе».
Поле, не обязательное для выполнения задачи пользователя, — это просьба об одолжении. Просите об одолжениях экономно, и только после того, как заслужили немного доверия.
Шесть способов сократить поля, не теряя данные
Когда явно мёртвые поля удалены, остаются легитимные бизнес-потребности, конкурирующие с не менее легитимной задачей UX. Вот набор инструментов, которым я реально пользуюсь — примерно в порядке частоты применения.
1. Выводите вместо того, чтобы спрашивать
Огромная доля «обязательных» полей существует только потому, что никто не удосужился проверить, можно ли вывести эти данные из чего-то, что пользователь уже сообщил. Если человек вводит корпоративный email-домен, часто можно узнать размер компании, отрасль и даже логотип через API обогащения данных (Clearbit, Apollo и ещё десяток конкурентов делают это недорого). Если человек вводит адрес доставки, отдельное поле «страна» не нужно — распарсите адрес, или как минимум дайте одному полю с автодополнением адреса заполнить город, область и почтовый индекс вместо четырёх отдельных полей ввода.
Паттерн город/область/индекс — хороший пример более общего принципа: если два поля коррелируют между собой, спрашивайте то, у которого меньше возможных значений, и выводите остальное. Почтовый индекс в большинстве стран определяет город и часто область. Спросите индекс, автозаполните остальное, дайте пользователю переопределить при необходимости. Вы заменили три-четыре поля одним, и данные, пожалуй, даже точнее — потому что вы не полагаетесь на то, что пользователь правильно напишет «Пятигорск».
Код страны для номера телефона — ещё один такой случай: определяйте его по IP или локали браузера и подставляйте заранее, вместо того чтобы заставлять человека рыться в выпадающем списке флагов в поисках своей собственной страны.
2. Отложите сбор данных до момента, когда он оправдан
Не все данные обязательно собирать в один момент. Это самый действенный приём, который я применяю в лид-формах и формах регистрации, и именно он вызывает больше всего сопротивления у команд, потому что ломает ментальную модель «одна форма — одна отправка».
Разбейте форму по срочности. Собирайте только то, что нужно для создания аккаунта или начала транзакции — обычно email и, может быть, имя. Всё, что относится к корзине два — размер компании, сценарий использования, бюджет, телефон — переносится на второй этап: экран онбординга после регистрации, письмо со ссылкой «дозаполните профиль», или шаг, который пользователь видит только при повторном входе.
Логика проста: человек, уже создавший аккаунт, преодолел порог вовлечённости, которого нет у незнакомца, просто разглядывающего лендинг. Тот же самый вопрос («какой размер у вашей компании?»), который на форме на лендинге ощущается как вторжение, внутри онбординга продукта воспринимается совершенно нормально, потому что теперь пользователь считает, что вы спрашиваете, чтобы ему помочь, а не чтобы квалифицировать его для менеджера по продажам.
Я неоднократно применял такое разделение в регистрациях на триал в B2B, и картина стабильно повторяется: конверсия первичной регистрации растёт на 25-60%, а процент заполнения профиля на отложенном этапе составляет 50-75% — то есть вы всё равно получаете большую часть данных, просто с большей базы пользователей, а те, кто пропускает этот шаг, скорее всего, всё равно не дали бы честного ответа.
3. Используйте поэтапное раскрытие вместо сплошного списка
Смежная, но отдельная техника: вместо того чтобы показать пятнадцать полей сразу, покажите три, а остальные раскрывайте в зависимости от ответов. Форме запроса расчёта, скажем, страховки для бизнеса не нужно показывать «количество сотрудников» и «размер автопарка» человеку, который двумя вопросами ранее выбрал «ИП, без транспорта». Условная логика позволяет форме оставаться короткой для каждого конкретного пользователя, даже если общее число полей по всем веткам велико.
Это отличается от отложенного сбора — вы не переносите сбор данных на другую сессию, вы просто не показываете нерелевантные поля конкретному респонденту. Психологический эффект тоже важен: форма, которая видимо реагирует на ваши ответы (поля появляются, исчезают, обновляется какой-то счётчик), воспринимается как умная и короткая, даже если общее число полей, которое может увидеть пользователь в «худшем случае», сопоставимо с плоской версией формы. Ощущаемые усилия падают, даже когда реальные падают не так сильно.
Оговорка: не злоупотребляйте ветвлением до такой степени, чтобы пользователи теряли понимание, на каком они этапе. Если в многошаговой форме больше 3-4 условных веток, добавьте лёгкий индикатор прогресса («шаг 2 примерно из 4»), чтобы у людей не возникало ощущения бесконечного коридора.
4. Заменяйте открытые поля выведенными или значениями по умолчанию
Ищите поля, для которых честный ответ у 80% пользователей одинаков, и сделайте это значением по умолчанию вместо пустого поля. Страна — по умолчанию та, что определена по IP. Валюта — та, что подразумевается локалью. Количество — по умолчанию 1. Согласие на рассылку — по умолчанию то, что разрешает ваш юридический отдел (здесь будьте осторожны: предзаполненные галочки согласия ограничены GDPR и подобными регламентами, так что у этого конкретного значения по умолчанию есть юридические, а не только UX-ограничения).
Значения по умолчанию мощны, потому что превращают задачу ввода данных в задачу подтверждения, а это гораздо дешевле когнитивно. Хитрость в том, чтобы значение по умолчанию было заметно редактируемым — заполненный выпадающий список, который выглядит заблокированным, отпугнёт те 20% пользователей, для которых значение по умолчанию неверно и которые не понимают, как его изменить.
5. Объединяйте поля, которые по сути являются одним решением
Имя и фамилия почти всегда разделены на два поля просто по привычке, а не по необходимости. Единое поле «полное имя» подходит для подавляющего большинства случаев — редко когда нужно обращаться к человеку «Уважаемый [Имя]» так, чтобы с этим не справилась библиотека парсинга имён (или даже простое разбиение по последнему пробелу). Исключение — по-настоящему персонализированные массовые рассылки, где ошибки парсинга дорого стоят, но это меньшинство форм, а не типовой случай.
Аналогично, «адрес, строка 1» и «адрес, строка 2» обычно можно объединить в одно многострочное текстовое поле для всего, что не является логистической/транспортной системой со строгими требованиями к валидации. Такое разделение существует потому, что кто-то сначала спроектировал базу данных, а форму — уже потом. Проектируйте форму для человека, а затем сопоставляйте её с тем, сколько бы столбцов ни требовала база данных за кулисами — пользователь никогда не должен видеть вашу схему данных.
6. Спрашивайте один раз, используйте везде
Если пользователь авторизован или уже заполнял форму на вашем сайте раньше, перестаньте запрашивать у него ту же информацию снова. Звучит очевидно, но я регулярно нахожу сайты, где постоянный клиент в третий раз вводит адрес доставки, потому что процесс оформления заказа и система аккаунтов не общаются друг с другом. Автозаполнение из сохранённых данных — с простой возможностью «использовать другой адрес» — убирает поля с точки зрения пользователя полностью, потому что ему ничего не нужно вводить, но не убирает их из вашей модели данных.
Автозаполнение браузера — тоже часть этой истории, и его стоит реально протестировать, а не просто полагаться на него. Нестандартные имена полей, нетипичная вёрстка (например, разбиение срока действия карты на два кастомных выпадающих списка вместо одного поля ММ/ГГ) и JavaScript, который очищает поля при потере фокуса, — всё это ломает нативное автозаполнение браузера. Форма, которая дружит с автозаполнением, фактически имеет меньше полей с точки зрения пользователя, даже если их количество на экране не изменилось.
Дизайн на уровне поля: детали, которые решают исход
Сокращение количества полей — это главный рычаг, но то, как устроено каждое оставшееся поле, имеет почти такое же значение, особенно на мобильных, где плохо настроенное поле ввода может превратить пятисекундную задачу в тридцатисекундную борьбу с клавиатурой.
Подбирайте тип ввода под тип данных
Используйте type="email", type="tel" и type="number", чтобы мобильные устройства показывали правильную раскладку клавиатуры — «@» и «.» на клавиатуре для email, цифровую панель для телефона. Это правка в одну строку на каждое поле, которая ощутимо снижает количество опечаток и время заполнения, и удивительно, как часто её всё ещё пропускают, особенно в самописных формах, которые не начинались с библиотеки компонентов.
Для дат избегайте трёх отдельных выпадающих списков день/месяц/год, если только вы не имеете дело с датой рождения, достаточно далёкой в прошлом, чтобы виджет календаря стал неудобным для прокрутки (никто не хочет крутить календарь на 40 лет назад, чтобы ввести год рождения). Для ближайших дат — запись на приём, окна доставки — выбор из календаря быстрее набора текста. Для дат в далёком прошлом обычное текстовое поле с подсказкой формата («ДД/ММ/ГГГГ») и щадящим парсингом, или три небольших числовых поля, часто оказываются лучше, чем календарь.
Подписывайте поля явно, не полагайтесь только на плейсхолдер
Плейсхолдер-вместо-подписи (серый текст внутри поля, исчезающий при начале ввода) всё ещё встречается и всё ещё проблема с точки зрения юзабилити. Как только пользователь начинает печатать, или если поле предзаполнено автозаполнением, подпись исчезает, и человек теряет ориентацию — особенно если его прервали и он возвращается к форме позже. Используйте постоянную подпись над полем или рядом с ним, а плейсхолдер оставьте для примеров форматирования («например, +7 999 123-45-67»), а не для названия самого поля.
Это важнее, чем кажется, потому что напрямую служит цели «сократить поля без потери данных»: чётко подписанное поле заполняется правильно с первого раза, а значит меньше ошибок валидации и меньше брошенных сессий. Непонятная подпись функционально похожа на лишнее поле, потому что добавляет цикл проб, ошибок и исправлений.
Валидируйте по ходу, а не только при отправке
Ничто не убивает сокращённую форму быстрее, чем ситуация, когда пользователь доходит до кнопки отправки, уверен, что всё сделано, и получает пять сообщений об ошибках сразу, потому что валидация запускалась только при сабмите. Валидируйте при выходе фокуса из поля (по событию blur, а не на каждое нажатие клавиши — это ощущается агрессивно и помечает состояние как «неверно», пока человек ещё печатает). Подтверждайте и успех тоже — небольшая галочка или смена цвета на правильно заполненном поле даёт позитивную обратную связь, которая снижает тревожность на следующих полях формы, особенно в длинных формах, где пользователи по ходу дела оценивают, «правильно ли они всё делают».
Сообщения об ошибках должны говорить, что делать, а не только что не так. «Введите корректный email» немного лучше, чем «неверные данные», но «Проверьте часть после @ — похоже, не хватает „.com“ или похожего окончания» решает реальную проблему пользователя. Это мелочь в масштабе одного поля, но на всю форму с реальными точками трения конкретизация сообщений об ошибках часто даёт для конверсии больше, чем удаление какого-нибудь посредственного поля.
Делайте необязательные поля видимо необязательными — и спрашивайте себя, зачем они вообще нужны
Если вы решили, что поле реально нельзя удалить или отложить, но оно при этом строго не обязательно, пометьте его явно «(необязательно)», а не помечайте звёздочками только обязательные поля, оставляя всё остальное в неопределённости. Пользователи сканируют форму в поисках самого быстрого пути, и неясность насчёт того, что обязательно, приводит и к избыточному заполнению (потраченное время), и к недозаполнению (пропущенные обязательные данные, срабатывающая ошибка).
При этом каждое необязательное поле должно вызывать вопрос: если пользователю нормально его пропустить, зачем оно вообще в этой форме, а не в корзине два, отложенное на потом? «Необязательное» иногда — это компромисс, к которому приходят стейкхолдеры, не сумев договориться, корзина это один или корзина два. Обычно это корзина два.
Когда правильное решение — вернуть поле обратно
Хочу подчеркнуть: это не аргумент в пользу чистого минимализма. Есть реальные случаи, когда больше полей, больше трения или более прямые вопросы улучшают результат — для пользователя, а не только для бизнеса, — и их стоит назвать, чтобы «сокращай всё подряд» не превращалось в слепо применяемую догму.
Квалификационные поля в формах для сложных продаж (high-touch sales) — легитимный случай. Если ваш отдел продаж тратит реальное время на разведывательные звонки, форма, которая заранее спрашивает про диапазон бюджета или размер команды и направляет неподходящих лидов на самообслуживание вместо звонка, реально экономит время всем, включая того, кто заполнял форму, — иначе он бы просидел бесполезный звонок с продажником. Критерий — меняет ли дополнительное поле дальнейший ход событий так, чтобы это было выгодно пользователю, а не просто удобно для внутренней отчётности.
Поля подтверждения — «подтвердите email», «подтвердите пароль» — снижают риск конкретного дорогостоящего сбоя (опечатка в email означает, что пользователь никогда не получит подтверждение и не поймёт почему), хотя стоит отметить, что для email конкретно часто лучшим решением будет просто показать введённое значение обычным текстом на экране проверки перед финальной отправкой, а не удваивать нагрузку ввода для каждого пользователя ради ловли опечаток.
Поля, требуемые законом или регуляторами, — ИНН для выставления счетов сверх определённых порогов, проверка возраста, чекбоксы согласия на конкретное использование данных — не опциональны независимо от UX-предпочтений, но их всё равно можно спроектировать хорошо: объясните одной строкой, зачем вы это спрашиваете, и не прячьте требование за общей подписью, из-за которой пользователь решит, что это очередной маркетинговый вопрос, который можно пропустить.
И иногда более длинная форма фильтрует по уровню намерения так, что это реально полезно бизнесу, не будучи враждебным к пользователю, — подробная форма запроса индивидуального расчёта для корпоративной услуги — разумное место, чтобы спрашивать больше, потому что пользователь, оказавшийся там, уже ожидает некоторых усилий, а версия из двух полей просто сгенерирует шум, разгребать который вашей команде обойдётся дороже, чем пользователю стоило заполнить дополнительные поля.
Как на самом деле измерить, сработало ли сокращение
Сокращение полей легко обосновать интуицией и трудно подтвердить без данных, а «конверсия выросла» — необходимое, но не достаточное условие: нужно проверить, что лиды или заказы, которые доходят до вас, всё ещё пригодны для использования.
Отслеживайте процент заполнения по каждому полю, а не только общее завершение формы. Большинство инструментов аналитики форм (Hotjar, FullStory или даже собственное событие на blur/change) могут показать, у какого конкретного поля самый высокий процент отказов сразу после него. Это обычно и есть ваш следующий кандидат на удаление, отложенный сбор или UX-исправление — вместо того чтобы гадать, начиная с верха формы.
Отслеживайте время заполнения вместе с процентом завершения. Форма, которая заполняется быстро, но выдаёт мусорные данные (явно фейковые номера телефонов, «asdf» в поле названия компании), говорит о том, что форма слишком короткая относительно ощущаемой ценности обмена — люди заполняют её, лишь бы миновать препятствие, а не потому что хотят получить то, что по ту сторону. Это сигнал сократить разрыв в ценности обмена (яснее и быстрее показать, что человек получает за свои данные), а не снова удлинять форму.
Отслеживайте конверсию дальше по цепочке, а не только факт отправки формы. Если удаление поля «телефон» из формы запроса демо удваивает число заявок, но вдвое снижает явку на забронированные звонки, вы ничего на самом деле не выиграли — вы просто перенесли трение из формы в календарь отдела продаж. Это самая распространённая ошибка, которую я вижу в кейс-стади вида «мы сократили форму, и конверсия выросла», которые не выдерживают проверки: там оптимизировали метрику, которую проще всего увидеть (отправки формы), вместо той, что действительно важна (платящие клиенты, успешные доставки, квалифицированные лиды), — а чтобы увидеть, как двигается вторая цифра, нужна дополнительная неделя-две ожидания, прежде чем станет ясно, реально ли изменение помогло.
Если вы работаете в B2B, проводите сравнение как минимум в течение одного полного цикла продаж, а не только двухнедельного A/B-теста, потому что люди, которые конвертировались из сокращённой лид-формы, могут закрываться на сделку с другим процентом спустя недели — а это и есть цифра, которая в итоге решает, был ли короткий вариант формы удачным обменом.
Наконец, следите за жалобами в поддержку и от отдела продаж, а не только за дашбордами. Если поддержка начинает получать жалобы вида «зачем вам мой адрес, я же уже его давал» — это признак того, что поле убрали из интерфейса, но не убрали фактически из требований где-то дальше по цепочке: вы просто перенесли трение из формы в телефонный звонок, а это хуже для всех. И наоборот, если продажи начинают говорить «половина этих лидов вообще не понимает, что оценивает» — это признак того, что вы отложили слишком много квалифицирующей информации, а процесс дальнейшего контакта не собирает то, что убрали из формы.
Короткий чек-лист для следующей формы, к которой вы прикоснётесь
Когда я сейчас сажусь переделывать форму, я прохожу примерно такую последовательность, и это занимает меньше времени, чем можно подумать по объёму абзацев выше:
- Выписать все текущие поля и рассортировать их на «нужно сейчас», «нужно позже» и «никто не может объяснить зачем».
- Немедленно удалить корзину три.
- Для корзины два решить: отложить на следующий шаг, вывести из других данных или сделать условным от предыдущего ответа.
- Объединить поля, которые по сути являются одним решением (имя, строки адреса), в единые поля ввода, где это позволяет модель данных.
- Задать значения по умолчанию везде, где один ответ покрывает большинство пользователей, и сделать значение по умолчанию видимо редактируемым.
- Исправить типы ввода, подписи и валидацию по ходу заполнения во всём, что пережило сокращение.
- Настроить отслеживание отказов по каждому полю до запуска, чтобы не гадать на втором круге.
- Проверить показатели дальше по цепочке — явку, качество лидов, обращения в поддержку — минимум в течение одного полного цикла, прежде чем объявлять победу.
Ничего из этого не требует экзотических инструментов или переделки всего продукта. Большая часть выигрыша в проектах, с которыми я работал, приходилась на шаги с первого по четвёртый — честную сортировку полей и отказ давать шанс аргументу «может, когда-нибудь пригодится» пережить сокращение. Техническая полировка (типы ввода, валидация, совместимость с автозаполнением) важна, но она — множитель для формы, уже урезанной до нужного размера, а не замена самого процесса урезания.
Неудобная часть этой работы — не дизайн, а внутренние переговоры. Каждое удаляемое поле кто-то когда-то туда поставил, и убрать его — значит завести разговор о том, действительно ли нужное этому человеку нужно прямо сейчас, нужно позже, или не нужно вовсе. Этот разговор стоит вести поле за полем, потому что альтернатива — форма, которая тихо просит пятнадцать вещей «на всякий случай», — это налог, который платит каждый посетитель, независимо от того, воспользуется ли бизнес когда-нибудь тем, что запросил.
