Как дизайнер продукта может решать проблемы в компании
Роль дизайнера в продуктовой разработке и типичные проблемы, с которыми он может столкнуться в работе.
Дизайнер продукта — это не просто творец, он воплощает функции UX- и графического дизайнера, аналитика, прототипировщика, маркетолога и исследователя. Его миссия — выявлять проблемы продукта, предлагать улучшения и воплощать их в жизнь с учётом стратегии бизнеса.
Недопонимание важности его вклада со стороны менеджеров, отсутствие осознания ценности дизайн-системы, проблемы коммуникации с командой разработки — все эти аспекты требуют внимания и анализа. Давайте пройдёмся по самым частым проблемам, с которыми сталкивается продуктовый дизайнер, и попробуем найти для них решение.
Управлять бизнесом - легко! С цифровыми решениями от МегаФона.
Настрой видеонаблюдение с оповещениями и аналитикой, подписывай документы онлайн без бумаги, координируй местоположение курьеров и статус выполнения задач.
Подключай сервисы от МегаФона ПроБизнес - и получай до 15 000 бонусных рублей!
Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585
Нет понимания ценности работы дизайнера со стороны бизнеса
Честно — мне трудно представить компанию, которая не инвестировала бы в дизайн. Однако если судить по моему опыту дизайн-ментора, встречаются случаи, когда дизайнерам не предоставляется возможность для полноценной работы — они лишь выполняют чужие указания без права на собственное творчество. Это снижает их потенциальную пользу для бизнеса.
Результативность дизайнера зависит от его роли и автономии в компании. Понимание своих задач и областей ответственности позволяет ему вносить значимый вклад в развитие продукта.
Более того, дизайн стоит на стыке потребностей пользователей, бизнес-целей и технологических решений, играя ключевую роль в создании успешных продуктов.
Руководителю.
Дизайнер — штатная бизнес-единица: он должен приносить пользу. Для этого он должен иметь полномочия, возможность влиять на продукт, нести ответственность за свои решения. В нынешнее время пренебрежение дизайном означает упущенные возможности для инноваций и роста.
Непонимание работы дизайнера со стороны менеджера/руководителя
Для создания выдающегося интерфейса критично погружение в контекст задачи: необходимо осознать цели, важные метрики, особенности продукта, его исторический фон, причины принятия предыдущих решений, их плюсы и минусы, а также технические ограничения и доступные данные. Это задание уже заметно сложнее, чем просто «создать интерфейс», верно?
Иногда менеджеру проще упростить роль дизайнера до рисовальщика интерфейсов, не участвующего в принятии ключевых решений. Это не продуктивно. Дизайнеры могут предложить решения, требующие значительных ресурсов для реализации, но которые могут принести значительные преимущества после внедрения. Иногда руководство готово к таким изменениям, видя в них долгосрочную выгоду.
Можно задаться вопросом: зачем делать лишние движения и тратить ресурсы разработчиков, когда можно по-быстрому внедрить решение, которое не потребует множества ресурсов — этакая заплатка, которая хоть как-то будет решать задачу?
В этом случае проблема часто заключается в нахождении равновесия между интересами менеджмента, бизнеса и разработчиков, и в том, как именно эти интересы можно сбалансировать для достижения оптимального результата.
Нет понимания ценности дизайн-системы и переиспользуемых компонентов
Представьте что у вас три дизайнера, которые работают над своим кусочком продукта, и между ними нет отлаженной коммуникации. Итог: у вас уже 25 видов различных кнопок, 30 шрифтов, и никто не знает, сколько цветов использует эта тройка творцов. А теперь представьте что ваш продукт активно растёт и масштабируется. Как поддерживать всё это? Нанимать ещё больше разработчиков?
Решением является создание единой дизайн-системы: начиная с базовых элементов, таких как шрифты и цвета, и двигаясь к унификации ключевых компонентов, включая кнопки и поля ввода. Этот подход требует тесного сотрудничества с разработчиками для внедрения и поддержания дизайн-системы, что ускоряет разработку, упрощает поддержку и гарантирует консистентность продукта.
Руководителю.
Поддерживайте консистентность в продукте, инициировав процессы создания дизайн-системы для дизайнеров и сторибука для разработчиков.
Сломанная коммуникация с командой разработки
Классический вариант работы на фрилансе выглядит так: сделал дизайн, отдал его разработчикам, они что-то сделали, результат ушёл клиенту. К сожалению, и во многих продуктовых компаниях иногда практикуется такой подход. Это порождает множество минусов: отсутствует глубокое обсуждение возможностей технологий и ограничений со стороны разработки. Когда дизайнеры не понимают технические аспекты продукта, их решения могут быть нереализуемыми или дорогими в исполнении. С другой стороны, разработчики без чёткого понимания того, что придумал дизайнер, могут неправильно воплощать идеи, что приводит к расхождению финального продукта с первоначальным дизайном. Отсутствие дизайн-ревью также усугубляет эти проблемы и ведёт к несоответствию и отсутствию консистентности в продукте.
Дизайнер и разработчики должны дружить. Решение простое: укрепление сотрудничества между дизайнерами и разработчиками через обязательные дизайн-ревью перед финализацией изменений.
Бизнесу.
— Коммуникация между дизайнерами и разработчиками должна стать неотъемлемой частью работы команды.
— Обязательна презентация дизайна команде разработки на ранних этапах проектирования.
— Необходимо наладить процесс дизайн-ревью для контроля качества внедряемых решений.
Недостаточное развитие дизайн-инфраструктуры и процессов в компании
Насколько эффективно работает ваша дизайн-команда, какие процессы у вас налажены? Получает ли дизайнер задачу в Jira, или же у вас есть несколько раундов обсуждения задачи с продукт-менеджером и разработчиками, включающие глубокое понимание контекста, бизнес-задач, ключевых метрик и сроков реализации?
В идеале дизайнер начинает с обсуждения задачи с командой и менеджером, переходит к этапу анализа конкурентов и разработки дизайна, а затем возвращается к команде на раннем этапе проектирования, чтобы поделиться идеями. На этом этапе разработчики могут поднять вопросы о необходимости доработок в существующих бэкенд-системах.
Что касается макета, то в нём должны быть чётко описаны точки входа и флоу пользовательских действий, учтены все возможные состояния. Когда дело доходит до передачи файлов в разработку, важно, чтобы поток был детально описан, учитывая все состояния и особые случаи. Если речь идёт о вебе, необходимо подготовить всё для демонстрации поведения на экранах различных размеров.
Дизайнер — одна из важнейших единиц в вашем бизнесе-механизме, и критически важно, чтобы он имел возможность не просто делать макеты, но и влиять на процессы в компании. Самое интересное, что продуктовый дизайнер — действительно подходящий для этого человек, учитывая его балансирование между задачами бизнеса, пользовательскими потребностями и ограничениями разработки. Я видел множество примеров, когда дизайнер, подключённый к решению проблемы на раннем этапе, кардинально менял условия игры и экономил колоссальное количество ресурсов компании. Видел и обратное, когда человек был зажат рамками недопонимания и отсутствия ресурсов, потихоньку выгорал и уходил, не в силах ничего изменить. Выбор за вами.
Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.
