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

История Екатерины Лаврентьевой, которая из дизайнера интерфейсов перешла в продуктовый дизайн. Споров «кто лучше» не будет, но пять личных выводов о профессии в материале найдёте.

До Совести я около года была junior дизайнером интерфейсов в небольшой студии. Там я получила базовые знания о UI и UX, рисовала аккуратные лэндинги, многостраничные сайты для разных заказчиков. Сменить место работы меня привело желание развиваться, в начале прошлого года под термином «развитие» я понимала возможность полноценно применять метрики и исследования на практике, понимать, зачем вообще я проектирую ту или иную вещь.

За год работы дизайнером группы разработки карты рассрочки Совесть я смогла многому научиться, пережила сильный личностный и профессиональный апгрейд. И сейчас за моими проектами стоят метрики, результаты качественных исследований, переговоры с продактом, бизнесом и командой разработки.

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

Работа в продуктовой команде сильно изменила понимание Human centered design. Раньше я считала, что «создать дизайн для человека» – это значит создать нечто интуитивно понятное по гайдам и с учётом трендов визуализации. А сейчас я понимаю, что всё гораздо сложнее и интереснее. Этот подход предполагает в первую очередь то, что мы пообщались с пользователем и/или посмотрели аналитику, чтобы оценить потребности перед тем, как приступать к отрисовке интерфейса или его изменению.

Понять пользователя и достичь контакта с ним можно разными способами: мы собираем данные от колл-центра (с какими вопросами относительно сайта или приложения звонят клиенты), из отзывов в сторах и обсуждений в соцсетях, приглашаем в офис ребят для проведения UX-тестов и глубинных интервью. Строим с клиентами CJM’ы, показываем прототипы, собираем фидбэк и проверяем гипотезы. Вы можете сделать сразу несколько вариантов кнопки, протестировать её на реальной аудитории и оставить ту, что работает эффективнее.

Так, например, у бизнеса была идея использовать в мобильном приложении свитчеры в рамках информирования об опциях на вкладке «Моя карта», с целью повышения конверсии их подключения. С точки зрения дизайна возникали сомнения в правильности применения нативного контроля ненативным, но UX-тесты показали, что люди не чувствуют фрустрации, нажимая на свитчер и видя экран подключения, а не анимацию с включением свитчера. А/Б тест также подтвердил, что свитчеры действительно справляются с задачей лучше, чем тэги.

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

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

Тем не менее, иногда бизнес-подразделение (маркетинг, операционное управление, департамент клиентского сервиса и прочее) при постановке задач может требовать реализации готового решения, не исследуя и не поясняя проблему, которую решаем. Это неправильный подход: не всегда и не все идеи стоит реализовывать, некоторые задачи могут не покрывать затраченных на них ресурсов, а разработка – это всегда дорого. Поэтому важно выстраивать с бизнесом правильный диалог. Чтобы этого достичь, необходимо понимать, почему компания принимает сейчас те или иные решения, с какими вызовами сталкивается бизнес, какие модели монетизации у продукта, почему в приоритет берутся определенные задачи и на какие KPI они нацелены.

Чтобы правильно провалидировать внедрение фичи, необходимо задать ряд вопросов:

• Какую проблему мы хотим решить и каких результатов достичь?
• Проблема действительно существует? Откуда вы знаете, что проблема реальна (данные аналитики, истории пользователей и прочее)?
  
• Какой масштаб проблемы?
  
• Можно ли решить проблему без разработки?
  
• Что случится, если фичу не реализовывать?
  

Приведу пример: механика реферальной программы в «Совести» «Приведи друга» была реализована с помощью стороннего подрядчика, поэтому пользователю было необходимо пройти несколько шагов аутентификации. Всё это затрудняло возможность привлечения новых клиентов и требовало дополнительной итерации при подсчёте денежных начислений. Пересмотрев процесс и подключив к нему разработчиков, мы упростили клиентский путь и стали полностью контролировать процесс получения денежных бонусов при удачном использовании сервиса на своей стороне. Таким образом, привлечение разработчиков стало оправданным, поскольку позволило за неделю увеличить количество заявок на карту через этот инструмент в 9 раз.

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

