UX-стратегия на практике. Часть 4 — От дизайн-команды к дизайн-культуре

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

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

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

Статья написана для журнала UXmatters.

Что делать?

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

1. Команда. Важен её состав и принципы организации.
2. Лидеры. Важно их видение, полномочия и ответственность.
3. Культура. Её построение — залог долгосрочного и гармоничного развития дизайна.

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

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

Денис Петелин говорит, что компания до 10 человек управляется преимущественно делегированием задач; до 100 человек — делегированием ответственности; до 1000 — положительной бюрократией (процессы, показатели и цели); до 10 000 — ценностями и культурой. Все эти инструменты управления нужны компании любого размера, но фокус на каждом этапе роста разный.

Команда

Как подбирать

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

• Аналитика
• Пользовательские исследования
• Информационная архитектура и проектирование интерфейсов
• Визуальный дизайн
• Фронт-енд
• Контент-стратегия и копирайтинг
• Контроль качества
• Маркетинг и PR
• Управление проектами и продуктами
• Общие навыки

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

Правда, сейчас говорят уже о M-, E-, Pi- и [подставьте любую букву]-образных моделях, но принцип тот же — нужна связка дизайнеров, сильных в разных навыках. Тем более, что у дизайнеров всегда есть крен либо в сторону систематизации, либо в сторону креативных решений. Первый будет делать скучно, а у второго решения при масштабировании превращаются в монстра. По отдельности они будут упираться в свои собственные ограничения, но в связке сделают мощный рывок.

План действий в целом такой:

1. Определить текущий и желаемый профиль команды.
2. Выделить навыки, которые развиты слабо или отсутствуют.
3. Решить, как прокачать их у имеющихся дизайнеров или нанять новых.

Для понимания текущих возможностей команды в целом нужно оценить конкретные навыки каждого дизайнера (например, анимация интерфейсов или экспертная оценка). Здесь поможет классическая матрица навыков:

^{Матрица навыков и знаний. Скачать}

По каждому из наборов навыков я вижу четыре уровня:

1. Осведомлённость — понимание того, как работает специалист в этой области. Какие задачи выполняет, каков рабочий процесс и инструментарий, методы и практики, какие особенности и ограничения накладываются на него.
2. Умение — способность решать базовые задачи в области. Доделать не очень важный кусок работ за ведущим специалистом, собрать макет или прототип на основе чужих наработок, внести осмысленные доработки в существующий документ и т.п.
3. Экспертиза — выполнение большинства задач в области знаний. От начала до конца и, зачастую, самостоятельно. Способность разобраться в нетипичной ситуации.
4. Лидерство — способность передать экспертизу другим участникам команды. Помощь в обучении и профессиональном росте коллег, развитии инструментария и методов работы, повышении общей дизайн-культуры. Возможность указать на проблемную ситуацию в проекте или процессе и помочь в ее решении.

Nathaniel Davis рассказывал на UXmatters о похожем подходе:

^{Модель навыков Nathaniel Davis}

Близкое по духу используют в Intercom:

^{Модель навыков Intercom}

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

^{Матрица навыков и знаний с точками роста. Скачать}

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

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

Альтернативный метод планирования команды предлагает Nick Daze. У каждого дизайнера есть профессиональный профиль, показывающий владение набором навыков. По мере роста диаграмма занимает все большую площадь:

^{Навыки дизайнеров разного уровня}

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

^{Владение навыками в продуктовой команде в целом}

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

^{Сильные навыки в продуктовой команде в целом}

Общие ориентиры

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

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

Многие компании ставят ориентир по соотношению дизайнеров и разработчиков в компании. Само по себе количество голов ни о чем не говорит, но такие цифры могут быть еще одним индикатором зрелости. Leah Buley сделала мощное исследование принципов работы дизайн-команд и получила медиану в 1:6. У лучших компаний отмечается 1:4, а абсолютный минимум для гармоничного развития — 1:12. IBM говорит о похожих значениях — в среднем 1:8, хотя все зависит от сложности продукта; в новой команде мобильного приложения это может быть 1:4, а те, кто занимается сложным корпоративным ПО с большой серверной частью имеют 1:12; количество чистых фронт-ендеров примерно 1:1. По опыту IBM, недостаток дизайнеров заставляет разработчиков решать эти задачи.

