Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку. И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах. Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить: - как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич; - как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь; - как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией); - как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса; как можно использовать любимый многими impact map для проработки целей пользователя; - как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.

1. Как UX-специалист делился
своими инструментами с
agile-командами.
Никита Ефимов
Сеть дата-центров “Селектел”

2. Никита
Ефимов
efimov.nikita@gmail.com

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

4. В ролях:

5. 5
Семен
UX-designer, Ix-designer, Product designer
Много лет занимается проектированием
пользовательского взаимодействия.
Последние годы тесно встраивался в разные
agile-команды с переменным успехом.
Характер - нордический, выдержанный.

6. 6
Собирательный образ разных agile-команд, с
которыми Семену довелось
взаимодействовать.
Agile-команда

7. 7

8. 8
А что, если…

9. 9
Совместное обсуждение продукта…
Прозрачный процесс и синхронизация
видения…
Минимизация потерь времени на
пересказ, споры и т.д.
ДЛЯ КОМАНДЫ!!!

10. 10

11. 11

12. 12
Начинать нужно с самого начала, с
анализа, проектировать все равно не
научу быстро…
И про проверку не забыть. Плох тот UX’ер,
который не проверяет свою работу…

13. 13
• Стратегия дизайна
• Experience Map
• Карта эмпатии
• Impact Map
• Модель Кано
• Оценка вкусовщины

14. 14
Пришел к командам

15. 15
Добавление функционала
Новый продукт
(или большой релиз)
VS

16. 16
А как вы фиксируете требования?
Lean/Project/etc. Canvas
В голове!
User story

17. 17
Оооо!!! User stories!
Сейчас расскажу, как их можно прокачать…

18. 18

19. 19
Любите канву??? Их есть у меня!
Для крупных релизов можно
использовать “Стратегию дизайна”

21. 21
Цели бизнеса;
Критерии успешности;
Целевая аудитория;
Задачи продукта;
Ограничения (технические, временные, финансовые);
Сильные/слабые стороны аналогов;
Маркетинговые/брендинговые задачи.

22. 22
Некоторые блоки понятны и очевидны. А
остальные-то нафига нужны?
Каждый из блоков пригодится
нам в дальнейшем…

23. 23
Цели бизнеса уже сейчас можно
“препарировать” с помощью Impact Map’а.
Знакомый вам инструмент?

24. 24
А случалось ли вам сталкиваться с
вкусовщиной?
В стиле “как-то не очень смотрится”….
Зачем нам блок “Маркетинговые задачи”?

25. 25
Да-да, такое частенько бывает…
Дизайнер как понарисует, а
заказчик не принимает…
Части команды тоже не нравится.
Как быть?

26. 26
Все на самом деле не так сложно. Нужно
сформировать оценочные характеристики.
Ну, например…

27. 27
Задачи продукта
• целевая аудитория;
• конкуренты;
• предполагаемый и желанный образ.
Эмоциональное воздействие
• дружелюбный - отталкивающий;
• упорядоченный - хаотичный.
Художественные гипотезы
• теплый - холодный;
• мрачный - яркий.

28. 28
1. Выбираем тип оценочных шкал
(Лайкерта или полярные)
Но не “как тебе дизайн?”, а в разрезе шкал.
2. Опрашиваем людей.

29. 29
Дизайн продукта создает ощущение легкости
1 2 3 4 5
Абсолютно
несогласен
Затрудняюсь
ответить
Абсолютно
согласен
тесный • • • • • просторный
яркий • • • • • скучный
скрытный • • • • • честный

30. 30
0
1
2
3
4
5
Молодежный-Солидный
Скучный - Яркий
Упорядоченный -
Хаотичный
Удобный-Неудобный
Медленный-
Оперативный
Дружелюбный -
Отталкивающий
Легкий-Нагруженный
Современный-
Старомодный
Дизайн 1
Дизайн 2

31. 31
Огонь! Это ведь позволит не тратить кучу
времени на споры…
И “понизит градус
напряженности” в команде…

32. 32
А вы фиксируете общее
взаимодействие человека с продуктом?
А зачем?
Эмм, что это?

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

35. 35
1. Состоит из точек взаимодействия…
Стратегию дизайна помните?
Берем блок “Задачи продукта”. Это и будут
первые точки…

37. 37
1. Состоит из точек взаимодействия…
2. Описывает процесс в каждой точке…

39. 39
1. Состоит из точек взаимодействия…
2. Описывает процесс в каждой точке…
3. Описывает цели человека, проблемы/
барьеры и эмоциональное состояние в
каждой точке…

40. 40
Так ведь они нарисованы, красиво…
Это ж сколько времени потрачено???
А так?

42. 42
Чтобы детально “препарировать” каждый
шаг (цели там всякие, проблемы и т.д.) можно
воспользоваться картой эмпатии…

44. 44
Брейнстормим фичи, в разрезе:
• как помочь избежать проблем/барьеров;
• как помочь достичь целей человека;
• как улучшить взаимодействие…

45. 45
А как работать с целями пользователей?
А вот тут поможет Impact Map!

47. 47
У пользователей есть свои цели;
Как эти участники позволят пользователю достигнуть его
цели?
Достижение этих целей затрагивает разных участников
процесса:
• самого пользователя;
• других участников.

49. 49
А ведь это похоже на User Story Map…
Правда?
Именно! Это хорошая основа
для Story Map’а…

50. 50
Jeff Patton

51. 51

52. 52
Круто получилось! Сейчас все оценим
по трудозатратам и в бой!
Воу-воу, полегче! Ведь не все эти
фичи реально нужны пользователям.

53. 53
Так а как быть? Пока ведь не
выпустим, не узнаем…
А мы просто спрашиваем у пользователей,
нужна им эта фича или нет…
А у нас все Product Owner решает…

54. 54
Тише-тише. Спрашивать - это хорошо, но
вот только не так.
Есть отличный способ - модель Кано.

56. 56
Задаем два простых вопроса для каждой
фичи.

57. 57
Как вы относитесь к наличию этого функционала в
продукте?
Как вы относитесь к отсутствию этого функционала в
продукте (или он будет выражен слабо)?

58. 58
И предлагаем такие же простые ответы
(для каждого вопроса)…

59. 59
Мне это нравится;
Я ожидаю, что этот функционал будет в продукте;
Я отношусь к нему нейтрально (не особо важно);
Я могу его терпеть;
Мне это не нравится.

61. 61

62. 62
И Семен рассказал, как можно
анализировать результаты опроса.

63. 63
А вот то, что это все можно проверить -
за это отдельное спасибо!
И никакой магии!

64. 64
Стратегия дизайна -
как способ фиксации первых требований с
ориентацией на пользователей.

65. 65
Experience Map -
как способ фиксации цельной картины
взаимодействия человека с системой.
Это хорошая основа для Story Map’а.

66. 66
Карта эмпатии -
как способ более глубокого понимания
человека.

67. 67
Impact Map -
помогает проработать цели человека (и
бизнеса, конечно) и нагенерировать фичи.

68. 68
Модель Кано -
помогает оценить ожидания и
удовлетворенность от наличия/отсутствия
определенного функционала.

69. 69
Оценка вкусовщины -
помогает (структурированно) оценить
восприятие интерфейса (дизайна).

70. 70
В реальной жизни

71. Спасибо!!!