Рано или поздно каждая студия разработки, которая занимается, в том числе и UI/UX, приходит к созданию дизайн-системы. Теоретического материала на эту тему много, поэтому рассказываем как мы пришли к тому, чтобы разработать собственную дизайн-систему для своих проектов, и как дизайн-система сможет помочь в работе.
Дизайн-система — комплекс элементов, который включает в себя гайдлайны и наборы компонентов, использующиеся в проектировании дизайна интерфейсов.
Когда мы берем в работу новый проект, то первое, над чем работаем, и первое, что выкатываем в сторы — MVP-версия приложения, и сделать это нужно быстро, в максимально сжатые сроки.
Вот тут как раз-таки начинается замкнутый круг:
Во время проектирования интерфейса для приложения «Заступник», мы на практике пришли к тому, что необходимо оптимизировать эту работу за счет разработки дизайн-системы, так как приложение вышло из стадии MVP и выросла в продуктовую историю, поддержка макета которой стала достаточно сложной в одной фигма-файле.
MVP-версия приложения и конечный продукт, тем более когда он остается на дальнейшей поддержке, могут сильно отличаться, так как в процессе работы подвергается и продолжает подвергаться миллиону корректировок и правок.
В таких условиях мы приходим к тому, что обычного UI-кита не хватает, по той причине, что он становится неактуальным — хранит в себе компоненты, которые уже не используются, следовательно, фигма-файл превращается в хаос, что ухудшает работу как дизайнеров, так и разработчиков.
Чтобы оптимизировать работу с макетами, было создано три файла для разных задач, а для их поддержки реализовали дизайн-систему.
Dev — для создания макета дизайнерами;
PreProd — для создании версии макета на следующий релиз, он же основной макет для разработчиков;
Prod — актуальная версия макета, которая на данный момент лежит в Сторах. Этот файл используют тестировщики, чтобы искать баги.
Такое разделение упрощает задачу тем, что поддержка этих файлов происходит не в трех разных файлах, а в одном — в файле дизайн-системы.
Как дизайн-система упростит работу над конкретным приложением.
В случае если эти три файла не будут соединены дизайн-системой, то вносимое изменение в один элемент придется вручную вносить отдельно в каждый из них.
При такой системе можно в какой-то элемент не внести изменение, что приведет к казусу в интерфейсе — вот на этой странице кнопка «Отправить» меняется из зеленой в серую, а на другой наоборот.
Дизайн-система решает эту проблему — она объединяет и структурирует библиотеку компонентов. Внеся изменение в компонент в дизайн-системе, он меняется и в остальных макетах.
Как дизайн-система упростит работу над любыми будущими проектами.
При работе над приложениями, дизайнеры разрабатывают с чистого фрейма каждый компонент, а разработчики пишут под них код.
Все приложения имеют похожую структуру и, примерно, одинаковый набор базовых компонентов, получается, что из проекта в проект проделывать одну и ту же работу — как-то бессмысленно…
Намного проще собрать в одно место все основные компоненты вместе с прописанным для них кодом. А при разработке MVP-версии нового проекта, брать готовые компоненты адаптируя их под фирменный стиль и требования заказчика.
Как результат, внедряя дизайн-систему в свою работу мы получаем следующее:
Ускорение разработки MVP-версий приложений;
Наиболее структурированная работа над проектом, что повышает удобство работы всей команде разработки: дизайнерам, разработчикам, тестировщикам и аналитикам;
Автоматизация внесения изменений во все дизайн-файлы;
При переходе в продуктовую историю, дизайн-система является хорошей базой, которую удобно масштабировать;
Сведение к минимуму дублирования сущностей;
В случае передачи макета другому дизайнеру, ему проще погрузиться в проект.
