Персоны

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

Зачем нужен метод персон?

Аргумент «персон» №1:

Персоны помогают держать в центре внимания потребности и проблемы пользователей, а не абстрактные предположения.

Контраргумент:

Собирательный образ никак не поможет держать в центре внимания проблемы пользователей, а точнее позволит держать их на максимально обобщенном уровне. Этот уровень, помимо того, что часто может меняться в частностях (которых не отражает «метод персон»), так еще и на верхних уровнях (обобщенных) не несет никакой существенной помощи в знаниях о пользователях.

Аргумент «персон» №2:

Дизайнеры и разработчики могут ориентироваться на конкретные сценарии использования, а не на обобщённые требования. Конкретный сценарий использования в рамках «персон» выглядит следующим образом: сценарии использования — это описания конкретных ситуаций, в которых пользователь взаимодействует с продуктом, с указанием: • Кто пользователь (например, персона "Елена, бухгалтер, 40 лет"). • Что она пытается сделать (например, заполнить отчёт для налоговой). • Где и когда это происходит (например, в офисе в конце рабочего дня). • Как она это делает (например, через Excel или ваш продукт). • Какие проблемы возникают (например, сложный интерфейс или нехватка времени).

Контраргумент:

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

Аргумент «персон» №3:

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

Контраргумент:

Здесь говорится о том, что «персоны» помогают решить проблему непонимания команды разработки в контексте того, для кого разрабатывается продукт. А создавая якобы общий ориентир вымышленного, но реалистичного пользователя, вокруг которого можно строить обсуждения, команда понимает, для кого этот продукт делается. Стоит ли говорить об очередной размытой и бесполезной по существу абстракции здесь? Если нет конкретных проблем (они не обозначены этим методом), то и решать нечего. Вся конкретика, которая будет высасываться из этих «персон», — лишь те же предположения, основанные на собирательном образе каких-то людей, что не раскрыли суть проблем, не дав ни ограничений, ни требований к разработке продукта.

Аргумент «персон» №4:

Персоны помогают оценивать, насколько решения соответствуют ожиданиям целевой аудитории.

Контраргумент:

Здесь и повторяться не стоит — всё уже сказано ранее по тексту.

Практическое применение

Также можно рассмотреть практические применения, в которых якобы помогает «метод персон». Можно выделить следующие пункты:

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

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

«Решения о разработке опираются на потребности ключевых персон».

Эти потребности могут оказаться ошибочным предположением, основанным лишь на собирательном образе и комментариях двух-трех человек, которые могут скрыть суть намерений и желаний. Строить на таком требования — значит лишь заполнить документацию ради её заполнения и использовать методологию ради её использования и соблюдения процесса (чем часто и занимаются люди).

«Сценарии персон используются для создания тестовых кейсов».

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

«Метод персон» слишком абстрактный метод определения желаний пользователей. Этот метод мало того, что не учитывает скрытые мотивы пользователей, так он ещё и не конкретизирует какие-либо нужды и потребности пользователей в целом. Он предлагает тебе набор персон (4–6 персон) — собирательные образы, которые основаны на формальных данных (например, "Елена хочет автоматизацию"). Они не учитывают, что на деле она может сопротивляться изменениям и не желать вашего продукта.

И тут какой-нибудь дизайнер с высоты своего опыта, отпив латте на кокосовом, возразит и скажет мне: «Но профессор Нельсон говорит, что персоны можно и нужно дополнить методом Jobs to Be Done (JTBD), чтобы они наиболее подробно раскрывали потребности пользователей». И я тебе, опытному и важному дизайнеру или исследователю, незамедлительно отвечу: в таком случае получится более конкретизированная структура в сути данных, но останется всё та же калька без особой пользы.

Jobs to Be Done (JTBD)

Для начала вкратце разберемся с термином и определением, основными принципами и философией подходов Jobs to Be Done.

Jobs to Be Done (JTBD) — это подход к разработке продуктов и услуг, основанный на понимании задач, которые клиенты пытаются выполнить в определённых ситуациях. Это методология, которая помогает компаниям создавать решения, ориентированные на реальные потребности пользователей, вместо того чтобы фокусироваться только на продукте или его характеристиках.

Существуют два направления подхода Jobs to Be Done:

1. Работа как прогресс или результат (Jobs-As-Progress) — продукт позволяет пользователю эволюционировать, упростив свое участие. Или вовсе полностью делегировать работу предлагаемому решению. Авторы этого направления: Клейтон Кристенсен, Алан Клемент, Карен Диллон.

