🚨 «Укажите объём двигателя»: Как мы сократили форму записи
Кейс для продуктовых дизайнеров, исследователей и всех, кто борется со сложными формами
🗣 Контекст: форма, которую невозможно было заполнить с первого раза
В одном из моих проектов в автодилерском холдинге (B2C, сеть дилерских центров) я столкнулась с формой онлайн‑записи на техническое обслуживание. Вот как она выглядела (см. скриншот «Было»):
- 4 шага, на каждом от 3 до 10 полей - Суммарно 20+ обязательных полей - Технические параметры: объём двигателя, модификация, тип КПП, точный пробег, тип двигателя и т.д.
Я, дизайнер с пятилетним опытом, заполняла её с трудом и ошибками. А что говорить об обычном человеке, у которого «просто что‑то стучит под капотом»? Команда разработки была права со своей стороны: «Нам нужны эти поля для точной записи в систему учёта»
Но пользователю то нет дела до бэкенда! Он хочет записаться и приехать
📊 Исследование: кастдевы вместо предположений Прежде чем перерисовывать форму, я провела 20+ глубинных интервью с реальными клиентами дилерских центров. Главный вопрос: «Какие данные о машине вы знаете точно, не глядя в документы?»
Вот результат: Практически все знают марку, модель и госномер, но мало кто знает объём двигателя, модификацию, тип КПП, точный пробег до километра Люди вводили эти поля «на глаз» (чтобы просто быстрее закончить с этим) → система выдавала ошибки → заявки не подтверждались → сервис терял деньги
Истинная проблема оказалась не в длине формы, а в неизвестности информации и, как следствие, в высокой когнитивной нагрузке
📚 Теоретическая база: почему 20+ полей — это плохо
Два фундаментальных принципа объясняют провал исходной формы: - Закон Хика (Hick’s Law) Время принятия решения растёт логарифмически с увеличением количества и сложности выбора. 20+ полей — а это десятки решений - Когнитивная нагрузка (Cognitive Load Theory, Джон Свеллер) Рабочая память человека ограничена. Каждый лишний вопрос, особенно требующий специальных знаний, перегружает её Отраслевые бенчмарки показывают: средний процент брошенных форм в автомобильном секторе достигает 68–82%. Наша форма была где‑то в этом диапазоне
✅ Решение: редукция полей на основе кастдевов (один экран, 3 параметра) Я не стала «прятать поля за шагами» (прогрессивное раскрытие) и не делала многоэтапный wizard. Вместо этого я удалила всё, без чего можно обойтись на этапе записи, и свела всё в один экран Как выглядит новая форма (скриншот «Стало»): - Всего 3 специфических параметра (марка/модель, госномер, услуга/дата) - Вся форма — 1 шаг - В 3 раза меньше полей по сравнению с исходной
Что исчезло: Объём двигателя, модификация, тип КПП, точный пробег, тип двигателя, год выпуска и т.д.
Почему их можно было убрать: Кастдевы показали, что клиент не может ответить на эти вопросы. А менеджер сервиса — может: уточнить по телефону или по VIN-коду после того, как заявка оставлена
❗️ Важно: технические параметры не потеряны. Они просто переложены на удобный момент (звонок мастера или приёмка авто). Бэкенд не пострадал
✅ Результаты: что измерили после A/B теста Среднее время заполнения сократилось с 4 минут до 1 минуты. Ключевой вывод: Мы не потеряли данные — мы просто перестали требовать от пользователя того, чего он не знает
🤔 Что этот кейс даёт другим дизайнерам:
Три урока, которые можно применить в любом проекте: - Кастдевы — не опция, а необходимость - Команда думала, что проблема в длине формы. Интервью показали: проблема в неизвестности информации. Без CustDev вы рискуете лечить не ту боль - Уважайте границы рабочей памяти пользователей
📋 Вместо заключения Этот кейс — не про магию и не про «интуицию». Он про системный подход: кастдевы → теория → редукция → A/B тест → метрики Если вы проектируете формы (в автосервисе, банке, B2B, e‑commerce) — задайте себе вопрос: «А что пользователь точно знает?» Удалите всё остальное
👉 Если нужен дизайнер, который умеет работать с метриками, проводить кастдевы и не боится резать поля — пишите Telegram: @LubakaL Telegram канал, где про дизайн просто и с юмором: https://t.me/UI_UX_With_Love