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

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

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

Структура навигации

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

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

Группировка элементов боковой панели

Чаще всего на боковой панели все элементы навигации объединяют в одну группу. Но не все элементы имеют одинаковую природу. Их можно разделить на три группы:

• Элементы контента
• Административные элементы
• Персональные элементы

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

Административные элементы включают данные, связанные с запуском и управлением приложением. К ним относятся функциональные возможности приложения (например, Настройки, Сообщить об ошибке) и любая информация об использовании приложения (например, FAQ, Поддержка).

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

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

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

Группировка элементов верхней панели

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

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

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

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

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

Поле поиска

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

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

Оптимальный дизайн и расположение

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

Перевод статьи The Best Location for Navigation Items on Web Apps из блога UX Movement Newsletter

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

Представьте, что у вас есть книга, которая помогает вам создать отличный UX-дизайн форм ввода и выбора данных. В ней подробно перечислены все примеры и антипримеры в отношении каждого компонента формы. И вы больше никогда не столкнётесь с проблемой, какое дизайн-решение принять при работе с формами. Именно об этом книга “Dos and Don’ts for Form Input and Selection”.

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

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

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

Ссылка на книгу: https://uxmovement.gumroad.com/l/dodontform

Вот несколько примеров из книги.

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

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

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

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

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

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

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

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

Человек на фотографии должен выглядеть привлекательно и профессионально, а также улыбаться. Заголовки должны звучать как диалог. В первом заголовке представителю следует назвать своё имя. Например, важно включить фразу: «Привет! Я — Мария».

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

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

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

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

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

Перевод статьи How to Make Users Fill Out the Longest 13 Field Form Inputs из блога UX Movement Newsletter

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

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

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

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

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

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

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

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

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

*Примечание. AJAX — подход к построению интерактивных интерфейсов веб-приложений, который заключается в «фоновом» обмене данными браузера с веб-сервером. 

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

Если вы разместите сообщение над кнопкой «Посмотреть ещё», то сможете проинформировать пользователей о том, сколько элементов им осталось посмотреть. Например, можно написать: «Просмотрено 24 товара из 144». Так они будут понимать, насколько далеко прокрутили страницу.

Кроме того, можно предусмотреть кнопку «Вернуться к началу». Она возвращает пользователя в начало страницы. Если вы разместите её под кнопкой «Посмотреть ещё», пользователи смогут легко вернуться к первой порции контента, не прокручивая страницу вверх.

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

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

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

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

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

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

Разница между данными «Текущее местоположение» (“Current Location”) и «Пункт назначения» (“Destination”) ничтожна. Везде адреса отображены в одном и том же формате и находятся рядом друг с другом. Более того, между данными «Время отправления» (“Departure Time”) и «Время прибытия» (“Arrival Time”) разница также незначительна. Неудивительно, что пользователи часто неправильно воспринимают информацию.

Рассматривайте данные с позиции визуального восприятия

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

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

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

Этот дизайн содержит гораздо меньше текста, потому что в нём нет названий полей. Обратите внимание, что названия «Номер заказа» (“Order ID”), «Статус» (“Status”), «Текущее местоположение» (“Current Location”), «Пункт назначения» (“Destination”), «Имя клиента» (“Client Name”), «Время отправления» (”Departure Time”), «Время прибытия» (“Arrival Time”) и «Общее время в пути» (“Total Elapsed Time”) удалены. Они излишни. Поскольку их заменили на визуальные элементы, теперь они выполняют свою функцию.

Каждое значение, за исключением «Номера заказа» (“Order ID”), сопровождается визуальным элементом, который улучшает восприятие данных. Теперь вы больше не читаете текст, а обрабатываете информацию на более глубоком уровне, через визуальные элементы. Это не только приятно для глаз, но и для мозга.

Визуальные элементы динамичны, потому что они отражают обновленные данные. Статус меняется с «В пути» (“In Transit”) на «Доставлено» (“Delivered”). Вы также можете видеть, как «двигаются» стрелки времени и местоположения, и линии маршрута заполняются цветом.

Ниже есть ещё один пример формата «Поле: Значение». Как видите, здесь всего три значения, но информацию все равно трудно обработать. Однако, когда вы отображаете данные в визуальном формате, они становятся более лёгкими для восприятия.

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

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

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

Ваша цель — перевести часть «Поле» из формата «Поле: Значение» в визуальный формат. Когда пользователи могут обрабатывать значения данных без названий полей, это означает, что вы всё точно визуально отобразили.

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

Перевод статьи A Better Way to Display Data Than “Field: Value” из блога UX Movement Newsletter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перевод статьи How to Simplify a Confusing 65 Item Mega Menu из блога 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% вертикального пространства, при отключенных параметрах. Страница удлиняется, только когда пользователь активирует настройку. Поскольку большинство страниц с настройками довольно длинные, это существенное преимущество.

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