Создание команды, работающей над дизайн-системой

Перевод Designing a Systems Team от Nathan Curtis.

команда работающая над дизайн системой

Команда, работающая над дизайн-системой, служит продуктовым командам

Великолепная книга Питера Мерхольца и Кристен Скиннер «Org Design for Design Orgs» описывает модели и роли при создании дизайн команд и отделов. В главе «Роли и состав команды» они описывают вспомогательную исследовательскую группу, работающую на несколько других команд: «Сейчас количество UX-специалистов достигло критической массы, достаточной для формирования отдельной команды… с руководителем… который поддерживает рост сотрудников и результаты исследований продуктов и услуг компании».

Когда я это прочитал, то подумал: «Да, как и команды, работающие над дизайн-системами» решающие простые, но распространённые проблем – визуальным языком, используемыми компонентами интерфейса и т.д. Запомнив это высказывание, я был удивлён, узнав, что в ноябре прошлого года на конференции UI21, посвящённой пользовательским интерфейсам, Питер рассказал о команде, занимавшейся дизайн-системой компании Spotify, которой пришлось «прокладывать путь к модели», которую он описал. Может быть, я что-то недопонял. Но за эти годы я проработал в 15-20 командах, создававших дизайн-системы, которые обслуживали группы с похожими (но не одинаковыми) методами работы.

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

команда работающая над дизайн системой

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

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

Стадии развития команды, работающей над дизайн-системой

