Команда для разработки дизайн-системы: кого взять и как масштабировать

Советы от основателя UX-агентства EightShapes Натана Кёртиса.

Многие ИТ-организации в конце концов приходят к пониманию необходимости создания дизайн-систем, однако порой это знание обходится им слишком дорого. Эффективное решение этой проблемы состоит в создании специальных «системных команд», которые обслуживают совокупность всех проектных направлений этой организации. Об этом пишут Питер Мерхольц и Кристин Скиннер в своей книге Org Design for Design Orgs:

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

Поэтому я был удивлён, прочитав выступление Питера на UI21, где он говорил, что такие команды были призваны «взломать организационный патч» в тех моделях, которые он описывал. Возможно, я что-то неправильно понял. За несколько лет мне удалось поработать примерно в 15-20 системных командах, и все они обслуживали другие подразделения своих предприятий схожим, хотя и не совсем одинаковым образом.

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

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

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

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

Сотрудники, работающие в системных командах в своё свободное время, часто рассказывали мне о том, как постепенно «сходило на нет» их страстное отношение к этой работе:

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

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

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

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

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

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

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

Команды, которыми я руководил, обычно состояли из сотрудников, обладающих следующими компетенциями:

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

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

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

Приведённые ниже примеры показывают, как менялись со временем модели моих системных команд.

Что было хорошо: наша сплочённая команда разрабатывала и документировала разнообразные стандарты для индивидуального веб-опыта. Это была дизайн-система в духе Big Kahuna: стиль, взаимодействие, компоненты, паттерны, бренд, редактура, SEO, доступность и непосредственно работа.

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

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

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

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

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

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

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

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

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

Что было хорошо: вместе с местным дизайнером мы разработали и задокументировали стиль и компоненты. При этом мы опирались на редизайн флагманского продукта, который сами же сделали кварталом раньше.

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

Мы выпустили библиотеку v1.0 за три месяца и возвращались к ней раз в квартал, чтобы отладить инструменты и расширить библиотечный каталог. Когда дизайнеры, инженеры и продуктовые лидеры составляли план на 2017 год, вице-президент компании очень тепло отозвался о нашей системе: «Создание дизайн-системы — это важнейшее достижение прошлого года. Она станет основой для всей нашей будущей работы».​

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

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

Другим следствием этого объединения стало привлечение внимания участников этого сообщества к собственным иконкам, брендам, графикам, контенту, пользовательскому опыту и доступности.

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

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

Да, бывают случаи (например, с Google Material), в которых дизайнерская спецификация имеет самостоятельное значение. Однако мой опыт показывает, что унификация визуального языка, компонентов и других структур в построенный код обеспечивает искомую эффективность, ясность и ремонтопригодность цифровых продуктов.

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

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

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

Это сопряжено со следующими проблемами:

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

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

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

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

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

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

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

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

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

#интерфейсы