Часто сталкиваюсь с тем, что люди смешивают понятия продуктового дизайна и UX/UI-дизайна. Это делают и работодатели, и работники, и даже авторы образовательных программ. Кто-то считает, что это просто разные названия одной и той же профессии. Также есть мнение, что продуктовый дизайнер — это просто очень хороший дизайнер интерфейсов, который делает всё то же самое, только лучше. Я даже знаю одну хорошую школу дизайна, где главным отличием продуктового дизайнера называют то, что он занимается мобильными приложениями. В этой статье я хочу рассказать, в чём же заключается роль дизайнера продукта и чем она отличается от роли дизайнера интерфейса. И как это проявляется на практике.
На самом деле всё очень просто. Продуктовый дизайнер должен, в первую очередь, решать задачи продукта. Сместить фокус внимания с пользователя и поставить в центр баланс между пользователем, бизнесом и разработчиками. Конечно, чем удобнее будет приложение для клиентов, тем лучше бизнесу. Однако при проектировании необходимо решать основную бизнес-задачу и примерно понимать стоимость разработки и внедрения той или иной функции. Таким образом, вместо пользователя, стоящего в центре, возникает треугольник: бизнес — пользователь — разработчик, работая внутри которого продуктовый дизайнер должен находить тонкий баланс и предлагать оптимальное решение.
Рисуя новый экран, продуктовый дизайнер думает не только о том, как это будет удобно пользователю, но и о том, как это решит бизнес-задачу, и является ли оптимальным с точки зрения затрат ресурсов отдела разработки. В итоге дизайнеру для успеха продукта нужно поменять своё отношение к проектированию примерно так…
Конфликт интересов пользователя и владельцев приложения и технические ограничения
Почему же нельзя просто поставить в центр пользователя и просто спроектировать самое удобное приложение, которое лучшим образом решит его задачи? Всё дело в том, что в реальности существует конфликт интересов между пользователем и владельцем приложения. Обычно это необходимость монетизации продукта или сайта, чтобы у компании-разработчика и команды разработки были ресурсы на разработку и поддержку этого продукта. Но возможны и другие варианты, не связанные с деньгами.
Кроме этого конфликта, при проектировании нужно понимать стоимость реализации. Не только знать технические ограничения, но и в принципе понимать, как работает разработка, и создавать интерфейс таким, чтобы на его реализацию было затрачено как можно меньше ресурсов разработчиков. Выбирать способы, наименее затратные и сложные в реализации.
Как же этого достичь?
Первое — узнать бизнес-задачи продукта. Это может быть захват рынка, максимизация прибыли, снижение издержек компании, необходимость шокировать аудиторию уникальным дизайном, максимально быстрый запуск MVP и т. д. Нужно как можно глубже погрузиться в контекст, для чего нужно построить коммуникацию с product-owner’ом и руководством продукта. И при постановке новых задач сразу узнавать или вырабатывать бизнес-цель.
Второе — изучение пользователя. Изучение потребностей аудитории, создание сценариев, проектирование user flow и т. д. То, что составляет суть работы дизайнера интерфейсов.
Третье — изучить технические ограничения. Это можно сделать, создав хорошую коммуникацию с разработчиками. Необходимо подключать их на самых ранних этапах проектирования экранов и построить постоянный диалог, сделав их полноправными участниками процесса проектирования, предоставив им право голоса. Если отладить этот процесс коммуникации с отделом разработки, со временем продуктовый дизайнер уже сам начнёт понимать ресурсоёмкость той или иной функции и способы оптимизации интерфейса, которые позволят экономить ресурс.
И последнее. Метод, которым мы будем искать этот баланс — это итеративный подход с постоянным сбором обратной связи и доработкой пользовательских сценариев по результатам. Только так продуктовый дизайнер сможет решить эту задачу и найти оптимальное решение.
Именно такой трёхсторонний взгляд позволит видеть всю картину, а постоянное тестирование и сбор обратной связи позволят находить баланс при принятии решений в процессе проектирования интерфейса. Как на стратегическом уровне, так и во всех мелочах вплоть до выбора формы кнопок и размера иконок.
Пример из практики. Как работает дизайнер продукта.
Чтобы вам было понятно, о чём я говорю, я хотел бы продемонстрировать этот подход на примере решения практической задачи. Это реальная задача из практики одного из моих коллег, но для простоты изложения я постараюсь максимально её упростить и отбросить некоторые шаги и детали, несущественные для демонстрации описанного мной подхода.
Допустим, у нас есть приложение по доставке еды, и нам поступила задача добавить туда новую функцию — возможность оставлять чаевые курьеру, который принёс нам заказ. Надо заметить, что для продуктового дизайнера это основной тип задач — не создание нового приложения с нуля, а улучшение и доработка существующего.
Решению задачи UX/UI дизайнером. Пользователь в центре.
Сначала попробуем поставить себя на роль дизайнера интерфейсов и будем использовать подход, в центре которого стоит пользователь. С чего мы начнём? Конечно, нужно пойти к нашим пользователям, изучить их поведение и желания, понять, что им нужно от этой функции, и на основании этого предложить наилучшее решение, которое улучшит их пользовательский опыт. А потом проверить, насколько пользователи удовлетворены.
Допустим, мы провели некий опрос, чтобы узнать, какой процент пользователей хочет оставлять чаевые, а также сколько людей вообще не любят этого делать. Здесь я, конечно, упрощаю, и исследования должны быть более глубокими, но для этой демонстрации этого достаточно.
Итак, мы получили результат: всего 1,4 % людей хотели бы оставлять чаевые в приложении, и при этом пятая часть не любит оставлять чаевые вообще. Получается, заботясь о наших пользователях, мы должны добавить где-нибудь небольшую кнопку, ведущую на диалог отправки чаевых, и сделать её не слишком яркой, чтобы не отвлекать и не раздражать большинство. Например, мы решим поставить её на экран успеха после успешной доставки. При нажатии на неё будет происходить переход на экран, где можно выбрать сумму чаевых и отправить их курьеру. И вот мы получили решение задачи, используя подход с центром на пользователе. Всё работает отлично, те, кто хочет оставлять чаевые, могут это сделать.
Продуктовый подход
А теперь поставим себя на роль дизайнера продукта. И, как я говорил раньше, вместе с изучением того, что нужно пользователям, попробуем понять, какие бизнес-задачи может и должна решить новая функция. Такие задачи чаще всего поступают от продакт-оунера, однако дизайнер может и сам их предложить, основываясь на своём понимании общей стратегии продукта. В нашем примере допустим, мы с командой решили, что это три основные цели.
Первое. Нам нужно собрать как можно больше чаевых. Это повысит доходы наших курьеров, сделает их счастливее, и они не уйдут к конкуренту, через приложение которого столько чаевых они бы не получили. Более того, в рекламе нашей службы доставки на бирже труда мы расскажем о том, как много чаевых получают наши курьеры, и переманим к себе самых лучших работников.
Вторая цель — улучшить отношения между курьерами и пользователями или по крайней мере не ухудшить их просьбами оставить чаевые. Будет здорово, если эта функция поможет покупателям видеть в курьерах живых людей, а не роботов. А курьерам чувствовать больше благодарности за их работу.
Третья цель — собрать дополнительную информацию о поведении пользователей, понять что им нравится и почему они оставляют чаевые, чтобы в дальнейшем улучшать наш сервис или дополнительно поощрять курьеров.
Как вы видите, все эти цели лежат вне запросов конечных пользователей приложения. И теперь задача продуктового дизайнера — найти тонкий баланс между интересами пользователей и бизнеса. Спроектировать такой интерфейс, который решит цели бизнеса и не ухудшит пользовательский опыт.
Шаг 1. Выносим запрос чаевых на экран успеха
Для простоты, мы будем вносить изменения в рамках того же экрана успеха, который мы модифицировали ранее. Возьмем тот же сценарий, но теперь подумаем что нам можно здесь изменить чтобы увеличить количество чаевых, решить первую бизнес-задачу. И для этого вынесем на экран тот функционал, который был скрыт под второстепенной кнопкой. Теперь не нужно делать лишний клик и пользователь сразу видит предложение конкретных сумм чаевых. Для увеличения конверсии, мы можем показать этот же экран когда пользователь в следующий раз откроет наше приложение, напомнить ему что он может оставить чаевые по прошлому заказу.
Допустим, мы внедрили эту функцию в тестовом режиме, провели небольшое тестирование и увидели что это изменение интерфейса увеличило объем чаевых. Но, как и ожидалось по результатам опросов пользователь, решение имело и негативные последствия. В отзывах многие отметили что их немного раздражает эта навязчивость и им не нравится что приложение просит платить дополнительно. Появились вопросы какой процент от чаевых достается курьеру, а сколько забирает компания. И вообще отношение к нашему приложению несколько ухудшилось. Таким образом мы сдвинули решение от пользователей в сторону бизнес-задачи. Чаевых стало больше, пользователи стали менее довольными.
Шаг 2. Делаем запрос дружелюбнее
Теперь идем дальше. Собрав этот первый фидбэк, а также держа в голове другие бизнес-цели, команда решила улучшить сценарий, переделав экран следующим образом:
Как вы видите, была добавлена информация кому идут чаевые — имя и фото курьера, а также текст о том что он получает всю сумму чаевых без комиссии. Кроме этого команда добавила в анкете курьера строку “цель, на которую я коплю деньги”, чтобы показать ее в приложении. При этом фото курьера в базе данных уже было, так что доработка не была слишком трудоемкой. По нашему замыслу, это должно повысить доверие к нашей функции и еще сильнее мотивировать дать чаевые. Ведь гораздо понятнее заплатить 100 рублей обычному парню Александру чтобы он накопил на поездку, чем передать деньги службе доставки. И даже если мы не будем платить чаевые — приложение еще раз напомнит нам о том что еду нам принес живой человек у которого есть свои желания.
Теперь мы проводим следующие тестирование и видим что данная модификация экрана еще больше увеличила общий объем чаевых и снизила практически до нуля количество негативных отзывов в опросах. Даже не смотря на то что этот экран появлялся перед началом работы с приложением. Кроме того, подтвердилась гипотеза что изображение и имя курьера на экране успеха вместе с его целью улучшит в целом отношение к ним со стороны покупателей. Например, это было подтверждено в регулярных опросах курьеров об отношениях с покупателями. Таким образом этот интерфейс уже работает на решение двух из трех задач бизнеса.
Шаг 3. Добавляем опрос.
К моменту теста второй версии накопилась статистика и дополнительная обратная связь. Выяснилось, что даже те кто не оставляет чаевые стали больше времени проводить на экране успеха, а служба поддержки стала получать одинаковые вопросы — некоторые пользователи не понимали что нажать чтобы не платить чаевые. Им было не очевидно что нажимая на кнопку закрыть, по умолчанию, они не платят ничего.
Делаем следующий шаг. Кроме того что нам нужно решить эту проблему, мы решили сделать еще одну модификацию. Спросить у тех кто решил оставить чаевые почему они это сделали. Что им понравилось. Чтобы на основании этой информации дополнительно поощрять курьеров и поставщиков а также улучшать сервис в тех местах, за которые будет собрано меньше голосов.
В новой версии была добавлена опция “не оставлять чаевые” выбранная по умолчанию, что решило проблему с непониманием. Теперь стало очевидно, что закрывая экран пользователь ничего не платит. Также при выборе любого объема чаевых раскрывается список где пользователь может выбрать что конкретно ему понравилось (или не выбирать ничего). В дальнейшем эти опросы помогли собрать много важной информации и о пользователях, и о курьерах и о сервисе.
Шаг 4. Технические ограничения.
Итак, мы получили решение всех бизнес-целей, и постарались уменьшить неудобство пользователей, чтобы интерфейс оставался дружелюбным. Однако, к примеру, при передаче в разработку столкнулись с ограничением. Оказалось что если каждый раз высчитывать чаевые в процентах от заказа, это потребует слишком значительных затрат времени разработчиков, и выделения дополнительных ресурсов, которых в данный момент нет. И мы решаем указать некоторые фиксированные значения чаевых, высчитав их от среднего чека. Отдел разработки говорит что такое реализовать сейчас можно и тогда мы убираем из интерфейса проценты и оставляем только фиксированные цифры. В результате получаем такой экран. С точки зрения целей юзера и бизнеса все тоже неплохо, и разработчики смогут сделать эту функцию в срок.
И вот перед вами финальное решение. В приложение добавлена функция выплаты чаевых таким образом чтобы учитывая интересы пользователя реализовать наши бизнес-цели, и вписаться в технические ограничения. Конечно, улучшения можно продолжить и дальше. К примеру, поощрять пользователей ачивками за оставленные чаевые. Например, написать оставившему чаевые клиенту что курьер накопил на поездку и прислать фотографию Александра из Таиланда (если он не против).
Возможно, я не учел множество нюансов, а многие важные этапы проектирования опущены. Но, надеюсь, мне удалось показать самое главное на этом примере. А именно чем отличается роль продуктового дизайнера от роли дизайнера интерфейсов, который ставит в центр пользователя. И как продуктовый дизайнер находит оптимальное решение задачи, используя итеративный подход и собирая обратную связь.
В заключение могу добавить что хоть мы и решали задачи бизнеса в этом примере, в конечном счете внесенные изменения должны улучшить и пользовательский опыт. Ведь если мы их достигнем, то привлечем более мотивированных курьеров, получим информацию для улучшения сервиса и построим более дружелюбную атмосферу. И в итоге сделаем продукт лучше для всех.
Спасибо за внимание.
ссылка на оригинал статьи https://habr.com/ru/articles/849526/
Добавить комментарий