Проблема
Каждый продукт компании выглядел по-своему, не было никаких правил построения интерфейсов. Единого визуального языка не существовало.
У компании на тот момент было больше 25 цифровых продуктов: сайты, веб-приложения, мобильные приложения, AI-интерфейсы. Каждый делался отдельно, без общей базы. Разработчики верстали «как умели», опираясь на собственный вкус и привычные библиотеки. Дизайнер также выполнял работу по ТЗ и не придерживался единого визуального языка. В результате все продукты отличались: разные отступы, разные кнопки, разные состояния ошибок. Продукты одной компании выглядели как продукты разных команд.
Я предложила начать разработку дизайн-системы, обосновала необходимость руководству и получила добро на ее разработку.
У компании на тот момент было больше 25 цифровых продуктов: сайты, веб-приложения, мобильные приложения, AI-интерфейсы. Каждый делался отдельно, без общей базы. Разработчики верстали «как умели», опираясь на собственный вкус и привычные библиотеки. Дизайнер также выполнял работу по ТЗ и не придерживался единого визуального языка. В результате все продукты отличались: разные отступы, разные кнопки, разные состояния ошибок. Продукты одной компании выглядели как продукты разных команд.
Я предложила начать разработку дизайн-системы, обосновала необходимость руководству и получила добро на ее разработку.
Исследование
Прежде чем разрабатывать дизайн-систему, нужно было понять контекст. Я начала с трёх направлений параллельно:
Аудит продуктов. Составила таблицу всех цифровых продуктов компании: платформа, аудитория (сотрудники или клиенты), технологический стек, статус, необходимость редизайна. Это позволило понять масштаб и расставить приоритеты.
Анализ отрасли. Изучила дизайн-системы НЛМК, Северстали и Росатома, как они документируют компоненты, какую структуру используют и что публикуют в открытый доступ. .
Опрос разработчиков. Провела опрос команды из 6 человек по технологическому стеку. Выяснилось, что большинство работает на React 18 + Tailwind CSS + Material UI. Это напрямую повлияло на требования к системе, компоненты должны быть совместимы с этим стеком при дальнейшей передаче в разработку.
Процесс
Определение принципов и архитектуры
Прежде чем делать компоненты, сформулировала зачем система нужна, какие проблемы решает и что будет, если её не использовать. Были определены 4 слоя дизайн-системы: Foundation, Components, Patterns и States.
Цветовая система на OKLCH
Для построения палитры выбрала цветовую модель OKLCH, так как в отличие от HSL она воспринимается глазом равномерно, что позволяет успешно балансировать оттенки. Для каждого токена проверяла контрастность через плагин и для гарантии читаемости по стандарту WCAG.
Токены в три слоя
Цвета выстроены иерархически: базовая палитра, далее семантические токены (color.bg-primary, color.text-secondary, color.status-error), потом компонентные цвета. Меняется только верхний уровень, всё остальное подтягивается автоматически.
Типографика и foundation-слой
Зафиксировала корпоративный шрифт TT Hoves, создала текстовые стили для трёх платформ (desktop, tablet, mobile). Отдельно — компонентная типографика: Button text, Label, Helper text. Добавила единые системы отступов, сеток и радиусов через токены.
Компоненты с документацией
Каждый компонент имеет свой набор правил: назначение, структура, все состояния (default, hover, focus, error, disabled), правила использования и запреты. Button, Input, Textarea, Select, Checkbox, Radio, Switch - каждый задокументирован по единому шаблону.
Итерации и доработки
К токенам я возвращаюсь до сих пор, при применении дизайн-системы в новых проектах. Многие токены дорабатываются, апробируются компоненты, добавляются новые.
Итог
Система применяется только к новым продуктам и крупным редизайнам. В планах на 2026: доработка недостающих компонентов и паттернов, подключение разработчиков, создание Storybook-библиотеки под React и гайдбука в PDF для всей команды.
кейс
PMH Design System
