Разочаровывающие шаблоны проектирования, которые нужно исправить: выбор дня рождения

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

Эти шаблоны не являются вредоносными или злыми. У них мало общего с вводящими в заблуждение подсказками о файлах cookie или таинственными CAPTCHA, замаскированными под пожарные гидранты и пешеходные переходы. Они также не разрабатываются с плохими намерениями или вредом: никто не просыпается утром в надежде увеличить показатель отказов или снизить конверсию.

Просто с годами некоторые более или менее случайные дизайнерские решения стали общепринятыми и принятыми, и, следовательно, они повторяются снова и снова — часто без вопросов или подтверждения данными или тестированием удобства использования. Они стали устоявшимися шаблонами проектирования. И часто совсем бедные . Снова и снова появляется среди жалоб пользователей во время тестирования.

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

Мы начнем со скромного и, казалось бы, безобидного паттерна, с которым мы все когда-то сталкивались — печально известного средства выбора дня рождения , которое слишком часто оказывается недоступным, медленным и громоздким в использовании. Мы уже подробно писали об идеальных средствах выбора даты и времени, но средства выбора дня рождения заслуживают отдельного разговора.

Разочаровывающий UX: раскрывающийся список/виджеты ко дню рождения, начиная с 2021 года

Каждый раз, когда вы подаете заявление о приеме на работу, открываете банковский счет или бронируете авиабилет, вам, вероятно, придется вводить дату своего рождения . Очевидно, что входные данные — это date , поэтому неудивительно, что интерфейсы используют виджет, похожий на календарь-выбор даты (собственный или пользовательский), или раскрывающийся список для запроса этого конкретного ввода. .

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

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

На практике мы совершаем аналогичные ошибки и со слишком сложными и строгими требованиями к паролю. Нередко людей настолько раздражают эти требования, что они помещают пароли на стикеры на своем экране или прячут их в файле personal.txt на своем рабочем столе, просто чтобы иметь возможность повторно ввести их при необходимости. Корпоративные пароли Wi-Fi и сложный SuperPIN для онлайн-банкинга — хорошие примеры этого в действии.

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

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

В случае ввода дня рождения в ходе юзабилити-тестов клиенты вводят что угодно с июля по июль до 06–6 , часто со случайными разделителями и несколькими опечатками по пути, а также со смешанным порядком дней, месяцев и лет. Проверка этого ввода после отправки не приносит пользы пользователям, потому что они не знают, какое форматирование ввода будет работать. Очевидно, что это также не удовлетворяет наши потребности.

С нашим дизайном мы должны обеспечить уважительное, простое руководство наряду с доступной технической реализацией. Это подводит нас к некоторым общим недостаткам нативных средств выбора даты и раскрывающихся списков.

Подводные камни встроенных средств выбора даты и раскрывающихся списков

К сожалению, встроенные средства выбора даты , запрашиваемые <input type="date"> , сопровождаются множеством кошмаров доступности. На момент написания, когда они используются в готовом виде, они не являются очень доступным выбором практически для любого типа ввода даты. Существует не только множество проблем с программой чтения с экрана, но также проблемы с фокусом и макетом, запутанные и общие сообщения об ошибках.

Я видел большое количество реализаций, полностью отключающих ввод с клавиатуры (см. выше), требующих, чтобы клиенты использовали исключительно виджет календаря встроенного средства выбора даты. И это мучительно, мучительно медленно. Без резервного ввода с клавиатуры пользователям приходится совершать долгий путь между днями, месяцами и годами, выполняя десятки и десятки нажатий или кликов .

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

В этом свете раскрывающиеся списки намного быстрее и проще в навигации. Они доступны по умолчанию, плюс вместо навигации между месяцами и годами достаточно найти нужные числа в 3 списках — дни, месяцы и годы. Но выпадающие списки по-прежнему медленные. У них проблемы с масштабированием. Зажимание прокручиваемых опций утомительно. Они занимают много места. Список лет длинный. И при указании ввода нам нужно нажать на элемент управления, затем прокрутить (обычно более одного раза), найти и выбрать цель и перейти к следующему раскрывающемуся списку. Тоже не воодушевляет.

Поэтому нередко можно увидеть, что выпадающие списки считаются UI последней инстанцией и обычно заменяются кнопками (например, для фильтров), переключателями, сегментированными элементами управления или полями автозаполнения, которые сочетают в себе гибкость текстового поля с гарантией <select> - коробка. Выпадающие списки не так уж плохи сами по себе; просто пользователи тратят гораздо больше времени, чем необходимо, заполняя их данными.

