Как проверить идею приложения с помощью прототипа по шагам
Прототип приложения показывает до написания кода, работает ли идея у реальных пользователей: виды прототипов, порядок тестирования и критерии оценки.
Команда rabbitclipПубликация: 6 мин чтения
Коротко
Проверить идею приложения с помощью прототипа значит до написания кода собрать экраны и сценарий в кликабельный черновик и показать его реальным пользователям. Цель не в красивом макете, а в ответе на один вопрос: захочет ли этот человек решать эту задачу с помощью этого приложения и сможет ли он это сделать? Прототип готовится за несколько дней, несколько разговоров показывают, выдерживает ли идея проверку, а неверное предположение обнаруживается до начала разработки, то есть по самой низкой цене.
Проверку часто пропускают, потому что автору идеи кажется, что он и так знает ответ. Но одобрение собственной команды или близкого круга не является доказательством. Представьте приложение для записи на приём: для владельца сценарий очевиден, а клиент, который видит его впервые, может застрять уже на втором экране. Узнать об этом после разработки приложения стоит месяцев труда и бюджета. Узнать на прототипе стоит одного дня.
Чем прототип отличается от MVP?
Прототип представляет собой такую модель, которая на самом деле не работает, но при этом выглядит так, как будто она работает. Экраны в ней связаны между собой, а кнопки ведут на следующий экран, однако за ними нет ни настоящего сервера, ни базы данных, ни платёжной системы. Его назначение состоит в том, чтобы проверить гипотезу, и создают его с расчётом на то, что потом его выбросят.
MVP же является настоящим продуктом, только меньшего размера. Реальные пользователи вводят в него реальные данные, система действительно работает, и она может попасть в магазины приложений. Обычный порядок такой: сначала делают прототип, а затем, если в этом есть необходимость, MVP. Идея, отвергнутая ещё на стадии прототипа, никогда не потребует затрат на MVP, а идея, которая эту стадию прошла, заодно помогает уточнить объём самого MVP.
Какой прототип отвечает на какой вопрос?
Какого-то единого вида прототипа не существует; выбор зависит от того вопроса, на который вам нужно получить ответ. Сначала запишите этот вопрос, а потом выберите самый дешёвый из инструментов, которые способны на него ответить.
Если вы проверяете, реальна ли сама проблема, вам вполне достаточно бумажного наброска и разговора. Если вы проверяете, понятен ли пользователям сценарий, вам нужны кликабельные экраны, собранные в дизайн-инструменте. Если же вы проверяете, возможно ли что-то с технической точки зрения, вы пишете небольшой фрагмент кода, который охватывает только рискованную часть.
- Бумажный или нарисованный набросок: верны ли проблема и базовый сценарий? Проверяется за несколько часов
- Кликабельная модель экранов: понятны ли сценарий и тексты? Пробуется на настоящем телефоне
- Услуга, выполняемая вручную: за кулисами работу делает человек, а пользователь видит автоматическое приложение; так можно измерить, реален ли спрос
- Техническая проверка: выясняется только, работает ли самая рискованная интеграция или функция
Кто должен тестировать прототип и как?
Тестировать прототип должны люди, которые входят в целевую аудиторию. Друзья и члены семьи, как правило, настроены доброжелательно и скрывают свою настоящую реакцию. Небольшой группы из пяти-восьми человек часто бывает достаточно, чтобы увидеть, как одни и те же проблемы начинают повторяться; важнее самого числа то, что эти люди действительно относятся к целевой группе.
Во время встречи не объясняйте пользователю, как устроено приложение. Дайте ему задачу, например «Запишитесь на приём на завтра», а затем замолчите и просто наблюдайте. То место, где он сомневается, то, что он понимает неверно, и та кнопка, которую он ищет, и есть настоящие пробелы вашего продукта.
Записывайте встречу на видео или аудио либо делайте заметки, но фиксируйте то, что произошло, без собственных трактовок. Если пользователь говорит «выглядит симпатично», не считайте это ценным отзывом. Фразы, которые описывают поведение, например «я бы пользовался этим каждую неделю» или «сегодня я делаю это вот так», и есть настоящие данные.
По чему видно, что идея сработала?
Запишите критерии успеха до теста, а не после. Иначе любой результат можно прочитать как хороший. Критерии таковы: завершил ли пользователь задачу без помощи, какую проблему он назвал, описывая её, и готов ли он сделать следующий шаг, например встать в список ожидания или оформить предзаказ.
Порог тоже определите заранее. Если вы ожидаете, что большинство людей, получивших задачу, пройдут сценарий без помощи, запишите это. Порог выбираете вы сами, но он должен быть зафиксирован до начала теста.
- Завершил ли пользователь задачу, не прося помощи?
- Застряло ли в одной и той же точке больше одного человека?
- Как пользователь решает эту проблему сегодня и устраивает ли его это?
- Готов ли он на конкретный шаг, например список ожидания, предварительную регистрацию или предзаказ?
Какие ошибки часто встречаются при проверке на прототипе?
Самая частая ошибка состоит в том, что прототип слишком сильно отполировывают. Модель, в которой доведён до конца каждый пиксель, заставляет пользователей говорить об эстетике, а не о сценарии, и, поскольку на неё уже потрачены усилия, команда начинает обороняться от критики. Прототип должен быть достаточно хорош для того, чтобы проверить гипотезу, и не более того.
Вторая ошибка заключается в наводящих вопросах. Ответ на вопрос «Вам нравится эта функция?» почти всегда будет положительным. Третья ошибка состоит в том, что негативные отзывы списывают на пользователей, которые якобы что-то не поняли; если три человека застревают в одном и том же месте, проблема кроется в экране, а не в людях.
- Слишком полировать прототип и превращать результат в спор о внешнем виде
- Задавать наводящие вопросы, которые подталкивают к ответу да
- Тестировать только со знакомыми и принимать их любезность за доказательство
- Определять критерии успеха после теста
Когда прототип не нужен или выбран неверно?
Если проблема, которую вы решаете, находится в хорошо знакомой области, где уже есть похожие продукты и устоявшийся сценарий, то долгий цикл прототипирования может оказаться лишним. В таком случае гораздо поучительнее сразу перейти к небольшому MVP и к реальным данным об использовании. Прототип ценен тогда, когда неопределённость высока, и лишь отнимает время, когда она низка.
Прототип к тому же не подходит для проверки поведения, которое зависит от оборудования, например качества камеры, работы датчиков или того, насколько хорошо приложение работает без сети. Такие риски проявляются только в небольшой технической пробе. Определите, относится ли ваше сомнение к рынку и поведению людей или к технологии; один и тот же инструмент не годится для обоих случаев.
Прототип не является препятствием для идеи, он оказывает услугу её владельцу: он дёшево ловит неверное предположение и укрепляет верное. Запишите тот единственный вопрос, на который нужен ответ, сделайте самый дешёвый прототип, который способен на него ответить, проверьте его с несколькими людьми из целевой аудитории и заранее определите критерии. Если вы хотите вместе подумать, как проверить вашу идею, вы можете договориться с rabbitclip об ознакомительной встрече.
Частые вопросы
Сколько времени занимает создание прототипа?
Это зависит от объёма идеи и от того вида прототипа, который вы выбрали. Бумажный набросок занимает несколько часов, а кликабельная модель экранов обычно несколько дней. Чем больше вы в него включаете, тем дольше длится работа, поэтому в прототип стоит брать только тот основной сценарий, который вам нужно проверить.
Можно ли сделать прототип, не умея программировать?
Да, можно. Бумажные наброски и кликабельные модели экранов в дизайн-инструментах не требуют никакого кода, и услуга, которую выполняют вручную, тоже его не требует. Код нужен только тогда, когда вы проверяете техническую осуществимость.
Со сколькими людьми тестировать прототип?
Пяти-восьми человек из целевой аудитории часто бывает достаточно, чтобы увидеть, как одни и те же проблемы начинают повторяться. Важнее самого числа то, что эти люди действительно относятся к целевой аудитории; мнение друзей и семьи не является надёжной мерой.
Каков следующий шаг, если прототип сработал?
Вы берёте тот основной сценарий, который выдержал проверку, и определяете вокруг него небольшой MVP. По-настоящему вы строите только этот сценарий, а затем измеряете его результаты на реальных пользователях. Те решения по текстам и по сценарию, которые вы узнали на прототипе, напрямую переходят в разработку.