Если вы не будете поддерживать связь с разработкой, есть риск, что вы принесёте ей космолёт, который невозможно сделать лишь потому, что вы не учли те или иные ограничения на стадии проектирования, в результате макет придётся переделывать ASAP, а это потерянное время и деньги. Поэтому важно, чтобы продуктовый дизайнер общался с разработкой на протяжении всей работы над лейаутами. Как это сделать? Запланируйте регулярные промежуточные встречи с командой разработки, показывайте наброски, получайте обратную связь. В идеале — начинайте работу над фичей со сторимэппинга или бумажного прототипирования вместе с разработчиками, а уже потом приступайте к макету.

Общий язык найти не сложно, если вы действительно слушаете друг друга, а не пытаетесь исключительно продавить свою точку зрения. В «Совести» есть backend разработчики, web, android и ios разработчики (суммарно порядка 50 различного уровня специалистов). Работа выстроена по принципам Agile, что позволяет нам кооперироваться на всех этапах работы над дизайном, а также обеспечить большую погружённость всех членов команды в процессы, повышает ответственность, заинтересованность и мотивацию. Как следствие, это отражается на результате и качестве продукта, в том числе в части дизайна. А ещё у наших разработчиков есть доступ к Figma, где они в любой момент могут подсмотреть за готовящимися макетами.

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

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

• Количество уникальных пользователей (сколько человек пользуются приложением в течение определенного времени – дня, недели или месяца, какова регулярность использования).

• Сессия (насколько продолжительным является взаимодействие человека с приложением, какие экраны он посещал, как именно и через сколько по времени завершил сессию).
  

• Взаимодействие с интерфейсом (какие кнопки и в какой последовательности нажимал человек, как реагирует на различные эксперименты или А/Б тесты).
• Удержание пользователей (как часто и с какой периодичностью человек возвращается в приложение и почему).
• Доход (если имеется платный контент или через приложение совершается покупка, необходимо знать, какое количество людей ими пользуется, какова средняя прибыльность пользователя, сколько денег приносит продукт).

Так, например, фиксируя данные по взаимодействию с интерфейсом в разделе «Опции», мы обнаружили низкую конверсию проваливаемости внутрь каждой из них. Люди просто не понимали, что на карточки можно нажать и получить дополнительную информацию. С помощью UX тестов мы нашли более оптимальный вариант, решающий задачу информированности об опциях.

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

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

Год-полтора назад мне хотелось делать всё максимально быстро и круто, но со временем — путём проб и ошибок — я поняла, что в условиях работы над сложными задачами, которые требуют большого объёма переговоров, исследований и тестирований, лучше не форсировать события и не предлагать сразу же первое пришедшее и подходящее под задачу решение. Конечно, иногда нет временных возможностей «на подумать», но, если условия позволяют побольше поисследовать, используйте этот шанс.

Например, когда мы запускали возможность клиентам переводить средства с карты «Совесть» на другие банковские карты, то появился вопрос, как корректно расположить новую услугу в мобильном приложении. Применив логику (баланс и операции с деньгами должны быть в одном месте) и вспомнив про паттерны, мы решили «поселить» «Переводы» рядом с кнопкой «Пополнить» на экране «Моя карта». Чтобы не усложнять путь клиента, мы отказались от кнопки «Включить» в контексте переводов и поставили лигал под кнопкой. Однако экран всё равно выглядит перенасыщенным информацией. Сейчас мы разрабатываем альтернативные варианты, которые позволили бы нам, допустим, увеличить количество шагов, но упростить использование.

Продуктовый дизайн — это не только аккуратный и понятный дизайн (не использую слово «красивый», так как «красота» — понятие субъективное). Продуктовый дизайн — это жизнь в состоянии постоянного исследования, подкреплённого опытом и знаниями.

Для начала необходимо уточнить состав продуктовой команды и насколько детально распределены роли в части дизайна (выделены ли UI/UX специалисты в отдельное направление или требуется «человек-оркестр»). Также важно узнать, как организован поэтапно процесс разработки дизайна и какие специалисты в него вовлечены. Учитывайте собственные скиллы, задавая этот вопрос. Например, если вы хотите в дальнейшем прокачаться больше в метриках исследований, спросите о том, как происходит процесс работы над фичей, как понимают, что выпущенное на прод — успешно, есть ли в библиотеке книга «Статистика и котики», наконец:)

Кроме того (и это важно), — не забудьте «на берегу» уточнить перспективы и возможности карьерного роста, имеется ли план развития специалиста в компании. И помните, что любые процессы (даже сильно устоявшиеся) можно выстроить иначе, если вы понимаете, зачем и как это нужно делать, умеете аргументировать свою позицию и окружены людьми, осознающими неизбежность изменений для достижения наилучшего результата.