Привет, это бета. Наш ведущий дизайнер Денис Кунгуров рассказал всё, что нужно знать про ДС. Что нужнее на проекте: дизайн-система или UI-kit? Зачем становиться Шерлоком и доставать лупу? И почему пилить систему вперёд продукта — «путь в никуда»? Все ответы — в статье.
Дизайн-система — это бесконечная работа. Её ведут на протяжении всей жизни продукта. Только вот чаще всего мы работаем не с ДС, а с UI-kit’ом. Что это за покемон?
Это единый набор элементов для интерфейса. Кнопочки, карточки, менюшки и т. д. С помощью него дизайнеры быстро находят нужный компонент.
UI-kit заточен на удобство дизайнера, поэтому у него нет связки с кодом. А вот дизайн-система повышает эффективность всей продуктовой команды: менеджеров, разработчиков, дизайнеров и аналитиков. Поэтому в ней есть и дизайн, и код.
Storybook
Это как библиотека компонентов, только для разработчиков. Компоненты, их токены, правила — всё это разрабы берут из storybook, когда верстают макеты.
Подробная и внятная документация
В дизайн-системах прописано всё: от компонентов до копирайтинга. Допустим, в команду приходит новый дизайнер — его надо погрузить в проект. Чтобы он прочитал всю документацию и остался жив, правила прописываются понятным языком.
Да и дизайнер, который давно в проекте, с помощью понятного текста быстро освежит в памяти, что можно юзать, а что нельзя.
Чёткие правила
Создатели дизайн-систем расписывают токены по чётким правилам нейминга. Они относятся и к другим компонентам — кнопкам, карточкам, лейаутам.
Сепарация сущностей на логические группы
А если простым языком — дизайн-система находится в нескольких файлах. Всё можно найти по категориям.
Организмы наивысшего уровня
Кроме простых элементов в дизайн-системе описаны шаблоны, лейауты и наборы архитектурных решений.
Дизайнеру не нужно с нуля проектировать интерфейс. Он заходит в набор лейаутов. Выбирает нужный. И уже в готовый лейаут вставляет свои кастомные элементы.
В лейауте расписаны все правила поведения интерфейса, например, как будут вести себя стеки по бокам при изменении ширины экрана. Это супер удобно для разработчиков.
Получаются идеальные условия: разработчики не верстают макет, а собирают его из готовых компонентов. Благодаря организмам высокого уровня вся команда работает в разы быстрее.
UI-kit — это просто библиотека элементов в фигме. Документацию и правила чаще всего не прописывают. У него нет storybook. Нет шаблонов, лейаутов и архитектуры. Есть только атомы и простые компоненты, и хранятся они в 1-2 файлах. Вам хватит UI-kit’a, если работаете над небольшим проектом и не собираетесь его масштабировать.
А для работы с большим продуктом нужно разрабатывать дизайн-систему. Это затратная штука, на неё выделяют много сил, времени и денег. В корпорациях над дизайн-системой работает отдельная команда.
Но дизайн-система работает на будущее. Через время она ускорит все рабочие процессы и сохранит команде деньги и силы.
Подход 1. Продукт → Дизайн-система: полное обновление
В этом случае продукт уже запустили, и из его дизайна мы выделяем систему. Дальше пилится масштабный апдейт, где весь продукт переводится в ДС.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
12327 тендеров
проведено за восемь лет работы нашего сайта.
В начале этого года Почта Mail резко стала «другой». Это было полное обновление сервиса. Но с оговоркой: радикальный апдейт был в рамках уже готовой ДС.
Как не облажаться при полном обновлении:
Подход 2. Продукт → Дизайн-система: планомерное обновление
Интерфейс есть, дизайн-системы нет. Здесь происходит постепенный апдейт. Допустим, решаете: кнопка всегда будет выглядеть так. Собирается вся команда, обсуждает идею, и после утверждения конкретный компонент выкатывается в обновление.
Как пример — Яндекс. С пометкой, что здесь речь идёт уже о сформированной дизайн-системе. В рамках неё все продукты компании обновляются планомерно.
Как не облажаться при планомерном обновлении:
Подход 3. Продукт | Дизайн-система: параллельное развитие
Пилим всё одномоментно. Это вариант для компаний с одним продуктом. Если бы сервис доставки Самокат сейчас делал ДС с нуля, ему бы подошёл такой подход.
Из плюсов: удобно прикидывать и масштабировать решения. Придумал кнопку в интерфейсе и сразу забабахал её в ДС. И наоборот.
Из минусов: процессы и коммуникация могут накрыться. Сложно контролировать и продукт, и дизайн-систему так, чтобы всё шло синхронно и каждый в команде понимал, что происходит.
А как не облажаться, если ДС и продукт сковывают друг друга? Сложно внедрить идею, которая качественно улучшит и то и другое. Поэтому при параллельном развитии мало экспериментов, а решения становятся однообразными и скучными.
От такой проблемы никуда не денешься. Если уже внедрён «параллельный» подход, и вам он не нравится — переходите на другой. Ставьте в приоритет продукт, а не дизайн-систему.
Подход 4. Дизайн-система → Продукт: путь в никуда
Сначала создать систему, а потом применять на продукт? У вас даже нет общего видения, а вы уже начали пилить кнопочки.
Так делать не надо. Система будет сковывать. Вас ждёт бесконечное количество несостыковок и бессмысленных итераций.
Подход 5. Концепция О_о Дизайн-система: пум пум
ДС не нужна в рамках концепции, можем расходиться. Максимум, что тут можно сделать — локальные компоненты, которые ускорят работу в будущем.
Дизайн-система — штука более трудозатратная, чем UI-kit. Поэтому нужно хорошо подумать, какую из двух баз выбрать. Может, получится обойтись только UI-kit’ом.
Дизайн-система — всегда вложение. Эдакая инвестиция в будущее, которая выстроит единую структуру в процессах и наладит диалог между разработчиками и дизайнерами.
И она необходима на продуктах, где нужна экосистема. UI-kit же подойдёт для несложных проектов. Ну или для сложных, но где не требуется постоянное расширение.
Больше полезного — в нашем тг-канале.
