Смотритель: barsrsind
  • ,

Обновленный логотип Фонда

Представляем эксклюзивом слегка обновленный логотип Фонда содействия развитию малых форм предприятий в научно-технической сфере, а также новое наименование Фонда – Фонд содействия инновациям. Хотя почему новое… Согласно постановлению Правительства РФ от 27 января 2011 года официальное сокращенное название Фонда – Фонд содействия инновациям, то есть названию уже больше 5 лет(!), а большинство его даже не знает.
22 года назад, когда Фонд начинал свою деятельность, основной задачей его была как раз финансовая поддержка малых предприятий, занимающихся наукоемким бизнесом. Поэтому такое длинное название – Фонд содействия развитию малых форм предприятий в научно-технической сфере – себя вполне оправдывало. Но за последние годы деятельность Фонда стала заметно шире. Мы запустили программу «УМНИК», нацеленную на поддержку молодых инноваторов, занимаемся развитием Центров молодежного инновационного творчества, с 2012 года Фонд является соорганизатором крупнейшего международного форума «Открытые инновации», проводится работа по поддержке и мониторингу инновационной инфраструктуры. В связи с этим полное наименование Фонда не до конца отражает всю его деятельность. Говорить о проблемах правильного произношения полного названия Фонда нет необходимости – многие намучались)
Так что, если вдруг увидите наш новый логотип, не пугайтесь!) (Антон Бобринев)

6.1-6.7 "Об интерфейсе", Алан Купер, Роберт Рейман и Девид Кронин



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

6.2 Создавая вымышленную историю о том, как человек использует наш продукт, мы получаем от своего творчества гораздо больше выгоды, чем если просто пытаемся выдумать лучший форм-фактор или расположение элементов на экране. Более того, повествование благодаря присущему ему аспекту социальности является очень действенным способом обмена хорошими идеями с участниками команды и заинтересованными лицами. В конечном счете, проектирование опыта, основанное на повествовании, дает более понятный и интересный для пользователей результат, поскольку основой служил рассказ.
Поскольку проектирование взаимодействия – это прежде всего проектирование поведения, а поведение характеризуется протяженностью во времени, повествовательная структура в сочетании с простейшими инструментами визуализации, такими как доска с маркерами (whiteboard), идеально подходит для описания, представления и проверки концепций проектирования.
Повествования в проектировании взаимодействия во многом напоминают комикс-раскадровку в киноиндустрии: их общими чертами являются наличие сюжета и краткость. Излишне детальная проработка раскадровок является пустой тратой времени и денег имеет тенденцию приводить к созданию неоптимальных идей – просто потому, что рисование поглощает значительные ресурсы.