2. Работа как активность (Jobs-As-Activities) — потребитель вовлечен в работу, но хочет, чтобы ее выполнение доставляло больше удовольствия, экономило время, было более технологичным. Автор теории: Тони Ульвик.

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

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

JTBD по Кристенсену был разработан как методология для создания инновационных решений, фокусируясь на понимании задач, которые клиенты хотят выполнить. Клейтон Кристенсен известен своими работами как раз в области инноваций, в частности теории «подрывных инноваций».

Но у нас народ повыдергивал из контекста метода формулу Job Story и применяет часто, где ни попадя. Снова, лишь стараясь показаться высокими профессионалами, «шарящими» в модных устаревших методах, пока мир мыслит и развивается дальше, они копируют и подражают каким-то глупцам. Но это уже другая история. Вернемся к нашим баранам.

Основные принципы JTBD (с комментариями автора)

«Люди «нанимают» продукты или услуги, чтобы решить конкретную проблему или достичь цели. Например, человек покупает дрель не потому, что хочет дрель, а чтобы просверлить отверстие в стене»

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

«Задачи клиентов зависят от конкретной ситуации, в которой они находятся. JTBD изучает, почему и в каких обстоятельствах клиент выбирает то или иное решение»

Люди могут выбирать решение не потому, что оно лучше решает задачу, а из-за страха осуждения, привычки или даже корпоративного принуждения. Например, менеджер в офисе «выберет» ваш софт не из-за удобства, а потому что управление навязало его, чтобы сэкономить или решить свои иные задачи, а сотрудник согласится, даже будучи несогласным. JTBD здесь изучает «почему», но игнорирует, что ответы на «почему» часто бывают фальшивыми, чтобы не выдать настоящие мотивы вроде «я боюсь потерять работу» или «мне плевать, лишь бы отстали».

«Задачи могут включать не только практические цели (например, повесить полку), но и эмоциональные (чувствовать себя уверенно) или социальные (выглядеть профессионально перед другими)»

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

«JTBD помогает выявлять, какие задачи клиенты считают важными, и разрабатывать продукты, которые лучше решают эти задачи, чем существующие решения»

Опять же всё сводится к поиску функциональностей на основе доверия словам через использование формулы Job Story для выявления якобы коренных мотивов. Истинные нужды клиентов так или иначе эволюционируют под влиянием рынка, пропаганды, экономического давления, трендов, социальных проблем, личных предубеждений и прочего. JTBD часто акцентирует функциональные задачи (например, «хочу быстро добраться до работы»), но может недооценивать эмоциональные или социальные аспекты (например, «хочу чувствовать себя статусно»). Это может привести к созданию продуктов, которые решают задачу технически, но не удовлетворяют клиента на эмоциональном уровне. В итоге продукт «лучше решает» только те задачи, которые выдумали вы сами, основываясь на ошибочных данных и от руководства линейной логикой.

Всё, финал

Даже основанные на данных персоны и подходы вроде Jobs To Be Done (JTBD) не всегда вскрывают «потаённые желания», потому что люди могут скрывать свои истинные намерения или не осознавать их. Метод персон слишком абстрактен и не учитывает скрытые мотивы человека, он не расскажет и не покажет то, что действительно важно. Но самое интересное, что и человек вам редко такое расскажет. JTBD (вместе с Job Story) так же не является тем методом, который поможет понять суть и раскрыть потаенные страхи и мотивы людей. Люди могут сказать что угодно ради простого желания пройти тест или желания показаться лучше, чем они есть на самом деле в своих помыслах. Вплоть до ложных показаний.

Пример №1.

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

Другой бухгалтер может говорить о желании автоматизации, но на деле бояться, что это сделает её работу ненужной. Но об этом мало кто признается на деле. Такие скрытые мотивы редко всплывают в исследованиях (JTBD в частности), а также в стандартных интервью или опросах.

Пример №2. Этот пример показывает принцип ошибочности суждений, основанных лишь на «фактах» исследования.

Вы шьете одежду и продаете её в регионах России (например, в 2010-х годах). Вы проводите опрос: какой цвет футболки вы хотели бы носить (купили бы)? Из отчетов так называемых «фактов» вы понимаете, что большинство сказало, что выбрало бы фиолетовые футболки, меньшее количество — коричневые, и оставшиеся — черные и белые цвета. Вы тратите деньги на производство этих футболок, но по факту скупили все черные и белые футболки, а фиолетовые и коричневые продались лишь на 25% от общего пошива. Почему так? Возможно потому, что люди рассказали о том, как хотели бы, но в сути большинство не купят фиолетовые и коричневые футболки по ряду причин — от того, что «на районе пацаны не поймут» и общественного мнения, сформированного в России 2010-х, до того, что субъект просто солгал или высказал, что хотел бы, но не может себе позволить по тем или иным причинам.

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

