Как дизайнер продукта может решать проблемы в компании. Читайте на Cossa.ru

13 мая, 12:57

Как дизайнер продукта может решать проблемы в компании

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

Как дизайнер продукта может решать проблемы в компании

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

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

Успейте купить корпоративный пакет COSSA-2025 со скидкой!


Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

Нет понимания ценности работы дизайнера со стороны бизнеса

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


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

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

Руководителю.

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

Непонимание работы дизайнера со стороны менеджера/руководителя

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


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

Можно задаться вопросом: зачем делать лишние движения и тратить ресурсы разработчиков, когда можно по-быстрому внедрить решение, которое не потребует множества ресурсов — этакая заплатка, которая хоть как-то будет решать задачу?

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

Нет понимания ценности дизайн-системы и переиспользуемых компонентов

Представьте что у вас три дизайнера, которые работают над своим кусочком продукта, и между ними нет отлаженной коммуникации. Итог: у вас уже 25 видов различных кнопок, 30 шрифтов, и никто не знает, сколько цветов использует эта тройка творцов. А теперь представьте что ваш продукт активно растёт и масштабируется. Как поддерживать всё это? Нанимать ещё больше разработчиков?


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

Руководителю.

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

Сломанная коммуникация с командой разработки

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


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

Бизнесу.

— Коммуникация между дизайнерами и разработчиками должна стать неотъемлемой частью работы команды.

— Обязательна презентация дизайна команде разработки на ранних этапах проектирования.

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

Недостаточное развитие дизайн-инфраструктуры и процессов в компании

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


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

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

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

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.


Телеграм Коссы — здесь самый быстрый диджитал и самые честные обсуждения: @cossaru

📬 Письма Коссы — рассылка о маркетинге и бизнесе в интернете. Раз в неделю, без инфошума: cossa.pulse.is

✉️✨
Письма Коссы — лаконичная рассылка для тех, кто ценит своё время: cossa.pulse.is