UX DESIGN PROCESS

1

Мифы:

UX — это

Что-то неопределенное

Что-то про пользователя

Работа одного человека в компании

Ступень процесса разработки

Единая область знаний

Юзабилити

2

Главный миф:

UX is UI

3

UX is not UI

4

User experience (UX) — Опыт взаимодействия Международный стандарт ISO 9241-210 определяет опыт

взаимодействия как «ощущение и реакцию человека,

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

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

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

антропологии, социологии, информатики, графический дизайн,

промышленный дизайн и когнитивную науку. В зависимости от

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

5

О чем это? "Опыт взаимодействия это не о внутренней работе продукта или

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

улице, где человек входит в контакт с ним. Когда кто-то спрашивает

вас, что это значит пользоваться этим продуктом или услугой, они

спрашивают об опыте взаимодействия.

Трудно ли делать простые вещи? Легко ли разобраться?

Какие ощущения возникают при взаимодействии с

продуктом?

Это опыт взаимодействия формирует впечатление клиента от

предложений компании, это опыт взаимодействия выделяет

компанию среди своих конкурентов, и это опыт взаимодействия

определяет, вернется ли клиент к вам.

Просто выложить информацию на сайте — не достаточно. Она должна

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

воспринять и понять ее. В противном случае, пользователь может

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

ищет. И даже если им удается найти эту информацию, они скорее

всего, сделают вывод, что если с вашим сайтом трудно работать, то с

вашей компанией, вероятно, тоже.

Проще говоря, если ваши пользователи получат неудачный опыт, они

не придут назад.

Даже если никто за пределами вашей компании не увидит ваш сайт

6

или приложение (как в случае внутреннего инструмента), опыт

взаимодействия все еще имеет огромное значение. Часто, это может

означать разницу между проектом, который создает стоимость

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

ресурсоемким кошмаром. Любой дизайн опыта взаимодействия

направлен на повышение эффективности. В основном это

представляется в двух ключевых формах: помочь людям работать

быстрее и помочь им делать меньше ошибок. Повышая

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

бизнеса в целом."

Jesse James Garrett "The Elements of User Experience"

7

Jesse James Garrett

"The Elements of User Experience"

"a must-have"

"an instant classic"

"a quantum leap

in explaining user experience"

8

5 уровней опыта взаимодействия

Jesse James Garrett

9

Как это работает?

1. Поверхность

Уровень поверхности представляет собой внешний вид продукта с

точки зрения конечного пользователя, то есть набор текста, картинок,

ссылок, форм, вкладок, кнопок и прочего.

2. Скелет

Под поверхностью находится уровень компоновки, представляющей

конкретную реализацию абстрактной структуры продукта. На этом

уровне решаются вопросы наиболее эффективного расположения

различных элементов UI.

Скелет создается с целью оптимизации конструкции этих элементов

для достижения максимального эффекта и эффективности.

3. Структура

На уровне структуры описывается взаимное расположение страниц.

То есть этот уровень отвечает на вопросы "откуда", "куда" и "как"

сможет перемещаться пользователь. Эффективная структура

облегчает навигацию и делает ее интуитивно понятной для

пользователей.

10

Скелет определяет размещение элементов интерфейса на странице, а

структура определяет, как пользователи пришли на эту страницу и

куда они могут перейти дальше.

4. Возможности

Уровень набора возможностей представляет из себя перечисление

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

пользователей.

5. Стратегия

Уровень стратегии — это самый низкий и наиболее абстрактный

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

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

относительно будущего программного продукта, как со стороны

потенциальных пользователей, так и разработчиков.

Ответы на эти вопросы будут сформированы и представлены в виде

конкретного списка на уровне набора возможностей.

Снизу вверх!

11

С каждым уровнем вопросы становятся немного менее абстрактными и немного более конкретными.

12

Как с этим работать? TRADITIONALUX DESIGN & USABILITY What are we making?

AGILEUX COLLABORATION DELIVERY How do we make it?

LEANUX MEASURING & VALIDATING PRODUCT/MARKET FIT Are we making the right thing?

13

LEANUX Всё новое — это хорошо забытое

старое

14

Lean — бережливое производство Главный вопрос — Мы делаем то, что нужно?

