Из разговоров с операционными продуктовыми дизайнерами стало понятно, что все компоненты нашей дизайн-системы слишком велики для внутренних инструментов. Многие из этих инструментов содержат полноэкранные таблицы данных и диаграммы. В этих насыщенных информацией контекстах важно, чтобы на экране было видно как можно больше контента, чтобы пользователи могли легко сканировать, анализировать и сравнивать информацию. К сожалению, когда операционные продуктовые команды попытались приспособить существующие компоненты к этим контекстам, они выглядели гигантскими и неуместными.
Гигантские компоненты
На первый взгляд казалось, что нам нужно значительно уменьшить компоненты, чтобы они хорошо работали для операционных продуктов – но насколько маленькими мы можем их сделать, сохраняя при этом стандарты WCAG AA?
Исследование отступов
Доступность является общепринятым стандартом качества Lyft и поэтому не подлежит обсуждению в нашей дизайн-системе. Раньше наши внутренние продукты в основном не проверялись на этот стандарт, потому что не было много централизованных ресурсов или руководящих принципов, которым они могли бы следовать. Неудивительно, что, когда мы подняли минимальный целевой размер указателя до 44px на начальных совещаниях с операционными командами, это стало камнем преткновения и вероятной проблемой.
Вместо того, чтобы продолжать настаивать на этом, мы провели дополнительное исследование. Мы посмотрели, как другие компании решали аналогичные проблемы. Следующие статьи, в частности, очень хорошо прояснили проблему:
- Отступы в дизайн-системахи размер в дизайн-системах от Натана Кертиса
- Использование плотности материала в Webот Уны Кравец.
Тем временем внутри компании мы проверили существующие веб-компоненты, чтобы увидеть, можно ли распространить текущий подход к изменению размеров и отступов на наши продукты.
Репрезентативные строки из таблицы аудита
Мы узнали, что, хотя, для большинства компонентов у нас были размеры «Default» и «Compact», эти имена не всегда соответствовали вертикальной высоте компонентов, размерам содержимого (то есть размерам текста и иконок), горизонтальному и вертикальному внутренним отступам или формам компонентов. (т.е. border radius). Некоторым компонентам не хватало двух размеров, а у других были разные названия версий «Default» и «Compact». Наборы компонентов росли фрагментарно – побочный эффект недосмотра в нашем процессе.
Когда мы добавляем новые компоненты в библиотеки, мы проверяем их использование в различных продуктах, чтобы стандартизировать их размеры. Мы не часто оцениваем все компоненты как набор, поэтому со временем размеры «Default» и «Compact» стали означать несколько разные вещи в разных контекстах.
Перед исследованием мы предполагали, что суть проблемы заключается в том, что для операционных продуктов требуются компоненты меньшего размера, но эти компоненты должны быть по своей природе недоступны для целей указателя. Однако в ходе аудита мы поняли, что никогда раньше не подходили к размеру, интервалу и плотности целостно. Что нам действительно нужно, так это четкие и последовательные правила, касающиеся того, как применять плотность как в потребительских, так и в операционных продуктах.
Определение плотности
Плотность – это перегруженный термин и он обычно относится к плотности экрана или буквальному разрешению дисплеев в пикселях. В то время как внутренние продуктовые команды всегда просили более плотные компоненты для плотных интерфейсов, они не говорили о пикселях и разрешении экрана. В ходе нашего исследования мы обнаружили, что есть 3 измерения, которые делают экран более или менее компактным. Эти измерения включают в себя визуальную плотность или набор пространственных отношений внутри визуальных элементов и между ними на экране, включая:
- Размер содержимого (например, масштаб шрифта, масштаб иконки)
- Внутренний отступ и форма контейнера – пространство внутри контейнера
- Макет – пространство между элементами экрана
Три измерения визуальной плотности
Казалось, что как только мы определили плотность, все остальное начало вставать на свои места. Во-первых, наши размеры «Default» и «Compact» теперь также могут быть определены и стандартизированы. Мы устанавливаем стандартные значения для внутреннего отступа, масштабов содержимого, интервалов и форм контейнеров в соответствии с базовой сеткой 8 пикселей. Мы также стандартизировали стили типографики, которые мы используем в операционных продуктах (скоро появится отдельная статья о них)! Эти решения имели счастливый побочный эффект, значительно упростив процесс принятия решений о добавлении новых компонентов в библиотеку.
Равномерная визуальная плотность для всех компонентов
Грубо говоря, потребительские веб-продукты могут использовать «Default» компоненты, в то время, как рабочие веб-продукты могут использовать «Compact» компоненты. Но мы также выделили определенные исключения и предоставили более подробные инструкции по смешиванию различных вариантов плотности на одном экране на нашем сайте с документацией.
Наконец, мы поняли, что третье измерение плотности (макет) было ключом к созданию доступного, визуально плотного интерфейса. С нашими минимальными требованиями к размерам контента и визуальной высоте (не менее 6 пикселей между каждым элементом интерфейса), мы можем обеспечить доступность цели указателя даже для самых перегруженных макетов. Мы просто определяем интерактивную область каждого компонента, чтобы она немного выходила за пределы его визуальной области и проверяем, чтобы интерактивные области соответствовали нашим требованиям к макету. Чтобы упростить задачу, мы создали вспомогательные компоненты доступности в Figma, чтобы наглядно показать дизайнерам минимально доступную целевую область указателя для каждого интерактивного элемента интерфейса.
Доступная интерактивная шпаргалка
5 простых шагов по исправлению системных отступов
Наш путь к пространственной ясности был извилистым: исправление отступов в существующей зрелой дизайн-системе – занятие непростое. Например, мы узнали о важности публикации изменений размера сразу пакетом, а не по отдельности, когда пользователи системы начали замечать, что некоторые компоненты изменились в размерах и не соответствуют компонентам, которые мы еще не «исправили» (упс)! Мы также узнали, что только энтузиасты дизайн-систем действительно в восторге от обновлений атрибутов, хотя, всем нравятся новые блестящие компоненты.
Если вы пытаетесь адаптировать свою систему для работы с новой визуальной плотностью или, если ваша система страдает от несогласованных размеров и интервалов, как у нас, мы надеемся, что этот план вам поможет:
- Проведите аудит компонентов вашей системы, решите, сколько различных вариантов визуальной плотности вам нужно, и назовите их.
- Для каждого варианта плотности определите значения для размера содержимого, внутренних отступов и формы контейнера, а также интервала макета с точки зрения вашей базовой пиксельной сетки (бонус: вовлекайте пользователей системы в процесс принятия решений)!
- Примените стандартизированные названия и значения визуальной плотности ко всем существующим компонентам (это основная задача, реализация которой может занять месяцы и стратегию надежной коммуникации, но оно того стоит).
- Создавайте новые компоненты, чтобы у каждого компонента была версия для всех вариантов визуальной плотности.
- Публикуйте массовые изменения визуальной плотности в своих библиотеках, чтобы подтвердить тот факт, что это целостное изменение на уровне атрибутов.
Какой бы беспорядочной ни была ваша таблица аудита – знайте, что доступные, насыщенные информацией интерфейсы возможны!
Перевод статьи medium.com
Найновіші коментарі (0)