Персоны · Конспекты по бизнес-анализу

Главные идеи#

Книга Алана Купера — первоисточник персон как метода проектирования программного обеспечения. Её основные идеи:

Конкретное лучше общего#

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

Персоны проектирования — не маркетинговые персоны#

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

Проектируйте для пользователя, а не для покупателя#

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

Состав персонажей#

Купер предлагает начинать примерно с 3–12 кандидатов в персоны на проект; после отсева полезными обычно остаются 3–7. Не каждая персона становится целью проектирования:

Основная персона (primary persona) — тот, чьи потребности нельзя удовлетворить интерфейсом, спроектированным для кого-то другого. Для каждой основной персоны делают свой интерфейс. Если основных персон больше трёх, Купер считает это признаком того, что продукт пытается делать слишком много.
Отрицательная персона (negative persona) — тот, для кого вы сознательно не проектируете, даже если он работает рядом с продуктом. В одном из кейсов Купера продукт был задуман так, чтобы полностью обойти роль посредника, а не облегчить её.
Персонам не нужны совершенно разные цели. Два человека с одинаковыми практическими целями, но разными мотивами (один хочет избежать ошибок, другой — получить повышение) могут быть двумя персонами.

Проектируйте для самой ограниченной основной персоны#

Это хорошо показывает кейс Купера с развлекательной системой на борту самолёта. Из персон-пассажиров команда выбрала основной не частого бизнес-путешественника, а пожилого пассажира, который неуверенно обращался с техникой и плохо владел руками. Логика такая: интерфейс, который работает для самого ограниченного пользователя, подойдёт и остальным, а наоборот — нет. В результате иерархию меню заменили одной прокручиваемой лентой названий, которой управляют большой физической рукояткой. Быстрые пути для опытных путешественников в системе были, но пожилому пассажиру не мешали.

Один лист — везде#

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

Как применять#

Стройте персоны на исследованиях. Опирайтесь на интервью и наблюдение, а не на мнения команды. Каждую персону должно быть можно проследить до реальных людей, с которыми вы встречались.
Записывайте цели, а не пожелания к функциям. «Хочет знать, когда велосипед будет готов, не звоня в мастерскую» — это цель; «хочет функцию SMS» — это решение.
Назовите основную персону для каждого интерфейса, а также отрицательные персоны. Запишите и тех и других в документ концепции и границ.
Используйте имена в требованиях. Пишите пользовательские истории и сценарии для персоны с именем, а не «как пользователь».
Проводите ревью по персоне. На ревью прототипов заменяйте вопрос «Удобно ли это пользователю?» вопросом «Работает ли это для основной персоны?».

Чек-лист для ревью#

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

Пример#

«Мастерская», вымышленная сеть из 12 веломастерских, добавляет онлайн-запись. Интервью с клиентами и сотрудниками стойки приёма дают четырёх кандидатов в персоны-клиенты: человека, который ездит на велосипеде на работу и должен получить его обратно к понедельнику; родителя, который записывает детские велосипеды; увлечённого велосипедиста, который хочет указать конкретные запчасти; и пожилого человека, который катается от случая к случаю и почти ничего не бронирует онлайн.

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

Подводные камни#

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

Источники и что почитать#

A. Cooper. The Inmates Are Running the Asylum. Sams, 1999. Рус. изд.: А. Купер. Психбольница в руках пациентов. СПб.: Символ-Плюс, 2004.