dr.Brain

doctor Brain

мир глазами веб-разработчика

Создаем Дизайн-систему

Практическое руководство по созданию Дизайн-системы

dr.Brain

время чтения 2 мин.

Photo by Filios Sazeides on Unsplash

В этом небольшом обзоре мы опишем основные этапы создания Дизайн-системы для собственного программного продукта.

Выбор фреймворка для разработки пользовательского интерфейса

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

Определение своей темы оформления

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

Создание пакета для Дизайн-системы

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

Storybook

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

Избегайте кастомного CSS и компонентов в коде продукта

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

Регрессионное тестирование

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

В заключение

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


Cпасибо за внимание.


Перевод статьи “Practical Guide to Creating a Design System”.

Новые публикации

Далее

Категории

О нас

Frontend & Backend. Статьи, обзоры, заметки, код, уроки.