Как эффективно решить дизайн-задачу: задаём продакт-менеджеру правильные вопросы
Всем привет! Меня зовут Богдан, я работаю дизайнером внутренних продуктов в компании, которая соединяет клиентов с ведущими экспертами отрасли с помощью технологий, и ревьюером на курсах «Веб-дизайнер» и «Дизайн интерфейсов» в Яндекс Практикуме. После пяти лет работы в стартапах я понял, что самое интересное ждёт нас, дизайнеров, впереди. Искусственный интеллект, виртуальная и дополненная реальности изменят подход к дизайну, а высокая конкуренция заставит предлагать всё более инновационные решения — и всё это, как мне кажется, сделает интерфейсы сложнее.
Уже сейчас всё больше компаний осознают важность качественного дизайна и проработанного пользовательского опыта. Поэтому дизайнеры чаще сталкиваются со сложными и запутанными проектами.
Чтобы выполнить работу хорошо, дизайнер должен уметь задавать продакт-менеджеру правильные вопросы. В этом тексте я расскажу о пяти важных правилах, которые помогают мне предотвращать недопонимания на первых этапах работы, выстраивать коммуникацию и эффективно решать конкретные дизайн-задачи.
Исходные данные
Я буду писать о реальном примере, с которым столкнулся в продуктовой компании. Условия были следующие: у меня был доступ к продакт-менеджеру, пользователям и команде разработки, а все участники были в курсе происходящего с проектом. Скорее всего, при работе в студии или на аутсорсе вопросы и порядок действий будут отличаться, но принцип всегда один.
Не начинай работу, пока на 100% не понимаешь, что нужно сделать
Итак, наш пример. Мы согласуем работу во внутренней CRM-системе. Менеджеры создают проекты, к этим же проектам присоединяются эксперты из внутренней базы.
За годы работы на платформе были созданы тысячи проектов, многие из которых похожи друг на друга. Наша задача — научить систему искать похожие проекты с помощью искусственного интеллекта, чтобы быстро находить релевантных экспертов на основе прошлого опыта. Поиск должен запускаться после создания каждого проекта.
Как видно, задача большая и размытая. Непонятно, когда менеджер должен видеть интерфейс новой функции, как именно система будет определять проект как похожий, как эта задача решается на сегодняшний день и решается ли вообще, — это лишь малая часть вопросов. Чтобы понять, с чего начать, нужно ответить на каждый из них.
Если вы новичок и оказались в похожей ситуации, не паникуйте — лучше используйте мой список вопросов и соблюдайте простые правила, которые помогут пошагово разобрать цели и задачи вашего проекта.
Правило №1: изучите предыдущий опыт — в первую очередь свой
Ваша цель — узнать, что сейчас происходит с продуктом и как он развивался, есть ли похожие и как они используются. Продакт-менеджер должен знать все нюансы и рассказать вам о них. Если вы не получили полную информацию, необходимо её запросить. Вот несколько вопросов, с которых можно начать.
Возможно, где-то в продукте уже и спрятано решение текущей проблемы. Может, оно плохо реализовано, а может, просто устарело и не отвечает нынешним потребностям пользователей.
Если это так, у нас будет возможность пообщаться с предыдущими пользователями и узнать из UX-интервью, чего им не хватает в этой фиче.
Чтобы создать что-то новое, нужно закладывать больше времени на ресёрч, дизайн и разработку. Об этом важно предупредить продакт-менеджера. Особенно это критично для внутренних продуктов компании, которые обычно непросто (почти невозможно) найти в открытом доступе. Чем уже сфера компании, тем сложнее найти реальные примеры решения похожей задачи.
Далеко не всегда можно получить такую информацию сразу, но стоит поискать главных конкурентов. Помочь может даже скриншот на сайте компании или фотография под постом в социальных сетях.
Круто, если получится вместе с командой посмотреть, как кто-то решает похожую задачу, что в этом решении вас устраивает, что нет и почему.
Правило №2: сформулируйте, какой ждёте результат
Если вам указали на конкретный пример или аналогичный продукт — прекрасно, работать будет проще. Но такое происходит крайне редко (почти никогда).
Если вы создаёте что-то новое или кардинально улучшаете и перерабатываете старый продукт, вам важно знать, что должно получиться в итоге: что мы хотим дать пользователю, чем мы лучше конкурентов и какую мы видим пользу от продукта для себя.
Задайте продакт-менеджеру следующие вопросы.
Тут важно сфокусироваться не на конкретном представлении («вот тут мы разместим кнопку, тут ссылку, а здесь покажем результат поиска»), а на решении проблемы пользователя («менеджер видит, что новый проект похож на тот, что мы делали два года назад»).
В основе ответа на этот вопрос — не описание интерфейса фичи в деталях, а именно логика и use case.
Важно заранее понимать, как мы узнаем, удалось ли нам решить проблему пользователя: какие мы введём метрики для измерения его удовлетворённости и на какие критерии будем обращать внимание.
В моём примере таких критериев два:
количество найденных проектов, с которыми менеджеры продолжают работу, по отношению к общему количеству проектов в выдаче;
время, которое пользователь тратит на отсев релевантных проектов.
В процессе работы я проводил специальные UX-тесты, в которых засекал время с момента открытия проекта пользователем до вынесения им вердикта — похож проект или нет. После релиза мы повторили тест и увидели, что больше проектов стали релевантными, а время принятия решения сократилось.
Один из самых объёмных и важных пунктов. Отвечая на этот вопрос, вы должны тщательно описать механику работы с продуктом: какие целевые аудитории есть у фичи, когда и как часто они будут ей пользоваться и какие есть исключения в тех или иных сценариях.
При работе над большим и сложным продуктом в продакшн идёт не весь результат сразу — обычно фича развивается и дополняется поэтапно. При таком подходе лучше начать с идеального финального варианта дизайна, а уже потом упрощать его до необходимых итераций, которые будут уходить в разработку. Так вы сможете заранее продумать весь интерфейс и не переделывать его, когда придёт очередь добавлять новые функции. Разработчики смогут закладывать в код основу для того, что будет доделываться позднее. А пользователям будет удобно — не придётся привыкать к новому дизайну после каждой итерации.
Правило №3: учтите интересы бизнеса
Если вы работаете над продуктом, значит, он нужен бизнесу. Работа дизайнера — постоянный поиск баланса между нуждами работодателя и пользователя. Поэтому нам важно сразу понимать, насколько мы можем «размахнуться» в работе над текущим проектом. Есть ли у нас время и ресурсы на проведение UX-исследований? Или главное — сделать всё быстро и просто?
Спросите у продакт-менеджера:
Какие именно функции являются самыми важными для целей бизнеса и почему?
Какую метрику нам важно поднять в первую очередь?
Какие функции относятся к категории nice-to-have и насколько важно их реализовать?
Правило №4: узнайте технические требования
Если вы знаете, на что способна ваша команда, это будет плюсом. Продакт-менеджер не всегда может рассказать вам подробности о технических ограничениях проекта, но часто уже понимает, что мы можем сделать, а что нет, реализация какого решения займёт слишком много времени и чем его можно заменить.
Уточнить у него можно следующее:
Для каких устройств нужна фича? Веб, мобилка, планшет?
Есть ли какие-то технические ограничения, о которых мне стоит знать?
Также я рекомендую узнать, какая команда разработчиков будут работать над фичей, а потом созвониться с ними — проговорить своё видение и обсудить технические ограничения. Я не могу передать словами, насколько это полезно и сколько времени помогает сэкономить.
Правило №5: соблюдайте сроки
Чтобы уложиться в сроки и не подвести команду, также важно задать несколько вопросов на старте:
Когда дизайн должен быть готов?
Когда фича уходит в продакшн?
Какой приоритет у реализации продукта или задачи?
Если фича большая и сложная, договоритесь о синках, например, каждые три дня. Так вы сможете держать менеджера в курсе работы и будете уверены, что движетесь в нужном направлении. Это намного эффективнее, чем потратить две недели на работу, а потом узнать, что это «совершенно не то, что нужно», и не уложиться в дедлайн. А такое случается — даже не по вине дизайнера или менеджера, а из-за того, что поменялись требования, ограничения или приоритеты.
Это пример из моей практики, и он не универсальный. Уверен, со временем вы составите свой список вопросов — и в будущем вам будет проще создавать решения, которые не только эстетически привлекательны, но и функциональны и удобны для пользователей.
