SlideShare une entreprise Scribd logo
1  sur  90
Télécharger pour lire hors ligne
Human-Centered Design
Глеб Уваров

1
Знакомство
ГЛЕБ УВАРОВ


Разработчик программного обеспечения в
Sam Solutions



Инженер-системотехник (БГУИР)



Интересуюсь вопросами User Experience,
Usability, Human-Centered Design
g.uvarov
g.uvarov@gmail.com

2
Работа над ошибками
Человек, по настоящему мыслящий, черпает из своих ошибок не
меньше познания, чем из своих успехов
Джон Дьюи

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

4
Итоги: Usability
 Широкий набор функций в продукте усложняет его с
точки зрения пользователя.
Бизнес не знает свою целевую аудиторию

Страх непринятия рынком

 Usability – ключ к созданию востребованных и
простых в использовании продуктов.

5
Итоги: Мифы
 Usability – не (только) визуальный дизайн
Это:
• Пользователь, его потребности, контекст
• Цели бизнеса
• Проектирование взаимодействия, информационная
архитектура
• Навигация

 Usability – не один шаг в процессе разработки
Это процесс:
• Непрерывного изучения пользователей
• Создания и тестирования прототипов раньше разработки
• Обязательной оценки на всех этапах проекта

6
Итоги: Мифы
 Usability – не UX

Pleasurable

Usability

UX

Usable, Useful
Functional

7
Итоги: Значимость Usability
 Для разработчика
 Для тестировщика
 Для аналитика
 Для менеджера проекта

8
План
1. Human-Centered Design
2. Контекст использования

3. Пользовательские требования
4. Проектирование

5. Оценка
6. Этапы развития Юзабилити в компании
9
Human-Centered Design
10
HCD – что это?
 HCD – методология, которая ставит человека
в центр проектирования
• Потребности пользователя
• Цели бизнеса (+ stakeholders)

 Цель HCD – оптимизировать Usability
системы, продукта или услуги
 Usability – это результат применения НCD

11
Human-Centered Design (ISO 9241-210)

1

2

4

3
12
Принципы HCD
 Fail Fast
 Пользователи. Задачи. Среда.
 Вовлекать пользователей
 Критическая важность оценки
 Мультидисциплинарность команды

13
Контекст использования
14
Общие принципы
 Определить
•
•
•
•

потребности
цели
ценности
ограничения

 Описать физические и социальные условия
 Определить технические требования
 Определить характеристики задач, на которые влияет
юзабилити
15
Наблюдение
 Наблюдать за пользователями
•

Что они делают?

•

Как они делают?

•

Чего они не делают?

•

Контекст

•

Понять их больные места

 О чем помнить:
• Обратить внимания на те задачи, которые пользователи
выполняют разными путями

16
Интервью
 Сбор информации о том, что пользователи думают о
существующем продукте и каково их мнение об
определенной функции.
 Культурные особенности, ожидания
 О чем помнить:
•
•
•
•
•

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

17
Персона
Люди. Как они работают. Как мыслят. Как живут.
18
Что такое Персоны?

 Персона – гипотетический
архетип реального
пользователя.
Чем должна обладать Персона?


Тип



Уровень подготовки



Имя, возраст



Ожидания



Фотография



Потребности



Место проживания
(география и язык)



Цели



Место работы и
должность



Биография

20
Основные принципы
 Проектировать для одной (ключевой)
персоны

 Персона должна быть конкретной
 Персона должны быть воображаемой

 Включить описание персон в
документацию
21
Почему Персоны важны?
 Закрывают споры о функциях
 Позволяют ранжировать функции
 Позволяют принимать взвешенные и
осмысленные решения в процессе
проектирования

22
Подбор Персон

23
Ключевая Персона
Persona 4: Alumni
“I keep an eye on upcoming events and research my old friends at the
University are doing. News feeds are important as I’m a busy man”

Dr Alan Mackintosh, GP, 40
Web usage

Access to other information platforms
Use of your website
Strength of relationship with you

Alan is a GP, living in Hertford, Herts, with his wife Alana and
their two small children; Isla 9, and Hamish 7. Alana is
pregnant, so there will soon be yet another addition to the
family. After Alan graduated his first job was in Scotland,
after which he moved to Cambridge for his GP training. His
main interests are art history and photography, but he also
enjoys bird watching, playing golf, art galleries, theatre, music
and the pub - Alan is a big fan of real ale. He is not politically
active, but he supports the coalition government.
He accesses the internet both from his PC at work and at
home using his laptop and his new iPad. Websites he visits are
Flickr, the Independent, Amazon, eBay, Waitrose, Expedia,
Wikipedia and Art. His parents live in Edinburgh so he is still
in touch with the area and the local community. He has an
interest in distance learning.

