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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Серверы в выделенных серверах и облачной платформе

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

Страницы серверов в выделенных серверах и облачной платформе

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

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

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

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

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

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

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

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

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

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

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

Было

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

Стало

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предпосылки

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

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

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

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

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

Решение

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

Итоги

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

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

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

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

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

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

Предпосылки

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

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

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

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

Решение

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

Итоги

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

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

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

Предпосылки

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

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

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

Решение

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

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

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

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

Типы кнопок

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

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

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

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

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

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

Размеры

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

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

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

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

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

Итоги

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

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

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

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

Предпосылки

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

Решение

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

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

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

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

Итоги

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

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

Предпосылки

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

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

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

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

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

Решение

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

Итоги

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

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

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

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

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

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

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

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

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

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

Предпосылки

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

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

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

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

Решение

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

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

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

Итоги

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

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

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

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

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

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

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

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

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

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