У каждой компании свое видение идеального процесса разработки продукта. Ниже изображено как это происходит в отделе дизайна Яндекса. Эта схема не золотой стандарт, она скорее обобщает множество других схем.

Линейность графика не должна вводить вас в заблуждение — процесс разработки продукта подобен клубку ниток

Концепция

Первичная идея

Любая разработка начинается с того, каким продукт должен быть и какую проблему должен решать. Несовершенство мира, анализ метрик, требования заказчика — все это может подстегнуть вас и зародить в вашей голове идею.

А что если нет идеи? Тогда посмотрите на конкурентов. Возможно их продукт просто закрывает потребность, но не решает проблему клиента. Посмотрите на другие области. Вот например, лекция на Ted.com о том, как физика помогла решить проблему в хирургии. В конце концов, посмотрите на изменение условий вокруг вас. Например, появление парковки в Москве послужило поводом для создания знаков и паркоматов. 

Еще идею можно сгенерировать. Для этого есть два способа. Аналитический — когда мы смотрим на статистику, цифры и наблюдения. И синтезирующий — когда мы перерабатываем накопленный опыт и делаем качественный скачок вперед. Первый способ довольно предсказуем, ведь у нас всегда есть под рукой измеримые показатели. Второй  — более рискованный. Это прыжок в бездну, в место, где никто не бывал до нас. Этот метод полагается на перебор альтернатив и их эволюцию. Аналитический метод поможет в краткосрочной перспективе, а синтезирующей — в долгосрочной. Вы можете использовать оба подхода одновременно.

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

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

Профили потребителей

Далее выясняем у людей, какие задачи должен решать продукт, какие боли закрывать и какие выгоды они получат. Ответы на эти вопросы мы получаем во время анкетирования и интервью. Задачи разделяются на три вида:

Далее идут боли, которые мешают выполнению задач. Например, в приложение конкурентов при заказе пиццы нужно пройти через 12 экранов настроек — задача выполняется, но это очень неудобно. Боли имеют те же самые три вида.

Выгоды бывают четырех видов. Обязательные — это базовые вещи. При заказе такси в любом сервисе вы получаете такси. Ожидаемые — то, что мы хотим получить от продукта. При заказе такси, мы ожидаем, что салон машины будет чистым. Желаемые — то, что мы хотели бы от продукта. При заказе такси, мы бы хотели выбрать марку машины. Неожиданные — запросы, о которых мы не задумывались, но их уже решили. Например, при заказе такси, автоматически рассчитывается время прибытия с учетом пробок.

Собираем задачи, боли и выгоды

После определения задач, выгод и болей, мы начинаем их ранжирование. Более важные ставим наверх, менее важные — вниз. В зависимости от ваших целей, некоторые пункты можно удалять или переносить из одной категории в другую.

Ранжируем их

Выбор сегмента рынка

После того, как мы определились с профилями потребителей, нужно определить кто является аудиторией нашего проекта. Есть несколько требований к ее подбору. Она должна быть измерима. Ее должно быть достаточно, иначе ваш проект не сможет самоокупаться. Эти люди должны быть достижимы, например, привлечение стариков, которые смотрят только первый канал, встанет вам в круглую сумму. Аудитория должна быть стабильна. Тут нужно отдельно упомянуть пример, который привел Сергей Томилов в лекции. Он назвал стабильной аудиторию туристов, которые летят в Турцию. Лекция была записана до событий с Турцией. Хороший пример того, что некоторые события трудно предугадать.

Иногда целевая аудитория может не совпадать с теми, кто покупает ваш продукт. Например, дети, которые покупают своим родителям смартфоны.

Гипотезы решений

Если вы определились с аудиторией, можно переходить к следующему шагу. На этом этапе мы формулируем гипотезы возможных решений. Это поможет нам обосновывать свои будущие решения в проекте. Примерный шаблон выглядит так:

Кажется, что ...это сработает так...
Чтобы проверить это, мы ...сделаем так...
И измерим ...вот эту метрику...
Мы правы, если ...метрика поведет себя так...

Гипотезы можно разделить на несколько видов. Бизнес-гипотезы отвечают на вопрос: «Что мы с этого получим?». Продуктовые — «какую аудиторию наш продукт обслуживает и с помощью какого решения?» Гипотезы об устройстве — «как устроен сервис?» Технологические гипотезы — «почему мы пишем на этом языке программирования, а не на другом?»

Мы плодим множество таких решений, а затем отбираем лучшие из них. Как только мы получили достаточное количество гипотез, переходим к составу продукта.

Состав продукта

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

Продукты и сервисы бывают четырех видов: физические (часы Apple Watch), нематериальные (услуги Uber), цифровые (стриминговый сервис Twitch.tv), финансовые (тарифные планы у Мегафона).

Болеутоляющие — это решения, сглаживающие боль потребителя. Например, вы никогда не умели беречь деньги, а приложение «Тяжеловато» сэкономило вам круглую сумму. 

Источники выгоды — это схема монетизация. Это может быть подписка каждый месяц, микроплатежи, пожертвования и многое другое

