Skillaz — дизайн-система как «интеграционный слой» для единого интерфейса (B2B / HRTech)

в условиях жёстких сроков и интеграции продуктов дизайн-система становится быстрым способом создать «бесшовный» опыт и общий язык для дизайнеров и разработки.

Главное

в условиях жёстких сроков и интеграции продуктов дизайн-система становится быстрым способом создать «бесшовный» опыт и общий язык для дизайнеров и разработки.

Фокус: дизайн-система как средство унификации UX между продуктами после интеграции; адаптация базовой системы (Magritte) под свой контекст; токены и документация в Figma; XP-часть (UX-паттерны) как слой “правил”, снимающий неопределённость; процесс обновлений через гейткипера.

Контекст

1. Контекст: почему дизайн-система появилась

Дизайн-система в Skillaz была инициирована как бизнес-требование: после интеграции нужно было объединить несколько продуктов в единый интерфейс, чтобы пользователь не сталкивался с разным UX при переключении между разделами. Задача формулируется как создание «бесшовного перехода» и единого визуального языка для всей линейки.

Позиционирование и цели

в условиях жёстких сроков и интеграции продуктов дизайн-система становится быстрым способом создать «бесшовный» опыт и общий язык для дизайнеров и разработки.

Состав системы

2. Старт под сроки: база Magritte + адаптация под B2B/desktop

Из-за ограниченного времени команда выбрала стратегию: взять существующую дизайн-систему и быстро адаптировать под свои потребности. В качестве базы использована дизайн-система HeadHunter (Magritte): изменили фундамент (типографика, цвета, тени), скорректировали компонентный состав (что-то убрали, что-то добавили) и начали оформлять документацию по компонентам и UX-паттернам. Отдельно подчёркивается, что система заметно разошлась с исходной: различаются контекст и приоритеты (у Skillaz — B2B и desktop-first).

4. Устройство системы: файлы, группы компонентов и X-patterns

Система устроена как набор файлов с разделением по назначению. В основном файле хранится база (типографика, сетка, прочие foundations) и сами компоненты. Документация вынесена в отдельные файлы по логическим группам компонентов (например, Data-display), где размещаются спецификации и правила. Отдельным слоем выделен файл X-patterns — паттерны взаимодействия пользователя (например, фильтры, типы поиска), которые позволяют командам ссылаться на единые правила вместо пересказов в каждой задаче.

5. Токены: палитра → семантика → компонентный слой

Токенная модель описана через уровни. Базовый слой — палитра оттенков (условные 100/200/…), поверх него формируется семантический слой (фон/текст/иконки и т.д.), а компонентный слой не дублируется в виде отдельного набора переменных в дизайне — его фиксируют в документации компонента, чтобы не раздувать библиотеки.

Процессы развития

7. Процесс изменений и роль гейткипера

На момент интервью система находится на стадии завершения MVP: формируется перечень компонентов и документации, перечень пополняется по мере появления новых кейсов. Процесс обновлений опирается на одного ответственного (гейткипера): срочные доработки продуктовые дизайнеры могут делать локально и согласовывать, после чего решения переносятся в дизайн-систему и документируются. Несрочные запросы отправляются в бэклог и берутся в работу по мере приоритетов. О завершённых обновлениях команда сообщает в общем чате дизайн-системы.

Документация

6. Документация: Figma как источник и Storybook со стороны разработки

Документация ведётся внутри Figma и закрыта для внешних пользователей. Со стороны разработки поддерживается Storybook по компонентам на основе описаний из дизайн-документации. Такой формат обеспечивает единый источник правил и снижает расхождения между дизайном и реализацией.

10. Ошибки и ограничения: вес библиотек и оптимизация документации

Главная ошибка на старте — недооценка веса: компоненты и документация могут становиться тяжёлыми и «раздувать» файлы. В ответ команда выносит в библиотеку только часто используемые вариации, а редкие состояния и сценарии оставляет в документации. Также документация делится на логические группы файлов, чтобы ускорять загрузку и работу в инструментах.

Контроль качества

8. Взаимодействие с разработкой: минимум бюрократии, но обязательное ревью

Коммуникация с разработкой построена прагматично: определяется приоритет реализации компонентов, по вопросам команда переписывается или созванивается, после реализации разработчики внедряют компонент в продукт, а затем дизайнер дизайн-системы проводит ревью реализации (соответствует/не соответствует) и возвращает на доработку при необходимости.

Масштабирование и внедрение

3. Цели: единый язык, скорость, масштабирование

Цели описываются как комплексные, но с приоритетами. На первом месте — единый дизайн и единый визуальный язык. Далее — ускорение производства (скорость сборки макетов для дизайнеров и скорость разработки) и, как отдельный приоритет, масштабирование сразу на несколько продуктов.

Уникальные практики и «фишки» кейса

1. База Magritte + быстрая адаптация под B2B/desktopВместо построения с нуля под жёсткий срок интеграции взяли готовую DS Magritte (от HeadHunter) и адаптировали её под свой контекст: B2B, desktop-first, HR-специфика. Сэкономили месяцы работы и получили предсказуемое поведение компонентов.

2. X-patterns — правила взаимодействия, а не только компонентыОтдельный слой документации фиксирует паттерны: как работают фильтры, типы поиска, повторяющиеся сценарии. В задачах можно просто ссылаться на один документ вместо того, чтобы заново описывать поведение. Правки вносятся в одном месте.

3. Библиотека картинок как «токены визуала»Аватарки, обложки и часто используемые изображения собраны в переиспользуемую библиотеку. Дизайнеры не подбирают визуалы вручную каждый раз — списки и экраны собираются быстрее.

4. Универсальная ячейка CellКомпонент Cell унаследован от Magritte и расширен под свои сценарии: аватар + ФИО + должность + элементы выпадающих списков и т.п. Частые варианты представления контента заложены внутрь и переиспользуются в разных местах.

5. Гейткипер в процессе измененийИзменения в DS проходят через одного ответственного — он удерживает цельность системы и снимает неопределённость «кто это решает». Минимум бюрократии, но обязательное ревью перед вливанием.

6. Группировка файлов по загрузкеДокументация и компоненты разнесены по логическим группам файлов — библиотеки не становятся «тяжёлыми». В основную библиотеку выносятся только частые вариации, редкие состояния остаются в документации.

Выводы и принципы

11. Итоговый инсайт: дизайн-система — отдельный продукт

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

12. Что можно перенять другим командам

Избранные цитаты