Назад
Мы можем делать больше с небольшим ресурсом. Продуктовые команды выделяют свой ресурс на контрибьют: правка багов, создание новых компонентов, различные доработки.
Команды активно участвуют в обсуждениях новых компонентов, предлагают новые идеи.
Была задача от бизнеса: нужно уметь менять цветовую тему в интерфейсе платформы. Нам пришлось переосмыслить подход к использованию цвета и семантике.
Мы разработали план по переезду на новые токены в дизайне и разработке. Сложнее всего было продуктовым командам. Общими силами и с нашей поддержкой мы смогли перевезти на новые токены более 50 команд за 4 месяца.
Описали жизненный цикл компонента, гайды по сборке локальных компонентов, миграции на новые токены и тд.
Мы внедрили важный процесс, который помогает нам контролировать макеты перед передачей в разработку и влиять на сверстанные экраны перед релизами.
Теперь это направление выделилось из ДС в отдельную команду, так как эта работа требует много времени и ресурсов, но она очень важна для руководства.
Мы можем делать больше с небольшим ресурсом. Продуктовые команды выделяют свой ресурс на контрибьют: правка багов, создание новых компонентов, различные доработки.
Команды активно участвуют в обсуждениях новых компонентов, предлагают новые идеи.
Была задача от бизнеса: нужно уметь менять цветовую тему в интерфейсе платформы. Нам пришлось переосмыслить подход к использованию цвета и семантике.
Мы разработали план по переезду на новые токены в дизайне и разработке. Сложнее всего было продуктовым командам. Общими силами и с нашей поддержкой мы смогли перевезти на новые токены более 50 команд за 4 месяца.
Описали жизненный цикл компонента, гайды по сборке локальных компонентов, миграции на новые токены и тд.
Мы внедрили важный процесс, который помогает нам контролировать макеты перед передачей в разработку и влиять на сверстанные экраны перед релизами.
Теперь это направление выделилось из ДС в отдельную команду, так как эта работа требует много времени и ресурсов, но она очень важна для руководства.
Был проведен анализ текущей библиотеки компонентов дизайн-системы, мы искали неиспользуемые или схожие компоненты. Далее была разработана стратегия по замене кастомных компонентов у продуктовых команд компонентами из дизайн-системы, с целью сокращения кастома и повышения метрики Adoption.
Мы доработали процесс разработки и обновления компонентов: добавили этапы исследования, оценки, тестирования, ревью и демо функционала для команд. Для увеличения эффективности и минимизации ошибок были внедрены инструменты автоматизации для сборки и деплоя компонентов.
Было проведено глубинное исследование лучших практик и современных тенденций в области дизайн-систем, а также учтены потребности текущих и будущих проектов. Была разработана долгосрочная стратегия развития, основанная на потребностях продуктовых команд, бизнес целях и с прицелом на устойчивую эволюцию дизайн-системы.
Запущена серия обучающих мероприятий для всех желающих, направленная на ознакомление с принципами построения дизайн-системы и практиками работы с ней. Для этого были подготовлены обучающие материалы и практические сессии с целью усиления понимания всей командой значимости и преимуществ использования дизайн-системы. Также были проведены митапы с планами на дизайн-системы и с демонстрацией открытого бэклога команды.
Мы собрали список недостающих компонентов и провели аудит текущего набора в библиотеке. Нам нужно было понять, что должно попасть в общую библиотеку, а что будет жить локально в командах. После проведенного анализа мы запланировали работу по отсутствующим компонентам и добавили их в общий бэклог.
Был проведен гэп-анализ компонентов в дизайне и коде. Мы разметили все компоненты, которые отсутствовали либо в разработке, либо в макетах и также запланировали по ним работы. Был описан и внедрён процесс обновления дизайн-библиотеки и сторибука. Таким образом мы смогли пофиксить проблему с использованием компонентов дизайнерами раньше, чем они появляются в разработке. Также был разработан процесс регулярной проверки и обновления компонентов, чтобы устранить любые расхождения (DS Check up).
Мы можем делать больше с небольшим ресурсом. Продуктовые команды выделяют свой ресурс на контрибьют: правка багов, создание новых компонентов, различные доработки.
Команды активно участвуют в обсуждениях новых компонентов, предлагают новые идеи.
Была задача от бизнеса: нужно уметь менять цветовую тему в интерфейсе платформы. Нам пришлось переосмыслить подход к использованию цвета и семантике.
Мы разработали план по переезду на новые токены в дизайне и разработке. Сложнее всего было продуктовым командам. Общими силами и с нашей поддержкой мы смогли перевезти на новые токены более 50 команд за 4 месяца.
Описали жизненный цикл компонента, гайды по сборке локальных компонентов, миграции на новые токены и тд.
Мы внедрили важный процесс, который помогает нам контролировать макеты перед передачей в разработку и влиять на сверстанные экраны перед релизами.
Теперь это направление выделилось из ДС в отдельную команду, так как эта работа требует много времени и ресурсов, но она очень важна для руководства.
Повышение CSI дизайн-системы было достигнуто путем внедрения регулярных митапов, анализа обратной связи от пользователей и оптимизации процессов.
Мы смогли увеличить уровень принятия дизайн-системы благодаря обучению пользователей, улучшенной документации и активной поддержке от нашей команды.
Уменьшили использование кастомных компонентов в продуктах с помощью обновления библиотек, внедрения Quality Gate и более быстрой реакции на запросы.
Дизайн-система (ДС) Pulse UI, на которой построена платформа Пульс, охватывает более 65 сервисов. Она способна покрывать запросы, начиная с лендингов и заканчивая высоконагруженными интерфейсами, такими как таблицы, дашборды и командные календари.
Одной из ключевых особенностей ДС Pulse UI является её гибкость в настройке тем. Благодаря продуманным дизайн-токенам и семантическим связям можно изменять палитру, типографику, скругления и другие визуальные параметры. Это нужно для адаптации интерфейсов под различные бренды и пользовательские предпочтения, что особенно важно для поддержания актуальности и привлекательности платформы в условиях быстро меняющихся требований рынка.
Мы начали с анализа текущей библиотеки компонентов дизайн-системы, нам нужно было найти неиспользуемые или схожие компоненты. Далее была разработана стратегия по замене кастомных компонентов у продуктовых команд компонентами из дизайн-системы, с целью сокращения % кастома и повышения метрики Adoption.
Необходимо было пересмотреть процесс разработки и обновления компонентов. Мы добавили этапы исследования, оценки, тестирования, ревью и демо функционала для команд. Для увеличения эффективности и минимизации ошибок были внедрены инструменты автоматизации для сборки и деплоя компонентов.
Было проведено глубинное исследование лучших практик и современных тенденций в области дизайн-систем, а также учтены потребности текущих и будущих проектов. Была разработана долгосрочная стратегия развития, основанная на потребностях продуктовых команд, бизнес целях и с прицелом на устойчивую эволюцию дизайн-системы.
Большим прорывом для нас послужил процесс контрибьюта – продуктовые команды смогли сами предлагать и разрабатывать новые компоненты, вносить правки и исправлять ошибки в текущей библиотеке.
После нескольких итераций и релизов мы достигли стабильной базовой версии, теперь мы можем собирать данные, эффективно оптимизировать процесс и внедрять ключевые функции. Мы разработали и внедрили процесс контрибьюта от продуктовых команд, что позволило использовать внутренние ресурсы продуктовых команд. Команды теперь активно участвуют в обсуждениях новых компонентов и предлагают идеи, что улучшило их отношение к дизайн-системе.
Мы обновили и внедрили новые токены цвета, переведя более 50 команд за 4 месяца. Создали множество полезной документации, включая гайды по жизненному циклу компонентов и миграции на новые токены. Внедрили процесс контроля качества Design Gate, который помогает проверять макеты и сверстанные экраны перед релизами, выделив это направление в отдельную команду.
Для оценки работы дизайн-системы мы используем две ключевые метрики: CSI (Component Satisfaction Index) и Adoption. CSI позволяет измерять удовлетворенность команд компонентами, а Adoption показывает, насколько активно команды используют компоненты дизайн-системы. Эти метрики помогают нам отслеживать эффективность и вносить необходимые улучшения.
Повышение CSI дизайн-системы было достигнуто путем внедрения регулярных митапов, анализа обратной связи от пользователей и оптимизации процессов.
Мы смогли увеличить уровень принятия дизайн-системы благодаря обучению пользователей, улучшенной документации и активной поддержке от нашей команды.
