Как мы перезапустили дизайн-систему: ошибки и лучшие практики

Предпосылки к обновлению дизайн-системы

Первая предпосылка: опыт клиентов

В панели управления

Selectel — провайдер IT-инфраструктуры. У нас широкая продуктовая линейка, в основе которой выделенные серверы и собственная облачная платформа. Еще — сетевые услуги, администрирование, консалтинг, защита IT-инфраструктуры и другие сервисы для комплексного решения бизнес-задач.

Во всех продуктах есть одинаковые объекты и действия. Например, заказ и удаление услуги или страницы серверов и сетей. До дизайн-системы эти сущности выглядели по-разному в разных продуктах. Это приводило к неконсистентному опыту клиентов и создавало лишнюю нагрузку — пользователям приходилось обучаться работе с интерфейсом заново при переходе между продуктами. 

Например, клиент, который пользуется выделенными серверами и облачной платформой, был вынужден запоминать, где в каждом из продуктов расположена важная информация и управление сервером. Вот яркие примеры различий ↓

Какие здесь недостатки:

1. Разные форматы отображения серверов: в выделенных серверах используется карточный вид, а в облачной платформе — табличный.
2. По-разному отображаются статусы: в выделенных серверах есть переключатель, который показывает состояние сервера, а в облачной платформе статус выводится в виде текста.
3. Различная механика взаимодействия с сущностями: в выделенных серверах кликабельна вся область карточки, по нажатию открывается страница сервера. Чтобы попасть на страницу сервера в облачной платформе, нужно кликнуть на название сервера.

Какие здесь недостатки:

1. Функции переименования сервера расположены в разных местах.
2. Снова разное отображение статусов.
3. Разная механика копирования uuid.
4. Разный порядок разделов второго уровня.

На сайте и в панели управления

Кроме неконсистентности внутри панели управления (ПУ), была разница между ней и сайтом компании.

Дизайн панели управления морально устарел. Это особенно чувствовалось при переходе с площадки на площадку. А разнородность в решениях особенно сильно ощущалась при первом заказе клиента, когда он выбирал продукт или услугу на сайте, а затем переходил в панель управления для ее заказа и настройки.

Клиенты выделенных серверов, например, сталкивались с тем, что форма заказа кардинально отличалась по оформлению и функционалу фильтрации.

Первый этап заказа сервера – выбор конфигурации

Какие здесь недостатки: 

1. Различия в фильтрации списка серверов: набор параметров фильтрации, расположение фильтров на странице и их последовательность.
2. Различия в дефолтном способе сортировки.

Второй этап заказа сервера – выбор дополнительных услуг, операционной системы и тарифного плана

Какие здесь недостатки: 

1. Различия в расположении смысловых блоков: конфигурация, «входит в стоимость», стоимость заказа.

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

Вторая предпосылка: опыт коллег

Продуктовые дизайнеры

Продуктовые дизайнеры долгое время жили без единой библиотеки компонентов. Это нормально работало до того, как изменились обстоятельства.

Было: Selectel начал нанимать дизайнеров с 2015 года.

• Изначально дизайнер был один и работал со Sketch – поддерживать консистентность на уровне одного человека было просто. В следующие годы штат дизайнеров вырос еще на три человека, но консистентность компонентов поддерживалась благодаря системе ревью: все решения проходили проверку у всех коллег и, если были какие-то несоответствия, их сразу замечали.
• Поддерживать консистентность помогал и формат организации команд: был создан отдел пользовательского опыта, куда входили проектировщики интерфейсов, фронтенд-разработчики и тестировщики. Мы проводили регулярные синки, и все были в курсе изменений в соседних продуктах.
• На старте у нас была небольшая дизайн-система. Точнее — часть компонентов, которые были реализованы в коде. Описание этих компонентов и кейсы их использования отсутствовали.

Стало: с 2019 года проектировщиков стали нанимать более активно.

