У компании «СКБ Контур» (один из продуктов — облачная бухгалтерия «Эльба») есть интерфейсные гайдлайны. Например, о валидации форм:

— Когда и как показывать сообщения об ошибках;
— Каким должен быть текст;
— Что делать с чекбоксами и группами радиокнопок в формах.

«Мгновенная валидация — появляется в момент ввода без потери фокуса. Не используйте мгновенную валидацию. Мы не хотим преждевременно ругать пользователя, мы хотим дать ему шанс исправиться самостоятельно».

#form #error

Мэтью Стендедж написал о применении неактивных кнопок [English].

Иногда лучше позволить пользователю ошибиться и получить подходящую обратную связь, чем не дать ему ошибиться.

Например, есть форма с обязательными полями и кнопка отправки формы, которая остаётся неактивной, пока пользователь не заполнит форму.

— Неактивная кнопка малозаметна. Размещённый на ней призыв к действию работает хуже;
— Нажатие на неё не приводит к целевому действию и обычно не даёт обратной связи. Непонятно, что делать, если форма вроде как заполнена, а кнопка всё ещё неактивна;
— Пользователи, которые раньше не сталкивались с такими кнопками, будут недоумевать, почему дизайн этой конкретной кнопки отличается;
— Неактивными кнопками в сложном интерфейсе можно закрыть недоступные пользователю функции. Но они всё равно не объяснят, почему функция недоступна.

#form #button

В SimbirSoft написали о проектировании форм. Об этом было уже много публикаций, поэтому я выбрал не самые распространённые советы:

6. Если поле заполнено неправильно, выделите его и напишите, что не так и как это исправить. Можно скрывать текст подсказки к полю (который не помог заполнить его правильно) и показывать только текст сообщения об ошибке.

7. Не располагайте в форме ссылки на другие страницы. Пользователь может перейти по ссылке и не вернуться к форме.

8. Не используйте плейсхолдеры без необходимости. Если в плейсхолдере есть полезная для заполнения поля информация, она пропадёт после заполнения, и пользователь не сможет себя перепроверить. Если информация бесполезна, она только помешает отличать заполненные поля от незаполненных.

10. Не используйте раскрывающиеся списки, если выбрать можно всего из трёх вариантов.

12. Подстраивайте размер полей под предполагаемое содержимое.

13. Оставляйте кнопки формы активными. Если пользователь заполнит не все поля, их можно выделить при нажатии на кнопку отправки формы. О неактивных кнопках есть хорошая статья.

#form

В Everest написали о формах поиска билетов на сайтах авиакомпаний.

— Поиск билетов — один из самых частотных сценариев на сайте авиакомпании. Форму поиска лучше располагать по центру и не совмещать с рекламными каруселями, чтобы те не отвлекали;
— Рядом можно расположить ссылки на следующие по популярности функции: регистрация, управление заказом, статус рейса;
— Полезно определять город вылета по локации пользователя. Если вылетов из его города нет, можно показывать ближайший. Если аэропорт временно не работает, показывать его недоступным и пояснением;
— Пользователи могут вводить неофициальные топонимы (Питер), хорошо бы это учитывать и находить искомые города;
— В списке городов можно показывать сначала популярные, а потом все остальные в алфавитном порядке;
— Только Utair понятно подсказывает, что в полях «Откуда» и «Куда» нельзя указать один и тот же город: «Укажите разные города»;
— Лучше не заполнять по умолчанию поле с датой вылета. Пользователи обычно фокусируются на заполнении пустых полей и могут его пропустить;
— Чтобы искать билет в один конец, на сайте Аэрофлота надо оставить пустым поле с датой возвращения. Возможность явно это указать пользователям привычнее: переключатель «Только туда — Туда и обратно» или кнопка «Обратный билет не нужен»;
— Если пользователь выбрал вариант «Туда и обратно», но дату возвращения не указал, можно искать билеты в один конец;
— Можно добавить крестик для быстрого сброса даты «Обратно»;
— Люди могут искать билеты сильно заранее, удобно иметь возможность выбрать год и месяц в календаре, а не пролистывать его помесячно. Используйте календарь, показывающий сразу 2 месяца;
— В календаре стоит выделять дни, когда рейсы есть. Удобно, если там будет примерная стоимость доступных билетов;
— Ни одна авиакомпания не разрешает выбрать больше билетов для младенцев (без отдельного места), чем выбрано билетов для взрослых, но только Уральские авиалинии отображают подсказку: «Младенцев не может быть больше, чем взрослых»;
— Полезно объяснять, что «младенцы» располагаются на руках у взрослых, без отдельного места.

