Метод персон: как «очеловечить» любой цифровой сервис

Что такое метод персон

В процессе разработки технологичных продуктов есть много интересных инструментов, помогающих IT-специалистам лучше понимать нужды своих клиентов. Без такого понимания разработчики будут делать продукты, ориентируясь только на свой опыт, который может быть непривычен для целевой аудитории продукта, что приведет к неудаче — продукт не будет востребован или разочарует клиентов.

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

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

Что такое «персоны»

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

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

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

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

По теме. Как JTBD помогает привлекать клиентов на рынке, где слишком много предложений

Зачем нужен метод

Этот подход помогает сформировать внутри продуктовой команды общее понимание того, кто является клиентом или пользователем продукта, какие у него есть ключевые особенности, влияющие на пользование продуктом или требующие выстраивания особенного клиентского пути (CJM).

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

Если у вас нет задачи делать «продукт для всех», а вы скорее хотите сфокусироваться на своей целевой аудитории, то при составлении набора персон нужно сосредоточиться на ключевых «типичных пользователях» — тех, чьи особенности нужно учитывать в первую очередь при составлении требований к дизайну и функционалу продукта.

Этим объясняется стремление к достаточно конкретному описанию «персоны». Ей даются реалистичные черты: имя, конкретный возраст, пол, образование, описание предпочтений, «болей» и особенностей пользования продуктом. Тем самым достигается нужная реалистичность профиля.

Если продукт не предполагает особенностей, обусловленных профилем клиентов, сводится функционально к простым задачам, то стоит рассмотреть другие альтернативы. Например, фреймворк Jobs-to-be-done, который лучше фокусирует на конкретных пользовательских «работах».

Какие параметры включаются в описание «персон»

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

1. Как именно будут использоваться персоны?
2. Какие решения будут на них опираться?

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

В случае проработки персоны — пользователя конкретного продукта или его фичи — описание может обрастать дополнительными параметрами и контекстами. Например, пользователь личного кабинета ипотечного заемщика.

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

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

Часто в описании персон в разных отраслях можно встретить следующие параметры:

• имя;
• изображение / фото;
• социодемографические параметры: пол, возраст, семейное положение, наличие детей / старших родственников, занятость;
• потребности и пользовательские цели, имеющие отношение к разрабатываемому продукту;
• основные проблемы, «боли», связанные с потребностями и задачами в области, для которой мы разрабатываем продукт;
• мотиваторы / драйверы, поддерживающие пользователя;
• описание текущих альтернатив, к которым прибегает персонаж для удовлетворения потребности;
• цитаты из реальных пользовательских интервью или количественные факты, подкрепляющие характеристики, заявленные в описании персоны.

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

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

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

По теме. Забудьте о JTBD и PMF по отдельности. Будущее — за их комбинацией

Как составить «персоны»

Хорошие «персоны» никогда не берутся из головы. Это результат обобщения разных фактов о целевой аудитории продукта, собранных при проведении потребительских исследований, анализе поведения реальной клиентской базы, отзывов клиентов и обращений в службу поддержки.

«Персоны» должны строиться с опорой на результаты исследований и внутренние данные по поведению пользователей.

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

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

Если персон много и они должны быть детальными и с большим набором параметров, то создание каждого профиля может требовать много ресурсов. Тут могут пригодиться ресурсы сторонних исследовательских / UX-агентств или сервисы на базе искусственного интеллекта, позволяющие оперативно проводить и обрабатывать большое количество глубинных интервью.

Выводы

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

Важно помнить, что:

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

Фото на обложке: Freepik