[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-158433683", "adfox_url": "//ads.adfox.ru/228129/getCode?p1=bxbwd&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid21=&puid22=&puid31=&fmt=1&pr=" } } ]
{ "author_name": "Ирина Белова", "author_type": "self", "tags": ["\u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441\u044b","\u0434\u0438\u0437\u0430\u0439\u043d"], "comments": 1, "likes": 10, "favorites": 7, "is_advertisement": false, "section_name": "default", "id": "26661" }
Ирина Белова
1 142

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

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

Поделиться

В избранное

В избранном

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

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

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

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

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

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

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

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

Этапы роста системных команд

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

1. Совместители

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

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

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

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

2. Специально выделенные люди

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

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

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

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

3. Отдельная системная команда

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

Состав системных команд разного масштаба

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

  • Обязательно, чтобы команда смогла создать элегантный визуальный язык. Она должна включать в себя дизайнеров, специализирующихся на визуализации и взаимодействии, а также специалистов по информационной архитектуре.
  • Обязательно, чтобы ваши инженеры могли сфокусироваться на внешнем интерфейсе. Им понадобятся знания HTML и CSS, а также навыки создания инструментов и правил.​
  • Желательно: формулировать видение, определять направление движения, курировать дорожные карты, мониторить принятие и организовывать бэклоги, дискуссии и критику — всё это задачи продуктового менеджера и лидера.
  • Пригодится: вам могут потребоваться такие особые навыки, как умение работать с контентной стратегией, доступностью, производительностью, SEO и так далее. Но если вы ограничены в финансах, то знайте, что системы, прежде всего, нуждаются в сочетании дизайнеров и инженеров.
  • Скорее всего, не понадобится: без контроля качества и исследований вполне можно обойтись. Поскольку с финансированием QA часто возникают проблемы, лучше обеспечивать должное качество другим способом. А исследования могут проводить другие подразделения компании.

4. «Команда команд»

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

«Команда команд»

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

Примеры системных команд

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

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

1. Отзывчивый eсommerce

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

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

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

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

2. Язык дизайна для быстрорастущей организации

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

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

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

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

3. Библиотека сайтов

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

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

4. Экосистема цифрового продукта

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

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

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

5. Библиотека для конкурентов

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

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

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

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

Уроки, извлечённые из управления системными командами

1. Дизайн-код помогает совместной работе дизайнеров и инженеров

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

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

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

2. Половинная занятость — это не так уж плохо

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

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

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

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

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

3. Приготовьтесь к постоянной ротации членов системной команды

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

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

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

4. Периодические сокращения команды неизбежны

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

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

5. Адаптация новых участников — это тест на качество системы

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

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

6. Расширяйте свою «клиентскую базу»

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

#интерфейсы

Популярные материалы
Показать еще
{ "is_needs_advanced_access": false }

Комментарии Комм.

0 новых

Популярные

По порядку

Прямой эфир

Компания отказалась от email
в пользу общения при помощи мемов
Подписаться на push-уведомления