Продолжаем серию статей о дизайн-паттернах — устоявшихся шаблонах, по которым дизайнеры понимают, чего ожидает пользователь, и какое визуальное решение лучше всего сработает. В предыдущей статье из этого цикла я рассказал, как оформлять кнопки в интерфейсе. На этот раз поговорим о формах.
Эти элементы интерфейса бывают очень разными. Самые простые — как подписка на рассылку: с полем для ввода email и кнопкой «Подписаться». Встречаются и сложные формы, со множеством полей на нескольких страницах. Например, как при оформлении покупки товаров в онлайн-магазине: с именем и контактами получателя, адресом доставки, выбором способа оплаты, данными карты. Рекомендации по всем наиболее распространенным полям форм и составлению формы вы и узнаете из этой статьи. Материал будет интересен начинающим UX-дизайнерам.
Отличаются формы не только масштабом, но и используемыми полями. Они могут быть предназначены для текста, цифр, дат, определенных данных
Самый простой однострочный элемент формы. Он используется для ввода короткого текста, например, имени. В этом поле обязательно должно быть ограничение на количество символов. Хотя я не рекомендую задавать минимальное количество букв, лучше ограничиться только максимальным. Раньше часто встречалось условие с минимумом в три символа, но мужчины по имени Ян сильно расстраивались, когда система не пропускала их имя 🙁
Что касается максимального количества символов, то тут надо понять, что происходит при вводе значения. Допустим, пользователь пишет «Игорь» и нажимает кнопку «Отправить». Эта информация отправляется владельцу сайта в базу данных
Помните: имена все же бывают разной длины. Особенно критичен этот совет для международных проектов. Например, у пользователей из арабских стран может быть вариант вроде «Мухаммед ибн» и далее имена его предков до седьмого колена. Из-за этого вводимое имя может получиться гораздо большим, чем вы рассчитывали изначально. |
Поля для ввода email и номера телефона могут быть как раздельными, так и одним комбинированным полем. В поле «Телефон» в идеале стоит добавлять плейсхолдер с начальными цифрами. В случае Украины это будет +380. Такой шаблон подскажет пользователю, что именно нужно ввести в поле, иначе человек может не понимать, как указывать начало номера: +380, 80, 380 или 093. Да, иногда система может быть настроена так, чтобы считать абсолютно любой вариант. Но лучше зафиксировать прямо в форме желательное начало номера. Тогда пользователь сразу поймет, какой формат ввода от него требуется.
Учтите, что +380 и аналоги сработают только в случае с пользователями из одной страны. Если же в форме предусмотрено несколько стран, эту задачу можно решить разными способами. Например, сделать выпадающий список по странам, где +380 меняется в зависимости от выбранного пользователем государства. Также это может быть дропдаун или редактируемая отдельно часть с флажком страны, чтобы человек быстрее понимал, к какой стране относится первая часть номера телефона.
Поле для пароля тоже текстовое, но его отличает возможность скрыть информацию за звездочками или кружочками. Это решение не позволит узнать пароль злоумышленнику, который подглядывает за действиями пользователя лично «через плечо» или с помощью программы, записывающей все происходящее на экране.
В этом случае надо предусмотреть два состояния для иконки в поле ввода: скрыть и показать пароль. Обычно это глаз — зачеркнутый или открытый. Но здесь возникает довольно холиварный вопрос: какой глаз лучше подходит для того или иного состояния? Проблема в определении, что показывает иконка: статус поля (пароль скрыт, и глаз зачеркнут) или же доступную опцию (пароль скрыт, но глаз открыт и показывает, что по клику на иконку можно увидеть вводимые данные). На практике чаще используется закрытый глаз.
Это поле дает пользователю возможность написать длинный комментарий или более объемный текст. Хотя и в этом случае должно быть ограничение на количество символов, чтобы не натыкаться на ту же отправку «Войны и мира».
И у однострочного, и у многострочного текста есть ограничение на типы символов. Например, в обоих случаях нельзя пропускать похожий на код текст. Это поможет предотвратить отправку на сервер вредоносного кода, который может уйти в базу данных и вызвать серьезные проблемы. Раньше так можно было даже положить какой-нибудь сайт. Сейчас, скорее всего, хостинг-провайдер не пропустит такой код. Он заботится о себе и своих серверах. Но про этот нюанс все равно следует помнить.
В целом же с этим типом полей нужно продумать много моментов, например:
В качестве непрямого примера приведу страницу каталога на Rozetka. Здесь есть названия товаров в две строки. Но что произойдет, если какое-то название будет в три строки или только в одну? Такие вариации карточек дизайнер должен прорисовывать и показать разработчику, чтобы тот увидел, как будет меняться отображение текста. Обычно с заголовком более двух строк остается все равно только две строки, но появляется пробел, и часть названия становится скрытой.
Аналогичная ситуация и с супердлинными полями. Для них в UI-ките можно показать, как форма выглядит пустой, заполненной целиком, с каким-то ошибками и т.д. Причем прорисовать нужно не одно поле, а всю форму для каждого случая. Таким образом будет понятно, как все элементы интерфейса взаимодействуют между собой.
Они необходимы в том случае, когда пользователю надо выбрать один элемент из множества. Обычно в группе радиокнопок не больше 7-8 пунктов. Хотя чаще такие списки включают 3-4 пункта — в зависимости от сложности формы и задачи дизайнера.
Эти элементы форм используются для множественного выбора из приведенного списка. В противовес радиокнопкам в этом случае пользователь может отметить сразу несколько пунктов или опций.
Свитчер (он же тогл
Хотя это не значит, что никто так не делает. Как пример — сайт сети ресторанов Mafia. Здесь дизайнеры применили свитчер для выбора размера пиццы: средней или большой. В этом случае паттерн используется с нарушением. Правда, мы осознаем, что пользователи понимают суть этого свитчера и он не вызывает у них затруднений. Ведь как минимум сделано две подписи — слева и справа. Но это не значит, что свитчер тут используется правильно. Причем с чекбоксом ниже сделано все корректно.
Подходят для ситуаций с очень большим выбором — например, с перечнем городов. Внутри выпадающего списка может быть как одиночный (радиокнопки), так и множественный выбор (чекбокс). Допустим, если нужно выбрать интересующие пользователя стили музыки, их может быть несколько. В таком случае выпадающий список делают с чекбоксами. Кроме того, в такой элемент формы можно встроить поиск. Тогда пользователь вводит первые буквы ответа (например, Х), и система сама предложит все доступные варианты на букву Х для быстрого выбора.
Иногда в форме есть поле с возможностью прикрепления пользователем файла. Например, это может быть при подаче резюме. Этот элемент интерфейса обманчиво прост. Нужно предусмотреть в нем возможность удаления уже выгруженного файла и выполнить прорисовку всех состояний поля.
При этом возникает несколько вопросов:
Все варианты также необходимо прорисовывать. Кроме того, если есть какие-то правила, их надо описывать в форме. Например, о том, что пользователь может выгружать файл только в форматах .pdf, .txt и .xcl, а максимальный размер файла составляет 10 МБ. Обычно подобные правила оформляют серым цветом и маленьким шрифтом ниже под полем.
Такие значения могут применяться для совершенно разных задач. Например, на картинке слева приведен вариант для выбора количества товаров через переключатель добавления с плюсом и минусом. Это простое и понятное решение, но перед его использованием надо подумать о сценариях пользователей.
Представьте сайт по продаже цветов. Кажется, что поштучное указание желаемого количество цветов удобно.
Но если какой-то щедрый человек решил подарить сотню роз, то ему с переключателем придется жать на плюсик 99 раз — это очень долго.
Поэтому когда вы понимаете, что могут быть такие множественные покупки, нужно добавить возможность ввести значение вручную. В таком случае пользователь кликнет на элемент, между плюсом и минусом появится поле ввода (при этом обязательно надо показать пользователю, что это поле ввода!), и человек введет нужное большое значение. А вот если речь идет о сайте продаж, допустим, новых машин, то сотню автомобилей за один раз вряд ли кто-то купит. Тогда будет достаточно простого плюса с минусом.
Второй пример на иллюстрации справа — это слайдеры. Такое поле пригодится для установки желаемого диапазона цен. Здесь опять-таки нужно помнить о деталях. Например, с каким шагом будут меняться значения: 1100, 1200 и далее или лучше дать пользователям более дробные варианты по типу 1101, 1114? Также стоит продумать, как будет меняться выдача. К примеру, если пользователь задал диапазон цен с потолком в 9000, стоит ли показывать еще и товары стоимостью 9050?
С одной стороны, разница не такая уж большая, и подобные товары могут заинтересовать покупателя. С другой — он может сказать: «Зачем мне показывают эти товары? Я же поставил ограничение 9000!». Потому в силу неоднозначности таких трактовок на практике можно встретить оба подхода.
Выбор даты и времени следующий важный элемент формы. Он достоин отдельной статьи, но в рамках этого материала я ограничусь базовым разбором — о том, что люди выбирают дату и время для разных задач. Например, пользователю при регистрации в соцсети надо указать дату рождения, и тогда в поисках нужного года рождения можно листать список очень долго. Возникает вопрос не только упрощения этой задачи, но и добавления «стартового» года по умолчанию.
Казалось бы, вряд ли это будет 2022 год, ведь очень низка вероятность того, что регистрироваться на сайте будет грудничок. Если же это сервис по типу «єМалятко», где регистрируют новорожденных, то 2022-й как раз и будет наиболее востребованным.
Другой пример ввода разных дат: когда пользователь покупает путевку. Подумайте, на какую временную перспективу люди обычно планируют свои поездки? И нужно ли при этом давать диапазон для выбора или лучше предложить фиксированные даты? А теперь сравните ответы с ситуацией на сайте кинотеатра при покупке билетов. Отдаленность дат в этом случае будет куда меньше. Ведь обычно показ фильмов в прогнозируется только на неделю вперед. Соответственно, это будут совершенно разные по оформлению календари.
Главное, что нужно делать дизайнеру в таком случае — изучать чужие подходы к аналогичным ситуациям. Например, у вас предусмотрена регистрация на сайте, и нужно знать даты рождения пользователей? Посмотрите, как это сделано в Facebook — с миллиардом аккаунтов здесь реализован один из лучших вариантов. У вас сервис по покупке авиабилетов или планированию путешествий? Примеров для подражания полно: Booking, Airbnb, Aviasales, tripmydream — там все отлично продумано.
У полей, как и у кнопок, может быть несколько состояний. Зачастую выделяют такие наиболее популярные:
Пассивное. Это базовое, самое простое состояние, которое установлено по умолчанию. Пользователь зашел на сайт, увидел такое поле и сразу понял: его надо заполнить — все стандартно.
Наведение. Это состояние поля проявляется при наведении на него курсора. Показывает пользователю, что поле готово к работе.
Активное. Это состояние вызывается после клика по полю для ввода текста и отражает готовность этого элемента формы к заполнению.
Заполненное. Как не сложно догадаться по названию, такое состояние можно увидеть после заполнения поля пользователем и перехода к другим полям.
Правильно заполненное. Если все данные корректны, поле приобретает именно такое состояние. Например, с его помощью можно показать, что в полях «Введите пароль» и «Повторите пароль» совпадают введенные данные. В случае с именем и фамилией такое состояние поля вряд ли понадобится.
Ошибка. Это состояние появляется, когда человек допустил ошибку во время ввода информации в поле. Например, это может быть ошибка валидации, когда были введены недопустимые символы. Например, буквы в графе для номера телефона или email без значка @.
Недоступное. Состояние, показывающее пользователю, что он не может вводить в какие-либо данные, но такая возможность есть при выполнении неких условий. Например, если он заполнит строку выше или воспользуется каким-то переключателем вроде способа получения товара самовывозом или с доставкой. В последнем случае после выбора пункта доставки поле для указания адреса станет доступным.
Фокус. Состояние фокуса нужно для людей, которые переключаются между элементами по нажатию клавиши tab или когда пользуются другим устройством ввода. Это состояние важно с технической точки зрения. Разработчик его сделает, насколько оно будет отличаться визуально от остальных состояний уже в руках дизайнера.
В завершении статьи поделюсь с вами советами на основе личного опыта. Следуйте этим шагам и вы сможете создавать правильные формы:
А как быть, если у вас два обязательных и 10 необязательных полей? Тогда кажется, что лучше возле двух поставить звездочки. Но на самом деле очень многие отказываются уже и от звездочек, и от Optional. Причина — сейчас крайне редко используют необязательные поля, и это логично. Если поле необязательное, то зачем его вообще запрашивать? Если же поля обязательны к заполнению, но пропущены пользователем, то система выдаст ошибку об этом. |
Конечно, только этими рекомендациями создание хороших и понятных пользователям форм не ограничивается. Но даже таких советов будет достаточно, чтобы продумать все основные поля в формах практически в любом интерфейсе.
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…