В 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

Ксения Толокнова написала о мобильных клавиатурах.

— При проектировании мобильных форм стоит подумать о подходящих экранных клавиатурах;
— Клавиатура зависит от типа поля ввода, которых около 50 на iOS и 30 на Android;
— Например, для ввода имейла на iOS на клавиатуре с буквами появляются «.» и «@». Для ввода телефона используется цифровая клавиатура с символами «+», «*» и «#»;
— Есть более специфичные варианты, заточенные под ввод определённых наборов символов. Например, dectimalPad для ввода нецелых чисел;
— Можно скрыть строку с рекомендациями (при вводе имейла в ней может быть имейл пользователя), настроить действия при вводе, например: автозамену при орфографических ошибках, написание новых предложений с заглавной буквы;
— Во многих клавиатурах есть кнопка действия (может быть заблокированной). По умолчанию это Return, которая в зависимости от типа поля переключает на следующее поле, создаваёт новую строку, сворачивает клавиатуру;
— В iOS их 12 вариантов: Next переключает на следующий элемент ввода или шаг, Continue переводит на следующий шаг, Search запускает поиск;
— Если в вашей форме на кнопке написано Continue, здорово, если на экранной клавиатуре тоже будет Continue;
— Можно настроить, как скрывать клавиатуру (или не скрывать совсем, как в Ноушене). В iOS-приложении Телеграма она скрывается свайпом вниз, у Ютуба — минимальной прокруткой контента;
— Чтобы в тулбаре появлялись коды из смс, типом поля должно быть OTP;
— Над клавиатурой можно добавить кастомный тулбар (Ноушен, Твиттер). Их можно стилизовать под нативный с помощью серого фона (Google App, Revolut);
— Например, в приложении MyFitnessPal в тулбаре можно менять единицы изменения, одновременно с этим вводя числа в соответствующее поле.

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

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

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

#button #form