Организация команды

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

1. Централизованный

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

Плюсы:

• Легче поддерживать консистентность между продуктами благодаря активному обмену наработками.
• Можно нанимать меньше людей. Продукты развиваются циклами, у дизайнера бывает сильная и слабая загрузка. Один человек может вести 2-3 проекта — один в активной фазе, остальное в поддержке.
• Активный обмен информацией внутри команды, так что дизайнеры профессионально растут с огромной скоростью.
• Дизайнеры в естественной среде, более мотивированы и их легче удержать.

Минусы:

• Дизайнер меньше вовлечён в продукт, потому что сидит отдельно от команды.
• Не все проекты получают дизайн вовремя из-за того, что дизайнер занимается сразу несколькими.

2. Погруженный

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

Плюсы:

• Лучшее погружение в продукт — дизайнер в деталях видит, что происходит во всех его аспектах (интерфейс, бизнес, технологии, ограничения).
• Более оперативная реакция на любые запросы. Повернуться и спросить что-то гораздо проще, чем пытаться выловить человека из другого кабинета. Который именно в эту секунду вышел позвонить.
• Чувство локтя с командой разработки. Участие во всех встречах и спонтанных беседах, понимание всех нюансов и болей.
• Можно заниматься не только срочными задачами, но и думать наперёд, чаще экспериментировать.

Минусы:

• Дизайнер медленнее растёт как дизайнер, поскольку обмен опытом с коллегами обрывочный. Сложно поддерживать равномерный уровень среди команд.
• Рассинхронизация дизайна продуктов. Общение между дизайнерами из разных команд не такое активное. Даже если есть авторитет снаружи, у него меньше полномочий на происходящее внутри чужой команды.
• Каждая команда заново постигает опыт ошибочных и успешных решений. Это еще одно следствие того, что общение команд не такое активное.
• Если дизайнер ушёл из компании, команда оголяется и дизайн стопорится до найма нового. А будучи вне близкой дизайнерской среды, он больше подвержен выгоранию и демотивации.
• Не все менеджеры умеют работать с дизайнерами и ещё больше нервируют их бессистемностью.

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

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

3. Распределённый

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

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

Часть продукта

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

… и кросс-функциональное взаимодействие

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

Общий язык

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

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

… и чувство локтя

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

Ответственность шире

Помимо продуктовых задач, каждый дизайнер берёт на себя ответственность по какой-то из частей общего стиля и логики работы интерфейса — тому самому общему языку.
Он отвечает за то, чтобы все продукты соответствовали гайдлайнам в определенном аспекте — по типу (визуальный язык, иконки и иллюстрации, рекламные форматы, анимация и т.п.), платформе (веб, мобильный веб, Android, iOS, Windows Phone, умные часы и т.п.), области (интерфейсные или процессные решения) или другому принципу. А значит плотно общается с дизайнерами из других команд. Для многих это первый управленческий опыт, который пригодится в будущем.

Ситуативные рабочие группы

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

Мобильность

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

… и комфортная рабочая среда

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

Дружбаны

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

Если подытожить преимущества и проблемы распределённого подхода:

Плюсы:

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

Минусы:

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

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

KPI

Использовать ли KPI для дизайнеров? Простой ответ — нет. Конечный специалист опосредованно влияет на выпуск продукта, ему сложно отвечать за общий результат. А если к этому ещё и привязывать зарплату, получится постоянный источник недовольства — влияние маленькое, а рублем бьют постоянно, причём часто за чужие факапы. В итоге это всё вырождается в искусственную конструкцию, которая даёт больше вреда, чем пользы.