Key tasks
•
Alan is a busy man with little free time between work and
family life. He subscribes to updates from alumni relations
and the events section of the site to keep up to date with
new information
•
He keeps an eye on upcoming events and lectures, trying to
find time to attend one or two a year
•
He finds and keeps in touch with other alumni though the
website and especially enjoys reunions when they are
arranged
•
Research is another important area , keeping him up to
date in his own area of expertise. Some old friends from his
student days are now work at the University, and he is
always interested in reading work they publish

•
•
•
•
•

You would like to promote
Alumni benefits and networking events/opportunities
Upcoming events and seminars particularly alumni events
and those related to medicine
New research that’s being carried out
News feeds, so that Alan can subscribe
How, when and where alumni can donate to the University

24
Пользовательские требования
25
26
Общие принципы


Описывать действия пользователя, а не системы



Согласованность требований с потребностями пользователя и
целями бизнеса



Измеряемость, непротиворечивость, достаточность



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

Контекст
Стандарты пользовательских интерфейсов
Измеряемые критерии юзабилити



Разрешить и задокументировать конфликты



Согласование с заказчиком

27
Сценарий
28
Что такое сценарий?
 Сценарий – это сжатое
описание способов
применения программного
продукта Персоной для
достижения цели.
Сценарии
 Это всегда реалистичные описания
жизненных ситуаций, в которых
пользователю может быть полезен
продукт
 Направляют разработку прототипов

 Используются для тестирования

30
Виды сценариев

 Повседневные

 Обязательные
 Исключительные ситуации

31
Литература

Karl E. Wiegers
Software Requirements, 2nd
edition

IIBA
Business Analysis Body of
Knowledge

32
Проектирование интерфейсов
Проблемы происходят не от сложности создания хороших вещей,
а от готовности принимать некачественные вещи, как неизбежное
33
Прототипы: для чего?
 Ранняя оценка
 Показать заказчику
 Контакт с разработчиками

 Тестирование
О чем помнить
 Опираемся на Персоны и Сценарии
 Оценка
• Быстро разработали – быстро получили обратную связь

 Стандарты
•
•
•
•

Платформы
Отраслевые
Корпоративные
UI Patterns

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

It depends 

35
Детализация

Прототипы: детализация

HTML
Wireframes
Бумажные
прототипы
Storyboards

Время
36
37
Storyboarding
 Акцент на том, как продукт решает задачу
 Нет привязки к конкретному интерфейсу

 Вовлечение всех заинтересованных лиц

38
Wireframe
 Компоновка элементов
 Назначение:
•

Какие элементы (контролы)

•

Какая информация

 О чем помнить:
•

Не показывают
интерактивность/flow

•

Бывают разной степени
детализации

39
Макеты для спецификаций


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



Назначение:
•



Для разработки

О чем помнить:
•

Описать:
•
•

Источники данных

•

Действия

•

•
•

Все состояния

Валидации

Выслушать разработчиков
Не показывать заказчикам и пользователям

40
Инструменты


Карандаш, бумага 



Balsamiq Mockups (www.balsamiq.com/products/mockups)



Axure (www.axure.com)



SketchFlow (www.microsoft.com/expression)



HTML,CSS,JS

41
Литература

Bill Buxton
Sketching User Experiences: Getting
the Design Right and the Right Design

Carolyn Snyder
Paper Prototyping: The Fast and Easy
Way to Design and Refine User
Interfaces
42
Оценка
Мы не разрабатываем ничего того, что не будет тестироваться.
Мы не тестируем то, что не будет использоваться.
43
Общие принципы
 Обязательный этап
 Чем раньше, тем лучше

 Непрерывный процесс
 Использовать результаты оценки в
последующих итерациях
 Выделять ресурсы на тестирование и
исправление ошибок на всех этапах
44
Юзабилити-тестирование
45
Этапы
1.

Найти репрезентативных пользователей (Персоны)
•

5-10 человек

2.

Выявить критические задачи (Сценарии)

3.

Создать протокол юзабилити-тестирования

4.

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

5.

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

6.

Внести исправления в дизайн

7.

Повторить со следующей группой
Принципы
 Чем раньше, тем лучше:
•
•
•
•
•
•

Начинать с бумажных прототипов
Степень детализации
На всех этапах
Итеративно
На ранних этапах – качественная оценка
На поздних этапах - Метрики

 Модератор
 Один и тот же набор задач
 Не более 1 часа

