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).
  • 0

  • 0

Комментариев нет

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.