А вот если давать дизайнеру менеджерские обязанности, то KPI будут уместны. Также полезны внутренние индикаторы здоровья команды — укладываемся ли в планы, нет ли нареканий по качеству. Для конкретного специалиста можно смотреть, развивается ли он, насколько часто факапит, готов ли потратить чуть больше сил, чем нужно, чтобы продукт вышел крутым и в срок. Но последнее — просто работа дизайн-менеджера, для которой никакие KPI не нужны.

Примеры

Хорошую концепцию командой работы предлагает James Kalbach — он приводит в пример джазовую импровизацию. Она строится на схожих принципах:

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

James наглядно проиллюстрировал это в своем мини-выступлении на TEDx:

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

Примеров будет очень много, поэтому можете пробежать этот кусок по диагонали.

Современные матричные структуры

Spotify

Гуру agile Henrik Kniberg и Anders Ivarsson проработали для компании интересную орг.структуру, где сотрудники делятся по 4 группам:

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

^{Модель команд Spotify}

Руководитель отдела (например, дизайна) — линейный менеджер для его сотрудников, который вовлечен в продуктовую работу, чтобы оставаться «в теме». У гильдий есть координаторы. Они — лидеры по компетенции и отвечают за то, чтобы каждый специалист делал свою работу хорошо. При этом менеджер продукта отвечает за то, что именно будет делать сотрудник, это внутренний предприниматель. Здесь есть внутренний конфликт — первые стараются сделать все правильно, вторые — быстро, но он как раз и позволяет находить баланс.

Twitter

Компания поделена на два типа команд — функциональные (профиль, медиа-контент, поиск и т.п.) и платформенные (веб, Android, iOS). Обновление попадает в продукт, только если обе согласны с решением. Т.е. функция одинаково работает на всех платформах, при этом не рушит их идентичность.

Adobe

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

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

Мультидисциплинарная дизайн-команда

MailChimp

При основании компании в 2008 году Aaron Walter был единственным дизайнером и он занимался вообще всем — проектированием и дизайном интерфейсов, фронт-ендом, пользовательскими исследованиями. Это помогло ему понять, как построить идеальную дизайн-команду — междисциплинарную, избегающую транзакционных издержек. В 2015 году в ней было 12 человек — 4 исследователя, 2 продуктовых дизайнера, 4 фронт-ендера, дизайнер почтовых рассылок и руководитель.

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

FiftyThree

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

Возможно, эта культура появилась у основателей еще в Pioneer Studios внутри Microsoft, где они работали над прототипом планшета Courier. Причем Andrew S. Allen, со-основатель Paper, говорит, что несмотря на примерно равное соотношение дизайнеров и разработчиков, они не дизайнерская компания — просто дизайн наконец-то имеет равную роль.

Распределённая экспертиза

Fruit Ninja

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

Централизация с внутренними подкомандами

Groupon

Дизайн-команда централизована, но внутри нее есть разделение по средам — веб, мобильные, маркетинг и т.п. И каждый из дизайнеров по возможности привязан к конкретному проекту. Они называют ее «централизованное партнерство». В нашей портальной дизайн-команде в Mail.Ru Group мы естественным путем пришли к похожей схеме работы.

^{Модель централизованного партнёрства Groupon}

Netflix

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

1. Мобильные и планшеты
2. Умные телевизоры и игровые консоли
3. Веб
4. Кросс-функциональная команда, сопровождающая выпуск собственных телешоу

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

Отдельная команда, распространяющая дизайн-культуру и дизайн-систему

Google

При работе над первым масштабным редизайном 2013 года, когда появился их фирменный плоский стиль под кодовым названием «Project Kennedy», была собрана небольшая рабочая группа UXA. После того как они нашли сильную визуально-интерфейсную концепцию, эта команда работала с дизайнерами из конкретных продуктов для ее внедрения. Сейчас связь между командой визуального языка и продуктами работает в обе стороны — дизайнеры на полях привносят в общий котел свежие паттерны и решения.

