Андрей Богданов – Как сделать дизайнеров счастливыми (страница 9)

18

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

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

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

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

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

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

– вносить предложения по улучшению процессов и дизайна в компании;

– открыто обсуждать существующие проблемы и искать пути их решения;

– и, наконец, просто стать видимыми друг для друга.

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

Первый пример – внутреннее демо дизайна, которое проводится в МТС Финтех каждые две недели. На нем все дизайн-команды рассказывают о новых разработанных сценариях, демонстрируют макеты и делятся друг с другом обратной связью по ним. Таким образом, работа команд становится прозрачной: все дизайнеры компании знают, над чем работают их коллеги.

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

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

В комьюнити можно и нужно формировать рабочие группы.

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

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

Рабочие группы – это временные объединения дизайнеров, и они существуют в период решения конкретных проблем. Например, в ВТБ рабочая группа дизайнеров прорабатывала шаблоны клиентских анкет, которые необходимы многим командам: и кредитам, и вкладам, и картам. А в МТС Финтех я таким образом организовал разработку нужного всем чек-листа для описания задач.

Сообщества убивает токсичность.

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

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

Опишите проблему X