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