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

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

#form #button #mobile

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

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

Пользуюсь положением редактора UX Notes и прошу: если у вас есть профиль на Хабре, пожалуйста, поставьте там оценку.

#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

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

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

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

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

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

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

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

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

#form

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

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

#form

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

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

#form

Анна Малинина написала об обработке ошибок при заполнении форм.

— Пользователей раздражают не сами ошибки, а то, как интерфейс о них сообщает. Он может быть слишком строгим, неожиданным или непонятным;
— Показывайте ошибку после того, как пользователь закончил заполнять поле;
— Для остальных полей ошибки можно показывать при попытке отправить форму;
— Не сообщайте о пустом поле, если пользователь его просто «потрогал»;
— Пишите понятные и конкретные сообщения. Вместо «Неверный формат» напишите, каким формат должен быть;
— Выбирайте дружелюбный тон и нейтральные слова: «Нельзя вводить больше 128 символов» → «Максимум 128 символов»;
— Лучшее место для отображения ошибки — рядом с полем;
— Для большего внимания к полю (и большей доступности) кроме красного текста ошибки и обводки у поля можно показать иконку с восклицательным знаком;
— Если пользователь попытался отправить форму с ошибками, прокручивайте её к первому полю с ошибкой;
— Не скрывайте сообщение об ошибке сразу, как пользователь перешёл к редактированию поля, чтобы он успел его осмыслить;
— Если текст ошибки о незаполненном обязательном поле будет единым («Это обязательное поле», без повторения названия поля), пользователям проще распознавать такие сообщения, и не будет лишних текстовых переменных;
— Если есть лимит на количество символов, и пользователи могут иногда копировать текст в поле, не обрезайте вставленный текст. Покажите ошибку и счётчик символов.

#form #error