Дизайн-система

Как я собрала ui-kit aka MVP Дизайн-системы, которая ускорила сборку фичей на 1–2 спринта и стала общей инфраструктурой для дизайна и разработки.

Проблемы

  1. 1

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

  2. 2

    Система не была готова к масштабированию, а ответственность за обновления была размытой

Интерфейсы собирались вручную

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

Скриншот внедрения Дизайн-системы в макеты

На что это влияло

  1. 1

    Дизайнеры тратили время на поиск актуальных макетов и решений

  2. 2

    Одинаковые элементы могли выглядеть и работать по-разному в разных частях продукта

  3. 3

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

Ждать «идеального момента» для Дизайн-системы было нельзя
Без неё хаос только масштабировался бы вместе с редизайном

Что я сделала

  1. 1

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

  2. 2

    За несколько дней собрала 23 ключевых компонента: кнопки, поля, списки и другие базовые элементы. За основу брала намечающийся редизайн

  3. 3

    Синхронизировала Дизайн-систему с разработкой: параллельно с редизайном разработчики собирали Storybook на базе наших компонентов

Скриншот MVP Дизайн-системы

Бизнес-ценность

На 1–2 спринта

Меньше стали тратить на разработку средней фичи

~500 тыс. ₽

Экономим в месяц за счёт меньшего числа ручных проверок, правок и повторной сборки типовых элементов

Система не была готова к масштабированию

Когда ui-kit начал распространяться за пределы моей команды, появились новые риски. Ей пользовались дизайнеры из разных продуктовых направлений, а разработка собирала Storybook по тем же компонентам.

На что это влияло

  1. 1

    Любой апдейт мог случайно сломать чужие макеты

  2. 2

    Компонентов становилось больше, и ориентироваться в файле становилось сложнее

  3. 3

    UI-kit начал использоваться разными командами, поэтому правила должны были быть понятны не только автору системы

Что я сделала

  1. 1

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

  2. 2

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

  3. 3

    Подготовила гайды и документацию по использованию компонентов и блоков

Бизнес-ценность

-30%

Обращений к лиду по поиску актуального макета и правилам использования компонентов

4–6 часов в неделю

Экономии времени дизайна на черновых макетах для проверки гипотез от продактов и аналитиков

Меньше доработок

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