Как дизайн-система помогает разработчикам быстрее создавать продукт, а клиентам — погружаться в него. На примере CoMagic

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

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

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

• Figmа. В ней собраны все компоненты для дизайнера:

— Magic UI: Base — основные стили: цвета, шрифты, тени и иконки,

— Magic UI: Web — компоненты для веб приложения,

— Magic UI: Patterns — типовые решения одинаковых или похожих задач пользователя,

— Magic UI: Verbal guide — набор правил для текстов в интерфейсах.

Дочерние системы:

— Magic UI: PMO — компоненты чатов,

— Magic UI: Mobile — стили и компоненты для мобильного приложения

• Storybook. Это набор готовых компонентов. Дизайнер делает макет в Figma, разработчик — верстку, а затем собирает эти же компонеты в «Сторибуке». В дальнейшем любой элемент элемент интерфейса он может забрать отсюда в виде кода (Input) и вставить в прототип.

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

Главы документа соответствуют названиям компонентов в Figma.

— В Magic UI: Base мы описываем правила типографики и использование шрифтов,

— в Magic UI: Web — набор компонентов, кнопки, селекторы и списки для правильного отображения на странице,

— в Magic UI: Patterns — типовые решения, чтобы команды не придумывали каждый раз новые,

— в Magic UI: Verbal Guide — набор правил для текстов в интерфейсе. Например, чтобы в кнопках было единообразие в названиях. Допустим, используется только слово «копировать», а «скопировать» уже не допускается. И так во всех интерфейсах. Свой ряд правил относится и к написанию чисел, телефонных номеров, знаков валют и пр.

Ломоносов писал про математику, что это наука, которая «ум в порядок приводит». Так же и с дизайном. Основная его цель — не «сделать красиво», а разобраться с хаосом. А если порядок наведен, то и работать проще и быстрее.

Компания Sparkbox (занимается веб-дизайном) провела эксперимент: «кодинг с нуля против кодинга с дизайн-системой». В первом случае разработчики должны были создать web-страницу, ориентируясь только на макет в «Фигме», а во втором — используя компоненты дизайн-системы.

Использование дизайн-системы позволило на 47% ускорить разработку простой страницы по сравнению с ее написанием с нуля. Вместо 4 часов и 20 минут время работы сократилось до 2 часов. Причем сюда включено и время, которое разработчики потратили на ознакомление с системой дизайна.

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

Например, раньше программистам приходилось выгружать новые иконки из проекта в «Фигме». Это занимало время. Использование «Сторибука» как склада готовых веб-компонентов решает эту проблему. Разработчик просто забирает код иконки и вставляет в интерфейс.

В идеальном мире, к которому мы идем, такой подход ускорит еще и тестирование новых прототипов интерфейсов на клиентах.

Допустим, дизайнер поставил гипотезу, что «этот интерфейс будет лучше без с полей и с этой кнопкой». Чтобы проверить гипотезу и получить фидбек от определенной выборки клиентов, дизайнеру достаточно будет самому поменять несколько элементов в прототипе, используя «Сторибук», вообще не занимая время разработки.

Нужная группа клиентов увидит обновленный интерфейс в специальной «песочнице» сразу на вебе, а не на картинке в «Фигме». Там можно нажимать кнопки, строить отчеты и применять прочий интерактив. Соответственно, такой эксперимент оказывается чище, потому что дизайнер может отследить, как стали вести себя пользователи после обновления интерфейса в настоящем личном кабинете.

Тестирование новых фичей на вебе — также огромный плюс для разработчиков. Это значительно ускоряет работу, поскольку все компоненты «Сторибука» утверждены и не не тратится время на их переповерку или создание.

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

Чтобы разобраться во всех нюансах старого личного кабинета пользователю приходилось сидеть с «энциклопедией в руках» и держать в голове массу информации.

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

Дизайн-систему необязательно создавать с нуля. Особенно, если у вас нет под это выделенной команды. На рынке существует множество готовых решений. Найти подходящее легко, например, на ant.design.

Однако у такого решения есть свой недостаток. Готовые дизайн-системы постоянно обновляются, выходят следующие версии. Если у вас несколько продуктов и несколько команд, обязательно произойдет путаница: кто-то добавит элемент из новой версии, а кто-то из предыдущей. Это некритично, но разлад вносит — мы ведь хотим единообразия, так ведь? Чисто технически тяжело знать все элементы системы и контролировать их использование, когда у тебя довольно масштабный продукт.

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

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

Хотите попробовать новый личный кабинет CoMagic? Обратитесь к личному менеджеру или по контактам на сайте.