Два подхода к дизайн-менеджменту

Привет! Я Ваня Соловьёв, дизайн-директор DocDoc. Сегодня я расскажу про подходы к дизайн-менеджменту и как они помогают мне в работе. Это текстовая версия моего выступления на прошедшей онлайн-конференции по дизайн-менеджменту.

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

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

Рассмотрим два подхода к управлению командой.

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

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

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

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

Хорошая метафора всего процесса: менеджер — дерево, а дизайнеры — яблоки. И задача менеджера — помогать «созревать яблокам», чтобы они самостоятельно достигали поставленных целей.

Для этого типа дизайн-менеджера важны два правила: самостоятельность превыше контроля и аргументы превыше авторитета.

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

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

Начнем с личности, с человека, а потом перейдем к команде.

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

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

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

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

Развитие софт-скиллов — это работа в первую очередь с личностью человека. Если «надавить», то человек может «закрыться» и будет непросто снова восстановить с ним нужный контакт. Поэтому помогать с развитием софт-скиллов нужно мягко и ненавязчиво. Сначала узнайте человека. Мне в этом помогают встречи 1 на 1, которые мы немного адаптировали для этого.

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

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

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

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

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

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

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

Давайте рассмотрим пару примеров развития софт-скиллов для понимания

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

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

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

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

Вторым примером будет навык, который превращает дизайнера из одиночки в командного игрока.

Иногда дизайнер трепетно относится к своему дизайну, как курица к яйцам. Он не покажет макет до тех пор, пока не доведет его «до идеального блеска». А когда покажет, то будет ревностно защищать каждый пиксель и бурно реагировать на критику.

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

Объясните дизайнеру, что ценность того, что он сделал, не в «красивых тенях и кнопочках», а в решении, которое лежит за этим визуалом. Сама суть дизайна в решении проблем. А макет дизайнера — это визуальный артефакт решения поставленной проблемы. Если решение сильное, то небольшие изменения в визуале никак не повлияют на саму идею.

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

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

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

В большинстве случаев не нужно прорабатывать решение тщательно с самого начала. Это затратно по времени и силам, а в итоге, можно не получить нужного решения.

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

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

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

И не забудьте собрать обратную связь на следующей встрече 1 на 1.

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

Чтобы избежать этого, мы ввели дизайн-синки — неформальные часовые встречи раз в неделю.

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

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

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

И да, никаких переговорок! 😉

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

Чтобы команда росла и развивалась, нужно задавать прозрачные векторы. Ребятам не нужно тратить свои ресурсы и время на мысли: «Как попросить повышения в зарплате?», «Хочу дальше развиваться, но не знаю куда и как?» и «Довольны ли мои коллеги моей работой? Если нет, то что можно улучшить?»

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

Наш главный инструмент — уровни в дизайне. Для дизайнера он решает вопросы «Как повысить себе зарплату?» и «Куда мне дальше развиваться?», а для компании «Как развивать дизайнера в нужном направлении?»

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

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

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

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