IBM

В рамках очередной волны трансформации компании, несколько лет назад было принято решение инвестировать в дизайн $100 млн и нанять до 1000 дизайнеров. Всего в компании 400 000 сотрудников и централизация экспертизы невозможна на практике. Была сделана ставка на лабораторию-инкубатор в Остине (Техас), которая занимается проработкой типовых процессов, визуальным языком, обучением. В итоге основная цель — повышение общей дизайн-культуры в компании, «продажа» ценности дизайна менеджменту разных уровней, проведение рабочих сессий и мастер-классов для передачи знаний и опыта. Один из инструментов для этого — менторство.

Vox Media

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

^{Формат работы разных дизайн-команд Vox Media}

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

^{Взаимодействие инфраструктурной и продуктовых дизайн-команд Vox Media}

У Nathan Curtis из EightShapes похожие мысли. Он сравнивает три модели — единственный владелец, централизованная команда и федеративное управление гайдлайнами. Третий подход наиболее правильный, но требует налаженного контакта между командами.

^{Модели инфраструктурной команды Nathan Curtis}

Тесная связка CEO и главы дизайна

Apple, Olivetti, Braun

Про внутреннюю кухню компании известно не так много, но долгое время одним из ключевых составляющих успеха считалась тесная связь CEO Steve Jobs и главного дизайнера Jony Ive. Они создают мощное видение идеального дизайна, вокруг которого строится вся работа. Интересно, что Olivetti и Braun, еще две компании, известные своим сильным дизайном, также полагались на такую связку. Но эта модель слишком зависит от силы и харизмы конкретных личностей, чтобы быть повторяемой.

Венчурные фонды и крупные консалтеры

За последние годы несколько сильнейших дизайнеров стали партнерами таких компаний — John Maeda (KPCB), Irene Au (Khosla Ventures), Jeffrey Veen (True Ventures), много интересного делает Google Ventures. Они работают с проинвестированными стартапами и помогают им выстроить системную работу по дизайну — от найма подходящих специалистов и выстраивания дизайн-процессов до работы над конкретными задачами и экранами.

Холакратия

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

А вот у Zappos эксперимент закончился внутренним кризисом — в первые недели после его запуска компанию покинуло 14% сотрудников. Холакратия призвана избежать проблем неэффективного менеджмента, но вместе с водой зачастую выплескивает и ребенка. Хороший менеджер — это в первую очередь лидер, который помогает своей команде расти и развиваться. Без него сотрудникам бывает сложно ставить высокие цели, отслеживать их достижение и в целом понимать ожидания компании.

Модель здоровой команды

Алексей Иванов и Дмитрий Волощук описали модель командного взаимодействия, похожую по сути на известную карту бизнес-модели Alexander Osterwalder. Это очень удобный инструмент для понимания того, кто вы и куда стремитесь. Проанализировав себя, будет гораздо проще выбирать подходящие форматы взаимодействия.

^{Модель командного взаимодействия Team Canvas}

Адаптивная стратегия

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

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

Лидеры

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

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

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

Видение...

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

… и запас Ново-Пассита

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

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

Компетентность в дизайне

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

… и зрелость в менеджменте

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

Подбор и развитие команды

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

Фасилитация и менторство

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

Ценит и хвалит команду

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

Лидер, а не босс

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

Базовые требования

Ну и, конечно, базовые требования — ответственность, системность, коммуникабельность, результативность, стрессоустойчивость и т.п. Отличную серию на эту тему пишут Jim Nieters и Pabini Gabriel-Petit (вторая часть).

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

Межпроектная рабочая группа

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

Нам нужны лидеры, отвечающие за разные уровни дизайна:

• Общее направление развития дизайна в компании и её продуктовой линейке.
• Уровень конкретных продуктов, как они будут развиваться.
• Уровень кросс-продуктовых решений по унификации дизайна (пиктограммы, анимация, письма рассылки и т.п.).

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

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

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

