Создание прототипа MVP (шаг 5)
После того как вы определили набор функций для своего кандидата в MVP, вам захочется протестировать его на пользователях. Чтобы это сделать, необходимо будет создать пользовательский опыт (UX), который вы сможете показать клиентам. Напомню, что это является верхним уровнем пирамиды соответствия продукта рынку.
На этом этапе цель состоит в том, чтобы создать такой прототип, который позволит вам проверить свои гипотезы. Как обсуждалось в главе 1, я намеренно использую пространный термин MVP-«прототип», чтобы охватить наиболее широкий спектр продуктов, которые вы можете протестировать на пользователях для получения обратной связи. Хотя первый же тестируемый «прототип» может стать в дальнейшем реальным MVP, его использование предоставляет возможность получить обратную связь быстрее и с меньшими затратами ресурсов, проверив выдвинутые гипотезы еще до создания настоящего MVP. Кроме того, как обсуждалось в главе 1, несмотря на то что я использую здесь термин MVP, процесс бережливого производства применим даже тогда, когда вы не создаете продукт с нуля, а, например, добавляете новую функцию или улучшаете уже существующее решение. Вид прототипа, который вы должны создать, зависит от того, какого рода тестирование вы собираетесь проводить.
Чем является (и чем не является) MVP?
Ведутся оживленные дебаты по поводу того, что следует понимать под термином MVP. Некоторые яростно доказывают, что лендинговая страница сама по себе уже является MVP. Другие утверждают, что это далеко не так, настаивая, что MVP должен быть реальным работающим продуктом или, по крайней мере, интерактивным прототипом. Способ, которым я разрешаю эту дихотомию, заключается в осознании того, что и то и другое является методом тестирования гипотез, лежащих в основе MVP. Использование термина «MVP-тест» позволяет прекратить эти дискуссии. Данный термин более точно описывает суть и оставляет возможность закрепить термин «MVP» за реальными продуктами.
Многие неверно истолковывают термин «минимально жизнеспособный продукт», делая слишком значительный акцент на слове «минимально». Они используют это как предлог для создания неполноценного MVP, который обладает слишком малой функциональностью, чтобы считать его жизнеспособным. Другие ссылаются на слово «минимально», чтобы оправдать некачественный пользовательский интерфейс или ошибки в коде. Несмотря на то что MVP по определению является ограниченным по представленному в нем функционалу относительно всего объема ценностного предложения, то, что вы предоставляете на суд пользователей, должно быть выше определенной планки, чтобы иметь потребительскую ценность.
Рисунок 7.1. Внутреннее строение MVP
Диаграмма на Рисунке 7.1 иллюстрирует разницу между неправильным и правильным способами интерпретации MVP. Я адаптировал этот рисунок по образцу, созданному талантливым UX-дизайнером Юсси Пасаненом из Volkside (http://volkside.com).
Подобно моей иерархии потребностей веб-пользователей (см. Рисунок 4.2), на этом рисунке различные аспекты продукта представлены в виде слоев пирамиды. В данном случае для описания атрибутов продукта используется пирамида из четырех иерархических уровней: функциональность, надежность, удобство [использования] и восхитительность. Пирамида слева иллюстрирует ошибочное представление о том, что MVP представляет собой всего лишь продукт с ограниченной функциональностью, а надежностью, удобством использования и функциями, вызывающими восхищение пользователя, при его создании можно пренебречь. Правая пирамида показывает, что, хотя MVP и обладает ограниченной функциональностью, он должен быть «полноценным» в том смысле, что в нем находят свое отражение атрибуты, расположенные на всех трех более высоких уровнях.
MVP-тесты
Возвращаясь к теме MVP-тестов, замечу, что вы можете использовать множество различных видов тестов. Возможно, вы слышали некоторые из названий: «Волшебник страны Оз», «Дымовой тест» и «Фальшивая дверь». В этой главе будут описаны различные виды тестов MVP, что, надеюсь, поможет вам решить, какой из них в наибольшей степени подходит к вашей ситуации. Кстати, вместо того чтобы повторять без конца слово «тестировать», я иногда буду использовать в качестве синонима слово «валидировать». Некоторым больше нравится именно «валидировать», потому что это подразумевает проверку лежащих в основе MVP гипотез. Других применение этого слова раздражает, поскольку, в их понимании, оно заранее указывает на успешное прохождение тестирования. Как уже было сказано, я использую слово «валидировать» просто как синоним к «тестированию гипотез», не придавая ему никакого смысла в отношении предполагаемых результатов.
Несмотря на то что термин «MVP-тест» обеспечивает удобное обобщение всех различных видов подобных тестов, между ними имеются ключевые различия. Существует два основных способа их классификации.
Продуктовые и маркетинговые MVP-тесты
Первый способ классификации MVP-тестов заключается в определении того, направлены ли они на тестирование самого продукта или же ваших маркетинговых усилий. Тест целевой страницы (лендинга), который измеряет, какой процент потенциальных клиентов нажимает кнопку «зарегистрироваться» и оставляет свой адрес электронной почты, ориентирован на маркетинг, поскольку в этом случае не происходит реального использования посетителем веб-страницы каких-либо функциональных возможностей продукта. В этом случае вы просто описываете потенциальным потребителям предлагаемый функционал, чтобы увидеть, насколько привлекательным и убедительным они находят ваше описание.
В свою очередь, MVP-тесты, направленные на валидацию продукта, обязательно включают в себя реальную демонстрацию потенциальным клиентам его функциональных возможностей с целью получения обратной связи. Это может быть действующая бета-версия продукта или просто вайрфрейм низкой точности для оценки соответствия продукта рынку. Как при продуктовом, так и при маркетинговом MVP-тестировании вас интересует, насколько привлекательным пользователи находят то, что вы им показываете; но цель получения обратной связи в этих случаях разная. Маркетинговые тесты могут принести ценную информацию, но она не будет иметь отношения к реальному продукту, создающему ценность для потребителя.
Когда при помощи повторяемого тестирования прототипа кандидата в MVP вы достигнете точки, в которой почувствуете, что с достаточной долей уверенности подтвердили соответствие продукта рынку, можно будет приступить к этапу создания реального MVP.
Количественные и качественные MVP-тесты
Второй способ классификации MVP-тестов заключается в отнесении их к качественным или к количественным. Качественный тест предполагает, что вы общаетесь с небольшим числом пользователей, не имеющим статистической значимости. В этом случае вас интересуют подробности, которые вы узнаете в ходе каждого интервью. Конечно, в полученных результатах вы можете попытаться выявить закономерности, но расчет статистических показателей не является первостепенной задачей для данного вида тестов. Если, например, вы провели индивидуальные интервью с 12 потенциальными потребителями, чтобы узнать их мнение о макете вашей лендинговой страницы, это означает, что вы провели качественное тестирование.
Количественное исследование предполагает проведение масштабного тестирования на большом количестве пользователей. В этом случае вам уже не настолько интересны отзывы отдельных пользователей – вас волнуют совокупные результаты. Если вы подготовили две версии лендинговой страницы и показали каждую из них тысячам пользователей, чтобы узнать, какая из версий будет иметь более высокий коэффициент конверсии, вы тем самым провели количественное тестирование.
Количественные тесты хороши для того, чтобы получить ответы на вопросы «что?» и «сколько?»: что именно сделали пользователи и сколько из них совершили то или иное действие (например, нажали на кнопку «зарегистрироваться»). Однако количественные тесты не объяснят вам, почему одни пользователи совершили то или иное действие, в то время как другие предпочли этого не делать. Напротив, качественные тесты хороши для получения ответов на вопрос «почему?». Они направлены на изучение причин, лежащих в основе решений различных пользователей.
Оба вида тестов имеют свою ценность и дополняют друг друга. Мой опыт показывает, что многие команды разработчиков излишне полагаются только на один вид тестов, обычно количественный. Принимая решение о том, каким из видов тестов следует воспользоваться, необходимо исходить из того, какую именно информацию вы хотите получить. На начальном этапе разработки продукта или маркетинговых материалов более полезными оказываются качественные тесты, позволяющие получить некоторое первоначальное представление. Использование на этом этапе количественных тестов без предварительного проведения качественных обычно не дает полезных результатов – вы получите совокупные статистические данные, но не будете знать, какие представления пользователей лежат в их основе. Во многих случаях команды, работающие над созданием продукта, чередуют раунды качественного и количественного тестирования по мере получения информации и прохождения итераций улучшения. Дополнительные советы, относящиеся к проведению качественного тестирования продукта на пользователях, вы найдете в главе 9.
Матрица MVP-тестов
На Рисунке 7.2 представлена матрица, содержащая сводную информацию о классификации различных MVP-тестов на основе сравнения продуктовых тестов с маркетинговыми и качественных тестов с количественными. В каждой из четырех ячеек матрицы я перечислил соответствующие ей MVP-тесты. Далее я коротко опишу каждый из четырех видов тестов, представленных на рисунке.
Рисунок 7.2. Классификация MVP-тестов
Качественные маркетинговые MVP-тесты
Давайте начнем с качественных маркетинговых тестов, размещенных в верхней левой ячейке матрицы. Очевидно, что существует множество различных способов продвижения продуктов на рынке. Вместо составления длинного списка соответствующих тестов я объединил их все под одним наименованием – «Маркетинговые материалы». Тесты, относящиеся к данному типу, включают в себя демонстрацию потребителям маркетинговых материалов и получение соответствующей обратной связи. Маркетинговые материалы включают в себя все, что вы хотели бы представить своему пользователю: целевую страницу, видеоролики, рекламу, электронные письма и так далее. Цель таких тестов – понять, насколько убедительным для пользователей является представленный им маркетинговый материал и почему. Таким образом, вы получаете обратную связь не о самом продукте, а, скорее, о том способе, которым вы доносите информацию о нем.
Такие тесты могут помочь понять, какие из предлагаемых вами преимуществ находят отклик со стороны потребителей, а также их реакцию на различные формы и способы рассказа о преимуществах вашего продукта. Проводимое в ходе качественного маркетингового тестирования интервью позволяют увидеть, насколько привлекательным в глазах пользователей выглядит ваше ценностное предложение. Вы даже можете показать клиентам маркетинговые материалы конкурирующего продукта, чтобы узнать их преимущества и недостатки, а также проверить гипотезу об отличиях вашего продукта от аналогов.
Один из хороших способов протестировать уровень общего представления предлагает так называемый «пятисекундный тест». Его идея состоит в том, что вы показываете пользователю домашнюю или целевую веб-страницу всего на пять секунд, а затем просите рассказать, что он запомнил и что ему понравилось. Поскольку пользователям свойственно делать быстрые выводы, такой тест может быть хорошим способом увидеть, насколько хорошо ваш лендинг доносит информацию о том, на что способен ваш продукт и почему кто-то может захотеть им воспользоваться.
Количественные маркетинговые MVP-тесты
Вы можете использовать количественные маркетинговые тесты для оценки спроса на ваш продукт. Также они могут применяться для оптимизации привлечения потенциальных клиентов и превращения их в реальных клиентов. Поскольку такие тесты фиксируют поведение пользователей, при большом размере выборки они могут обеспечить вас значительным объемом полезной информации.
Целевая (лендинговая) страница / «Дымовой тест»
Одним из самых популярных тестов данного вида является целевая (лендинговая) страница или «Дымовой тест». Такой тест предусматривает создание рабочей веб-страницы, на которую вы направляете пользовательский трафик. Целевая страница описывает продукт, который вы планируете создать, и предлагает посетителям выразить свою заинтересованность. Обычно для этого предлагается кликнуть на кнопке «Зарегистрироваться». Этот тест иногда называют «дымовым», поскольку он проводится в отсутствии реального продукта, которым посетители веб-страницы могли бы воспользоваться. Вместо этого присутствует лишь описание планируемого функционала, благодарность посетителям за проявленный интерес и предложение указать свой адрес электронной почты или другую контактную информацию, чтобы сообщить о выходе продукта.
Ключевым показателем для данного вида тестов является коэффициент конверсии: процент посетителей целевой страницы, которые нажали на соответствующую кнопку, чтобы превратиться из потенциального клиента в покупателя. Например, если вы привлекли на свою лендинговую веб-страницу 1000 посетителей, из которых 250 человек нажали кнопку «Зарегистрироваться», то коэффициент конверсии составит 25 %. На величину данного показателя влияет то, какие преимущества вы выберете для демонстрации и насколько хорошо опишете свой продукт. При этом необходимо учитывать, что даже если вы выбрали для показа действительно важные для пользователей преимущества, коэффициент конверсии может оказаться низким из-за плохой проработки дизайна веб-страницы и текстового описания.
Ваша команда разработчиков может создать и использовать для статистической оценки посещений целевых страниц собственные решения. Однако стоит отметить, что такие удобные инструменты, как Optimizely и Unbounce, ускоряют и упрощают процесс тестирования и оптимизации лендинговых страниц, экономя при этом затраты на их разработку.
MVP-тест целевой страницы на примере приложения Buffer
Приложение Buffer представляет собой хороший пример MVP-теста целевой страницы. Buffer – это продукт, который помогает организовывать размещение сообщений в Twitter, публикуя выбранные твиты в заранее запланированное вами время. Генеральный директор и соучредитель Buffer Джоэл Гаскойн описал в своем блоге (https://blog.bufferapp.com/idea-to-paying-customers-in7-weeks-how-we-did-it) процесс MVP-тестирования целевой страницы этого продукта. По его словам, в случае с Buffer он решил применить иной подход, нежели к своему предыдущему стартапу: «Я начал писать код для Buffer еще до того, как проверил степень жизнеспособности проекта. Но я быстро осознал свою ошибку, остановился, глубоко вдохнул и сказал себе: “На этот раз сделай все правильно. Начни с проверки того, нужен ли людям этот продукт”».
Первая домашняя страница Buffer описывала ценностное предложение продукта с помощью заголовка и трех маркированных пунктов. Еще там была одна единственная работающая кнопка «Тарифные планы и цены», нажав на которую посетители попадали на страницу со следующим текстом: «Вы застали нас в процессе разработки». Далее посетителям предлагалось ввести свой адрес электронной почты, чтобы получить уведомление о запуске продукта.
Как объяснил Гаскойн: «Цель этого двухстраничного MVP состояла в том, чтобы проверить, захочет ли кто-то вообще использовать наше приложение. Я просто разместил ссылку в Twitter и спросил читателей, что они думают об этой идее. После того как несколько человек отправили мне свою электронную почту с лендинговой страницы, а некоторые даже прислали полезные отзывы на e-mail и в Twitter, я счел свою идею протестированной».
Таким образом, Гаскойн получил подтверждение востребованности задуманного им проекта. Далее следовало проверить, готовы ли люди платить за это. Поэтому он сделал дополнительную страницу (перед формой для отправки адреса электронной почты), на которой разместил описание трех тарифных планов с различными уровнями использования продукта: бесплатный, за 5$ в месяц и за 20$ в месяц. Это позволило ему увидеть, сколько кликов собрал каждый тарифный план, в дополнение к тому, сколько пользователей согласились указать свой e-mail. Тестирование прошло успешно. Несмотря на появление необходимости дополнительного перехода между страницами, посетители по-прежнему заходили на форму отправки адреса электронной почты, оставляли свои e-mail и даже выбирали платные условия использования продукта.
Стоит отметить, что никакой фактической платы за использования Buffer не взималось (хотя бы потому, что реально работающего продукта на тот момент еще не существовало). Но собранные статистические данные позволили Гаскойну почувствовать, что у него есть достаточно доказательств соответствия его продукта рынку. Всего два простых теста помогли ему обрести необходимую уверенность для продвижения к реализации своей идеи.
Демо-ролик
Демо-ролик на самом деле является всего лишь еще одним вариантом тестирования с использованием целевой страницы, в основе которого лежит видеоролик, рассказывающий о вашем продукте. О его эффективности можно судить опять же по коэффициенту конверсии, рассчитываемому на основе посещений веб-страницы с регистрацией. Данный тип теста хорошо подходит для продуктов, ценность которых трудно описать только словами. Облачный сервис хранения данных Dropbox провел один из самых известных MVP-тестов с использованием демонстрационного видеоролика. Основатель Dropbox Дрю Хьюстон заметил, что люди просто не понимают словесных объяснений, чем Dropbox с его уникальным подходом к синхронизации файлов выгодно отличается от других сервисов хранения файлов, представленных в то время на рынке. Поэтому он создал видеоролик, в котором показал и объяснил, как работает Dropbox. Пользователи увидели в этом ролике действующий способ решения проблем, с которыми они реально сталкивались, пытаясь управлять своими файлами и обмениваться ими между различными устройствами. Это привело к появлению большого количества подписчиков в листе ожидания закрытого бета-тестирования Dropbox.
Рекламная кампания
Чтобы протестировать целевую страницу, вам нужно каким-то образом заманить на нее пользователей. Один из способов сделать это является проведение рекламной кампании. Например, сервис Google AdWords в тот момент, когда пользователи осуществляют поиск в сети Интернет, демонстрирует им короткую контекстную рекламу. Вы можете поэкспериментировать с различными ключевыми поисковыми словами и текстами рекламных объявлений, чтобы увеличить количество переходов. Это позволит собрать количественные статистические данные о том, какие именно ключевые слова и фразы обладают наибольшей привлекательностью для ваших потенциальных потребителей. Вы также можете использовать медийную рекламу для тестирования различных сообщений и изображений. Учитывая, что реклама в Facebook позволяет устанавливать демографические критерии, она может оказать существенную помощь в проверке ваших гипотез о целевом рынке. Поскольку рекламные объявления, как правило, невелики по своему объему, в них бывает невозможно уместить ценностное предложение целиком. Вместо этого приходится ограничиваться коротким слоганом. Соответственно, данный вид тестирования будет наиболее полезен для оптимизации усилий по привлечению клиентов, а не для проверки соответствия продукта рынку.
Например, планируя создание сайта, помогающего людям в поиске работы, вы могли бы запустить три рекламные кампании, каждую со своим слоганом: «Мы подберем вам работу вашей мечты», «У нас самая большая база вакансий в любой точке мира» и «Мы предлагаем самый быстрый способ поиска вакансий». Затем вы могли бы сравнить количественные показатели переходов по ссылкам всех трех рекламный кампаний и определить, какая из них оказалась наиболее эффективной.
Маркетинговое A/B тестирование
A/B-тестирование, также известное как сплит-тестирование, представляет собой количественный метод, при котором вы тестируете два альтернативных проекта одновременно, чтобы сравнить их эффективность по ключевому показателю, такому, например, как коэффициент конверсии. Вы можете использовать A/B-тестирование для проверки различных редакций маркетинговых материалов, чтобы понять, какая из них работает лучше. Например, провести тестирование двух разных версий целевой страницы – с различающимися описаниями продукта, ценами, изображениями, цветовыми или другими элементами дизайна, а затем сравнить их коэффициенты конверсии. Вы также можете применить A/B тесты для большинства других маркетинговых материалов, размещаемых в Интернете: рекламных объявлений, видеороликов и почтовых рассылок.
В тестах могут участвовать более двух альтернатив. Например, вы можете провести A/B/C-тест с тремя версиями материалов. Правила проведения A/B-теста предусматривают, что тестирование всех участвующих в нем версий проводится параллельно, в одно и то же время, в равных условиях. Например, 50 % трафика направляется на версию A и столько же – на версию B. Менее желательно тестировать версии последовательно (100 % трафика на версию A, затем 100 % трафика на версию B). Тестируя альтернативные варианты одновременно, вы избегаете риска, что имевшиеся в разное время различия во внешних факторах приведут к искажению полученных результатов.
Часто после проведения нескольких A/B-тестов, направленных на оптимизацию какого-либо аспекта продукта, определяется наиболее эффективный вариант, который получает звание «чемпиона». Далее вы можете проводить периодическое тестирование вновь появляющихся альтернатив, сравнивая их результаты уже не между собой, а с показателями чемпиона. Важным аспектом в этом случае является статистическая значимость, которая определяется разницей в значениях сравниваемых показателей и в размере выборки. Существуют формулы и онлайн-инструменты, которые позволяют рассчитать статистический уровень достоверности для конкретного теста. Однако важно знать, что статистическая значимость всегда выше при наличии существенных различий величины показателей и большого размера выборки. Если размер выборки слишком мал, вы не добьетесь статистически значимых результатов. Если у вас есть два варианта с очень похожими значениями сравниваемых показателей, может потребоваться очень большой размер выборки, чтобы заметить статистически значимую разницу между ними.
Список наиболее популярных инструментов для проведения A/B тестирования включает в себя следующие сервисы: Optimizely, Unbounce, KISSmetrics, Visual Website Optimizer и Google Content Experiments (входит в состав Google Analytics). Эти инструменты позволяют выбрать для тестирования несколько альтернативных версий продукта, а затем случайным образом распределить между ними пользовательский трафик. Функционал этих сервисов дает возможность отслеживать интересующие вас действия посетителей, рассчитать коэффициент конверсии и получить результаты для каждого из тестируемых вариантов с указанием уровня статистической достоверности.
Мультивариантное тестирование похоже на A/B-тестирование, но подразумевает проверку разных версий элементов веб-страницы, а не всей страницы целиком. В этом случае каждый тестируемый элемент страницы является переменной. Допустим, при разработке целевой страницы у вас возникло три разных идеи относительно заголовка и три разных идеи основного изображения. При применении мультивариантного теста будут опробованы все девять возможных комбинаций разных заголовков и изображений, чтобы определить, какая из них работает наиболее эффективно.
Краудфандинг
Краудфандинговые платформы, такие как Kickstarter и Indiegogo, могут стать отличным способом проверить, готовы ли потребители платить за ваш продукт, а также оценить этот спрос в количественном выражении. Названные платформы обеспечивают разработчикам, которые хотят производить и продавать свой продукт, возможность продвигать его и получать деньги от клиентов, желающих приобрести его сразу после выхода. Вы можете установить минимальный порог суммы собираемых средств, взяв на себя обязательство по созданию продукта только в том случае, если установленный порог будет превышен. Такой подход, при котором клиенты платят вам еще до того, как вы приступите к разработке, соответствует принципам бережливого производства, поскольку он устраняет неопределенность в отношении того, нужен ли ваш продукт потребителям.
Часы Pebble Watch – это одна из историй успеха, имевших место на платформе Kickstarter. Сначала основатель данного стартапа, Эрик Мигиковский, попытался привлечь финансирование со стороны венчурных компаний через инкубатор Y Combinator. Однако попытка оказалась безуспешной. Тогда он запустил кампанию по сбору средств на Kickstarter с первоначальной целью финансирования в размере 100000$. Подписчики получали право приобрести часы Pebble Watch по цене 115$ сразу после их выпуска, фактически получая за предзаказ скидку от полной цены в 150$. Проект собрал первоначально установленную сумму за два часа, и от желающих сделать взнос не было отбоя. В итоге Pebble прекратила сбор средств на Kickstarter после того, как более 68 тыс. человек внесли в фонд реализации этого проекта более 10 млн $.
Краудфандинговая платформа Kickstarter стала новым привлекательным каналом финансирования стартапов. Проект, предусматривающий производство гарнитур виртуальной реальности Oculus Rift, стартовал с установленной первоначальной целью сбора средств в размере 250000$ в августе 2012 года. За месяц было собрано чуть менее 2,5 млн $, что почти в 10 раз превышало целевую сумму. Менее чем через два года Facebook приобрела Oculus Rift за 2 млрд $.
Предприниматели, вынашивающие идею стартапа, могут использовать краудфандинг как способ снизить финансовые риски, прежде чем решиться на реализацию своего проекта. Краудфандинг особенно хорошо подходит для продажи потребительских товаров, поскольку он обеспечивает прямой канал для электронных продаж. Однако, поскольку реальный продукт, который потенциальные покупатели могли бы увидеть своими глазами, пощупать и опробовать, в данном случае отсутствует, существенно возрастает роль подробного описания как ценностного предложения, так и его преимуществ перед конкурентами. Поэтому многие стартапы снимают высококачественные видеоролики и создают обширные разделы с ответами на часто задаваемые вопросы о своем будущем продукте. Если вы решите воспользоваться краудфандингом для сбора средств, не стоит забывать о возможности донесения до потенциальных клиентов информации о вашем продукте и другими действенными способами, например в социальных сетях.
Сайты краудфандинговых платформ могут стать отличным способом установить контакт с первыми пользователями вашего продукта. Скорее всего, не составит особого труда вовлечь их в обсуждение имеющихся у них потребностей и предпочтений. Кроме того, они могут стать источником хороших идей по улучшению вашего продукта. Веб-страницы, посвященные краудфандинговым проектам, часто становятся активной точкой коммуникации между стартапом и его клиентами.
Качественные продуктовые MVP-тесты
Мы рассмотрели маркетинговые MVP-тесты, которые позволяют убедиться в том, что ваши сообщения находят отклик у потребителей, а также количественно оценить ожидания с помощью таких маркетинговых показателей, как коэффициент конверсии. В свою очередь, продуктовые тесты позволяют убедиться в том, что клиенты видят ценности вашего реального продукта. При разработке нового продукта, переработке дизайна или добавлении очередной функции качественные продуктовые тесты являются наиболее подходящим способом оценить и улучшить соответствие продукта рынку. Есть два принципиально различающихся момента для проведения качественного продуктового тестирования: до того, как вы представите свою разработку, и после появления самого продукта. И в том и в другом случае вы получаете полезные результаты.
Вы можете протестировать дизайн продукта на пользователях еще до начала разработки реально работающей версии. Обычно процесс разработки продукта включает в себя создание вайрфреймов, макетов и интерактивных прототипов – все это дает представление о вашем будущем «детище», не являясь при этом самим продуктом. Будет разумно протестировать предполагаемый дизайн до того, как вы приступите к непосредственному написанию программного кода для своего продукта, поскольку это позволит сократить объем отходов. Обычно вносить изменения в проекты получается намного быстрее и дешевле, чем корректировать уже написанный программный код. Тестируемые элементы дизайна могут различаться по степени точности, то есть по тому, насколько достоверно и близко они отражают реальный продукт. К этой теме мы вернемся чуть позже.
После создания продукта вы, опять же, сможете протестировать его на пользователях – преимущество этого момента заключается в том, что точность результатов такого тестирования составляет все 100 %. Возможно, вы при этом узнаете то, чего не смогли заметить на этапе тестирования артефактов дизайна. Например, во время разработки вы могли получить отзывы о макете веб-страницы, о том, насколько доходчиво изложена информация и привлекателен визуальный дизайн. Однако вы не заметили бы до момента реализации продукта, что веб-страница загружается очень медленно или того, что она не работает должным образом в определенном браузере. Тестирование готового продукта в реальных условиях не обязательно должно быть сопряжено с негативными последствиями; однако, если вы откладываете его до того момента, когда продукт будет запущен в эксплуатацию, вы точно очень сильно рискуете. Причем, этот риск ничем не оправдан и должен быть снижен путем демонстрации результатов проектирования еще на ранних стадиях процесса разработки продукта. Это позволит гарантировать, что клиенты в итоге оценят его должным образом.
Вы можете показать клиентам различные проектные артефакты, чтобы получить от них своевременную обратную связь. На Рисунке 7.3 тестируемые артефакты классифицированы по степени их точности (на горизонтальной оси) и уровню интерактивности (на вертикальной оси). Напомню, что, говоря о точности, мы подразумеваем, насколько артефакт похож на конечный продукт, в то время как интерактивность означает доступный пользователю уровень взаимодействия с артефактом по сравнению с полноценно работающим продуктом.
Рисунок 7.3. Проектные артефакты, распределенные по степени их точности и интерактивности
Обратите внимание на Рисунок 7.4, который иллюстрирует различия между низкой и высокой точностью артефактов проекта. Оба представленных на рисунке результата проектирования относятся к одному и тому же приложению для iOS (источник: https://itunes.apple.com/us/app/pointedlysimple-score-keeper/id933257819). Это приложение, созданное талантливым UX-дизайнером Беном Норрисом, позволяет упростить процесс подсчета очков во время различных настольных игр (например, в Scrabble), заменяя использование для этой цели ручки и бумаги. В левой части рисунка показан вайрфрейм низкой точности. Он не использует каких-либо цветов (сделан в оттенках серого) и показывает только расположение элементов экрана без детализации визуального оформления. Высокоточный макет в правой части рисунка выглядит гораздо более похожим на реальный продукт (несмотря на то что его цветное изображение в печатной версии этой книги также представлено в оттенках серого). Элементам пользовательского интерфейса здесь уже придан близкий к реальному дизайн, использующий определенные цвета, шрифты и графику.
Рисунок 7.4. Вайрфрейм низкой точности в сравнении с высокоточным макетом
Эскизы
В левом нижнем углу Рисунка 7.3 вы можете видеть проектные артефакты, обозначенные как «Эскизы», которые характеризуются наименьшей точностью и наименьшей интерактивностью. Создание эскиза – отличный способ начать визуализировать идеи, особенно если вам нужно обсудить их с товарищами по команде и другими внутренними заинтересованными сторонами. Эскиз на доске или бумаге позволяет вносить в проект быстрые правки. Я активный сторонник использования доски для рисования, особенно на ранней стадии проектирования. На самом деле, данный метод вполне может являться идеальным инструментом бережливого производства, поскольку позволяет участникам команды осуществлять быстрые итерации своих идей. Однако, какими бы полезными ни были эскизы для внутреннего использования, слишком низкая точность не позволяет использовать их для получения обратной связи от пользователей (именно по этой причине они отсутствуют в представленной на Рисунке 7.2 матрице MVP-тестов).
Вайрфреймы
Следующим по степени точности артефактом проектирования является вайрфрейм, который с низкой или средней точностью дает представление о компонентах продукта и об их местоположении. Вайрфреймы – это не «совпадающие до пикселя» отображения; скорее, они показывают относительные размеры и расположение элементов. Обычно они не содержат каких-либо деталей визуального оформления, таких как цвета, картинки и шрифты. При их создании чаще используют оттенки серого и заполнители вместо реальных изображений, чтобы не отвлекать рецензентов элементами визуального дизайна. В некоторых случаях могут также использоваться заполнители вместо реального текста – например, «lorem ipsum»[14], – хотя это становится все менее распространенной практикой. Я рекомендую с самого начала использовать реальные текстовые элементы – даже если по содержанию это будет всего лишь черновик, – чтобы заранее выявить потенциальные проблемы с версткой.
Вайрфреймы могут быть нарисованы вручную, но обычно они представляют собой цифровые артефакты, созданные с помощью программных продуктов, предназначенных для проектирования либо специальных приложений для создания вайрфреймов. Чаще всего для создания графического дизайна используют такие приложения как Illustrator и Sketch. Приложения OmniGraffle и Visio представляют собой инструменты более общего назначения. Некоторые специалисты, не являющиеся профессиональными дизайнерами, создают вайрфреймы в PowerPoint или Keynote. Я рекомендую использовать более эффективные инструменты, специально разработанные для создания вайрфреймов, такие как Balsamiq, Axure и UXPin – для веб-продуктов.
Поскольку продукты для мобильных устройств – будь то нативные или интернет-приложения – как правило, имеют элементы пользовательского интерфейса, отличные от тех, которые используются для традиционных веб-приложений, появились специализированные инструменты для создания мобильных вайрфреймов. Дизайнерам, создающим вайрфреймы для мобильных приложений, я рекомендую такие инструменты, как Flinto и Marvel. Тем, кто не занимается дизайном, для создания мобильных вайрфреймов подойдут простые в использовании приложения POP и Dapp.
Новые и все более мощные инструменты для создания вайрфреймов появляются постоянно. Если вы давно не интересовались новинками в этой сфере, я настоятельно рекомендую это сделать. Я часто сталкивался с ситуациями, когда дизайнеры и менеджеры по продуктам упускают из виду важные вещи только потому, что продолжают цепляться за старый привычный инструмент, к которому они привыкли, и которым владеют в совершенстве. Очевидно, что производительность важна, и смена используемых инструментов требует дополнительных затрат времени. Но освоение нового инструмента может оказаться полезным, благодаря тем возможностям, которые он перед вами открывает и которые в итоге обеспечивают достижение еще более высокого уровня производительности.
Вот некоторые признаки, указывающие на то, что вам, вероятно, следует изучить современные инструменты для создания вайрфреймов:
• Вы рисуете основные элементы веб-страницы с нуля, используя формы и линии, вместо того чтобы воспользоваться библиотекой предопределенных виджетов.
• Создаваемые вами вайрфреймы не реагируют на «клики» и нажатия клавиш.
• Ваши вайрфреймы трудно «расшаривать» для использования другими людьми.
• Вы создаете вайрфреймы для мобильных устройств с помощью инструмента, который не оптимизирован под соответствующие экраны.
• Создание вайрфреймов занимает больше времени, чем вам хотелось бы.
• Вы вообще не создаете вайрфреймы.
Современные инструменты делают создание вайрфрейма настолько простым и доступным, что на самом деле не может быть никаких оправданий для отказа от их использования теми, кто занимается разработкой продуктов. Возможно, в вашей команде есть один или несколько дизайнеров, которым поручена именно эта часть работы, и все же умение быстро визуализировать идею, которой вы хотите поделиться с другими людьми – это очень ценный навык, который стоит освоить. Поэтому предлагаю вам поближе познакомиться с инструментами для создания вайрфреймов.
Общей особенностью современных инструментов для создания вайрфреймов является наличие библиотеки виджетов, содержащей наиболее распространенные элементы пользовательского интерфейса. Например, если вы хотите создать вайрфрейм приложения для iOS, вам не придется рисовать стандартные элементы управления iOS вручную – в библиотеке современного инструмента наверняка имеется набор общих элементов пользовательского интерфейса iOS.
Поскольку вайрфрейм обеспечивает представление пользовательского интерфейса, разработчики часто считают нужным добавить в него поясняющие комментарии. В них могут содержаться важные детали, такие как список опций, которые должны отображаться в выпадающем меню, ограничение количества символов, которые пользователь может вводить в определенное поле формы, или конкретная формулировка сообщения об ошибке. Такие аннотированные вайрфреймы могут служить мощными инструментами проектирования, содержащими большую часть спецификации продукта, необходимой для дальнейшей разработки. Очевидно, что версия вайрфрейма, предназначенная для показа пользователям, не должна отображать служебные комментарии.
Еще несколько лет назад вайрфреймы, как правило, были статичными, то есть не реагировали на клики мышью или нажатия клавиш. Но современные инструменты существенно упростили создание интерактивных вайрфреймов, которые позволяют объединить набор вайрфреймов отдельных веб-страниц в логическую цепочку с доступными пользователю возможностями навигации. Обычно для целей тестирования пользователю оказываются доступными лишь отдельные элементы пользовательского интерфейса – те, которые имеют непосредственное отношение к дизайну и к тому, что именно вы хотите протестировать. Такой пользовательский сценарий называется «счастливый путь». Он предполагает, что пользователь будет следовать только одной, заранее заготовленной для него цепочке перемещений, без возможности выбора альтернативных вариантов использования интерфейса.
На сегодняшний день кликабельные вайрфреймы, по сути, полностью вытеснили статичные формы. Тест статичного вайрфрейма требовал, чтобы пользователь в определенном месте говорил вам: «Я бы нажал вот на эту кнопку», – после чего вы показывали ему следующий статичный вайрфрейм. Интерактивные вайрфреймы создают для пользователя более захватывающий опыт, позволяя самостоятельно изучать ваш продукт и ориентироваться в нем. Кроме того, поскольку интерактивные вайрфреймы обычно тестируются на том же типе устройства, на котором будет использоваться готовый продукт (например, на компьютере, планшете или телефоне), пользовательский опыт оказывается еще более реалистичным.
Макеты
Как показано на Рисунке 7.3, следующим по степени точности артефактом проектирования являются макеты, которые гораздо больше похожи на конечный продукт, чем вайрфреймы. Макеты передают такие детали визуального дизайна, как цвета, шрифты и изображения. В некоторых случаях они должны «совпадать до пикселя» с конечным продуктом, однако необходимость в такой степени достоверности присутствует далеко не всегда. Макеты обычно создают с помощью приложений для графического дизайна, таких как Illustrator, Photoshop или Sketch.
Как и в случае с вайрфреймами, макеты могут быть статичными или интерактивными. С помощью приложений для графического дизайна обычно получают статичные файлы формата jpg, gif или png, которые по своей сути не является интерактивными. Чтобы создать набор интерактивных макетов, эти изображения объединяются с помощью другого приложения, которое позволяет создавать «горячие точки», при нажатии на которые происходит переход от одного макета к другому.
С этой задачей хорошо справляется веб-приложение InVision. Этот инструмент позволяет загружать изображения и связывать их воедино с помощью создания кликабельных горячих точек. Еще одним похожим по функционалу инструментом является приложение Balsamiq. При тестировании макетов также применяется сценарий «счастливый путь», когда пользователю доступны лишь некоторые элементы навигационного управления, не позволяющие отклониться от намеченного разработчиками маршрута. Как видите, интерактивные макеты и вайрфреймы похожи в том, что и те и другие позволяют осуществлять переходы между страницами, однако в случае с макетами то, что видит при этом пользователь, существенно больше похоже на конечный продукт. Именно потому, что интерактивные макеты выглядят максимально правдоподобно, они могут обеспечить очень ценную обратную связь со стороны пользователей. Некоторые команды, умеющие создавать качественные интерактивные макеты, начинают тестирование проектных артефактов на пользователях именно с этого уровня. Во многих случаях перед разработкой макетов они тоже создают вайрфреймы, но не показывают их пользователям.
Интерактивный прототип
На еще более высоком уровне с точки зрения степени точности и интерактивности находятся интерактивные прототипы. Слово «прототип», по сути, может быть использовано для описания любого интерактивного проектного артефакта, поскольку оно обозначает либо не полнофункциональный продукт, либо лишь точное изображение продукта.
Интерактивные прототипы включают в себя гораздо большее количество функционирующих элементов управления пользовательского интерфейса, нежели интерактивные макеты. Это могут быть выпадающие меню, эффекты наведения курсора, работающие формы ввода и аудио- или видеоплееры. Для создания интерактивных прототипов используются различные инструменты разработчика. Веб-прототипы обычно создаются с использованием HTML, CSS и JavaScript. Для быстрой разработки используются популярные интерфейсные фреймворки, такие как jQuery и Bootstrap. Прототипы также могут быть созданы с использованием Ruby on Rails или других фреймворков быстрой разработки, если вам требуется облегченный функционал на стороне сервера. Мощные инструменты, такие как Axure, которые умеют экспортировать прототип в HTML, CSS и JavaScript, позволяют создавать интерактивные прототипы без использования программного кода. Прототипы под операционные системы мобильных устройств, таких как iOS или Android, могут быть созданы в HTML или в машинном коде.
MVP-тесты: «Волшебник страны Оз» и «Консьерж»
Ни один из обсуждавшихся выше качественных продуктовых тестов не предусматривал проверку работы полнофункционального продукта или услуги. Такие варианты MVP-тестов, как «Волшебник страны Оз» и «Консьерж», позволяют фактически протестировать сам продукт или услугу в реальном времени. При этом весь функционал конечного продукта выполняется в ручном режиме. Такие методы малоэффективны и не рассчитаны на долгосрочное использование. Идея, лежащая в основе MVP-теста «Консьерж», заключается в активном личном взаимодействии с небольшим количеством пользователей с целью получить реальное представление о целевых клиентах, их потребностях и предпочтениях, а также о том, как адаптировать продукт для наиболее полного соответствия ожиданиям потенциальных потребителей. Такой подход помогает понять, что должен уметь делать продукт, еще до того, как вы приступите к его созданию. «Консьерж» больше подходит для тестирования услуг, особенно в тех случаях, которые требуют плотного взаимодействия с клиентом и его личного участия в процессе.
MVP-тест «Консьерж» на примере Airbnb
Например, сайт по аренде жилья Airbnb использовал MVP-консьержа для улучшения своего сервиса. В своем выступлении на фестивале South By Southwest (SXSW) директор по продуктам Джо Заде рассказал, как команда Airbnb выдвинула гипотезу о том, что объявления о сдаче недвижимости, которые сопровождаются профессионально сделанными фотографиями, могут принести больше прибыли. Для проверки этой гипотезы они вручную отбирали арендодателей, которым предлагали провести бесплатную профессиональную фотосъемку сдаваемых помещений. Затем компания нанимала фотографов по месту нахождения сдаваемого жилья. Проведя фотосессию, фотографы загружали сделанные снимки в Dropbox, а сотрудники Airbnb – опять же, вручную – подгружали их к соответствующим объявлениям на сайте. В итоге команда Airbnb убедилась в том, что их гипотеза верна: количество бронирований по объявлениям, к которым прилагались профессионально сделанные фотографии, в два-три раза превышало средний уровень.
После подтверждения гипотезы Airbnb автоматизировала большую часть ручных операций этого процесса. Теперь то, что во время проведения консьерж-теста делали люди, система бронирования Airbnb делает в автоматическом режиме: предлагает хозяевам жилья воспользоваться преимуществами профессиональной фотосъемки, назначает фотографов и подгружает сделанные снимки к соответствующим объявлениям. Таким образом, проведя предварительное тестирование и проверив свою гипотезу прежде, чем тратить на ее реализацию ценные ресурсы разработчиков, Airbnb снизила риск возможных потерь.
MVP-тест «Волшебник страны Оз» похож на описанный метод тестирования «Консьерж» в том смысле, что в течение некоторого – недолгого – времени определенные функции приложения выполняются вручную. При этом разница заключается в том, что пользователь не знает, что все, что он получает как результат работы тестируемого приложения, на самом деле выполняется людьми; в «Волшебнике страны Оз» происходящие действия оказываются скрыты от пользователя «за занавеской». Пользователь полагает, что имеет дело с настоящим «живым» продуктом. Цель тестирования состоит в том, чтобы вручную проверить все предусмотренные функции продукта, прежде чем тратить ресурсы на создание автоматизированного решения.
«Живой» продукт
Готовый MVP также может быть протестирован на пользователях. В идеале, на пути к готовому продукту вы должны были провести все необходимые качественные тесты его проектных артефактов. Только почувствовав уверенность в том, что в достаточной степени подтвердили соответствие продукта рынку, вы приступаете к созданию реального MVP. В главе 12 я расскажу, как создавать продукт с использованием методов Agile-разработки.
Даже если вы провели все необходимые тесты артефактов на этапах проектирования, хорошей идеей будет протестировать «живой» MVP после его создания. Между этапами проектирования и разработки часто происходят какие-нибудь изменения. Поскольку для «живого» продукта характерна максимально возможная точность, по результатам его тестирования вы можете узнать от пользователей что-то новое, чего не обнаружили во время проведения тестов с более низкой точностью. Например, вы можете проверить, как ваш веб-продукт на самом деле выглядит и ведет себя на экранах разных размеров и в различных браузерах.
Вы можете протестировать свой «живой» продукт как в модерируемом режиме, так и без непосредственного участия модератора. При модерируемом тестировании вы находитесь рядом с пользователем в тот момент, когда он использует продукт. Соответственно, немодерируемый вариант подразумевает, что пользователь остается с продуктом один на один (при этом все его действия фиксируются для последующего анализа). Модерируемое тестирование может проводиться как лично, так и удаленно с применением программного обеспечения, обеспечивающего возможность совместного использования экрана, такого как Skype, WebEx или join.me. Я расскажу об этом подробнее в главе 9.
Количественные продуктовые MVP-тесты
Как только у вас появится готовый продукт, которым воспользуется значительное число людей, вы сможете приступить к проведению количественных тестов. В отличие от качественных продуктовых тестов, когда вы получаете отзывы лишь от небольшого числа пользователей, количественные тесты обычно проводятся на больших объемах выборки, состоящей из реальных потребителей продукта.
Тесты «Фальшивая дверь» или «Страница 404» являются хорошим способом выяснить уровень спроса на новую функцию, которую вы планируете создать. Идея состоит в том, чтобы предложить пользователям ссылку или кнопку для перехода на страницу новой функции и, таким образом, на основе количества осуществленных переходов оценить ее востребованность (в %). Это позволяет понять, действительно ли клиентам нужна данная функция, прежде чем вы потратите ресурсы на ее создание. Поскольку на момент проведения теста самой функции еще не существует, при переходе по ссылке пользователи обычно попадают на веб-страницу, где размещена благодарность за проявленный интерес и сообщение о том, что функция еще не готова для использования. Вы также можете добавить на эту страницу специальную форму для заполнения, чтобы посетитель мог поделиться своим мнением о том, почему он считает эту функцию полезной.
Крайний вариант теста данного типа применяется теми разработчиками, кто не утруждает себя даже созданием простейшей целевой страницы, поскольку технически все попытки перехода по ссылке можно отслеживать и при отсутствии самой веб-страницы. В этом случае, кликнув на ссылку, пользователь попадает на «страницу 404» (где 404 – это код ошибки, означающий, что «страница не найдена»).
Компания Zynga, являющаяся разработчиком игр и имеющая большой опыт в области количественного тестирования продуктов, часто использует метод «фальшивых дверей». В своем выступлении на конференции Stanford Technology Ventures соучредитель Zynga, Марк Пинкус, рассказал, что его команда. собираясь протестировать новые игровые идеи, придумывает для каждой из них короткий питч из пяти слов. Затем эти питчи используются для создания рекламных ссылок, которые компания на некоторое время встраивает в свои уже существующие игры, чтобы увидеть, насколько большой интерес каждая из них вызвала у геймеров.
Стоит отметить необходимость постоянного отслеживания частоты и продолжительности применения метода «фальшивых дверей», чтобы не огорчать своих клиентов. Подобные «обманки» не должны использоваться в течение длительного срока. Не стоит допускать ситуаций, когда «фальшивая дверь» продолжает существовать уже после того, как вы достигли нужного вам размера статистической выборки.
Аналитика продукта и A/B-тесты
Аналитика продукта сама по себе не является тестом, но она может помочь в получении представления о том, как клиенты на самом деле используют продукт. Например, вы можете узнать, какие функции используют чаще всего и на каких веб-страницах проводят больше времени. При внедрении в продукт каких-либо усовершенствований вы можете отследить соответствующие изменения ключевых метрик продукта, чтобы проверить свои гипотезы. Аналитика продукта также является основой для A/B тестирования, поскольку аналитические методы используются для расчета метрик и сравнения результатов тестирования. Наиболее востребованными решениями для анализа продуктов являются такие инструменты, как Google Analytics, KISSmetrics, Mixpanel и Flurry.
A/B-тесты продукта или сплит-тесты используются для сравнения производительности двух альтернативных пользовательских интерфейсов (A и B), являющихся составной частью продукта. Например, предположим, что вы разработали новый процесс регистрации для своего веб-приложения, который, по вашему мнению, будет иметь более высокий процент завершений, чем прежний вариант. Вместо того чтобы просто заменить существующий процесс на новый, вы могли бы провести следующий A/B-тест: случайным образом разделить напополам поток пользовательского трафика, отправив одну половину на прежнюю версию страницы регистрации (A), а другую – на новую (B), после чего сравнить количество завершенных регистраций. Существует несколько популярных инструментов для проведения A/B-тестов: Optimizely, KISSmetrics, Visual Website Optimizer и Google Content Experiments (входит в состав Google Analytics).
Для маркетингового A/B-тестирования большинство компаний используют инструменты сторонних разработчиков. Однако, когда дело доходит до A/B-тестирования продукта, многие в конечном итоге предпочитают создавать и использовать собственные решения, чтобы добиться большей гибкости за счет совместимости программного кода. Одна из основных причин такого подхода заключается в том, что большинство инструментов для проведения A/B-тестирования написаны с использованием JavaScript, что позволяет им прекрасно взаимодействовать с клиентской частью продукта. Однако эти инструменты оказываются не столь полезны в тех случаях, когда необходимо протестировать продукт в его серверной части. Стоит отметить, что ведущие инструменты для проведения A/B-тестирования, такие как KISSmetrics, предлагают способы интеграции с вашей внутренней серверной A/B-платформой.
В целях проведения тестирования вовсе не обязательно равномерно распределять трафик между вариантами A и B. Пока вариант с меньшим количеством посетителей имеет количество посещений, удовлетворяющее требованиям статистической значимости, полученные результаты можно считать валидными. Многие компании постоянно экспериментируют, предлагая небольшим группам своих пользователей десятки или даже сотни альтернативных функций или дизайнов. Время от времени на сайтах Google, Amazon и других известных сервисов можно заметить появление новой кнопки, функции или дизайна. Если вы заметите, что изображение одного и того же приложения на вашем экране отличается от того, что другой пользователь видит на экране своего устройства, то, скорее всего, один из вас стал участником A/B-тестирования.
Аналитика и A/B-тестирование представляют собой мощные эмпирические инструменты, которые помогают понять поведение клиентов и соответствующим образом оптимизировать ваш продукт. Свободное владение этими инструментами обеспечивает быструю итерацию и отличает успешные команды разработчиков от других. Учитывая важность таких тем, как аналитика и A/B-тестирование, я вернусь к ним для более подробного рассмотрения в главах 13 и 14.
В этой главе были рассмотрены различные MVP-тесты, разъяснена разница между качественными и количественными, продуктовыми и маркетинговыми разновидностями тестов. После того как вы выбрали подходящий для вашего случая MVP-тест, необходимо разработать веб-страницу, экран или другой пользовательский интерфейс для проведения тестирования. Качественное проектирование пользовательского опыта имеет огромную важность, поскольку напрямую способствует успешности каждого из рассмотренных выше MVP-тестов. Поэтому, прежде чем перейти к теме непосредственного проведения тестирования MVP, я хочу посвятить отдельную главу принципам превосходного UX-дизайна, которые вы сможете применять при разработке артефактов для MVP-тестов.