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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, С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».

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

Из минусов:

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

Важно:

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

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

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