• UX-команда выросла до 16 человек.
• Часть проектировщиков стала переходить на Figma, и решения уже не проходили ревью всех коллег — это было бы неэффективной тратой времени.
• Отдел пользовательского опыта расформировали: специалистов разделили на продуктовые кросс-функциональные команды. Большинство было укомплектовано дизайнером, фронтенд- и бэкенд-разработчиком, тестировщиком и продакт-менеджером. Общения между дизайнерами стало в разы меньше.
• Мы все еще жили с подобием дизайн-системы.

Начали накапливаться разнородные решения одних и тех же задач. Постепенно сформировалось несколько UI-kit’ов для групп продуктов и личные kit’ы. В них дизайнеры создавали компоненты так, как им удобно, и работали только над тем набором, который лично они используют в работе.

У этого решения были свои плюсы — например, скорость работы. Если отправлять работу на ревью коллеге, который использует тот же kit, что и ты, то все будет консистентно с большой вероятностью.

Минусы тоже были, и в какой-то момент они стали перевешивать. Личные UI-kit’ы были далеки от идеала, многие состояния компонентов не были проработаны и наполнение этих kit’ов было не полным. В результате проектировщик прорабатывал только то, что ему казалось важным. 

Кроме того продукты развивались, в них появлялись новые интерфейсные решения, знания о которых не распространялись по UX-команде. В итоге проектировщики могли проектировать их заново, хотя в соседней команде уже было готовое решение.

Фронтенд-разработчики

Устаревший фреймворк

Мы использовали AngularJS 1.7.9, в то время как уже вышел Angular 13. Главная причина, по которой мы не могли остаться на AngularJS, — он устарел, и в 2021 году его поддержка прекратилась. Искать сторонние библиотеки, которые были бы актуальны и совместимы с AngularJS, становилось все сложнее. Как и искать людей на рынке, которые готовы работать со старым AngularJS.

Почему Angular 13? Потому что в него встроено много инструментов для упрощения ведения разработки. Также он дает больше свободы для повышения производительности приложения — это важная для нас характеристика. 

Межкомандные коммуникации

Проектировщики и разработчики использовали одинаковые термины для обозначения разных вещей – это приводило к ошибкам в реализации и неэффективной трате времени. Например, возникала путаница при наименовании состояний компонентов и определения понятия «компонент» в принципе. Поэтому при их реализации часто возникали запросы на доработку или консультацию со стороны фронтенд-разработчиков.

Третья предпосылка: опыт команд без UX-дизайнера

Команды, в которых не было дизайнера, были вынуждены самостоятельно проектировать решения. Без определенных компетенций сделать эту работу на высоком уровне невозможно, поэтому в прод попадали некачественные решения. Ими было сложно пользоваться, они не учитывали крайние состояния интерфейса. Это было еще одним пунктом в копилку общей неконсистентности, которая приводила к снижению лояльности клиентов.

У нас была возможность обновить фреймворк, договориться о терминологии, зафиксировать один UI-kit и без переезда на новую дизайн-систему, но из-за критической массы проблем было эффективнее решить все их разом в рамках обновления дизайн-системы.

Ресурсы и ограничения на старте

• Продуктовая компания, у которой 40+ своих сервисов. Для нас было челленджем создавать дизайн-систему для такого количества продуктов, текущих и предстоящих потребностей бизнеса.
• Кросс-функциональные команды продуктов. Проектировщики и фронтенд-разработчики были встроены в продуктовые команды и работали над задачами конкретного продукта.
• Команда из 16 проектировщиков и 16 разработчиков. В нашем случае это были специалисты, full-time работающие в продуктовой команде. Поэтому пришлось договариваться о том, чтобы руководители выделили часть их рабочего времени на дизайн-систему.

Цель: создать 45 компонентов, 10 паттернов. Этот набор закрыл бы 99% потребностей при проектировании.

Сложности на старте

• Ноябрь – приближался конец года. Основной целью менеджеров продуктовых команд было завершение задач из текущего роадмапа, поэтому было сложно договориться о выделении времени на работу над дизайн-системой.
• Продуктовый роадмап на следующий год – только у 10% команд работы над дизайн-системой входили в роадмап, с остальными пришлось договариваться по ситуации.
• Старая дизайн–система со своими недостатками.
  • Отсутствовали некоторые состояния компонентов. Например, hover.
  • Содержала не все компоненты, которые использовались именно в панели управления.
  • Не хватало правил использования компонентов. Например, было неясно, что использовать для текущей задачи – radio buttons или tabs? Как понять, когда использовать primary, а когда secondary button?
  • Дизайн ДС не обновлялся с 2016 года.