Большинство людей, с которыми я разговаривал (с клиентами, на конференциях, в сообществесистемного дизайна на Slack, находятся на одной из четырёх стадий развития: работающие в свободное время, работающие постоянно, профильная команда и команда команд.

Первая стадия: одиночки, работающие в свободное время

Люди, занимающиеся дизайн-системами в свободное время, обычно описывают затухание своего страстного порыва следующим образом: «Я сам по себе. В свободное время я создал (набор элементов интерфейса для Sketch или их код для Bootstrap), но никто, кроме меня, им не пользуется. Что мне делать дальше?»

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

Сухой остаток: не впадайте в уныние! Многие системы зарождались подобным образом. Докажите, что ваши инструменты способны приносить пользу – на примере пилотных проектов покажите их логичность, эффективность и возможность повторного использования. Это первый шаг в познании того, каким образом системы приносят людям пользу.

Вторая стадия: люди, которые занимаются системами постоянно

Когда систему оценили по достоинству, её создатель, работавший на продуктовую команду, добивается разрешения тратить на свою разработку небольшую часть времени (10% - 25%), а также рассказывает о пользе этой работы для других. Вооружённые официальным разрешением и временем, вы начинаете регулярно демонстрировать осязаемые результаты, будь то стандартизованные проектные ресурсы или набор фрагментов кода.

команда работающая над дизайн системой

В это время ваши единомышленники, также понимающие важность такой работы, могут помочь вам. Кто-то может начать вести беклог, но при этом его могут забросить из-за неясно сформулированных тикетов, ждущих своей очереди месяцами. Полусырая документация будет копится на недоделанных страницах или (о, нет!) в Confluence. Обновления будут, но мало кто о них знает, когда, как или почему.

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

«Если сумеете, то вам нужно создать потребность внутри своей организации, которую нельзя закрыть имеющимися ресурсами», Джаред Спул (Jared Spool), из книги «Beyond the UX Tipping Point».

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

Третья стадия: команда, работающая над дизайн-системой, как продуктовая команда

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

команда работающая над дизайн системой

В команды, которые я недавно создавал и впоследствии возглавлял, входили такие специалисты:

  • ОБЯЗАТЕЛЬНО: дизайнеры разных направлений, например, специалисты по визуальному проектированию, проектированию взаимодействия, проектированию информационной архитектуры. В любом случае, команда должна отличаться умением создавать элегантный визуальный язык.
  • ОБЯЗАТЕЛЬНО: инженеры со знанием HTML и CSS, способные работать над клиентской частью системы, и имеющие опыт для определения её архитектурных ограничений и создания инструментария.
  • СЛЕДУЕТ иметь: сотрудника, способного управлять продуктом и сотрудника с лидерскими качествами для определения стратегии команды и направлений работы, выбора схемы работы, проверки процесса внедрения, создания беклога, проведения scrum-митингов и критического анализа.
  • МОЖНО иметь специалистов в узких областях вроде контент-стратегии, доступности, надёжности, SEO и других. Хотя они и играют определённую роль, но не забывайте, что системы это, во-первых и в главных, объединение дизайна и инженерии.
  • ОБЫЧНО НЕ БЫЛО: специалистов по обеспечению качества и исследователей. Финансирования на это обычно нету и команды, работающие над дизайн-системами, в любом случае, могут сами создавать методы для их проверки. Исследования могут проводиться внутри продуктовых команд.

Стадия 4: команда команд, работающих над дизайн-системами

Некоторые большие компании (Google, IBM, GE, Cisco или Microsoft) создают такие команды, чтобы, для упорядочит работу многочисленных взаимосвязанных команд.

команда работающая над дизайн системой

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

Примеры команд, работающих над дизайн-системами

Хотя я участвовал в командах, создающих дизайн-системы, постоянно (с 2006 года), могу сказать, что многое в отрасли изменилось в 2012 году, когда появился адаптивный дизайн, усилились позиции HTML и CSS, а супер-успешные стартапы (называемые также «единорогами») начали (частично) систематически делать дизайн в коде. На следующих примерах видно, как прогрессировали модели команд, работающих над дизайн-системами, в которых я участвовал с того времени.

Пример 1: адаптив в электронной коммерции

Что работало хорошо: наша профильная команда занималась дизайном и документированием стандартов индивидуального взаимодействия пользователя с веб-ресурсом. Эта система была «большим боссом»: стиль, взаимодействие, компоненты, паттерны, бренд, публикации, SEO, удобство и всё, что только можно! Компании понадобилось около 2 лет, чтобы «стать адаптивной», и система играла решающую роль в направлении взаимодействия с клиентом в нужное русло.

команда работающая над дизайн системой команда работающая над дизайн системой

Что я с тех пор делаю по-другому: программную часть. Наша команда, работавшая над дизайн-системой, создала хорошо отлаженную библиотеку компонентов для прототипирования адаптивного дизайна и сделала стандартный сайт. Однако технические специалисты были против нашего кода и так и не создали библиотеку для себя. Результат? Двойная работа, неэффективность и неконсистентность (за исключением разработчиков, утащивших наш код в свои программы). Я поклялся себе никогда больше не заниматься бескодовыми системами в средах, которым он явно нужен.

Пример 2: язык проектирования для стремительно расширяющейся организации

Что работало хорошо: количество дизайнеров в компании всего за 12-18 месяцев выросло с, 30 до 200, и наша команда занялась созданием общего языка проектирования, задокументированного на сайте с настраиваемыми стандартами (то есть, действовала как фронтенд-разработчик). Учитывая большой масштаб и разветвлённость этой организации, мы объединили дизайнеров для того, чтобы они занялись иконками, а также основами взаимодействия с пользователем и получаемого им опыта. Хотя масштаб был меньше – всего лишь визуальный стиль, кнопки и формы за шесть месяцев, но наша работа, учитывая её размах и трудности, с которыми мы столкнулись, была признана успешной.

команда работающая над дизайн системой

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

Пример 3: простая библиотека для сайта

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

команда работающая над дизайн системой

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

Пример 4: экосистема цифрового проекта

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

команда работающая над дизайн системой

Через три месяца мы выпустили библиотеку v.1.0 и обновляли её раз в квартал с тем, чтобы улучшить настройку инструментов и расширить её каталог. Когда дизайнерскую, техническую и продуктовую команды собрали для обсуждения планов на 2017 год, вице-президент по техническому развитию похвалил систему: «Создание этой системы было самым важным, что мы сделали в прошлом году. Она будет являться основанием для всей нашей будущей работы».

Пример 5: создание библиотеки вместе с конкурентами

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

команда работающая над дизайн системой

Замедление работы произошло только на время перепроектирования кода, для того, чтобы он был удобнее для всех участников. Scrum-митинги и планирование стали, занимать больше времени. Тем не менее, в обозримом будущем наш путь вперёд будет единым, что, по-видимому, устраивает генерального директора и вице-президента: «Я предвидел и заранее смирился с тем, что у нас будут две библиотеки, но затем появилась и третья. Мне очень приятно видеть, что мы нашли способ создавать только одну».

Ещё одним способом улучшения стало использование объединённого дизайнерского сообщества в наших интересах: пользовательский опыт, иконки, бренд, графики, контент и удобство. В то время как ни у одного из специалистов, ответственных за выполнение конкретной части работы, нет узкоспециальных знаний, все их «участки работы» стали точками соприкосновения для дискуссий, расстановки приоритетов и вовлечения коллег .

Уроки, полученные во время управления командами, работающими над дизайн-системами

№1. Дизайн в коде это правильно. Соединяйте дизайн и инженерию

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

команда работающая над дизайн системой

Да, в условиях мирового масштаба есть проекты (пример: Google Material), в которых важна спецификация, а не код. Но, по моему опыту, объединение визуального языка, компонентов и других структур в создаваемый код реализует потенциальную эффективность системы, её ясность и лёгкость в сопровождении. Сухой остаток: независимо от того, кем является мой клиент, мой самый главный первый вопрос, кто и из каких отделов сможет работать вместе с нами для достижения нашей общей цели.

№2. Люди, работающие неполный рабочий день, это сила, а не слабость

Заметили общую черту, присущую всем командам, описанным выше? Все их сотрудники заняты только неполный рабочий день, а в остальное время занимаются продуктом. В команде среднего размера заняты сотрудники из 3-5 ключевых продуктовых команд. Это позволяет видеть, что требуется важным продуктам, и минимизирует возможность проявления предвзятости по отношению к какому-либо из них.

команда работающая над дизайн системой

Возможные риски:

  • Руководитель, на словах признающий систему неполного рабочего дня, но при этом ожидающий 32 и более часов в неделю работы над своим продуктом.
  • Члены команды, создающие множество противоречивых ритуалов (scrum-митинги, планирование, критический анализ), раздувающих время совещаний, вместо того, чтобы просто «делать дело». Сухой остаток: вы можете работать с людьми, занятыми не целый день, но ждите, что вам придётся их контролировать. Управлять каждым шагом. Чётко разделять две их работы и не сотрудничать с теми, кто нарушает обещание работать на вас. Всё будет сложно, но не настолько, чтобы как-то серьёзно испортить процесс.

№3. Найдите баланс между целостностью и заменяемостью

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

команда работающая над дизайн системой

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

№4. Воспринимайте периодическое сокращение команды как возможность

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

№5. Используйте новых сотрудников длятестирования системы

Новый сотрудник это прекрасный и простой способ протестировать ясность дизайна вашей системы, качество кода и приверженность заявленным по поводу неё обещаниям.

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

№6. Системные сотрудники должны расширять сеть контактов

Ваша система работает на одно, а не на несколько направлений бизнеса? Тогда на этой границе вы и должны искать сотрудников. Система охватывает отделы маркетинга и продукта? Тогда старайтесь, как минимум, развить стабильное, полноценное сотрудничество с ними обоими или (в идеале) наберите из них обоих сотрудников. Без специалистов в конкретных областях будет трудно создать систему и передать её куда-то туда другим командам на внедрение.