Однодневный 8 часовой мастер-класс для начинающих проектировщиков интерфейса, графических и веб-дизайнеров, программистов, аналитиков и руководителей проектов. Курс для всех, кто сегодня уже работает над интерактивными продуктами, но чувствуют, что делают это «по старинке», «на коленке», не используя лучшие практики и научный подход. Мастер-класс дает первый опыт погружения в проектирование дизайна взаимодействия «по уму» и позволяет узнать на практике, что скрывается на модными словами user-centered design, rapid prototyping, wireframes и agile user experience testing. Курс читают практикующие специалисты при поддержке Таллинского университета.

1. Экспериментальный
дизайн взаимодействия
ixdworks.com @ ProfsoUX 2014

2. История курса
● Воркшоп проводится с 2010 года
● Формат: 10 дней по 3 часа на англ.яз
● 3 ментора, состав меняется
● В сегодняшнем формате 1 дня – впервые
● На русском языке – впервые
● В нынешнем составе – тоже впервые

3. Цель
Прожить один день в шкуре
дизайнера взаимодействия.

4. Задачи
● Познакомиться с лучшими практиками user-
centered design и попробовать применить их
● Разработать бумажный прототип мобильного
приложения, сайта или инфосистемы
● Привлечь потенциальных пользователей к
оценке и тестированию прототипа
● Обменяться опытом с коллегами по цеху

5. Методика
● Групповая работа в командах из 3-5 человек
● Микролекции, за которыми следует
эксперимент (практическое задание)
● Темы для практического задания будут
предоставлены, можно выбрать свою
● Рефлексия (ретроспектива)

7. Начинаем!

8. Выбираем тему
ixdworks.com @ ProfsoUX 2014

9. Мобильные приложения
● (А) Ориентирование в университетском городке
● (Б) Сравнение цен на курсы англ. языка
● (В) Поиск подходящего ресторана
● (Г) Приготовление вкусной и здоровой пищи

10. Разогревочное упражнение
Метод Эдварда де Боно
“Шесть шляп мышления”
http://thinkingschool.ru/metodyi-myishleniya/shest-shlyap-myishleniya/

11. Персонажи, сценарии и
пользовательские истории
ixdworks.com @ ProfsoUX 2014

12. Шесть шагов от идеи к продукту
(простите, поленился перевести картинку)

13. Цель:
угодить пользователям,
предложив им самый лучший способ
избавления от “боли”

14. “Боль”: цель, задача, goal

15. Решение

16. Решение зависит от контекста:
время, место, культура, доступность технологии

17. Чем хороши четкие цели?
● Держат в фокусе
● Просто объяснить
● Дают повод для
дискуссии
● Принадлежат
пользователям, а
не разработчикам
Например
● Звонить в любую
страну дешевле, чем
по мобильнку
● Найти ночлег в
чужом городе
● Договориться о
времени встречи с 5
коллегами

18. Персонаж:
модель пользователя

19. Заказчик: интернет-магазин семян

20. Клиенты бывают разными
и цели у них тоже разные

21. Персонаж
● Модель типичного пользователя
● Основывается на изучении аудитории:
– наблюдение, интервью, статистика
● Описывается целями и задачами,
желаниями и потребностями,
возможностями и ограничениями
● Социально-демографический портрет
имеет второстепенное значене
● Имеет имя и фотографию для возникновения
эмпатии и упрощения идентификации
Возможный веб-инструмент: http://personapp.io/

22. Карточка персонажа
Биографические данные
Имя, возраст, род занятий, образование
Фотография
Случай из жизни
Описание контекста, в котором персонаж
столкнулся с проблемой,как решает сейчас,
что мотивирует найти лучшее решение.
“Боль”
Решение какой проблемы ищет?
Какой цели желает достичь,
какие задачи ставит перед собой?
Ограничения
навыки использования
компьютера,
ограниченные
возможности,
доступность ресурсов

23. Николай Воробьев,
садовник музея-заповедника “Царское село”
Николай Воробьев
44 года, женат, отец двоих сыновей
Случай из жизни
Николай отвечает за заказ семян и удобрений. К
началу сезона ему нужно высадить более 70
сортов растений. Сейчас он выбирает их по
каталогам 5 поставщиков и делает заказ по
телефону у каждого из них отдельно.
“Боль”
Перелопачивание каталогов в посках нужного
сорта и подходящей цены отнимает время; хотел
бы общаться с другими садоводами, чтобы
узнавать о качестве семян, % всхожести и т.п.
Ограничения
Использует компьютер
ради “Одноклассников”
и чтобы узнать детали
матчей “Зенита”,
которые он пропустил.
На прошлой неделе
врач прописал ему очки

24. Сценарии
● Зарисовки из жизни, помогающие представить контекст
взаимодействия пользователя с продуктом
● Повествование – самый дешевый способ рассказать о проблеме и
видении возможного решения с точки зрения пользователя
● Дают представление о цели, мотивации и наборе совершаемых
пользователем действий
– тут “действия” описываются словами “заказать”, “узнать”, “найти”, а не
технологическими терминами “нажать”, “открыть”, “отправить”.

25. Пример сценария
Вечер пятницы. Николай вспоминает, что за
неделю кончилось несколько сортов
удобрений. Через 2 часа начинается матч
“Зенита”, а перед этим надо забрать
старшего сына с тренировки. Нужно
поскорее заказать эти удобрения! Тем
более, что вид и количества такие же, как
были в прошлом заказе...

