Как мы переработали дизайн-систему для компании с 40+ продуктами или уроки, которые я бы хотела усвоить раньше

Привет! Меня зовут Ксения Гаврилова, я дизайн-менеджер в Selectel. В тексте расскажу, как в 2022 году мы обновили дизайн-систему. Это был сложный и интересный путь, в котором нужно было наладить коммуникацию в командах, обновить фреймворк и выровнять UX в сложных технических продуктах.

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

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

Быстрая навигация по тексту:

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

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

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

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

→ Уроки, которые я вынесла из процесса

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

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

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

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

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

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

→ Саммари и шаблон

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

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.

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

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

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

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

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

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

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

• Продуктовый роадмап на следующий год – только у 10% команд работы над дизайн-системой входили в роадмап, с остальными пришлось договариваться по ситуации.

• Старая дизайн–система со своими недостатками:

→ Отсутствовали некоторые состояния компонентов. Например, hover.

→ Содержала не все компоненты, которые использовались именно в панели управления.

→ Не хватало правил использования компонентов. Например, было неясно, что использовать для текущей задачи – radio buttons или tabs? Как понять, когда использовать primary, а когда secondary button?

→ Дизайн ДС не обновлялся с 2016 года.

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

Предпосылки

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

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

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

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

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

Решение

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

Итоги

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

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

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

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

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

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

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

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

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

Предпосылки

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

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

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

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

• Проектировщики тратят на работу над компонентом один рабочий день в неделю.

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

Решение

• Принятие ситуации и переоценка сроков.

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

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

Итоги

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

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

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

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

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

Предпосылки

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

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

• сколько может быть значений в списке,

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

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

Решение

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

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

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

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

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

Типы кнопок

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

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

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

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

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

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

Размеры

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

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

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

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

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

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

Итоги

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

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

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

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

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

• Члены команды доверяют друг другу, появилось чувство плеча. В такой обстановке проще и приятнее работать.

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

Предпосылки

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

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

Решение

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

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

3. Договорились, что если изменения масштабные и затрагивают всю команду, необходимо организовать встречу и провести презентацию. Это позволит убедиться, что информация точно доставлена до всех членов команды и позволит обсудить нюансы решения. Результаты встречи также должны быть зафиксированы в meeting notes. Кроме того, должна быть приложена ссылка с записью встречи.

4. Мы решили навести порядок в Confluence — там мы храним внутреннюю базу знаний компании — и организовали дерево данных по ДС так, чтобы по заголовку было сразу понятно содержание страницы.

Итоги

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

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

Предпосылки

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

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

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

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

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

Решение

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

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

Итоги

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

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

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

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

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

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

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

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

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

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

Предпосылки

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

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

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

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

Решение

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

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

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

Итоги

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

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

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

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

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

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

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

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

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

Чтобы приблизить ощущение праздника, запустите нашего бота. Он расскажет, что почитать, посмотреть или приготовить, подберет тотемное животное на 2024 и попробует предсказать будущее.

Запустить бота

#дизайн #дизайнсистема #кейс #it #selectel