Дизайнеры и разработчики: основы эффективного взаимодействия

Как организована работа продуктовых команд в Spotify

В Spotify мы используем пятиэтапный процесс, который позволяет различным командам объединить усилия и добиться результата. Мы называем его "Шкала", и по сути это немного доработанный классический фреймворк дизайн-мышления.

Пять этапов, пять целей

1. Мы понимаем потенциальные потребности, желания и боли пользователей 

2. Мы обдумываем их и проводим мозговой штурм, чтобы найти решение 

3. Мы создаем продукт, инструмент или услугу и... 

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

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

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

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

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

“Шкала” не является одноразовым циклом. Дизайн и разработка сплетаются в своего рода танце, где опыт и знания определяют, кто главный. Этот танец — ДНК любой успешной команды. Мы называем его DNE (в отличие от DNA / ДНК) технологической команды (по первым буквам Design & Engineering / дизайн и разработка) — смена ролей и сотрудничество на протяжении всего срока работы над продуктом или функцией.

Как объединить дизайн и разработку? 

Как добиться успеха в этом танце? Как заставить наши команды танцевать вместе, не наступая друг другу на ноги?

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

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

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

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

Даже самые лучшие пары сталкиваются с трудностями! Давайте посмотрим, что мы узнали из историй сотрудников Spotify.

Дизайнеры и разработчики: четыре причины проблем

1. Недостаток взаимодействия

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

Один из них сказал: 

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

Другой разработчик также сказал нам:

“Худшая ситуация — когда ты получаешь готовые макеты, а потом вынужден говорить: Нет, мы не можем этого сделать, это технически неосуществимо.”

Почему так происходит? 

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

2. Проблемы коммуникации

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

Вот конкретный пример, о котором нам рассказал один из разработчиков: 

“Разработчики работают над задачей A, а дизайнер — над задачей B. Дизайнер не хочет отнимать время у команды технических специалистов и поэтому работает над решением самостоятельно. Позже разработчики могут отвергнуть решение, в создании которого они не участвовали, и тогда дизайнеру придется начинать все с нуля. Никто не хочет делать лишнюю работу.”

Также препятствием может стать непонятная терминология:

“Пример из опыта моей команды. Дизайнеры называли MVP (минимальный жизнеспособный продукт) продукт во всех вариациях и со всеми необходимыми функциональными возможностями, а разработчики — абсолютный минимум, который нужно выпустить после первой итерации, только одну версию с парой обязательных функций.”

Почему это происходит?

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

3. Чувство, что одна команда блокирует работу другой

Коллеги рассказали, что иногда в процессе совместной работы одна команда ощущает себя “заблокированной” другой. 

Наш разработчик поделился:

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

С другой стороны, один из дизайнеров сказал:

“Я бы хотел, чтобы разработчики чувствовали, что когда мы, все вместе, работаем над макетом и исследуем концепцию как команда, они играют важную роль. Да, они не пишут код, но участвуют в дизайне. Это тоже работа!”

Почему так происходит? 

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

“Хотелось бы, чтобы разработчики знали, что даже если мы не можем реализовать какое-то решение, нам все равно нужно его изучить, это наш долг как дизайнеров.”

4. Разногласия по поводу того, что необходимо, а что лишнее

Один из разработчиков отметил:

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

Почему так происходит?

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

При правильном подходе этот потенциальный конфликт приоритетов может создать идеальный баланс между двумя дисциплинами! 

Как сделать эти отношения успешными? 

1.  Тесное взаимодействие

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

Один разработчик сказал:

“Самые лучшие коллаборации с дизайнерами случались тогда, когда я мог связаться с ними в любой момент, и когда они чувствовали, что ко мне тоже можно обратиться в любую минуту. Личный контакт — ключ к эффективному взаимодействию!”

Действия: 

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

• Участвуйте в работе и встречах друг друга. Проводите совместные обсуждения, оставляйте комментарии в документации и общайтесь в Slack.  

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

• Заведите совместный канал в Slack, чтобы поддерживать активную беседу.

• Вовлекайте дизайнеров и разработчиков в процесс с самого начала и избегайте классической передачи полномочий (вместо этого перераспределяйте роли). 

2. Интересуйтесь работой друг друга и высказывайте свое мнение о ней

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

Один дизайнер сказал: 

“Я бы хотел, чтобы разработчики больше знали о дизайн-мышлении и могли сосредоточиться на потребностях/проблемах, а не на решениях.”

А разработчик отметил:

“Я бы хотел, чтобы дизайнеры были в курсе ограничений и сложностей реализации некоторых идей.”

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

Действия:

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

• Не думайте, что ваши коллеги имеют опыт сотрудничества с дизайнерами / разработчиками. Узнайте, так ли это. Если нет, познакомьте их с основами своей работы и объясните, как они могут вам помочь. Расскажите им о том, что означают те или иные профессиональные термины.

3. Будьте добрее друг к другу 

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

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

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

Действия: 

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

• В шведском языке (потому что Spotify, конечно же, шведский продукт) есть понятие snälltolka, которое дословно переводится как "интерпретировать по-доброму". Когда вы расстроены или испытываете стресс в общении со своим коллегой, постарайтесь истолковать его слова по-доброму и воспринимать его действия как попытку решить проблему и продвинуться вперед. 

Резюме

Итак, что мы узнали о взаимоотношениях между дизайнерами и разработчиками? 

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

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

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