Скидки до 60% и 3 курса в подарок 2 дня 00 :58 :43 Выбрать курс
Дизайн
#Мнения

Дизайн vs фронтенд: секреты win-win-взаимодействия

Продуктовый дизайнер Flowwow Маргарита Савченко рассказала, как найти общий язык с разработчиками и сократить время работы над фичей.

Иллюстрация: Полина Честнова для Skillbox Media

Жизнь можно сделать лучше!
Освойте востребованную профессию, зарабатывайте больше и получайте от работы удовольствие.
Каталог возможностей

Маргарита Савченко

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

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

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

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

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

Подбираем ключик к сердцу разработчика

Изучаем мышление фронтендеров

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

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

  • В каком формате вам удобнее получать макеты? Например, разделить его на шаги или оставить только то, что изменилось.
  • Что для вас важно при описании логики?
  • Как вам удобнее получать обозначения изменений в макетах?
  • Есть ли что-то, что для вас критически важно описать в макете?
  • Сколько размерностей экранов нужно? Нужно ли дополнительно прописывать адаптивности или вы сделаете это самостоятельно?
  • В каком формате вам удобно получать анимацию?
  • Работаете ли вы в dev-режиме (режиме разработчика) с макетом?

Прописываем логику фич

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

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

Изображение: Маргарита Савченко / Flowwow

Подключаем разработчиков на разных этапах работы

Главная ошибка в работе над макетом ― показать его разработчикам в последний момент. Вовлекайте коллег прямо в процессе: запрашивайте их мнение на этапе формирования гипотез и уточняйте, получится ли реализовать все идеи и сколько это займёт времени.

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

Правильно даём фидбэк

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

Откажитесь от оценочного «мне не нравится» и сосредоточьтесь на фактах. Объясните, почему вы хотите внести исправление и как это повлияет на работу приложения. К тексту обязательно приложите скриншот и покажите, что именно нужно исправить и как должно получиться в результате. Такой подход помог нашей компании сократить время от первых тестов до выпуска фич на 15%.

Изображение: Маргарита Савченко / Flowwow

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

Лайфхаки для быстрого выхода фич


1. Показываем изменения «до/после»

Результат: разработчики стали изучать фидбэк в два раза быстрее.

Вносить правки всегда тяжело, особенно когда не понимаешь их сути и ценности. Обосновать перед разработчиком ценность изменений помогут подробные скриншоты «до/после».

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

Изображение: Маргарита Савченко / Flowwow

2. Обозначаем логику цветами

Результат: вопросы по логике фич сократились в 1,5–2 раза.

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

Так, мы закодировали изменения цветом в нашей компании:

  • Зелёный. Внешняя логика ― изменения, которые видит клиент.
  • Синий. Внутренняя логика ― изменения со стороны админки.
  • Фиолетовый. Логика переходов ― путь клиента после взаимодействия со ссылками.
  • Оранжевый. Общая логика ― всё важное, что не вошло в предыдущие блоки. Например, с кем согласовать изменения, перед тем как отдать задачу в релиз и в продакшен.

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

Не забывайте детально прописывать все изменения в формате «до/после» и размещать блоки рядом с элементами, которые нужно изменить. Если нужно скорректировать конкретную цифру, выносите её крупно на скриншоте и отмечайте комментарием.

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

Изображение: Маргарита Савченко / Flowwow

3. Делим макет на итерации

Результат: сэкономили 20–30% времени в работе над фичей.

Если предстоит работа над объёмной задачей, смело разбивайте её на этапы. Разработчики ― обычные люди: они уходят в отпуск, болеют, отвлекаются на другие задачи, из-за чего могут терять фокус на продолжительных проектах.

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

Мы выделяем итерации по следующему алгоритму:

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

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

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

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

4. Транслируем ценности через макет

Результат: сократили количество ошибок на 10%.

В случае сложных задач с объёмным техзаданием, например с требованиями от юристов или менеджеров, мы выносим главное в описание задачи и там же предлагаем готовое решение. Благодаря этому разработчик не вынужден бегать между ТЗ, вашими комментариями и параллельно думать, как реализовать фичу.

Рассмотрим пример:

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

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

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

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

Никаких компромиссов — только win-win

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

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

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

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

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

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

Больше интересного про дизайн в нашем телеграм-канале. Подписывайтесь!

Понравилась статья?
Да

Пользуясь нашим сайтом, вы соглашаетесь с тем, что мы используем cookies 🍪

Ссылка скопирована