Главный принцип — Уменьшение рисков

Риски:

- незавершенная работа

- изменение требований

- избыточная функциональность

15

Как это работает? - Борьба с потерями — избавляемся от ТЗ, документов, отчетов.

Минимальный объем информации, необходимый для начала работы

по реализации. *

- Итерации, Итерации, Итерации. Итерации улучшают продукт.

Сокращение времени итерации, а не времени разработки. Короткие,

повторяющиеся циклы низкой детализации.

- Живое взаимодействие в команде. Отзывы всех членов команды

разработчиков как можно раньше и чаще.

- Всё — гипотеза. Гипотеза должна быть доказана или опровергнута.

* О Breadhead

В Breadhead никогда не было большого количества документов и процесса UX на 4

месяца. Не было четкой системы. LeanUX может помочь построить процесс и стать

хорошей философией.

16

Ключевой компонент Ключевым компонентом методологии Lean является цикл

"Build-Measure-Learn".

На первом шаге мы выясняем проблему, которая должна быть

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

(MVP), чтобы начать процесс изучения как можно быстрее.

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

17

18

Минимально жизнеспособный продукт (Minimum Viable Product) Минимально жизнеспособный продукт имеет только те возможности,

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

Продукт обычно запускается для лояльных пользователей, чтобы

получить обратную связь.

"Минимально жизнеспособный продукт — это та версия нового

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

количество проверенных знаний о клиентах с наименьшими

усилиями."

19

Иллюстрации взяты из презентации Семена Молоткова

20

Что важно учесть LeanUX ориентирован строго на этап проектирования (дизайна).

Сокращению подвергается время цикла, а не время разработки.

Что можно прочитать Jeff Gothelf "Lean UX: Getting Out Of The Deliverables Business".

21

LeanUX in real life

Jeff Gothelf. Lean UX process for an interactive agency

22

Ключевые моменты - Регулярное вовлечение клиента. Нужно упомянуть, что будут

показаны наброски, черновые варианты, а не готовые решения.

Получить как можно больше отзывов от клиента. Вовлекая клиента в

процесс по средствам быстрых итераций дизайна и тестирования, мы

получим оптимальное решение в меньшие сроки.

- LeanUX — это не ленивый UX. Скетчи, презентации, обсуждения,

исследования, испытания, создание каркасов — все это используется в

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

эти инструменты, когда это целесообразно и, что более важно,

использовать их на глубине, подходящей для непосредственной

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

- Должен быть баланс между потребностями бизнеса и потребностями

пользователей.

23

Рабочий процесс

24

Стратегия 1 итерация ~ 5­15 дней Проводим исследование для определения продукта и его

конкурентного позиционирования. Формируем идеи.

Входные данные: бриф, обсуждение проекта

25

0. Разогрев: Elevator Pitch Цель этапа:

Учесть все точки зрения и составить общую картину.

На какие вопросы нужно ответить:

For (target customer), who have (customer need), (Product name) is a (market category), that (one key benefit). Unlike (competition), (Product name) (unique differentiator).

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

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

26

Как:

Все заинтересованные стороны (stakeholders) заполняют шаблон

отдельно друг от друга. Если собрать все заинтересованные стороны не

удается, то заполняем шаблон вместе с клиентом.

By John Whalen

By Dave Gray, Sunni Brown, James Macanufo

27

1. Потребности бизнеса Цель этапа:

Привести все заинтересованные стороны, в том числе и команду

разработки, к единому пониманию проекта и приоритетов

бизнес-целей.

На какие вопросы нужно ответить:

- Видение проекта?

- Каковы предположения, на которых основывается стратегия

продукта?

- Как продукт вписывается в общую бизнес-стратегию организации?

Какие бизнес-цели для продукта?

- Насколько велик рынок для продукта, и какую долю рынка он может

занять?

- Какие конкурентные продукты уже существуют в данной области?

Какие продукты являются лидерами рынка? Каковы их сильные и

слабые стороны?

- Какие возможные угрозы?

- Что отличает ваш продукт от других продуктов на рынке?

- Кто целевые пользователи продукта?

- Какую проблему пользователей решает продукт?

- Каковы их мотивы и цели?

- Какие задачи они обычно выполняют? Как часто?

