Зачем мы разработали дизайн-систему?

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

Дизайн-система — комплекс элементов, который включает в себя гайдлайны и наборы компонентов для проектирования дизайна интерфейсов

Приступая к работе над новым проектом, первое, что разрабатывается, и первое, что выкатывается в сторы — MVP-версия приложения. Сделать это нужно так быстро, насколько это возможно.

Вот тут как раз-таки начинается замкнутый круг:

Во время проектирования интерфейса для приложения «Заступник», мы на практике пришли к тому, что необходимо оптимизировать эту работу за счет разработки дизайн-системы, так как приложение вышло из стадии MVP и выросла в продуктовую историю, поддержка макета которой стала достаточно сложной в одной фигма-файле.

MVP-версия приложения и конечный продукт, тем более когда он остается на дальнейшей поддержке, могут сильно отличаться, так как в процессе работы подвергается и продолжает подвергаться миллиону корректировок и правок.

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

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

• Dev — для создания макета дизайнерами;
• PreProd — для создании версии макета на следующий релиз, он же основной макет для разработчиков;
• Prod — актуальная версия макета, которая на данный момент лежит в Сторах. Этот файл используют тестировщики, чтобы искать баги.

Такое разделение упрощает задачу тем, что поддержка этих файлов происходит не в трех разных файлах, а в одном — в файле дизайн-системы

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

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

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

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

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

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

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

• Ускорение разработки MVP-версий приложений;
• Наиболее структурированная работа над проектом, что повышает удобство работы всей команде разработки: дизайнерам, разработчикам, тестировщикам и аналитикам;
• Автоматизация внесения изменений во все дизайн-файлы;
• При переходе в продуктовую историю, дизайн-система является хорошей базой, которую удобно масштабировать;
• Сведение к минимуму дублирования сущностей;

В случае передачи макета другому дизайнеру, ему проще погрузиться в проект.