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

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

Эта статья решает четыре проблемы UX-дизайна подсказок:

1. Слишком много текста в подсказке
2. Воздействие на сообщения об ошибках
3. Воздействие на названия полей
4. Неправильное применение подсказки-заполнителя

Слишком много текста в подсказке

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

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

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

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

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

Воздействие на сообщения об ошибках

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

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

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

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

Воздействие на названия полей

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

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

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

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

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

Неправильное применение подсказки-заполнителя

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

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

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

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

Когда использовать текстовые подсказки

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

Используйте текст с подсказками, когда вам нужно:

1. Разъяснить пользователю вопросы конфиденциальности и безопасности.
2. Проинформировать его о том, почему вы запрашиваете конфиденциальные личные данные.
3. Запросить у людей необычные данные, которые требуют разъяснений.

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

Всегда полезно изучить данные, которые вы получаете от пользователей. Если вы заметите, что они постоянно вводят неверные данные, это признак того, что им нужны текстовые подсказки. При условии правильной реализации UX, вы поможете им получить требуемый результат.

Перевод статьи The Best UX Design for Form Field Help Text из блога UX Movement Newsletter

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!

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

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

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

Поиск в меню

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

Поэтому необходимо сократить время прокрутки и внедрить в меню функцию поиска. Она значительно сузит список в зависимости от того, что пользователь будет вводить в поле поиска.

В поле выбора «Отрасль» (Industry) доступно 147 вариантов. Ввод одной буквы сокращает список и отображает варианты, которые начинаются с этой буквы. Чем больше пользователь печатает, тем короче становится список. Обратите внимание, как ввод буквы «С» сократил список со 147 вариантов до 15. Если человек введёт слово «Компьютер» (Computer), список сократится до пяти вариантов, и необходимость в прокрутке и поиске отпадёт.

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

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

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

Режим по умолчанию

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

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

На мобильном устройстве при появлении фокуса клавиатура появится автоматически. Пользователь может скрыть её, нажав кнопку «Готово» (Done), чтобы выбрать вариант из меню. Тем не менее, поиск в меню должен всегда быть в приоритете, поскольку пользователь уже знает, что он ищет.

Когда люди вводят несуществующий запрос, нужно показать пустое состояние, чтобы они знали, что результаты не соответствуют их запросу. Достаточно будет написать в сообщении меню «Нет результатов. Введите новый запрос» (No results. Enter a new search).

Также в поле поиска полезно добавить кнопку для очистки неверного ввода в виде иконки «X». С мобильной клавиатуры сложно выделять и удалять текст, поэтому пользователи мобильных устройств высоко оценят эту функцию.

Чтобы оптимизировать любое объёмное поле выбора, внедрите функцию поиска в меню. Неважно, сколько у вас вариантов — 100 или 1000. Если пользователь знает, что он ищет, поиск варианта будет быстрее и удобнее прокрутки списка.

Перевод статьи Why You Should Never Split Text Field Inputs из блога UX Movement Newsletter

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!

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

Распространённая ошибка — смешивать бинарную логику с переключателями между сегментами. Другими словами, дизайнеры включают в этот компонент варианты «Включить/Выключить» (“On/Off”). Более того, они могут добавить туда опцию «Настроить» (“Custom”), которая позволяет пользователям настраивать параметры. Нельзя объединять всё это в переключатель между сегментами, потому что это запутает людей.

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

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

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

Чтобы логика была последовательной, необходимо отображать переключатель до появления уровня настройки. После того как пользователь включит параметр, ниже появятся опции «Настроить» (“Custom”). Таким образом, опция «Настроить» (“Custom”) больше не совпадает с вариантом «Включить» (“On”) и появляется только при определённых условиях. В логике переключателя между сегментами появляется смысл и взаимоисключение.

Переключение между противоположными режимами

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

Например, в настройке «Режим обрезки» (“Crop Mode”) есть режимы «Фиксированный» (“Fixed”) и «Соотношение» (“Ratio”). Эти опции противоположны, но по стилю и иерархии сегмента выглядят подобными. Вместо того, чтобы отобразить их, как близких родственников, их скорее нужно показать, как противников.

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

Поэтому следует использовать иконки, которые будут представлять различные режимы. Однако подходящих иконок для режимов «Фиксированный» (“Fixed”) и «Соотношение» (“Ratio”) нет. Наиболее наглядный и понятный способ их представления — сохранение пропорций. Пропорции не сохраняются при включенном режиме режим «Фиксированный» (“Fixed”). Однако включенный режим «Соотношение» (“Ratio”) их сохраняет.

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

Однако не стоит отображать эти иконки внутри переключателя, потому что их будет трудно отличить друг от друга. Пользователи будут игнорировать трудно различимые иконки и упускать их из виду. В результате они даже не поймут, что есть функция «Сохранить пропорции» (“Constrain Proportions”).

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

К тому же кнопка переключения занимает мало места и находится в одной строке с текстовыми полями «Размеры» (“Dimensions”). Это идеальное место для кнопки переключения, поскольку режим обрезки применим непосредственно к значениям размеров.

К кнопке переключения также следует добавить всплывающую подсказку, потому что она объясняет функцию иконки. В данном случае, когда пользователи наведут курсор на иконку, появится текст «Сохранить пропорции» (“Constrain Proportions”). Он проинформирует пользователей о функции кнопки переключения.

Переключение между связанными опциями

Для взаимосвязанных опций используют переключатель между сегментами. Например, параметр «Сжатие» (“Compressor”) отображает варианты качества сжатия — «Низкое» (“Low”), «Среднее» (“Medium”) и «Высокое» (“High”). Все они связаны, потому что их можно классифицировать в рамках одной категории.

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

Однако добавление к компоненту варианта «Настроить» (“Custom”) усложняет ситуацию. Этот сегмент позволяет пользователям вручную настраивать качество сжатия, вместо того, чтобы выбирать предустановленную опцию. Проблема в том, что это увеличит ширину переключателя между сегментами, нарушит композицию, а элементы перестанут вписываться в ограниченное пространство.

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

Например, если видимый вариант — «Низкое» (“Low”), легко предположить, что нажатие на стрелку вперёд отобразит опцию «Среднее» (“Medium”), а затем опцию «Высокое» (“High”). Пользователи могут предугадать, каким будет следующий вариант, потому что значения будут увеличиваться.

После варианта «Высокое» (“High”) следует опция «Настроить» (“Custom”). При её выборе под переключаемым инструментом выбора появится компонент слайдера. Там пользователи смогут вручную настроить качество сжатия. Если они переключатся на следующий вариант, слайдер исчезнет.

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

Перевод статьи How to Simplify the Most Confusing Toggle Segments из блога UX Movement Newsletter

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!

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

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

Имя/Фамилия

Пользователи, как правило, воспринимают разделённые поля ввода как единое целое. Например, личность пользователя — не только «Питер» или «Паркер», а сочетание имени и фамилии — «Питер Паркер».

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

У некоторых пользователей есть не только имя и фамилия, но и отчество. Если разделить поля ввода имени, то в таком случае пришлось бы добавить поле «Отчество». Такой подход усложнит форму, увеличит трудоёмкость ввода данных и усилия на переключение между полями.

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

Более эффективный подход — применение единого поля под названием «Полное имя». Оно позволит учесть все интернациональные особенности и длину имён, существенно снижая когнитивную нагрузку.

В скобках вы даже можете добавить к названию поля «имя и фамилия» (first and last), чтобы уточнить тип данных, которые вам нужны. Если вы локализуете свою форму, вы можете указать формат фамилии или имени в зависимости от страны пользователя.

Люди могут ввести только своё имя в поле «Полное имя». Если вы хотите, чтобы они ввели и свою фамилию тоже, установите ограничение для проверки. Поле должно содержать две последовательности в строке, чтобы оно было допустимым. Другими словами их ввод должен включать по крайней мере один пробел.

Номер телефона

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

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

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

Специальные символы и пробелы уже будут в поле по мере того, как пользователи будут вводить данные. Однако всё же стоит сохранить подсказку-заполнитель («XXX»), чтобы люди понимали, сколько цифр им ещё предстоит ввести. Подсказка будет исчезать по мере ввода данных.

Номер кредитной карты

Разделённое поле ввода для номера кредитной карты также состоит из трёх текстовых полей. Три поля усложняют пользователям редактирование текстового ввода, если они ошиблись.

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

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

Дата рождения

Если вы запрашиваете дату рождения пользователя в текстовой форме, вам придётся разделить поля, потому что название месяца станет вариантом выбора в выпадающем списке (статья). Однако если вы запрашиваете дату рождения в числовой форме, то весь текстовый ввод  можно объединить в одно поле.

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

Также следует сохранить подсказку-заполнитель ДД/ММ/ГГГГГ по мере ввода данных пользователями, чтобы они знали, что идёт сначала: месяц или день. Подсказка-заполнитель не исчезнет, пока человек не начнёт вводить данные поверх неё. Это важно, потому что во многих странах сначала указывают день, а не месяц.

Будет ещё лучше, если вы локализуете маску ввода для отображения правильного формата в зависимости от страны пользователя. Таким образом, если пользователь не из Соединенных Штатов, маска ввода может отображаться в формате DD-MM-YYYY или YYYY-MM-DD. Большинство стран мира используют формат День-Месяц-Год. Однако только некоторые применяют формат Год-Месяц-День.

Адрес/Квартира

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

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

Проблема не только в этом. Некоторые могут случайно ввести свой адрес во втором поле. Легко допустить такую ошибку, потому что ширина поля «Квартира» такая же, как и у поля адреса и находится рядом. Оба названия также начинаются с буквы "А" (в английском варианте).

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

Чтобы избежать разделения полей для ввода адреса, используйте единое поле «Полный адрес» и к названию в скобках добавьте «номер квартиры». Когда пользователи увидят название «Полный адрес (квартира)», они поймут, что их просят ввести полный адрес, включая номер квартиры, если он есть.

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

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

Перевод статьи Why You Should Never Split Text Field Inputs из блога UX Movement Newsletter

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!

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

Например, на странице настроек ниже вы видите 15 вариантов с радиобаттонами, которые пользователям предстоит просмотреть. Если они неправильно поймут суть какой-либо настройки, они легко выберут неверный вариант и их впечатление о приложении испортится. Поэтому важно навести порядок на странице настроек с помощью двузначной (есть только два результата: «истина» и «ложь», да-нет, 0 и 1) и условной логики (есть несколько условий).

Двузначная логика

Когда вы смотрите на радиобаттоны, вы видите, что есть только два варианта: когда настройка может быть включена или выключена. Лучше представить эти функции включения/выключения с помощью переключателя.

При выборе переключателя вам не придётся заставлять людей много читать или использовать множество элементов управления. Один переключатель помогает сократить многословные названия до одного краткого названия и количество радиобаттонов до одного элемента управления.

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

В состоянии  «включено» переключатель — синий. Это помогает пользователям быстрее увидеть активные настройки. Остальные элементы страницы — чёрные, что позволяет моментально выделять включенные переключатели.

Условная логика

Если пользователь включает переключатель, появляется больше элементов. В таком случае можно применить настройку к двум условиям: «управление любым проектом» («manage for any project») или «управление только назначенными проектами» («manage for assigned projects only»).

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

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

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

Вместо того чтобы скрывать двузначную и условную логику в списке, компоненты сегмента с переключателем хорошо их иллюстрируют. Если сравнить дизайн с 15 радиобаттонами и дизайн с 6 переключателями, вы увидите, насколько всё стало более упорядоченным.

Сравнение настроек

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

Если вы сравните радиобаттоны и сегменты с переключателем, вы заметите, насколько понятнее стала логика. Названия более краткие, а варианты с условиями видны только при включенном состоянии основной настройки. Другими словами, если переключатель выключен, пользователи не увидят условную логику, потому что в данном контексте это не имеет смысла.

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

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

Перевод статьи How to Simplify a Long 15-Option Settings Page из блога UX Movement Newsletter

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!

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

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

Почему две колонки

Оптимальное количество колонок — две, потому что в большинстве форм есть поля, близкие по смыслу. Например, Имя (First Name) и Фамилия (Last Name) связаны между собой. Поэтому их лучше размещать рядом друг с другом, чтобы пользователи могли сразу увидеть эту связь, сканируя форму по горизонтали.

Другие примеры связанных данных — поле Почтовый индекс (Postal Code), Город (City) и Штат (State). Поскольку люди привыкли видеть их в логической связке, важно объединить их в одной строке. Поля для ввода даты рождения (месяц, день и год) — тоже связанные данные, которые логично расположить рядом.

Блоки полей

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

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

Блоки полей также могут растягиваться и сжиматься. Например, в десктопной версии поле Адрес электронной почты (Email Address) занимает две колонки. Однако на мобильных экранах превращается в одну.

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

Обратите внимание, как поля Город (City) и Штат (State) делят блок поля. Поля для ввода дня и года рождения также разделены в рамках одного блока. В результате эти поля всегда будут расположены горизонтально и выглядеть как близкая пара.

При выборе типа блока поля для данных ориентируйтесь на следующее:

• Если текст ввода длинный, используйте растянутый блок поля
• Если текст ввода короткий, делите блок поля
• Если длина ввода средняя, применяйте базовый блок поля

Место для сообщений об ошибках

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

В примере вы видите вертикальные межколонники, равные 18 пикселям, и горизонтальные пустые строки, равные 24 пикселям. Большие горизонтальные пустые строки позволяют размещать сообщения об ошибках под каждым полем. Каждое сообщение об ошибке должно занимать всю ширину блока поля. Если текст длиннее ширины поля, его следует переносить на следующую строку.

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

Перевод статьи This 2-Column Grid Will Make Your Form Fields Responsive из блога UX Movement Newsletter

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!

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

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

Неоднозначное состояние по умолчанию

Это форма для установки рабочего времени. В ней есть несколько проблем. На первый взгляд состояние по умолчанию кажется неоднозначным. Непонятно, что делать, если бизнес в этот день не работает. Пользователю нужно снять галочку с чекбокса, чтобы указать «Закрыто», но чтобы это понять, нужно немного разобраться в форме.

Кроме того, неясно, какое поле выбора отвечает за время открытия и закрытия. На них есть только надпись «Выбрать» (“Select”), что вынуждает пользователей гадать. Хотя они могут угадать верно, неопределённость всё равно добавляет когнитивную нагрузку.

Длинный список меню

В меню есть 24 варианта для выбора. В этом списке есть временные интервалы: равные часу и полчасу, а минуты отсутствуют. Включение минут привело бы к экспоненциальному увеличению размера меню.

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

Уберите выпадающие списки и чекбоксы

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

В этом случае пользователи сразу понимают, что делать, если их бизнес работает или не работает в определённый день. С помощью переключателя «Открыто/Закрыто» ("Open/Closed") это видно и понятно. Если пользователь выбирает «Закрыто» ("Closed"), поля для ввода времени отображаться не будут.

Управляемые текстовые поля уникальны тем, что они позволяют пользователям контролировать ввод часов, минут и AM/PM по отдельности. Значение по умолчанию в подсказке начинается с «ЧЧ:ММ» ("HH:MM"), чтобы указать час и минуту.

Когда люди выбирают поле, оно выделяет ввод «ЧЧ» ("HH"), чтобы они могли ввести час. После этого пользователи переходят к «ММ» ("MM"), чтобы ввести минуты. Наконец, они переходят к AM/PM и выбирают его, нажимая стрелки вверх и вниз или вводят "P" или "A". Не нужно вводить двоеточие, потому что оно автоматически появится в поле ввода.

Преимущество такого подхода в том, что пользователи могут вводить абсолютное время с точностью до конкретной минуты, а не только до получаса. Ещё один плюс — текстовые поля уточняют время закрытия и открытия с помощью названий «С» ("From") и «До» ("To"). И самое большое преимущество состоит в том, что пользователям больше не нужно просматривать и прокручивать длинные списки меню для ввода времени.

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

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

Сравнение форм для указания рабочего времени

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

Выбор состояния «Открыто/Закрыто» ("Open/Closed") становится более понятным благодаря переключателям. Кроме того, ввод времени закрытия и открытия проще и удобнее для ввода и просмотра. С таким дизайном пользователи могут указать своё рабочее время без лишних сложностей и без выпадающих списков.

Перевод статьи How to Simplify Time Fields Without Using Select Menus из блога UX Movement Newsletter

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!

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

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

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

1. Высота текстового поля должна составлять 60px

Оптимальная высота текстовых полей составляет ровно 60px, не больше и не меньше. При такой высоте вокруг названия поля и текста ввода останется достаточно свободного пространства. Если высота будет меньше 60px, то названию поля и тексту ввода будет слишком тесно внутри поля.

2. Вертикальный отступ между элементами текстового поля равен 12px

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

3. Все внутренние отступы текстового поля равны 12px

Размер всех внутренних отступов, которые окружают текстовые элементы внутри поля, должен быть равен 12px. Неравномерные внутренние отступы приведут к тому, что название поля и текст ввода будут выглядеть странно и непоследовательно.

4. Обводка текстового поля серая, а её размер равен 2px

Слабовидящие пользователи не увидят поля с обычной серой обводкой размером в 1px, а чёрная обводка слишком контрастная. Поэтому гораздо лучше использовать обводку, размер которой равен 2px, и выбрать для неё серый цвет. В таком случае все пользователи увидят её, и она не будет отвлекать внимание от текста.

5. Жирным должен быть текст ввода, а не название поля

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

6. Размер шрифта для текста ввода равен 16px

Размер шрифта для текста ввода должен быть равен не менее 16px. Если он меньше этого значения, то когда пользователь будет выбирать поля ввода, мобильные браузеры будут увеличивать его масштаб. Увеличение масштаба может привести к тому, что они будут видеть только левую часть формы.

