Методики анализа

1.

1. Проектирование пользовательского
интерфейса
2. Исследования пользовательского опыта
3. Персонажи, как модели пользователей
4. Сценарии и требования, как основы
проектирования

2.

1. Проектирование
пользовательского
интерфейса
2

3.

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

4.

Процесс проектирования, ориентированного
на цели
Исследования
Моделирование
Выработка
требований
Сопровождение
разработки
Детализация
поведения,
формы и
содержания
Определение
общей
инфраструктуры
интерфейса
4

5.

Этап 1. Исследования
Исследования
• наблюдение
• интервью
• помогают классифицировать возможные
варианты использования продукта
набор шаблонов • выявить цели и мотивы применения
или моделей
продукта.
поведения
5

6.

Этап 2. Моделирование
• информационные потоки
• диаграммы рабочих процессов.
Моделирование
Модели
пользователя –
«персонажи»
• устойчивые комбинации моделей поведения, склонностей, взглядов,
целей, мотивов, обнаруженных на этапе исследований.
• синтез персонажей,
• дифференциация персонажей
• ранжирование персонажей
6

7.

Модели пользователя – «персонажи»
синтез
персонажей
дифференциация
персонажей,
ранжирование
персонажей
•выявление целей и связывание возможных
моделей поведения с персонажами таким
образом, чтобы все цели были охвачены и не
было повторений;
•сопоставление целей персонажей и создание
иерархии приоритетов, основанной на том,
насколько широко цели того или иного
персонажа покрывают цели других
персонажей;
•присвоение персонажам типов в зависимости
от степени влияния персонажа на
окончательную форму и поведение продукта.
7

8.

Этап 3. Выработка требований
Выработка
требований
• сценарные методы проектирования,
направленные на достижение целей и
удовлетворение потребностей
конкретных персонажей,
• пользовательские требования
• требования бизнеса
сбалансированный
перечень
• технические ограничения
требований
8

9.

Этап 4. Определение общей инфраструктуры
интерфейса
• на основе контекстных сценариев с применением общих
принципов и шаблонов проектирования.
• Каждый шаблон проектирования задает решение
определенного типа уже проанализированных проблем.
общая
инфраструктура • Шаблоны проектирования выстраиваются в иерархию и
эволюционируют с появлением новых контекстов
интерфейса
устоявшаяся
концепция
проекта
• логическая и примерная формальная структура для
последующей детализации.
• Несколько вариантов визуальной инфраструктуры
9

10.

Этап 5. Детализация поведения, формы и
содержания
Детализация
поведения,
формы и содержания
проектная
документация
• последовательные итерации более узко сфокусированных
сценариев.
• Такой подход часто представляет собой баланс проектирования
«сверху вниз» (опирающегося на шаблоны) и проектирования «снизу
вверх» (опирающегося на принципы).
• спецификация формы и поведения в бумажном или интерактивном
формате
• Проектировщики взаимодействия фокусируются на согласованности
задач
• Графические дизайнеры определяют наборы начертаний и размеров
шрифтов, пиктограмм и других визуальных элементов
10

11.

Этап 6. Сопровождение разработки
• Реакция на все препятствия и
технические осложнения на
Сопровождение
пути разработчиков
разработки
корректировка
проектных
решений
11

12.

2. Исследования
пользовательского
опыта
12

13.

Пользовательский опыт (User Experience)
показывает, насколько удобно чувствует себя
пользователь при использовании того или иного
интерфейса.
Можно рассматривать пользовательский опыт,
как комплексный подход к разработке системы
взаимодействий между человеком и продуктом
13

14.

Модели продукта
модель реализации
описывает подробности реализации продукта в
коде
ментальная модель
упрощенное
представление,
описывающее
взаимодействие с системой
модель представления (интерфейс)
способ
предъявления
пользователю
функционирования программы
14

15.

Модели продукта
Модель
реализации
Модели представления
Отражает
технологию
хуже
лучше
Ментальная
модель
Отражает
видение
программы
пользователем
15

16.

Группы пользователей
Эксперты
Начинающие
необходимо
проектировать
наилучшее
взаимодействие
Вечные середняки
16

17.

Группы пользователей
Начинающие
• обычно требуется быстрый и
целенаправленный
инструктаж, который не
будет фиксированной частью
интерфейса и исчезнет, как
только пропадет в нем
необходимость,
• обзорное «Знакомство с
программой» (guided tour).
17

18.

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

19.

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

20.

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

21.

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

22.

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

23.

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

24.

Интервьюирование экспертов
в предметной области (ЭПО)
Имеющиеся нормы и
зарекомендовавшие себя на практике
подходы, действующих в данной
предметной области.
планирование исследований
пользовательской аудитории.
24

25.

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

26.

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

27.

Наблюдение
более полные и точные
данные о ситуации,
которую стремится понять
проектировщик, и
поведении пользователя в
тех или иных условиях
27

28.

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

29.

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

30.

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

31.

Аудит продукта/прототипа
и конкурирующих решений
представление о состоянии дел в
предметной области и базу для подготовки
вопросов к интервью
сильные и слабые стороны доступных
пользователю продуктов
Текущий объем функциональности
продукта.
31

32.

3. Персонажи, как
модели пользователей
32

33.

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

34.

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

35.

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

36.

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

37.

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

38.

Процесс разработки персонажа
Выявление
поведенческих
переменных
Сопоставление
респондентов с
поведенческими
переменными
Выявление
значимых
шаблонов
поведения
Расширение
описания
атрибутов и
поведений
Проверка полноты
и выявление
избыточности
Синтез
характеристик и
соответствующих
им целей
Назначение
персонажам типов
38