- Кто является основными пользователями, для которых вы

разрабатываете ваш продукт?

28

- Есть ли вторичные пользователи, чьи потребности вы хотите

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

или дополнения в наборе функций вашего продукта?

- Являются ли некоторые типы пользователей крайне

случайными, потребности которых вы не должны учитывать при

разработке вашего продукта?

- Какие группы пользователей можно выделить?

- имеют общие роли, цели и мотивы

- имеют схожие навыки и характеристики

- общие ментальные модели

- работают в подобных контекстах

- как правило, выполняют определенные задачи

- Какие функции сделают ваш продукт полезным для ваших

целевых пользователей?

- Какие функции необходимы для решения бизнес-задач?

- Как проходит процесс взаимодействия пользователя с продуктом?

- Каковы требования к продукту?

- Какую информацию вы хотите сообщать пользователям?

- Какую информацию вы хотите получить от пользователей?

Как:

- Интервью со всеми заинтересованными сторонами

(stakeholders/клиент)

- Брейнштормы

- Все заинтересованные стороны (stakeholders) выписывают

бизнес цели отдельно друг от друга. Если собрать все

заинтересованные стороны не удается, то работаем вместе с

клиентом. Расставляем приоритеты бизнес целей в ходе общего

обсуждения.

Примеры:

29

- Поразить клиентов!

- Создать (возможность), которая принесет пользу клиентам.

- Стимулировать (поведение пользователя) (стратегическим

решением).

By John Whalen

- S.M.A.R.T. техника для оценки целей пользователей и бизнеса

- Изучение бизнеса

- Изучение специфики бизнеса

- Изучение продукта

- SWOT анализ

- Конкурентный анализ

30

2. Потребности пользователей Цель этапа:

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

На какие вопросы нужно ответить:

- Каково предположение бизнеса о пользователях?

- Каково наше предположение о пользователях?

- Какую проблему пользователей решает продукт?

- Как продукт вписывается в их работу или жизнь? В их рутину.

- Если продукт должен удовлетворить потребности пользователей:

- Каким функционалом он должен обладать?

- Во время анализа деятельности, нужно ответить на вопросы:

- Какие цели должны выполнить ваши основные пользователи?

- Если разные пользователи имеют разные роли и цели и,

следовательно, выполняют различные задачи? Как они в этих

ролях взаимосвязаны?

- Как ваши пользователи достигают своих целей в данный

момент?

- Какую терминологию используют ваши целевые пользователи,

чтобы описать свои задачи и данные?

- В какой последовательности ваши целевые пользователи

выполняют свои задачи? Каковы отношения между различными

задачами?

- Каковы первоочередные задачи ваших целевых пользователей?

- Каковы потребности в информации ваших целевых

31

пользователей?

- Какая информация нужна пользователю, чтобы успешно

завершить каждую задачу?

- Как они используют информацию, которая является

результатом выполнения каждой задачи?

Как:

- Группировка и приоритезация пользователей

- Быстрые наброски персонажей

- Никаких детальных описаний персонажей! Это

LeanUX!

- Персонаж + Ситуация + Предыдущий опыт + Мотивы +

Вопросы

- Изучение пользователей, их привычек и рутины

- Интервью с пользователями

- Анализ собранной информации

- Создание карты опыта взаимодействия

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

Содержит путь пользователя, его потребности, желания,

ожидания и общее впечатление. А также возможности продукта

на каждом этапе.

32

Experience Map by Adaptive Path

- Анализ деятельности и создание карты деятельности

Определение видов деятельности и их вспомогательных частей

(задачи, действия, манипуляции).

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

поможет определить подходящий объем функций продукта. А

также процессы, модели взаимодействия и макеты интерфейса

продукта.

- Разложение деятельности на задачи.

- Разбиение каждой задачи на пошаговый процесс:

- данные для выполнения

- когнитивный процесс

- действия над объектами

- точки принятия решений

- результаты процесса

33

- Определение способов улучшить, автоматизировать или

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

для пользователей.

34

3. Формирование идей Цель этапа:

- Выявить и определить точные требования к продукту

- Перечислить и разбить на итерации набор функциональных

возможностей

- Сформировать концепцию и ключевые идеи

