Дэн Олсен – MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям (страница 26)

На сегодняшний день кликабельные вайрфреймы, по сути, полностью вытеснили статичные формы. Тест статичного вайрфрейма требовал, чтобы пользователь в определенном месте говорил вам: «Я бы нажал вот на эту кнопку», – после чего вы показывали ему следующий статичный вайрфрейм. Интерактивные вайрфреймы создают для пользователя более захватывающий опыт, позволяя самостоятельно изучать ваш продукт и ориентироваться в нем. Кроме того, поскольку интерактивные вайрфреймы обычно тестируются на том же типе устройства, на котором будет использоваться готовый продукт (например, на компьютере, планшете или телефоне), пользовательский опыт оказывается еще более реалистичным.

Макеты

Как показано на Рисунке 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.