Опубликован: 06.05.2014 | Доступ: свободный | Студентов: 2640 / 618 | Длительность: 10:33:00
Лекция 1:

Проектирование, ориентированное на пользователей. Пользовательский опыт

Сценарии и требования, как основы проектирования

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

Рассмотрим три типа сценариев, основанных на персонажах и используемых на различных этапах проектирования, ориентированного на цели.

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

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

Рассмотрим процесс формирования требований к продукту на основе персонажей и сценариев.

Шаг 1: Постановка задачи и определение образа продукта.

Создание надежного основания для процесса проектирования. Постановка задачи определяет цель самого проектирования, кратко отражает ситуацию, требующую изменения, как с точки зрения персонажей, так и с точки зрения бизнеса, который создает для этих персонажей продукт. Определение образа продукта ставит на первое место потребности пользователей, показывает, как благодаря удовлетворению этих потребностей достигаются бизнес-цели. Сводка целей пользователей и испытываемых ими сложностей в виде постановки задачи и определения образа продукта помогает достичь взаимопонимания внутри команды и привлечь ее внимание к приоритетам предстоящего проектирования [ 1.1 ] .

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

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

Шаг 3: Выявление ожиданий персонажей.

Ожидания пользователей являются важным источником требований. Для каждого ключевого или второстепенного персонажа необходимо выявить:

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

Шаг 4: Разработка контекстных сценариев.

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

Контекстные сценарии устанавливают основные точки соприкосновения каждого ключевого и второстепенного персонажа с проектируемой системой (возможно, и с другими персонажами посредством системы) в течение дня или иного осмысленного промежутка времени.

Шаг 5: Выявление требований.

На основе анализа контекстного сценария можно получить потребности персонажей – требования, которые могут включать в себя объекты, действия и контексты. Рассмотрим группы требований:

  • Информационные требования отражают потребности персонажей в информации, которую должна предоставлять система. Можно считать информационные требования объектами и прилагательными, связанными с этими объектами.
  • Функциональные требования – это операции или действия, которые должны выполняться с объектами системы и которые, как правило, реализуются в виде интерфейсных элементов управления. Функциональные требования можно считать действиями продукта. Кроме того, функциональные требования определяют места или контейнеры, с помощью которых объекты или данные отображаются пользователю.
  • Требования бизнеса могут включать в себя сроки разработки, стандарты, структуры ценообразования и бизнес-модели.
  • Требования бренда и опыта пользователей отражают характеристики опыта, который в идеальном случае пользователи и клиенты связывали бы с вашим продуктом, компанией или организацией.
  • Технические требования могут включать в себя ограничения по весу, размеру, форм-фактору, свойствам дисплея, энергопотреблению, а также по выбору программной платформы.
  • Требования покупателей и партнеров могут включать в себя простоту установки, обслуживания, настройки, стоимость поддержки лицензионные соглашения.

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

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