Этап 3. Интервью, метод персон и JTBD #дизайнпроект
Меня зовут Юля, я продуктовый дизайнер в экосистеме Мир Привилегий.
В этом цикле статей я создам проект-концепцию мобильного приложения для портфолио, который пройдет все стадии формирования дизайн-проекта.
Тема “приложение для выбора мероприятий”.
Автор статьи — Юлия Слащилина
Связаться со мной — телеграм
Мой телеграм-канал “Другой дизайн”, где я делюсь опытом работы в продукте и пишу о дизайне.
Интервью
После формирования идеи, осознания ее места в мире и проведения даже небольшого анализа, нам нужно понять как именно ее реализовать, чтобы она по максимуму оказалась нужной и релевантной для клиента.
Раньше, когда я шла после школы по центральной улице своего города, меня время от времени приглашали куда-то зайти, чтобы ответить на пару вопросов, обычно это были какие-то компании вроде «Вкуснотеево» или подобного типа, и опросы, безусловно, были за небольшое вознаграждение — за их продукцию. Никогда не задумывалась, зачем это все делалось, пока не стала дизайнером. Иногда я отвечала, и девушка что-то записывала в бланк, а иногда приглашали в офис и приходилось недолго сидеть за компьютером, что-то щёлкая. А человек сзади меня наблюдал.
Сейчас опросы и интервью стали проще, легче привлекать людей, а так же точнее стала обработка данных, что тоже немало важно.
Продукт делается для людей. Чтобы людям он был нужен, мы должны понимать, чего они хотят. Проблема лишь в том, что они сами этого сказать зачастую не могут, так как не осознают многих своих потребностей, поэтому с помощью интервью, мы должны вывести пользователя на «чистую воду». Не прямо, а лишь подтолкнув его на правду.
Итак, интервью зачастую помогает найти и подтвердить проблему. Важно при ее поиске не зацикливаться уже на какой-то существующей проблеме, а тем более на ее решении, так как это ограничивает наше восприятие и вместо того, чтобы объективно делать выводы — мы ищем подтверждение нашим догадкам. Нужно задавать правильные, желательно, не прямые вопросы, на которые пользователи могут дать развернутый ответ. Вместо того, чтобы спрашивать о том, какая у него проблема в настоящем, лучше спрашивать о том, как он решал эту проблему в прошлом.
У меня тема поисков мероприятий. Вот так выглядели вопросы, которые я задавала при небольшом опросе.
Где вы находите мероприятия и события в городе?
Куда вы ходили на прошлых выходных? Как узнали о этом мероприятии?
Где вы покупаете билеты в кино, музей или театр? Купленные заранее билеты храните на почте, отметив, как важное?
Вы ходите куда-то после работы в будние дни? Или только по выходным?
Как часто вы ходите куда-то один? Почему?
Для вас имеет значение местность, где находится мероприятие? Как часто вы гуляете по городу?
Это вопросы, на которые можно дать точный ответ, который поможет мне в понимании того, как позиционировать свое приложение, какие функции включать. Также нужно учитывать, что они все задаются среди диалога, в контексте. Именно поэтому полезнее разговаривать с человеком вживую (с парой человек я поговорила на работе лично, а с другими списалась). Всего я поговорила лишь с пятью людьми, общая картина сложилась схожая. Плюс поискала отзывы пользователей на разные сервисы по схожей тематике, почитала мнения на форумах.
Важный момент: люди, которых вы изучаете и с которыми разговариваете обязательно должны отвечать целевой аудитории вашего продукта. Она может быть очень ограниченная или, наоборот, крайне широкой.
Интервью на самом деле сложная и глубокая тема для изучения и тем более проведения. В данном случае оно нужно как фундамент для обоснования релевантности функционала и аргументации принятых решений в проекте, которые будут в приложении. Это дает понимание того, как происходит работа над продуктом, доказывает ценность проекта, даже если он несуществующий.
В крупных компаниях есть отдельные исследовательские отделы с формировавшимися фокус-группами, в компаниях поменьше интервью проводится в более ограниченных рамках. Иногда, вообще нет ресурсов его проводить. Интервью — это не панацея, но очень важный инструмент. И на самом деле, даже если оно не проводится целенаправленно, всегда есть клиентский сервис, отзывы, метрики и обмен мнением в сети (если продукт раскручен), так или иначе общение с пользователями совершается, что при правильном подходе может дать не меньше нужной и важной информации, чем прямое интервью.
Тем не менее, оно необходимо для формулировки гипотез, понимания пользователей и того насколько продукт отвечает запросам.
Отличная статья про интервью.
Еще советую книгу «Продукт, который ждут». Там много о интервью и тестировании гипотез.
Метод персон и Job to be done
Метод персон.
После проведения интервью в идеале мы остаемся с каким-никаком пониманием того, кто наш клиент и в чем он в теории нуждается (это предстоит еще проверить).
По сути персона — это структурное и подробное описание целевой аудитории, собирательный образ человека(людей) для которой(которых) создается сервис, ключевое: это не просто набор фактов, а полноценный психологический портрет с мотивацией персоны и ее отношением к продуктам.
Если очень упростить, то создав несколько персон (которые отчасти могут даже противоречить друг другу) — мы должны найти такое решение, которое удовлетворит каждого — сделав интерфейс адаптивным, к примеру.
Зачем это нужно? Продукт, как бы он не старался, не сможет удовлетворить всех без исключения. Особенно, если есть чёткие критерии у целевой аудитории. Например, продукт для автомобилистов, не будет актуален в большинстве вопросов для пешеходов и тд. Зная для кого именно мы делаем продукт, отсекаются все возможные «но». Алан Купер (основоположник метода) давал имена своим персонам, и даже раздавал их разработчикам, чтобы они четко знали для кого делают продукт.
У нас в продукте при обсуждении функционала очень часто были баталии между коллегами, якобы «зачем это надо, вот я бы вообще этим пользоваться не стала» и наоборот. Зная, что ваша персона ТОЧНО использовала бы вашу фичу, лишние претензии отсекались бы сразу.
Работа должна быть сделана.
Метод, который якобы пришел на смену методу персон. Тем не менее, они немного разные и чаще друг друга дополняют, нежели чем спорят.
JTBD — это определение работы, которую должен выполнять продукт. Она более универсальна и не зависит от характеристик, которые у пользователей одного продукта могут отличаться.
Пользователи покупают продукт для решениях своих проблем. Нет разницы, кто этот человек, важно то, какая проблема может быть решена с помощью работы этого продукта. Один и тот же продукт может удовлетворять несколько запросов, что позволяет понять истинную мотивацию юзера, зачем он обратился к продукту. А так же разные продукты могут решить одну и ту же проблему.
Углубиться в понимание работы помогает Job Story, который строится по следующей формуле: когда (описание ситуации), я хочу (мотивация или изменение), чтобы (результат).
При составлении Job Story (да и везде, где могут формироваться гипотезы) важно не только опираться на интервью, но и вставать на место потребителей.
Подробнее о Job Story и о том, как правильно ее составить:
Отличная статья про JTBD и метод персон.
Таким образом для проекта в портфолио готов еще один блок с исследованием для развития концепции продукта.
Вот что вышло:
Следующим делом продумаем User Flow и набросаем CJM параллельно в первыми прототипами нашего проекта)
