- PVSM.RU - https://www.pvsm.ru -
В первых трёх частях я описал общий подход к UX-стратегии [1], подходящего дизайнера для её реализации [2] и результат его работы [3]. Это развёрнутый манифест — куда и как нужно развиваться, чтобы стратегия заработала на всех трёх уровнях — оперативном, тактическом и стратегическом. Пора собрать это в работающий механизм, т.е. слаженную дизайн-команду. Как работать на оперативном уровне и достигать тактических успехов, чтобы приближаться к стратегическим целям компании?
Лет пять-семь назад я бы писал о рабочем процессе — какие этапы работ проходит дизайнерская задача, чтобы мы смогли понять, что и как делать, а после этого передать результат в разработку и по ходу процесса отслеживать качество реализации. Но последняя декада проходит под знаком перехода от водопадных моделей сначала к agile, а теперь и lean. Не то что бы смысл нашей работы изменился — нам все также важно понять, что нужно пользователям и найти удачное дизайн-решение для их потребностей. Но формат вовлеченности в производственный процесс и мировоззрение в целом радикально изменились.
Идёт постоянное изменение форматов взаимодействия и их подстройка под конкретный проект и задачу. Невозможно жёстко придерживаться идеального дизайн-процесса — мы должны быть адаптивными, как и современный веб. Выручают скорее ценности, на которые мы ориентируемся и которые разделяем с продуктовой командой.
Статья написана для журнала UXmatters [4].
Для того чтобы в современном мире получалось удачно вписываться в динамичный производственный процесс, а компания могла работать на рынке бодро, обновляя продукты и предлагая новые, нужно озаботиться тремя вещами:
Рабочий процесс создания дизайна также важен, но он стал гигиеническим требованием — это обязательное, но далеко не достаточное условие для сильной дизайн-команды. Он должен быть и должен быть продуманным. Но для успеха куда важнее общие ценности.
Процесс нужен как ориентир, а не бюрократическая обязаловка — это съедает время и мотивацию. Он будет часто меняться. Главное — хорошо вписаться в общую производственную цепочку. Если в ней есть проблемы, мешающие реализации качественного дизайна — нужно вмешиваться в сопутствующие процессы.
Денис Петелин говорит [5], что компания до 10 человек управляется преимущественно делегированием задач; до 100 человек — делегированием ответственности; до 1000 — положительной бюрократией (процессы, показатели и цели); до 10 000 — ценностями и культурой. Все эти инструменты управления нужны компании любого размера, но фокус на каждом этапе роста разный.
Во второй части я много рассказывал о продуктовом дизайнере — современном специалисте, который готов взять на себя ответственность за продукт и не ограничиваться каким-то одним титульным навыком (исследования, визуальный дизайн, информационная архитектура, проектирование взаимодействия и т.д.). Для сильной команды нужны именно такие люди — только так можно добиться стоящих результатов. Сейчас сложно нанять по сильному сфокусированному человеку для каждой специализации — высоки транзакционные издержки. Усложняется коммуникация, теряются детали, замедляется работа. Лучше иметь несколько человек более широкого профиля, которые вместе дадут правильную комбинацию навыков. Их общий набор [2] я описывал во второй части:
В общем, классическая Т-образная модель описания навыков. Brad Frost приводит отличную аналогию с ножками стола [6] — их должно быть несколько, чтобы конструкция не развалилась:
Правда, сейчас говорят уже о M-, E-, Pi- и [подставьте любую букву]-образных моделях [7], но принцип тот же — нужна связка дизайнеров, сильных в разных навыках. Тем более, что у дизайнеров всегда есть крен либо в сторону систематизации, либо в сторону креативных решений. Первый будет делать скучно, а у второго решения при масштабировании превращаются в монстра. По отдельности они будут упираться в свои собственные ограничения, но в связке сделают мощный рывок.
План действий в целом такой:
Для понимания текущих возможностей команды в целом нужно оценить конкретные навыки каждого дизайнера (например, анимация интерфейсов или экспертная оценка). Здесь поможет классическая матрица навыков:
Матрица навыков и знаний. Скачать [9]
По каждому из наборов навыков я вижу четыре уровня:
Nathaniel Davis рассказывал на UXmatters о похожем подходе [10]:
Модель навыков Nathaniel Davis
Близкое по духу используют в Intercom [11]:
Модель навыков Intercom
Для развития команды нужно понимать, какие цели стоят перед компанией, координироваться с долгосрочными планами по продуктам. Мы решаем проблемы бизнеса с помощью дизайна. В зависимости от их набора сейчас и в ближайшем будущем, нужно подбирать людей по комбинации опыта и навыков. Точки роста отмечаются в текущем профиле команды:
Матрица навыков и знаний с точками роста. Скачать [9]
Значит, нам нужно прокачивать существующую команду в этих направлениях или нанимать новых людей с таким опытом. А если наоборот, какие-то из навыков уже достаточно сильны, при найме новых дизайнеров тут можно снизить входящие требования — они смогут прокачать эти навыки внутри компании. Зато появится возможность выбирать людей с необычным опытом, который обогатит команду.
В целом очень важно делать так, чтобы навыки «растекались» внутри команды — сильные в каком-то направлении люди передают знания другим. Этому здорово помогает парная работа над задачами, а также ситуативные рабочие группы. Например, один из дизайнеров задает направление для нового подхода к иконкам приложений, а остальные учатся у него.
Альтернативный метод планирования команды [13] предлагает Nick Daze. У каждого дизайнера есть профессиональный профиль, показывающий владение набором навыков. По мере роста диаграмма занимает все большую площадь:
Навыки дизайнеров разного уровня
Похожая модель описывает продуктовую команду в целом — менеджеров продукта, дизайнеров и разработчиков:
Владение навыками в продуктовой команде в целом
Если профили всех сотрудников совместить, получится портрет команды в целом. Белое пятно в центре — это результат наложения навыков всех трех ключевых компетенций продуктовой команды, т.е. то, что знают и умеют все. John называет его индикатором её здоровья. Правда, для детализированного анализа навыков она мне не подошла — лепестковая диаграмма имеет слишком много лучей.
Сильные навыки в продуктовой команде в целом
Хотя я только что много говорил о подборе навыков, при поиске дизайнеров лучше фокусироваться не на них. Сильных специалистов можно зацепить интересными вызовами и сложными проблемами, а не похожим на любое другое объявление перечислением требований, поэтому делайте упор на них в описании вакансий. А уж про навыки вы всегда успеете поговорить на собеседовании и увидеть их в деле на тестовом. Очень хорошо об этом написал Jay Kaufmann [14].
Ещё один интересный аспект — это попадание дизайнеров во внутреннюю культуру. Крайне важно понимать, какие ценности разделяет новый сотрудник. Это здорово влияет на итоговый продукт, особенно для молодых компаний. С другой стороны, это не должно быть похоже на секту или армию с полным единомыслием — люди со свежим взглядом и отношением к работе способны усилить команду. Главное, чтобы эта свежая струя со временем влилась в общее видение, скорректировав его, а не начала расшатывать вас.
Многие компании ставят ориентир по соотношению дизайнеров и разработчиков в компании. Само по себе количество голов ни о чем не говорит, но такие цифры могут быть еще одним индикатором зрелости. Leah Buley сделала мощное исследование принципов работы дизайн-команд [15] и получила медиану в 1:6. У лучших компаний отмечается 1:4, а абсолютный минимум для гармоничного развития — 1:12. IBM говорит о похожих значениях [16] — в среднем 1:8, хотя все зависит от сложности продукта; в новой команде мобильного приложения это может быть 1:4, а те, кто занимается сложным корпоративным ПО с большой серверной частью имеют 1:12; количество чистых фронт-ендеров примерно 1:1. По опыту IBM, недостаток дизайнеров заставляет разработчиков решать эти задачи.
Второй вопрос — это организация команды. Как именно дизайнеры будут включены в общий производственный цикл. Наиболее привычных и понятных два — централизованный и погруженный. Оба подхода имеют свои плюсы и минусы.
По сути, мы создаем внутреннее дизайн-агентство, которое решает задачи сразу нескольких продуктов. Когда он работает:
Плюсы:
Минусы:
Классический формат для стартапов и многих продуктовых компаний — дизайнер находится внутри команды разработки. Плюсы и минусы тут во многом обратны централизованному подходу:
Плюсы:
Минусы:
Многие компании растут экстенсивно, поэтому логика выбора первого или второго варианта не всегда есть — просто так исторически сложилось. Поэтому в целях оптимизации со временем происходит переход от одной схемы к другой. В некоторых компаниях они и вовсе регулярно чередуются, но это вряд ли хорошая практика.
При этом в одной организации может существовать смесь подходов. Например, дизайнеры являются частью общей продуктовой команды, но юзабилити-лаборатория работает как централизованное агентство.
Централизованный и погруженный способы организации команды предполагают или/или — выбор одного из способов развития, со всеми их плюсами и минусами. Но что если взять лучшее из двух миров? Осознанно или нет, некоторые компании переходят к распределённому формату работы дизайн-команды и экспертизы в целом.
По сути это матричная система управления, примененная к дизайну. Дизайнер состоит в проектной команде и работает с продукт-менеджером. И в более вольной манере включен в функциональную, где есть либо конкретный дизайн-менеджер, либо рабочая группа дизайнеров из разных команд. Чем характерен формат?
Дизайнеры — часть продуктовой команды, находятся внутри неё. Это позволяет им глубоко понимать продукт, быстро реагировать на все запросы команды и накапливать авторитет на принятие сложных решений.
Хороший дизайн работает на всех уровнях — понимание проблем пользователей и целей бизнеса, проектирование и дизайн продукта, их добротное внедрение на практике, наполнение качественным контентом, умный маркетинг, заботливая поддержка пользователей, усиление бренда. Это те специалисты, с которыми нужно учиться взаимодействовать напрямую и выстраивать горизонтальные связи — только так итоговый продукт будет вызывать восхищение.
Залог того, что дизайнеры из разных команд смогут выдавать согласованные решения с единым визуальным стилем и принципами работы. Что можно считать таким языком?
Не посылать друг друга за спиной в потенциально конфликтной ситуации. Или даже подменить ушедшего из другой команды на случай чего.
Помимо продуктовых задач, каждый дизайнер берёт на себя ответственность по какой-то из частей общего стиля и логики работы интерфейса — тому самому общему языку.
Он отвечает за то, чтобы все продукты соответствовали гайдлайнам в определенном аспекте — по типу (визуальный язык, иконки и иллюстрации, рекламные форматы, анимация и т.п.), платформе (веб, мобильный веб, Android, iOS, Windows Phone, умные часы и т.п.), области (интерфейсные или процессные решения) или другому принципу. А значит плотно общается с дизайнерами из других команд. Для многих это первый управленческий опыт, который пригодится в будущем.
Сильный инструмент для решения общепродуктовых задач. Это временные команды, которые собираются по нужным навыкам исходя из конкретной проблемы. Это позволяет решать нетипичные задачи достаточно быстро и без перестройки орг.структуры.
Дизайнер условно привязан к рабочему месту. Он может работать в продуктовой команде или переезжать к другим дизайнерам для решения задач по всей продуктовой линейке.
Рабочее пространство должно помогать специалистам работать эффективно и креативно и в продуктовой команде, и в общедизайнерской среде. Это легкодоступные места для обсуждений и брейнштормов, демонстрации концептов и мудбордов, сбора идей и наработок.
Большое количество общих активностей между дизайнерами компании позволяет вариться в узкопрофессиональной среде, сохранять мотивацию и формировать те самые общие ценности. Обмен знаниями, пиво, общие задачи по унификации, брейнштормы на тему будущего развития и т.п.
Если подытожить преимущества и проблемы распределённого подхода:
Плюсы:
Минусы:
Также возникает конкуренция между продуктовыми задачами и общими по унификации продуктовой линейки. В зависимости от того, где сейчас сидит дизайнер (в продукте или с другими дизайнерами), зависят его неявные приоритеты — он считает эту рабочую группу более важной и уделяет ей больше внимания.
Использовать ли KPI для дизайнеров? Простой ответ — нет. Конечный специалист опосредованно влияет на выпуск продукта, ему сложно отвечать за общий результат. А если к этому ещё и привязывать зарплату, получится постоянный источник недовольства — влияние маленькое, а рублем бьют постоянно, причём часто за чужие факапы. В итоге это всё вырождается в искусственную конструкцию, которая даёт больше вреда, чем пользы.
А вот если давать дизайнеру менеджерские обязанности, то KPI будут уместны. Также полезны внутренние индикаторы здоровья команды — укладываемся ли в планы, нет ли нареканий по качеству. Для конкретного специалиста можно смотреть, развивается ли он, насколько часто факапит, готов ли потратить чуть больше сил, чем нужно, чтобы продукт вышел крутым и в срок. Но последнее — просто работа дизайн-менеджера, для которой никакие KPI не нужны.
Хорошую концепцию командой работы предлагает James Kalbach — он приводит в пример джазовую импровизацию [17]. Она строится на схожих принципах:
James наглядно проиллюстрировал это в своем мини-выступлении на TEDx:
Похожие вещи говорит и Baruch Sachs [18] — несмотря на всё планирование и стратегии, командам и руководителям бизнеса приходится постоянно импровизировать, поскольку окружающая технологическая и бизнес-среда постоянно меняются. И многие компании находят нестандартные подходы к работе дизайн-команд.
Примеров будет очень много, поэтому можете пробежать этот кусок по диагонали.
Гуру agile Henrik Kniberg и Anders Ivarsson проработали для компании интересную орг.структуру [19], где сотрудники делятся по 4 группам:
Модель команд Spotify
Руководитель отдела (например, дизайна) — линейный менеджер для его сотрудников, который вовлечен в продуктовую работу, чтобы оставаться «в теме». У гильдий есть координаторы. Они — лидеры по компетенции и отвечают за то, чтобы каждый специалист делал свою работу хорошо. При этом менеджер продукта отвечает за то, что именно будет делать сотрудник, это внутренний предприниматель. Здесь есть внутренний конфликт — первые стараются сделать все правильно, вторые — быстро, но он как раз и позволяет находить баланс.
Компания поделена на два типа команд — функциональные (профиль, медиа-контент, поиск и т.п.) и платформенные (веб, Android, iOS). Обновление попадает в продукт, только если обе согласны с решением. Т.е. функция одинаково работает на всех платформах, при этом не рушит их идентичность.
Команда Photoshop разбита на целостные команды [20], отвечающие за определенную функциональность продукта. Они называются «молекулы» и состоят из дизайнеров, разработчиков и менеджеров. Во многом это стало результатом перехода к бизнес-модели SaaS, когда вместо крупных релизов раз в пару лет продукт стал обновляться каждые полгода, а то и чаще.
Поскольку Photoshop предназначен для достаточно разнородной аудитории (фотографы, дизайнеры и другие креативные специалисты), исследователям важно было наладить быстрый канал для общения с пользователями и получения обратной связи от них. Продуктовые дизайнеры имеют доступ к этому сообществу в Slack и Facebook, так что могут проверять свои решения и искать еще не решенные проблемы.
При основании компании в 2008 году Aaron Walter был единственным дизайнером и он занимался вообще всем — проектированием и дизайном интерфейсов, фронт-ендом, пользовательскими исследованиями. Это помогло ему понять, как построить идеальную дизайн-команду — междисциплинарную, избегающую транзакционных издержек. В 2015 году в ней было 12 человек [21] — 4 исследователя, 2 продуктовых дизайнера, 4 фронт-ендера, дизайнер почтовых рассылок и руководитель.
Команда мобильна и люди регулярно пересаживаются к разработчикам, маркетологам и другим специалистам для решения определенной задачи. Кроме того, в офисе есть гостевое пространство, куда регулярно приезжают видные эксперты отрасли вроде James Victore и Brad Frost — это здорово заряжает дизайнеров. Вдобавок, сотрудники Mailchimp практикуют работу всех специалистов в отделе поддержки пользователей [22]. Такое стимулирование междисциплинарного общения здорово помогает развитию продуктов.
Компания выпускает популярное приложение Paper для рисования на iPad, которое известно своим интересным и вовлекающим интерфейсом, зачастую ломающим традиционные решения для подобных продуктов. Для этого им нужно часто прототипировать необычные подходы, так что в команде сразу три сильных дизайнера с неплохим опытом разработки [23], которые занимаются постоянными экспериментами. Не менее важна в этом контексте и роль пользовательского исследователя, который не только проверяет новые паттерны взаимодействия на практике, но и активно ищет еще не решенные проблемы.
Возможно, эта культура появилась у основателей еще в Pioneer Studios внутри Microsoft, где они работали над прототипом планшета Courier. Причем Andrew S. Allen, со-основатель Paper, говорит, что несмотря на примерно равное соотношение дизайнеров и разработчиков, они не дизайнерская компания — просто дизайн наконец-то имеет равную роль.
В прошлом году компания отказалась от роли дизайнера и уволила двух последних [24]. Руководство посчитало, что хороший дизайн — это фокус для компании, а значит за него должны отвечать все [25] — и художники, и разработчики, и остальные сотрудники. Хотя на вид шаг выглядит противоречивым, это важное изменение внутренней культуры, которая должна стать залогом добротных продуктов. А для того чтобы она заработала и качество было на уровне, есть «тренер» по дизайну.
Дизайн-команда централизована, но внутри нее есть разделение по средам [26] — веб, мобильные, маркетинг и т.п. И каждый из дизайнеров по возможности привязан к конкретному проекту. Они называют ее «централизованное партнерство». В нашей портальной дизайн-команде в Mail.Ru Group мы естественным путем пришли к похожей схеме работы.
Модель централизованного партнёрства Groupon
Дизайн-команда сидит отдельно от разработчиков, но они регулярно ходят на стендап-встречи, где обсуждают все возникающие вопросы и могут видеть общую картину. Внутри отдела 4 группы [27]:
Явных приставок «ведущий», «младший» у дизайнеров нет — уровень оценивается по вкладу в работу, в то время как приставки могут ограничивать и демотивировать. Хотя у кого-то из специалистов есть крен в сторону визуальной части или проектирования интерфейсов, они называют себя продуктовыми дизайнерами, ведь все в той или иной степени влияют на продукт.
При работе над первым масштабным редизайном 2013 года, когда появился их фирменный плоский стиль под кодовым названием «Project Kennedy», была собрана небольшая рабочая группа UXA [28]. После того как они нашли сильную визуально-интерфейсную концепцию, эта команда работала с дизайнерами из конкретных продуктов для ее внедрения. Сейчас связь между командой визуального языка и продуктами работает в обе стороны — дизайнеры на полях привносят в общий котел свежие паттерны и решения.
В рамках очередной волны трансформации компании [29], несколько лет назад было принято решение инвестировать в дизайн $100 млн и нанять до 1000 дизайнеров [30]. Всего в компании 400 000 сотрудников и централизация экспертизы невозможна на практике. Была сделана ставка на лабораторию-инкубатор в Остине [31] (Техас), которая занимается проработкой типовых процессов, визуальным языком, обучением. В итоге основная цель — повышение общей дизайн-культуры в компании, «продажа» ценности дизайна менеджменту разных уровней, проведение рабочих сессий и мастер-классов для передачи знаний и опыта. Один из инструментов для этого — менторство.
Дизайн-команда издательского дома [32] пробовала разные форматы — полноценная продуктовая команда для каждого сайта, централизованный отдел, перед тем как остановиться на текущем, совмещающем куски из всего этого. Изменения в подходах зачастую вызваны насущными проблемами текущего этапа жизненного цикла компании — по мере решения больших задач старые системы оказывались уже неэффективными.
Формат работы разных дизайн-команд Vox Media
В итоге команды внутренних инструментов и приложений централизованы, а дизайнеры конкретных сайтов находятся внутри продуктовой разработки. Благодаря этому получается плодотворное взаимодействие — люди в полях часто экспериментируют, а команда инструментов делает для наиболее успешных экспериментов общие для всех решения. Чтобы коммуникация между ними оставалась тесной, они проводят ежедневные стенд-апы, еженедельные ретроспективы, регулярные ревью кода и критику дизайна.
Взаимодействие инфраструктурной и продуктовых дизайн-команд Vox Media
У Nathan Curtis из EightShapes похожие мысли [33]. Он сравнивает три модели — единственный владелец, централизованная команда и федеративное управление гайдлайнами. Третий подход наиболее правильный, но требует налаженного контакта между командами.
Модели инфраструктурной команды Nathan Curtis
Про внутреннюю кухню компании известно не так много, но долгое время одним из ключевых составляющих успеха считалась тесная связь CEO Steve Jobs и главного дизайнера Jony Ive. Они создают мощное видение идеального дизайна, вокруг которого строится вся работа. Интересно, что Olivetti и Braun, еще две компании, известные своим сильным дизайном, также полагались на такую связку. Но эта модель слишком зависит от силы и харизмы конкретных личностей, чтобы быть повторяемой.
За последние годы несколько сильнейших дизайнеров стали партнерами таких компаний — John Maeda (KPCB), Irene Au (Khosla Ventures), Jeffrey Veen (True Ventures), много интересного делает Google Ventures [34]. Они работают с проинвестированными стартапами и помогают им выстроить системную работу по дизайну — от найма подходящих специалистов и выстраивания дизайн-процессов до работы над конкретными задачами и экранами.
В последнее время все чаще встречается упоминание экспериментов с холакратией — когда в компании нет формального менеджмента. Это работает с переменным успехом — например, Valve, Medium и Buffer развиваются успешно [35]. У них свои нюансы организации команд — полная самоорганизация, деление по направлениям или менторство.
А вот у Zappos эксперимент закончился внутренним кризисом [36] — в первые недели после его запуска компанию покинуло 14% сотрудников. Холакратия призвана избежать проблем неэффективного менеджмента, но вместе с водой зачастую выплескивает и ребенка. Хороший менеджер — это в первую очередь лидер, который помогает своей команде расти и развиваться. Без него сотрудникам бывает сложно ставить высокие цели, отслеживать их достижение и в целом понимать ожидания компании.
Алексей Иванов [37] и Дмитрий Волощук описали модель командного взаимодействия [38], похожую по сути на известную карту бизнес-модели Alexander Osterwalder. Это очень удобный инструмент для понимания того, кто вы и куда стремитесь. Проанализировав себя, будет гораздо проще выбирать подходящие форматы взаимодействия.
Модель командного взаимодействия Team Canvas
В разные периоды жизни дизайна в компании нужны разные подходы. На старте часто не обойтись без жесткого формата, когда дизайн-команда замыкает почти всё на себя. Вас мало и не хватает на всех, а процессы и другие базовые вещи еще не налажены. А по мере взросления постепенно переходить к распределённому, вовлекая в принятие решений по дизайну всю компанию.
Сразу запустить его сложно — требуется отладка базовых процессов (проведение задач, обеспечение качества, визуальный язык), выстраивание взаимопонимания с продукт-менеджерами и топ-менеджментом, повышение общей дизайн-культуры.
И самое главное — нужны дизайн-лидеры, которые способны осознать важность правильного подхода и выстроить его, понимая детали работы бизнеса и орг.структуры конкретной компании.
Многим приходит на ум фигура вроде Джонни Айва. Но на практике единый «король дизайна» в компании не всегда получается и не всегда нужен. По мере роста организации объем задач становится настолько обширным и масштабным, что один человек вряд ли сможет потянуть это. Во-первых, для принятия осмысленных решений требуется достаточно глубокое погружение в текущие задачи. А даже с десятком продуктов это крайне сложно. Во-вторых, человек, который находится вне продуктовой команды, имеет ограниченное влияние на неё — текущие продуктовые задачи обычно в большем приоритете.
Один из выходов — разделение функций дизайн-менеджера и арт-директора. Первый отвечает за управление и развитие команды, второй задает направление для дизайна продуктов и помогает масштабировать его. Это снижает нагрузку и лучше фокусирует обоих.
Хотя для больших компаний этого всё равно недостаточно. Поэтому правильнее говорить о локальных лидерах, отвечающих за свой участок и координирующихся друг с другом. Можно начать с качеств, которые важны для них:
Обладает видением того, куда должен развиваться дизайн, вдохновляет им и проводит его в жизнь. Как в плане конкретных решений и гайдлайнов, так и в плане практик и методов, процессов. Способен представить, как будет работать компания через пару лет, и не боится тягот и лишений в годы внедрения. Причем не факт, кто его кто-то просил об этом — он сам увидел проблемы в процессах или продуктах и нашел время и возможность заняться ими.
Часто большие изменения затрагивают разного рода тяжелое наследие. При этом вся компания давно хочет их поменять, но мало у кого хватает сил взяться за дело и решить эту тысячу мелких проблем. Многие перегорают на этом пути, а надо стиснуть зубы и идти дальше.
Тут можно нажить себе внутренних врагов, даже если у лидера и не было цели провоцировать конфликты — немного политики есть в любой компании. Но если действовать аккуратно: проявляя эмпатию, понимая специфику работы и текущие проблемы коллег — найти союзников станет проще.
Это, казалось бы, само собой разумеющееся требование, но так бывает не всегда. Либо компания назначает не самого сильного в предметной области специалиста, либо он сам со временем теряет навык и не следит за развитием профессии. А без этого сложно получить уважение команды и добиться хорошего дизайна продуктов. Быть лучше всех во всех навыках необязательно и вряд ли возможно — надо брать людей умнее себя. Но базовая компетентность нужна.
По мере внедрения изменений в компании будет меняться спектр задач и проблем, которые стоят перед дизайн-командой и организацией в целом. Бывают удачные периоды и не очень, спокойные и полные неопределенности. Так что помимо профессионального развития нужно держать себя в форме и как менеджер, оставаясь релевантным.
Собирает сильную в своей профессиональной области и нацеленную на решение проблем бизнеса команду. А затем помогает дизайнерам делать интересную работу и расти, оставаясь бодрыми и мотивированными. Если специалисты остаются в компании после минимальных полутора-двух лет и продолжают расти — это хорошая работа менеджера.
Помогает менеджерам и разработчикам лучше и правильнее взаимодействовать с дизайнерами. А самой дизайн-команде — самостоятельно доводить свои идеи и решения до внедрения. Причем со временем это должно становиться частью общей культуры — не всегда можно и нужно участвовать во всех задачах, встречах и обсуждениях. Важно, чтобы за их результат не было стыдно даже без участия лидера с сильным видением и опытом.
В продуктовой работе хватает успехов, провалов и просто рутины. Критически важно отмечать заслуги коллег и мотивировать на их повторение, разбирать и не повторять ошибки. Кроме того, лидера слышно чаще, чем дизайнеров, поэтому заслуги часто приписывают ему, даже против его желания. И чем больше он отмечает конкретных дизайнеров, тем сильнее воспринимается команда в целом.
Имеет видение хорошего дизайна и проводит его в жизнь, создавая подходящую среду и процессы, вдохновляя на изменения, а также решая проблемы и конфликты. При этом не занимается микро-менеджментом, а дает команде автономию, ресурсы и возможности, чтобы видение стало реальностью. Ну а если вдруг все заняты или кто-то заболел — может сделать нужную работу руками сам. Степень успешности такого лидера — не количество успешно отданных приказов, а сила, самостоятельность и успешность его команды. Он на передовой, а не в кабинете.
Ну и, конечно, базовые требования — ответственность, системность, коммуникабельность, результативность, стрессоустойчивость и т.п. Отличную серию на эту тему пишут Jim Nieters и Pabini Gabriel-Petit [39] (вторая часть [40]).
Незрелые менеджеры часто думают о своей незаменимости — мол, если компания отпустит его, все развалится. Особо обидчивые даже начинают гадить, если отношения закончились не так, как хотелось. Это недальновидный и слабохарактерный ход мыслей. Если лидер действительно верит в то, что делает, то выстроит процессы и команду так, чтобы его видение продолжало внедряться и после его ухода. Иначе все усилия были бесполезны и он просто зря потратил несколько лет своей профессиональной жизни.
Одному лидеру сложно эффективно работать на всех трёх уровнях — оперативном, тактическом, стратегическом. Каждый из них требует мощного погружения для того чтобы добиваться сильных результатов. А ещё — немного противоречит остальным. Например, дизайнер на оперативном уровне стремится сделать макет идеальным. Хотя на стратегическом уровне возникает вопрос, сможем ли мы внедрить эту функцию в ближайшее время и нужен просто грубый набросок для прощупывания почвы. Один человек может балансировать в этом, но всегда будут перекосы.
Нам нужны лидеры, отвечающие за разные уровни дизайна:
Один из главных теоретиков менеджмента Ицхак Адизес предлагает модель PAEI для характеристики менеджеров. Для успешного управления компанией нужны четыре составляющих — производство, администрирование, предпринимательство и интеграция. Однако конкретный менеджер сам по себе склонен только к некоторым из них, так что не может эффективно закрыть все потребности организации. И нужна связка нескольких управленцев для того, чтобы компания жила и росла гармонично.
Если помнить, что лидер — это в первую очередь функция, а уже потом позиция, то можно не городить сложную иерархическую структуру. Закрыть все три уровня дизайна в компании сможет эффективная межпроектная рабочая группа. Все боятся обособленности внутри организации на уровне функций. Но обособленность на уровне продуктов также плоха для компании с их портфелем. Поэтому такая рабочая группа хорошо сработает для создания и внедрения единых гайдлайнов по всей продуктовой линейке.
В общем, как и для организации участников дизайн-команды, для эффективного взаимодействия дизайн-лидеров внутри компании нужны отдельные подходы и форматы.
Если построить здоровую дизайн-культуру с правильными ценностями, она сама вынесет качество продуктов на новый уровень. Тогда вашей дизайн-командой станет вся компания, которая всей своей массой будет двигать уровень дизайна вперёд. Это должно быть общее видение, которое разделяют все и каждый старается воплотить его на своём уровне.
Мы должны достучаться до каждого менеджера, разработчика, тестировщика, маркетолога. Объяснить, что и зачем мы делаем в плане дизайна; каких целей хотим добиться и куда идём; что важно учитывать всегда, а где пройденные не одной сотней организаций грабли. Они должны понимать, что мы делаем и почему, чтобы быть на нашей стороне и поддерживать нас.
По мере этой работы с не-дизайнерами возникнет эмпатия и у дизайнеров к ним. А значит связи внутри компании станут в целом теснее и полезнее. Разработчики будут охотнее рассказывать об используемых технологиях и ограничениях, менеджеры — чаще делиться дорожными картами, да и сами дизайнеры сильнее проникнутся уважением друг к другу. Прозрачность работы повысится, доверия станет больше во все стороны, а мелких косяков меньше, так что каждый из нас сможет сфокусироваться на более высокоуровневых задачах.
Осознанно или нет, определенная культура взаимоотношений и продуктовой работы в любой компании есть. Про какие-то из них рассказывают вдохновлённые истории, какие-то изображают в карикатурах.
Карикатура про организационные модели известных компаний
В стартапах всё проще — тяжёлого наследия нет и можно сразу внедрять здоровые ценности. Но у них нет и времени на это, так что в большинстве существующих организаций придётся постараться. Закон Conway [41] говорит, что компания воспроизводит свою собственную орг.структуру в дизайне продуктов. Зачастую это продукт хаотичного роста и реорганизаций, многих компромиссов, кризисов и вынужденных решений, которые скапливаются в организационный долг [42].
Хотя поменять всю структуру компании не в силах и не в компетенции дизайн-менеджеров, от решения многих организационных проблем зависит дизайн продуктов. Полезно опереться на модель проблем в работе команд Patrick Lencioni [43], известного теоретика менеджмента:
Модель проблем в работе команд Patrick Lencioni
Она помогает понять, почему дизайнеры сталкиваются со странным или прохладным отношением коллег при попытке продвигать сложные, но важные решения. А это уже полпути к успеху.
Какие проблемы дизайн-команда решит с внедрением здоровой дизайн-культуры?
Если обучить менеджеров, разработчиков, тестировщиков, маркетологов и других специалистов базовым правилам и принципам хорошего дизайна, то они смогут отличать хорошее от плохого и быть нашими глазами и руками на своём уровне — как минимум не допускать ошибок самим, а ещё лучше — показывать нам на наши недоработки.
Баги реализации дизайна — бич любого процесса разработки. Как уменьшить их?
Роли и специализации в продуктовой команде в любом случае пересекаются — верстальщик поможет решить ошибку дизайнера, а дизайнер — то, что забыл менеджер продукта. Для этого нужно понимать специфику работы смежных ролей в продуктовой команде, самому выступать ментором и источником знаний для них. И самое главное — не лютовать с авторитаризмом в принятии решений, впуская на свою профессиональную территорию коллег из других профессий. В слабо интегрированных командах это источник затыков, но ведь от этих пересечений можно извлекать пользу — каждый повышает качество работы коллеги, а значит и всего продукта.
Культура поможет и при проработке новой функциональности или продуктов. Подходы к проведению рабочих сессий, более качественные предложения и осведомленность о трендах — это всё сделает не-дизайнеров более полезными.
Важно организовать обмен знаниями. Мы знаем очень много о пользователях и их работе с интерфейсами. Во многом за это нас ценят менеджеры и разработчики. Паттерны и лучшие практики, методы и техники, гайдлайны и стандарты, истории успешных и провальных запусков, исследования и факты — всем этим нужно делиться с коллегами, а еще лучше собирать для последующего использования. Aaron Walter рассказывает о системном подходе MailChimp [44] по систематизации знаний о пользователях и дизайне.
А если еще и вместе ходить на пользовательские исследования и тестирования, можно развить в коллегах эмпатию и чувство ответственности за дизайн-решения. И наглядно показать, как спорные предложения приводят к реальным проблемам. Ну а со временем научиться вместе искать выходы из таких ситуаций, зачастую прямо в лаборатории. Полезный индикатор для этого предлагает Jared Spool — «часы налёта» наблюдения за пользователями [45]. Он рекомендует не меньше 2 часов в течение полутора месяцев для каждого сотрудника компании.
Конечно, разработчик или менеджер не сможет и не должен знать весь объем знаний по дизайну. Но чем выше их базовый уровень — тем проще вам общаться на одном языке. Да и договориться по сложным вопросам станет легче. При этом дизайнеры не станут ненужными — наоборот, за счет общего понимания проблематики их ценность в глазах коллег вырастет.
Команда получает авторитет и кредит доверия. К ней постоянно прислушиваются, приходят с проблемами, а не готовыми решениями. Причем не только менеджеры, но и конечные специалисты — разработчики, верстальщики, тестировщики. Это развивает горизонтальные связи, критичные для долгосрочного успеха. Помните, что вы команда не только среди дизайнеров, но и со всей компанией.
Совсем избавиться от конфликтов невозможно — коллеги всегда будут искать более простой и дешевый способ реализации задач, а время будет поджимать и не давать сделать задуманное. Но их частота и накал будут постоянно снижаться.
Изменение культуры идёт через изменение отношения и поведения в компании относительно дизайна. Лучше начать с внедрения правильных практик и здоровых привычек, которые приведут к новым ценностям. Полезно сформулировать список таких привычек и начать регулярно культивировать их. Тем более, что компания ждёт от нас в первую очередь результатов, а не просто масштабной организационной движухи, так что действовать всё равно придется малыми победами. Кстати, для начала они должны быть поддержаны внутри дизайн-команды — сложно пропагандировать ценности, которые вы не разделяете сами.
Какие здоровые привычки помогут прочувствовать и принять ценности?
Этот список можно продолжать вещами, важными именно для вашей компании. Задача дизайн-команды — постоянно напоминать об этих хороших практиках, пока они не дойдут до автоматизма.
Этот процесс не очень быстрый — чтобы привычка приживалась, нужно приличное количество времени. При этом выдавать результат вам нужно здесь и сейчас, не дожидаясь оздоровления обстановки. К сожалению, на ранних этапах можно растерять часть дизайн-команды — не все готовы пройти через тяжелый ранний период хаоса. Но чем здоровее становится культура, тем более сильных специалистов можно привлечь и тем мотивированнее будет вся команда.
Всегда полезно посмотреть на то, какие привычки и ценности продвигают известные дизайн-команды. Например, ustwo придерживается следующих принципов [46]:
Spotify говорят, что здоровая культура поможет сгладить проблемы в процессе. Это правильный баланс между хаосом и бюрократией.
Один из лучших способов прокачки дизайн-культуры. Любая более-менее серьезная функциональность, а тем более новый продукт, продумываются небольшой рабочей группой — менеджер продукта, дизайнер, ведущий разработчик. Это мини-воркшоп, на котором:
В результате мы выходим оттуда с готовым решением, которое учитывает все требования и ограничения. Либо несколькими альтернативными путями, которые мы хотим проверить. Это лучше бессмысленного пинг-понга, когда дизайнер и менеджер общаются внутри таск-менеджера, недопонимая друг друга и генерируя тонны ненужных комментариев и артефактов.
Менеджеры и разработчики чувствуют себя соавторами решения. Они будут биться за него, а не пытаться поменять при первой возможности. Они видят всю цепочку принятия дизайн-решений, отброшенные варианты, а также предлагают свои идеи — зачастую действительно сильные. И лучше понимают, как думает и работает дизайнер. Нет больше героя-одиночки, который спустился с высоты своего положения и выдал магически работающее решение — дизайн сделан командой.
Да и сами дизайнеры перестают биться до потери пульса за своё решение — нет необходимости доказать всем, что вы умнее остальных. О вас будут судить по успеху продукта в целом, а не по конкретным мелочам в интерфейсе.
При этом ко-дизайн и дизайн комитетом — разные вещи. Нужно минимизировать количество участников встреч до 3-5 человек. Большие встречи нужны только для сбора идей и требований/пожеланий, а также — презентации готовых концепций. Нельзя создавать концепцию большой группой людей. У рабочей группы есть ответственный, который собирает концепцию из полученных идей.
Некоторые компании практикуют ко-дизайн с пользователями — это отличная возможность получить обратную связь быстрее и усилить эмпатию. Похожие идеи продвигают lean-исследования, а в Скандинавии подход используется с 1960х годов.
Есть несколько упакованных форматов ко-дизайна — дизайн-спринты, дизайн-студии и другие вариации на тему дизайн-мышления. Причем их практикуют не только продуктовые компании, но и современные агентства, которые активно вовлекают клиента в работу.
Пятидневный формат командной работы для концептуального проектирования продукта [47] от Google Ventures. Их версия дизайн-мышления, упакованного под конкретные задачи — подход отлично справляется с задачей помочь молодым стартапам, в которые инвестировал фонд.
Получается такая модель:
Дизайн-спринт от Google Ventures
В отличие от дизайн-мышления, здесь пользовательские исследования вынесены отдельно. Формат называется «исследовательский спринт [48]» и включает 4 дня:
Однодневная или двухдневная рабочая сессия [49], в которой участники делятся на команды и работают над решением продуктовых проблем. Основные этапы:
Классический формат дизайн-мышления из пяти этапов от Стенфорда и IDEO известен всем — эмпатия, постановка проблемы, выдвижение идей, прототипирование и тестирование. Одна из ключевых идей — чередование этапов расхождения (изучение пространства проблем и решений) и схождения (выбор наиболее подходящих вариантов). Полностью или частично его практикуют огромное количество компаний и это самый популярный способ вовлечения не-дизайнеров в процесс создания дизайна.
Модель «двойного алмаза» от British Design Council
Некоторые переупаковывают его под свои задачи и одна из самых ярких версий получилась у IBM [50]. Общая схема плюс-минус одинакова — состоит из наблюдения, рефлексии и делания через думание руками. А вот привязка к рабочему процессу очень интересна — как раз на этом этапе многие и теряют интерес к дизайн-мышлению, поскольку в чистом виде применить его сложно. У IBM есть три ключевых инструмента для этого:
Упакованные методологии требуют знания процесса и навыков фасилитации. Поэтому их распространение по компании — отдельная задача. Но для огромных организаций вроде IBM с 350 000 сотрудников это один из немногих инструментов, позволяющих распространить дизайн-культуру. Тем более, что так или иначе влияют на дизайн многие из этих сотен тысяч.
Проводя масштабные изменения в дизайне Intuit, дизайн-лидеры запустили программу «миссионеров» или «катализаторов» изменений [51]. Внутри дизайн-команды регулярно проводились рабочие сессии и тренинги для специалистов из разных частей компании. Со временем они стали проводниками этих идей в своих подразделениях и смогли научить дизайн-мышлению гораздо большее количество коллег. Сейчас таких «катализаторов» уже 1200 и это оказало огромное влияние на качество дизайна и принятия решений в целом. Похожая инициатива успешно работает в компании Immersion — программа называется Sparks и в ней участвует 10% сотрудников.
Процесс?
Большая часть моей статьи говорит о том, что нужно быть гибким и избегать лишней бюрократии. Но какие-то процессы нужны в любом случае — это обязательное условие для продуктивной работы команды, хотя больше не достаточное.
Нужно определить ключевые этапы работ по типовым задачам — от создания концепции нового продукта до поддержки существующих. Они будут ориентиром, из которого для каждой конкретной ситуации подбирается план действий.
В централизованной команде необходимо вести его на краткосрочной, среднесрочной и долгосрочной дистанциях:
В распределенном формате всё идет от продукта — основные планы задаются его менеджером, но в идеале это те же три уровня. А клуб дизайн-менеджеров исходит уже из них, добавляя общие задачи по унификации продуктовой линейки.
Нужен стандартизированный механизм контроля качества выпускаемых продуктов. Дизайн-ревью для проверки точности реализации дизайна, оценка юзабилити, аналитика на соответствие поставленным бизнес-задачам. В идеале — возможность отложить выпуск фичи, если её качество не фонтан. Полезные инструменты:
Важно то, как проводятся пользовательские исследования и организована работа с аналитикой, но это особенности конкретных компаний, которые за рамками этой статьи.
Необходимо выбрать и отладить оптимальный инструментарий для:
Вместе со стандартами именования файлов, слоёв и других общих штук это поможет работать быстрее и сжигать меньше времени на оперирование.
Полезно создавать проверенный пул, чтобы быстро запускать работу. Зачастую это проблема — пока найдёшь, пока договоришься, пока пройдут все юридические формальности и проверки…
Проблема многих компаний в работе с аутсорсерами — мало кто знает, как их правильно использовать. Из-за этого плохой результат и взаимные обиды. Для продуктовой компании рискованно отдавать задачи, определяющие сам продукт — это чревато кучей итераций и взаимным недовольством (хотя некоторые современные агентства научились работать в этом формате). Я вижу три здравых подхода:
Команда должна постоянно расти и развиваться, чтобы дизайнеры становились сильнее и мудрее, а значит готовы отвечать на новые вызовы и решать все более сложные задачи. Для этого нужны:
Чтобы дизайнеры не закисали в рутине и смотрели в разные стороны, нужно регулярно переключать их от основных проектных задач. Мы делим задачи на три типа:
Соотношение в нашей команде — 70%/20%/10%. Хотя основную часть занимает продуктовая работа, вызовов хватает и в ней. А ведь именно профессиональные вызовы двигают специалистов вперед и делают работу любимой. Зачастую это то, что сделано на пределе — возможных вариантов решения проблемы, знаний и навыков, времени и ресурсов.
Их часто демонизируют, говорят что это губитель всего живого. Всё верно, если собирается десяток человек. На такой встрече каждый вполне здраво считает, что раз он здесь — от него ждут активного участия. И предлагает свои идеи (зачастую без погружения в проблему), которые в сумме превращаются в трудно стыкуемый хаос. Их и понять-то сложно, не говоря о том, чтобы учесть.
Если же сократить количество участников до необходимого минимума в 3-4 человека и иметь фасилитатора, всё становится гораздо приятнее. Это действительно полезная рабочая группа, способная быстро решать задачу и договариваться между собой. У них просто нет времени тупить в телефоны и перекрикивать друг друга!
Конечно, более масштабные встречи тоже нужны — для презентаций, первичных брейнштормов. Но надо знать границы возможностей любого формата взаимодействия.
Один из главных теоретиков менеджмента Питер Друкер говорил, что культура ест стратегию на завтрак. Это избитая фраза, но жизнь постоянно доказывает её правоту.
Меняйте дискурс — думайте и говорите о ценностях, а не процедурах. Построить идеальную команду или процесс невозможно — реальные ограничения всегда будут мешать и осаживать. С правильной культурой ваши достижения долгосрочны, а не разваливаются как только вы отвернетесь. Вашей дизайн-командой становится вся компания, а результатом дизайна не только хорошие продукты, но и сама организация.
Автор: Mail.Ru Group
Источник [52]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/ux/186415
Ссылки в тексте:
[1] общий подход к UX-стратегии: http://www.jvetrau.com/uxstrategy-1/
[2] подходящего дизайнера для её реализации: http://www.jvetrau.com/uxstrategy-2/
[3] результат его работы: http://www.jvetrau.com/uxstrategy-3/
[4] для журнала UXmatters: http://www.uxmatters.com/mt/archives/2016/09/applied-ux-strategy-part-4-design-culture.php
[5] Денис Петелин говорит: http://thetorch.ru/?p=235
[6] аналогию с ножками стола: http://bradfrost.com/blog/post/i-have-no-idea-what-the-hell-i-am-doing/
[7] M-, E-, Pi- и [подставьте любую букву]-образных моделях: https://www.linkedin.com/pulse/which-letter-shaped-future-employees-leaders-esin-akay
[8] Image: http://www.jvetrau.com/wp-content/uploads/2016/09/SkillKnowledgeMatrixNow.png
[9] Скачать: http://www.jvetrau.com/wp-content/uploads/2016/09/SkillKnowledgeMatrixPublic.xlsx
[10] похожем подходе: http://www.uxmatters.com/mt/archives/2011/11/the-t-model-and-strategies-for-hiring-ia-practitioners-part-2.php
[11] используют в Intercom: https://blog.intercom.io/how-to-hire-designers/
[12] Image: http://www.jvetrau.com/wp-content/uploads/2016/09/SkillKnowledgeMatrixFuture.png
[13] Альтернативный метод планирования команды: https://medium.com/@nickdaze/building-creative-teams-without-your-gut-5a49ef4338f
[14] написал Jay Kaufmann: http://www.smashingmagazine.com/2015/11/writing-inspiring-job-descriptions-for-ux/
[15] мощное исследование принципов работы дизайн-команд: https://vimeo.com/121037431
[16] IBM говорит о похожих значениях: http://www.ibm.com/design/thinking/in-practice/
[17] приводит в пример джазовую импровизацию: https://experiencinginformation.wordpress.com/2015/04/06/jazz-as-a-model-for-teamwork/
[18] Похожие вещи говорит и Baruch Sachs: http://www.uxmatters.com/mt/archives/2016/02/getting-specific-on-soft-skills-for-ux-professionals.php
[19] интересную орг.структуру: http://agilerussia.ru/practices/spotifyscaling/
[20] разбита на целостные команды: https://medium.com/@Mediauras/my-two-years-as-an-anthropologist-on-the-photoshop-team-e700acb7d3d5
[21] 12 человек: http://habrahabr.ru/company/friifond/blog/250605/
[22] работу всех специалистов в отделе поддержки пользователей: https://habrahabr.ru/company/friifond/blog/250857/
[23] в команде сразу три сильных дизайнера с неплохим опытом разработки: https://medium.com/in-progress/creativity-and-productivity-at-fiftythree-112ab025e06a
[24] компания отказалась от роли дизайнера и уволила двух последних: https://www.engadget.com/2015/09/15/fruit-ninja-halfbrick-no-more-designers/
[25] хороший дизайн — это фокус для компании, а значит за него должны отвечать все: http://www.fastcodesign.com/3051300/firing-its-designers-might-be-the-best-thing-for-the-creators-of-fruit-ninja
[26] Дизайн-команда централизована, но внутри нее есть разделение по средам: http://www.slideshare.net/UXSTRAT/ux-strat-2014-peter-merholz-shaping-organizations-to-deliver-great-user-experiences
[27] Внутри отдела 4 группы: http://blog.production.invision.works/inside-design-netflix/
[28] рабочая группа UXA: http://www.fastcodesign.com/3046512/how-google-finally-got-design
[29] очередной волны трансформации компании: http://www.nytimes.com/2015/11/15/business/ibms-design-centered-strategy-to-set-free-the-squares.html?_r=0
[30] инвестировать в дизайн $100 млн и нанять до 1000 дизайнеров: http://radar.oreilly.com/2015/04/ibm-is-banking-on-designs-roi.html
[31] лабораторию-инкубатор в Остине: http://www.slideshare.net/UXSTRAT/ux-strat-2014-todd-wilkens-putting-ux-and-strategy-at-the-heart-of-the-product-team
[32] Дизайн-команда издательского дома: http://product.voxmedia.com/2015/5/5/8551635/building-a-team-to-scale-storytelling-while-fostering-experimentation
[33] похожие мысли: https://medium.com/eightshapes-llc/team-models-for-scaling-a-design-system-2cf9d03be6a0
[34] много интересного делает Google Ventures: https://blog.intercom.io/podcast-braden-kowitz-talks-design-and-startups/
[35] Valve, Medium и Buffer развиваются успешно: http://www.fastcompany.com/3045509/hit-the-ground-running/myths-of-companies-with-no-management
[36] у Zappos эксперимент закончился внутренним кризисом: http://www.gallup.com/businessjournal/189074/no-managers-organizational-approach-doesn-work.aspx
[37] Алексей Иванов: http://alexeyivanov.com/
[38] модель командного взаимодействия: http://theteamcanvas.com/
[39] серию на эту тему пишут Jim Nieters и Pabini Gabriel-Petit: http://www.uxmatters.com/mt/archives/2014/12/ux-leadership-part-1-the-nature-of-great-leaders.php
[40] вторая часть: http://www.uxmatters.com/mt/archives/2015/01/ux-leadership-part-2-what-great-leaders-must-do.php
[41] Закон Conway: https://en.wikipedia.org/wiki/Conway%27s_law
[42] организационный долг: http://venturebeat.com/2015/05/19/organizational-debt-is-like-technical-debt-but-worse/
[43] модель проблем в работе команд Patrick Lencioni: http://www.tablegroup.com/books/dysfunctions
[44] системном подходе MailChimp: http://alistapart.com/article/connected-ux
[45] «часы налёта» наблюдения за пользователями: https://www.uie.com/articles/user_exposure_hours/
[46] ustwo придерживается следующих принципов: https://ustwo.com/blog/7-habits-of-highly-effective-teams
[47] Пятидневный формат командной работы для концептуального проектирования продукта: http://www.gv.com/sprint/
[48] исследовательский спринт: http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions
[49] Однодневная или двухдневная рабочая сессия: https://articles.uie.com/design_studio_workshop/
[50] получилась у IBM: http://www.ibm.com/design/thinking/
[51] программу «миссионеров» или «катализаторов» изменений: https://hbr.org/2011/06/the-innovation-catalysts
[52] Источник: https://habrahabr.ru/post/309742/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.