- Создать архитектуру продукта

На какие вопросы нужно ответить:

- Какова концепция продукта?

- Какие возможности должен иметь продукт?

- Каков приоритет возможностей?

- Каковы возможные решения по реализации этих возможностей?

- Какие страницы и каково их взаимное расположение?

"Откуда", "куда" и "как" сможет перемещаться пользователь?

- Какой контент необходим?

- Как будет работать продукт?

Как:

- Перечень возможностей (таблица функциональности)

- Оценка функциональности по 3ем параметрам и определение

приоритетов:

- Польза для бизнеса

- Польза для пользователей

- Сложность разработки

35

- Создание информационной архитектуры

- Контентная стратегия

- Описание логики

- Создание диаграмм активности, статусов и т.д.

Несмотря на короткий список, это самый сложный этап.

36

4. Создание набросков Цель этапа:

- Материализовать и проверить идеи

- Решить вопросы наиболее эффективного расположения различных

элементов UI

На какие вопросы нужно ответить:

- Как будет выглядеть и взаимодействовать интерфейс продукта?

Как:

- Проработка в набросках одного или двух ключевых сценариев.

Точность проработки не так важна.

- Как только они будут созданы, начните проверку.

37

Diagram of the iterative design and critique process. Warfel, Todd Zaki.

2009. Prototyping: A Practitioner's Guide. New York: Rosenfeld Media.

By John Whalen

38

Кратко о стратегии: Стратегия. 1 итерация ~ 5­15 дней

Входные данные:

- Бриф

- Обсуждение проекта

Процесс:

0. Разогрев: Elevator Pitch

1. Потребности бизнеса

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

3. Формирование идей

4. Создание набросков

Возможные выходные данные:

- Elevator Pitch

- Описание проекта с точки зрения бизнеса

- Описание проекта с точки зрения пользователей

- Таблица функциональности

- План реализации функциональности

- Информационная архитектура

- Контентная стратегия (добавит к сроку этапа от 4 дней и более)

- Описание логики

- Диаграммы активности, статусов и т.д.

- Наброски

39

Кратко о разработке: Разработка. 1 итерация ~ 10­20 дней

Входные данные:

- Стратегия

Процесс:

1. Создание каркасов

- Создание низкоуровневых каркасов

- Создание высокоуровневых каркасов

- Добавление комментариев

- Проработка состояний

- Реализация интерактивности

2. Описание работы системы

- Создание диаграмм активности, состояний и т.д.

- Описание логики

- Создание таблицы сущностей

- Создание таблицы сущностей по страницам

Выходные данные:

- Каркасы/интерактивные каркасы с комментариями

- Диаграммы активности, состояний и т.д.

- Описание логики

- Таблица сущностей

- Таблица сущностей по страницам

40

Использовать все эти инструменты нужно тогда, когда это

целесообразно и, что более важно, использовать их на глубине,

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

решить для бизнеса.

41

Весь процесс создания продукта 1. Стратегия. 1 итерация ~ 5­15 дней 0. Разогрев: Elevator Pitch

1. Потребности бизнеса

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

3. Формирование идей

4. Создание набросков

2. Валидация — ? дней 1. Внутренняя валидация

- Валидация front-end разработчиком и программистом

2. Валидация клиентом

3. Валидация пользователями

3. Итерация ~ 1­4 дней 4. Валидация — ? дней 1. Внутренняя валидация

- Валидация front-end разработчиком и программистом

2. Валидация клиентом

3. Валидация пользователями

5. Разработка. 1 итерация ~ 10­20 дней 1. Создание каркасов

2. Описание работы системы

42

6. Валидация — ? дней 1. Внутренняя валидация

- Валидация front-end разработчиком и программистом

2. Валидация клиентом

3. Валидация пользователями

7. Тестирование

8. Итерация ~ 1­4 дней

9. Дизайн

10. Верстка

11. Обсуждение проекта с программистом (перед началом программирования)

12. Программирование

13. Обсуждение всего проекта после запуска

14. Анализ (Аналитика и т.п.)

15. Итерация — ? дней (Улучшение продукта)

43

"...but don't forget, "Great design does not come from great processes; it comes from great designers."

Fred Brooks

44