Итак, теперь вы знаете о предпосылках, ограничениях и задачах проекта. Теперь переходим к главному: урокам, которые я вынесла из процесса.

Урок 1: Выделите одного владельца дизайн-системы

Для кого урок в первую очередь: дизайн-менеджеры, UX-лиды

Предпосылки

Над проектом работала вся UX- и FE-команда: мы распределили нагрузку и запланировали процессы, но не четко зафиксировали роли.

Например, мне казалось, что ответственность за результат — несмотря на то, что есть менеджер проекта — в разной степени лежит на всех участниках. И что все смотрят на важность ДС и ее необходимость для будущей работы так же, как и я.

На самом деле, это когнитивная ловушка — когда ответственных несколько, считай, на самом деле ответственного нет вовсе. До этой жизненной мудрости я дошла не сразу — разработка дизайн-системы в Selectel стала одной из моих первых больших менеджерских задач. 

Параллельно с ней я пыталась сделать еще несколько, пока не заработала тревожное расстройство (шутка, у меня есть психолог, который следит, чтобы такого не случилось).

Более опытные менеджеры сразу считали, что ответственная я, но это мы проговорили не сразу.

Решение

В какой-то момент я осознала, что вся ответственность на мне – The end. Из такой позиции мне стало проще принимать решения, я начала смотреть на процесс более верхнеуровнево и снизила ожидания от других членов команды.

Итоги

Наличие одного владельца гарантирует единую точку для принятия решений и помогает следить за порядком в процессах.

Я понимала цель, предпосылки и контекст. Отталкиваясь от этих данных, принимала решения об организации файлов, описаниях характеристик, проработке компонентов и итерациях разработки.

Без выделенной роли владельца дизайна-система легко может прийти в беспорядок, поскольку люди и приоритеты в командах меняются, а документация устаревает.

Евангелизм стал регулярной практикой.

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

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

Укрепилось кросс-функциональное сотрудничество.

Роль владельца дизайн-системы предполагает много коммуникации с различными отделами. Из этой точки можно помогать командам разрешать конфликты, согласовывать приоритеты и способствовать тому, чтобы дизайн-система оставалась объединяющей силой, а не источником разногласий.

Урок 2: Оценивайте время, исходя из уровня сложности, ресурсов и опыта команды

Для кого урок в первую очередь: UX-лиды, FE-лиды

Предпосылки

При оценке времени на разработку одного компонента со стороны UX я опиралась на свой опыт. Прежде чем подключить команду, сделала референсное описание компонента кнопки примерно за 20 часов. В это время входил анализ других ДС, лучших практик и определение структуры описания компонента.

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

Для отслеживания прогресса по разработке компонентов я создала такую таблицу:

Я понимала, что моя оценка слишком оптимистичная, но не думала, что настолько. Проблемы возникли практически сразу. Через неделю ни у кого из проектировщиков не было материала, который можно было бы передавать в ревью. Требовалось дополнительное время, мы договорились о неделе на доработку черновика. Данные по первой итерации выглядели следующим образом:

• Проектировщики тратят на работу над компонентом один рабочий день в неделю.
• Время оформления компонента оказалось ≈ 40 часов (а не 20 как я изначально думала). 
• Всего компонентов ≈ 40.
• Проектировщиков 14, иногда они болеют и ходят в отпуск.
• С текущей скоростью UX–команда закончит работу над компонентами через 4 месяца. И это только над компонентами — дальше еще паттерны, страницы и работа FE-разработчиков.

Решение

