Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#Мнения</a>

2 <ul><li>15 янв 2025</li>

3 <li>0</li>

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

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

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

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

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

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

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

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

12 <ul><li><a>Подбираем ключик к сердцу разработчика</a></li>

13 <li><a>Лайфхаки для быстрого выхода фич</a></li>

14 </ul><ul><li><a>Показываем изменения до/после</a></li>

15 <li><a>Цветокодировка логики</a></li>

16 <li><a>Разделение макета на итерации</a></li>

17 <li><a>Трансляция ценностей через макет</a></li>

18 </ul><ul><li><a>Никаких компромиссов - только win-win</a></li>

19 </ul>Изучаем мышление фронтендеров

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

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

22 <ul><li>В каком формате вам удобнее получать макеты? Например, разделить его на шаги или оставить только то, что изменилось.</li>

23 <li>Что для вас важно при описании логики?</li>

24 <li>Как вам удобнее получать обозначения изменений в макетах?</li>

25 <li>Есть ли что-то, что для вас критически важно описать в макете?</li>

26 <li>Сколько размерностей экранов нужно? Нужно ли дополнительно прописывать адаптивности или вы сделаете это самостоятельно?</li>

27 <li>В каком формате вам удобно получать анимацию?</li>

28 <li>Работаете ли вы в dev-режиме (режиме разработчика) с макетом?</li>

29 </ul>Прописываем логику фич

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

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

32 Изображение: Маргарита Савченко / FlowwowПодключаем разработчиков на разных этапах работы

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

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

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

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

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

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

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

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

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

42 Изображение: Маргарита Савченко / FlowwowРезультат:вопросы по логике фич сократились в 1,5-2 раза.

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

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

45 <ul><li>Зелёный. Внешняя логика ― изменения, которые видит клиент.</li>

46 <li>Синий. Внутренняя логика ― изменения со стороны админки.</li>

47 <li>Фиолетовый. Логика переходов ― путь клиента после взаимодействия со ссылками.</li>

48 <li>Оранжевый. Общая логика ― всё важное, что не вошло в предыдущие блоки. Например, с кем согласовать изменения, перед тем как отдать задачу в релиз и в продакшен.</li>

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

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

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

52 Изображение: Маргарита Савченко / FlowwowРезультат:сэкономили 20-30% времени в работе над фичей.

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

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

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

56 <ul><li>Определяем бизнес-логику. Выписываем всё, что нужно исправить и внедрить.</li>

57 <li>Уточняем у разработчика, как быстро можно внедрить то или иное изменение.</li>

58 <li>Выделяем наиболее выгодные фичи с учётом оценки разработки и ценности для бизнеса. Их внедряем первыми. Остальные переводим на следующие спринты или удаляем.</li>

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

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

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

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

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

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

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

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

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

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

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

70 <ul><li>меняйте в продукте только то, что не отвечает его цели и ценностям;</li>

71 <li>обосновывайте свои предложения;</li>

72 <li>помните, что вы работаете с живыми людьми, у которых могут быть проблемы дома, куча параллельных задач, - проявите заботу и постарайтесь терпеливо всё объяснить.</li>

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

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

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

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

77 Другие материалы о работе дизайнера

78 - <a>Научитесь: Профессия Графический дизайнер PRO Узнать больше</a>

78 + <a>Научитесь: Профессия Графический дизайнер PRO + ИИ Узнать больше</a>