И тогда возникает вопрос о значениях по умолчанию . В то время как с выпадающими списками мы часто по умолчанию вообще не вводим данные ( mm/dd/yyyy ), с выбором даты нам нужно предоставить некоторую отправную точку для просмотра календаря. В последнем случае, по иронии судьбы, «начальная» дата обычно совпадает с датой заполнения формы, например , 15 мая 2021 года . Конечно, это не кажется оптимальным, но какой должна быть правильная дата? Нам нужно с чего- то начинать, верно?

Ну, на самом деле нет правильной даты . Мы могли бы начать раньше или позже, 3 месяца назад или завтра, но в случае выбора именинника все эти варианты являются чистыми догадками. И как таковые, они несколько разочаровывают: без каких-либо данных клиентам может потребоваться прокрутить весь путь от 1901 до конца 1980-х годов, а с некоторым набором данных им нужно будет исправить это, часто перескакивая на десятилетия вперед и назад. Это взаимодействие потребует безупречной точности прокрутки.

Какой бы выбор мы ни сделали, мы почти всегда будем ошибаться . Это, вероятно, будет отличаться для веб-сайта бронирования отелей или службы доставки еды и множества других вариантов использования — только не для ввода дня рождения. Это подводит нас к разговору о том, как объективно оценить, насколько хорошо разработана форма ввода.

Оценка качества дизайна формы

Дизайн можно рассматривать как очень субъективный вопрос. В конце концов, кажется, что у каждого есть свое мнение и предпочтения относительно правильного подхода к той или иной проблеме. Но в отличие от любого самовыражения или искусства, дизайн должен решать проблему. Таким образом, вопрос заключается в том, насколько хорошо конкретный дизайн решает конкретную проблему. Чем однозначнее передача дизайнерского замысла, чем меньше ошибок совершают заказчики, чем меньше их прерывают, тем лучше дизайн. Эти атрибуты измеримы и объективны .

По моему собственному опыту, формы — самый сложный аспект взаимодействия с пользователем. Существует так много сложных аспектов, от микрокопии и макета формы до встроенной проверки и сообщений об ошибках. Правильная работа с формами часто требует надлежащего отображения внутренних и сторонних ошибок во внешнем интерфейсе и упрощения сложной базовой структуры до набора предсказуемых и разумных полей формы. Это может легко стать разочаровывающим кошмаром в сложных устаревших приложениях и сторонних интеграциях.

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

• Ментальная модель
  Насколько хорошо дизайн нашей формы вписывается в ментальную модель клиента? Запрашивая личные данные, мы должны запрашивать ровно тот минимум, который необходим нам, чтобы помочь нашим клиентам начать работу. Мы не должны запрашивать какие-либо конфиденциальные или личные данные (пол, день рождения, номер телефона), если у нас нет для этого веской причины, и объяснить это в пользовательском интерфейсе.
• Сложность
  Сколько элементов ввода мы отображаем на странице, на мобильных устройствах и на десктопах? Если форма содержит 70–80 полей ввода, а не отображает их все на одной странице или использует макет с несколькими столбцами, может быть хорошей идеей использовать шаблон списка задач, чтобы разбить сложность на более мелкие, управляемые фрагменты.
• Скорость ввода
  Сколько времени и усилий нужно заказчику для корректного заполнения данных? Для данного ввода, сколько нажатий/нажатий клавиш/операций требуется для точного заполнения формы заданными данными, при условии, что по пути не будет допущено ошибок.
• Доступность
  Говоря о скорости ввода, мы должны обеспечить поддержку различных режимов взаимодействия, в первую очередь пользователей программ чтения с экрана и пользователей клавиатуры. Это означает, среди прочего, правильно установленные метки, большие кнопки, метки, размещенные над полем ввода, и правильное сообщение об ошибках.
• Масштабируемость
  Если нам когда-нибудь понадобится перевести пользовательский интерфейс на другой язык или адаптировать его для другого форм-фактора, насколько это будет просто и сколько проблем это вызовет? (Типичный пример проблемного решения — шаблон плавающей метки, о нем мы поговорим в отдельном посте.)
• Серьезность прерываний
  Как часто мы прерываем клиентов, будь то загрузка счетчиков, ранняя или поздняя встроенная проверка, замораживание частей пользовательского интерфейса для настройки интерфейса на основе предоставленного пользовательского интерфейса (например, после выбора страны), частота неправильного предварительного заполнения данных, или ошибочно автокорректированные данные?
• Коэффициент успеха формы
  Сколько клиентов успешно заполнили форму без единой ошибки? Если форма хорошо разработана, подавляющее большинство клиентов вообще не должны видеть никаких ошибок. Например, для этого требуется, чтобы мы использовали автозаполнение браузера, порядок табуляции был логичен, а внесение изменений было обычным и очевидным.
• Скорость восстановления
  Насколько высок процент клиентов, которым удалось обнаружить ошибку, исправить ее и перейти к следующему шагу формы? Нам нужно отслеживать, как часто появляются сообщения об ошибках и какие сообщения об ошибках встречаются чаще всего. Вот почему часто бывает полезно зайти в службу поддержки и сначала узнать у них, на что клиенты часто жалуются.
