MICROSOFT .NET ARCHITECTURE DAY 4 июня 2009 Москва · должны...

MICROSOFT .NET ARCHITECTURE DAY4 июня 2009, Москва

Разработка пользовательского интерфейса — современные подходы

Дмитрий Сатин Андрей Сикорский

HUMAN-CENTERED DESIGN

новый стандарт качества ваших продуктов

Методологии разработки

3

Инструменты разработки

4

Ключевой момент

5

Немного о числах

6

Айсберг Юзабилити

10% - Внешний вид: макет, цвета изображения

30% - Функциональность: меню, кнопки, управление

60% - Цели и задачи пользователя: действия, навигация, объекты и взаимодействие между ними

7

Айсберг Юзабилити

8

Говорим о деньгах?

9

$100,0

$10,0

$1,0

$0,1

Релиз

Разработка

Проектирование

Анализ

Цена исправления ошибок

10

ROI в юзабилити

Оценка уровня ROI воспользовавшихся юзабилити-услугами.

Опрос проводился агентством E-consultancy в 2007 году.

0

5

10

15

20

25

30

35

40

45

50

11

Стоимость юзабилити

Затраты на юзабилити составляют приблизительно 10% от разработки при условии итеративности разработки и использовании всего спектра методов [юзабилити] на всех этапах проекта

12

Методологии разработки

13

MSF: Role Clusters

• Accessibility• Internationalization• Technical Communications• Training• Usability• Graphic Design

14

15

ISO 13407: User Centered Design

ISO 13407: User Centered Design

ISO 13407: User Centered Design

ISO 13407: User Centered Design

ISO 13407: User Centered Design

ISO 13407: User Centered Design

ISO 13407: User Centered Design

ISO 13407: User Centered Design

ПРИНЦИПЫ HCD

Хороший мастер своего дела всегда знает, как люди будут использовать его изделие.

1. Следование принципам HCD

2. Пользователи, задачи, среда

3. Вовлечение пользователей в процесс

4. Критическая важность оценки

5. Итеративность

6. Целостность User Experience

7. Распределение функций

8. Мультидисциплинарность команды

Структура раздела

Следование принципам HCD

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

26

Пользователи, задачи, среда

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

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

27

Вовлечение пользователей в процесс

Необходимо активно вовлекать пользователей.

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

28

Критическая важность оценки

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

29

Итеративность

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

30

Целостность User Experience

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

31

Распределение функций

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

Функции человека, полученные в результате этого распределения, формируют набор пользовательских задач.

32

Мультидисциплинарность команды

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

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

33

ПЛАНИРОВАНИЕ HCD

Забавно как все мои знания о юзабилити летят в окно, когда я начинаю программировать накануне окончания проекта.

1. Участие в жизненном цикле

2. Ответственность

3. Содержание плана

4. Согласование плана

5. Интеграция с планом проекта

6. Время и ресурсы

7. Риски и пересмотр плана

Структура раздела

Участие в жизненном цикле

Необходимо планировать и интегрировать HCD на всех этапах жизненного цикла проекта.

36

Ответственность

Ответственный за планирование проекта должен оценить важность и влияние юзабилити по следующим измерениям:

как связаны юзабилити с назначением и использованием продукта, системы или сервиса;

уровень и тип возможных рисков при возникновении проблем с юзабилити;

особенности среды разработки.

37

Содержание плана

выбрать адекватную глубину проработки этапов HCD;

интегрировать эти работы с другими этапами разработки;

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

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

38

Согласование плана

адекватные вехи для HCD работ, интегрированных в общий процесс разработки;

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

39

Интеграция с планом проекта

План HCD-работ должен быть органичной частью общего плана разработки.

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

Работы в рамках HCD должны начинаться на самом раннем этапе проекта.

40

Время и ресурсы

На этапе планирования проекта необходимо выделить время и ресурсы для работ в рамках HCD.

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

41

Риски и пересмотр плана

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

Разделы плана проекта, касающиеся HCD, должны пересматриваться на протяжении всего жизненного цикла проекта.

42

ЭТАПЫ HCD

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

Общая схема

Понять и специфицировать контекст использования

Специфицировать пользовательские требования

Разработать дизайн-решение

Произвести его оценку

44

КОНТЕКСТ ИСПОЛЬЗОВАНИЯ

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

1. Группы пользователей

2. Задачи пользователей

3. Среда и условия

4. Степень детализации

5. Интеграция с требованиями

Структура раздела

Группы пользователей

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

Необходимо определить ключевые характеристики пользователей.

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