47
Сколько пользователей вовлекать?

48
Юзабилити-тестирование (Схема)
Пользователь

Помощники
модератора

Модератор
Сценарии


Плохая задача
•



Хорошая задача
•



У вас есть 200 книг по научной фантастике, сейчас они лежат в ящиках в
вашей гостиной. Как бы вы их организовали?

Плохая задача
•



Найти и купить книжную полку

Заказать межбиблиотечный абонемент

Хорошая задача
•

Как бы вы получили книги, которые недоступны в нашей библиотеке?

50
Как стоит делать


Придерживаться графика или сценария



Пройти этот сценарий заранее (знать что я это сам могу сделать)



Дать стимул (подарок, сладости)



Поощрять пользователей думать вслух (Think aloud)



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



Не вмешиваться в процесс



Поговорить с пользователем после тестирования (посмотреть на запись
тестирования, дать ему прокомментировать свои действия)



Пересмотреть записи и заметки и сделать выводы как можно раньше после
тестирования

51
Как НЕ стоит делать
 Допускать нерепрезентативных пользователей к
тестированию
 Учить пользователя
 Помогать тестируемому при малейших затруднениях
 Вмешиваться в процесс

 Сходить с ума если пользователь не может сделать
то, что вы считаете очевидным 

52
Метрики
Если мы не можем что-то измерить, то как мы сможем
это улучшить?
Метрики – Продуктивность.
Эффективность.
 Выполнимость задачи
•

Да/Нет

•

Градации (полностью, частично, с помощью или без)

 Время на задачу
•

Для выполненных задач

 Ошибки
 Эффективность

54
Метрики: Дефекты
- все, что препятствует выполнению задачи
- что не относится к выполнению задачи

- пользователь не увидел то, что ожидал
увидеть
- выполнение неверного действия
- неправильная интерпретация чего-либо
55
10 юзабилити эвристик
Якоб Нильсен
56
1. Видимость состояния системы
(обратная связь)
 Система должна всегда информировать
пользователя о своем состоянии с помощью
соответствующих средств, в разумное время
2. Соответствие системы
реальному миру (метафоры)
 Система должна разговаривать с пользователем на
его языке и использовать понятия, образы и концепции,
которые уже знакомы пользователю по реальному
миру.

58
59
3. Свобода действий и контроль
над ситуацией (навигация)
 Пользователь может совершить действие по
ошибке. У него должен быть «аварийный
выход» из этой ситуации, четко обозначенный
в программе

60
61
4. Последовательность и следование
стандартам (единообразие)

 Пользователи не должны гадать, означают ли
различные слова, ситуации, действия,
объекты одно и то же

62
63
5. Предупреждение ошибок
 Дизайн, который предупреждает
возникновение проблем, лучше, чем самое
хорошее сообщение об ошибке

64
65
6. Узнавание вместо воспоминания
(память)
 Делайте все объекты, функции, действия видимыми и
легко доступными пользователю. Минимизируйте
запоминание – пользователь не должен постоянно
стараться удержать в памяти информацию из одной
части программы, чтобы применить ее в другой

66
7. Гибкость и эффективность
использования
 Функции, которые ускоряют работу, нужно оформлять
так, чтобы они не мешали начинающим, но были
легко доступны продвинутым пользователям

67
8. Эстетичный и минималистичный
дизайн
 Страницы, формы и диалоги не должны содержать
лишней и нерелевантной информации. Каждый
дополнительный элемент конкурирует с важным
содержимым и снижает его заметность

68
69
9. Восстановление после ошибок
 Хорошие сообщения об ошибках должны
объяснять на понятном языке, в чем состоит
проблема и как ее исправить

70
71
72
10. Помощь и документация
 Вся документация должна быть легко обнаружима,
сосредоточенной на задачах пользователя и
описывать конкретные шаги. Однако лучше, если
система может использоваться без документации

73
74
75
Human-Centered Design - резюме


Исследование раньше прототипа
•



Прототипы раньше разработки
•
•
•



Это очень дешево
Проводим проверку
Вовлекаем всю команду

Тестирование прототипов до разработки
•



Использовать разные техники исследований

Дешевые исправления

Оценка
•
•
•
•

Обязательная
Непрерывная
Итеративная
Долгосрочная

76
8 этапов развития юзабилити в
компании
Якоб Нильсен
77
Этап 1: Враждебность к юзабилити
 Хороший пользователь — мертвый
пользователь

 Цель – писать программы, и чтобы они
запускались на компьютере
Этап 2: Юзабилити,
поддерживаемая разработчиками
 Задумались об удобстве