26. Пример сценария
Вечер пятницы. Николай вспоминает, что за
неделю кончилось несколько сортов
удобрений. Нужно поскорее их заказать,
ведь через 2 часа начинается матч “Зенита”,
а перед этим надо забрать старшего сына с
тренировки. Тем более, что список и
количества с прошлого заказа почти не
изменились...

27. Признаки годного сценария
● Контекст использования продукта
– спешка, дождь, шум, свет, прерывания,
взаимодействие с другими продуктами
● Цель и мотивация для ее достижения
– только одна цель, убедительное обоснование
● Ничего не говорит о возможном решении
– только описываем желаемый результат
● Самодостаточный для понимания сути

28. Пользовательские истории –
формалированное описание
одной полезной функциии продукта

29. Пользовательские истории
● Шаблон:
В роли …(пользователя)... я могу …
(сделать нечто)..., чтобы … (достичь цели).
● Пример:
Как постоянный клиент, я могу видеть
свои предыдущие заказы, чтобы быстро
повторить любой из них.

30. Польза историй
● Одинаково понятны всем участникам процесса
(пользователь и заказчик остаются увлечены)
● Намекают устраивающее пользователя решение
● Поддаются достаточно точной оценке трудозатрат
на реализацию (часы/дни)
● Сравнительно легко могут быть превращены в набросок
страницы или экрана, программны
код прототопа
● Просто обслуживать: упорядочивать по важности,
объединять в релизы, разбивать на подзадачи и т.п.
● Можно отказаться от любой “фичи” и спасти бюджет или
сроки, не убив идею продукта

31. За дело!

32. Бумажное прототипирование
ixdworks.com @ ProfsoUX 2014

33. Бумажные прототипы —
быстрый и дешевый способ
визуализации пользовательских историй
Также известны как:
paper prototypes, low fidelity prototypes,
LO-FI и даже иногда как wireframes

34. Предназначение прототипов
● Заменить подробное ТЗ
● Конкретизировать
возможное решение
● Повод для обсуждения
● Делать, а не говорить
● Проверить дизайн-
концепцию с реальными
пользователями

35. Когда использовать бумагу?
● Во время мозговых штурмов с командой
● На хакатонах, на переговорах с заказчиком
● Перед тем, как нанять Агенство-Чье-Имя-
Нельзя-Называть или фриланс-девелопера
● Во время разработки по методологии agile
● Если мы ограничены во времени и деньгах
● Везде, где нет доступа к комп./интернету

36. Примеры: начало

37. Примеры: “слои”

38. Пользовательская история в слоях

39. Карты и блокнот

40. Шаблоны и заготовки
Где взять?
http://goo.gl/4rQldn
http://goo.gl/pzMV29
http://goo.gl/CbgxMG

41. А можно без бумаги?
Можно, но:
● будет медленнее
● и потому дороже
● не вовлекает всех
участников
● сложнее тестировать
● нужен компьютер
= not fun! :)
● flinto.com
● balsamiq.com
● gomockingbird.com
● iplotz.com
● popapp.in
+100500
Совет: удачные бумажные прототипы
можно сфотографировать

42. Приступим?

43. Тестирование
бумажных прототипов
ixdworks.com @ ProfsoUX 2014

44. Ура, мы в финале!
(аплодисменты)

45. Цель:
убедиться, что предложенный дизайн
решает задачу пользователя
(и делает его счастливым)

46. Зачем тестировать? Слово классику:
Источник: Jakob Nielsen, 2000
http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

47. Кроме того...
“коридорное тестирование”
aka
hallway / guerilla / agile UX testing
считается одной из 12 рекомендованных
Джоэлом Спольски в 2000 году
“лучших практик” в разработке продуктов.
Остальные 11 практик
http://www.joelonsoftware.com/articles/fog0000000043.html

48. Планирование
● Что тестируем?
● Где тестируем?
● С кем тестируем? (не “на ком!”)
● Как тестируем?

49. Тестируем каждый “чих”
(и чем раньше, тем лучше)
● Почеркушки на салфетках (скетчи, наброски)
● Бумажные прототипы
● Каркасные модели (wireframes)
● Кликабельные прототипы (mock-ups)
● Альфа- и бета-версии (early builds)
Готовый продукт тестировать уже позно.
Как правило, это делают, чтобы убедить владельца
в неизбежности тотального редизайна.

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

51. Идеальный пользователь
● Чувствовал ту же “боль”
● Схож с персонажем в целях и
проблемах, а не в
соцдемографических
характеристиках
● Готов помочь бесплатно
● Не боится говорить,
критиковать, предлагать
● Очень редкий зверь!

52. Придумываем задания
(на основе сценариев и историй)
Плохо
● Зайдите в свой
профиль и измените
пароль на “mypwd1”
● Упорядочьте
результаты поиска
по росту цены
Хорошо
● Восстановите
забытый пароль
● Найдите бюджетный
хостель на Невском

53. Контрольный список
● Задания выполнимы за 5-15 минут
● Определены критерии успешности
● Каждое задание записано на отдельную
карточку для удобства пользователя
● Аппаратура для видеозаписи настроена
● Заготовлены благодарственные шоколадки

54. Как это выглядит?

55. Ход тестирования
● Замечаем потенциального пользователя
● Знакомимся, рассказываем что мы тут делаем
● Проверяем на соответствие персонажу открытым вопросом:
“Часто ли вы путешествуете один?”
● Предлагаем поучаствовать в тестировании, честно ориентируем
по времени (5 или 15 мин)
● Выполняем задания (напоминая проговаривать происходящее,
“Что вы сейчас ищите на экране?”)
● В конце спрашиваем общее мнение, идеи
● Благодарим и вручаем шоколадку
● Обсуждаем с командой, записываем свои соображения

56. Удачной охоты!