исследование обязательности
Нераздражающая валидация
повышаем KPI в государственных учреждениях
- ПродуктУчётные системы на базе Neat UI: большое количество форм с полями ввода, а так же настройки в админке. Пользователи — операторы приема и админы системы. Операторы ограничены во времени приема граждан, а админы взаимодействуют с нагруженными системными настройками.
- ПроблемаАналитики и тестировщики часто «спотыкаются» о пропущенные обязательные поля и настройки, и узнают о них только при попытке сохранения. При возвращении обратно, приходится искать, какая из красных звездочек не прошла валидацию. Так появилась гипотеза о том, что нам нужен какой-то другой подход к валидированию обязательных полей: что-то более заметное в процессе заполнения.
- ТребованияОператор или админ должен видеть обязательные поля сразу, потому что ограничен во времени. Обязательное необходимо обозначать красным, чтобы сохранить преемственность паттерна и минимизировать когнитивную нагрузку восприятия нового интерфейса операторами.
- Контекст операторов приемаОператоры приема в социальных учреждениях имеют 15 минут, чтобы выяснить проблему посетителя, отсканировать документы, заполнить необходимый минимум информации и отпустить человека. При этом есть отвлекающие факторы: посетители задают вопросы, делятся фактами из жизни, забывают документы и доносят их позже. Как правило заявления дозаполняются и запускаются в работу в отдельное от приема время.
- Контекст админаАдмины работают с технически сложными настройками, требующими понимания системы. Обязательные настройки могут затеряться среди опциональных, потому что их соотношение от одного конструктора к другому очень разное и зависит от задач. Кроме того, не любая настройка выражается в инпутах — иногда это какой-то более сложный блок и красная звездочка может потеряться и остаться незамеченной.
- ГипотезаИспользуемые красные звездочки обязательности шумят и бьют сетку, а так же остаются незамеченными в нагруженных интерфейсах, потому что они остаются неизменно красными - поле мало меняется до заполнения и после. Это влияет на ключевые метрики продукта: скорость настройки в админке, скорость ввода данных, количество ошибок.
Контекст ошибки
Обязательность — это одна из многих функций валидации, и незаполненные обязательные поля могут находиться в контексте других ошибок.
Например, условная обязательность: когда необходимость заполнения поля зависит от состояния других полей в реальном времени.
На встречах с заинтересованными стейкхолдерами звучали предпочтения в подходах к валидационным сообщениям, которые не покрывали всевозможные кейсы наших продуктов.
Поэтому я структурировала для себя и коллег известные подходы к валидации форм разной сложности, которые встречаются в наших продуктах.
Например, условная обязательность: когда необходимость заполнения поля зависит от состояния других полей в реальном времени.
На встречах с заинтересованными стейкхолдерами звучали предпочтения в подходах к валидационным сообщениям, которые не покрывали всевозможные кейсы наших продуктов.
Поэтому я структурировала для себя и коллег известные подходы к валидации форм разной сложности, которые встречаются в наших продуктах.
На этой схеме я сразу отметила конфликтующие и, наоборот, более ожидаемые комбинации подходов. Мы наглядно увидели невозможность единственно верного подхода, и далее шли от задач и возможностей, отказавшись от личных предпочтений.
Предупредить ошибку или предупредить об ошибке?
В первом случае интерфейс не допускает того, чтобы пользователь ошибся, то есть отправил запрос с некорректными данными, а во втором случае даёт шанс на ошибку и информирует его.
Первый вариант звучит предпочтительнее, но пользовательский ввод — не единственный способ попадания некорректной информации в систему. Существуют внешние сервисы, импорт и другие пути поступления данных. Так что предупреждать ошибку можно и нужно, но наравне с этим подходом нужно поддерживать и план Б.
В продолжение структурирования всех подходов я вынесла и способы избежания ошибок пользовательского ввода.
Первый вариант звучит предпочтительнее, но пользовательский ввод — не единственный способ попадания некорректной информации в систему. Существуют внешние сервисы, импорт и другие пути поступления данных. Так что предупреждать ошибку можно и нужно, но наравне с этим подходом нужно поддерживать и план Б.
В продолжение структурирования всех подходов я вынесла и способы избежания ошибок пользовательского ввода.
Критерии выбора:
нет плохих приемов, но есть неподходящие обстоятельства
- Общая нагруженность формыЕсли форма не видна целиком, и в ней много обязательных полей и зависимостей, то оператор не видит всей картины. Это значит, что список всех ошибок нужно расположить в одном месте, но обеспечить понятную навигацию оператора к очагам ошибок.
- Скорость заполнения формыВ формах, которые я проектировала, очень много обязательных полей, ввода дат, телефонов, адресов, реквизитов документов. Кроме того, присутствует сложная валидация данных: непересечение дат, контрольные суммы и блокирующие друг друга условия. При этом есть регламент заполнения формы в 15 минут — столько длится приём гражданина специалистом.
В данном случае в ход идет почти всё: маски, подсказки, разбиение форм на простые объёмы данных, степпер, подключение необходимых справочников и особый подход к обязательным полям. - Сложность системы валидацииЯ сталкивалась с ситуациями, когда некорректно заполненным может оказаться практически каждое поле. Если под каждым из них появится сообщение об ошибке, форма покраснеет и структурно поедет. Кроме того, бывают взаимосвязанные поля, и система не всегда может понять, какое из них некорректное.
Ситуация для пользователя по определению неудобная, но можно не усугублять: обойтись без жирных красных рамок, все сообщения вынести в отдельное место, некорректные поля лаконично отметить. - Кто пользователиЕсть случаи, когда нельзя пользоваться цветом как способом передачи информации. Например, проектируется сайт «доступная среда». Среди пользователей будут люди, которые видят цвета не так как все, и допустим красная подсветка незаполненных полей ничего не даст.
В этом случае помогут формы с пошаговым заполнением, спокойные анимации, автофокус, подсветка элементов за счет утолщения линий. - Соотношение цены и качестваЯ стараюсь оценивать вероятность возникновения ошибки, и стоит ли эта вероятность потраченных человекочасов на разработку системы предупреждения ошибок. Как правило, это дороже, чем вывести сообщение о совершившейся ошибке.
Так же стоит учитывать возможности фреймворков и платформ. Безусловно, нет ничего невозможного, но это вопрос времени и стоимости.
В продуктовой разработке вообще хороша итеративность: смотрим, в каких местах пользователь часто ошибается, и предпринимаем меры по ситуации.
Иногда меры — это переработать интерфейс. Допустим, предложить степпер с пошаговым заполнением вместо длинной формы.
В поисках альтернатив красным звездочкам
Все представленные ниже варианты нами рассматривались и разбивались об один из критериев выше: слишком много красного, или бьется сетка, или много шума, или увеличивается форма, которая и так может оказаться нагруженной.
К чему я пришла
Упростить сложное, спрятать бесформенное, локализовать красное.
- Сохранили привычный паттернКруг вместо шумной звездочки значительно разгружает наши сложные формы, но близок к звездочке визуально.
- Гибкий порядок полейМаркер находится внутри поля и не бьет верстку при любом расположении полей.
- "Лампочка перестала гореть"Оператор получает небольшую ачивку: «лампочка перестала гореть», видит прогресс заполнения, интерфейс как будто его похвалил.
- Дополнительная разгрузка формыПри старте заполнения «красных лампочек» больше, чем в конце. По мере заполнения формы, она разгружается: раздражающего красного меньше, заполненных полей больше.
- Фокус на главномЗаполненное поле больше не отвлекает оператора и фокусирует его внимание на пока что пустых обязательных полях. В этой парадигме оставшиееся одно поле намного проще заметить, ведь остальные поля больше не подсвечены.
Проверка гипотезы, A\B тестирование
- Тестовая группа пользователейТестирование за неимением иной аудитории я проводила на коллегах: две группы по 40 человек. Выборка небольшая для количественных исследований, но лучше, чем ничего.
- Задача пользователей«Заполните форму как можно быстрее, не задумываясь. По завершении заполнения нажмите „отправить“. Необязательные поля заполнять не требуется, но если заполнили — оставьте.»
- Замеряемые метрики— скорость заполнения
— количество ошибок
— настроение пользователя - Собираемые данные— время заполнения: между кликом на кнопку «старт» и временем отправки корректной формы),
— количество ошибок: клики на кнопку «отправить» при наличии незаполненных полей
— количество заполненных необязательных полей
— небольшой опрос со смайликами в конце - Минимизация погрешностиДве группы по 40 человек заполняли формы данных о себе — информация, которая не заставляет задумываться и минимизирует погрешность в замере скорости заполнения. Формы отличались только способом обозначения обязательности. Формы были достаточно длинными и не помещались целиком в экран, иначе замеры не дали бы ощутимой разницы.
В данном случае не было возможности полностью повторить контекст админов или операторов со всеми отвлекающими факторами. Поэтому решили минимизировать контекст в целом и выразить его лишь задачей на скорость. - Результат— скорость повысили на 23%
— количество ошибок снизили на 31%
— настроение выше среднего встречается на 15% чаще у группы B
Клик на кнопку «отправить» и заполненные необязательные поля в данном случае считались ошибками одного уровня, потому что важно было проверить, насколько хорошо оператор выявляет обязательные поля среди всех.
В итоге мы реализовали выбранный подход и внедрили во все наши продукты. Позднее реальные пользователи, операторы тестовых подсистем, также дали положительную обратную связь.
Заключение
Мы живём в эпоху глобальной автоматизации, и все равно программам приходится договариваться с пользователем о правилах игры. Валидация заставляет пользователя подстраиваться под приложение. Поэтому очень важно, чтобы просьба программы что-то сделать была для пользователя вежливой, удобной и нераздражающей.