Дизайн-процессы (автор Оля Найда)

Участники процесса: 👨‍🎨 Дизайнер (Ops) 🦾 Разработчик (Ops) 🚀 Маркетолог 🤖 Менеджер Все начинается с определение целей, которые продукт и команда должны достичь. Например в формате OKR (Objective and Key Results) # 1. Формирование глобальной гипотезы для достижения OKR Общекомандный сбор с планированием действий, которые нужно произвести для достижения OKR (формирование целевых результатов) Достижение результатов полагается на данные внутренних исследований: проблемные интервью, аналитика статистических данных. В ходе интервью находятся пользовательские истории, которые максимально точно описывают проблемы, которые необходимо решить команде с помощью своего продукта и достигнуть продуктовых и бизнес-результатов. На основе количественных данных и маркетинговых вводных определяется группа респондентов для интервьюирования и сбора качественных данных. Это может быть интервью по существующей функциональности, а может быть исследование новых направлений. В ходе интервью записываются истории, определяется контекст пользователей продукта.

Паттерны в историях помогают составить точные **пользовательские портреты** и в будущем привязывать новые истории и функциональности к этим портретам. После того, как мы поняли какие проблемы существуют у пользователей мы формируем видение идеального продукта. > Люди, которые создают онлайн-курсы через наш продукт, могут закрывать все свои задачи только через наш сервис. Они считают продукт лучшим решением из тех, что они использовали. Они советуют его коллегам и переводят своих клиентов на него. Им настолько нравится продукт, что они продают его за нас. Так за первый релиз мы привлекли 3000 новых платных пользователей > После формирования видения, необходимо определить способы его достижения. Это можно сделать с помощью гипотез. Ниже приведён фреймворк по которому легко это сделать. ## 1. Каждая гипотеза проходит по такому циклу (HADI) ### HYPOTHESIS. **Формирование гипотез-фичей, которые будут проверяться.** Опираемся на собранные ранее данные, в предыдущем цикле или в ходе исследований перед началом разработки продукта (качественные и количественные). У нас уже есть пользовательские портреты и истории с которыми они сталкиваются. **Гипотеза должна отвечать на вопрос:** Как изменится мир пользователей вашего продукта, когда они у них появятся? **Я ВЕРЮ, ЧТО** (моя функция / продукт / решение) **БУДЕТ** (направление изменения) (то, что изменится) **ДЛЯ** (целевого пользователя) **ПОТОМУ ЧТО** (причина изменения) **Как может звучать гипотеза:** «Я верю, что добавив к инструменту рассылки опросы, которые необходимы пользователям для тестирования домашнего задания, мы уменьшим отток инфобизнесменов в другие продукты, потому что они смогут закрывать свои потребности только через наш продукт и не использовать Сенлер вообще» И так далее, гипотез может быть много они сортируются по ценность/усилия ### ACTION. Реализация предположений. 1. Определяем пул задач, которые необходимо выполнить, для проверки этой гипотезы. Задачи можно представлять в виде небольших историй. Например: **Я как** (название роли/персонажа) **хочу** запланировать рассылку на конкретную дату, **чтобы** домашние задания пришли в конце учебного плана. 2. Дизайн грубых прототипов, без привязки к стилям, бумага или приложение типа [https://balsamiq.com/](https://balsamiq.com/). Прототипы разрабатываются, чтобы удовлетворить небольшую историю. 3. Проверка прототипов внутри команды и Лаконичный копирайтирг в интерфейсе 4. Тестирование на небольшом количестве пользователей для отслеживания грубых ошибок. Снова возвращаемся к истории: просим пользователя выполнить целевой сценарий истории. Например, выполнить те действия, которые приведут к вовремя отправленным домашним заданиям. Или конкретно запланировать рассылку на определённую дату. 5. Ревью с разработчиками, можем ли мы внедрить эти решения, какие есть особенности 6. Дизайн мокапов высокой детальности, реалистичных в стиле приложения. 7. Написание спецификаций для реализации 8. Разработка и внедрение функциональности ### DATA. Запуск проверки гипотезы для отслеживания количественных данных На этом этапе мы раскатываем наше решение на часть пользователей для которых мы создавали эту гипотезу. И узнаём подтвердилась гипотеза или нет. Если мы не сделали лучше, проверяем следующую гипотезу, которая может привести к планируемому результату ### IMPLEMENTATION. Внедрение новой функциональности в весь продукт Если гипотеза оказалась верной, мы уменьшили отток пользователей среди тестовой аудитории, то мы раскатываем на всех пользователей эту часть функциональности. Далее цикл повторяется