Пять промахов продуктового дизайнера, тормозящих команду
Являясь продуктовым дизайнером, за время своей работы я подмечал ошибки и недочёты, и вот решил их сформировать в некий список — можно назвать это своеобразным ретро. Постараюсь кратко описать 5 основных ошибок, которые мешают продуктивной работе и качественному результату.
Ошибка 1 – Предполагать, что разработчик всё знает
Очень частый кейс: разработчику передаётся макет или задача, в которой, вроде бы, всё понятно, но поведение какого-то компонента не описано и не показано. Вам это очевидно, постановщику задачи — тоже, и вы, пребывая в уверенности, что это понимают все, отдаёте задачу. В итоге получаете что-то вроде того, что хотели, но не совсем то. Далее либо конфликт, либо попытка вернуть задачу на доработку, что, скорее всего, уже не поместится в текущий спринт.
Решение:
- Разработчики не могут читать ваши мысли; чётко указывайте все детали.
- Избегайте недопонимания и будьте конкретны.
Ошибка 2 – Вести разговоры о дизайн-проекте в разных местах
Это классика любой команды. У вас ведь есть Jira? И, наверное, рабочий чат? А ещё в столовой что-то обсудили или на созвоне решили выпилить функционал? Такое бывает у всех. Теперь представьте, что это было в пятницу. В понедельник вы приходите выполнять задачу, а артефакты находятся везде, и какая-то часть потерялась. В итоге либо идёте по второму кругу, либо упускаете важные моменты при выполнении задачи.
Решение:
- Обсуждения должны вестись в контексте инструмента для дизайна или разработки. Всё, что написано в чатике или сказано в столовой, должно быть сразу перенесено в Jira (или аналогичный инструмент).
- Фиксируйте все решения в Figma или спецификациях, чтобы информация была доступна всем участникам.
Ошибка 3 – Не обновлять технические требования после изменений в дизайне
Эта ошибка часто вызывает проблемы. После согласования дизайна и передачи задачи в разработку, то есть постановки в спринт, у вас может появиться идея что-то доработать. Это фатальная ошибка: разработчик уже зафиксировал, что он берёт в работу, и рассчитал время. Разработчики не любят сюрпризы, даже если ваш макет стал в 100 раз лучше.
Решение:
- Если изменения неизбежны, обновите технические требования и оставьте комментарий с обоснованием.
- Сообщайте разработчикам об изменениях заранее. Предупреждайте, прежде чем начать изменять макет.
Ошибка 4 – Не привлекать разработчиков на ранних этапах проектирования
Представьте ситуацию: вы с продуктовым менеджером придумали классную фичу, которая лучше, чем у всех конкурентов, кропотливо всё проработали и готовы передать её разработчику. Но он говорит, что в проекте не готов бэкенд или нужно расширять базу данных. Всем грустно, и приходится упрощать фичу.
Решение:
- Привлекайте разработчиков на ранних этапах. Это помогает выявить ограничения и получить ценные предложения.
- Разработчики могут предложить варианты, о которых вы не подумали.
Ошибка 5 – Отсутствие организованного файла с дизайном
Встречается у тех, у кого в макетах на одной странице лежат несколько версий, куча локальных компонентов, а где-то рядом ещё скриншоты референсов. Если в таком виде начать общение с разработчиком, скорее всего, это закончится неудачей.