6.3 В девяностые годы сообществом HCI (Human'Computer Interaction – взаимодействие человека и компьютера) была проделана значительная работа в области проектирования программ, ориентированных на варианты использования. Здесь находятся истоки понятия сценария, которое широко используется как указание на метод решения задач проектирования через конкретизацию – использование специально составленного рассказа, чтобы одновременно конструировать и иллюстрировать проектные решения.
Сценарии, основанные на персонажах, суть краткие нарративные описания одного или более персонажей, применяющих продукт для достижения конкретных целей. Сценарии позволяют начинать проектирование с рассказа, описывающего идеальный с точки зрения персонажа опыт, фокусируя внимание на людях, их образе мысли и поведении, а не на технологии или бизнес-целях.
В основе контекста и содержания сценария лежит информация, собранная на этапе исследований и подвергнутая анализу на этапе моделирования.
Такой процесс приводит к немедленному синтезу структуры и поведения продукта (как правило, на доске), которые позже прорабатываются более детально. Наконец, на протяжении всего процесса проектирования персонажи и сценарии применяются для проверки разумности допущений и пригодности выдвигаемых идей.

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

6.5 Как сценарии, основанные на персонажах, так и варианты использования (use cases) представляют собой методы описания взаимодействия пользователя с системой. Однако они решают очень разные задачи. Целеориентированные сценарии суть средство для итерационного определения поведения продукта с позиции конкретных пользователей.
Варианты использования – это методика, основанная на исчерпывающем описании функциональных требований к системе, часто носящем транзакционный характер и ориентированном на низкоуровневые действия пользователя и соответствующие реакции системы (Wirfs'Brock, 1993).

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

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

2. Мозговой штурм.

3. Выявление ожиданий персонажей. Необходимо записать ожидания пользователей в формальном виде.

4. Разработка контекстных сценариев. Они описывают широкий контекст, в котором проявляются шаблоны использования, и включают информацию о среде использования и об организационных вопросах.
Концентрируйтесь на том, как проектируемый продукт может наилучшим образом помогать персонажам в достижении их целей.
Контекстные сценарии отвечают на вопросы, подобные этим:
• В какой обстановке будет использоваться продукт?
• Будет ли он использоваться в течение долгого времени?
• Часты ли прерывания в работе персонажа?
• Работает ли с компьютером/устройством более чем один пользователь?
• Какие еще продукты используются вместе с проектируемым?
• Какие основные действия должен выполнить персонаж, чтобы достичь своих целей?
• Каков ожидаемый конечный результат применения продукта?
• Какова допустимая сложность продукта исходя из частоты его использования и навыков персонажа?

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

5.10-5.17 "Об интерфейсе", Алан Купер, Роберт Рейман и Девид Кронин



5.10 Самый важный принцип проектирования взаимодействия — не заставляйте пользователей чувствовать себя дураками.

Разработка персонажей включает следующие основные шаги процесса:
1. Выявить поведенческие переменные (перечислить самостоятельные аспекты наблюдавшихся вариантов поведения, то есть создать набор поведенческих переменных).
2. Сопоставить респондентов с поведенческими переменными.
3. Выявить значимые шаблоны поведения.
4. Синтезировать характеристики и соответствующие им цели.
5. Проверить полноту и выявить избыточность.
6. Расширить описание атрибутов и поведений.
7. Назначить персонажам типы (с. 133-134).

5.11 Шаг 1. В общем случае наиболее важные различия между шаблонами поведения определяются при рассмотрении следующих типов переменных:
• Деятельность: чем занят пользователь, частота и объем.
• Взгляды: каким образом пользователь думает о предметной области и технологии продукта.
• Наклонности: каковы образование и подготовка пользователя, его способность обучаться.
• Мотивация: каким образом пользователь вовлечен в предметную область продукта.
• Навыки: умения пользователя, связанные с предметной областью продукта и используемой технологией (с.134-135).

5.12Шаг 2. Некоторые из переменных будут отражать непрерывный диапазон поведения (к примеру, от новичка до эксперта в компьютерной области), а некоторые – дискретные варианты выбора (скажем, использование цифрового либо пленочного фотоаппарата). Здесь важна не столько точность значений, сколько взаимное расположение респондентов (с. 135).

5.13 Шаг 3. Разместив респондентов по осям, найдите группы (кластеры) отдельных респондентов, близких сразу по нескольким диапазонам или переменным. Группа респондентов, кластеризованная сразу по шести'
восьми различным переменным, вероятнее всего, представляет значимый шаблон поведения, который ляжет в основу персонажа. У некоторых специализированных ролей может быть лишь один значимый шаблон, однако обычно таких шаблонов два или даже три. Чтобы шаблон считался корректным, должна существовать логическая или причинно-следственная связь между кластеризованными поведениями, а не просто случайная корреляция (с.135-136).

5.14 Шаг 4. Для каждого выявленного значимого шаблона поведения необходимо синтезировать детали на основе
ваших данных. Опишите среду потенциального использования, типичный рабочий день (или иной подходящий контекст), существующие решения задач и причины недовольства пользователей этими решениями, а также значимые отношения с окружающими.
На этом этапе достаточно простого перечисления различных характеристик поведения, представленного в сжатой форме. Старайтесь держаться как можно ближе к наблюдавшемуся поведению. Описание одной-двух характерных для личности персонажа деталей поможет вдохнуть в него жизнь. В то же время слишком длинная и чересчур не' обычная вымышленная биография, напротив, сделает персонажа менее правдоподобным.
Цели – самая важная из деталей, синтезируемых на основе данных интервью и наблюдений за поведением. Лучше всего эта задача решается посредством анализа шаблонов поведения, присущих каждому персонажу.
Связать набор персонажей единственной социальной связью, безусловно, проще, чем задать несколько различных и неродственных социальных связей между отдельными персонажами и другими, не входящими в набор персонажей лицами, однако гораздо лучше изначально приложить усилия к созданию разнообразных персонажей, чтобы потом не возникало искушения подчинить совершенно непохожие сценарии динамике одной социальной группы (с. 136-138).

5.15Шаг 5. Проверьте соответствие персонажей и поведенческих переменных, а также характеристики и цели персонажей – нет ли существенных пробелов, которые требуют заполнения?
Каждый персонаж должен отличаться от всех прочих по меньшей мере одним значимым вариантом поведения (с. 138).

5.16Шаг 6. Перечень характеристик и целей, полученный на шаге 4, очерчивает сущность сложного поведения, однако оставляет многие вещи нераскрытыми. Повествование от третьего лица является гораздо более ярким способом представить взгляды, потребности и проблемы персонажа другим участникам процесса разработки.
Типичное описание персонажа – это синтез наиболее важных деталей, полученных в ходе исследований и относящихся к этому персонажу.
Как правило, рассказ об одном персонаже не должен занимать более одной'двух страниц. Повествование не обязано включать все наблюдавшиеся детали, поскольку в идеальном варианте проектировщики принимали участие в исследовании, а большинству людей за пределами команды проектировщиков более подробное изложение и не требуется.
В начале создания повествовательных описаний выберите фотографии для своих персонажей.
При создании подобных вспомогательных средств коммуникации важно помнить, что персонажи – не самоцель, а лишь инструменты для проектирования и принятия решений (с. 139-140).

5.17 Шаг 7. К этому моменту ваши персонажи должны восприниматься уже как настоящие люди, которых вы знаете. У проектирования всегда должна быть цель – та аудитория, на которой сосредоточен процесс проектирования. И, как правило, чем конкретнее обозначена эта цель, тем лучше. Создание интерфейсного решения, отвечающего потребностям хотя бы трех-четырех персонажей одновременно, уже может оказаться весьма сложной задачей.
Посему необходимо назначить персонажам приоритеты, определяющие, кто из них станет основной целью проектирования.
Задача в том, чтобы выбрать из набора того персонажа, чьи нужды и цели можно полностью удовлетворить посредством одного интерфейса, не забывая при этом об остальных персонажах. Мы решаем эту задачу, назначая персонажам типы. Существует шесть типов персонажей, которые назначаются обычно в таком порядке:
ключевой. На один интерфейс в продукте может приходиться только один ключевой персонаж, однако для некоторых продуктов (в особенности для корпоративного пользования) возможно наличие нескольких различных интерфейсов, каждый из которых ориентирован на отдельного ключевого персонажа.
Ключевой персонаж выбирается методом исключения: цели каждого персонажа следует рассмотреть в сравнении с целями остальных. Если не очевидно, какой из персонажей является ключевым, это может означать одно из двух: или продукту требуется несколько интерфейсов, каждый из которых предназначен для своего ключевого персонажа (так часто бывает в корпоративных и технических продуктах), или же продукт «берет на себя» слишком многое. Если у потребительского продукта несколько ключевых персонажей, то, возможно, объем егофункциональности слишком широк;

При проектировании каждого интерфейса сосредотачивайтесь на единственном ключевом персонаже.

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

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

покупатель;

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

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

Персонажи – крайне полезный инструмент, однако они не являются единственным инструментом, помогающим моделировать пользователей и их окружение. В работе «Contextual Design» Хольцблат и Бейера содержится огромный объем информации о моделях, например, модели артефактов, физические модели, модели бизнес-процессов (диаграммы бизнес-процессов и диаграммы последовательностей).
Хорошо проработанный персонаж должен в достаточной степени отражать личный рабочий процесс, однако на межличностном и организационном уровне модели бизнес-процессов все же необходимы для отражения рабочего взаимодействия.
При этом пользовательский интерфейс, опирающийся преимущественно на модели бизнес-процессов, часто терпит неудачу по той же причине, что и программы, спроектированные в модели реализации, взаимодействие с которыми основано на их внутренней технической структуре. Поскольку бизнес-процессы для бизнеса являются по сути тем же, чем структура для программирования, проектирование на основе бизнес-процессов в результате дает некую «бизнес-модель реализации», охватывающую всю функциональность, но не учитывающую человека.

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

5.1-5.9 "Об интерфейсе", Алан Купер, Роберт Рейман и Девид Кронин



5.1 Персонажи — описательные модели пользователей на основе поведенческих шаблонов из исследований.
Проектировщики должны создавать модели пользователей на основе данных наблюдений за их поведением, интуитивно выявляя общие зависимости в этих данных. Лишь после формализации найденных зависимостей можно надеяться на систематическое конструирование таких шаблонов взаимодействия пользователя с продуктом, которые будут хорошо соответствовать поведению, ментальным моделям и целям пользователей. Такую формализацию обеспечивают персонажи (с. 109-111).

5.2 Лучший способ успешно удовлетворить потребности широкой аудитории – проектировать для конкретных типов людей с конкретными потребностями. Беспорядочно наращивая функциональность продукта, чтобы охватить как можно более широкую аудиторию, вы увеличиваете когнитивную нагрузку на всех пользователей и осложняете им ориентирование в пределах продукта.
Персонажи помогают проектировщикам:
• Определять, что должен делать продукт и каким должно быть его поведение. Цели и задачи персонажей образуют фундамент для проектирования.
• Общаться с заинтересованными лицами, разработчиками и другими проектировщиками. Персонажи задают общий язык для обсуждения проектных решений, а также помогают удерживать фокус на
пользователях на каждом шаге процесса.
• Достигать взаимопонимания и согласия в вопросах проектирования. С общим языком приходит и общее понимание. Персонажи сокращают потребность в подробных моделях и диаграммах: многочисленные нюансы поведения пользователей проще понять благодаря повествовательным средствам, на которых основана работа с персонажами. Проще говоря, поскольку персонажи напоминают живых людей, они воспринимаются легче, чем диаграммы и списки функций.
• Оценивать эффективность решений. На персонажах можно испытывать проектные решения в процессе их формирования так, словно вы показываете их реальным пользователям. Хотя этот метод не отменяет необходимость тестирования на реальных пользователях, он является мощным средством проверки найденных при проектировании решений на соответствие реальности. Это позволяет быстро и недорого выполнять итерации проектирования, пользуясь лишь набросками на доске, и при этом подойти к моменту тестирования на реальных пользователях с более сильными интерфейсными решениями.
•Вносить вклад в работу других подразделений, связанных с продуктом, например в планы по маркетингу и продажам. Авторы сталкивались с тем, что клиенты начинают применять персонажей внутри своей организации в иных целях, например в качестве источника информации для маркетинговых кампаний, развития структуры организации и других задач стратегического планирования. Подразделения, не имеющие непосредственного отношения к разработке продукта, жаждут подробной информации о пользователях продукта и обычно проявляют к персонажам огромный интерес.

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

Виды исследований, являющиеся основой для создания персонажей:
• данные интервью с пользователями в контексте использования;
• данные интервью с пользователями вне контекста использования;
• информацию о пользователях, предоставленную заинтересованными лицами и экспертами в предметной области (ЭПО);
• данные исследований рынка, таких как фокус-группы и опросы;
• модели сегментации рынка;
• результаты обзора литературы и более ранних исследований (с. 111-115).

5.3 Персонаж вбирает в себя уникальный набор шаблонов поведения, связанных с использованием определенного продукта (или с аналогичной деятельностью в предметной области, если продукт еще не существует), которые выявляются посредством анализа данных интервью и при необходимости подкрепляются дополнительными количественными данными.
Чтобы набор персонажей был эффективным средством проектирования для нескольких продуктов, персонажей следует создавать на основе исследований, охватывающих контексты использования всех этих продуктов.
Мы считаем, что в большинстве случаев для различных продуктов следует изучать и создавать самостоятельных персонажей.
Стереотипы во многих отношениях являются противоположностью хорошо проработанных персонажей, так как представляют предубеждения и предположения проектировщиков и исследователей, а не фактические данные. Персонажи должны быть типичными и правдоподобными, но не стереотипными.
Смысл персонажей не в определении среднего пользователя, а в выявлении образцов поведения в рамках определенного спектра. Поэтому нужно для каждого продукта определить набор персонажей.
Крайне важно, чтобы персонажи отражали мотивы пользователей – в виде описания целей (с. 115-118).

5.4 Роли пользователей, или ролевые модели, в определении Ларри Константайна, являются абстракцией – определенным соотношением между классом пользователей и их задачами, включая потребности, интересы, ожидания и шаблоны поведения (Constantine and Lockwood, 1999). Будучи абстракциями (принимающими обычно форму списка атрибутов), роли не визуализируются в виде людей, а потому обычно неспособны передавать более широкие человеческие мотивы и контексты. Персонажи дают более целостную модель пользователей и контекста, в котором эти пользователи находятся, тогда как многие другие модели, напротив, стремятся к большей схематичности. Персонажей, конечно же, можно применять в сочетании с другими методиками моделирования, и, как мы увидим в конце главы, некоторые модели становятся крайне полезными дополнениями к персонажам (с. 119-121).

5.5 Иногда в некоторых случаях просто не хватает времени, ресурсов или поддержки со стороны руководства, чтобы выполнить всю необходимую работу «в поле». Здесь могут помочьусловные персонажи.
Условные персонажи структурируются аналогично реальным персонажам, но основаны на доступных данных, а также на догадках проектировщика о поведении, мотивах и целях. Как правило, в основу кладется сочетание экспертных знаний заинтересованных лиц и ЭПО о пользователях (когда такая информация доступна), а также выводы о пользователях, сделанные на основе существующих данных по рынку. По сути дела условные персонажи – это гипотеза о персонажах, на которую нарастили немного «мяса».
Правда, есть и тонкости: условные персонажи потому и называются условными, что служат всего лишь дублерами персонажей, основанных на полноценных качественных данных, поэтому тут кроются многие риски:
• сфокусировать усилия на неверных целях проектирования;
• сфокусировать усилия на верных целях, но упустить из виду ключевые аспекты поведения, которые сделали бы ваш продукт особенным;
• столкнуться со сложностями в получении поддержки лиц и групп, которые не участвовали в создании персонажей;
• дискредитировать ценность персонажей и получить долгосрочную аллергию на них на уровне организации в целом (с. 121-123).

5.6 В то время как персонажи задают контекст для шаблонов вариантов поведения, цели являются стимулами этого поведения. Персонаж без целей полезен в качестве инструмента коммуникации, но теряет ценность в качестве средства проектирования. Именно цели людей или персонажей побуждают их вести себя определенным образом. Таким образом, цели не только отвечают на вопрос, почему и как персонажи желают пользоваться продуктом, но могут также служить проектировщику компактным внутренним представлением для подчас весьма сложного поведения персонажа, равно как и решаемых персонажем задач.
Одной из важнейших задач в моделировании персонажей является выявление целей и их краткое выражение: каждая цель должна описываться одним простым предложением (с. 123-124).

5.7 В своей книге «Emotional Design» (Norman, 2005) Дон Норман выдвигает идею о том, что проектирование продукта должно затрагивать три различных уровня когнитивной и эмоциональной обработки, которые он называет физиологическим, поведенческим и аналитическим.
Проектирование для физиологического уровня означает проектирование того, что изначально воспринимается человеком через органы чувств, прежде чем он более близко познакомится с продуктом или артефактом.
Интересный факт: исследователям в области юзабилити удалось показать, что пользователи изначально считают привлекательные интерфейсы более удобными – и эта уверенность зачастую сохраняется еще долго после того, как пользователь приобрел достаточный опыт обращения с интерфейсом и обладает неоспоримыми свидетельствами обратного (Dillon, 2001).
Проектирование для уровня поведенческих реакций означает создание такого поведения продукта, которое дополнит собственное поведение пользователя, входя в соответствие его неявным предположениям и ментальным моделям. Из трех уровней проектирования, анализируемых Норманом, проектирование поведения, вероятно, лучше всего знакомо проектировщикам взаимодействия и юзабилити-специалистам.
В идеальном случае опыт взаимодействия пользователя с продуктом или артефактом будет гармонизацией элементов проектирования физиологического и аналитического с фокусировкой на проектировании поведения (с. 124-127).

5.8 Чтобы связать эти три уровня с проектированием, нужно учитывать три типа пользовательских целей соответствуют уровням когнитивной обработки по Норману – физиологическому, поведенческому, аналитическому:
• эмоциональные цели;
• конечные цели;
• жизненные цели.

Вот примеры эмоциональных целей:
• Чувствовать уверенность в том, что ситуация под контролем.
• Получать удовольствие.
• Ощущать душевный подъем или расслабленность.
• Быть собранным и сосредоточенным.

Вот некоторые примеры конечных целей:
• Узнавать о проблемах до того, как они послужат причиной катастрофы.
• Поддерживать контакт с родными и друзьями.
• Заканчивать запланированные дела к пяти часам вечера ежедневно.
• Найти музыку, которая мне понравится.
• Получить наилучшее предложение.

Вот примеры таких целей:
• Прожить хорошую жизнь.
• Преуспеть в реализации амбиций.
• Стать знатоком в определенной области.
• Быть привлекательным, популярным, завоевать уважение коллег.

Связав цели персонажа с моделью Нормана, мы можем обозначить самые важные побуждающие стимулы пользователей:
• Эмоциональные цели, связанные с физиологическим уровнем обработки: как пользователь хочет себя чувствовать.
• Конечные цели, связанные с поведением: что пользователь хочет делать.
• Жизненные цели, связанные с анализом и рефлексией: кем пользователь хочет быть (с. 127-130).

5.9 Пользовательские цели – не единственная разновидность целей, которую проектировщики должны принимать во внимание. Цели покупателей, бизнес-цели и технические цели – это непользовательские цели. Обычно эти цели следует учитывать и рассматривать, однако они не влияют на основное направление проектирования. На эти цели также нужно ориентироваться, но их нельзя удовлетворять за счет пользователя (с. 131-133).

4.10-4.14 "Об интерфейсе", Алан Купер, Роберт Рейман и Девид Кронин



Этнографические интервью: интервьюирование и наблюдение за пользователями

4.10 Техника этнографических интервью представляет собой сочетание методик включенного наблюдения и направленного интервьюирования. Одним из примеров такой техники является контекстное исследование.
Согласно Бейеру и Хольцблат, оно основано на ремесленнической (мастер – подмастерье) модели обучения: необходимо наблюдать за пользователем и задавать ему вопросы так, как если бы он был высококлассным ремесленником, а интервьюер – его новым подмастерьем. Бейер и Хольцблат перечисляют также четыре базовых принципа организации этнографических интервью:
• Контекст (взаимодействовать с пользователями и наблюдать в естественной рабочей среде).
• Сотрудничество.
• Интерпретация (исключить ошибки в ней).
• Направленность (адекватность вопросов) (с. 90-91).

4.11 Заимствованный из антропологии термин «этнография» обозначает систематическое изучение человеческих культур, подразумевающее погружение в эти культуры.
Поскольку проектировщики должны охватить весь спектр поведения пользователей в отношении продукта, крайне важно при планировании серии интервью отобрать в нужной степени разнородную группу пользователей и типов пользователей. Основываясь на информации, полученной от заинтересованных лиц и ЭПО, а также в результате обзора литературы, проектировщики должны выдвинуть гипотезу, которая послужит точкой отсчета в определении того, каких именно пользователей и потенциальных пользователей необходимо интервьюировать.
Гипотеза о персонажах пытается дать общие ответы на следующие три вопроса:
• Каковы категории людей, которые могут использовать данный продукт?
• Как могут различаться их потребности и поведение?
• Какие шаблоны поведения и типы рабочей обстановки необходимо изучить?
В связи с тем, что до сбора данных о пользователях точно предсказать поведенческие переменные сложно, часто применяется другой подход к построению гипотезы о персонажах – использование
демографических переменных. При планировании интервью вы можете с помощью исследований рынка выявить распределение целевой аудитории по половозрастному и географическому составу, а также по уровню дохода. Участники интервью должны как можно шире распределяться по этим демографическим спектрам, чтобы в получившейся выборке респондентов оказались представлены все важные шаблоны поведения.
После того как вы сформулировали гипотезу о персонажах, содержащую описание потенциальных ролей, а также поведенческих, демографических и средовых переменных, необходимо составить план проведения интервью, который можно передать человеку, отвечающему за организацию встреч с пользователями. Из нашего опыта следует, что для проверки каждого потенциального поведенческого шаблона требуется примерно шесть интервью (а в особо сложных предметных областях и больше). Это означает, что каждая роль или переменная (поведенческая, демографическая или средовая),
обозначенная в гипотезе о персонажах, исследуется в четырех-шести интервью (и, соответственно, более, если речь идет о сложной предметной области)(с. 92-96).

4.12 При проведении интервью авторы отдают предпочтение командам из двух проектировщиков: один управляет ходом интервью и делает простые заметки, а другой ведет подробные записи (в середине интервью проектировщики могут меняться ролями). Часового интервью на каждого пользователя обычно достаточно, за исключением случаев очень сложных предметных областей (медицина, наука, финансовые службы). Следует ограничиваться шестью интервью в день, чтобы между ними оставалось достаточно времени на внутреннее обсуждение и выработку стратегических планов дальнейших интервью, а также чтобы избежать переутомления интервьюеров.
Фазы этнографических интервью:
• Первичные интервью концентрируются на сборе знаний о предметной области, как ее видит пользователь. Преобладают широкие открытые вопросы, погружение в детали практически отсутствует.
• Уточняющие интервью – этап, на котором проектировщики начинают осознавать основные шаблоны использования продукта и задают открытые уточняющие вопросы, помогающие собрать из фрагментов целостную картину. Вопросы в целом больше сосредоточены на специфике предметной области, поскольку к этому моменту проектировщики уже усвоили ее основные правила, структуру и терминологию.
• Завершающие интервью дают подтверждение ранее выявленным шаблонам использования и дополнительно проясняют пользовательские роли и варианты поведения, корректируют предположения о задачах и информационных потребностях. Закрытых вопросов здесь гораздо больше – с их помощью проясняются все нестыковки в собранных данных.
Основные важные приемы:
• Проводите интервью там, где происходит взаимодействие пользователя с продуктом. Внимательно анализируйте рабочую среду – она с большой вероятностью переполнена подсказками, указывающими на какие-либо задачи, о которых респондент мог и не упомянуть. В частности, обращайте внимание на следующие вещи: информация, необходимая человеку (бумаги на столе или клейкие листочки по периметру монитора); свидетельства неадекватности систем («шпаргалки» и пользовательские руководства); частота и приоритетность задач (папки входящих и исходящих); используемые виды отображения рабочих процессов (памятки, графики, календари).
• Избегайте жесткого следования предопределенным наборам вопросов — это не анкетирование. Ключевые темы для обсуждения: цели, приоритеты, функция, предпочтения, процесс, исключения, профессиональность и др.
• Сначала концентрируйтесь на целях – и лишь потом на задачах. На первом месте стоит необходимость понять, почему и как действуют пользователи (что движет поведением людей в различных ролях и каким образом они рассчитывают в конечном итоге достичь цели), а не что за задачи они решают.
• Не делайте из пользователя проектировщика. Направляйте респондента в сторону формулирования проблем и уводите его от формулирования конкретных интерфейсных решений. Такие решения, как правило, несут на себе отпечаток приоритетов пользователя: ему они представляются хорошими, однако на практике оказываются односторонними и недальновидными, лишенными того равновесия и той проработанности, которых способен достичь проектировщик, располагающий результатами исследований и обладающий многолетним опытом.
• Избегайте дискуссий по технологическим вопросам. Не стоит делать из пользователя не только проектировщика, но также программиста или инженера. Обсуждение технических деталей лишено смысла, если отсутствует понимание стоящих за техническими решениями целей.
• Поощряйте пользователей рассказывать истории.
• Просите показывать и рассказывать.
• Избегайте наводящих вопросов. В интервью очень важно избегать
наводящих вопросов. Вот некоторые примеры наводящих вопросов: Вам бы помогла функция X? Вам нравится X, верно? Как вы думаете, стали бы вы пользоваться X, если бы она была доступна?
После каждого интервью команды сопоставляют заметки и обсуждают наиболее интересные тенденции или конкретные моменты, обнаружившиеся в ходе последнего интервью.
Когда цикл интервью завершен, полезно еще раз пройтись по всем записям, отмечая или подчеркивая тенденции и шаблоны в полученных данных. Это подготовка к следующему шагу – созданию персонажей на основе данных всех исследований (с. 97-102).

4.13 В маркетинговых организациях особенно популярен метод сбора пользовательских данных посредством фокус-групп, в котором репрезентативная группа пользователей, отобранных по заранее выявленным демографическим параметрам, собирается в одной комнате и отвечает на структурированный набор вопросов и/или выбирает ответы из предложенных вариантов. Часто встреча записывается на диктофон или видеокамеру для последующего анализа. Хотя может возникнуть ощущение, что фокус-группы дают необходимый контакт с пользователями, этот метод во многих случаях малопригоден в качестве инструмента проектирования.
Юзабилити-тестирование (или, как его еще не очень удачно называют, пользовательское тестирование) – это набор методик, позволяющих измерить характеристики взаимодействия пользователя с продуктом с целью оценки уровня юзабилити продукта. Как правило, в ходе юзабилити-тестирования изучается, насколько хорошо пользователи выполняют конкретные стандартизированные задачи и с какими проблемами они при этом сталкиваются. Результаты такого тестирования часто помогают выявить как аспекты, затрудняющие понимание и использование продукта, так и удачные решения.
Карточная сортировка – техника, снискавшая популярность благодаря информационным архитекторам. Она позволяет понять, как пользователи организуют идеи и информацию. Существует ряд вариантов этой техники, но обычно она сводится к тому, что пользователей просят выполнить сортировку колоды карт, каждая из которых описывает определенную функциональность продукта или веб-сайта либо содержит связанный с ним фрагмент информации. Сложной частью является анализ результатов: необходимо найти паттерны и зависимости путем выявления тенденций или посредством статистического анализа.
Анализ рабочих заданий — набор методик, задействующих анкетирование или открытые интервью для формирования детального представления о том, как люди в настоящий момент выполняют конкретные задания (с.102-107).

4.14 Пользовательские исследования – фундамент проектирования. Уделяйте планированию исследований достаточное время. Подбирайте методы исследования сообразно этапам разработки. Вашему продукту это пойдет на пользу, а вы сможете избежать потерь времени и ресурсов. Лабораторное тестирование продукта может дать большой объем информации, но не обязательно будет иметь большую ценность. Этнографическое интервьюирование в начале процесса позволяет вам как проектировщику глубоко понять своих пользователей, их потребности и мотивы. Когда ваша концепция продукта построена на основе качественных пользовательских исследований и моделей, опирающихся на результаты этих исследований, юзабилити-тестирование становится еще более эффективным инструментом для оценки решений, принятых в ходе проектирования. Качественные исследования позволяютвзять хороший старт уже в самом начале проекта (с. 108).

4.1-4.9 "Об интерфейсе", Алан Купер, Роберт Рейман и Девид Кронин



4.1 Основой для проектирования являются качественные исследования. Количественные исследования не подходят для оценки человеческой деятельности — ведь у человека каждое мгновение меняется настроение, очень сложное поведение, подверженность влиянию множеству факторов, что вносит определенное искажение в оценку. Поэтому качественные исследования дают более достоверные и точные данные о человеческой деятельности, причем с меньшими затратами (с. 81-83).

Хочется продублировать случай, приведенный в книге:

«Вот весьма показательный случай: клиент попросил нас выполнить исследование пользователей в контексте разработки Windows'продукта, предназначенного для любительского видеомонтажа в домашних условиях. Будучи опытным разработчиком программ для монтажа и создания видео, клиент к тому моменту уже успел провести традиционное исследование рынка и обнаружил хорошую нишу для бизнеса: продукт для людей, которые приобрели цифровую видеокамеру и компьютер, но еще не успели связать эти два устройства. В рамках полевого исследования мы провели интервью с десятками людей из числа потенциальных пользователей. Первое открытие было вполне предсказуемым: больше всех занимались видеосъемкой и стремились делиться смонтированными записями родители. А вот вторая находка оказалась несколько пугающей: из двенадцати человек, к которым мы зашли в гости, лишь один сумел подключить видеокамеру к компьютеру – да и то при помощи коллеги, сведущего в информационных технологиях. Одним из обязательных условий успеха продукта была способность людей перенести видео на компьютер для монтажа, однако на тот момент, как оказалось, очень тяжело было заставить порт FireWire или карту видеозахвата как следует работать на персональном компьютере с процессором Intel.
После четырех дней исследований мы помогли клиенту принять решение: приостановить разработку продукта – что, вероятно, сэкономило компании значительные средства».


4.2 Методы качественных исследований: интервьюирование заинтересованных лиц, экспертов, пользователей, покупателей; наблюдение за пользователями, этнографические полевые исследования; обзор литературы; аудит продукта/прототипа и конкурирующих решений (с. 84).

4.3 Интервьюирование заинтересованных лиц. Проектировщик должен иметь представление о техническом окружении и бизнес-контексте продукта и понимание возможностей и ограничений «материала».
Заинтересованное лицо — это любой человек, обладающий полномочиями в отношении проектируемого продукта и/или несущий ответственность за какой'либо его аспект.
Интервьюирование заинтересованных лиц должно проводиться до начала любых исследований пользовательской аудитории, поскольку возникающие обсуждения нередко задают способы проведения пользовательских исследований. Кроме того, обычно оказывается более эффективным интервьюировать заинтересованных лиц поодиночке, а не в группах, объединяющих сразу несколько отделов.
От заинтересованных лиц важно получить информацию по следующим вопросам:
• Предварительное видение продукта.
• Бюджет и график проекта.
• Технические возможности и ограничения.
• Потребности бизнеса.
• Представления заинтересованных лиц о пользователях.
Обсуждение этих тем важно еще и для выработки общего языка и взаимопонимания между группами проектировщиков, руководителей и разработчиков.

4.4 Интервьюирование экспертов в предметной области (ЭПО). Как и заинтересованные лица, ЭПО способны представить продукт и его пользователей под интересным углом зрения, однако проектировщикам следует проявлять осторожность и понимать, что точка
зрения ЭПО в определенном смысле искажена. Основные моменты:
ЭПО – это зачастую пользователи-эксперты. Часто ЭПО уже не являются пользователями продукта и смотрят на вещи скорее с точки зрения менеджера.
• ЭПО хорошо осведомлены, но они не проектировщики.
• ЭПО необходимы в сложных или специализированных предметных областях.
• Вам понадобится общаться с ЭПО в течение всего процесса проектирования.

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

4.6 Интервьюирование пользователей. В результате хорошо бы получить следующую информацию:
— контекст интеграции продукта в жизнь или рабочий процесс пользователей – когда, почему и каким образом применяется продукт;
— осведомленность в предметной области с точки зрения пользователя;
— существующие задачи и виды деятельности, которые выполняются при помощи данного продукта, и те, которые не поддерживаются им;
— цели и мотивы использования продукта;
— ментальная модель – как пользователи думают о своей работе и деятельности, а также чего они ожидают от продукта;
— проблемы и сложности при работе с продуктом (с. 88-89).

4.7 Наблюдение за пользователями. Для фиксации того, что говорят и делают пользователи, многие юзабилити-специалисты применяют технические средства, такие как аудио- и видеозапись.
Интервью, проводимое вне контекста ситуации, которую стремится понять проектировщик, даст менее полные и менее точные данные. Вероятно, наиболее эффективным методом сбора качественных данных о пользователях является сочетание интервьюирования и наблюдения (с. 89).

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

4.9 Аудит продукта/прототипа и конкурирующих решений. Команде проектировщиков следует провести неформальную эвристическую или экспертную оценку интерфейсов как своего продукта, так и конкурирующих продуктов, проверяя их на соответствие
принципам качественного взаимодействия и визуального дизайна (с.90).

3.1-3.7 "Об интерфейсе", Алан Купер, Роберт Рейман и Девид Кронин



3.1 Существует дилемма — на кого ориентироваться при проектировании интерфейса: новичков, экспертов или середняков. Обычно основной режим интерфейса строится для новичков, а режим для экспертов прячется глубоко в настройках. А если вспомнить, что интерфейс обычно строится на модели реализации вместо представления?
На самом деле нужно просто помнить, что большинство пользователей — не начинающие и не эксперты; они середняки. Все бывают новичками, но никто не задерживается в этой группе надолго. Еще меньше пользователей вырастают в экспертов. Причем навыки пользователей уходят и возвращаются в зависимости от частоты использования продукта. Ларри Константайн тоже отмечал, что нужно проектироваться для середняков, которых он называл совершенствующимися или вечными середняками (с. 73-74).

3.2 Поэтому нужно проектировать интерфейс, в целом ориентируясь на середняков, но учитывая и две крайние группы — новичков и экспертов. Бывает, что у некоторых программ такая специфика, что в ее проектировании нужно ориентироваться на экспертов — обычно это программы для профдеятельности технически ориентированных людей, например, инструменты для разработчиков, специальные измерительные и медицинские приборы. Ожидается что пользователи в этой сфере обладают компетенциями и готовы приложить усилия для изучения продукта (с. 75-76).

3.3 На практике возникает следующая ситуация: программисты используют способы взаимодействия в интерфейсе, подходящие для экспертов, а маркетологи — для новичков. И это при том, что самая важная группа пользователей середнячков. Поэтому оптимизируйте интерфейс для середняков (с. 76-77).

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

3.5 Стандартная встроенная справка — неподходящий способ поддержки начинающих; тут больше подходит «знакомство с программой», как отдельная функция в диалоговом окне. Было отмечено, что должны быть кнопки отмены в диалоговых окнах (с. 78).

3.6 Для экспертов важнее становится быстрый доступ к используемым ими функциям программы, их уже не будет пугать сложность интерфейса (с. 78-79).

3.7 Середнякам нужен доступ к инструментам, им уже не нужны объяснения; идеальны тут всплывающие подсказки. Встроенная справка — инструмент для середняков (с. 79).

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

Глава 3 завершена. В 4 главе речь о том, как понять пользователей и про качественные исследования.

2.6-2.10 "Об интерфейсе", Алан Купер, Роберт Рейман и Девид Кронин



2.6 Как уже было замечено в предыдущем топике, большинство ПО привержены модели реализации. С точки зрения инженера такая модель логичная и понятна, но для пользователя, к сожалению, это не так. Многие моменты с модели реализации, перенесенные в модель представления, вызывают когнитивный диссонанс, затрудняющий освоение и использование продукта (с. 64-65).

2.7 Проектировщики взаимодействия должны защищать пользователей от моделей реализации. Нужно учитывать, что большинство пользователей не обладают математическим мышлением (с. 66-67).

2.8 Новые технологии требуют новых представлений. На нас еще влияет механическая эра. Не стоит копировать артефакты механической эры в пользовательских интерфейсах без учета возможностей информационной эры (с. 68-69).

2.9 Часто привычные нам представления, которые придерживаются того вида, к которому привык пользователь, можно спроектировать лучше (например, календарь — изначально он разбит по месяцам, потому что так удобнее было сделать на бумаге; на мониторе же все просто дублируют его конструкцию вместо того, чтобы перепроектировать в духе информационной эры под нужды пользователей и адаптировать его). Но важно помнить, чтобы существенные изменения приносили значительные улучшения. То есть было, ради чего людям привыкать, адаптироваться к новым представлениям (с. 70-71).

2.10 Наше мышление еще подвержено влиянию механистической эры; улучшить программы позволит мышление, соответствующее информационной эре (с. 71-72).

2 глава завершена. Следующая глава — про новичков, экспертов и середняков.

2.1-2.5 "Об интерфейсе", Алан Купер, Роберт Рейман и Девид Кронин



2.1 Купер уверен, что не пользователей надо подстраивать под логику машины или программного продукта, а, наоборот, логику продукта под мышление пользователей (с. 59);
2.2 Системная модель (с точки зрения разработчиков) или модель реализации (с точки зрения проектировщиков) — подробное в плане реализации представление о работе кода или машины (с. 59-60);
2.3 Пользовательская ментальная модель — представление пользователя о работе машины или программного продукта. Оно может кардинально отличаться от системной модели, но оно не мешает совсем пользователю использовать продукт. Однако знание, как устроен продукт, не помогает понять, как им пользоваться (с. 60);
2.4 Модель представления или проектирования — способ представления, выбранный проектировщиком, функционирования программы пользователю. Она сильно отличается от системной модели.
Чем ближе к пользовательской ментальной модели модель проектирования, тем эффективнее и легче будет работа пользователя с программой.
Таким образом,пользовательский интерфейс должен следовать пользовательской ментальной модели, а не модели реализации.
Целеориентированное взаимодействие отражает пользовательские метальные модели (с. 61-63).
2.5 Пользовательская модель может быть не точной, не очень правдивой, главное — обеспечивать эффективную работу пользователя. Пример: многие не подкованные технически пользователи уверены, что всё происходит в дисплее, если ему объяснить, что это не так, что центральное место — маленькая микросхема в системном блоке, то эта информация не повлияет на качество и эффективность работы пользователя с программой — т.е. эта информация, хоть и более точна, но бессмысленна для пользователя (с. 64).

Далее читайте о том, что большинство ПО привержены модели реализации и примерах данного факта.