Ксения Гаврилова, Автор в Академия Selectel

Предпосылки к обновлению дизайн-системы Первая предпосылка: опыт клиентов В панели управления Selectel — провайдер IT-инфраструктуры. У нас широкая продуктовая линейка, в основе которой выделенные серверы и собственная облачная платформа. Еще — сетевые услуги, администрирование, консалтинг, защита IT-инфраструктуры и другие сервисы для комплексного решения бизнес-задач. Во всех продуктах есть одинаковые объекты и действия. Например, заказ и удаление услуги или страницы серверов и сетей. До дизайн-системы эти сущности выглядели по-разному в разных продуктах. Это приводило к неконсистентному опыту клиентов и создавало лишнюю нагрузку — пользователям приходилось обучаться работе с интерфейсом заново при переходе между продуктами. Например, клиент, который пользуется выделенными серверами и облачной платформой, был вынужден запоминать, где в каждом из продуктов расположена важная информация и управление сервером. Вот яркие примеры различий ↓ Серверы в выделенных серверах и облачной платформе. Какие здесь недостатки: Разные форматы отображения серверов: в выделенных серверах используется карточный вид, а в облачной платформе — табличный. По-разному отображаются статусы: в выделенных серверах есть переключатель, который показывает состояние сервера, а в облачной платформе статус выводится в виде текста. Различная механика взаимодействия с сущностями: в выделенных серверах кликабельна вся область карточки, по нажатию открывается страница сервера. Чтобы попасть на страницу сервера в облачной платформе, нужно кликнуть на название сервера. Страницы серверов в выделенных серверах и облачной платформе. Какие здесь недостатки: Функции переименования сервера расположены в разных местах. Снова разное отображение статусов. Разная механика копирования uuid. Разный порядок разделов второго уровня. На сайте и в панели управления Кроме неконсистентности внутри панели управления (ПУ), была разница между ней и сайтом компании. Дизайн панели управления морально устарел. Это особенно чувствовалось при переходе с площадки на площадку. А разнородность в решениях особенно сильно ощущалась при первом заказе клиента, когда он выбирал продукт или услугу на сайте, а затем переходил в панель управления для ее заказа и настройки. Клиенты выделенных серверов, например, сталкивались с тем, что форма заказа кардинально отличалась по оформлению и функционалу фильтрации. Первый этап заказа сервера – выбор конфигурации Пример страницы сайта и ПУ в момент выбора сервера. Какие здесь недостатки: Различия в фильтрации списка серверов: набор параметров фильтрации, расположение фильтров на странице и их последовательность. Различия в дефолтном способе сортировки. Второй этап заказа сервера – выбор дополнительных услуг, операционной системы и тарифного плана Пример страницы сайта и ПУ в момент выбора доп. опций. Какие здесь недостатки: Различия в расположении смысловых блоков: конфигурация, «входит в стоимость», стоимость заказа. Критическая масса таких разнородных решений приводило к снижению лояльности клиентов, которые одновременно используют несколько услуг. Кроме разнородного опыта у пользователей, накапливались различные проблемы на уровне команд дизайнеров и разработчиков. Вторая предпосылка: опыт коллег Продуктовые дизайнеры Продуктовые дизайнеры долгое время жили без единой библиотеки компонентов. Это нормально работало до того, как изменились обстоятельства. Было: 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-разработчиков. Решение Принятие ситуации и переоценка сроков. Я провела ревью того, что команда успела сделать и дала обратную связь. Где-то ребята закопались в анализе доступной информации и я дала рекомендацию остановиться и перейти к созданию документации, а где-то все действия были обоснованы и я согласилась, что на разработку такого компонента нужно большее количество времени. Поиск наилучшего формата работы над продуктовыми задачами и дизайн-системой одновременно. Кому-то оказалась удобнее выделять целый день под работу над компонентом и держать фокус только на этой задаче, а кому-то нравилось «отвлекаться»‎ от продуктовых задач и заниматься разработкой компонента в течение недели в свободные слоты. Итоги Учитывайте прошлый опыт, уровень сложности и ресурсы команды при планировании работ. Брать время разработки черновика для одного компонента как референсное – не лучшая идея. Выборка слишком маленькая для масштабирования. Кроме того, компоненты слишком разные и уровень навыков у людей в команде тоже. Если это первый проект, над которым вы работаете с командой и пока еще нет релевантного опыта, на основе которого можно было бы сделать оценку, лучше относиться к первой итерации как к тестовой и вообще не строить ожиданий. Тем более — коммититься на какие-то дедлайны со стейкхолдерами. Завершите первую итерацию, проведите ретро и после стройте предположения по срокам. Давайте возможность дизайнерам и разработчикам самостоятельно решать, когда работать над компонентом. При этом предлагайте помощь в поиске оптимального формата и договаривайтесь о дедлайнах. Урок 3: Описывайте не только состояния компонентов, но и кейсы в продукте Для кого урок в первую очередь: UX-лиды, UX-дизайнеры Предпосылки В старой дизайн-системе командам не хватало описания реальных кейсов использования. Например, у нас были компоненты, которые реализованы в коде, но мы не знали, как ими пользоваться. Так, с RadioButton было не понятно: сколько может быть значений в списке, как и где показывать ошибку, если выбор опции обязательно нужно сделать, какой стиль должен быть у заголовка группы, можно ли располагать группу горизонтально. Без правил каждый дизайнер интерпретировал данные по-своему. Следом копилась неконсистентность в решениях. В проектировании новой ДС решили сразу восполнить этот пробел и описать кейсы использования в продукте. Решение Во время подготовки шаблона описания компонента для новой дизайн-системы я сразу зафиксировала смысловые блоки, которые должны быть: Название компонента Оглавление Описание компонента Типы компонента Специфичная информация по компоненту Правила использования Размеры Источники информации Сам компонент и его варианты Рассмотрим описание компонента на примере кнопки. Название, оглавление и описание компонента Для удобства навигации сделали оглавление кликабельным, а при описании компонента старались писать максимально емко и отвечать на вопрос «для чего используется этот компонент?». 2. Типы кнопок В этом блоке мы перечисляли варианты компонента, добавили визуализацию и назначение каждого варианта. 3. Специфичная информация по компоненту: текст на кнопке Для каждого компонента этот блок будет отличаться. К примеру, для кнопки важной частью является текст — именно он влияет на то, поймет ли пользователь, за какое действие отвечает кнопка. Чтобы сделать описание более наглядным и исключить разночтения, мы использовали формат «верно / неверно». 4. Правила использования Компоненты существуют не в вакууме, поэтому при их использовании всегда нужно учитывать контекст и связь с другими элементами интерфейса. 5. Размеры Этот раздел нужен в нескольких случаях: Когда проектируете компонент. В этом случае разработчик будет использовать описание как спецификацию. Когда выбираете нужный размер при проектировании решения. Описание в последней колонке подскажет, какой размер лучше использовать. Когда вы работаете над адаптивностью и продумываете размерную линейку для разных девайсов. 6. Источники информации Разработка каждого компонента велась по стандартному дизайн-процессу и в ходе поиска и анализа лучших практик в индустрии было изучено много материала. Терять доступ к такой информации не хотелось, поэтому я выделила отдельный блок для сбора данных. 7. Сам компонент и его варианты Это — важная часть для команды дизайнеров, ведь именно с помощью компонентов собираются все интерфейсные решения. Нам важно было учесть нюансы каждого компонента, чтобы в будущем сэкономить время и брать все решения «из коробки»‎, ничего не дорабатывая. Это был один из самых трудозатратных этапов. Вдобавок к этому Figma выпустила несколько обновлений, которые были прекрасны, но нам пришлось пересобирать компоненты, чтобы воспользоваться новыми фичами. Итоги Не буду говорить, что это было просто, – в процессе создания таких описаний многим дизайнерам приходилось превозмогать :) Создание документации к компонентам требует разных навыков: уметь искать и анализировать источники информации, владеть Figma на высоком уровне, уметь работать с текстами и писать документацию так, чтобы вся команда понимала смысл, уметь давать и принимать обратную связь, уметь договариваться с коллегами. Но по завершению всех работ UX-команда увидела ценность такого подхода и теперь пользуется результатами своей работы. Подробное описание компонентов дает дизайнерам ответы на все возникающие вопросы при проектировании интерфейсов. Решения между продуктами стали более консистентны между собой. Время проектирования сократилось примерно в 3 раза. Решения дизайн-системы универсальны и могут переиспользоваться в каждом продукте. Дизайнерам понятно, почему решения выглядят именно так, ведь они сами участвовали в их разработке. Работать в таком контексте намного проще, чем когда на тебя спускают требования «из ниоткуда»‎. Члены команды доверяют друг другу, появилось чувство плеча. В такой обстановке проще и приятнее работать. Урок 4: Фиксируйте договоренности в публичном пространстве Для кого урок в первую очередь: UX-лиды, UX-дизайнеры, FE-лиды Предпосылки Над дизайн-системой одновременно работало 16 дизайнеров и 16 разработчиков. Каждый отвечал за несколько компонентов. Некоторые дизайнеры отвечали за определение формата описания properties, организацию хранения макетов и прочие общие договоренности. У нас были ежедневные синки с дизайнерами, где мы рассказывали о том, как продвинулись в работе. Но в какой-то момент с нами произошла ситуация, характерная для работы в большой команде: знания стали забываться, перестали распространяться на всех и хранились локально у некоторых дизайнеров и разработчиков. Решение У нас были ежедневные синки, и я решила, что хорошей практикой будет, если каждый день meeting notes будет вести новый человек. Таким образом у нас всегда были логи и повысилась вовлеченность членов команды – когда тебе нужно что-то записать в публичный документ, ты будешь более внимательно слушать коллег и вовлекаться в обсуждение. Пример оформления заметок со встреч. 2. На одном из ретро мы поняли, что нужно транслировать договоренности и изменения не только в meeting notes, но и Telegram, так как на информацию в нем коллеги быстрее реагируют, чем на отбивки в почте. Так у нас появились теги для маркировки сообщений об изменениях в ДС. 3. Договорились, что если изменения масштабные и затрагивают всю команду, необходимо организовать встречу и провести презентацию. Это позволит убедиться, что информация точно доставлена до всех членов команды и позволит обсудить нюансы решения. Результаты встречи также должны быть зафиксированы в meeting notes. Кроме того, должна быть приложена ссылка с записью встречи. 4. Мы решили навести порядок в Confluence — там мы храним внутреннюю базу знаний компании — и организовали дерево данных по ДС так, чтобы по заголовку было сразу понятно содержание страницы. Итоги Появилось единое пространство для фиксации договоренностей, а также повысилась общая вовлеченность команды. Время на поиск ответа на свой вопрос и выяснение деталей у коллег в рабочих чатиках заметно сократилось. Урок 5: Публично рассказывайте об успехах проекта Для кого урок в первую очередь: дизайн-менеджеры, UX-лиды Предпосылки Создание дизайн-системы – одна из моих первых задач в роли дизайн-менеджера. В тот момент все мое внимание было сконцентрировано на том, чтобы создать продукт с высоким качеством, проработать corner-кейсы и обойти все технические ограничения. Ориентированность на качество – отличная история, но я упускала еще один важный пласт работ: дистрибуцию промежуточных результатов до стейкхолдеров. Мне казалось, что все и так все знают, информация сама растекается по компании и затекает в уши тех, кому нужно. И это правда было так, но дотекала она совсем не в том формате, в каком бы мне хотелось. Стейкхолдерам казалось, что разработка идет очень долго. Им было непонятно, почему нужно настолько детально проработать все компоненты и почему все же нельзя взять их все из коробки. Процесс создания дизайн-системы был окутан туманом, появлялось напряжение между продуктовыми командами и горизонтальной UX-командой. Работать в таких условиях было неприятно. Решение Вскоре я поняла, что дальше так продолжаться не может и предприняла ряд шагов: Организовала встречи с руководителями команд. Состав участников — я как лид UX-направления, лид FE-направления, техлиды продуктовых команд и UX-дизайнеры. Создала чат, в который каждую неделю отписывалась о результатах за прошлую неделю. У стейкхолдеров была возможность задавать интересующие вопросы и уменьшать уровень неизвестности. Стала говорить о промежуточных результатах на продакт-синках, которые проводятся на всю компанию. Итоги Позитивные изменения, которые я отметила: Стейкхолдеры тоже вовлеклись в процесс разработки ДС Создание дизайн-системы – сложная задача, в которой участвуют дизайнеры, разработчики, продакт-менеджеры и другие заинтересованные лица. И всем участникам процесса должно быть понятно, что происходит на текущий момент. Когда я начала делиться прогрессом разработки с как можно большим количеством людей, то стейкхолдеры стали вовлекаться, оставлять отзывы, задавать вопросы и вносить предложения. Появился мэтч между ожиданиями и реальностью Прозрачность приводит не только к лучшим результатам, но и гарантирует, что дизайн-система будет соответствовать ожиданиям и потребностям всех стейкхолдеров в компании. У стейкхолдеров появилось чувство сопричастности Когда стейкхолдеры вносят свой вклад в создание и развитие инструмента, появляется чувство сопричастности и ответственности за происходящее. Стейкхолдеры перестали воспринимать дизайн-систему как нечто навязанное сверху, а начали видеть инструмент, который помогли создать. Как следствие они были более мотивированы вкладывать ресурсы в ее развитие. Работа менеджеров стала проще Руководителям команд было важно понимать прогресс по созданию дизайн-системы, чтобы учитывать его при планировании работ по своему направлению. Когда этот процесс и сроки стали более прозрачны всем, стало проще выполнять свою работу. Урок 6: Закладывайте ресурсы на развитие и поддержку дизайн-системы Для кого урок в первую очередь: дизайн-менеджеры, UX-лиды, FE-лиды Предпосылки Когда я начинала работу над этим проектом, делала предварительную оценку и договаривалась о выделении ресурсов на реализацию, то обсуждение со стейкхолдерами шло из позиции «через Х месяцев у нас будет Y результат, после чего я не буду претендовать на ресурсы дизайнеров и разработчиков». Мне казалось, что если сразу скажу «ребята, нам потом еще все это поддерживать и развивать», то мне откажут прямо на старте. В какой-то момент я сама начала верить, что скоро мы дойдем до финальной точки и закроем эту задачу, хотя понимала что дизайн-система, — живой продукт, который должен развиваться параллельно портфелю компании и изменениям нужд дизайнеров и разработчиков. В итоге, когда 90% ДС было готово, стало очевидно, что на поддержку и развитие ДС нужно тратить соизмеримое количество ресурсов, доступ к которым прикрылся. Решение Введение новых ролей — дизайнера и разработчиков дизайн-системы В реалиях Selectel дизайнерам было сложно совмещать работу над продуктом и дизайн-системой, поэтому мы пришли к тому, что выделили одного дизайнера на работы по ДС. При этом остальные также участвуют, но уже в факультативном формате, когда закрыты приоритетные продуктовые задачи. Если у вас есть ресурсы, рекомендую нанять людей, которые будут заниматься только дизайн-системой, а не просить продуктовых дизайнеров совмещать свои задачи с созданием ДС. Все-таки, это достаточно отличающиеся между собой навыки в дизайне. Кроме того, не всем продуктовым дизайнерам интересно заниматься дизайн-системой. Аналогичная ситуация с разработкой. Здесь мы выделили двух FE-разработчиков. Итоги Коллеги используют дизайн-систему при создании фичей Это важно, так как на самом деле цель – не создать дизайн-систему, а добиться того, чтобы ее использовали продуктовые команды. И как раз этот процесс невозможен без поддержки и своевременного реагирования на возникающие запросы на доработки и правки багов. Саммари Если вдруг вы просто долистали до конца, чтобы оценить объем или хотите прочитать только самое основное, то вот вся мякотка в двух словах. Проведите предварительный анализ и поймите, действительно ли вам нужна самописная дизайн-система, или ваши потребности можно закрыть с помощью одной из тех, что уже есть в открытом доступе. Если вы все-таки решили ввязаться в эту историю, то вот, что я рекомендую сделать: 1. Выделить отдельную роль для владельца дизайн-системы. Иначе вы рискуете столкнуться с перекладыванием ответственности между коллегами и увеличением сроков разработки. 2. Адекватно оценивать время на разработку компонентов. Уделите время и подумайте, какие факторы могут повлиять на скорость работы вашей команды, не будьте излишне оптимистичны. 3. Описывать не только состояния компонентов, но и кейсы использования в реальном продукте. Ваша цель — не реализовать максимально качественно и детально компоненты в вакууме, а создать правила, по которым команда сможет их использовать и создавать качественные продуктовые решения. По ссылке — пример описания кнопки из дизайн-системы Selectel. 4. Фиксировать договоренности в публичном пространстве. Чем больше людей в вашей команде, тем более формально стоит подходить к сбору и упорядочению информации, которая у вас есть. 5. Проводить маркетинг успехов. Работа над дизайн-системой – долгая история. Важно рассказывать коллегам о вашем прогрессе и держать их в контексте. 6. Закладывать ресурсы на развитие и поддержку дизайн-системы. Дизайн-система – это продукт, который развивается параллельно с продуктовым портфелем компании. Нужно понимать, что у этого проекта нет конца и после реализации ключевой части нужно будет его поддерживать. И для этого продукта нужна отдельная команда.