UXPUB 🇺🇦 Дизайн-спільнота

Cover image for Как мы улучшили сегментированные элементы управления (segmented control)
Редакція
Редакція

Опубліковано

Как мы улучшили сегментированные элементы управления (segmented control)

#ux

Несколько лет назад мы создали сегментированный компонент для дизайн-системы Lyft Product Language (LPL). Возможно, вы читали наше руководство по проектированию и использованию элементов управления выбором. Однако, недавно мы посмотрели на показатели внедрения и использования наших компонентов, и обнаружили, что очень немногие команды использовали сегментированный элемент управления при создании продуктов и функций ?.

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

Определение проблемы

Мы начали с первых принципов и спросили: «Что такое сегментированный элемент управления?» Apple утверждает, что они представляют собой «линейный набор из двух или более сегментов, каждый из которых функционирует как взаимоисключающая кнопка». Они считают, что для перехода между различными представлениями можно использовать сегментированные элементы управления. Google не согласен с использованием сегментированных элементов управления для навигации и говорит, что иногда можно выбрать несколько сегментов – в отличие от Apple. Google также не считает, что сегментированные элементы управления – это элементы управления выбором ?.

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

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

Предыдущие элементы управления выбором

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

Различные сегментированные элементы управления для каждого случая

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

  1. Стилистические различия: элементы управления с разными цветами выделения и фона, формами контейнеров и / или стилями текста.
  2. Семантические различия: элементы управления, используемые для навигации или фильтрации контента (как позволяет Apple) вместо выбора, как предполагалось.

Решайте одну проблему за раз

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

Новые, легкие стили сегментированных элементов управления

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

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

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

Варианты в реальных дизайнах

Тем временем на предмет семантических расхождений мы просмотрели другие системы… и обнаружили больше расхождений ?‍♀️. Во-первых, нет единого мнения о том, как назвать этот паттерн. Помимо сегментированного элемента управления (segmented control), мы видели, что в разных системах оно называется группой кнопок (button group), переключателями (toggle buttons), радио-кнопкой (radio bar) или переключателем контента (content switch). И для каждого нового имени есть разные правила использования. Оказывается, это не просто проблема соглашения о платформе, это мета-проблема для всех дизайн-систем. Неудивительно, что мы видели так много различных его вариантов в наших специализированных командах!

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

Понятные и последовательные отличия

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

Сегментированные элементы управления позволяют пользователям делать один выбор из набора в 2–5 параметров в качестве общей альтернативы радио-кнопкам и раскрывающимся меню. Они наглядно представляют все доступные варианты для пользователей и просты в использовании на мобильных устройствах.

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

Блок-схема экосистемы управления выбором

Вывод

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

  1. Переименование страницы со старым компонентом.
  2. Перемещение страницы со старым компонентом в раздел «DeprecatedDungeon» нашей библиотеки.
  3. Добавление очевидного визуального наложения ко всем вариантам старого компонента, в комплекте с эмодзи призрака ?, за который проголосовала наша команда дизайнеров.

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

Изгнан, но не забыт

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


Перевод статьи medium.com

Найновіші коментарі (0)