Сторителлинг для проектирования интерфейсов, или персонажи
Решила рассказать историю о том, как истории о пользователях помогают профессионалам по юзабилити проектировать новые сайты и переделывать неоптимально спроектированные или устаревшие.
Буду цитировать классическую книгу Алана Купера под дурацким названием "Психбольница в руках пациентов", потому что в ней самым понятным образом описана схема создания персонажей и объяснена работа этого механизма.
Слов под катом много, но я много раз сталкивалась с тем, что люди, далекие от айтишной среды, понятия не имеют об этой технологии (а также с интересом слушают при случае).
Передаю слово Алану Куперу:
Альберт Эйнштейн сказал, что нельзя решить проблему, находясь внутри системы, которая ее породила. Начиная с 1992 года я занимался разработкой метода, получившего название целеориентированного проектирования (Goal-Directed Design), и проектировщики в моей консультационной компании применяют его во всех проектах.
Принципы действия самых мощных инструментов всегда просты, однако применение таких инструментов весьма нетривиально. Это, несомненно, верно и для инструментов проектирования взаимодействия. Наш самый эффективный инструмент исключительно прост: это точное описание пользователя продукта и его целей. Сложность здесь в том, чтобы создать и применить такое точное описание.
Наиболее очевидный подход состоит в том, чтобы найти реального пользователя и расспросить его, но этот подход неэффективен по ряду причин, и основная из них такова, что жертва определенной проблемы не наделяется автоматически силой, позволяющей эту проблему решить. Реальный пользователь - источник, конечно же, ценный, и мы уделяем большое внимание, но никогда не позволяем напрямую влиять на принимаемое решение.
Работоспособный подход кажется примитивным, но обладает невероятной мощью и эффективен во всех случаях. Мы выдумываем несуществующих пользователей и проектируем для них. Мы называем таких несуществующих пользователей персонажами (personas), и они представляют собой необходимую базу качественного проектирования взаимодействия.
Персонажи - не реальные люди, но они представляют реальных людей в процессе проектирования. Это гипотетические архетипы реальных пользователей. Будучи воображаемыми, они, тем не менее, определяются достаточно жестко и точно. На практике мы не столько «выдумываем» персонажи, сколько обнаруживаем их в качестве побочного продукта процесса расследования. Но мы действительно выдумываем их имена и личные сведения.
Персонажи определяются своими целями. Цели же, разумеется, определяются персонажами. Похоже на тавтологию, но это не так. Свойства персонажей выявляются в процессе изучения и анализа так же, как серия тектонических событий выявляется геологами по слоям осадочных пород: присутствие окаменелостей указывает на геологический пласт, а сам геологический пласт указывает на наличие окаменелостей. В следующей главе я много скажу о целях, сейчас же замечу, что мы выявляем их так же, как выявляем персонажи. Мы определяем, какие персонажи имеют отношение к делу, а также их цели в процессе итеративного совершенствования в рамках начального исследования предметной области.
Как правило, мы начинаем с разумного приближения и быстро сосредотачиваемся на правдоподобном наборе персонажей. Данный итеративный процесс похож на итеративный процесс, применяемый разработчиками программного обеспечения при создании продуктов, но имеет одно фундаментальное отличие. Циклическое совершенствование дизайна проекта и его предпосылок происходит быстро и легко, так как мы работаем на бумаге, работаем с текстом. Но циклическое совершенствование реализованного продукта медленнее и сложнее, поскольку здесь необходимо кодирование.
**
Чтобы создать продукт, удовлетворяющий широкую аудиторию пользователей, как подсказывает логика, необходимо возможно больше расширить его функциональность, охватив, таким образом, как можно больше людей. Это ошибочная логика. Вы добьетесь гораздо большего успеха, проектируя для единственного человека.
Представьте, что проектируете автомобиль, удовлетворяющий вкусам широких масс. Можно с легкостью выделить по меньшей мере три подгруппы пользователей: мать с малолетним ребенком, плотник, младший руководящий работник. Мамочке нужна безопасная, надежная машина, просторная, с большими дверями, для перевозки детей, собак, пакетов с покупками и т. д. Плотнику Джо нужен крепкий полноприводный пикап, достаточно большой, чтобы в него поместились лестницы, материалы, мешки с цементом и ящики с инструментами. Младший руководящий работник Сет видит себя в машине спортивного типа с мощным двигателем, жесткой подвеской, откидным верхом и - места в машине должно хватать только на двоих.
Решение задачи показано на рисунке. Такой автомобиль сочетает пожелания каждого водителя: минивэн с откидным верхом, пространством для детей и пиломатериалов. Что за дурацкая, невозможная машина! Даже если ее создать, ее никто не купит. Правильное решение: создать минивэн для Мамочки, пикап для Джо, спортивную машину для Сета.
Роберт Лутц (Robert Lutz), руководитель компании Chrysler, говорит, что 80% участников фокус-группы возненавидели новый пикап Dodge Ram. Но после выхода на рынок машина стала бестселлером, потому что остальные 20% в нее влюбились. Любовь людей к продукту, пусть даже этих людей не очень много, - вот ключ к успеху.
Чем больше размер мишени, тем меньше вероятность попадания «в яблочко». Если вы желаете достичь уровня удовлетворенности продуктом в 50%, это невозможно сделать, осчастливив 50% широкой аудитории, Единственный способ достичь цели состоит в том, чтобы выявить эти 50% и стремиться осчастливить их на 100%. И это еще не все. Еще большего успеха можно добиться, если выделить 10% рыночной аудитории и направить свои усилия на то, чтобы вызвать у них стопроцентный восторг. На первый взгляд - противоречие, однако проектирование для единственного пользователя - самый эффективный способ удовлетворить широкую аудиторию.
**
Чемодан на колесиках - хороший пример эффективности проектирования для одного человека. Этот небольшой чемодан со встроенными колесами и убирающейся ручкой произвел целую революцию в области багажа, а проектировался при этом совсем не для широкой аудитории. Изначально чемодан задумывался для экипажей самолетов, то есть для очень узкой аудитории пользователей. Чистота дизайна продукта принесла этой группе пользователей полное удовлетворение. Остальные путешественники вскоре осознали, что такой чемодан решает и их проблемы тоже. Его легко перевозить по переполненным людьми аэропортам, маневрировать между рядами кресел в самолете и завозить на борт.
После успеха чемоданов на колесиках в целевом сегменте продукт выпустили и на другие рынки. Сегодня в продаже есть большие чемоданы на колесах, чемоданы на колесиках «haute couture», бронированные чемоданы на колесиках, детские чемоданы на колесиках. Сегодня уже непросто купить багажный чемодан без встроенных колес и убирающейся ручки.
**
Чем более конкретными мы делаем персонажи, тем более эффективными инструментами проектирования они становятся. Происходит это потому, что по мере конкретизации персонажи теряют эластичность. К примеру, мы не можем просто сказать, что Эмили пользуется офисными приложениями. Мы говорим, что Эмили пишет письма бабушке при помощи WordPerfect версии 5.1. Мы не позволяем Эмили просто поехать на работу. Мы снабжаем ее темно-синей Toyota Camry выпуска 1991 г., с серым пластиковым детским сиденьем и отвратной царапиной на заднем бампере. Мы не позволяем Эмили просто пойти на работу. Мы назначаем ее клерком по заведению счетов в бежевом отсеке компании Global Airways в Мемфисе, штат Теннесси. Такая характерная детализация - очень мощный инструмент проектирования и коммуникации. Как следствие, все наши персонажи описываются с тщательным вниманием к деталям.
По мере обрастания Эмили конкретными отличительными чертами происходит замечательная вещь: она становится в представлении разработчиков реальным человеком. Ее можно называть по имени, как реального человека. Она приобретает осязаемое воплощение, которое позволяет в процессе проектирования видеть все предположения с ее точки зрения. По мере того, как Эмили утрачивает гуттаперчевость, мы начинаем видеть, каковы ее умения, какова ее мотивация, чего она желает достичь. Вооруженные этим знанием, мы способны изучить ее в свете предметной области программы и понять, является ли она в действительности архетипом пользователя. Проектировщик, обладающий некоторым опытом, обычно способен синтезировать подходящий персонаж с первой попытки.
Одним из самых важных шагов в успешном определении персонажа является выбор имени. Персонаж без имени просто не имеет смысла. Никто не сможет представить себе такой персонаж, как конкретного человека.
Чтобы сделать каждый персонаж более реальным для участников проекта, я люблю дополнять имена портретами, прикреплять к каждому персонажу изображение. Можете вырезать изображения из журналов, если угодно.
Четко обозначенный, полностью развитый персонаж становится мощным инструментом. До тех пор, пока пользователь не имеет четкого определения, программист может воображать, будто пользователем является он сам. Четко определенный персонаж - это ключ к подавлению склонности разработчика искажать характеристики пользователей. Задолго до написания первой строки кода качественно определенный персонаж становится невероятно эффективным средством для проектирования взаимодействия.
**
К примеру, проектируя чемодан на колесиках, в качестве персонажа мы могли бы взять Герда, командира рейса Боинга-747 из Ванкувера во Франкфурт.
С одной стороны, мы не можем расширением персонажа охватить всех пилотов коммерческих рейсов. Скажем, Соня посещает занятия в Университете аэронавтики Эмбри-Риддл и собирается стать профессиональным пилотом после выпуска. Она летает ежедневно, но только на маленьких одномоторных самолетах, и никогда не ночует вне дома. Если говорить о багаже, то Соня - крайний случай. Если определение Герда распространить на Соню, то персонаж из точного превращается в размытый. Начинаются бесконечные и бесцельные дискуссии о том, является ли Соня пилотом авиалиний, и о том, какие требования предъявляет она к своему багажу.
С другой стороны, проектируя чемодан на колесиках, мы можем в качестве прототипа рассматривать Франсин, стюардессу компании на Reno Air. Она трижды в день преодолевает немалые расстояния, раздавая напитки и пакетики с арахисом. Герд и Франсин совершенно разные личности, но их цели и потребности в области багажа эквивалентны.
Программисты живут исключительными ситуациями, и под этим влиянием выбирают персонажи. Они будут спорить, что Соня законно претендует на роль персонажа, поскольку занимает место пилота. В этом разница - программирование определяется краевыми случаями предметной области, а проектирование - центральными. Если есть хоть какое-то сочинение в центральном расположении персонажа, этот персонаж следует исключить из рассмотрения.
**
В интересах точного определения персонажей необходимо определить средние показатели. Средний пользователь никогда не бывает математически средним. У среднего человека в моем населенном пункте 2,3 ребенка, но ни у одного жителя города не может быть такого количества детей. Более полезным представителем мог быть стать Сэмюэл, отец двоих детей, или Уэллс, у которого трое детей. Сэмюэл полезен, потому что он личность. Да, гипотетическая, но обладающая точными характеристиками. Родитель, имеющий 2,3 ребенка, не может существовать, как раз из-за этого невозможного среднего показателя.
Усредненные персонажи уничтожают преимущества конкретности точных. Великая сила персонажей именно в их точности и конкретике. Обобщенные данные сводят эту силу на нет.
Персонажи - самый мощный из имеющихся в нашем распоряжении инструментов проектирования. Они являются основой целеориентированного проектирования. Персонажи позволяют нам видеть масштаб и природу проблемы проектирования. Позволяют точно понять и определить цели пользователя и таким образом определить, что должен делать продукт и чего он может совершенно спокойно не делать. Точно определенный персонаж дает нам определенность относительно уровня владения пользователя компьютером, поэтому мы перестаем терзаться загадкой, для кого проектировать: для дилетанта или специалиста.
Изобретенные персонажи уникальны для каждого проекта.
Буду цитировать классическую книгу Алана Купера под дурацким названием "Психбольница в руках пациентов", потому что в ней самым понятным образом описана схема создания персонажей и объяснена работа этого механизма.
Слов под катом много, но я много раз сталкивалась с тем, что люди, далекие от айтишной среды, понятия не имеют об этой технологии (а также с интересом слушают при случае).
Передаю слово Алану Куперу:
Альберт Эйнштейн сказал, что нельзя решить проблему, находясь внутри системы, которая ее породила. Начиная с 1992 года я занимался разработкой метода, получившего название целеориентированного проектирования (Goal-Directed Design), и проектировщики в моей консультационной компании применяют его во всех проектах.
Принципы действия самых мощных инструментов всегда просты, однако применение таких инструментов весьма нетривиально. Это, несомненно, верно и для инструментов проектирования взаимодействия. Наш самый эффективный инструмент исключительно прост: это точное описание пользователя продукта и его целей. Сложность здесь в том, чтобы создать и применить такое точное описание.
Наиболее очевидный подход состоит в том, чтобы найти реального пользователя и расспросить его, но этот подход неэффективен по ряду причин, и основная из них такова, что жертва определенной проблемы не наделяется автоматически силой, позволяющей эту проблему решить. Реальный пользователь - источник, конечно же, ценный, и мы уделяем большое внимание, но никогда не позволяем напрямую влиять на принимаемое решение.
Работоспособный подход кажется примитивным, но обладает невероятной мощью и эффективен во всех случаях. Мы выдумываем несуществующих пользователей и проектируем для них. Мы называем таких несуществующих пользователей персонажами (personas), и они представляют собой необходимую базу качественного проектирования взаимодействия.
Персонажи - не реальные люди, но они представляют реальных людей в процессе проектирования. Это гипотетические архетипы реальных пользователей. Будучи воображаемыми, они, тем не менее, определяются достаточно жестко и точно. На практике мы не столько «выдумываем» персонажи, сколько обнаруживаем их в качестве побочного продукта процесса расследования. Но мы действительно выдумываем их имена и личные сведения.
Персонажи определяются своими целями. Цели же, разумеется, определяются персонажами. Похоже на тавтологию, но это не так. Свойства персонажей выявляются в процессе изучения и анализа так же, как серия тектонических событий выявляется геологами по слоям осадочных пород: присутствие окаменелостей указывает на геологический пласт, а сам геологический пласт указывает на наличие окаменелостей. В следующей главе я много скажу о целях, сейчас же замечу, что мы выявляем их так же, как выявляем персонажи. Мы определяем, какие персонажи имеют отношение к делу, а также их цели в процессе итеративного совершенствования в рамках начального исследования предметной области.
Как правило, мы начинаем с разумного приближения и быстро сосредотачиваемся на правдоподобном наборе персонажей. Данный итеративный процесс похож на итеративный процесс, применяемый разработчиками программного обеспечения при создании продуктов, но имеет одно фундаментальное отличие. Циклическое совершенствование дизайна проекта и его предпосылок происходит быстро и легко, так как мы работаем на бумаге, работаем с текстом. Но циклическое совершенствование реализованного продукта медленнее и сложнее, поскольку здесь необходимо кодирование.
**
Чтобы создать продукт, удовлетворяющий широкую аудиторию пользователей, как подсказывает логика, необходимо возможно больше расширить его функциональность, охватив, таким образом, как можно больше людей. Это ошибочная логика. Вы добьетесь гораздо большего успеха, проектируя для единственного человека.
Представьте, что проектируете автомобиль, удовлетворяющий вкусам широких масс. Можно с легкостью выделить по меньшей мере три подгруппы пользователей: мать с малолетним ребенком, плотник, младший руководящий работник. Мамочке нужна безопасная, надежная машина, просторная, с большими дверями, для перевозки детей, собак, пакетов с покупками и т. д. Плотнику Джо нужен крепкий полноприводный пикап, достаточно большой, чтобы в него поместились лестницы, материалы, мешки с цементом и ящики с инструментами. Младший руководящий работник Сет видит себя в машине спортивного типа с мощным двигателем, жесткой подвеской, откидным верхом и - места в машине должно хватать только на двоих.
Решение задачи показано на рисунке. Такой автомобиль сочетает пожелания каждого водителя: минивэн с откидным верхом, пространством для детей и пиломатериалов. Что за дурацкая, невозможная машина! Даже если ее создать, ее никто не купит. Правильное решение: создать минивэн для Мамочки, пикап для Джо, спортивную машину для Сета.
Роберт Лутц (Robert Lutz), руководитель компании Chrysler, говорит, что 80% участников фокус-группы возненавидели новый пикап Dodge Ram. Но после выхода на рынок машина стала бестселлером, потому что остальные 20% в нее влюбились. Любовь людей к продукту, пусть даже этих людей не очень много, - вот ключ к успеху.
Чем больше размер мишени, тем меньше вероятность попадания «в яблочко». Если вы желаете достичь уровня удовлетворенности продуктом в 50%, это невозможно сделать, осчастливив 50% широкой аудитории, Единственный способ достичь цели состоит в том, чтобы выявить эти 50% и стремиться осчастливить их на 100%. И это еще не все. Еще большего успеха можно добиться, если выделить 10% рыночной аудитории и направить свои усилия на то, чтобы вызвать у них стопроцентный восторг. На первый взгляд - противоречие, однако проектирование для единственного пользователя - самый эффективный способ удовлетворить широкую аудиторию.
**
Чемодан на колесиках - хороший пример эффективности проектирования для одного человека. Этот небольшой чемодан со встроенными колесами и убирающейся ручкой произвел целую революцию в области багажа, а проектировался при этом совсем не для широкой аудитории. Изначально чемодан задумывался для экипажей самолетов, то есть для очень узкой аудитории пользователей. Чистота дизайна продукта принесла этой группе пользователей полное удовлетворение. Остальные путешественники вскоре осознали, что такой чемодан решает и их проблемы тоже. Его легко перевозить по переполненным людьми аэропортам, маневрировать между рядами кресел в самолете и завозить на борт.
После успеха чемоданов на колесиках в целевом сегменте продукт выпустили и на другие рынки. Сегодня в продаже есть большие чемоданы на колесах, чемоданы на колесиках «haute couture», бронированные чемоданы на колесиках, детские чемоданы на колесиках. Сегодня уже непросто купить багажный чемодан без встроенных колес и убирающейся ручки.
**
Чем более конкретными мы делаем персонажи, тем более эффективными инструментами проектирования они становятся. Происходит это потому, что по мере конкретизации персонажи теряют эластичность. К примеру, мы не можем просто сказать, что Эмили пользуется офисными приложениями. Мы говорим, что Эмили пишет письма бабушке при помощи WordPerfect версии 5.1. Мы не позволяем Эмили просто поехать на работу. Мы снабжаем ее темно-синей Toyota Camry выпуска 1991 г., с серым пластиковым детским сиденьем и отвратной царапиной на заднем бампере. Мы не позволяем Эмили просто пойти на работу. Мы назначаем ее клерком по заведению счетов в бежевом отсеке компании Global Airways в Мемфисе, штат Теннесси. Такая характерная детализация - очень мощный инструмент проектирования и коммуникации. Как следствие, все наши персонажи описываются с тщательным вниманием к деталям.
По мере обрастания Эмили конкретными отличительными чертами происходит замечательная вещь: она становится в представлении разработчиков реальным человеком. Ее можно называть по имени, как реального человека. Она приобретает осязаемое воплощение, которое позволяет в процессе проектирования видеть все предположения с ее точки зрения. По мере того, как Эмили утрачивает гуттаперчевость, мы начинаем видеть, каковы ее умения, какова ее мотивация, чего она желает достичь. Вооруженные этим знанием, мы способны изучить ее в свете предметной области программы и понять, является ли она в действительности архетипом пользователя. Проектировщик, обладающий некоторым опытом, обычно способен синтезировать подходящий персонаж с первой попытки.
Одним из самых важных шагов в успешном определении персонажа является выбор имени. Персонаж без имени просто не имеет смысла. Никто не сможет представить себе такой персонаж, как конкретного человека.
Чтобы сделать каждый персонаж более реальным для участников проекта, я люблю дополнять имена портретами, прикреплять к каждому персонажу изображение. Можете вырезать изображения из журналов, если угодно.
Четко обозначенный, полностью развитый персонаж становится мощным инструментом. До тех пор, пока пользователь не имеет четкого определения, программист может воображать, будто пользователем является он сам. Четко определенный персонаж - это ключ к подавлению склонности разработчика искажать характеристики пользователей. Задолго до написания первой строки кода качественно определенный персонаж становится невероятно эффективным средством для проектирования взаимодействия.
**
К примеру, проектируя чемодан на колесиках, в качестве персонажа мы могли бы взять Герда, командира рейса Боинга-747 из Ванкувера во Франкфурт.
С одной стороны, мы не можем расширением персонажа охватить всех пилотов коммерческих рейсов. Скажем, Соня посещает занятия в Университете аэронавтики Эмбри-Риддл и собирается стать профессиональным пилотом после выпуска. Она летает ежедневно, но только на маленьких одномоторных самолетах, и никогда не ночует вне дома. Если говорить о багаже, то Соня - крайний случай. Если определение Герда распространить на Соню, то персонаж из точного превращается в размытый. Начинаются бесконечные и бесцельные дискуссии о том, является ли Соня пилотом авиалиний, и о том, какие требования предъявляет она к своему багажу.
С другой стороны, проектируя чемодан на колесиках, мы можем в качестве прототипа рассматривать Франсин, стюардессу компании на Reno Air. Она трижды в день преодолевает немалые расстояния, раздавая напитки и пакетики с арахисом. Герд и Франсин совершенно разные личности, но их цели и потребности в области багажа эквивалентны.
Программисты живут исключительными ситуациями, и под этим влиянием выбирают персонажи. Они будут спорить, что Соня законно претендует на роль персонажа, поскольку занимает место пилота. В этом разница - программирование определяется краевыми случаями предметной области, а проектирование - центральными. Если есть хоть какое-то сочинение в центральном расположении персонажа, этот персонаж следует исключить из рассмотрения.
**
В интересах точного определения персонажей необходимо определить средние показатели. Средний пользователь никогда не бывает математически средним. У среднего человека в моем населенном пункте 2,3 ребенка, но ни у одного жителя города не может быть такого количества детей. Более полезным представителем мог быть стать Сэмюэл, отец двоих детей, или Уэллс, у которого трое детей. Сэмюэл полезен, потому что он личность. Да, гипотетическая, но обладающая точными характеристиками. Родитель, имеющий 2,3 ребенка, не может существовать, как раз из-за этого невозможного среднего показателя.
Усредненные персонажи уничтожают преимущества конкретности точных. Великая сила персонажей именно в их точности и конкретике. Обобщенные данные сводят эту силу на нет.
Персонажи - самый мощный из имеющихся в нашем распоряжении инструментов проектирования. Они являются основой целеориентированного проектирования. Персонажи позволяют нам видеть масштаб и природу проблемы проектирования. Позволяют точно понять и определить цели пользователя и таким образом определить, что должен делать продукт и чего он может совершенно спокойно не делать. Точно определенный персонаж дает нам определенность относительно уровня владения пользователя компьютером, поэтому мы перестаем терзаться загадкой, для кого проектировать: для дилетанта или специалиста.
Изобретенные персонажи уникальны для каждого проекта.