Как и в случае с профилями потребителей, вам нужно расположить все эти части по приоритету и выбрать самые важные. Определились с составом? Самое время его проверить.

Тест состава продукта

На этом этапе наша задача взять список задач, болей и выгод, и соотнести его с гипотезами решений. Примерно так:

Смотрим, есть ли совпадение в обоих системах

Если совпадают карточки из двух систем, помечаем галочкой. Это значит, что для функции уже заготовлена гипотеза решения. Помните, нет задачи, чтобы все совпало. Вполне возможно, что для каких-то проблем вы не нашли пока решение.

Далее наша задача убедится, что потребители видят ценность в продукте. Вам нужно задать только основные вопросы. Если при обсуждение нужен дополнительный вопрос, которого нет в списке — задавайте. Вопросы могут быть разными:

• Что мы должны оставить, а от чего отказаться?
• Что кажется второстепенным?
• Что бы вы добавили?
• Что бы вы убрали?
• Что-нибудь важное потерялось?

На этом этапе лучше иметь заготовку, например, брошюру или промо-сайт, которую можно продемонстрировать человеку. Иногда сложно понять о чем речь, если нет визуального представления о продукте.

Ранжирование фич

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

• Важность
• Ощутимость (боль возникает мгновенно или нет)
• Неудовлетворенность
• Выгодность, рентабельность (платежная аудитория, большая ли аудитория)

После мы проводим эксперимент «Купи фичу». Пользователям раздается виртуальный бюджет. С его помощью они могут проголосовать виртуальным рублем за функции продукта. Бюджет заведомо ниже стоимости всех фич, поэтому мы можем увидеть количественно, сколько людей купят эту функцию продукта. Все это даст нам представление о том, что для людей наиболее ценно в нашем продукте. А раз у нас есть список особенностей, можно делать минимально-жизнеспособный продукт.

Минимальный продукт (minimal viable product, MVP)

На этом этапе мы создаем MVP. Его задача создать максимальную ценность при минимальной стоимости. Мы должны проверить жизнеспособность продукта, при этом не обанкротив компанию. Здесь слово «минимальный» отражает набор функций необходимых пользователя и не имеет отношения к сложности технической части.

Примером минимального продукта может служить история dropbox. Перед запуском самого сервиса, они сделали серию лендингов с описанием функций продукта. Это позволило выяснить, есть ли у потребителей интерес к сервису.

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

• Тестирование продуктовой гипотезы
• Экономия времени на разработку, потраченную впустую
• Ускорение предоставления продукта ранним покупателям

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

• Доказательства ценнее мнений
• Экспериментируйте чаще
• Детали на старте не важны
• Эксперименты не равно реальность
• Сохраняйте видение проекта
• Знайте, что может разрушить вашу идею
• Первым делом поймите своего потребителя
• Обеспечьте измеримость
• Не все факты одинаковы равны
• Проверяйте необратимые решения дважды

Подходя к следующей стадии посмотрите сюда. Чем ближе к концу графика, тем больше времени и бюджета вы тратите.

Продукт

Реализация

Прежде, чем приступить к реализации, мы должны презентовать продукт команде или компании. Мы доказываем, что наш продукт стоит на него потраченных денег и принесет пользу. Если проекту дан зеленый свет, то начинается проработка всех деталей. Мы составляем чеклист важного, балансируя между качеством и стоимостью. Дорабатываем дизайн. Вот пример реализации мобильной главной страницы Яндекса:

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

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

Делаем третий подход. Вспоминаем, что на мобильном телефоне можно делать свайп. Выкатили такую версию. Спустя пару недель посмотрели на цифры и как люди пользуются продуктом. Все метрики рухнули. Табы снизу плохо видны и они кликаются меньше, чем на главной. Чтобы увеличить кликабельность, сделали цифры очевидными. Добавили слова «баллы», «письма», «рубли».

Делаем четвертый подход потому, что метрики все равно не очень. Уменьшаем и подписываем иконки.

Метрики все равно не идеальны. Делаем ссылки очевидными, покрасив их в синий. Даже это не исправило ситуацию. Это последний макет на момент создания лекции. Есть предположение, что счетчики неправильно развешаны.

Коммуникация

После запуска проекта нам важно создать определенное отношение к продукту. Нужно понимать, кому, где и что мы говорим. Или по-другому, «аудитория + канал + сообщение». Чтобы сделать ваше сообщение эффективным, нужны:

• Причина вам доверять
• Эмоции
• Исследования
• Тестирование

Ваша задача сформировать потребность в продукте. Если вы пытаетесь завлечь пользователей с помощью заголовков «101 способ заработать в интернете без регистрации и смс», то получите соответствующую аудиторию. Думайте о взаимоотношениях пользователя с продуктом.

А что дальше?

А дальше только развитие продукта. На этом этапе вы начнете получать реальные данные от ваших пользователей. И все решения и гипотезы будут проверены.

Это очень краткий конспект лекций о продуктовом дизайне в Яндексе (с 11 по 18). Полный курс можно посмотреть на канале академии дизайна Яндекса. Также вы можете почитать конспект Александра Бизикова.