Дизайн-системы 101


18.08.2021 Время чтения - 9 минут 763

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


Читайте нас в Telegram.


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

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

Почему стоит использовать дизайн-систему?

При правильном внедрении дизайн-системы могут принести команде дизайнеров множество преимуществ:

Работы по проектированию (и разработке) можно создавать и воспроизводить быстро и в любом масштабе.

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

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

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

Это создает единый язык внутри и между кросс-функциональными командами.

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

Это создает визуальную согласованность по продуктам, каналам и (потенциально разрозненным) отделам.

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

Это может служить обучающим инструментом и референсом для джуниор-дизайнеров и авторов контента.

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

Почему не стоит использовать дизайн-систему?

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

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

Элементы дизайн-системы

В дизайн-системе есть две важные части:

  • «хранилище» дизайна
  • люди, которые управляют им

Хранилище дизайн-системы

Хранилища проектов могут иметь множество форм, но они часто содержат руководство по стилю, библиотеку компонентов и библиотеку шаблонов.

Руководство по стилю

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

Руководство NASA по графическим стандартам 1976 года (NHB 1430.2) – пример тщательного руководства по стилю брендинга. Оно предлагает гораздо больше, чем на удивление современные визуальные примеры. Рекомендации по цветовым комбинациям для улучшения видимости и удобочитаемости, явные принципы дизайна, такие как «Знак следует рассматривать как крупномасштабный заголовок; поэтому формулировки должны быть четкими и краткими. Выражаться желательно кратко, чтобы ускорить коммуникацию, особенно с водителями транспортных средств».
Руководство по стилю контента Mailchimp содержит надежные советы о том, как писать различные виды контента, чтобы они соответствовали ценностям и «тону голоса» компании.

Библиотеки компонентов

Библиотеки компонентов (также известные как дизайн-библиотеки) – это то, что многие люди ассоциируют с дизайн-системами. Эти полные библиотеки содержат заранее определенные, повторно используемые UI-элементы и служат контрольным пунктом для дизайнеров и разработчиков. Там они могут узнать и реализовать определенные UI-элементы. Создание этих библиотек требует значительного времени и ресурсов. Помимо визуальных примеров компонентов, они включают в себя:

  • Имя компонента: специфическое и уникальное имя UI-компонента. Оно нужно, чтобы избежать недопонимания между дизайнерами и разработчиками;
  • Описание: четкое объяснение того, что собой являет этот элемент и как его обычно используют. Иногда сопровождается указаниями о том, что с ним делать, а что нельзя, для разъяснения контекста;
  • Атрибуты: изменения или корректировки, которые можно внести в объект. Они могут понадобится для кастомизации или адаптации компонента для определенных потребностей (изменения могут касаться цвета, размера, формы, копий);
  • Фрагменты кода: фактический фрагмент кода для элемента (некоторые дизайн-системы доходят до того, что делятся кучей примеров и предлагают среду «песочницы» для опробования разных настроек компонентов);
  • Фронтенд и бэкэнд фреймворки для реализации библиотеки (при необходимости), чтобы избежать болезненной и ненужной отладки.
Система Material Design от Google имеет библиотеку компонентов, в которой хранятся гайдлайны по реализации и фрагменты кода (показанные выше) для конкретных операционных систем и фреймворков. А также подробные гайдлайны по дизайну с описанием того, что делать можно, а что не стоит в отдельной вкладке.
Дизайн-система IBM Carbon содержит гайдлайны по особенностям использования, стилю и коду. А также соображения доступности и «песочницу кода» для дизайнеров и разработчиков, чтобы визуализировать любые настройки перед реализацией.

Библиотека шаблонов

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

Дизайн-система Atlassian идентифицирует множество шаблонов, включая шаблон хедера.  Он не только показывает наглядный пример, но также выделяет точный компонент, который дизайнеры должны использовать, и объясняет, как именно следует использовать каждый компонент.
Хотя многим веб-сайтам государственного сектора предстоит еще пройти долгий путь, Система веб-дизайна США (USWDS) является отличной отправной точкой для объединения многих разрозненных отделов и агентств с четкими руководящими принципами. USWDS определяет шаблоны страниц (изображенные выше), а также дизайн-принципы, компоненты и спецификации кодирования.

Команда дизайн-систем

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

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

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

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

Как подойти к внедрению дизайн-системы

Обычно существует три подхода к использованию дизайн-системы:

  • внедрение существующей дизайн-системы
  • адаптация существующей дизайн-системы
  • создание собственной частной или открытой дизайн-системы

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

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

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

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

Заключение

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

Оригинал.

Читайте также: Принципы UX на примере эвристических постеров


Читайте нас в Telegram.