использования

 Интуитивный подход
 Удобство использования с точки
зрения разработчиков

79
Этап 3: Юзабилити
децентрализованных групп
 Произвольные инициативные
группы

 Юзабилити-процессы не
систематизированы
 Нет выделенного бюджета

80
Этап 4: Выделенный бюджет под
юзабилити
 Есть выделенный бюджет
 Юзабилити – волшебство

 Специалисты
децентрализованы
 Юзабилити-тестирование
проводится слишком
поздно
81
Этап 5: Управляемая юзабилити
 Выделенный отдел юзабилити
 Архивы исследований
 Юзабилити-менеджер

82
Этап 6: Систематический
юзабилити-процесс
 Итеративные юзабилитипроцессы

 Тестирование на каждом
этапе цикла разработки
 Ранние исследования

83
Этап 7: Интегрированный HumanCentered Design
 Численные метрики
юзабилити
 Использование данных
юзабилити для
определения того, ЧТО
следует производить

 Построение продукта «от
потребностей»
84
Этап 8: Компания,
ориентированная на пользователей
 Полная интеграция User
Experience и HumanCentered Design на все
сферы взаимодействия
клиента и компании,
стратегию и бизнеспроцессы

85
Успешных вам
продуктов!
86
Спасибо за внимание!
Вопросы?

Глеб Уваров

g.uvarov
g.uvarov@gmail.com
87
Полезные книги

Donald A. Norman
The Design of Everyday Things

Jacob Nielsen, Hoa Loranger
Prioritizing Web Usability

Jesse James Garrett
The Elements of User
Experience

88
Полезные книги

Дж. Гарретт
Веб-дизайн: Элементы
опыта взаимодействия

Алан Купер
Об Интерфейсе. Основы
проектирования
взаимодействия

Алан Купер
Психбольница в руках
пациентов

89
Полезные книги

Стив Круг
Веб-дизайн или «не
заставляйте меня думать!».

Билл Скотт, Тереза Нейл
Проектирование вебинтерфейсов

Луис Розенфельд, Питер
Морвиль
Информационная
архитектура в интернете
90

Contenu connexe

Similaire à Human Centered Design

Usability lecture sam solutions by gleb uvarov part 2
Usability lecture sam solutions by gleb uvarov part 2Usability lecture sam solutions by gleb uvarov part 2
Usability lecture sam solutions by gleb uvarov part 2Anastasia Schebrova
 
5 alina petrenko - key requirements elicitation during the first contact wi...
5   alina petrenko - key requirements elicitation during the first contact wi...5   alina petrenko - key requirements elicitation during the first contact wi...
5 alina petrenko - key requirements elicitation during the first contact wi...Ievgenii Katsan
 
Практические аспекты разработки ПО #1
Практические аспекты разработки ПО #1Практические аспекты разработки ПО #1
Практические аспекты разработки ПО #1Denis Umnov
 
Работа с требованиями в Agile
Работа с требованиями в AgileРабота с требованиями в Agile
Работа с требованиями в AgileISsoft
 
User eXperience design - как построить сайт для пользователей, а не для себя
User eXperience design - как построить сайт для пользователей, а не для себяUser eXperience design - как построить сайт для пользователей, а не для себя
User eXperience design - как построить сайт для пользователей, а не для себяAndrew Yaroshenko
 
Проводник по джунглям user experience
Проводник по джунглям user experienceПроводник по джунглям user experience
Проводник по джунглям user experiencetabtabus
 
Всё юзабилити за час
Всё юзабилити за часВсё юзабилити за час
Всё юзабилити за часDigital Guru Club
 
исследование пользователей электронных сми
исследование пользователей электронных смиисследование пользователей электронных сми
исследование пользователей электронных смиEugene Kulakov
 
Работа с требованиями в Agile - Part 3
Работа с требованиями в Agile - Part 3Работа с требованиями в Agile - Part 3
Работа с требованиями в Agile - Part 3ISsoft
 
Продукт с нуля
Продукт с нуляПродукт с нуля
Продукт с нуляITCP Community
 
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...Yury Vetrov
 
Что делать или почему никто не виноват
Что делать или почему никто не виноватЧто делать или почему никто не виноват
Что делать или почему никто не виноватAstra Media Group, Russia
 
How to study your audience? End user research
How to study your audience? End user researchHow to study your audience? End user research
How to study your audience? End user researchEugene Kulakov
 
Низкомолекулярное проектирование: структурированные данные и UX
Низкомолекулярное проектирование: структурированные данные и UXНизкомолекулярное проектирование: структурированные данные и UX
Низкомолекулярное проектирование: структурированные данные и UXLara Simonova
 
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...Dakiry
 