Культура

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

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

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

Проблематика

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

^{Карикатура про организационные модели известных компаний}

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

Хотя поменять всю структуру компании не в силах и не в компетенции дизайн-менеджеров, от решения многих организационных проблем зависит дизайн продуктов. Полезно опереться на модель проблем в работе команд Patrick Lencioni, известного теоретика менеджмента:

1. Недоверие из-за чувства незащищенности.
2. Боязнь конфликтов, которые бывают полезными, из-за стремления сохранить искусственную гармонию.
3. Недостаточная преданность делу из-за всеобщей неясности.
4. Безответственность из-за дискомфорта в общении.
5. Безразличие к результатам из-за погони за личными целями и статусом.

^{Модель проблем в работе команд Patrick Lencioni}

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

Какие проблемы дизайн-команда решит с внедрением здоровой дизайн-культуры?

Качество продуктов выше

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

Баги реализации дизайна — бич любого процесса разработки. Как уменьшить их?

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

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

Свежих мыслей больше

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

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

А если еще и вместе ходить на пользовательские исследования и тестирования, можно развить в коллегах эмпатию и чувство ответственности за дизайн-решения. И наглядно показать, как спорные предложения приводят к реальным проблемам. Ну а со временем научиться вместе искать выходы из таких ситуаций, зачастую прямо в лаборатории. Полезный индикатор для этого предлагает Jared Spool — «часы налёта» наблюдения за пользователями. Он рекомендует не меньше 2 часов в течение полутора месяцев для каждого сотрудника компании.

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

Сопротивление среды меньше

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

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

Здоровые привычки

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

Какие здоровые привычки помогут прочувствовать и принять ценности?

• Делиться знаниями. По профессиональной тематике, результатам запусков продуктов, аналитике и исследованиям.
• Принимать продуктовые решения совместно в связке менеджер продукта+дизайнеры+разработчики.
• Не критиковать коллег за ошибки, а делать выводы из проблемных ситуаций и не повторять их.
• Давать взвешенную обратную связь, отмечающую сильные и слабые стороны решений и подходов.
• Держать результаты своей работы открытыми и всегда доступными.
• Объяснять логику принятия решений в своей профессиональной области.
• Оперативно отвечать на вопросы коллег и помогать им решать проблемы с реализацией и развитием дизайна.
• Развивать горизонтальные связи — общение специалистов напрямую, минуя менеджеров.
• Устраивать парные рабочие сессии, когда дизайнер и специалист другой предметной области вместе решают задачу за компьютером.
• Чаще говорить об успехах дизайна и удачных внедрениях, а также позитивном вкладе дизайнеров. Мотивировать менеджмент компании, поддерживающий дизайн, активнее рассказывать об этом. Другие управленцы будут стремиться копировать этот опыт.
• Фиксировать принятые на встречах решения и придерживаться их. В идеале — описывать и отброшенные варианты, а также логику принятия решения.
• Всегда продолжать учиться и развиваться профессионально.

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

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

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

1. Радость важнее стресса.
2. Гибкость важнее структуры.
3. «Мы» важнее «я».
4. Несерьезность важнее серьезности.
5. Совместная работа важнее иерархии.
6. Смелость важнее комфорта.
7. Принципы важнее результата.

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

Ко-дизайн

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

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

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

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

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

При этом ко-дизайн и дизайн комитетом — разные вещи. Нужно минимизировать количество участников встреч до 3-5 человек. Большие встречи нужны только для сбора идей и требований/пожеланий, а также — презентации готовых концепций. Нельзя создавать концепцию большой группой людей. У рабочей группы есть ответственный, который собирает концепцию из полученных идей.

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

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

Дизайн-спринты

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

