Дизайн-система для Ekit

Ekit — комплексная платформа для управления мероприятиями: от создания организаций и персон, участвующих в событии, до системы контроля и управления доступом.

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

Во время онбординга и работы над первым флоу я столкнулась со сложностями: было непонятно, где искать компоненты, как выстроены схожие пользовательские сценарии.

От коллеги-дизайнера я узнала, что Ekit создавался в сжатые сроки, а стейкхолдеры не выделяли ресурсов на создание дизайн-системы. Как перфекционист, я не могла оставить всё как есть и предложила создать полноценную дизайн-систему и унифицировать макеты.

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

Так я и получила задачу по созданию дизайн-системы :)

Аргументы в пользу создания дизайн-системы:

На данный момент команда не ориентируется в макетах, разработчики не понимают принципы работы ключевых элементов интерфейса

На стейдже одинаковые элементы и страницы работают по-разному (об этом говорили тестировщик и продакт)

Руководство обозначало проблему несогласованности текстов и наименований

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

Отсутствие унифицированных компонентов замедляет разработку и усложняет поддержку продукта

Создание дизайн-системы значительно сократит время на создание новых флоу

Исследование

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

Начала с того, что провела бенчмаркинг нескольких дизайн-систем, включая Контур.Гайды, ДС Ростелекома, Taiga UI, ДС Госуслуг и др. Анализировала их структуру, подходы к документированию и созданию компонентов.

В результате я выделила несколько фишек, которые решила интегрировать в будущую дизайн-систему:

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

Подробное описание кейсов применения, показывающее, в каких сценариях использовать тот или иной компонент.

Разъяснение логики работы компонентов: их поведения в разных состояниях, зависимостей и ограничений.

Стандартизация паддингов и размеров для соблюдения визуального единства и удобства разработки.

Процесс работы

Создание молекул

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

Добавила систему отступов и скруглений, используя Variables.

Далее пересобрала существующие компоненты, привела их к единому стилю, описала принципы их работы. Разработчики сказали, что они используют библиотеку PrimeVue, поэтому почти к каждому элементу для их удобства я добавила ссылки на соответствующие элементы в библиотеке.

Унификация макетов

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

А ещё в фигма вышло обновление, и я заменила все заметки для разработчиков в фреймах на Annotations, а линии, указывающие на расстояния, на Measurements. Стало ещё роскошнее, восторг!

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

Создание редполитики

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

Создание организмов и шаблонов

Отдельно создала и описала принципы работы организмов и стандартных страниц.

Создание атомов

Собрала и стандартизировала стили типографики (изначально их было более 30), разделила их на две группы: Title (8 стилей) и Text (3 стиля).

Проанализировала существующие макеты. Выявила дублирующиеся компоненты, противоречия в UI&UX. Пообщалась с разработчиками, тестировщиком и продактами для выявления слабых мест продукта, которые важно исправить. Составила список и изучила best practises на соответствующие темы.

Результаты и выводы

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

Уроки и рефлексия

Помимо этого приятного результата, хочу еще выделить следующие:

Ekit обрёл консистентность, исчезли противоречия в интерфейсе и нарушения в логике его работы

Почти в два раза сократилось время, затрачиваемое дизайнерами, на создание макетов

Самостоятельно с нуля собрала целую дизайн-систему

У разработчиков исчезли вопросы о работе тех или иных компонентов и флоу, так как я провела знакомство с дизайн-системой (а еще они были очень признательны за то, что ко всем элементам привязаны ссылки на PrimeVue)

Уменьшилось количество экранов, так как больше не было необходимости отрисовывать и подписывать каждый раз интерактивность того или иного элемента

Теперь во время согласования макетов и тестирования всё внимание уделялось UX флоу, а не внешнему виду

К сожалению, руководству не удалось заключить достаточное количество сделок на использование Ekit, поэтому инвестор перевел его в статус заморозки (команда была расформирована).

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

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

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

Если ты на 99% уверен в своей идее, имеешь достаточно объективных аргументов, — иди до конца, донеси её актуальность до всех и реализуй.

Дружить с разработчиками — они расскажут всё, как есть на самом деле. Как реализуются макеты на фронте, что стоит учитывать, какие вопросы необходимо закрыть.

Важно провести общий колл с командой, на котором дизайнер расскажет о дизайн-системе и о том, как ей оперировать.