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

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

MICROSOFT .NET ARCHITECTURE DAY

4 июня 2009, Москва
новый стандарт качества ваших продуктов

HUMAN-CENTERED DESIGN
Методологии разработки

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

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

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

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

10% - Внешний вид: макет, цвета

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

60% - Цели и задачи

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

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

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

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

Анализ $0,1

Проектирование $1,0

Разработка $10,0

Релиз $100,0

10
ROI в юзабилити
50
45
40
35

 Оценка уровня ROI 30

воспользовавшихся 25

юзабилити-услугами. 20
15
 Опрос проводился агентством
10
E-consultancy в 2007 году.
5
0

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