Создание и масштабирование дизайн-системы в Figma: пример из практики

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

Когда швейцарская холдинговая компания ABB приступила к созданию системы проектирования, ее целью было связать воедино единый внешний вид для сотен программных продуктов, многие из которых приводят в действие механические системы, обеспечивающие работу заводов, шахт и других промышленных объектов. . Это была непростая задача для компании с почти двумя десятками бизнес-подразделений и почти 150 000 сотрудников по всему миру. Для Абдула Сиала, который занимал должность ведущего проектировщика в группе систем проектирования ABB из 10 человек, масштабирование библиотеки компонентов и шаблонов зависело от поддержания открытости и прозрачности с упором на обширную документацию.

Роль дизайнера дизайн-системы

Все чаще крупные компании, такие как ABB, имеют команды, занимающиеся исключительно созданием и обслуживанием систем проектирования. «Система дизайна обеспечивает согласованность, выход на рынок в разумные сроки и не позволяет производству застрять на настройках, которые не создают ценности», — говорит дизайнер из Мадрида Алехандро Веласко. Или, как объясняет Александр Брито, дизайнер из Лиссабона, Португалия, «системы дизайна обеспечивают структуру, когда множество людей используют один и тот же набор инструментов. Как будто у всех один язык».

Если традиционное руководство по стилю охватывает основы дизайна — шрифты и цвета, например, — система дизайна имеет гораздо более широкий охват. «Система дизайна — это сочетание руководства по стилю, компонентов дизайна, шаблонов проектирования, компонентов кода и, помимо всего прочего, документации», — говорит Сиал. Когда он работал над системой проектирования АББ, ею регулярно пользовались около 120 проектировщиков. Работа представляла собой версию 4.8 системы, и команда назвала ее «Эволюция дизайна».

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

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

Жизненный цикл компонента

Работая над системой проектирования АББ, Сиал руководствовался одной всеобъемлющей философией: «Документация, документация, документация». Для каждого повторно используемого элемента на веб-сайтах АББ, мобильных экранах или больших автономных экранах Сиал хотел показать то, что он называет жизненным циклом компонента. Это означало обширное ведение записей для всех компонентов и шаблонов — навигационных цепочек, заголовков, полей ввода или кнопок, и это лишь некоторые из них. «Какие путешествия она прошла? Какие решения вошли в него? Таким образом, мы не всегда воссоздаем все заново. Прежде чем что-то попробовать, вы можете прочитать и увидеть, что кто-то это уже тестировал», — говорит Сиал.

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

Документация особенно важна для такой крупной системы проектирования, как у ABB. «С такой большой командой нужно уметь масштабироваться, — говорит он. «Как сделать так, чтобы каждый, кто присоединяется к команде, мог быстро перейти к любому компоненту и понять, как он начинался, как редактировался и какую версию он использует?»

Поиск подходящего инструмента

Существует множество инструментов для создания систем дизайна, включая Figma, Sketch и Adobe XD. Сиал экспериментировала с несколькими, пробуя сочетание инструментов дизайна и управления проектами, прежде чем остановилась на Figma, которая предлагает достаточно места для документации.

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

Настройка иерархии

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

Покрытие

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

Инвентарь, варианты использования и запросы

На этой странице приведены примеры многочисленных способов отображения компонента в цифровом продукте компании. Например, в случае компонента текстового поля на странице инвентаризации будет показано, как текстовое поле выглядит на сайте abb.com по сравнению с тем, как оно выглядит на iPhone, и как оно отображается на устройстве Android. «Инвентаризация позволяет нам четко понять, что уже есть», — говорит Сиал.

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

Ссылки, лучшие практики и конкурентный анализ

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

Тесты и данные

На странице данных результатов тестирования собраны все данные, связанные с тестированием компонента, включая результаты A/B-тестирования и отзывы пользователей и заинтересованных сторон. Короче говоря, Сиал говорит: «Это целая история компонента». Возможно, два года назад команда дизайнеров попробовала новый вариант и обнаружила, что он не работает? «Возможно, мы работали над этим вариантом и по какой-то причине отказались от него», — говорит он. Если это так, такая история может значительно сэкономить время, гарантируя, что дизайнеры не попробуют это снова.

Объем

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

Версии

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

Песочница

Песочница позволяет дизайнерам экспериментировать с различными итерациями компонента или шаблона непосредственно в Figma. «Это может быть грязно, и нет никакой стандартизации», — говорит Сиал. «Это просто игровая площадка, где дизайнер может делать что угодно».

Фигма-компонент

Файл также содержит страницу для самого компонента Figma, элемента пользовательского интерфейса, который легко повторяется во всей дизайн-системе. Дизайнер может вносить изменения в компонент, и это изменение будет распространяться на все экземпляры этого компонента в компании, сохраняя все единообразным. Эта страница будет экспортирована в библиотеку системы дизайна Figma, и любой отдельный дизайнер может перетащить компонент Figma в свой дизайн. Если команде дизайн-системы необходимо внести изменения в компонент, они могут сделать это один раз и развернуть по всей компании.

Правила стиля

Затем дизайнеры и разработчики системы дизайна создают страницу правил стиля, своего рода сводку для элементов, которые, по словам Сиала, «не видны в дизайне». Например, как будет отображаться компонент при прокрутке страницы вниз? Это также место, где команда дизайн-системы отслеживает нерешенные вопросы или проблемы. Он говорит, что был удивлен тем, насколько цельной оказалась эта страница: «Сначала мы думали, что эта страница не так уж важна, но теперь мы понимаем, что проводим здесь большую часть своего времени».

Сдавать

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

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

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

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

Веб-страница документации

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

Сотрудничество является ключевым

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

Это грандиозное предприятие и не обязательно правильный шаг для всех компаний. Стартапам, например, может быть лучше начать с готовой системы, такой как Google Material Design или IBM Carbon Design System, вместо того, чтобы выделять обширные ресурсы на ее создание. Тем не менее, может наступить время, когда этого будет недостаточно, говорит Александр Брито: «Как только у вас есть несколько дизайнеров, работающих вместе, вы начинаете понимать, что нужен кто-то, кто будет создавать правила, которые больше соответствуют продукту или продукту. бренд, который вы создаете».

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

Наличие структуры, включающей обширную документацию, включая историю и лучшие практики, лежит в основе системы дизайна Figma. «Это успех, потому что люди могут прочитать всю документацию в одном месте, — говорит Сиал. «Они могут видеть все, начиная от варианта использования и дизайна и заканчивая передачей и последней страницей компонента. Люди могут видеть весь жизненный цикл компонента».

Вы можете полностью просмотреть файл Figma Абдула Сиала здесь: Шаблон компонента .

Дальнейшее чтение в блоге Toptal Design:

• Последовательность — это ключ — как создать дизайн-систему Figma
• Сила структуры — руководство по моделям систем проектирования
• Понимание систем дизайна и шаблонов
• Сила Figma как инструмента дизайна
• Мини-учебник — Использование возможностей Figma для всего процесса проектирования