39.

Шаг 1. Выявление поведенческих
переменных
определяют
самостоятельные
аспекты
наблюдавшихся
вариантов
поведения
Типы:
Деятельность: чем занят пользователь, частота и объем.
Взгляды: каким образом пользователь думает о предметной области
и технологии продукта.
Наклонности: каковы образование и подготовка пользователя, его
способность обучаться.
Мотивация: каким образом пользователь вовлечен в предметную
область продукта.
Навыки: умения пользователя, связанные с предметной областью
продукта и используемой технологией.
39

40.

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

41.

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

42.

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

43.

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

44.

Шаг 6. Расширение описания атрибутов и
поведений
Повествование от
способом
третьего
представить
лица является
взгляды,
ярким
потребности
и
проблемы персонажа другим участникам процесса
разработки.
Типичное описание персонажа – это синтез наиболее
важных деталей, полученных в ходе исследований и
относящихся к этому персонажу.
44

45.

Шаг 7. Назначение
персонажам типов
ключевой
покупатель
второстепенный
обслуживаемый
дополнительный
отвергаемый
Разработка приложений для смартфонов на ОС Android. Лекция 1.
Проектирование, ориентированное на пользователей. пользовательский опыт
45

46.

Шаг 7. Назначение персонажам типов
ключевой
задает основную цель в проектировании интерфейса,
выбирается
методом
исключения:
цели
каждого
персонажа рассматриваются в сравнении с целями
остальных. Если не очевидно, какой из персонажей
является ключевым, это может означать одно из двух:
или
продукту
каждый
ключевого
из
требуется
которых
персонажа
несколько
предназначен
(так
часто
интерфейсов,
для
своего
бывает
в
корпоративных и технических продуктах), или же
объем его функциональности слишком широк.
46

47.

Шаг 7. Назначение
персонажам типов
второстепенный
дополнительный
в основном оказывается
доволен интерфейсом
ключевого персонажа, но
имеет дополнительные
потребности, которые
можно включить в
продукт, не нарушая его
способности служить
ключевому персонажу
пользовательский персонаж,
не являющийся ни
ключевыми, ни
второстепенным.
Их нужды обычно полностью
представлены сочетанием
нужд ключевого и
второстепенных персонажей
и удовлетворяются одним из
ключевых интерфейсов
47

48.

Шаг 7. Назначение
персонажам типов
покупатель
персонаж, отражающий потребности покупателей, а не
конечных
пользователей.
Обычно
персонажи
покупателей используются в качестве второстепенных
персонажей.
Однако
в
некоторых
корпоративных
средах кто-то из таких персонажей может оказаться
ключевым, если ему предназначается собственный
административный интерфейс.
48

49.

Шаг 7. Назначение
персонажам типов
обслуживаемый
не является пользователем продукта, однако его
непосредственно затрагивает применение продукта.
Обслуживаемые персонажи – это способ отслеживать
социальные
порядка,
и
физические
оказываемые
воздействия
продуктом.
Эти
второго
персонажи
используются так же, как второстепенные персонажи.
49

50.

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

51.

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

52.

Виды деятельности, используемые
для получения искомых проектных решений
создание сценариев, как средства описания
идеального для пользователя взаимодействия;
использование этих сценариев для выработки
требований;
определение
на
основе
этих
требований
инфраструктуры взаимодействия для продукта и
пошаговое
наполнение
этой
структуры
все
более детальными решениями
52

53.

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

54.

Процесс формирования требований
к продукту на основе персонажей и
сценариев
Постановка
задачи и
определение
образа продукта
Мозговой штурм
Выявление
ожиданий
персонажей
Выявление
требований
Разработка
контекстных
сценариев
54

55.

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

56.

Шаг 1: Постановка задачи и
определение образа продукта
Определение образа продукта ставит на первое место
потребности пользователей
Сводка
целей
пользователей
и
испытываемых
ими
сложностей в виде постановки задачи и определения образа
продукта
помогает
команды
и
достичь
привлечь
ее
взаимопонимания
внимание
к
внутри
приоритетам
предстоящего проектирования
56

57.

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

58.

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

59.

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

60.

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

61.

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

62.

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

63.

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

64.

Шаг 5: Выявление требований
Информационные
требования
Функциональные
требования
Требования
бизнеса
Требования
бренда и опыта
пользователей
Технические
требования ограничения
Требования
покупателей и
партнеров
64

65.

Шаг 5: Выявление требований
Информационные
требования
отражают потребности персонажей
в информации, которую должна
предоставлять система.
Функциональные
требования
операции или действия, которые
должны выполняться с объектами
системы
реализуются в виде интерфейсных
элементов управления
действия продукта
Объекты и прилагательные,
связанными с этими объектами.
места или контейнеры, с помощью
которых объекты или данные
отображаются пользователю.
65

66.

Шаг 5: Выявление требований
Требования бизнеса
Требования бренда
и опыта
пользователей
сроки разработки
стандарты
структуры
ценообразования
характеристики опыта,
который пользователи и
клиенты связывали бы с
вашим продуктом,
компанией или
организацией.
бизнес-модели
66

67.

Шаг 5: Выявление требований
Технические
требования ограничения
Требования
покупателей и
партнеров
по весу,
простота установки,
размеру,
форм-фактору,
свойствам дисплея,
энергопотреблению,
выбору программной платформы.
Простота обслуживания и
настройки,
стоимость поддержки
лицензионных соглашений
67

68.

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

69.

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