Similaire à Human Centered Design (20)

Usability lecture sam solutions by gleb uvarov part 2
Usability lecture sam solutions by gleb uvarov part 2Usability lecture sam solutions by gleb uvarov part 2
Usability lecture sam solutions by gleb uvarov part 2
 
5 alina petrenko - key requirements elicitation during the first contact wi...
5   alina petrenko - key requirements elicitation during the first contact wi...5   alina petrenko - key requirements elicitation during the first contact wi...
5 alina petrenko - key requirements elicitation during the first contact wi...
 
Практические аспекты разработки ПО #1
Практические аспекты разработки ПО #1Практические аспекты разработки ПО #1
Практические аспекты разработки ПО #1
 
Работа с требованиями в Agile
Работа с требованиями в AgileРабота с требованиями в Agile
Работа с требованиями в Agile
 
User eXperience design
User eXperience designUser eXperience design
User eXperience design
 
User eXperience design - как построить сайт для пользователей, а не для себя
User eXperience design - как построить сайт для пользователей, а не для себяUser eXperience design - как построить сайт для пользователей, а не для себя
User eXperience design - как построить сайт для пользователей, а не для себя
 
Проводник по джунглям user experience
Проводник по джунглям user experienceПроводник по джунглям user experience
Проводник по джунглям user experience
 
Всё юзабилити за час
Всё юзабилити за часВсё юзабилити за час
Всё юзабилити за час
 
Launched startup
Launched startupLaunched startup
Launched startup
 
исследование пользователей электронных сми
исследование пользователей электронных смиисследование пользователей электронных сми
исследование пользователей электронных сми
 
Работа с требованиями в Agile - Part 3
Работа с требованиями в Agile - Part 3Работа с требованиями в Agile - Part 3
Работа с требованиями в Agile - Part 3
 
Продукт с нуля
Продукт с нуляПродукт с нуля
Продукт с нуля
 
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...
 
Что делать или почему никто не виноват
Что делать или почему никто не виноватЧто делать или почему никто не виноват
Что делать или почему никто не виноват
 
Presentacion Ruso
Presentacion RusoPresentacion Ruso
Presentacion Ruso
 
Presentacion Ruso
Presentacion RusoPresentacion Ruso
Presentacion Ruso
 
User Story Canvas
User Story CanvasUser Story Canvas
User Story Canvas
 
How to study your audience? End user research
How to study your audience? End user researchHow to study your audience? End user research
How to study your audience? End user research
 
Низкомолекулярное проектирование: структурированные данные и UX
Низкомолекулярное проектирование: структурированные данные и UXНизкомолекулярное проектирование: структурированные данные и UX
Низкомолекулярное проектирование: структурированные данные и UX
 
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
 

