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