#form #search

В ITpelag написали для начинающих о полях ввода и формах.

— У поля должна быть подпись. В ней указывайте, что должно быть введено («Имя», а не «Введите имя»). Без двоеточия;
— Не размещайте подпись в плейсхолдере — так пользователь не сможет перепроверить правильность заполнения полей в большой форме;
— В плейсхолдере можно показать формат или пример вводимых данных;
— В поле можно расположить контролы, помогающие его заполнить: сканирование из QR-кода, скрытие и отображение пароля, голосовой ввод;
— Если поле часто очищают, предусмотрите контрол его очистки;
— Ширина поля должна соответствовать вводимым данным — так проще понять, что надо ввести, и убедиться, что поле заполнено верно;
— Маски ввода помогают не ошибиться, например, в количестве необходимых символов;
— Отмечайте необязательные поля. Обычно (если форма спроектирована хорошо) необязательных полей меньше, чем обязательных;
— Проверяйте поле на корректность после его заполнения — фокус ушёл с поля или пользователь нажал на кнопку отправки формы;
— Поля большой формы делите на логические группы или даже на отдельные шаги — чтобы не пугать пользователей её монолитностью или количеством полей.

#input #form

Таня из Everest написала о формах поиска на сайтах клиник.

— Поле поиска заметнее просто иконки;
— Если по нажатию отображать модальное окно поиска, внимание пользователя будет сосредоточено на ключевом действии и появится место для популярных запросов и плейсхолдера, который подскажет, что именно можно искать («Ищите врачей, услуги, статьи и другие материалы»);
— Популярные запросы лучше разделить на категории: анализы, процедуры, приём врача;
— Стоит отображать кнопку «Найти», так как многие привыкли на неё нажимать. Но и нажатие на Enter тоже должно работать;
— После ввода символов в поле стоит показывать подсказки. Удобен переключатель с разделами (врачи, услуги, новости), в которых найдены подходящие страницы, — можно конкретизировать список подсказок;
— Или хотя бы указать категорию конкретной подсказки;
— Стоит выделять, в чём конкретная подсказка совпадает с запросом, чтобы было понятно, почему она отображается;
— На странице с результатами поиска количество найденного помогает решить, готов ли пользователь к такому объёму информации или стоит уточнить запрос;
— Результаты поиска надо группировать по категориям;
— С помощью списка подходящих под запрос категорий можно фильтровать результаты поиска (по умолчанию стоит выбрать категорию, которую выбрал пользователь в модальном окне поиска) или быстро перемещаться между блоками на странице с результатами;
— Полезны способы уточнить запрос: чекбокс «По полису ДМС», по расположению отделения или врача.

#form #search #health

Леви Ковач написал о мобильных формах.

— Если в раскрывающемся списке от 2 до 5 вариантов для выбора, лучше заменить его на Segmented Control. Так сделать выбор можно меньшим количеством нажатий;
— Если вариантов 2 и это, например, «Показать» и «Скрыть», можно заменить его на чекбокс или переключатель;
— Если варианты — это значения в рамках определённого диапазона, можно использовать ползунок;
— Если варианты — числовые значения и пользователи обычно не сильно меняют значения по умолчанию, подойдёт степпер. Меньше нажатий и ошибок;
— Иногда несколько раскрывающихся списков можно объединить в один. Например, выбор даты;
— Располагайте поля в одну колонку;
— Сообщения об ошибке при заполнении поля показывайте рядом с этим полем и показывайте по мере заполнения формы, не перечисляйте неправильно заполненные поля в конце или начале формы;
— Не повторяйте, что поле обязательно для заполнения. Старайтесь исключить из формы необязательные поля. Подписывайте необязательные поля, если такие всё-таки оказались в форме;
— Группируйте связанные поля.

In English. #form #mobile

Лена из Red Collar написала о слайдере для ввода суммы и проектировании кредитного калькулятора в целом.