7. Размер шрифта для названия поля меньше на два пункта

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

8. Текст ввода — чёрный, а название поля — серое

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

Сравнение вариантов выравнивания для названия поля

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

• Текст ввода легче сканировать, не отвлекаясь на визуальные эффекты
• Название поля легче отличить от текста ввода
• Обводки каждого текстового поля легко различимы
• Каждое текстовое поле легко выделить
• Каждая группировка данных понятна

У вас есть всё необходимое для переноса названия поля внутрь и его выравнивания по верхнему краю. На дворе 2023 год. Пришло время оставить в прошлом выравнивания названий полей по левому и верхнему краям и подумать о будущем.

Перевод статьи 8 Rules for Switching to Infield Top-Aligned Form Labels из блога UX Movement Newsletter

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!

Самое разрушительное действие — действие, которое удаляет данные пользователя навсегда. Без возможности отменить или вернуть их. Поэтому необходимо предпринимать дополнительные меры предосторожности, чтобы сделать нажатие на кнопку «Удалить» ("Delete") более безопасным.

Кнопка «Удалить» ("Delete") без мер предосторожности похожа на обычную кнопку действия в модальном окне подтверждения. В результате пользователи будут нажимать на неё, не задумываясь о том, что это может привести к разрушительным последствиям.

Некоторые интерфейсы меняют визуальное оформление, окрашивая цветом кнопку «Отмена» ("Cancel"). Это делает кнопку «Удалить» ("Delete") менее заметной, чтобы она не притягивала к себе взгляд пользователей. Тем не менее, этого всё равно недостаточно для того, чтобы предотвратить опасные удаления.

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

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

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

Чтобы поставить галочку в чекбоксе, достаточно одного щелчка мыши. Затем кнопка «Удалить» ("Delete") переходит из неактивного состояния в активное. Это простое ограничение предотвращает ошибку удаления без высокой когнитивной нагрузки.

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

Язык заголовка и кнопки также выглядит более дружелюбно. Вместо того, чтобы написать «Удалить безвозвратно» ("Delete Permanently"), дизайнер использует «Удалить навсегда» ("Delete Forever"). Это более понятный способ сказать то же самое. Слово «безвозвратно» ("permanently") более техническое и пугающее.

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

Как видите, функции предотвращения ошибок необходимы, чтобы обеспечить безопасность пользователей. Не делайте опасные кнопки удаления похожими на обычные. В случае возможных разрушительных последствий следует предпринимать дополнительные меры предосторожности, чтобы сделать «Удаление» ("Delete") безопасным и надёжным действием.

Перевод статьи How to Make Dangerous Delete Buttons Safer to Click из блога UX Movement Newsletter

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!

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

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

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

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

В дизайне справа палитра более согласованная. Здесь есть дисциплина и контроль в выборе цветов. Помимо этого здесь цвета соответствуют элементам интерфейса. В результате он выглядит более эстетичным и формирует сильный образ бренда.

Четыре цвета

Чтобы создать устойчивый образ бренда нужно четыре цвета: чистый цвет (pure hue), светлый тон (tint), тёмный тон (shade) и тон с добавлением серого (tone). Дальше всё зависит от правильного применения. Вы будете использовать чистый цвет, чтобы создать светлый и тёмный тона, а также тон с добавлением серого.

Чистый цвет (Pure hue)

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

Применение

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

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

Светлый тон (Tint)

Затем вы создаёте светлый тон, добавляя в чистый цвет белый, что приводит к максимальной яркости и низкому уровню насыщенности. В примере ниже яркость светлого тона равна 100%, а насыщенность — 7%.

Применение

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

Тёмный тон (Shade)

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

Применение

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

Также тёмный тон можно использовать для того, чтобы выделить элементы высокого приоритета в режиме тёмной темы. Например, в примере выше тёмный тон есть на карточке «Следующая сессия» («Next session»). Поскольку это самый важный элемент, этот тон позволяет выделить его на светлом фоне.

Также полезно использовать тёмные тона для заголовков. Как правило, большинство дизайнеров выбирают для заголовков чёрный цвет. Однако тёмный тон обеспечивает высокий контраст и делает текст более брендированным и привлекательным.

Тон с добавлением серого (Tone)

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

Применение

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

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

Тон с добавлением серого также можно применять к неактивным иконкам и пунктам меню. Более низкий контраст цветов хорошо показывает неактивные состояния интерактивных элементов.

Типографика

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

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

Перевод статьи How to Fix Apple's Illegible White Button Labels из блога UX Movement Newsletter

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!