Наш подход к управлению дизайн-системами

Главное, зачем нужно систематизировать дизайн в крупном продукте – чтобы от релиза к релизу все элементы дизайна сохраняли один и тот же вид и смысл. Решение становится консистентным, а команде не приходится начинать новый интерфейс с отрисовки кнопок. У взрослой системы все базовые элементы уже готовы, и можно сразу заниматься бизнес-задачами.

У команды должен быть единый источник знаний обо всех компонентах дизайна и правильные представления о том, как они функционируют. Иначе в соседних разделах будет разная логика работы с документами, кнопки «Далее» начнут перемещаться из угла в угол. Это не просто неопрятно, но и сильно вредит юзабилити – пользователя придётся раз за разом учить, как ему работать с интерфейсом.

Без дизайн-системы команде будет сложно выйти на постоянные поставки релизов – слишком много придётся пересоздавать заново, уточнять и согласовывать. Дизайн станет бутылочным горлышком для всей команды, которое будет заметно влиять на Time-to-Market.

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

С чего начинается дизайн-система

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

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

Если у вас нет UI-кита, то с каждой новой итерацией проекта и с каждым новым дизайнером будут появляться всё новые элементы – одинаковые по смыслу, разные по логике. UI-кит снижает хаос в компонентах на больших проектах и помогает дизайнерам придерживаться правил, которые они сами сформулировали.

Например, вот часть UI-кита одного из наших продуктов. Здесь собраны цвета с присвоенными переменными, чтобы их легче было использовать в коде, списки шрифтов, отступов, кнопок, иконок со всеми типами наведений.

Взаимодействие с командой разработки

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

В True Engineering создание дизайна проходит в три основных шага:

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

За последние годы у нас сложился набор инструментов, которые мы используем на каждом шаге. Прототипы рисуются в Sketch, с аналитиками экраны и сценарии удобно обсуждать в Miro, а разработчики привыкли использовать Zeplin. Каждый этот сервис отлично справляется со своими задачами, но возникает очевидная проблема – материалы приходится параллельно актуализировать в трёх пространствах.

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

Поэтому в последнее время мы переходим на Figma – платформу, которая объединяет в себе практически всё, что нам нужно для совместной работы над макетами. Здесь можно интенсивно работать над материалами, одновременно вносить множество правок, отправлять макеты заказчику и получать от него комментарии. И поддерживать целые дизайн-системы.

Заключение

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

Так что сейчас мы «собираем чемоданы», а все новые проекты мы сразу запускаем в Figma.