• Частота отказов формы
  Сколько клиентов отказываются от формы? Обычно это происходит не только из-за сложности формы, но и потому, что клиенты не могут найти способ исправить ошибку из-за агрессивных валидаторов или отключенных кнопок «отправить». Это также происходит из-за того, что форма запрашивает слишком много конфиденциальной и личной информации без уважительной причины.

Чтобы понять, насколько хорошо работает форма, мы проводим исследования юзабилити с клиентами, получающими доступ к интерфейсу на своем собственном компьютере — будь то мобильное устройство, планшет, ноутбук или настольный компьютер — на своей собственной ОС, в своем браузере. Просим записывать экран, если это возможно, и использовать протокол мышления вслух, чтобы проследить, где, как и почему случаются ошибки. Мы также изучаем, как быстро клиент переходит от одного поля формы к другому, когда он делает паузу и думает, и когда происходит больше всего ошибок.

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

Теперь давайте посмотрим, как мы можем применить это к задаче ввода дня рождения.

Разработка лучшего ввода дня рождения

Если кто-то спросит вас о вашем дне рождения, вы, вероятно, будете иметь в виду определенную последовательность цифр. Он может быть упорядочен в dd/mm/yyyy или mm/dd/yyyy , но это будет строка из 8 цифр, которую вы повторяете во всех видах документов с самого раннего возраста.

Мы можем использовать эту простую модель ввода дня рождения с помощью простого поля с одним вводом , которое будет объединять все три ввода — день, месяц и год. Это означало бы, что пользователь будет просто набирать строку из 8 цифр, все время оставаясь на клавиатуре.

Тем не менее, этот подход поднимает несколько вопросов:

• нам нужно поддерживать автоформатирование и маскирование,
• нам нужно объяснить позицию ввода дня/месяца,
• нам нужно поддерживать поведение кнопки Backspace на входе,
• нам нужно отслеживать и скрывать/показывать/постоянно отображать маскирование,
• нам нужно поддерживать переходы к определенному значению (например, месяцу),
• нам нужно свести к минимуму клики ярости и навигацию внутри ввода, чтобы изменить определенное значение на мобильных устройствах,
• Если автоматическое создание не используется, нам нужно придумать набор правил очистки и проверки для поддержки любых разделителей.

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

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

Например, часто можно увидеть, как люди вводят 01, понимая, что допустили ошибку, затем меняют ввод на 010, а затем удаляют первый 0, просто чтобы получить перевернутую (и правильную) строку — 10. Избегая автоматический переход от одного поля к другому, мы могли бы создавать меньше проблем и сделать простой пользовательский интерфейс немного более предсказуемым и простым в использовании.

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

На протяжении многих лет я не мог обнаружить ни одной проблемы с этим решением в течение многих лет тестирования, и неудивительно, что шаблон также используется на Gov.uk.

Когда вам все-таки нужен выбор даты

Хотя приведенного выше решения, вероятно, более чем достаточно для ввода дня рождения, оно может оказаться недостаточно хорошим для более общих ситуаций. Нам может понадобиться ввод даты, который менее буквален, чем день рождения, когда клиентам придется выбирать день, а не указывать его (например, « первая суббота июля» ). В этом случае мы могли бы улучшить три поля ввода с помощью виджета календаря , который также могли бы использовать пользователи. Ввод по умолчанию будет зависеть либо от текущей даты, либо от будущей даты, которую обычно выбирает большинство клиентов.

Адам предоставляет простой пример кода для шаблона «Памятная дата» в своей системе дизайна NoStyle. Он решает множество задач по разработке и позволяет избежать множества проблем с доступностью, и все это благодаря тому, что не нужно нажимать на виджеты календаря или ненужной прокрутки по раскрывающимся спискам.

Подведение итогов

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

Когда мы спрашиваем наших клиентов о дате их рождения , мы запрашиваем очень конкретную дату — очень конкретную строку, относящуюся к точному дню, месяцу и году. В этом случае выпадающий список не нужен. Также не выполняется просмотр календаря, по умолчанию используется более или менее случайное значение. Если вам это нужно, по возможности избегайте встроенных средств выбора даты и встроенных раскрывающихся списков и используйте вместо этого доступное пользовательское решение. И полагайтесь на три простых поля ввода с метками и пояснениями, расположенными над полем ввода.

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

Статьи по Теме

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

• Идеальный отзывчивый конфигуратор
• Идеальное сравнение характеристик
• Идеальный слайдер
• Идеальный Аккордеон
• Книга шаблонов проектирования форм Адама Сильвера, опубликованная на SmashingMag
• Подпишитесь на нашу электронную рассылку, чтобы не пропустить следующие.