1. Принятие ситуации и переоценка сроков. Я провела ревью того, что команда успела сделать и дала обратную связь. Где-то ребята закопались в анализе доступной информации и я дала рекомендацию остановиться и перейти к созданию документации, а где-то все действия были обоснованы и я согласилась, что на разработку такого компонента нужно большее количество времени.
2. Поиск наилучшего формата работы над продуктовыми задачами и дизайн-системой одновременно. Кому-то оказалась удобнее выделять целый день под работу над компонентом и держать фокус только на этой задаче, а кому-то нравилось «отвлекаться»‎ от продуктовых задач и заниматься разработкой компонента в течение недели в свободные слоты.

Итоги

Учитывайте прошлый опыт, уровень сложности и ресурсы команды при планировании работ.

Брать время разработки черновика для одного компонента как референсное – не лучшая идея. Выборка слишком маленькая для масштабирования. Кроме того, компоненты слишком разные и уровень навыков у людей в команде тоже.

Если это первый проект, над которым вы работаете с командой и пока еще нет релевантного опыта, на основе которого можно было бы сделать оценку, лучше относиться к первой итерации как к тестовой и вообще не строить ожиданий. Тем более — коммититься на какие-то дедлайны со стейкхолдерами.

Завершите первую итерацию, проведите ретро и после стройте предположения по срокам.

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

При этом предлагайте помощь в поиске оптимального формата и договаривайтесь о дедлайнах.

Урок 3: Описывайте не только состояния компонентов, но и кейсы в продукте

Для кого урок в первую очередь: UX-лиды, UX-дизайнеры

Предпосылки

​​В старой дизайн-системе командам не хватало описания реальных кейсов использования. Например, у нас были компоненты, которые реализованы в коде, но мы не знали, как ими пользоваться.

Так, с RadioButton было не понятно:

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

Без правил каждый дизайнер интерпретировал данные по-своему. Следом копилась неконсистентность в решениях. В проектировании новой ДС решили сразу восполнить этот пробел и описать кейсы использования в продукте.

Решение

Во время подготовки шаблона описания компонента для новой дизайн-системы я сразу зафиксировала смысловые блоки, которые должны быть:

1. Название компонента
2. Оглавление
3. Описание компонента
4. Типы компонента
5. Специфичная информация по компоненту
6. Правила использования
7. Размеры
8. Источники информации
9. Сам компонент и его варианты

Рассмотрим описание компонента на примере кнопки.

1. Название, оглавление и описание компонента

Для удобства навигации сделали оглавление кликабельным, а при описании компонента старались писать максимально емко и отвечать на вопрос «для чего используется этот компонент?».

2. Типы кнопок

В этом блоке мы перечисляли варианты компонента, добавили визуализацию и назначение каждого варианта.

3. Специфичная информация по компоненту: текст на кнопке

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

Чтобы сделать описание более наглядным и исключить разночтения, мы использовали формат «верно / неверно».

4. Правила использования

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

5. Размеры

Этот раздел нужен в нескольких случаях:

1. Когда проектируете компонент. В этом случае разработчик будет использовать описание как спецификацию.
2. Когда выбираете нужный размер при проектировании решения. Описание в последней колонке подскажет, какой размер лучше использовать.
3. Когда вы работаете над адаптивностью и продумываете размерную линейку для разных девайсов.

6. Источники информации

Разработка каждого компонента велась по стандартному дизайн-процессу и в ходе поиска и анализа лучших практик в индустрии было изучено много материала. Терять доступ к такой информации не хотелось, поэтому я выделила отдельный блок для сбора данных.

7. Сам компонент и его варианты

Это — важная часть для команды дизайнеров, ведь именно с помощью компонентов собираются все интерфейсные решения. Нам важно было учесть нюансы каждого компонента, чтобы в будущем сэкономить время и брать все решения «из коробки»‎, ничего не дорабатывая.

Это был один из самых трудозатратных этапов. Вдобавок к этому Figma выпустила несколько обновлений, которые были прекрасны, но нам пришлось пересобирать компоненты, чтобы воспользоваться новыми фичами.

Итоги

Не буду говорить, что это было просто, – в процессе создания таких описаний многим дизайнерам приходилось превозмогать 🙂

Создание документации к компонентам требует разных навыков:

