Дизайн

Product Designer: шо ты такое?!

09 сентября 2020

 

Периодически мне в LinkedIn пишут с предложениями о позиции продакт диза, вот только описание позиции часто содержит в себе: создание прототипов, разработка UI проекта, графика какая-нибудь и шо-то еще. Серьезно?! Это даже занятостью UX дизайнера не назвать (что в целом я бы особо и не разделял, ибо оно +- схоже, как по мне, разве что отдельно можно добавить сервис-дизайн к скиллам продакта, но то уже отдельная история, которую тут я затрагивать не буду, главное сейчас по полочкам разложить основное), ибо сделать прототип просто из головы и его обрисовать – это не проектирование пользовательского опыта, это просто проектирование интерфейса, которое никак вообще не связано с пользовательским опытом ЦА данного продукта (и это хорошо еще, когда этого типа продакта берут с экспертизой в сфере деятельности продукта, а когда и ее нет – беда-печаль). 

 

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

 

А теперь давайте с самого начала (да простят меня менеджеры и аналитики – я ни в коем случае не преуменьшаю написанным далее их роль в разработке продукта). Если вы введете в гугл-переводчике “to design”, то получите перевод не “рисовать картинку” и не “плясать под дудку заказчика”, а “проектировать”. Еще раз повторим для закрепления фразу из предыдущего абзаца: проектировать интерфейс и проектировать пользовательский опыт – это две большие разницы. 

 

Проектирование и разработка продукта начинаются далеко не с прототипа, а с изучения контекста. Но об исследованиях я уже писал и говорил на ютубе отдельно, потому просто усвоим, что надо изучить боли и потребности ЦА, нужно изучить рынок, требования инвесторов, конечно же задокументировать это, а дальше не бросаться лупить все подряд (ибо мы же получили уже “задание”, верно?), дальше нужно понять что действительно необходимо вывести на MVP. Для этого неплохо подходит та же модель Кано (погуглите что это, а то объяснять ее тут – это отдельная статья будет), через которую мы просеиваем все полученные требования и разделяем их на 5 категорий (обязательные, одномерные, привлекательные, неважные и нежелательные), чтобы затем выделить что нам навредит и отбросить это, выделить набор фичей на MVP и остальное оставить для последующих фаз разработки.

 

Продакт должен говорить на одном языке с пользователями, т.е. не стесняться составлять глоссарий в ходе исследований. В ходе всей разработки продакт должен влиять на процессы, связывающие косвенно или напрямую выполнение пользователями своих задач и взаимодействие их с продуктом (но тут уже начинается сервис-дизайн и это тоже на отдельную статью по объему тянет, так что гуглите что это такое отдельно). Далее идет конечно же все то, что я уже описывал (к примеру, тут) ранее. Подробнее добавлю о тестировании: тестирование – это не только выполнил задачу или нет, это не только заметить отступление от сценария при выполнении. Всегда измеряйте показатели при тестировании, чтобы в дальнейшем был виден прогресс (сразу или уже после релиза вы в любом случае будете понемногу выкашивать косяки в интерфейсе, которые могут возникнуть из-за ряда факторов). Основное, что стоит замерять:

  1. Количество успешно выполненных задач (если после тестирования второго варианта интерфейса количество пользователей, которые успешно прошли по какому-то пути, стало меньше – увольтесь тихо и не портьте продукт)
  2. Количество ошибок (ошибка – это не невыполнение задачи, ошибкой так же считается и отклонение от основного и самого короткого пути)
  3. Время для выполнения задачи (все просто: чем быстрее – тем лучше)
  4. Удовлетворенность пользователей (да, качественная, а не количественная, метрика, но тоже надо учитывать и опрашивать на предмет возможных улучшений)
  5. Если же у вас есть 2 и более варианта пути от точки входа к следующему шагу во флоу (например, навигация и строка поиска для интернет-магазинов и подобных сервисов), то нужно замерять чем пользователи больше пользуются, дорабатывать неработающую составляющую
  6. Эффективность обучения пользователей (конечно же это не касается простеньких магазинчиков и пр, но ведь на таких проектах продакты и не работают. Рекомендую погуглить разные виды онбординга, ознакомиться и в дальнейшем, если необходимо, выбирать подходящий вид, чтобы и пользователя не перегружать со старта, и доступно объяснить ему что тут нужно делать, чтобы не продать душу дьяволу за выполнение какой-то задачи)
  7. Еще куча и куча показателей, которые могут быть уникальными для вашего продукта

 

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

 

Или же на нашем последнем проекте (НДА, все дела, так что без названий) пользователь при восстановлении пароля получает код и идет отсчет времени (60 сек) до ресенда. Если пользователь нажал назад при этом, то нам надо определиться: если он потом опять вернется к восстановлению, то мы будем каждый раз так задрачивать сервак запросами или же покажем ему для ресенда тот отсчет, который начался несколькими секундами ранее. 

 

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

 

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

  1. Мониторить поведение пользователей в текущей системе и выкашивать косяки/улучшать показатели
  2. Если у вас есть служба поддержки или просто возможность отправить фидбэк, то прорабатывать эти тикеты. Если нет (что само по себе уже днище), то неплохо быть на связи с ЦА и собирать хотя бы раз в квартал фидбэк где и что можно улучшить
  3. Мониторить рынок и предлагать варианты развития продукта

 

А еще у меня дико горит по поводу описаний вакансий. Как я уже писал ранее, нередко аутсорс-компании пишут о том, что нужен продакт, а в итоге ты приходишь на проект, рисуешь интерфейсы и играешь на кожаной флейте заказчика каждый раз, когда хочешь хоть что-то сделать хорошее, а не рисовать “хотелки”. И я никогда не понимал градаций Junior/Middle/Senior Product Designer. Это как вообще? Мало того, что джун точно не может быть продактом в виду неопытности, так еще и в целом это в корне переворачивает суть позиции продакта: продакт – это человек, который проектирует продукт, остальные могут ему помогать, но ПРОДАКТ ОДИН и никак не ранжируется. Я могу еще понять Lead Product Designer, когда у вас куча продуктов объединяются в один и он как бы возглавляет все это и сводит воедино, но тут уже все настолько размыто, что это уже чисто менеджер, скорее. 

 

Ну а пройти курс обучения полноценного продуктового дизайна можно тут 🙂 

Почитай еще 3 последних статьи: