5 способов сделать так, чтобы дизайнеры и разработчики понимали друг друга

Привет! Меня зовут Наташа Серёжникова, я старший дизайнер в Авито. Люблю разбираться в том, как взаимодействуют люди внутри команд и между ними. В статье расскажу, как мы выстроили прозрачный процесс работы между дизайнерами и разработчиками, разберу примеры и дам 5 советов.

Но сначала кратко объясню, какие специалисты работают с продуктом в Авито:

🔎 В нашу команду discovery входят дизайнер, редактор, продакт, аналитик и исследователь

🛠 В команду delivery — тестировщик, тимлид, фронтенд и бекенд разработчики.

А теперь к советам.

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

2. Сделайте процесс дизайна прозрачным для разработчиков

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

4. Показывайте разработчикам целевое видение

5. Настройте процесс дизайн-ревью макетов Ещё раз все 5 советов коротко

Дизайнер является связующем звеном между продуктом и разработкой и объединяет discovery и delivery команды. Например, ему важно уметь давать разработчикам обратную связь и понимать, что они говорят.

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

Чтобы общаться на одном языке, мы внедрили пару правил:

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

✅ Не стесняемся задавать странные вопросы. Так мы решили проблему недопонимания между сотрудниками из разных команд и сократили время на переписки.

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

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

Чтобы сделать дизайн-процессы более понятными для разработчиков мы:

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

✅ Ввели понятные статусы в Фигме, чтобы все участники понимали, что происходит с макетом.

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

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

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

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

✅ Приглашаем разработчиков на дни с пользователями. Коллеги могут провести интервью сами или послушать, как исследователь общается с пользователем. Теперь разработчики понимают, кто пользуется продуктом, и с какими проблемами сталкиваются эти люди.

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

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

✅ Показываем разработчикам «макеты из будущего». Это даёт им нужный контекст, объясняет наши решения и добавляет мотивации. Когда ребятам нравится, что они делают, это помогает договариваться о фичах. Например, так коллеги охотнее ищут способ реализовать более сложное решение в короткие сроки.

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

В другой статье мои коллеги уже рассказали, как мы готовим целевое видение и какие ещё преимущества даёт такой подход:

👉 Как устроить работу между дизайнером и продактом, чтобы не рисовать концепты в стол

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

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

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

Вот так могут выглядеть макеты до и после дизайн-ревью:

Именно дизайнер может помочь с тем, чтобы реализация на проде соответствовала тому, что задумала, отрисовала и протестировала команда discovery.

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

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

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

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

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