Привет! Меня зовут Константин. Уже второй год мы с командой проектировщиков работаем в БФТ-Холдинге над большим продуктом для государства. Конечно, дело не обошлось без дизайн-системы. Мы познали много боли и сделали немало ошибок, прежде чем создать систему, которой удобно пользоваться. Сегодня я расскажу про ключевые этапы эволюции нашей дизайн-системы (Далее - ДС).
Для кого эта статья? Начинающие проектировать ДС узнают об основных проблемах, которые их ожидают. Опытные пользователи смогут найти для себя новые инструменты управления ДС
План статьи
Этап 1 - Зарождение ДС
Когда мы только начинали строить продукт, нас не особо волновала проблема расширения ДС. Мы хранили все компоненты на одной странице, разграничивая их заголовками. Там же мы размещали правила, черновики концептов и сами концепты…
И однажды мы осознали, что наша ДС начала расти слишком быстро. Инструментов для быстрого нахождения компонентов у нас не было, поэтому поиск нужного элемента превращался в настоящий квест. Приходилось скролить километры фреймов, прежде чем найти нужный.
Проблема этапа 1: отсутствие навигации и поиска по компонентам
Этап 2 - Появление статусной модели
Чуть позже к дизайн-системе получили доступ разработчики. Начались первые проблемы: в разработку стали уходить компоненты, которые находятся на стадии проектирования. Эта проблема натолкнула нас на мысль о создании статусной модели, где будет указано, какой компонент – актуальный, а над каким еще ведутся работы.
Самым очевидным и быстрым решением для нас было делать бордеры у фреймов:
Зеленый — все гуд, можно брать в работу
Красный — не лезь, компонент не согласован
Нам казалось, что это просто и понятно. Нам, но не всем… Мы не учли, что человек, не погруженный в ДС, или только пришедший на проект, не в курсе про наши обозначения. Тем более, что правила статусной модели были оговорены лишь на словах, без документального подтверждения :)
Проблема этапа 2: компоненты уходят в разработку раньше положенного
Этап 3 - Зарождение ДС V2.0
Так больше продолжаться не могло. Поэтому мы решили: пора что-то менять.
Первым делом мы начали разбивать компоненты по своим страницам.
Лайфхак! Когда разносите компоненты на страницы, сохраняйте их первоначальные фреймы. Мы создавали новые фреймы. Итог — все ссылки на компоненты, которые указывались в постановках JIRA, стали неактуальны. Вместо того, чтобы рисовать красивые блоки, мы ходили по JIRA и актуализировали ссылочки в десятках задач :)
Также мы добавили ряд новых фич:
Четкая структура у страниц – «Строение, вариации, примеры»
Мы детально проработали структуру и описание компонент. Для удобства коллег к каждому фрейму мы прикрепили ссылку на песочницу и реализованные кейсы. Это удобно, так как не нужно бегать и искать, где лежит компонент, а где к нему реализация.
Лайфхак! Даже несмотря на то, что информация была хорошо структурирована, к нам поступала куча вопросов: «Какой ширины блок?», «Какая высота?», «А есть ли скролл?»…
Вывод — не поленитесь и выделите важную для читателя информацию. В нашем случае все важное мы помечали желтым бейджем
Декомпозиция компонентов – «Properties» и «Variants»
О пользе данных решений можно говорить долго. Если коротко, то мы разбили компоненты на составляющие, каждую из которых можно настроить.
Properties мы используем, если:
Есть переключаемые конфигурации (версия с иконкой или без)
Есть текстовые (или иные) слои, которые можно настроить через Properties
В Variants мы помещаем компоненты, если:
Есть серьезные визуальные изменения (размер, цвет, стиль)
Есть интерактивные состояния (hover, focus)
Все вместе это работает круто по нескольким причинам:
Вам больше не нужно лазить по слоям, пытаясь включить нужный – все настройки на поверхности
Использование Properties частично наводит порядок в слоях
Больше не нужно создавать кучу вариантов для каждого компонента, достаточно создать несколько и управлять конфигурацией с помощью Properties
Лайфхак! Чтобы не плодить мастер-компоненты и составляющие больших компонент на основных страницах, мы создали отдельную страницу Доп. компоненты для дизайнера. Теперь, если нам нужно добавить к компоненту вариацию, мы идем на эту страницу и создаем еще одно состояние. Важно отметить: эта страница только для дизайнеров. Для всех остальных – это темный лес
Проблема этапа 3: информация об обновлениях компонент несвоевременно доходит до коллег
Этап 4 - Статусная модель. Контроль версий
На этапе 2 мы использовали бордеры в качестве статусов. Идея оказалась провальной.
По итогу мы нашли два способа решить эту проблему:
1. Добавить раздел «В процессе согласования» + иконки на страницах
Решение рабочее: явно указано, какие компоненты еще нельзя брать в работу. Усилить эту историю можно, добавив статусы «В работе» и «На рефакторинге» на сами страницы.
2. Тариф Figma Organization
Мы придерживались концепции, что дизайн-система не должна содержать мусора. То есть коллеги должны видеть в ней только эталонные решения. Для нашего тарифа был доступен функционал Branches (ветки). Получается некая аналогия Github, но для дизайнеров.
Чем хорошо данное решение:
Вы согласовываете все в рамках ветки, а только после этого выгружаете в мастер ДС
При должном оформлении вы сможете контролировать: кто, когда и какой компонент/правку внес
Все в курсе ваших обновлений и это круто: каждую неделю мы обновляли нашу дизайн-систему и оповещали об этом разработчиков и аналитиков в нашем чате
Лайфхак! Местами у нас с коллегами были проблемы с коммуникацией. Все изменения мы делали словно в вакууме — разработчики и аналитики не узнавали о них своевременно. Поэтому мы завели Telegram-канал, где раз в неделю оповещали коллег о новых фиксах и фичах. Это сработало, чем сильно облегчило нам жизнь
Проблема этапа 4: очень много информации, которая находится в разных источниках
Этап 5 - Финальные удобства: «Стартовая страница»
К этапу № 5 мы имеем:
Телеграм-канал с обновлениями
Ютуб-канал с гайдами
Десятки модулей в продукте. В каждом есть свой Telegram-чат с аналитиками и ссылка на макеты (и хорошо бы еще помнить, кто за какой модуль отвечает).
Держать столько информации в голове невозможно. Хранить все в Telegram не вариант — быстро засоряется. Поэтому мы сделали разводящую страницу. В начале мы разместили перечень модулей с ссылками на Telegram-чаты и Фигму. Чуть ниже расположили Базу знаний – это либо полезные гайды, либо связанная с ДС информация, но лежащая в другом месте. И еще ниже — список проектировщиков с их зоной ответственности.
Решение оказалось замечательным: любой сотрудник самостоятельно может зайти на разводящую страницу и найти то, что его интересует, не отвлекая коллег в чатах.
Заключение
По результатам пяти этапов мы получили следующий результат:
Простая и понятная навигация по системе
Находить компоненты стало гораздо быстрее, ведь у каждого появилась своя страница. Содержимое страниц обрело четкую структуру – теперь коллеги могут быстрее находить нужную информацию о компоненте.
Ускоренная работа с компонентами
Благодаря Properties значительно ускорилась сборка макетов. Скажу больше, некоторым аналитикам настолько все стало понятно, что они начали собирать макеты сами, не привлекая к этому дизайнеров. И это о-о-о-очень упростило нам жизнь :)
Понятная статусная модель
Благодаря веткам коллеги видят только эталонные решения. Для дизайнеров появился инструмент контроля и проверки задач внутри команды.
Своевременное получение информации
Вся общая информация о проекте находится в едином пространстве. Появился Telegram-канал, в котором все коллеги получают своевременные обновления о компонентах.
Безусловно, применив все эти практики, ваша жизнь станет намного легче. Но не стоит ожидать, что это полностью избавит вас от головной боли. Также следует понимать: все перечисленные советы могут идеально вписаться в вашу систему, а могут требовать доработок или вовсе оказаться лишними. Я надеюсь, что каждый смог найти что-то новое для себя. А если хотите поделиться опытом проектирования своих ДС, или у вас есть вопросы, пишите в комментариях.