1. День 1: Подготовка. Обмен знаниями о проблеме, которые уже есть внутри компании; описание целевой аудитории и сценариев использования; планирование недели.
2. День 2: Скетчи. Наброски идей, их обсуждение и оценка.
3. День 3: Принятие решения. Определение того, какой из набросков пойдет в работу дальше.
4. День 4: Прототип. Создание прототипа решения.
5. День 5: Тестирование. Общение с потенциальными пользователями для проверки прототипа и отдельных идей.

Получается такая модель:

^{Дизайн-спринт от Google Ventures}

В отличие от дизайн-мышления, здесь пользовательские исследования вынесены отдельно. Формат называется «исследовательский спринт» и включает 4 дня:

1. День 1: Подбор респондентов.
2. День 2: Расписание и предварительный план интервью.
3. День 3: Финальное расписание и план интервью.
4. День 4: Проведение интервью и структурирование найденных инсайтов.

Дизайн-студии

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

1. Разогрев, в котором людей учат не бояться делать скетчи, даже если они не умеют рисовать.
2. Команды готовят максимальное количество набросков решения, после чего обмениваются ими.
3. Каждый выбирает наиболее интересную ему идею и прорабатывает ее в деталях.
4. Идеи сортируются по этапам customer journey.
5. Идеи обсуждаются, критикуются и защищаются.
6. Еще один этап доработки идей.
7. Рабочая группа голосует за идеи с помощью метода KJ.

Дизайн-мышление в упаковке

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

^{Модель «двойного алмаза» от British Design Council}

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

• «Горки». Описание проблемы с точки зрения идеального результата для целевой аудитории.
• Уточнение проблематики. Регулярные встречи дизайн-команды с заказчиками по ходу решения проблемы, причем на каждой последующей решение становится все более проработанным.
• Представители пользователей. Постоянное привлечение пользователей для оценки текущего состояния решения.

Внедрение практик ко-дизайна

Упакованные методологии требуют знания процесса и навыков фасилитации. Поэтому их распространение по компании — отдельная задача. Но для огромных организаций вроде IBM с 350 000 сотрудников это один из немногих инструментов, позволяющих распространить дизайн-культуру. Тем более, что так или иначе влияют на дизайн многие из этих сотен тысяч.

Проводя масштабные изменения в дизайне Intuit, дизайн-лидеры запустили программу «миссионеров» или «катализаторов» изменений. Внутри дизайн-команды регулярно проводились рабочие сессии и тренинги для специалистов из разных частей компании. Со временем они стали проводниками этих идей в своих подразделениях и смогли научить дизайн-мышлению гораздо большее количество коллег. Сейчас таких «катализаторов» уже 1200 и это оказало огромное влияние на качество дизайна и принятия решений в целом. Похожая инициатива успешно работает в компании Immersion — программа называется Sparks и в ней участвует 10% сотрудников.

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

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

Планирование

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

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

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

Обеспечение качества реализации дизайна

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

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

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

Инструменты

Необходимо выбрать и отладить оптимальный инструментарий для:

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

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

Работа с аутсорсерами

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

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

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

Профессиональный рост

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

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

Широкий круг задач

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

• Продуктовые. Работа над продуктами и их функциональностью.
• Инфраструктурные. Задачи по унификации дизайна и его отдельных составляющих — иконки, анимация, типографика, типовые экраны и паттерны, сетки и т.п.
• Визионерские. Как будут выглядеть продукты через пару лет? Какие необычные интерфейсные решения на рынке можно применить к основному продукту? Не факт, что концепты попадут в жизнь в чистом виде, но они здорово «опыляют» более приземленные решения. Это похоже на концепт-кары автопроизводителей, которые прощупывает будущие направления развития моделей марки.

Соотношение в нашей команде — 70%/20%/10%. Хотя основную часть занимает продуктовая работа, вызовов хватает и в ней. А ведь именно профессиональные вызовы двигают специалистов вперед и делают работу любимой. Зачастую это то, что сделано на пределе — возможных вариантов решения проблемы, знаний и навыков, времени и ресурсов.

Встречи бывают хорошими

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

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

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

Итого

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

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

Автор: Mail.Ru Group

Источник