Многие до сих пор не понимают, что же такое дизайн-система и, например, ошибочно выдают UI-кит за дизайн-систему. UI-кит это важная часть дизайн-системы, но на самом деле это только верхушка айсберга.
Более того, существуют продукты, дизайн-система которых не включат в себя графический интерфейс (UI-кит), например, умная колонка.
Что включает в себя дизайн-система?
Для начала, давайте разбираться, какие артефакты может в себя включать дизайн-система.
Дизайн
Паттерны — система предсказуемых для пользователя повторяющихся элементов интерфейса. Например, паттерн навигации по приложению. Еще больше примеров вы найдете в статье «UX/UI Паттерны что это такое?».
Визуальный язык — часто еще называют «Стилями». Здесь содержится информация о цветовой палитре, иллюстрациях, иконках, радиусах скругления и т. д.
UI-кит — набор компонентов интерфейса, например, кнопки, инпуты, селекты, хлебные крошки и т. д. Качественных и доступных в фигме UI-китов для общего пользования не так много, но мне удалось найти не самый идеальный, но достойный пример от VK. В этом примере помимо UI-кита содержатся стили и шаблоны.
Шаблоны — компоненты UI-кита, которые вместе создают блоки или даже целые страницы. Для примера представьте, какую-нибудь форму отправки заявки, состоящую из нескольких инпутов и кнопки «Отправить». Если эта форма часто встречается в интерфейсе или есть много похожих форм, неплохо было бы её занести в качестве шаблона в дизайн-систему.
Редактура — содержит информацию о том, как мы общаемся с пользователем, например, мы пишем «Вы» с большой буквы или придерживаемся более неформального общения. Есть отличные примеры от Райффайзен банка и Mail.
Код
Компоненты в коде — все компоненты интерфейса должны быть реализованы и аккуратно перенесены в код. Идеально если наименование компонентов в фигме будет совпадать с наименованием компонентов у разработчиков, тогда вероятность того, что какие-то компоненты интерфейса будут реализованы по другому заметно уменьшается.
Виджеты — сверстанные компоненты, которые можно открыть и отдельно каждый покликать, что-то ввести, в общем посмотреть как он реально работает. Например, в дизайн-системе СберБизнеса при просмотре компонента, можно кликнуть «Demo UI».
Стандарты доступности — важная тема о которой еще напишу отдельную статью. Если коротко, то необходимо позаботиться о том, чтобы инструменты, которыми пользуются люди с ограниченными возможностями здоровья, работали корректно, например, «Voice over» и «Talk back».
Песочница разработки — изолированное пространство для разработчиков где храниться код элементов интерфейса.
Процесс
Анонсы — важно чтобы члены команды были в курсе изменений и нововведений в дизайн-системе. Вы можете использовать email рассылки, чаты в мессенджерах, созвоны и т. д. Выбирайте любой удобный для вас инструмент.
Гайды — помимо самих компонентов в фигме и в коде необходимо доступное и понятное описание для всех членов команды. Помимо информации об использовании компонентов, гайды могут содержать описание принципов которых придерживается команда и многое другое. Контур гайды один из лучших примеров, к которому я особенно часто обращался в начале своего пути.
Дизайн-ревью— с целью соблюдения всех правил описанных в дизайн-системе важно проводить ревью среди дизайнеров. Особенно это касается команд в которой есть джуны и мидлы. Правильная реализация ревью это отдельная большая тема и подход сильно зависит от размеров компании.
Техническое ревью — ревью также важно проводить и разработчикам между собой. Я работал в командах где даже рядовые разработчики проверяли код самого опытного коллеги.
Что такое хорошая дизайн-система?
Спойлер — дизайн-система, которая работает.
Если у вас отсутствуют артефакт хотя бы в одной из областей (дизайн, код, процесс) то с большой долей вероятности ваша дизайн-система не работает должный образом. Тут даже в целом возникает вопрос — дизайн-система ли это?
Очень важно, чтобы помимо дизайнерских артефактов вы с разработчиками говорили на одном языке, и у вас были отлажены процессы. Только тогда вы приобретаете все ценности от использования дизайн-системы.
В чем ценность дизайн-системы?
Разработке и дизайну
Легче запустить MVP — в дизайн-системе есть всё для запуска MVP, в следствии чего вы можете быстрее выпустить, что-то новое на реальных пользователей, собрать фидбек и скорректировать свой бэклог.
Возможность заниматься продуктом, а не техникой —вы не тратите каждый раз время на обсуждение каких-то базовых правил и принципов, всё уже продумано и отлажено. В результате вы больше времени посвящаете самому продукту, а не рутине.
Меньше багфикса—когда все члены команды синхронизированы и опираются на единую дизайн-систему, отлажены процессы в т. ч. ревью, возникает меньше багов, которые приходится потом править.
Пользователям
Консистентный дизайн— узнаваемый интерфейс от продукта к продукту и от экрана к экрану. Представьте вы заходите в тёмную комнату и находите выключатель света с левой стороны, заходите во вторую комнату, а выключатель уже расположен за дверью под потолком, заходите в третью, а там выключатель снова на новом месте. Уверен вам это не понравиться. Также и при взаимодействии с цифровым интерфейсом важно чтобы всё работало и выглядело ожидаемо и привычно для пользователя.
Уменьшенный размер продукта—все элементы интерфейса хранятся в одном месте и переиспользуются, в следствии чего данные продукта занимают меньший объем и быстрее грузятся у пользователя, а это важно, т. к. качество интернета далеко не везде идеально.
Бизнесу
Точность планирования и прогнозируемый результат — у бизнеса два любимых вопроса при разработке продуктов «Ну чё когда?» и «Как это будет выглядеть?». Дизайн-система даёт большую прозрачность в планировании и прогнозировании своих ожидании.
-
Экономия средств — час каждого сотрудника стоит денег, а когда команда, используя дизайн-систему, тратит меньше времени на создание новых фичей или запуск нового продукта, то тут всё становится очевидно.
Ключевые шаги построения дизайн-системы
Люди
На данном этапе необходимо с командой сформировать общее представление: для чего нужна дизайн-система, какие артефакты она будет содержать, кто будет учавствовать в её создании. Исходя из этого сформировать принципы, только не абстрактные из серии «мы делаем инновационную дизайн-систему», а чёткие и понятные принципы через призму которых в дальнейшем вы будете всё пропускать.
Примеры принципов:
Дизайн=код — говорит о том, что не важно разработчик зашел в фигму или дизайнер в код, они должны увидеть что-то общее: архитектуру, названия. Настоятельно рекомендую придерживаться этого принципа, т. к. он помогает говорить с разработчиками на одном языке и выстроить позитивные отношения.
Темизация и поддержка экосистемности—работая в экосистеме, например, Сбер, у вашей дизайн-системы стоит вызов поддерживать все типы продуктов, а они для разной аудитории, и здесь уже стоит вопрос про тимизацию, необходимо самим определить уровень этой тимизации.
Все является шаблоном для всего—любой компонент из одного слоя является шаблоном для компонента из следующего слоя т. е. идет каскадная сборка, тот самый атомарный дизайн, возможно измененный, но в целом он самый.
Предсказуемость гибкость и масштабируемость, быстро и консистентно. Учесть будет ли у вас светлая и темная тема, является ли ваш интерфейс мультиязычным и т. д.
Процессы
К созданию дизайн-системы важно относиться, как к созданию любого другого отдельного продукта и чтобы понять, как встроить новые процессы, важно разобраться в текущих и ответить на ряд вопросов:
Как устроен текущий рабочий процесс в команде и компании?
Какие ограничения?
Какие используем инструменты для управления проектами и документацию?
Текущие методы ведения проекта?
Что нужно изменить в текущих процессах?
Какие сильные и слабые стороны текущих процессов?
Планирование
Можно строить планирование на базе диаграммы Ганта, но есть более эффективная модель и несколько инстайтов к ней…
Вычтите отпуска, праздники, заложите возможные больничные дни, всё чтобы понять сколько у вас на самом деле рабочих дней. Довольно очевидно, но многие про это забывают.
Ставьте топ 3 задачи на квартал без которых вы прям точно не сможете.
В конце квартала закладывайте неделю на ЧП. Многие команды это не раз спасало.
Заводите в качестве задач, всё, что занимает больше 2 часов. Если одна какая-то мелочь, то ок, сделали и побежали дальше, но когда таких мелочей много, вместе они способны занимать дни и недели.
При планировании старайтесь учесть все зависимости.
Реализация
Если опускаться от больших сущностей к маленьким у компонента также есть цикл разработки. В конечном счете у вас произойдет релиз и публикация компонента.
При анализе обязательно изучите весь возможный контекст где используется и будет использоваться этот компонент, составьте чек-лист для ревью и не откладывайте написание гайдов в долгий ящик, пусть это будет частью цикла разработки.
Еще немного про дизайн-системы
В конце хочу поделиться ссылками на общедоступные дизайн-системы, которые мне больше всего нравятся, надеюсь и вам они будут полезны, а также хочу добавить, что при создании дизайн-системы важно быть гибким, действовать ситуативно и делать корректировки на основании полученного опыта. Удачи вам!
https://mui.com/material-ui/react-select/?ref=vc.ru
https://atlassian.design/?ref=vc.ru
Вторая часть будет про организацию дизайн-системы, токены, как строить дизайн-систему на токенах и в чём плюсы такого подхода, расскажу про плагин «Figma Tokens», а бонусом дам ссылку на UI-Kit, собранный на токенах.