Human Centered Design

  • 2. Знакомство ГЛЕБ УВАРОВ  Разработчик программного обеспечения в Sam Solutions  Инженер-системотехник (БГУИР)  Интересуюсь вопросами User Experience, Usability, Human-Centered Design g.uvarov g.uvarov@gmail.com 2
  • 3. Работа над ошибками Человек, по настоящему мыслящий, черпает из своих ошибок не меньше познания, чем из своих успехов Джон Дьюи 3
  • 4. Итоги  Технологии развиты настолько, чтобы покрыть нужды целевой аудитории.  Большинство существующих решений не является простыми в использовании.  Причина сложности продуктов – в отличии целей тех, кто создает продукты, и тех, кто их использует. 4
  • 5. Итоги: Usability  Широкий набор функций в продукте усложняет его с точки зрения пользователя. Бизнес не знает свою целевую аудиторию Страх непринятия рынком  Usability – ключ к созданию востребованных и простых в использовании продуктов. 5
  • 6. Итоги: Мифы  Usability – не (только) визуальный дизайн Это: • Пользователь, его потребности, контекст • Цели бизнеса • Проектирование взаимодействия, информационная архитектура • Навигация  Usability – не один шаг в процессе разработки Это процесс: • Непрерывного изучения пользователей • Создания и тестирования прототипов раньше разработки • Обязательной оценки на всех этапах проекта 6
  • 7. Итоги: Мифы  Usability – не UX Pleasurable Usability UX Usable, Useful Functional 7
  • 8. Итоги: Значимость Usability  Для разработчика  Для тестировщика  Для аналитика  Для менеджера проекта 8
  • 9. План 1. Human-Centered Design 2. Контекст использования 3. Пользовательские требования 4. Проектирование 5. Оценка 6. Этапы развития Юзабилити в компании 9
  • 11. HCD – что это?  HCD – методология, которая ставит человека в центр проектирования • Потребности пользователя • Цели бизнеса (+ stakeholders)  Цель HCD – оптимизировать Usability системы, продукта или услуги  Usability – это результат применения НCD 11
  • 12. Human-Centered Design (ISO 9241-210) 1 2 4 3 12
  • 13. Принципы HCD  Fail Fast  Пользователи. Задачи. Среда.  Вовлекать пользователей  Критическая важность оценки  Мультидисциплинарность команды 13
  • 15. Общие принципы  Определить • • • • потребности цели ценности ограничения  Описать физические и социальные условия  Определить технические требования  Определить характеристики задач, на которые влияет юзабилити 15
  • 16. Наблюдение  Наблюдать за пользователями • Что они делают? • Как они делают? • Чего они не делают? • Контекст • Понять их больные места  О чем помнить: • Обратить внимания на те задачи, которые пользователи выполняют разными путями 16
  • 17. Интервью  Сбор информации о том, что пользователи думают о существующем продукте и каково их мнение об определенной функции.  Культурные особенности, ожидания  О чем помнить: • • • • • интервью должно быть коротким, разные техники опроса, не выражать свое собственное мнение, делать заметки пользователи часто говорят не то, что делают 17
  • 18. Персона Люди. Как они работают. Как мыслят. Как живут. 18
  • 19. Что такое Персоны?  Персона – гипотетический архетип реального пользователя.
  • 20. Чем должна обладать Персона?  Тип  Уровень подготовки  Имя, возраст  Ожидания  Фотография  Потребности  Место проживания (география и язык)  Цели  Место работы и должность  Биография 20
  • 21. Основные принципы  Проектировать для одной (ключевой) персоны  Персона должна быть конкретной  Персона должны быть воображаемой  Включить описание персон в документацию 21
  • 22. Почему Персоны важны?  Закрывают споры о функциях  Позволяют ранжировать функции  Позволяют принимать взвешенные и осмысленные решения в процессе проектирования 22
  • 24. Ключевая Персона Persona 4: Alumni “I keep an eye on upcoming events and research my old friends at the University are doing. News feeds are important as I’m a busy man” Dr Alan Mackintosh, GP, 40 Web usage Access to other information platforms Use of your website Strength of relationship with you Alan is a GP, living in Hertford, Herts, with his wife Alana and their two small children; Isla 9, and Hamish 7. Alana is pregnant, so there will soon be yet another addition to the family. After Alan graduated his first job was in Scotland, after which he moved to Cambridge for his GP training. His main interests are art history and photography, but he also enjoys bird watching, playing golf, art galleries, theatre, music and the pub - Alan is a big fan of real ale. He is not politically active, but he supports the coalition government. He accesses the internet both from his PC at work and at home using his laptop and his new iPad. Websites he visits are Flickr, the Independent, Amazon, eBay, Waitrose, Expedia, Wikipedia and Art. His parents live in Edinburgh so he is still in touch with the area and the local community. He has an interest in distance learning. Key tasks • Alan is a busy man with little free time between work and family life. He subscribes to updates from alumni relations and the events section of the site to keep up to date with new information • He keeps an eye on upcoming events and lectures, trying to find time to attend one or two a year • He finds and keeps in touch with other alumni though the website and especially enjoys reunions when they are arranged • Research is another important area , keeping him up to date in his own area of expertise. Some old friends from his student days are now work at the University, and he is always interested in reading work they publish • • • • • You would like to promote Alumni benefits and networking events/opportunities Upcoming events and seminars particularly alumni events and those related to medicine New research that’s being carried out News feeds, so that Alan can subscribe How, when and where alumni can donate to the University 24
  • 26. 26
  • 27. Общие принципы  Описывать действия пользователя, а не системы  Согласованность требований с потребностями пользователя и целями бизнеса  Измеряемость, непротиворечивость, достаточность  Спецификация требований: • • • Контекст Стандарты пользовательских интерфейсов Измеряемые критерии юзабилити  Разрешить и задокументировать конфликты  Согласование с заказчиком 27
  • 29. Что такое сценарий?  Сценарий – это сжатое описание способов применения программного продукта Персоной для достижения цели.
  • 30. Сценарии  Это всегда реалистичные описания жизненных ситуаций, в которых пользователю может быть полезен продукт  Направляют разработку прототипов  Используются для тестирования 30
  • 31. Виды сценариев  Повседневные  Обязательные  Исключительные ситуации 31
  • 32. Литература Karl E. Wiegers Software Requirements, 2nd edition IIBA Business Analysis Body of Knowledge 32
  • 33. Проектирование интерфейсов Проблемы происходят не от сложности создания хороших вещей, а от готовности принимать некачественные вещи, как неизбежное 33
  • 34. Прототипы: для чего?  Ранняя оценка  Показать заказчику  Контакт с разработчиками  Тестирование
  • 35. О чем помнить  Опираемся на Персоны и Сценарии  Оценка • Быстро разработали – быстро получили обратную связь  Стандарты • • • • Платформы Отраслевые Корпоративные UI Patterns  Степень детализации • It depends  35
  • 37. 37
  • 38. Storyboarding  Акцент на том, как продукт решает задачу  Нет привязки к конкретному интерфейсу  Вовлечение всех заинтересованных лиц 38
  • 39. Wireframe  Компоновка элементов  Назначение: • Какие элементы (контролы) • Какая информация  О чем помнить: • Не показывают интерактивность/flow • Бывают разной степени детализации 39
  • 40. Макеты для спецификаций  Макет с подробными описанием всех элементов управления  Назначение: •  Для разработки О чем помнить: • Описать: • • Источники данных • Действия • • • Все состояния Валидации Выслушать разработчиков Не показывать заказчикам и пользователям 40
  • 41. Инструменты  Карандаш, бумага   Balsamiq Mockups (www.balsamiq.com/products/mockups)  Axure (www.axure.com)  SketchFlow (www.microsoft.com/expression)  HTML,CSS,JS 41
  • 42. Литература Bill Buxton Sketching User Experiences: Getting the Design Right and the Right Design Carolyn Snyder Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces 42
  • 43. Оценка Мы не разрабатываем ничего того, что не будет тестироваться. Мы не тестируем то, что не будет использоваться. 43
  • 44. Общие принципы  Обязательный этап  Чем раньше, тем лучше  Непрерывный процесс  Использовать результаты оценки в последующих итерациях  Выделять ресурсы на тестирование и исправление ошибок на всех этапах 44
  • 46. Этапы 1. Найти репрезентативных пользователей (Персоны) • 5-10 человек 2. Выявить критические задачи (Сценарии) 3. Создать протокол юзабилити-тестирования 4. Провести тестирование 5. Проанализировать результаты 6. Внести исправления в дизайн 7. Повторить со следующей группой
  • 47. Принципы  Чем раньше, тем лучше: • • • • • • Начинать с бумажных прототипов Степень детализации На всех этапах Итеративно На ранних этапах – качественная оценка На поздних этапах - Метрики  Модератор  Один и тот же набор задач  Не более 1 часа 47
  • 50. Сценарии  Плохая задача •  Хорошая задача •  У вас есть 200 книг по научной фантастике, сейчас они лежат в ящиках в вашей гостиной. Как бы вы их организовали? Плохая задача •  Найти и купить книжную полку Заказать межбиблиотечный абонемент Хорошая задача • Как бы вы получили книги, которые недоступны в нашей библиотеке? 50
  • 51. Как стоит делать  Придерживаться графика или сценария  Пройти этот сценарий заранее (знать что я это сам могу сделать)  Дать стимул (подарок, сладости)  Поощрять пользователей думать вслух (Think aloud)  Тестируется система, а не пользователь!  Не вмешиваться в процесс  Поговорить с пользователем после тестирования (посмотреть на запись тестирования, дать ему прокомментировать свои действия)  Пересмотреть записи и заметки и сделать выводы как можно раньше после тестирования 51
  • 52. Как НЕ стоит делать  Допускать нерепрезентативных пользователей к тестированию  Учить пользователя  Помогать тестируемому при малейших затруднениях  Вмешиваться в процесс  Сходить с ума если пользователь не может сделать то, что вы считаете очевидным  52
  • 53. Метрики Если мы не можем что-то измерить, то как мы сможем это улучшить?
  • 54. Метрики – Продуктивность. Эффективность.  Выполнимость задачи • Да/Нет • Градации (полностью, частично, с помощью или без)  Время на задачу • Для выполненных задач  Ошибки  Эффективность 54
  • 55. Метрики: Дефекты - все, что препятствует выполнению задачи - что не относится к выполнению задачи - пользователь не увидел то, что ожидал увидеть - выполнение неверного действия - неправильная интерпретация чего-либо 55
  • 57. 1. Видимость состояния системы (обратная связь)  Система должна всегда информировать пользователя о своем состоянии с помощью соответствующих средств, в разумное время
  • 58. 2. Соответствие системы реальному миру (метафоры)  Система должна разговаривать с пользователем на его языке и использовать понятия, образы и концепции, которые уже знакомы пользователю по реальному миру. 58
  • 59. 59
  • 60. 3. Свобода действий и контроль над ситуацией (навигация)  Пользователь может совершить действие по ошибке. У него должен быть «аварийный выход» из этой ситуации, четко обозначенный в программе 60
  • 61. 61
  • 62. 4. Последовательность и следование стандартам (единообразие)  Пользователи не должны гадать, означают ли различные слова, ситуации, действия, объекты одно и то же 62
  • 63. 63
  • 64. 5. Предупреждение ошибок  Дизайн, который предупреждает возникновение проблем, лучше, чем самое хорошее сообщение об ошибке 64
  • 65. 65
  • 66. 6. Узнавание вместо воспоминания (память)  Делайте все объекты, функции, действия видимыми и легко доступными пользователю. Минимизируйте запоминание – пользователь не должен постоянно стараться удержать в памяти информацию из одной части программы, чтобы применить ее в другой 66
  • 67. 7. Гибкость и эффективность использования  Функции, которые ускоряют работу, нужно оформлять так, чтобы они не мешали начинающим, но были легко доступны продвинутым пользователям 67
  • 68. 8. Эстетичный и минималистичный дизайн  Страницы, формы и диалоги не должны содержать лишней и нерелевантной информации. Каждый дополнительный элемент конкурирует с важным содержимым и снижает его заметность 68
  • 69. 69
  • 70. 9. Восстановление после ошибок  Хорошие сообщения об ошибках должны объяснять на понятном языке, в чем состоит проблема и как ее исправить 70
  • 71. 71
  • 72. 72
  • 73. 10. Помощь и документация  Вся документация должна быть легко обнаружима, сосредоточенной на задачах пользователя и описывать конкретные шаги. Однако лучше, если система может использоваться без документации 73
  • 74. 74
  • 75. 75
  • 76. Human-Centered Design - резюме  Исследование раньше прототипа •  Прототипы раньше разработки • • •  Это очень дешево Проводим проверку Вовлекаем всю команду Тестирование прототипов до разработки •  Использовать разные техники исследований Дешевые исправления Оценка • • • • Обязательная Непрерывная Итеративная Долгосрочная 76
  • 77. 8 этапов развития юзабилити в компании Якоб Нильсен 77
  • 78. Этап 1: Враждебность к юзабилити  Хороший пользователь — мертвый пользователь  Цель – писать программы, и чтобы они запускались на компьютере
  • 79. Этап 2: Юзабилити, поддерживаемая разработчиками  Задумались об удобстве использования  Интуитивный подход  Удобство использования с точки зрения разработчиков 79
  • 80. Этап 3: Юзабилити децентрализованных групп  Произвольные инициативные группы  Юзабилити-процессы не систематизированы  Нет выделенного бюджета 80
  • 81. Этап 4: Выделенный бюджет под юзабилити  Есть выделенный бюджет  Юзабилити – волшебство  Специалисты децентрализованы  Юзабилити-тестирование проводится слишком поздно 81
  • 82. Этап 5: Управляемая юзабилити  Выделенный отдел юзабилити  Архивы исследований  Юзабилити-менеджер 82
  • 83. Этап 6: Систематический юзабилити-процесс  Итеративные юзабилитипроцессы  Тестирование на каждом этапе цикла разработки  Ранние исследования 83
  • 84. Этап 7: Интегрированный HumanCentered Design  Численные метрики юзабилити  Использование данных юзабилити для определения того, ЧТО следует производить  Построение продукта «от потребностей» 84
  • 85. Этап 8: Компания, ориентированная на пользователей  Полная интеграция User Experience и HumanCentered Design на все сферы взаимодействия клиента и компании, стратегию и бизнеспроцессы 85
  • 87. Спасибо за внимание! Вопросы? Глеб Уваров g.uvarov g.uvarov@gmail.com 87
  • 88. Полезные книги Donald A. Norman The Design of Everyday Things Jacob Nielsen, Hoa Loranger Prioritizing Web Usability Jesse James Garrett The Elements of User Experience 88
  • 89. Полезные книги Дж. Гарретт Веб-дизайн: Элементы опыта взаимодействия Алан Купер Об Интерфейсе. Основы проектирования взаимодействия Алан Купер Психбольница в руках пациентов 89
  • 90. Полезные книги Стив Круг Веб-дизайн или «не заставляйте меня думать!». Билл Скотт, Тереза Нейл Проектирование вебинтерфейсов Луис Розенфельд, Питер Морвиль Информационная архитектура в интернете 90