В общем, JTBD (а именно Job Story) лишь больше приоткроет суть на то, что скорее всего важно для человека (пользователя) в его процессуальных действиях, но как и всякий метод, вырванный из контекста, не даст истинного понимания сути вещей. Эти методы лишь инструменты (часто не совсем рабочие), и их ценность зависит от того, где, как, когда и с чем их используют.

Что делать?

1. Глубокие, контекстные интервью:

• Задавайте больше не прямые вопросы, а косвенные, которые выявляют эмоции и контекст: «Расскажите, как вы справляетесь с рутинными задачами? Что вас в них раздражает или радует?»

• Спрашивайте больше не «что?», а «почему?», чтобы приблизиться к истинным мотивам. Пример: Бухгалтер говорит: «Я хочу автоматизацию». Спрашиваем: «Почему?» — «Чтобы тратить меньше времени». — «Почему это важно?» — «Чтобы успевать больше». — «Почему вы хотите успевать больше?» — «Потому что я боюсь, что меня заменят, если я не буду эффективной». Вот тут и вскрывается страх потери работы (к примеру).

2. Наблюдение вместо опросов:

• Если есть возможность, понаблюдайте за пользователями в их естественной среде (например, как бухгалтер работает в офисе). Это называется этнографическое исследование. Оно помогает увидеть, что люди делают, а не что они говорят. Пример: вы можете заметить, что бухгалтер тратит много времени на ручное заполнение не потому, что это необходимо, а потому, что это её способ «выглядеть занятой».

3. Учёт скрытых мотивов:

• Признайте, что у пользователей могут быть «неудобные» мотивы (страх потерять работу, желание тянуть время, привычка к рутине). Это жизнь и действительность. Задавайте вопросы, которые снимают барьеры: «Что бы вы потеряли, если бы эта задача была автоматизирована?» и т. д. Это помогает понять, например, что бухгалтер ценит ручной труд не только как источник дохода, но и как способ контроля или уверенности.

4. Итеративный подход:

• Не стройте выводы на основе одного интервью. Проводите несколько сессий с одними и теми же людьми, чтобы установить доверие и получить более честные ответы.

• Проверяйте предположения и свои доводы через прототипы и их тесты, а не только через слова.

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

В силу такой сложности необходимо прикладывать совокупность навыков, методологий и личного опыта с пониманием жизни и устройства мира в целом. И даже тогда вы лишь приблизитесь к более-менее адекватной картине, на которой можно уже строить что-то по требованиям и болям. А все остальное — точно такой же тычок пальцем в жопу дизайнера или исследователя важного, как если бы я просто говорил, что нужно людям, т. к. понимаю для кого мы делаем продукт и как бы поступал сам со стороны пользователя, собрав при этом ещё пару таких отзывов. И такой подход в субъективном предположении был бы более действенный и к тому же не тратил время на сбор «персон», которые ничего не дадут, а точнее дадут то, что и так понятно. А вы дрочите бытие на методологиях, считая, что это панацея и поможет вам понять суть. Но поможет это вам лишь заполнить отчетность, документацию и оправдать свои косяки перед руководством, мол мы провели «исследования». В итоге получить свою з/п и взять следующую задачу. Что большинству и интересно. Бездумно, но с видимостью «профессионального подхода» исполнять и обслуживать вкусы заказчика, продавая свой образ некого "крутого эксперта", а не разрабатывать продукт и не служить профессии и обществу.

А то так посмотреть, сплошная нелепость и мещанство. Какие-то западные мудаки придумали эти методы в «лохматых» 90-х, а у нас в 2020-х годах дизайнеры и прочие гуси-лебеди надели на себя все эти методологии как аборигены бусы, считая, что это как-то решает их проблемы. А что толку? Лишь отрабатывают то, что в дурацких книгах написано их авторитетами. Сами головой думать не привыкли, вот и результат — сплошные ожидания работодателей с карго-культными искажениями в сознании и такие же аборигены-дизайнеры. Смешно и грустно.

Вот мы и разобрали с вами по сути все эти нерабочие и полурабочие устаревшие инструменты, подойдя к вопросу с дотошностью великого политика и деятеля Лаврентия Берии.

Всем спасибо. Сильно «не горите», больше думайте своей головой и не поклоняйтесь своим нелепым авторитетам и идолам западным. А то смотреть тошно на подобное безобразие и идолопоклонничество своим свергнутым «богам».