— Поле для ввода суммы можно объединить со слайдером, чтобы пользователь указывал её, не переключаясь на клавиатуру;
— Кружок слайдера, который пользователь двигает, может быть небольшим, но с областью нажатия от 32 пикселей;
— Длина слайдера должна быть не маленькой, чтобы легко устанавливать нужное значение, но и не большой, чтобы взгляду и курсору не преодолевать большие расстояния по горизонтали;
— Если в слайдере можно указывать значения только с определённым шагом и вариантов для выбора немного, вместо поля со слайдером подойдёт Segmented contol;
— Если числа большие (стоимость недвижимости), округляйте вводимые слайдером суммы до 10000. Так проще воспринимать числа и обсуждать с кредитным менеджером условия;
— Для суммы первоначального взноса показывайте, какой процент она составляет от стоимости недвижимости;
— Для ввода суммы первоначального взноса и срока кредита можно добавить кнопки быстрого выбора популярных значений (например, для первоначального взноса — 15, 20, 25 и 30%);
— Не скрывайте размер переплаты и итоговую сумму, которую заплатит клиент;
— Расскажите о налоговом вычете, который можно получить;
— Покажите размер минимального дохода, необходимого для того, чтобы получить нужный кредит;
— Добавьте подсказки для терминов и пояснений к вычисленным суммам (например, как появилась сумма налогового вычета).

#slider #calculator #form

Александр Мачуговский написал о неактивных кнопках и расположении кнопок в мобильных формах.

— Блокировать действие уместно, когда не выполнены условия для его выполнения;
— Проблема в том, что условия могут быть разными: не хватает данных от пользователя (на текущем экране, прошлом, в сторонних сервисах вроде подтверждения имейла) или компонентов программы (медленный интернет или вычисления, внутренние ошибки);
— Неактивная кнопка не подскажет, в чём проблема, а также плохо заметна;
— Блокировка кнопок может быть полезна для необратимых деструктивных действий, чтобы совершить ошибку было сложнее;
— В мобильной форме фиксированная в нижней части экрана кнопка занимает место, и её преждевременное нажатие (если она не заблокирована) приводит к ошибке. Лучше расположить её в конце формы — пользователь увидит её, прокрутив экран с формой до конца, и она как раз окажется под пальцем;
— Если форма занимает меньше одного экрана, кнопку можно закрепить в нижней части экрана, чтобы на неё легко было нажать;
— Таким образом в длинных и коротких формах пользователь будет видеть кнопки в одном и том же месте.

#form #button #mobile

Я написал, как быстро сделать в Фигме прототип формы, поля которой можно заполнять в любом порядке.

— С этим помогут локальные переменные (Variables) и условия (экшен Conditional);
— Если их не использовать и просто переводить пользователя с одного экрана на другой, для формы из 4 полей потребуется 16 экранов (включая полностью заполненную форму и полностью незаполненную);
— Поля, с которыми будет взаимодействовать пользователь, надо заменить на локальные компоненты с вариантами «Не заполнено» и «Заполнено»;
— Когда пользователь заполняет поле, это надо сохранять в локальную переменную;
— При отображении формы надо проверять переменные и переключать компоненты заполненных полей на нужный вариант: триггер After delay, повешенный на компоненты конкретных полей, плюс экшен Conditional.

#figma #prototype #form

Егор Камелев написал о проектировании форм.

— Каждое поле формы должно быть обосновано. Большое количество может отпугнуть пользователя, но стоит учитывать и мотивацию: если очень надо, пользователь заполнит всё;
— Определите, что произойдёт дальше с данными: кто их получит, в каком виде. Возможно, потребуется задать формат письма с ними или спроектировать страницу в админке, которая их отобразит;
— Как система может обогатить то, что пользователь ввёл? Например, получателю может пригодиться дата и время заполнения формы;
— Если обязательных полей меньше, чем необязательных, можно отметить только первые, чтобы не перегружать интерфейс. И наоборот. Если все поля обязательны, можно ничего не отмечать или ограничиться текстом об этом в начале формы;
— Как будет выглядеть письмо или страница с данными в админке, если необязательные поля не были заполнены?
— Как будут валидироваться поля, данные какого типа и объёма можно ввести, какими могут быть ошибки и текст сообщений о них?
— Что увидит пользователь после отправки формы? Что стоит показать в сообщении об успехе? Например, после заполнения формы обратной связи можно указать, когда и на какой имейл будет отправлен ответ. Так пользователь может перепроверить, что не ошибся в адресе;
— Общие принципы работы форм можно определить отдельно и в дальнейшем применять ко всем формам в продукте. Например, из менее очевидных: допустимость автофокуса на первом поле формы, время жизни сессии, автосохранение данных, сообщение при попытке покинуть страницу, защита от роботов и так далее.

#form

Александр Мачуговский написал, как сообщать пользователю о пустых обязательных полях формы.

— Правило хорошего UX — дать пользователю возможность вернуться в предыдущий режим, к изначальному состоянию;
— Пользователь нажимает на кнопку отправки формы, все пустые поля переходят в состояние Error, в нормальное состояние они возвращаются по очереди по мере заполнения. По сути форма переходит в режим отладки;
— Нажатие на кнопку приводит к изменению состояния полей, но объект взаимодействия — кнопка, с ней связан локус внимания пользователя. Но не она говорит с пользователем, а поля (которые вместо полей ввода стали полями вывода);
— Если автоматически фокусироваться на первом пустом поле, на мобильных это приведёт к отображению клавиатуры и затруднит изучение формы в целом. Можно прокручивать страницу к этому полю, но тогда пользователю придётся нажимать на поле, чтобы его заполнить;
— Стоит разделять ошибки данных (не хватает @ в адресе электронной почты) и ошибки процесса (пришёл ответ сервера о несуществующем адресе);
— Пустое поле — не ошибка данных, а приглашение к взаимодействию;
— Принцип «один экран — одно действие» сокращает количество вариантов для выбора и повышает его скорость;
— Если на экране одновременно одно поле, поднимающаяся при фокусе клавиатура не мешает. Если оставить его пустым, нажатие на «Продолжить» вернёт фокус в поле и отобразит клавиатуру, приглашая к взаимодействию без сообщения об ошибке;
— Если на экране полей много, можно реализовать их последовательное заполнение, переходя между полями кнопкой Next на экранной клавиатуре и прокручивая страницу так, чтобы заполняемое поле было ровно над клавиатурой;
— При попытке отправить форму можно вернуть пользователя к первому неправильно заполненному полю (с сообщением об ошибке), не помечая все остальные.

Копия статьи. #error #form

Вика Шаханина написала о проектировании настройки повторяющегося события в календаре.

— Чтобы не изобретать велосипед, можно изучить существующие решения. Настройка повторяющихся событий есть в нативных календарях в iOS и Android;
— Прежде, чем слепо копировать аналог (если решения разные, надо ещё разобраться, какое достойно копирования), полезно протестировать его на респондентах;
— Тестировать iOS и Android-календарь стоит как на пользователях соответствующей системы (календарь им привычен), так и на пользователях альтернативной;
— Трудности с созданием события, повторяющегося каждые 3 месяца, возникли в Андроиде;
— Чтобы задать характер повтора, надо было нажать на поле «Не повторяется» с двумя стрелками по кругу. Не все догадались на него нажать для настройки повторения (проблема индикатора состояния и команды);
— В самой настройке повтора был заголовок «Повторяется раз в», поле для ввода цифры и селектор с несклоняемыми «день, неделя, месяц, год». Последнее затруднило понимание. Один респондент поставил повтор каждые 4 года, думая, что повтор будет 4 раза в год;
— В итоге выбрали решение из iOS с добавлением склоняемой подсказки о текущей настройке: «Каждые 2 недели», «Каждые 3 месяца».

#form #time

Позабавило сегодня. В компании «Ю-эксперт», которая занимается проектированием интерфейсов, написали об ошибках в форме запроса консультации.

Среди прочих выделили:

1. Нет чекбокса для согласия на обработку персональных данных и ссылки на соответствующий регламент. Почему плохо: люди хотят быть уверенными, что их данные будут в сохранности. Плюс есть законодательные ограничения.

2. Не указано время, когда после отправки запроса с клиентом свяжется менеджер. Клиент не понимает, что произойдёт дальше, может не дождаться ответа и переключиться на общение с конкурентами.

3. В форме надо указать слишком много информации. Например, и номер телефона, и адрес электронной почты. Надо спрашивать что-то одно. Люди не хотят сообщать много сведений о себе, плюс при указании телефона и имейла становится непонятно, как с клиентом свяжется менеджер.

4. Непонятное сообщение об отправке заявки. Например, английский текст, когда остальной интерфейс на русском, или что-то на технарском вроде «Ответ записан».

Плюс ещё 3 ошибки.

Заканчивается статья ссылкой на форму запроса бесплатного аудита юзабилити в компании «Ю-эксперт». И сколько же ошибок в этой форме? Ноль? А вот и нет: все перечисленные выше, то есть 4 из 7 обозначенных в статье.

#form

Антон Жиянов написал об автокомплите.

— Автокомплит (подсказки) помогает правильно ввести сложные данные вроде адреса, модели машины или названия компании;
— Часто его совмещают с валидацией и отображают ошибку, если пользователь вводит что-то непредусмотренное автокомплитом;
— Так можно делать в редких случаях, когда список вариантов ограничен: адреса пунктов выдачи, аэропорты вылета;
— С «открытыми» списками так делать нельзя;
— Если покупатель в магазине укажет неизвестный автокомплиту дом — ничего страшного. Менеджер потом перезвонит и уточнит. Если показывать ему ошибку, он не сможет сделать заказ.

#form