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

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

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

Исходные данные

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

Не начинай работу, пока на 100% не понимаешь, что нужно сделать

Итак, наш пример. Мы согласуем работу во внутренней CRM-системе. Менеджеры создают проекты, к этим же проектам присоединяются эксперты из внутренней базы.

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

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

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

Правило №1: изучите предыдущий опыт — в первую очередь свой

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

• Это новая фича или мы улучшаем существующую?

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

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

• Насколько фича уникальна для рынка?

Чтобы создать что-то новое, нужно закладывать больше времени на ресёрч, дизайн и разработку. Об этом важно предупредить продакт-менеджера. Особенно это критично для внутренних продуктов компании, которые обычно непросто (почти невозможно) найти в открытом доступе. Чем уже сфера компании, тем сложнее найти реальные примеры решения похожей задачи.

• У каких конкурентов это уже есть?

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

• Есть ли референсы?

Круто, если получится вместе с командой посмотреть, как кто-то решает похожую задачу, что в этом решении вас устраивает, что нет и почему.

Правило №2: сформулируйте, какой ждёте результат

Если вам указали на конкретный пример или аналогичный продукт — прекрасно, работать будет проще. Но такое происходит крайне редко (почти никогда).

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

Задайте продакт-менеджеру следующие вопросы.

• Каким должен быть результат?

Тут важно сфокусироваться не на конкретном представлении («вот тут мы разместим кнопку, тут ссылку, а здесь покажем результат поиска»), а на решении проблемы пользователя («менеджер видит, что новый проект похож на тот, что мы делали два года назад»).

В основе ответа на этот вопрос — не описание интерфейса фичи в деталях, а именно логика и use case.

• Как мы проверим, что достигли цели?

Важно заранее понимать, как мы узнаем, удалось ли нам решить проблему пользователя: какие мы введём метрики для измерения его удовлетворённости и на какие критерии будем обращать внимание.

В моём примере таких критериев два:

• количество найденных проектов, с которыми менеджеры продолжают работу, по отношению к общему количеству проектов в выдаче;

• время, которое пользователь тратит на отсев релевантных проектов.

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

• Какие есть основные сценарии использования?

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

• Как будет развиваться фича?

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

Правило №3: учтите интересы бизнеса

Если вы работаете над продуктом, значит, он нужен бизнесу. Работа дизайнера — постоянный поиск баланса между нуждами работодателя и пользователя. Поэтому нам важно сразу понимать, насколько мы можем «размахнуться» в работе над текущим проектом. Есть ли у нас время и ресурсы на проведение UX-исследований? Или главное — сделать всё быстро и просто?

Спросите у продакт-менеджера:

• Какие именно функции являются самыми важными для целей бизнеса и почему?

• Какую метрику нам важно поднять в первую очередь?

• Какие функции относятся к категории nice-to-have и насколько важно их реализовать?

Правило №4: узнайте технические требования

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

Уточнить у него можно следующее:

• Для каких устройств нужна фича? Веб, мобилка, планшет?

• Есть ли какие-то технические ограничения, о которых мне стоит знать?

Также я рекомендую узнать, какая команда разработчиков будут работать над фичей, а потом созвониться с ними — проговорить своё видение и обсудить технические ограничения. Я не могу передать словами, насколько это полезно и сколько времени помогает сэкономить.

Правило №5: соблюдайте сроки

Чтобы уложиться в сроки и не подвести команду, также важно задать несколько вопросов на старте:

• Когда дизайн должен быть готов?

• Когда фича уходит в продакшн?

• Какой приоритет у реализации продукта или задачи?

Если фича большая и сложная, договоритесь о синках, например, каждые три дня. Так вы сможете держать менеджера в курсе работы и будете уверены, что движетесь в нужном направлении. Это намного эффективнее, чем потратить две недели на работу, а потом узнать, что это «совершенно не то, что нужно», и не уложиться в дедлайн. А такое случается — даже не по вине дизайнера или менеджера, а из-за того, что поменялись требования, ограничения или приоритеты.

Это пример из моей практики, и он не универсальный. Уверен, со временем вы составите свой список вопросов — и в будущем вам будет проще создавать решения, которые не только эстетически привлекательны, но и функциональны и удобны для пользователей.