10 тезисов о дизайн-системах

Дизайн-системы значительно упрощают дизайн-процесс. Но как построить саму дизайн-систему так, чтобы она развивалась вместе с продуктом и гибко менялась под новые требования? Об этом — в нашем переводе статьи UX-дизайнера и наставника Diana Wolosin с Medium.com.

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

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

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

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

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

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

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

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

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

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

Конечные пользователи не контактируют с дизайнерскими инструментами (такими, как Figma, Zeplin, Invision или Sketch), но они взаимодействуют с самим продуктом и могут визуально определить несогласованность в системе. У пользователей есть определенные ожидания по поводу функционирования каждого элемента интерфейса — в зависимости от того, как он выглядит и где расположен.

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

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

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

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

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

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

Атомарный дизайн позволяет работать быстрее и обновлять элементы сразу в нескольких макетах автоматически. Это реально меняет правила игры! Рекомендую применять этот метод в любой дизайн-системе.

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

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

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

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

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

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

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

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

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

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

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

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

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