Самый неприятный сценарий при разработке государственного сервиса — не превышение бюджета на этапе разработки, а переплата уже после релиза: когда заявители массово бросают форму на середине, KPI по конверсии не выполнены, а нагрузка на живых сотрудников не уменьшается. Обычно так получается, когда не продуман UX (user experience, или опыт пользователя): как форма устроена и как она взаимодействует с пользователем. Этот параметр очень важно продумать заранее, а не чинить после того, как метрики не сошлись. В этой статье разобрали шесть приемов проектирования удобных онлайн-форм на примере сервиса «ГИС Энергоэффективность», разработанного нашей компанией.
Если в интернет-магазине ошибка в поле приводит к тому, что заказ не будет завершен и превратится в «брошенную корзину», то в государственных сервисах цена плохого проектирования гораздо выше. Чаще всего ошибка в заполнении формы приводит к отказу в предоставлении государственной услуги: пользователь не получает справку, визу, направление к врачу или не может подать отчет. Это вынуждает заново обращаться за услугой, теряя время, которое может быть критичным. Иногда пользователь и вовсе разочаровывается в электронном сервисе и обращается в ведомство лично.
Для государственного или муниципального органа, предоставляющего услугу, это тоже неприятно: в первом случае растет нагрузка на цифровой сервис, что может привести к сбоям, во втором — увеличивается загруженность сотрудников. И в обоих случаях страдает репутация.
Поэтому при разработке государственных сервисов важно обращать особое внимание на онлайн-формы, причем не столько на их дизайн и текст, сколько на UX (user experience, или «опыт пользователя»): то, насколько посетителю сайта удобно, понятно и комфортно заполнять поля для ввода данных. Мы в Uplab много работаем со сложными цифровыми продуктами, в том числе для государства, поэтому у нас выработался свой комплекс приемов и методов для создания таких форм.
Самый очевидный способ минимизировать ошибки при заполнении — убрать ручной ввод. Здесь мы используем простое правило: в каждом поле со свободным вводом проверяем, нельзя ли взять это значение из справочника или реестра.
Каждый пользователь сайта Госуслуги видел этот принцип в действии: например, при выборе поликлиники для прикрепления гражданину не нужно вручную набирать адрес. Учреждение можно найти на интерактивной карте или выбрать из выпадающего списка.
В ГИС «Энергоэффективность», системе электронной отчетности по выбросам СО2, разработанной Uplab, этот принцип работает для организаций. Реквизиты компании — ОКВЭД, ОКАТО, юридический адрес — заявитель указывает один раз при регистрации в системе, а не переносит их в каждый новый отчет вручную.
Если одни и те же данные вводят в нескольких местах, то рано или поздно они расходятся. Не говоря уже о том, что каждый ввод занимает дополнительное время. Поэтому в государственных сервисах, где есть защищенные базы данных, информацию можно автоматически подтягивать в разные формы из других разделов или профиля пользователя.
Если данные есть в базе другого ведомства, автозаполнение технически реализуется через межведомственное электронное взаимодействие. Вместо того чтобы просить пользователя приложить справку или вписать реквизиты, форма сама делает запрос в систему-источник — ФНС, Росреестр, ЗАГС — и получает данные, пока заявитель заполняет соседние поля.
Пример — вход через Госуслуги. Пользователю не нужно заново вводить ФИО, дату рождения, СНИЛС или паспортные данные: один раз подтвержденные в профиле ЕСИА, они автоматически подставляются в каждый новый сценарий, от записи к врачу до подачи заявления на льготу. При оформлении многих услуг не нужно прикладывать выписку из ЕГРН, чтобы подтвердить право собственности на квартиру, — система запрашивает эти сведения в Росреестре сама.
У приема есть ограничение: он работает только там, где ведомство-источник данных подключено к межведомственному обмену и отдает актуальную информацию. Если сведения в реестре устарели или запрос идет с задержкой — а на практике так бывает, — форма должна показать пользователю статус проверки, а не блокировать заявку. Иначе автоматизация вернет ту же ошибку, от которой должна была избавить, только теперь без возможности исправить ее самому.
Пользователи не любят длинные сценарии, и единая форма ввода данных на несколько десятков полей скорее отпугнет их. Конечно, в государственных сервисах клиент не может закрыть страницу с мыслью «пойду поищу у конкурентов». Но когда он смирится с неизбежным и начнет заполнять такую форму, есть большая вероятность, что дело не дойдет до конца: данные могут сброситься из-за сбоя соединения, пользователь может отвлечься или потерять концентрацию и допустить ошибки.
Разбивка на шаги — это сразу несколько плюсов:
заполнение можно прервать и продолжить,
ошибки появляются постепенно, а не сваливаются списком в конце,
пользователь лучше фокусируется на сценарии, потому что у него есть «передышки».
Важное дополнение: форму нельзя просто порезать на части, шаги должны совпадать с этапами сценария. Если разбивка просто делит поля на три части, то она добавляет лишние клики и ничего не улучшает.
Пример — форма подачи заявления на загранпаспорт нового образца на Госуслугах. Она разбита на шаги, которые повторяют разделы бумажной анкеты, уже знакомой многим получателям услуги:
Тип паспорта — на 10 лет или на 5, обычный или биометрический, на себя или на ребенка. Этот выбор определяет, какие поля появятся дальше.
Личные данные — ФИО, дата и место рождения, СНИЛС, паспорт РФ.
Смена фамилии — шаг показывается только тем, кто ее менял, для остальных пропускается целиком.
Трудовая деятельность за 10 лет — место работы или учебы, должность, период. В бумажной анкете это отдельный лист, и на сайте это отдельный шаг с собственной логикой добавления нескольких мест работы.
Воинский учет — показывается только мужчинам призывного возраста.
Фотография — загрузка снимка 35×45 мм с проверкой требований (фон, отсутствие рамки) сразу после загрузки, а не после отправки всей формы.
Способ получения ответа и оплата госпошлины — с указанием скидки 30% при оплате онлайн.
Проверка данных перед отправкой.
Сложные онлайн-формы в государственных сервисах, например, заявление на загранпаспорт, которое мы рассмотрели выше, редко заполняют за один присест: данные собирают из нескольких источников, что-то требует уточнений. Без черновика человек держит все это в своем файле и переносит в форму руками, а ручной перенос — это распространенный источник ошибок.
Вместе с черновиком имеет смысл продумать: что происходит с незавершенным отчетом к дедлайну и напоминает ли о нем система. Это убережет пользователя от проблем из-за просроченных документов и поможет поддерживать порядок в черновиках.
Пример — ГИС «Энергоэффективность», где черновик — это первое официальное состояние отчета, до подписания. Также в ГИС «Энергоэффективность» уведомления о приближении срока сдачи приходят автоматически, поэтому пользователь знает, что ему пора вернуться к неподписанным отчетам.
Проверка внутренней логики формы (или поиск противоречий между разными формами) — не то же самое, что проверка формата или сверка данных со справочником. Она нужна именно в том случае, когда все поля заполнены верно, а вместе противоречат норме.
Коротко о том, как это работает:
Проверка формата сканирует только одно поле: там, где нужна дата, стоит дата, а не текст произвольной длины, номер телефона состоит из нужного количества цифр. Что написано в соседних полях — неважно.
При сверке со справочником система тоже проверяет одно поле, но отвечает на другой вопрос: есть ли введенное значение в готовом списке. Например, существует ли такой регион, такая специальность, такой код.
Проверка на противоречия сравнивает несколько полей друг с другом. Категория прав «В» — верное значение. Срок действия удостоверения «до 2024 года» — тоже верное значение, и по формату, и по справочнику. Но если сейчас 2026 год, а для управления машиной нужны права категория «С», это сочетание нарушает норму, хотя оба поля по отдельности заполнены правильно.
Чтобы находить такие ошибки, в систему закладываются не отдельные допустимые значения, а допустимые сочетания: какие категории прав подходят для управления какими машинам, действует ли удостоверение на сегодняшнюю дату. При этом тип реакции системы на противоречия может быть разным: от подсветки поля и сообщения об ошибке до блокировки отправки формы. Например, в нашем проекте ГИС «Энергоэффективность» у отчета есть отдельный статус — «проверка сомнительных значений». Система не блокирует отправку, а помечает подозрительные цифры, чтобы их посмотрел специалист.
Эксперты Nielsen Norman Group (всемирно известная американская исследовательская и консалтинговая компания, лидер и главный авторитет в сфере юзабилити и UX-дизайна) рекомендуют проверять поле сразу после заполнения. Не прятать его во всплывающую подсказку и не выносить в список ошибок в начале формы, а выводить сообщение об ошибке рядом с полем. Мы как разработчики полностью согласны с этим правилом, потому что такая реализация помогает пользователю быстро исправить ошибку и повышает число успешно завершенных сценариев.
Если стоит задача не создавать форму для государственного цифрового сервиса с нуля, а улучшить UX уже существующего решения, мы рекомендуем начать с разбора отказов — возможно, для редизайна будет достаточно только одного или двух приемов. Вот примерный порядок действий:
изучить пользовательские сценарии, собрать статистику отказов (или провести тесты с реальными пользователями);
собрать причины, по которым заявления и отчеты возвращают;
проанализировать, какие проблемы можно решить с помощью приемов, описанных в статье;
провести тесты обновленного решения;
перенести удачные наработки в интерфейс.
К сожалению, часть проблем нельзя вылечить интерфейсом. Иногда причина незавершенных сценариев — сложные регламенты получения услуг: например, система запрашивает данные, которых нет у пользователя, или нужно загрузить слишком большой перечень документов.
Если у вас есть форма, с которой пользователи не справляются, — напишите нам через кнопку «Обсудить проект». Мы проведем UX-аудит сайта и предложим решения по улучшению. А если нет, то мы поможем сделать такую.
Комментарии к статье
Комментарии: 0