← Назад | Продолжение (Глава 7) →
(Перед вами бесплатный курс от InVision Studio «Продуктовый дизайн». В курсе 7 глав. Если вы здесь впервые, то лучше начните сначала)
Над переводом работали: Федор Фоминых и Ринат Шайхутдинов.
Освоить проектирование на высшем уровне, помогает практика выхода за рамки ремесла. Дизайн — это не только цвет и форма, дизайн — это скурпулёзное планирование с конкретной целью — помогать другим людям. Поэтому, определение дизайна как культуры выходит далеко за пределы тех процессов которые происходят внутри вашей команды.
Разработчики, продакт-менеджеры и исследователи тоже играют важную роль в разработке продукта. Все вместе вы формируете пользовательский опыт. Но несмотря на общие интересы, нашим командам часто не хватает банальной дисциплины, что затрудняет сотрудничество и общение вплоть до полной остановки.
Организационный дизайн существенно влияет на дизайн продукта. Если люди не смогут наладить между собой хорошие отношения, продукт развалится.
Разломы между командами, разломы в продукте
Довольно часто в компаниях можно встретить такие сценарии: Кортни с командой несколько недель пилили дизайн нового продукта. И вот, окончательный вариант был представлен заказчику, моментально одобрен и радостная Кортни передала файлы команде разработчиков.
Эверетт из отдела разработки поразился красоте полученного дашборда, но вынужден был полностью переделать весь дизайн потому что решение оказалось абсолютно нежизнеспособным. Выяснилось, что у них нет технической возможности отображать данные нарисованные Кортни, а форма регистрации не содержит даже самые необходимые поля.
Работая над приложением Эверетт в командой всё дальше уходил от концепции заложенной дизайнерами. Когда Кортни наконец увидела результат она просто не узнала свой проект и её стало очень не по себе. Через всё здание она полетела к разработчикам, ворвалась к Эверетту и потребовала объяснений. Тот пребывал в глубокой обиде из-за того, что с ним изначально никто не посоветовался, но нашёл в себе силы объяснить что красивый дизайн совершенно не соответствовал инженерным требованиям.
Отношения у них были сложные — они постоянно работали над продуктами в атмосфере легкого недопонимания. Сейчас же спор вокруг продукта превратился в настоящий конфликт. Начался хаос.
Прямо как в «Кремниевой долине» от HBO, эта история может оказаться нам слишком близка. Кортни и Эверетт не могут идти в ногу потому что вся организация работает с ограниченными возможностями — у них вертикальная структура отношений. Проектирование — это верхнеуровневый процесс после завершения которого работа передаётся в разработку. Но разработчики не должны работать на этапе решений задач приложения. Несчастная Кортни проигнорировала важные детали технического процесса и в итоге ей пришлось отказаться от важных элементов дизайна.
Вертикальная структура отношений иногда встречается и в обратном направлении — от разработки к дизайну. Разработчики просто обожают сначала построить всю архитектуру продукта и потом идти к дизайнерам за красотой. Результат предсказуемый — можно нарисовать очень красивые кнопки, подобрать шрифты, но если рабочие алгоритмы построены на базах данных без учёта ментальных моделей, пользователи скажут вам «нет».
Оба сценария не работают. Хороший продукт должен сочетать в себе и дизайн и технологии. Ощущения исходящие от продукта и его функционал прочно взаимосвязаны и одинаково важны. Это можно сравнить с тем, как правое и левое полушария мозга обрабатывают информацию задействуя при этом творческое мышление и логику.
Мы можем взять пример с природы. Нам надо лишь объединить команды для совместной работы. Ведь работая над продуктом все вместе под одной крышей — мы просто не сможем облажаться и обязательно сделаем хороший продукт.
Кросс-функциональные команды
Кросс-функциональные команды — отличительная черта методики Agile. В них объединяются разработчики, дизайнеры и продакт-менеджеры чтобы определить цель, полезное действие и комплекс ощущений от продукта.
Хороший продукт состоит из трех элементов: бизнес, код и дизайн. Представитель каждой из областей должен участвовать в принятии решений по продукту.
— Алекс Шлейфер, Airbnb
Кросс-функциональные команды работают по горизонтальной структуре. Продакт-менеджеры, дизайнеры и разработчики вместе ставят задачи и вместе выдвигают новые концепции. Каждый участник команды может участвовать в принятии ключевых решений.
В отличие от вертикальной структуры, которую так любят Кортни и Эверетт, у кросс-функциональных команд нет таких больших разрывов в понимании между людьми.
В вертикальной структуре, которую так любят Кортни и Эверетт такие разрывы привели к настоящему кризису общения. Никто не должен чувствовать себя забытым. Дизайнеры и разработчики вместе вырабатывают стратегию бизнеса.
Совет: Продакт менеджер
Менеджер по продукту в команде может решать разные задачи, но как правило такие ребята выстраивают план разработки продукта и его соответствие бизнес-целям. Они следят чтобы команда придерживалась расписания и ликвидируют барьеры на пути к прогрессу.
Преимущества кросс-функциональных команд:
- Работая в тесном сотрудничестве дизайнеры и разработчики намного глубже понимают деятельность своих коллег.
- Внутри кросс-функциональных команд хорошо развивается эмпатия и взаимное уважение — это положительно влияет на сотрудничество.
- Всё общение происходит намного быстрее — дизайнеры на месте узнают о технических проблемах вызванных неудачными решениями, а разработчики узнают когда функционал мешает дизайну.
- Разнообразие взглядов на каждом этапе ведёт к созданию ещё более лучших продуктовых решений.
- Совместное владение ослабляет закулисные дрязги и укрепляет доверие.
- По завершению проекта команда может разойтись, но останутся крепкие связи и настоящая дружба. Это укрепляет общую культуру компании.
Преимущества небольших команд можно выразить в трёх словах: непрерывный обмен смыслами, фокусировка, товарищество. Небольшой команде легче следить за статусом проекта, легче вносить правки и легче обучаться. Когда одна команда работает внутри одного проекта, то все участники фокусируются на одних и тех же задачах. Когда команда работает внутри одного пространства, то между участниками развиваются тесные, рабочие отношения.
— Джефф Готельф, автор Lean UX
Совет: Размер команды
Для простоты коммуникации делайте кросс-функциональные команды не более 10 человек. Большее количество специалистов потребует времени на ведение документации, планирование встреч, синхронизацию процессов и т.д. Когда мы сидим в одном пространстве, то все процессы внутри команды происходят легче.
Сейчас компании инвестируют в дизайн всё больше и больше.
— Irene Au, Khosla Ventures
Начинаем трансформацию процесса создания цифрового продукта
Чтобы внести конкретные улучшения в организацию процесса разработки продукта, вам потребуется поработать красной ручкой на своей оргсхеме. Подобные изменения не происходят легко и быстро.
Но прежде чем вводить радикальные изменения отработайте кросс-функциональность на небольших проектах с маленькими сроками. Для начала можно попробовать применить новые схемы на недельном спринте.
Дизайн-спринты
Дизайн-спринт это 5-дневный период разработки, разработанный в Google Ventures. Спринт — решение важных бизнес вопросов при помощи дизайна, прототипирования и тестирования идей на клиентах. Поскольку спринт длится всего неделю, то это хороший и безопасный способ проверить в действии вашу кросс-функциональную команду.
Более подробное описание спринтов можно изучить в книге Sprint от Google Ventures или на их веб-сайтах. Суть такова: за 5 дней команда должна перейти от изучения существующей проблемы до утверждения найденного решения. Если у вас получится удачно провести спринт и вы представите хорошее решение для продукта, то этим вы создадите задел для развития кросс-функциональности в будущем.
Рабочие группы
Рабочие группы чем-то похожи на спринты. Они тоже собирают команду из разных специалистов и решают сложные задачи. Рабочие группы собираются вместе на длительный период — их цель передать готовый продукт в руки клиентов. Когда проект заканчивается, все расходятся по своим командам.
Отличительные черты рабочих групп:
- Четко поставленные цели и метрики для измерения успеха;
- В команде есть дизайнеры, разработчики, продуктовый менеджер и возможно, исследователь;
- Право принимать ключевые решения по разработке продукта;
- Жёсткий дедлайн;
У MailChimp большой опыт создания рабочих групп для работы на сложных проектах. Одна из групп однажды была создана для разработки сервиса редактирования электронных писем перетаскиванием.
В команде были дизайнер, фронтенд-разработчик и два программиста, один из которых умел делать классные прототипы. Ребята всей группой закрылись в маленьком помещении и приступили к проекту. Они делали зарисовки, обсуждали задачи и рассматривали их со всех сторон.
Постепенно зарисовки превратились в простые прототипы. Дизайнер изучил концепцию интерфейса и внес необходимые правки. Затем фронтенд-разработчик закодил новый дизайн, настраивая по ходу взаимодействие элементов. Они работали циклами, на каждом витке демонстрируя друг другу результаты и призывали этим к дискуссии.
В конце концов, прототип достиг своего предела. Его протестировали на всех сотрудниках компании, потом на избранных клиентах, и вскоре, новый редактор Neapolitan был запущен. Создание рабочей группы позволило компании отвлечься от огромной массы своего продукта и углубиться в одну маленькую но важную функцию, которая сделала работу в MailChimp проще и быстрее. После окончания проекта люди разошлись по своим командам унося с собой уважение к коллегам и к их нелёгкому труду. Также, люди запомнили каких результатов можно добиваться используя горизонтальное проектирование.
Идем дальше: внедрение горизонтального дизайна
Когда все увидят реальную пользу от рабочих групп, то возникнут мысли о внедрении такой практики в масштабе всей кампании. Кросс-функциональную структуру команды горизонтального проектирования можно расширить через объединение разработки, продакт-менеджмента и дизайна в организационную структуру, обычно называемую EPD.
Алекс Шлейфер вице-президент по дизайну Airbnb, описывает EPD как табурет на трех опорах, который поддерживает организацию.
Настоящая команда это как табуретка на трёх ножках, каждая из которых олицетворяют собой три важнейших составляющих для создания успешного продукта. Если заложить эти вещи в самом начале, то они будут расти и развиваться параллельно, по мере увеличения масштабов организации.
— Алекс Шлейфер, Airbnb
Если у табурета одна ножка короче других — возникнет дисбаланс и табурет упадет. Команда EPD будет плохо работать, если отдельные её части сильнее или слабее относительно других. Сила EPD заключается в разделении власти.
На протяжении всего процесса разработки, все функции EPD должны включаться с самого старта и развиваться синхронно.
Команды EPD обычно создаются вокруг функций продукта и по области взаимодействия с пользователем:
- Fb организует свои команды по таким функциям: лента новостей, профиль или мессенджер.
- Airbnb организует команды исходя от области взаимодействия с пользователем — например, для гостя или хозяина.
Как и в рабочих группах, каждая команда здесь кросс-функциональна (как табуретные ножки EPD).
На успешность EPD сильно влияет атмосфера взаимоотношений между руководителями направлений разработки, продакт-менеджмента и дизайна. Возможный конфликт быстро перекинется от лидеров на всю команду. Крайне важно, чтобы все 3 лидера действовали воедино в руководстве и в общении с компанией.
Совет: Как сделать кросс-функциональное сотрудничество лучше
В блоге FirstMark Capital Алекс Шлейфер рассказывает, как Airbnb объединяет команды и организует их в EPD для более эффективного сотрудничества.
Проблемы кросс-функциональных команд
Кросс-функциональные команды дают нам неоспоримые преимущества, но они могут дать и проблемы. Из-за временного статуса перед рабочими группами редко ставят серьёзные задачи. Чтобы дизайнеры не почувствовали себя как на каникулах, заведите традицию — на каждом таком проекте обязательно учиться чему-то новому. Пока не научится — из проекта не выпускать.
При частой практике использования кросс-функциональных команд возникает ощущение, что пространство наполнено постоянными потоками беженцев. Дизайнерам придётся подстраиваться к незнакомым командам и при этом не потерять собственную идентичность. Давайте узнаем как эти довольно распространённые проблемы решаются в крупных компаниях. Имея перед глазами ясное понимание структуры EPD и набор готовых решений вы сможете плавно и безболезненно совершить этот переход.
Изоляция
Из главы «Показывай и рассказывай» мы помним, что дизайнеру необходим поток регулярной обратной связи (фидбэк) от коллег по цеху. Но если в кросс-функциональной команде только один дизайнер, то такой фидбэк ему получить не от кого. Давайте посмотрим как эта проблема решается в таких кампаниях как Slack, X/Twitter и BBC.
Slack: парный дизайн
Горизонтальный дизайн в кросс-функциональных командах является основной рабочей моделью в Slack, но дизайнеры у них всегда работают парами, причем один из них берёт на себя роль лидера.
В дизайне нужен напарник. С ним можно браться за любые дела и находить множество идей для развития. Как правило, напарник схож с вами по навыкам или отлично дополняет вас. И конечно же, вдвоем намного легче прорываться сквозь преграды к цели.
— Диоген Брито, Slack
Если у вас в команде мало дизайнеров, то можно привлекать человека на временной основе. Если основному дизайнеру будет кто-нибудь помогать хотя бы 1-2 часа в день, уже станет намного легче двигаться не сбавляя темп.
X/Twitter: дизайн-ревью
В начале 2014 года в Twitter отошли от централизованной системы и создали у себя кросс-функциональные команды. Чтобы дизайнеры не чувствовали себя оторванными от коллектива, Майк Дэвидсон вице-президент по дизайну ввёл в распорядок еженедельные обзоры дизайна и ещё ряд подобных мероприятий. Таким образом, дизайнеры вернули себе возможность делиться опытом, почувствовали дыхание большого коллектива, и синхронизировали все рабочие процессы.
BBC: Ротация в командах
В кампании BBC работает более 20 000 сотрудников. Это позволяет им каждый год подбирать для человека новую команду. Такая практика помогает всем сотрудникам (не только дизайнерам) завязывать новые рабочие отношения и углублять общее знакомство со всей организацией.
Дизайнеры, которые хотят работать в UX-команде обсуждают эту идею со своим менеджером. Это принимается положительно если дизайнер более года отработал в похожей команде. HR-менеджер оформляет трансфер с учётом навыков дизайнера, карьерных целей и наличии свободных мест в командах.
Согласование стиля и ценностей
Распределенным командам дизайнеров важно не забывать о консистентности дизайна для всех продуктов и функций. Если у дизайнеров не будет четких гайдов, то вы потеряете не только стили интерфейсов но и ценности компании. Многие крупные организации во всём мире пытаются решить эту проблему, и у некоторых это даже получается. Одна из таких компаний — Spotify.
Spotify: Дизайн-системы и ценности
По мере масштабирования компании становится труднее следить за единообразием дизайна. Такие компании, как Salesforce, IBM, BBC и Atlassian чтобы обеспечить UI-единообразие разрабатывали дизайн-системы, но в Spotify пошли дальше и использовали свою дизайн-систему для решения организационных проблем.
Команда развития языка дизайна Spotify называется GLUE (Global Language for a Unified Experience) — они центр вселенной для всех дизайн-проектов компании. Все дизайнеры постоянно держат на связи отдел GLUE чтобы оперативно получать новые рекомендации и вносить свои предложения. Такая система это не продукт с четкими сроками, а скорее история зарождения и развития продукта который помогает другим продуктам.
— Натан Кертис, EightShapes
Если раньше дизайн-системы скромно топтались где-то сбоку, то сейчас они играют важную роль в жизни крупных организаций. Они стали идеальной средой в которой дизайнеры могут объединять свои силы для принятия общих решений.
Гильдия
В кросс-функциональных командах Spotify все дизайнеры объединены в гильдию — сообщество по интересам, где можно делиться знаниями, инструментами и передовым опытом. К дискуссии может присоединиться любой желающий, даже если он не дизайнер. Деятельность гильдии координирует специальный человек.
Ценности
Внутри кросс-функциональной команды одинокий дизайнер часто вынужден соглашаться с разработчиками, которые не любят работать со сложным дизайном и стремятся всё сделать дёшево и сердито. Ну зачем нам анимировать этот переход? Это что, даст какую-то ценность? Когда дизайнер в команде один, ему трудно отстоять все мелкие нюансы своего макета. Ему остаётся лишь закусить губу и молча вернуться к работе.
Если вы единственный дизайнер в кросс-функциональной команде, то вам придётся брать на себя больше ответственности, чем если бы вас было несколько.
— Майк Дэвидсон, Бывший вице-президент по дизайну в Twitter
Ничего страшного, если между дизайнерами и разработчиками возникают небольшие трения — это даже поможет отнестись к себе более критически. Но иногда разработчики не воспринимают дизайн потому что не понимают как можно измерить его успех.
Разработчики привыкли измерять успех количественно:
- Сколько строчек кода потребовалось?
- Производительность сайта выросла?
- Сколько багов там насчитали?
Дизайнеры же измеряют успех качественно:
- Как это выглядит?
- Этим легко пользоваться?
- Этим можно восхищаться?
Дело в том, что работу дизайнера нельзя замерять показателями от разработки, а работу разработчика нельзя оценивать дизайнерскими метриками. Но можно и нужно работать вместе, и тогда обязательно появится общее, командное понимание успеха.
В Spotify осознали эту потребность и сформулировали основные принципы по которым определяются наиболее важные аспекты при решении дизайнерских задач. Ознакомится с принципами может любой желающий, а главная их ценность в том, что они помогают дизайнерам объединиться и совместно сформулировать необходимые решения.
Например, разработчику больно видеть как драгоценное пространство интерфейса тратится на какую-то огромную фотографию. Зачем она здесь? Давайте вместо неё разместим побольше каких-нибудь данных. Если в подобной ситуации дизайнеру необходимо почувствовать поддержку системы ценностей Spotify. Тогда он может смело ответить, что наши ценности обязывают нас следить чтобы интерфейс был живым а не мёртвым! Данная фотография оживляет всю страницу и задаёт необходимую цветовую гамму!
При наличии в дизайне общедоступного набора ценностей, мы ясно видим приоритеты дизайна и понимаем как их достичь.
Горизонтальное проектирование на практике
Горизонтальный дизайн не должен ощущаться в вашей организации как догма. Неважно по каким методикам работает ваша компания — Agile или Lean, всё это помогает ей создавать атмосферу взаимоуважения и сопереживания. В результате появляется почва для разработки хороших продуктов.
Организационный дизайн сильно влияет на дизайн продукта. Ключевые факторы в этом здесь — совместное принятие решений, совместное преодоление трудностей и смешанные команды.
Вот ваш список дел, которые нужно сделать, чтобы применить боковой дизайн на практике в своей компании:
- Начинать лучше с маленького недельного дизайн-спринта.
- Когда вы ощутили преимущества кросс-функциональных команд, создайте рабочую группу по разработке проекта с понятными сроками и чётко обозначенными целями. В команде должны быть дизайнеры, разработчики и продакт-менеджер.
- Когда вы увидите что ваша организация готова идти дальше — объедините все команды в структуру EPD. Разработчики, продакт-менеджмент и дизайн делятся полномочиями и подчиняются непосредственно CEO или исполнительному директору.
← Назад | Продолжение (Глава 7) →