Разработка дизайн-системы. Часть 1:  артефакты, ценность, ключевые шаги

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

Более того, существуют продукты, дизайн-система которых не включат в себя графический интерфейс (UI-кит), например, умная колонка.

Что включает в себя дизайн-система?

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

Дизайн

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

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

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

• Шаблоны — компоненты UI-кита, которые вместе создают блоки или даже целые страницы. Для примера представьте, какую-нибудь форму отправки заявки, состоящую из нескольких инпутов и кнопки «Отправить». Если эта форма часто встречается в интерфейсе или есть много похожих форм, неплохо было бы её занести в качестве шаблона в дизайн-систему.

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

Код

• Компоненты в коде — все компоненты интерфейса должны быть реализованы и аккуратно перенесены в код. Идеально если наименование компонентов в фигме будет совпадать с наименованием компонентов у разработчиков, тогда вероятность того, что какие-то компоненты интерфейса будут реализованы по другому заметно уменьшается.

• Виджеты — сверстанные компоненты, которые можно открыть и отдельно каждый покликать, что-то ввести, в общем посмотреть как он реально работает. Например, в дизайн-системе СберБизнеса при просмотре компонента, можно кликнуть «Demo UI».

• Стандарты доступности — важная тема о которой еще напишу отдельную статью. Если коротко, то необходимо позаботиться о том, чтобы инструменты, которыми пользуются люди с ограниченными возможностями здоровья, работали корректно, например, «Voice over» и «Talk back».

• Песочница разработки — изолированное пространство для разработчиков где храниться код элементов интерфейса.

Процесс

• Анонсы — важно чтобы члены команды были в курсе изменений и нововведений в дизайн-системе. Вы можете использовать email рассылки, чаты в мессенджерах, созвоны и т. д. Выбирайте любой удобный для вас инструмент.

• Гайды — помимо самих компонентов в фигме и в коде необходимо доступное и понятное описание для всех членов команды. Помимо информации об использовании компонентов, гайды могут содержать описание принципов которых придерживается команда и многое другое. Контур гайды один из лучших примеров, к которому я особенно часто обращался в начале своего пути.

• Дизайн-ревью— с целью соблюдения всех правил описанных в дизайн-системе важно проводить ревью среди дизайнеров. Особенно это касается команд в которой есть джуны и мидлы. Правильная реализация ревью это отдельная большая тема и подход сильно зависит от размеров компании.

• Техническое ревью — ревью также важно проводить и разработчикам между собой. Я работал в командах где даже рядовые разработчики проверяли код самого опытного коллеги.

Что такое хорошая дизайн-система?

Спойлер — дизайн-система, которая работает.

Если у вас отсутствуют артефакт хотя бы в одной из областей (дизайн, код, процесс) то с большой долей вероятности ваша дизайн-система не работает должный образом. Тут даже в целом возникает вопрос — дизайн-система ли это?

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

В чем ценность дизайн-системы?

Разработке и дизайну

• Легче запустить MVP — в дизайн-системе есть всё для запуска MVP, в следствии чего вы можете быстрее выпустить, что-то новое на реальных пользователей, собрать фидбек и скорректировать свой бэклог.

• Возможность заниматься продуктом, а не техникой —вы не тратите каждый раз время на обсуждение каких-то базовых правил и принципов, всё уже продумано и отлажено. В результате вы больше времени посвящаете самому продукту, а не рутине.

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

Пользователям

• Консистентный дизайн— узнаваемый интерфейс от продукта к продукту и от экрана к экрану. Представьте вы заходите в тёмную комнату и находите выключатель света с левой стороны, заходите во вторую комнату, а выключатель уже расположен за дверью под потолком, заходите в третью, а там выключатель снова на новом месте. Уверен вам это не понравиться. Также и при взаимодействии с цифровым интерфейсом важно чтобы всё работало и выглядело ожидаемо и привычно для пользователя.

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

Бизнесу

• Точность планирования и прогнозируемый результат — у бизнеса два любимых вопроса при разработке продуктов «Ну чё когда?» и «Как это будет выглядеть?». Дизайн-система даёт большую прозрачность в планировании и прогнозировании своих ожидании.

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

Ключевые шаги построения дизайн-системы

Люди

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

Примеры принципов:

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

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

• Все является шаблоном для всего—любой компонент из одного слоя является шаблоном для компонента из следующего слоя т. е. идет каскадная сборка, тот самый атомарный дизайн, возможно измененный, но в целом он самый.

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

Процессы

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

• Как устроен текущий рабочий процесс в команде и компании?

• Какие ограничения?

• Какие используем инструменты для управления проектами и документацию?

• Текущие методы ведения проекта?

• Что нужно изменить в текущих процессах?

• Какие сильные и слабые стороны текущих процессов?

Планирование

Можно строить планирование на базе диаграммы Ганта, но есть более эффективная модель и несколько инстайтов к ней…

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

• Ставьте топ 3 задачи на квартал без которых вы прям точно не сможете.

• В конце квартала закладывайте неделю на ЧП. Многие команды это не раз спасало.

• Заводите в качестве задач, всё, что занимает больше 2 часов. Если одна какая-то мелочь, то ок, сделали и побежали дальше, но когда таких мелочей много, вместе они способны занимать дни и недели.

• При планировании старайтесь учесть все зависимости.

Реализация

Если опускаться от больших сущностей к маленьким у компонента также есть цикл разработки. В конечном счете у вас произойдет релиз и публикация компонента.

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

Еще немного про дизайн-системы

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

https://ant.design/?ref=vc.ru

https://mui.com/material-ui/react-select/?ref=vc.ru

https://atlassian.design/?ref=vc.ru

Вторая часть будет про организацию дизайн-системы, токены, как строить дизайн-систему на токенах и в чём плюсы такого подхода, расскажу про плагин «Figma Tokens», а бонусом дам ссылку на UI-Kit, собранный на токенах.