• уметь искать и анализировать источники информации,
• владеть Figma на высоком уровне,
• уметь работать с текстами и писать документацию так, чтобы вся команда понимала смысл,
• уметь давать и принимать обратную связь,
• уметь договариваться с коллегами.

Но по завершению всех работ UX-команда увидела ценность такого подхода и теперь пользуется результатами своей работы.

• Подробное описание компонентов дает дизайнерам ответы на все возникающие вопросы при проектировании интерфейсов.
• Решения между продуктами стали более консистентны между собой.

Время проектирования сократилось примерно в 3 раза. Решения дизайн-системы универсальны и могут переиспользоваться в каждом продукте.

• Дизайнерам понятно, почему решения выглядят именно так, ведь они сами участвовали в их разработке. Работать в таком контексте намного проще, чем когда на тебя спускают требования «из ниоткуда»‎.
• Члены команды доверяют друг другу, появилось чувство плеча. В такой обстановке проще и приятнее работать.

Урок 4: Фиксируйте договоренности в публичном пространстве

Для кого урок в первую очередь: UX-лиды, UX-дизайнеры, FE-лиды

Предпосылки

• Над дизайн-системой одновременно работало 16 дизайнеров и 16 разработчиков.
• Каждый отвечал за несколько компонентов.
• Некоторые дизайнеры отвечали за определение формата описания properties, организацию хранения макетов и прочие общие договоренности.
• У нас были ежедневные синки с дизайнерами, где мы рассказывали о том, как продвинулись в работе. 

Но в какой-то момент с нами произошла ситуация, характерная для работы в большой команде: знания стали забываться, перестали распространяться на всех и хранились локально у некоторых дизайнеров и разработчиков.

Решение

1. У нас были ежедневные синки, и я решила, что хорошей практикой будет, если каждый день meeting notes будет вести новый человек. Таким образом у нас всегда были логи и повысилась вовлеченность членов команды – когда тебе нужно что-то записать в публичный документ, ты будешь более внимательно слушать коллег и вовлекаться в обсуждение.

2. На одном из ретро мы поняли, что нужно транслировать договоренности и изменения не только в meeting notes, но и Telegram, так как на информацию в нем коллеги быстрее реагируют, чем на отбивки в почте. Так у нас появились теги для маркировки сообщений об изменениях в ДС.

Итоги

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

Урок 5: Публично рассказывайте об успехах проекта

Для кого урок в первую очередь: дизайн-менеджеры, UX-лиды

Предпосылки

Создание дизайн-системы – одна из моих первых задач в роли дизайн-менеджера. В тот момент все мое внимание было сконцентрировано на том, чтобы создать продукт с высоким качеством, проработать corner-кейсы и обойти все технические ограничения.

Ориентированность на качество – отличная история, но я упускала еще один важный пласт работ: дистрибуцию промежуточных результатов до стейкхолдеров. Мне казалось, что все и так все знают, информация сама растекается по компании и затекает в уши тех, кому нужно.

И это правда было так, но дотекала она совсем не в том формате, в каком бы мне хотелось. 

Стейкхолдерам казалось, что разработка идет очень долго. Им было непонятно, почему нужно настолько детально проработать все компоненты и почему все же нельзя взять их все из коробки.

Процесс создания дизайн-системы был окутан туманом, появлялось напряжение между продуктовыми командами и горизонтальной UX-командой. Работать в таких условиях было неприятно.

Решение

Вскоре я поняла, что дальше так продолжаться не может и предприняла ряд шагов:

• Организовала встречи с руководителями команд. Состав участников — я как лид UX-направления, лид FE-направления, техлиды продуктовых команд и UX-дизайнеры.
• Создала чат, в который каждую неделю отписывалась о результатах за прошлую неделю. У стейкхолдеров была возможность задавать интересующие вопросы и уменьшать уровень неизвестности.
• Стала говорить о промежуточных результатах на продакт-синках, которые проводятся на всю компанию.

Итоги

Позитивные изменения, которые я отметила:

Стейкхолдеры тоже вовлеклись в процесс разработки ДС

