Документ представляет собой канву гипотезы, которая помогает структурировать процесс разработки нового функционала, начиная с описания идеи и её проблематики. Основные пункты включают определение проблемы, целевой аудитории, текущего поведения пользователей, ценности решения и бизнес-целей, а также метрики для оценки успеха. Канва также фокусируется на важности команды, поддержке пользователей и выявлении ограничений и возможностей в процессе реализации.

1. Канва гипотезы
С чего начать работу над
новым функционалом?

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

3. Много заинтересованных лиц

4. Закидывают идеями

5. Каждый защищается как может…

6. Добавь фичу, бл@#!

8. 8NE
Брат, мы тебе поможем

9. Быстро перепрыгиваем от идеи к решению

10. А проблему-то какую решаем?

11. А точно это та самая проблема?

12. Люблю канвасы

13. bit.ly/hypothesis_canvas

14. bit.ly/hypothesis_canvas

15. bit.ly/hypothesis_canvas

16. 1 Описание идеи
В 2-3 предложениях фиксируем описание идеи.
Не можем описать просто и понятно? И реализовать не сможем просто и
понятно.

17. 2 Проблема
• Какую проблему мы пытаемся решить?
Можем ли мы однозначно описать проблему?
• Откуда мы узнали об этой проблеме?
Исследования, отзывы, сами придумали выдвинули гипотезу и т.д.
• Как частно нам о ней сообщают?
Это было один раз или каждый день об этом пишут?
• Как давно эта проблема известна?
Может она уже устарела?

18. 3 Кого затрагивает
• Каких пользователей затрагивает эта проблема?
• Являются ли они основной ЦА в данный момент?
• Как часто они сталкиваются с данной проблемой?
Каждый раз при работе, периодически, раз в жизни и т.д.
• Насколько критичны последствия проблемы?
Блокирует работу, мешает эффективно работать, “мелочи жизни” и т.д.
• В какой момент времени возникает проблема?
Что происходит с пользователей в данный момент?
• В каком контексте возникает проблема?

19. 4 Текущее поведение
• Как пользователи сейчас решают данную проблему?
И решают ли вообще
• Какие альтернативные решения используют?
Есть ли у нас аналоги/конкуренты?
• Что их не устраивает в текущем варианте решения
проблемы?

20. 5 Ценность
• Какую ценность мы принесём пользователям?
• Почему люди захотят пользоваться предлагаемым
решением?
• Чем новое решение будет лучше их существующего
поведения?

21. Карта “притяжения”
http://elezea.com/2013/11/progress-making-forces/

22. 6 Цели бизнеса
• Какую ценность получит бизнес от реализации?
Почему для бизнеса важно это реализовать?
• Какие проблемы могут возникнуть, если не решить
данную проблему?

23. 7 Метрики
• Как мы поймем, что достигли успеха?
Что сумели донести ценность пользователям и решить их проблемы
• Какого типа данные/исследования нам нужны?
Качественные и/или количественные

24. Интерфейс Шрёдингера
запасаюсь попкорном

25. 25NE
It’s time to review

26. bit.ly/hypothesis_canvas

27. 1 Задачи пользователей
• Какие задачи пользователи будут выполнять с новым
функционалом?
Как они это делают сейчас мы уже посмотрели
• Какие задачи будут наиболее частотны?
• Какие задачи будут наиболее важны?

28. 2 Осведомлённость
• Как люди узнают о появлении (или наличии) данного
функционала?
• Нужно ли нам что-то делать для этого?
Уведомления в интерфейсе, рассылки, реклама, публичные ресурсы и т.д.

29. 3 Помощь и поддержка
• Нужна ли помощь при работе?
Чтобы начать работу с функционалом, во время работы с функционалом
• Что это должна быть за помощь?
Контекстная помощь, какие-либо интерфейсные решения, новый раздел в
хелпе и т.д.

30. 4 Ограничения
Что нам может помешать или осложнить жизнь?
Люди, время, технологии, текущие интерфейсные решения, контекст, навыки
пользователей и т.д.

31. 5 Возможности
Что нам может помочь или упростить жизнь?
Люди, время, технологии, текущие интерфейсные решения, контекст, навыки
пользователей и т.д.

32. 6 Ключевые активности
Что в итоге нужно сделать, чтобы донести до
пользователей обозначенную ценность?

33. 7 Ключевые ресурсы
• Кто и что нам нужно, чтобы всё это реализовать?
• Кого затрагивают ключевые активности?

34. bit.ly/hypothesis_canvas

35. Помогает
• Структурированно разбирать входящие идеи и хотелки;
• Не забывать важные детали при обсуждении;
• Подольше оставаться в “области проблем”;
• Отсеивать на раннем этапе ненужные (людям в первую
очередь) фичи;
• Фасилитировать командные обсуждения;
• Опираться при проектировании и разработке;

36. Бывает, что так мы выбираем решения

37. P.S.

38. Заменяем слово “проблема” на
слово “потребность” и используем
точно также.
А если нет проблемы, но есть
потребность?

39. P.P.S.

41. Ну вот и все…
slideshare.net/nefimov
efimov.nikita@gmail.com
fb.com/nikita.efimov