В теме 48 ответов, и 12 участников, последнее обновление сделано пользователем 
Герман Шестеров 11 г, 12 мес. назад.
-
Сообщения
-
Я все же считаю, что любая программа в частности, и любая техника, да и компьютер вообще — это все вспомогательные инструменты. Антропоцентрический подход, знаете ли
Если представить, что не существует компьютеров как таковых, продолжают ли выполняться те самые должностные обязанности и регламенты? Я думаю да, только алгоритм другой. Что-то делается на бумаге, что-то еще черт знает как. Компьютер в данном случае автоматизирует так или иначе существующую деятельность, видоизменяет ее для того, чтобы помочь сделать ее эффективнее, возможно — безопаснее, прозрачнее и т.п.
Никто не говорит "долой все ограничения, пускай юзер творит все, что захочет". Скорее я имела в виду, что у пользователя должно формироваться чувство контроля над ситуацией, что может быть достигнуто разными способами: от поддержки undo и redo, прямого влияния на поведение ПО, когда это возможно, до заведомых предупреждений со стороны системы (притом формулировка тоже очень важна) о ситуациях, на которые пользователь повлиять не может.Приветствую всех, кому интересна тема юзабилити. Напомню, в своей предыдущей статье (Очерки о юзабилити. Часть 5: Вежливые программы) я размышляла о том, какое поведение программ создает отрицательное впечатление у пользователей. Сегодня мы поговорим о том, как создавать системы, которые казались бы пользователю вежливыми и дружелюбными и вызывали бы желание использовать их в дальнейшем. В этой статье мы перейдем к более конкретным темам и обсудим, во-первых, понятие «Проектирование взаимодействия», во-вторых, такие инструменты как пользовательские сценарии (user scenarios) и карты сценариев (scenario maps).
Читать далееИнтересно, что в статье никак не описано, то откуда берутся персоны, как они генерируются. Типичная ловушка для новичков, которые легко и быстро придумывают Bullshit персонажи, имеющие минимальнyю свайзь с реальными пользователями и представляющие минимальную ценность для практического проектирования взаимодействия.Например, персонаж Анн Брукс, проведенный в качестве примера. Как на проектирование взаимодействия может повлиять то, что она работает на MacBook Air у себя на кухне, пьёт кофе, обшается по Skype, владеет Adobe Photoshop? А если бы она работала из офиса, на MacBook Pro/ Sony Vaio, пила чай, то как бы это повлияло на дизайн? Как цель: "Позиционирование себя как профессионала" реализуется через сценарий "Редактирование профиля"?
Bullshit, одним словом.
К примеру, для построения персонажей, о которых рассказывает Санжар Кетенбеков был проведен он-лайн опрос 27.000 пользователей и фокус-группы с участием 64 пользователей. Если не проводить хотя бы меньшего по маштабам исследования, то ваши персонажи окажутся просто списанными с потолка.
Старые добрые роли и сценарии использования куда как надежнее.
Можно небольшое уточнение? Фраза, формирующая третий абзац — Bullshit, одним словом — относится к самой статье?Можно небольшое уточнение? Фраза, формирующая третий абзац — Bullshit, одним словом — относится к самой статье?
Фраза относится конкретно к описанию персонажа и пользовательскому сценарию, приведенным в качестве примера.
70%-80% информации в описании персонажа и сценарии не имеют практической пользы/ отношения к проектированию взаимодействия.
В статье, действительно, не описано, откуда берутся персоны и откуда, в частности, взялась Анн Брукс. Поэтому позволю себе рассказать об этом здесь.
К сожалению, не могу раскрыть всех подробностей, ибо NDA. Для выделения персон на этом проекте (замечу, проект реально существующий, функционирующий, хоть и бета, так что эмприрические данные имеются) мы
предприняли следующие шаги:
1) Посмотрели данные веб-аналитики
2) Изучили данные зарегистрированных пользователей (в системе есть довольно подробные профили, так что возможность была). Да, их не 27.000, но и 200 человек, ИМХО, это уже неплохая выборка, чтобы начать. Тем более что определенные тенденции в поведении проявились достаточно быстро, на основании чего можно было выделить категории а-ля "себя показать" и "на других посмотреть" (утрирую, конечно)
3) Собрали непосредственную обратную связь от пользователей применительно к задаче, которую мы решали (через форму обратной связи и интервьюирование отдельных пользователей)
4) Обсудили наши выводы с заказчиками (с этим тоже повезло, т.к. заказчики лично знают многих пользователей и смогли добавить ценных сведений)Я не считаю результат 100% попаданием "в яблочко". Но в то же время не думаю, что для составления персон требуются какие-то особые уникальные навыки и сакральные знания.
Теперь о целях. Ключевая цель Анн — не просто "прорекламировать" свои профессиональные услуги, а проявить себя как личность, показать, что она — особенная, выделиться, в общем. Анн воспринимает свой профиль, в некотором роде, как продолжение себя, и очень привязана к нему. И так как Анн — персонаж нестандартный, творческий, весь такой "не похожий на всех остальных", профиль должен соответствовать.
Поэтому при проектировании мы заложили возможности, позволяющие таким, как Анн, сделать свои профили визуально и по структуре отличными от остальных, добавив расширенные возможности кастомизации. На это решение, конечно же, не повлиял бы тот факт, что она пила чай, а не кофе. Но эти мелкие детали, как мне кажется, позволяют добавить реалистичности и оживить персонаж.
Если я, конечно, не ошибаюсь, у вас в профиле Linkedin указан навык "Creating Scenarios and Personas", т.е. смею предположить, в своей работе вы персон используете. Возможно, вы сможете поделиться результатами своей работы (без "секретной информации", конечно же)? Мне лично (и я думаю остальным тоже) было бы очень интересно посмотреть и обсудить процесс их создания. Ну или какими-нибудь чужими примерами, которые вы считаете достойными внимания.
В статье, действительно, не описано, откуда берутся персоны и откуда, в частности, взялась Анн Брукс.
Об этом действительно нужно было подробнее рассказать. Ведь без такого рассказа создаётся ощущение, что персоны получаются сами-собой, "из воздуха".
Для выделения персон на этом проекте (замечу, проект реально существующий, функционирующий, хоть и бета, так что эмприрические данные имеются) мы
предприняли следующие шаги:
1) Посмотрели данные веб-аналитики
2) Изучили данные зарегистрированных пользователей (в системе есть довольно подробные профили, так что возможность была). Да, их не 27.000, но и 200 человек, ИМХО, это уже неплохая выборка, чтобы начать. Тем более что определенные тенденции в поведении проявились достаточно быстро, на основании чего можно было выделить категории а-ля "себя показать" и "на других посмотреть" (утрирую, конечно)
3) Собрали непосредственную обратную связь от пользователей применительно к задаче, которую мы решали (через форму обратной связи и интервьюирование отдельных пользователей)
4) Обсудили наши выводы с заказчиками (с этим тоже повезло, т.к. заказчики лично знают многих пользователей и смогли добавить ценных сведений)+10
Это снимает 60% моих претензий.
Ок. Данные собрали. Но как из них выделить персонажей? Приходится распутывать клубок шаг за шагом.
Ещё 30% претензий снимаются по причине того, что были представлены собственные персонажи из реального проекта, а не пример из интернета.
Из оставшихся 20%, 10% связаны с субъективностью персонажей: два разных исследователя-аналитика для одного проекта могут составить различный набор персонажей. Как определить, какой из наборов является более точным?
Ешё 10% скорее всего с разницей в восприятии. Существует около десятка методов описания пользователей: Пользовательские Роли, Актеры, Профили пользователей, Архетипы, Сегменты… Все в какой-то мере работают. Различаются уровнем детализации и точностью описания.
Для персон характерна высокая детализация и очень большой разброс по точности. Именно случай персонажей с высокой детализацией и малой реальной точностью вызывает опасения.
Но эти мелкие детали, как мне кажется, позволяют добавить реалистичности и оживить персонаж.
Мне, как проектировщику, в данном случае было бы удобнее работать c менее детальными, но более точными описаниями. Приходится проделывать двойную работу — отфильтровывать описания персонажей от фоновых деталей для того чтобы выделить то, что действительно значимо. B этом случае дополнительная детализация несёт минимальную добавочную полезную нагрузку.
Если я, конечно, не ошибаюсь, у вас в профиле Linkedin указан навык "Creating Scenarios and Personas", т.е. смею предположить, в своей работе вы персон используете. Возможно, вы сможете поделиться результатами своей работы (без "секретной информации", конечно же)? Мне лично (и я думаю остальным тоже) было бы очень интересно посмотреть и обсудить процесс их создания. Ну или какими-нибудь чужими примерами, которые вы считаете достойными внимания.
На самом деле, кое в чем мне не повезло, всё никак не получается поработать на хорошем проекте с сильным UX Analyst или UX Researcher. Так что отношения со всей этой тематикой получаются скорее случайными и теоретическими, чем систематическими. Прослушал курс о персонах, читал Купера, Гудвин, Адлин, несколько раз применял AD Hoc Personas на проектах. Получалось с переменным успехом. Особого преимущества не заметил.
Потом почитал:
http://www.graphpaper.com/2006/03-29_ia … f-personas
http://www.devoil.com/papers/PersonasCo … armful.pdf
http://www.portigal.com/wp/wp-content/u … -Grata.pdfСовпало с собственными впечатлениями.
Кое чем поделюсь. В последнее время достаточно много думаю о том, что для "типичных" веб сайтов, существуют и типичные пользовательские архетипы. Например, поведенческие группы пользователей, выделенные для одной ситуации можно использовать и для других подобных случаев. Т.е. вместо создания персонажей мы используем какую-то более универсальную классификацию пользователей.
Например, использование типологии личности по Кейрси/ MBTI. (http://www.keirsey.com/4temps/overview_temperaments.asp).
4 поведенческих типа личности: Традиционалист (Guardian), Гедонист (Artisian), Идеалист (Idealist) и Рационалист (Rational). У каждого свои предпочтения к функциональности и контенту. Традиционалисты и Гедонисты составляют 70-80% населения. Если наш дизайн/ контент/ функциональность покрывает их потребности, то мы уже на достаточно хорошем уровне.Дополнительно, можно использоватьдругие классификации, например по тому, на какой стадии покупательского цикла находится посетитель сайта. Провераяем, что наш сайт может предложить пользователю:
- Выбирающему место покупки и саму покупку;
- Решившему совершить покупку;
- Обращающемуся за поддержкой.У каждой из этих пользовательских групп свои потребности. Т.е. на уровне списка функциональности, карты сайта мы можем оченивать как покрыты потребности каждой из групп пользователей.
Не претендую на академичность подхода, но добавлю от себя.
У нас на проекте также используются персоны, они "выросли" логичным образом из акторов, обрастая именами, изображениями/фотографиями и некоторыми деталями.Например так:
Менеджер в ХХХ компании, управляет ХХХ нескольких Клиентов. Имеет доступ ко всей функциональности, включая ограниченный ХХХ. Предполагается, что в основном занимается управленческими и контролирующими активностями.
/аля-фото/
Боб 38 лет, владелец небольшой ХХХ. Сейчас подчинении 5 человек, однако, если дела продолжат идти в гору, Боб хочет нанять еще 5-10 сотрудников. Решает в основном коммерческие вопросы по общению с клиентами и распределением задач между подчиненными. Несмотря на некоторый опыт, непосредственно ХХХ занимается редко, делегируя работу подчиненным.Что лично нам это дало:
* эмпатия к нашему пользователю
* принятие и проверка решений ("А Боб бы использовал этот отчет?") — звучит глупо, но помогает).У нас на проекте также используются персоны, они "выросли" логичным образом из акторов, обрастая именами, изображениями/фотографиями и некоторыми деталями.
Такой подход кажется достаточно эффективным и практичным.
Одни из самых сильных сторон персонажей проявляются в случае, если с их помощью получается ещё и сегментировать пользователей внутри ролей. Т.е. если среди пользователей с определённой ролью обнаруживается несколько подгрупп с различными целями и поведением.
Из оставшихся 20%, 10% связаны с субъективностью персонажей: два разных исследователя-аналитика для одного проекта могут составить различный набор персонажей. Как определить, какой из наборов является более точным?
Вряд ли можно полностью избавиться от субъективности. Точно так же два разных аналитика зададут разные вопросы, напишут разные спецификации, нарисуют разные макеты…
Мне, как проектировщику, в данном случае было бы удобнее работать c менее детальными, но более точными описаниями. Приходится проделывать двойную работу — отфильтровывать описания персонажей от фоновых деталей для того чтобы выделить то, что действительно значимо. B этом случае дополнительная детализация несёт минимальную добавочную полезную нагрузку.
Это не финальный артефакт, а то, что мы используем для мозгового штурма и составления карты сценария. Для остальной работы используются более короткие описания (все персоны на одном альбомном листе с ключевыми особенностями: демографические и психографические данные, цели и "болевые точки"). Вся эта работа затем трансформируется в макеты интерфейса.
Кое чем поделюсь. В последнее время достаточно много думаю о том, что для "типичных" веб сайтов, существуют и типичные пользовательские архетипы. Например, поведенческие группы пользователей, выделенные для одной ситуации можно использовать и для других подобных случаев.
С этим согласна на 100%. В большинстве случаев мы создаем не абсолютно новые продукты, так что существуют какие-то похожие системы. Поэтому первым делом я всегда стараюсь найти результаты пользовательских исследований для похожих систем. Не всегда, конечно, они есть в свободном доступе, но когда есть — это уже позволяет заранее обратить внимание на какие-то вещи.
С типологиями Кейрси и Майерс-Бриггс сталкивалась когда-то давно на общей психологии: в то время меня не впечатлило, а ныне и вовсе подзабылось. Так что спасибо за ссылку, освежу в памяти и попробую соотнести с новыми знаниями
А что вы думаете о классификации VALS?Интересная классификация, спасибо за ссылку!С типологиями Кейрси и Майерс-Бриггс сталкивалась когда-то давно на общей психологии: в то время меня не впечатлило, а ныне и вовсе подзабылось. Так что спасибо за ссылку, освежу в памяти и попробую соотнести с новыми знаниями
А что вы думаете о классификации [url=http://www.strategicbusinessinsights.com/vals/ustypes.shtml]VALS[/url]?Для оптимального применения персонажей/ типологии в проектировании необходимо выделить 1-2 ключевых персонажа + возможно ещё максимум 4 второстепенных. При большем количестве будет сложно сконцентрироваться.
Достоинством типологии Кейрси является относительная простота применения. Всего 4 основных типа, достаточно много открытой подробной информации. 2 из типов: Традиционалисты и Гедонисты покрывают 70-80 процентов населения, так что при проектировании для широкой аудитории работа на оба этих типа даёт уже неплохое покрытие-точность.
У Маерс-Бриггс типов уже 16,они более-менее равномерно распределены, не сгруппированы, так что работать сложнее, появляется излишняя детализация. Это скорее как дополнительное описение для Кейрси.
То же самое, относится и к VALS: 8 типов, равномерно распределены и не совсем ясно, как нужно проектировать, чтобы удовлетворить потребности каждого из них.
На выходных прочитал книгу Steve Mulder The User Is Always Right. Понятно описано, как создаются персонажи вышего ценового диапазона, вроде тех, о которых рассказывал Санжар Кеттенбеков: до 3 месяцев на разработку, бюджет порядка €500.000… Много исследований и статистического анализа + капелька креативности для вкуса.Всем привет!С огромной задержкой, но все же удалось мне привести в порядок свои пометки по последней встрече analyst.by. Как обещала, публикую детализацию своего доклада о разных интересных трюках по созданию положительного опыта взаимодействия. С той оговоркой, что все эти принципы можно использовать не только с пользователями, но и с заказчиками, работать с которыми аналитикам (и не только) приходится не меньше. А что-то применимо и по отношению к другим членам команды… но обо всем по порядку.
Читать далее
Вы должны авторизироваться для ответа в этой теме.
