кейс
Дизайн-система для 15+ цифровых продуктов
Проблема
Основная проблема была в том, что каждый продукт компании выглядел по-разному
В компании не существовало единого подхода к проектированию интерфейсов, как и единого визуального языка. Единственным объединяющим звеном был брендбук.
При этом компания имела уже >15 продуктов (сайты, приложения, AI-интерфейсы).
Я поняла, что логичным шагом будет предложить разработку дизайн-системы, после чего собрала аргументы для руководителя, почему это полезно и как это ускорит процессы дизайна и разработки. Идея была принята, после чего наступил самый сложный этап - реализации идеи.
При этом компания имела уже >15 продуктов (сайты, приложения, AI-интерфейсы).
Я поняла, что логичным шагом будет предложить разработку дизайн-системы, после чего собрала аргументы для руководителя, почему это полезно и как это ускорит процессы дизайна и разработки. Идея была принята, после чего наступил самый сложный этап - реализации идеи.
Исследование
Прежде чем разрабатывать дизайн-систему, нужно было понять контекст
Ресерч внутренних продуктов
На этапе исследования я составила таблицу всех цифровых продуктов компании: платформа, аудитория (сотрудники или клиенты), технологический стек, статус, необходимость редизайна.
Анализ опыта других компаний
Изучила дизайн-системы НЛМК, Северстали и Росатома, как они документируют компоненты, какую структуру используют и что публикуют в открытый доступ.
Опрос разработчиков
Провела опрос команды разработчиков по технологическому стеку, чтобы понять, как в дальнейшем будет происходить разработка компонентов.
UI-аудит
Провела UI-аудит повторяющихся компонентов и паттернов в уже существующих интерфейсах, что позволило понять, какие элементы точно необходимо учесть в дизайн-системе на первом уровне.
процесс
Система модернизировалась по мере внедрения в новые продукты
Определение основных принципов дизайн-системы
Прежде чем делать компоненты нужно было прописать базовые принципы. В связи с чем прописаны цели, принципы, какие проблемы решает дизайн-система, что будет если ее не использовать и основные ограничения.
Первый этап проектирования - foundation
Логика проектирования строилась на принципах атомарного дизайна. В связи с чем сначала прорабатывалась база (или на языке дизайна - создавались переменные/variables): палитра, типографика, система отступов, радиусов и сеток. Для всего были собраны overview-страницы. Также был создан набор иконок в единой стилистике с идентичными свойствами.
Создание единого набора компонентов (состояния, вариации, правила использования)
На данный момент создан базовый набор компонентов и описаны их правила использования в документации (Button, Input, Checkbox / Radio / Switch / Toggle, Select / Dropdown, Textarea). Каждый компонент спроектирован с точки зрения удобства переиспользования, все значения заданы с помощью токенов + сделаны удобные свойства для включения/выключения составных частей компонента.
Особенности
Для построения палитры мной была выбрана цветовая модель OKLCH, так как в отличие от HSL она воспринимается глазом равномерно, что позволяет успешно балансировать оттенки. Для каждого токена проверяла контрастность через плагин для соблюдения стандарта WCAG.
Цвета выстроены иерархически: базовая палитра, далее семантические токены (color.bg-primary, color.text-secondary, color.status-error), потом компонентные цвета. Меняется только верхний уровень, всё остальное подтягивается автоматически. Таким способом можно пользоваться разными палитрами и удобно переключать темы (light/dark).
итог
Процесс дизайна ускорился в несколько раз, снизилось количество ошибок в макетах, новые продукты стали выглядеть консистентно (будто они находятся в одной экосистеме!)
На текущий момент система внедрена в 2 новых продукта и проходит этап тестирования и доработки.
