Чем виртуальные персонажи лучше обезличенных, например, администратор — модератор?
Ответ я нашел в сети. Лучше всего прочитать оригинал с картинками:
28.09.2006Платон Днепровский
Комментариев: 14
О пользе персонажейПрактика, ИнструментарийИспользование персонажей (persona) – один из способов сбора и формализации требований к интерфейсу. Но, по мнению некоторых коллег и заказчиков, их польза часто сомнительна, и кажется, будто персонажи – «красивая сказка», не имеющая практической ценности.
Цитата:
Платон, у меня такой вопрос по практическому использованию вами персонажей: насколько велика, на ваш взгляд, связь между характеристиками разработанных вами персонажей и интерфейсом созданной системы? Как осуществляется переход от персонажей к самому интерфейсу? Есть ли вообще польза в их использовании?
На мой взгляд, и по моему опыту разработки интерфейсов, существует достаточно сильный «разрыв» между разработкой интерфейса и созданием персонажей. Персонажи играют скорее «демонстративную» и «декоративную», нежели практическую цель.
– сомневается в эффективности персонажей Геннадий Драгун в комментариях к статье про работу.
В отсутствие персонажей как таковых, даже при наличии полных и формальных требований к целевой аудитории (ЦА), все, что мы держим в голове о пользователях в ходе проекта – это то, что они вообще есть.
Как правило, если в маркетинговом исследовании написано, что наша ЦА – это пожилые женщины с минимальным уровнем компьютерной грамотности, мы представляем пользователей так (как нам хочется):
Эдуард, тут хорошая фотографияCферические кони в вакууме
При этом все понимают, что это не совсем так.
Мы в своей работе используем персонажей достаточно часто, попробую описать выгоды, которые нам приносит такой подход.
Основные (и проверенные на опыте) плюсы от использования персонажей следующие:
■Сбор персональных пользовательских требований к интерфейсу
■Структуризация и ранжирование требований
■Повышение качества коммуникации с другими участниками проекта
■Упрощение организации юзабилити-тестирований
Немного поподробнее о каждом пункте.
Сбор требований Каждый раз, создавая персонажа, мы «вживаемся» в него, чего не происходит при простой фиксации характеристик ЦА. Да, мы все знаем, что если уровень компьютерной грамотности у пользователей низкий – нужно любой шаг системы максимально «разжевывать», а если пользователь в возрасте – делать контролы крупнее. Это «знание» - один из аргументов против применения персонажей: дескать, итак все уже известно, и нечего тут писать ЖЗЛ вместо ТЗ.
На самом деле главная прелесть персонажей – не фиксация их характеристик, влияющих на интерфейс, а прослеживание их действий полностью, учитывая всякие отвлекающие задачи, дополнительные артефакты и прочее. И, поверьте, отсюда «выкапывается» огромное количество полезной информации, которая, подчас, очень сильно влияет на конечный продукт. Примеров множество. В одном случае осознание того, что в автосервисе у мастера могут быть грязные руки повлияло на всю идеологию системы. В другом, одном из наших любимых примеров, моделирование работы страховых операторов (проект для Росгосстраха), выявило ряд «мелких» особенностей, как-то: желание как можно раньше уходить с работы (сразу по окончании рабочего дня) или нередкое отсутствие части необходимых документов у страхователей. Эти особенности очень сильно изменили не только интерфейс, но и системные «потроха», и формат БД. В частности, пришлось вводить возможность промежуточного сохранения документов, чего не было предусмотрено изначально.
Структуризация и ранжирование Даже имея под рукой все (пользовательские) требования, зачастую очень непросто их транслировать в интерфейс. Некоторые требования, например, напрямую противоречат друг другу. Когда же они разбиты по персонажам, степень важности которых также известна, все значительно проще. Одному персонажу эта функция нужна, другому мешает? Давайте смотреть, кто для нас (в смысле реализации бизнес-задачи) важнее. Давайте смотреть, кто с какой частотой пользуется системой. И в результате мы наверняка сможем «спрятать» неудобную для кого-то функцию, оставляя ее при этом доступной для другого пользователя. Или выясним, что необходимы несколько вариантов интерфейса – кстати, достаточно частый случай, но имея все требования «в куче» это совсем не очевидно. Вообще «заточка» интерфейсов под персонажей часто весьма эффективный способ. Иначе в лучшем случае придумываются «Лайт» и «Про» версии, но чаще реализуется «все в одном».
Коммуникация Не такое явное, но, тем не менее, весьма полезное преимущество. Как правило, в проекте принимают участие минимум 2 стороны (заказчик и разработчик интерфейсов), чаще 3 (+ техразработчик), иногда 4 (+ бизнес-консультант). И практически любое более-менее серьезное предложение со стороны юзабилити-специалистов всегда обсуждается разными сторонами. Поверьте, намного проще аргументировать идею, говоря, что именно эта штука, которая затянет разработку на 2 недели и увеличит бюджет, жизненно необходима не вообще «нашим пользователям», а конкретному Петру Михалычу со зрением -6, особенно если Михалычи составляют процентов 40 всех пользователей. Да, когда мы описывали и обсуждали жизнь Михалыча, все смеялись и не принимали его всерьез. Но потом оказывается, что поставить себя на место Петра Михалыча значительно проще, чем на место сферического коня в вакууме.
Те же самые техразработчики, имея перед собой портрет Петра Михалыча и его жизнеописание (а мы стараемся в каждом проекте сделать такие листовки) принимают значительно более адекватные самостоятельные решения, нежели «просто ни для кого». Проверено не раз.
В качестве примера вспоминается тот же проект с «Росгосстрахом»: уже после завершения проекта ИТ-команда поехала на пробное внедрение куда-то «в регионы». Нам ребята потом рассказывали, как их поразило точное совпадение аудитории с теми персонажами, что мы смоделировали в проекте. И насколько проще им было найти общий язык с ними, так как все их нужды и особенности были продуманы и сто раз обсуждены, пусть со смехом и скепсисом.
Юзабилити-тестирование Готовые или полуготовые интерфейсы тестируются на группах пользователей – фактически, на тех же персонажах, только реальных. А подготовка к тестированию требует значительного количества ресурсов: необходимо разработать сценарии тестирования, дополнительные задания, да и просто составить «скринеры» для рекрутинга респондентов. Имея же описание персонажей, мы «легким движением руки» получаем из них необходимые данные. Так что здесь мы прилично экономим на трудозатратах.
Это все действительно работает, хотя в начале нам тоже это казалось игрой. Можно не называть эти модели «персонажами», но когда делаешь все «по уму», в результате все равно выходят ОНИ – как в том анекдоте, когда, что ни спроектируй, при сборке все равно получается танк. Можно не давать им имена, не включать в описание проекта «типичный день Петра Михалыча», не визуализировать (подбирать фото). Но раз вся информация уже собрана, почему бы не потратить еще 15 минут, и не получить полноценную модель – она сильно облегчит работу хотя бы в плане коммуникации.
И все будут помнить, что, на самом деле, пользователь у нас таков:
Эдуард, тут чудесная фотографияРеальный Пётр Михалыч
И еще раз кратко остановлюсь на вопросе Геннадия:
Как осуществляется переход от персонажей к самому интерфейсу? Во-первых, после формирования персонажей составляются подробные матрицы: что делают персонажи, чем они при этом пользуются, как часто они это делают и т.д. Причем, как вы понимаете, в описание включаются все данные, а не только непосредственно бизнес-сценарии и артефакты самой системы. Исходя из этих данных, затем можно сделать вывод, как именно реализовывать ту или иную функцию системы. Вот «деланье выводов», сиречь синтез интерфейсных решений – это самая творческая часть, и рецептов конкретных дать нельзя. Но, чем больше мы учли, тем проще делать эти выводы.
И, во-вторых, в ходе разработки-доработки-оптимизации интерфейса, в режиме «быстрых правок», нам банально проще встать на место Петра Михалыча.
P.S. Отдельное спасибо мой хорошей подруге Наташе Черкасовой, которая прислала мне прекрасную фотографию «Михалыча».
Дальше идут Комментарии (14)Цитата:
Богдан 02.10.2006 10:49
Вопрос: А как из десяти выбранных персонажей определить главного, под которого будет проектироваться И.?
Цитата:
Иван Дегтяренко02.10.2006 15:56
Основная идея следующая. У нас, допустим, есть персонаж A и персонаж B. Интерфейс, разработанный под персонажа A “подгоняется” относительно небольшой кровью под персонажа B, а интерфейс, идеальный для персонажа B ну никак не подходит персонажу A, то нужно проектировать подпероснажа A.
Часто бывает, что пероснажи различаются настолько, что идеальнымрешением будет разработка отдельных интерфейсов. Основный персонаж для каждого изинтерфейсов называется ключевым. Подробнее про синтез персонажей можно прочитать в книгах А. Купера.
Цитата:
Евгения04.10.2006 16:30
Платон, поделитесь, пожалуйста, каким образом команда получает сведения для создания персонажей? Какие именно сведения и у кого запрашиваются на практике?
Проведение интерьвью и наблюдения за реальными пользователями требуют немалых ресурсов от команды. Можно ли обойтись “малой кровью” при сборе такой информации и не потерять реалистичность и точность персонажей?
Цитата:
Геннадий Драгун05.10.2006 19:35
Спасибо огромаднейшее за статью. Даже и не ожидал, что тот мой немного скептический пост вызовет такую вот реакцию. Сразу бросился перечитывать литературу по тематике персонажей (до Купера, правда так пока и не добрался, лежит себе в темном уголке винчестера).
А вывод я сделал простой и очевидный: «У каждого из орудий юзабилити инструментария есть своя область применения. » Это орудие наиболее эффективно, когда применяется именно в этой области, когда соблюдаются определённые начальные условия.
Так и с персонажами. Вывод про них такой: «Персонажи не берутся с потолка.» Они должны быть на чем-то основаны: на описании целевой аудитории, маркетинговом исследовании, на результатах собственного наблюдения за целевыми пользователями…
Расскажу о своей ситуации - offshore разработчика интерфейсов. Коммуникация с заказчиком идёт чаще всего виртуально, прямой контакт очень редок, чаще через посредника в виде Бизнес-Аналитика или Менеджера Проекта. К самому целевому пользователю доступа нет. Он нём вообще ничего не известно кроме пары строк текста.
У заказчика о нем свои, обрывочные, не всегда точные представления. Бывает, что даже составить какую-то модель пользователя составить невозможно. (Попробуйте представить себе, как будет работать с вашей системой китайский инженер?)
В такой ситуации персонажи, да и многие другие юзабилити методы, связанные с получением информации непосредственно от конечных пользователей, не работают. Тут эффективнее методы discount/ guerilla юзабилити, опора на логику и на ревью.
Цитата:
Геннадий Драгун05.10.2006 19:43
Богдан - если выбрано целых 10 персонажей, то значит неправильно выбирали. Перефразируя закон Парето: в 4 случаях из 5 вашей системой будут пользоваться только 2 основных. Остальные 8 - в оставшемся одном случае. Разрабатывать нужно под этих главных 1-го или 2-х, но так чтобы система оставалась хотябы минимально пригодна для пользования и неосновными 8-ю.
Когда-то читал статью на похожую тему, о том, что невозможно разработать систему для большого количества персонажей - максимум 2-3. У User-Cenered людей есть поговорка: “Дизайн для всех - дизайн для никого.” Хотя с этим можно поспорить.
Цитата:
Платон Днепровский09.10.2006 17:50
Евгения,
Сведения собираются в основном именно так, как Вы и написали - интервью, тестирования и полевые наблюдения. Да, это и ресурсов требует, и не всегда возможно.
Если не получается - мы стараемся собрать побольше информации от заказчика, иногда он нам предоставляет весьма полезные маркетинговые исследования.
Но в этом случае максимум, что нам дается - это именно описание характеристик “персонажа”, а всю нужную нам информацию о контексте работы мы вынуждены моделировать сами.
Вообще, моделирование во многом происходит, благодаря “вживанию в шкуру” персонажа. Но для узких специалистов и каких-то уникальных процессов это практически невозможно.
Вот этот случай - самый сложный, тут приходится искать и сторонние публикации и описания, и выуживать у заказчиков специалистов, представляющих работу пользователей с разных сторон. А потом интегрировать это все в “полусинтетического” персонажа.
Вообще без пользователей нельзя. Другое дело, что иногда в роли пользователей могут выступать друзья, коллеги, да и сами разработчики (если подходят) - вот, пожалуй, единственный случай “малой крови”.
По опыту, как я уже и писал в этой статье, персонажи, пусть и неявно, моделируются практически всегда, другое дело - с кого они списываются, и насколько качественно.
Цитата:
Проектирование от Microsoft. Современное состояние дел04.05.2007 21:55
7
[…] На выходе получилась диаграмма с описанием типовых предприятий (2 типа), их внутренней структуры (5 отделов), внутренних процессов (33) и работников (61). Работники представлены в виде персонажей. […]
Цитата:
About Face 3 - предисловие | Перепроектируйте это немедленно!02.07.2007 16:07
8
[…] и внедрение методики персонажей, усовершенствование текстовых сценариев […]
Цитата:
HCI, лопата, тачка и Яма 2.0 | Взгляд изнутри03.07.2007 18:01
9
[…] и контекст работы пользователей (для чего необходимы персонажи), и банально иметь возможность менять что-то в […]
Цитата:
Yoshi11.12.2007 12:58
Отличная статья…
А как проходит вживание в роль?
Цитата:
Антон05.01.2008 14:27
Я описываю несколько персонажей для зарубежного сайта. Как мне понять и убедится, что я близок к Петру Михалычу, а не к сферическим коням в вакуме? (Думая о решении,а не о проблеме) Что вы думаете о том, если прислать жизнеописание Петра Михалыча похожему Ивану Фёдоровичу, скажем на Facebook и попросить его прокомментировать?
Цитата:
Денис20.06.2008 01:27
12
Описанный подход был использован для производства на свет урода. Он называется MS Office 2007. Какие-то функции полезны очень, а общий интерфейс - полная сумятица и неразбериха, потому что либо слишком много персонажей, либо делали только под одного: того, который увидел компьютер третий раз…
А вообще спасибо за статью
Цитата:
� руглый стол RusCHI №1 at ALSEDI Group15.12.2008 20:03
13
[…] подход в юзабилити и его сравнение с методикой персонажей“. Применение теории деятельности позволяет […]
Цитата:
Валентин07.01.2009 17:09
14
Автор фотографии — Владимир Ролов, выдающийся фотокорреспондент советских времен. Эта фотография не постановочная, за ней — настоящая история приобщения пожилого человека к компьютеру; старику действительно приходилось так печатать.
Будет здорово, если вы укажете автора в статье.