47

Задачи пользователей

Определить целевые задачи пользователей и общие задачи системы.

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

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

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

48

Среда и условия

Необходимо определить технические условия и ограничения, в том числе аппаратное и программное обеспечение и др.

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

49

Степень детализации

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

50

Интеграция с требованиями

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

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

51

ПОЛЬЗОВАТЕЛЬСКИЕ ТРЕБОВАНИЯ

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

1. Общий принцип

2. Влияние на организационные вопросы

3. Описание потребностей пользователей

4. Спецификация требований

5. Конфликты требований и компромиссы

6. Проверка пользовательских требований

Структура раздела

Общий принцип

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

54

Влияние на организационные вопросы

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

55

Описание потребностей пользователей

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

Эти нужды должны быть описаны скорее в терминах –что пользователь пытается достичь, нежели – как он будет это делать.

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

56

Спецификация требований

Предполагаемый контекст использования;

Требования, вытекающие из нужд пользователей и контекста;

Требования стандартов пользовательских интерфейсов;

Измеряемые критерии юзабилити;

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

57

Конфликты требований и компромиссы

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

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

58

Проверка пользовательских требований

Требования описаны так, что их выполнение может быть протестировано;

Требования проверены и утверждены заказчиком;

Требования не содержат нерешенных противоречий;

Требования обновляются при необходимости в течение всего проекта.

59

ПРОЕКТИРОВАНИЕ

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

1. Процесс

2. Принципы проектирования

3. Проектирование взаимодействия

4. Проектирование интерфейсов

5. Степень детализации

6. Улучшения по результатам проверки

7. Коммуникации с командой проекта

8. Презентация результатов

Структура раздела

Процесс

проектирование задач пользователя, взаимодействия с интерфейсом в соответствии с пользовательскими требованиями;

конкретизация ранних концепций;

улучшение дизайна по результатам обратной связи и оценки;

презентация результатов для тех, кто отвечает за разработку.

62

Принципы проектирования

Соответствие задачам пользователя

Самоочевидность

Соответствие ожиданиям пользователя

Обучаемость

Управляемость

Терпимость к ошибкам

Возможности индивидуализации

63

Проектирование взаимодействия

Выявление задач и подзадач пользователя;

Распределение задач между пользователем и продуктом;

Определение интерактивных объектов, необходимых для решения задачи;

Выбор подходящих диалоговых техник;

Проектирование динамики и последовательности взаимодействия;

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

64

Проектирование интерфейсов

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

65

Степень детализации

Уровень детализации и реалистичности прототипов должен определяться решением конкретных задач.

66

Улучшения по результатам проверки

Обратная связь должна быть использована для улучшения и доработки продукта.

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

В плане проекта должно быть предусмотрено время на внесение изменений по результатам обратной связи.

67

Коммуникации с командой проекта

Между ответственным за HCD и остальными членами команды разработки должно быть налажено тесное взаимодействие.

68

Презентация результатов

Спроектированные решения должны сопровождаться описаниями и объяснениями, в особенности там, где необходимо найти компромисс.

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

69

ОЦЕНКА

Если вы никогда не наблюдали в юзабилити лаборатории за тем, как пользователь взаимодействует с продуктом, вы действуете вслепую.

1. Общие принципы

2. Проведение оценки

3. Методы оценки

4. Тестирование с пользователями

5. Долгосрочный мониторинг

Структура раздела

Общие принципы

Оценка является обязательным этапом HCD.

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

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

Проведение оценки

выделение ресурсов

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

планирование оценки

чтобы она была частью плана проекта;

достаточно полную проверку

для получения значимых оценок всей системе;

решение выявленных проблем

анализ и приоритезация выявленых проблем и предложение их решения;

реализацию решений

передача решений так, чтобы команда эффективно использовала их.

73

Методы оценки

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

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

Объем финальных оценок должен определяться степенью рисков, связанных с невыполнением требований.

74

Тестирование с пользователями

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

75

Долгосрочный мониторинг

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

Критерии и измерения для долгосрочного наблюдения должны быть достаточно чувствительными для своевременного выявления сбоев и проблем в системе.

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

76

UX Russia

http://groups.google.com/group/uxrussia

http://twitter.com/uxrussia

Конференция «Сайт-2009» (25–26 июня 2009)

http://www.site-2009.ru

UsabilityLab

http://twitter.com/usabilitylab

http://usabilitylab.ru

События, сообщества и контакты

INFO@USABILITYLAB.RU

Дмитрий Сатин и Андрей Сикорский