Создание дизайн-системы – сложная задача, в которой участвуют дизайнеры, разработчики, продакт-менеджеры и другие заинтересованные лица. И всем участникам процесса должно быть понятно, что происходит на текущий момент. Когда я начала делиться прогрессом разработки с как можно большим количеством людей, то стейкхолдеры стали вовлекаться, оставлять отзывы, задавать вопросы и вносить предложения. 

Появился мэтч между ожиданиями и реальностью

Прозрачность приводит не только к лучшим результатам, но и гарантирует, что дизайн-система будет соответствовать ожиданиям и потребностям всех стейкхолдеров в компании.

У стейкхолдеров появилось чувство сопричастности

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

Работа менеджеров стала проще

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

Урок 6: Закладывайте ресурсы на развитие и поддержку дизайн-системы

Для кого урок в первую очередь: дизайн-менеджеры, UX-лиды, FE-лиды

Предпосылки

Когда я начинала работу над этим проектом, делала предварительную оценку и договаривалась о выделении ресурсов на реализацию, то обсуждение со стейкхолдерами шло из позиции «через Х месяцев у нас будет Y результат, после чего я не буду претендовать на ресурсы дизайнеров и разработчиков». 

Мне казалось, что если сразу скажу «ребята, нам потом еще все это поддерживать и развивать», то мне откажут прямо на старте. 

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

В итоге, когда 90% ДС было готово, стало очевидно, что на поддержку и развитие ДС нужно тратить соизмеримое количество ресурсов, доступ к которым прикрылся.

Решение

Введение новых ролей — дизайнера и разработчиков дизайн-системы

В реалиях Selectel дизайнерам было сложно совмещать работу над продуктом и дизайн-системой, поэтому мы пришли к тому, что выделили одного дизайнера на работы по ДС. При этом остальные также участвуют, но уже в факультативном формате, когда закрыты приоритетные продуктовые задачи.

Если у вас есть ресурсы,  рекомендую нанять людей, которые будут заниматься только дизайн-системой, а не просить продуктовых дизайнеров совмещать свои задачи с созданием ДС. Все-таки, это достаточно отличающиеся между собой навыки в дизайне. Кроме того, не всем продуктовым дизайнерам интересно заниматься дизайн-системой.

Аналогичная ситуация с разработкой. Здесь мы выделили двух FE-разработчиков.

Итоги

Коллеги используют дизайн-систему при создании фичей

Это важно, так как на самом деле цель – не создать дизайн-систему, а добиться того, чтобы ее использовали продуктовые команды. И как раз этот процесс невозможен без поддержки и своевременного реагирования на возникающие запросы на доработки и правки багов.

Саммари

Если вдруг вы просто долистали до конца, чтобы оценить объем или хотите прочитать только самое основное, то вот вся мякотка в двух словах.

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

Если вы все-таки решили ввязаться в эту историю, то вот, что я рекомендую сделать:

1. Выделить отдельную роль для владельца дизайн-системы. Иначе вы рискуете столкнуться с перекладыванием ответственности между коллегами и увеличением сроков разработки.

2. Адекватно оценивать время на разработку компонентов. Уделите время и подумайте, какие факторы могут повлиять на скорость работы вашей команды, не будьте излишне оптимистичны.

3. Описывать не только состояния компонентов, но и кейсы использования в реальном продукте. Ваша цель — не реализовать максимально качественно и детально компоненты в вакууме, а создать правила, по которым команда сможет их использовать и создавать качественные продуктовые решения.

По ссылке — пример описания кнопки из дизайн-системы Selectel.

4. Фиксировать договоренности в публичном пространстве. Чем больше людей в вашей команде, тем более формально стоит подходить к сбору и упорядочению информации, которая у вас есть.

5. Проводить маркетинг успехов. Работа над дизайн-системой – долгая история. Важно рассказывать коллегам о вашем прогрессе и держать их в контексте.

6. Закладывать ресурсы на развитие и поддержку дизайн-системы. Дизайн-система – это продукт, который развивается параллельно с продуктовым портфелем компании. Нужно понимать, что у этого проекта нет конца и после реализации ключевой части нужно будет его поддерживать. И для этого продукта нужна отдельная команда.