Дизайн-система в реалиях студии. WAT?

Как студия Digital Lab внедряла в свои процессы дизайн-систему и что из этого вышло? Опытом делится ведущий дизайнер Слава.

В (не)далеком 2013-м разработчик интерфейсов Брэд Фрост выпустил книгу Atomic Design, где описал принципиально новый подход к построению дизайна. Он предложил разделить его на минимальные составляющие, из которых будут строиться более сложные и функциональные объекты.

Говоря простыми словами, атомарность в дизайне позволяет изменить все, изменив атом, – от молекулы до всех страниц, в которых используется атом.

Как и большинство студий, Digital Lab на постоянной основе работает с разными проектами, которые не подразумевают тотальную привязку к корпоративному стилю клиентов.

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

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

Чтобы не потерять хватку, нам захотелось разобраться в этой технологии и применить ее к своим процессам. Мы выделили 4 основные цели:

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

Мы решили реализовать идеи в мобильной разработке. Пришлось кстати и то, что постоянный клиент из сферы фуд-ритейла согласился на полный редизайн мобильного приложения. Дизайнерам дали зеленый свет. Ура! Погнали!

ВАЖНО! Сегодня мы поделимся опытом только со стороны дизайнеров, иначе «оченьмногобуков».

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

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

Возможно, мы вернемся к Storybook позже, но на данном этапе для нас это скорее рудимент, чем фича.

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

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

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

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

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

Так выглядит мастер-компонент в дизайн-библиотеке и его модификации на странице приложения.

Главной задачей было выстраивание системы отступов, которая максимально снизит количество косяков при разработке.

Поэтому по умолчанию отступ между объектами и до краев экрана равен нулю. Сам объект через auto layout уже включает в себя необходимые отступы с учетом теней (если они есть).

Мы совмещаем использование auto layout и spacing, чтобы избежать излишней вложенности в слоях компонента, и чтобы разработчики лучше понимали, как скейлится объект в зависимости от ширины экрана и увеличения контента.

На изображении показано строение объекта, где:

• Fill позволяет объекту скейлиться,
• Hug увеличивает количество текста и растягивает объект по высоте,
• Fix обозначает фиксированные отступы между объектами.

Для удобства дизайнеры добавляют во варианты компоненты с названием Cover, из которых формируется палитра компонентов.

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

Состав палитры:

• Spacing – прямоугольники с нулевой прозрачностью и фиксированной высотой/шириной (0.5x / x / 2x / 3x /… / 16x);
• System Elements – нативные элементы, кастомные инпуты и т. д.;
• Buttons – всевозможные кнопки с градацией на Primary, Secondary, Mute, Link и т. д.;
• Icon+Illustrations – все иконки, инпуты с изображениями, иллюстрации;
• Controls – свитчи, чекбоксы, радиокнопки;
• Counters Badges – счетчики, индикаторы и т. д.;
• Elements State — элементы, которые могут иметь несколько состояний (Default / Focus / Mute);
• Elements Scaled – элементы с динамической шириной;
• Templates – готовые к использованию компоненты в максимально сложном состоянии.

К сожалению, идеального подхода мы не нашли. На каждый блок приходится свой ряд характеристик (в зависимости от необходимости).

Например, Сounters Badges: «Type=Name, Android / iOS=On/Off, Color=Green(опционально) / Red(опц.) / Yellow(опц.) / White(опц.)».

При этом Unscaled Elements: «Type=Name, Android / iOS=On/Off, State=Default / Focus / Mute / Preloader».

А вот Templates: «Type=Name, Size=And 360 / And 411(опц.) / iOS 320(опц.) / iOS 375 / Preloader».

Есть ряд плюсов, которые не могут не радовать:

• наконец-то в макетах царят красота и порядок при работе любого дизайнера;
• у разработчиков возникает гораздо меньше вопросов, чем раньше;
• стартовая дизайн-система прекрасно живет в новых проектах и без проблем масштабируется;
• скорость разработки проекта увеличилась, рентабельность выросла;
• снизился bus factor: если кто-то заболел или ушел в отпуск, любой дизайнер без проблем может его подменить;
• разработчики стали бережнее относиться к дизайну и стараются сделать продукт максимально приближенным к макетам;
• правки, которые раньше съедали время и портили настроение, сейчас вносятся в считанные минуты и совсем никого не расстраивают :)

Из минусов:

• Дизайн-система требует времени. Мы стали выделять 5–10 % рабочего времени на поддержание целостности и модернизацию дизайн-систем.
• Немного ограничивает фантазию. Порой хочется сделать что-то необычное и вау, но в дизайн-системе уже есть готовое решение и идеи приходится согласовывать дополнительно. Но чаще именно новое, более качественное решение заменяет предыдущее в дизайн-системе.
• Сначала ее сложно принять, а потом – тяжело с ней расстаться (хочется что-нибудь накидать даже в лендингах или баннерах).

Для себя мы решили, что дизайн-система в условиях студии может быть крайне полезна:

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

Важно:

• не вдаваться в крайности и не создавать дизайн-систему на все на свете;
• провести анализ и сделать выводы, стоит ли профит от системы потраченного времени;
• не копировать опыт других компаний.

Дизайн-система – 100%-й must have для крупных брендов, но в студии она вряд ли выживет в привычном виде. К счастью, она может подстраиваться и эволюционировать под любые нужды как живой организм.

Главное понять, как и в какой степени интегрировать ее в процессы, взвесить за и против и только потом приступать к работе.

P. S.: Мы рассказали о нашем опыте работы в новом формате. Будем рады, если он будет кому-то полезен. Спасибо за внимание!