Тестирование минимально жизнеспособного продукта (MVP) на пользователях (Шаг 6)
После того как вы применили принципы UX-дизайна и создали версию, которую можно рассматривать в качестве минимально жизнеспособного продукта (MVP), следующим шагом должно стать его тестирование на пользователях. Это – тот самый момент, когда шины нового автомобиля впервые соприкасаются с дорогой. Вы помните, что в главе 7 обсуждались два принципиально разных типа доступных вам тестов: количественный и качественный. В одном случае вы будете получать обратную связь от небольшого числа клиентов (качественные тесты), в другом – в вашем распоряжении окажутся агрегированные результаты с широким охватом респондентов (количественные тесты).
Количественные тесты, такие как A/B или лендинг-тесты, относительно просты в проведении и анализе, поскольку они не предусматривают общение с пользователями. В этом случае речь идет только о «сухих цифрах». Вы отслеживаете коэффициент конверсии (или другой интересующий вас показатель) для тестируемого MVP и смотрите, как он соотносится с целевым значением, представляющим успешный результат, или с соответствующими показателями продуктов-аналогов. При этом важно помнить об объеме статистической выборки, так как это напрямую влияет на степень достоверности получаемых результатов.
Эта глава посвящена тому, как следует проводить тестирование MVP на пользователях для достижения наилучших результатов. Отзывы пользователей обладают невероятной ценностью, потому что позволяют выявить то, о чем вы сами не знаете. В условиях максимально плотного рабочего соприкосновения со своим продуктом, трудно – часто невозможно – воспринимать его так, как это делает впервые столкнувшийся с ним, незаинтересованный в успехе пользователь. Поскольку вы знаете свой продукт лучше, чем кто-либо другой, у вас возникает так называемая «продуктовая слепота»: вы не замечаете проблемные зоны, которые легко выявит новый пользователь всего за несколько минут использования вашего любимого детища. Тестирование на пользователях – это лучшее лекарство от последствий «продуктовой слепоты».
Такая форма испытания продукта подтверждает или опровергает ключевые гипотезы, независимо от того, сформулированы ли они в явной форме или являются неформализованными предположениями. По причине все той же слепоты создателей по отношению к своему продукту первое же его тестирование на пользователях часто приводит к самым неожиданным результатам. Когда я провел первые интервью с пользователями продукта стартапа Box для облачного взаимодействия, члены команды его создателей узнали для себя так много нового, что, сразу оценив полезность тестирования на пользователях, захотели проводить его как можно чаще.
Проведение качественного тестирования на пользователях подразумевает, что вы показываете им результаты ваших разработок – вайрфреймы, макеты или прототипы – с целью получения соответствующих отзывов. Для успешной разработки и проведения таких тестов требуются определенные навыки. Я дам вам советы, как следует и как не следует проводить тестирование на пользователях, чтобы оно принесло максимальную пользу.
Сколько пользователей нужно привлечь к тестированию?
Для достижения наилучших результатов я рекомендую проводить интервью одновременно только с одним пользователем. Вы можете организовать и совместное тестирование, но обычно это приводит к искажению результатов из-за групповой динамики. Особенно отчетливо это негативное влияние проявляется в фокус-группах с количеством участников от 6 до 12 человек. Некоторые люди не склонны открыто высказывать свое мнение из-за страха быть осужденными или раскритикованными другими участниками. Один-два активных члена группы часто доминируют в дискуссии, заглушая другие голоса. Кроме этого, участники тестирования часто бывают подвержены групповому мышлению, когда все или большая часть группы под влиянием друг друга искусственным образом приходят к единому мнению, что также приводит к искажению получаемой информации.
Беседуя одновременно только с одним участником тестирования, вы избавляетесь от проблемы негативного группового влияния и имеете возможность провести более насыщенное и углубленное интервью. Пользователь в этой ситуации получает гарантии быть услышанным, что стимулирует его высказываться открыто и делиться своими истинными чувствами, особенно если беседа ведется с глазу на глаз. Исходя из моего опыта, чем больше наблюдателей присутствует при разговоре, тем сильнее некоторые пользователи беспокоятся о том, как их слова оценивают со стороны. Многие модераторы предпочитают, чтобы на интервью присутствовал их помощник, который берет на себя ведение записей. Такое распределение обязанностей позволяет модератору сосредоточиться на проведении теста, и это нормальная практика. Лично я предпочитаю делать заметки самостоятельно, чтобы быть уверенным в том, что все мои выводы будут зафиксированы, а также для обеспечения приватности при проведении интервью. Если участие наблюдателей по каким-то причинам все же необходимо, то хорошей альтернативой их личного присутствия в комнате переговоров является использование веб-камеры, которая транслирует сеанс тестирования на монитор, находящийся в другой комнате. Если тест проводится в дистанционном формате, то для наблюдения за действиями пользователя можно использовать функцию совместного использования экрана.
В своей практике я проводил пользовательское тестирование одновременно с двумя и тремя участниками. Это сработало прекрасно, потому что целью проведения тестирование было получение отзывов о печатных макетах; мы все сидели за одним столом и могли рассматривать представленные материалы, показывать что-то из увиденного друг другу. Вероятно, результат был бы не настолько хорош, если бы каждый пользователь рассматривал обсуждаемый дизайн на ноутбуке. В том случае я выбрал групповой вариант вместо проведения индивидуальных интервью, потому что мой клиент хотел получить результаты тестирования как можно скорее. Соответственно, групповой подход позволил мне пообщаться с большим количеством пользователей за один день. Иногда участники тестирования просто не являются на беседу; неявки – это суровая реальность исследований, проводимых с участием пользователей. Таким образом, еще одним преимуществом назначения на каждый сеанс встреч сразу с двумя или тремя пользователями являлось то, что я не терял времени даром, если кто-то из них не приходил на интервью.
Команды, работающие над созданием продукта, часто спрашивают: «Сколько пользователей необходимо привлечь для проведения тестирования?» Вопрос закономерный. Если вы опросите слишком мало людей, то рискуете не уловить все проблемные вопросы, на которые вам необходимо найти ответы. Кроме того, вы можете принять во внимание мнения, которые на самом деле не являются репрезентативными, но не осознавать, что это так. С другой стороны, общение со слишком большим количеством пользователей требует дополнительного времени и ресурсов. Вы можете перейти количественную грань, за которой последует уменьшение отдачи – когда вы будете продолжать выслушивать одни и те же отзывы, не получая никакой новой информации. Я обнаружил, что тестирование раундами с участием пяти-восьми пользователей обеспечивает хороший баланс. Такого количества участников тестов достаточно, чтобы выявить основные проблемы и закономерности мнений разных пользователей. После проведения каждого раунда тестирования вы должны пересматривать свой продукт или дизайнерский проект на основе полученных результатов. Затем измененный продукт следует вновь вынести на суд пользователей в рамках нового раунда тестирования, и так до тех пор, пока вы не убедитесь, что продукт соответствует рынку.
Повторюсь, вы должны быть готовы к тому, что некоторые пользователи не явятся для участия в тестировании. Средний показатель неявки обычно составляет около 10 %. Эту проблему можно решить, просто приглашая на одного участника больше запланированного количества. Например, если мне требуется опросить семь человек, то с целью подстраховаться на случай неявки я назначаю встречи с восемью участниками.
Очное, дистанционное и немодерируемое тестирование с участием пользователей
Вы можете проводить исследовательское тестирование продукта на пользователях как в очном, так и в онлайн формате. При очном опросе модератор и пользователь находятся в одной комнате. Дистанционное же тестирование подразумевает использование технологии совместного доступа к экрану или видеозаписи. При удаленном тестировании вы можете проводить как модерируемые, так и немодерируемые тесты. Модерация означает присутствие исследователя во время прохождения теста пользователем. Соответственно, немодерируемый вариант проведения теста предполагает отсутствие исследователя в то время, когда клиентам предоставляется для тестирования артефакт или продукт с приложением рекомендаций о том, что и как они должны делать. Процесс тестирования записывается для последующего просмотра командой разработчиков. В большинстве случаев с этой целью используются инструменты, позволяющие осуществлять запись с экрана монитора пользователя (чтобы затем увидеть, какие кнопки он нажимал во время использования продукта). Часто применяется и запись звука, чтобы зафиксировать комментарии пользователя. Некоторые инструменты позволяют снимать на видео лицо клиента в процессе тестирования (например, с помощью веб-камеры).
Из трех методов качественного тестирования – очного, дистанционного модерируемого и дистанционного немодерируемого – я бы рекомендовал выбирать по возможности очное тестирование. Находясь рядом с пользователем во время тестирования, вы можете собрать гораздо больше полезных данных, чем при дистанционном использовании общего экрана. При очном формате вы можете видеть не только экран, но и лицо пользователя, улавливать такие мелочи, как вздохи, выражения лица и другие едва уловимые сигналы. Вы замечаете, куда направлен взгляд пользователя. Кроме того, при личном общении вы, скорее всего, сможете наладить лучшее взаимопонимание, что обычно приводит к получению более качественных данных, поскольку в этом случае пользователь чувствует себя более комфортно.
Конечно, иногда бывает трудно найти целевых пользователей для проведения очного тестирования. В этом случае на выручку приходит дистанционный модерируемый формат, позволяющий связаться с участниками там, где они находятся. Хотя этот способ и не так хорош, как очное тестирование, вы все равно можете получить с его помощью ценную информацию. Чтобы видеть экран пользователя вам потребуется специальное приложение, такое как GoToMeeting, WebEx, Skype, Screenleap или join.me. Соответственно, вы должны быть готовы столкнуться с техническими трудностями. Для вас не должно стать сюрпризом, что, в тот момент, когда вы будете готовы начать удаленный сеанс, выяснится, что клиенты не установили программное обеспечение, необходимое для предоставления доступа к своему экрану, или им нужна помощь в его настройке. Кроме того, приложение, обеспечивающее совместное использования экрана, может мешать тестированию, например внося путаницу в действия пользователей или искажая размеры элементов дизайна продукта. Помехами могут стать также плохое качество связи, приводящее к задержкам отображения на вашем экране действий пользователя, и использование брандмауэров. Однако, если не принимать во внимание возможные технические трудности, дистанционное тестирование с модерацией может снабдить вас большим объемом ценной информации от пользователей.
Третий способ – немодерируемое дистанционное тестирование – проводится с помощью таких сервисов, как UserTesting или Validately. Они позволяют обеспечить доступ клиентов к артефактам проектирования и фиксируют их действия. Многие из таких сервисов, помимо технического решения, готовы предложить услуги по формированию группы пользователей для участия в тестировании вашего продукта. Одним из преимуществ такого подхода является более быстрое получение результатов: вам не приходится тратить время на поиски и сборы пользователей; несколько участников могут проходить тестирование одновременно, не будучи зависимы от доступности модератора. Однако в этом случае вы не находитесь рядом, а значит, не можете наблюдать за пользователем по ходу выполнения теста. Поскольку в этом случае пользователь следует письменным инструкциям, вам приходится тратить больше времени на разработку процесса тестирования и подробных указаний по прохождению его этапов. В таких случаях рекомендуется провести пилотный тест с одним или двумя участниками, прежде чем запускать тестирование на большой группе пользователей. Кроме того, отсутствие модератора означает, что он не сможет задавать попутные вопросы типа «А почему вы нажали эту кнопку?». Вы должны заранее подготовить полный список вопросов, на которые хотели бы получить ответы, из-за чего придется уделить большее внимание их формулировкам по сравнению с модерируемым вариантом тестирования.
Функционал большинства инструментов, применяемых при проведении немодерируемого дистанционного тестирования, ограничивается записью происходящего на экране пользователя с фиксацией движений мыши и нажатий клавиш. При том что запись с экрана пользователя, безусловно, полезна для исследования, прослушивание исходящего от пользователя голосового сопровождения существенно увеличивает ценность полученного материала. Некоторые инструменты позволяют делать в том числе видеозапись лица пользователя. Другие специализированные приложения вовсе не делают никаких видеозаписей (даже экрана), а просто фиксируют нажатия клавиш и рассчитывают процент «кликабельности». Такого рода количественная информация тоже будет полезна для последующего анализа, но, когда ваша цель состоит в тестировании продукта на соответствие рынку без присутствия модератора, весьма желательно получить как запись экрана, так и аудиозапись комментариев пользователя. Большинство современных приложений для дистанционного тестирования предоставляют такие возможности.
Одним из преимуществ немодерируемого тестирования является отсутствие риска влияния модератора на результаты. Действительно, в этом случае клиенты оценивают продукт на основании полностью самостоятельного его использования – то есть в условиях, максимально приближенных к реальной ситуации. Замечено, что большинство участников тестирования в присутствии модератора проявляют большее усердие при выполнении тестов.
Итак, какой же метод тестирования вы должны выбрать? Когда вы только начинаете проверку своего MVP, модерируемое тестирование будет лучшим выбором, поскольку оно позволяет задавать вопросы и получать исчерпывающие отзывы от пользователей. Как я уже подчеркивал, очное тестирование подходит идеально, если удается собрать целевых пользователей. В противном случае на этом этапе следует использовать дистанционное модерируемое тестирование. Когда вы продвинетесь дальше и почувствуете большую уверенность в своем MVP, немодерируемое тестирование может стать полезным инструментом в дополнение к модерируемому, поскольку оно занимает меньше времени и обходится дешевле. По этим же причинам немодерируемое тестирование является хорошим вариантом, если у вас нет ресурсов для проведения тестов с участием модератора.
Как отобрать для тестирования целевых потребителей
Конечно, вы хотите быть уверены в том, что пользователи, на которых вы тестируете свой продукт, являются представителями целевой аудитории. В противном случае полученная обратная связь может вас дезориентировать. Для отбора участников тестирования используют скрининг – некое подобие анкеты, набор вопросов, которые вы задаете кандидатам. Например, если для вашего исследования требуются мнения молодых мужчин, при отборе вы будете задавать вопросы о возрасте и поле. При этом для каждого вопроса вы подготавливаете несколько вариантов ответов и решаете, какие из них указывают на соответствие респондента вашим требованиям, а какие исключают его из числа представителей целевой аудитории. В Главе 3 обсуждались различные типы атрибутов, которые могут использоваться для идентификации целевого потребителя.
Как правило, в дополнение к демографическим поведенческие атрибуты имеют не менее важное значение. Например, если вам для тестирования требуются заядлые любители видеоигр, логично было бы спрашивать респондентов: «Играете ли вы в видеоигры?» – отфильтровывая тех, кто выбрал ответ «нет». Затем вы могли бы спросить ответивших «да»: «Сколько часов в неделю вы обычно играете в видеоигры?» При этом респондентам предлагалось бы сделать выбор из списка возможных вариантов ответов. Например таких: «менее пяти часов в неделю», «от 5 до 10 часов в неделю», «от 10 до 20 часов в неделю», «от 20 до 30 часов в неделю» и, наконец, «более 30 часов в неделю». Вы можете решить для себя, что геймерами вы признаете тех, кто играет не менее 20 часов в неделю. Соответственно, в список участников вашего тестирования попадут только те, кто выбрал какой-то из двух последних вариантов ответа.
Психографические атрибуты – мнения и чувства пользователей – также могут быть полезны для скрининга. При отборе все той же целевой аудитории одним из возможных психографических вопросов мог бы быть такой: «Считаете ли вы себя заядлым геймером?» Или вы могли бы спросить: «Насколько вам нравится играть в видеоигры?» – и предложить цифровую шкалу для ответа.
При подготовке вопросов для отбора участников тестирования следует опираться на заранее созданных вами персонажей представителей целевой аудитории. Как и в других рассматриваемых аспектах, вопросы для отбора являются гипотезами, которые подлежат проверке и итеративному уточнению. Если при проведении первого раунда тестов вы заметили, что используемый набор проверочных вопросов не позволил привлечь для тестирования целевых клиентов, необходимо соответствующим образом изменить список вопросов для отбора участников следующего раунда тестов.
Часто после первых тестов вы обнаруживаете дополнительные критерии для добавления в свой скринер. Например, предположим, что у нас есть приложение для управления портфелем ценных бумаг, ориентированное на инвесторов. Тогда первый фильтр может состоять из вопросов о частоте сделок и стоимости инвестиционного портфеля респондента. Однако по итогам первого раунда тестирования мы обнаружили, что существует два различных типа инвесторов: те, которые предпочитают самостоятельно принимать инвестиционные решения, и те, кто не прочь делегировать эту задачу профессиональному консультанту. Наше ценностное предложение находит отклик у первой группы, но совершенно не привлекательно для второй группы. В таком случае для отбора участников последующих раундов тестирования будет уместно добавить еще один фильтр, позволяющий выявлять самостоятельных инвесторов и отсеивать остальных. Соответствующие изменения должны быть внесены и в персонажный профиль нашего целевого пользователя.
Как только при помощи скрининга вы смогли отобрать клиентов, от которых хотели бы получить обратную связь, следующим шагом станет их привлечение. Возможно, это окажется наиболее сложной задачей. Те компании, которые в целях улучшения своего продукта довольно часто проводят тестирование на пользователях, находятся на постоянной связи со своими целевыми клиентами. В противном случае, за ними придется побегать.
Один из способов заключается в привлечении местных пользователей вашего продукта путем размещения онлайн-объявлений на Craigslist, TaskRabbit и им подобных веб-сайтах. Рекомендуется включать в объявление ссылку на онлайн-опрос, размещенный на SurveyMonkey, Google Forms или других опросных сайтах, содержащий подготовленные вами вопросы для фильтрации участников. Количество откликов может сильно варьироваться в зависимости от места публикации объявления и размера предлагаемого вознаграждения.
Если количество откликов вас не устраивает, можно прибегнуть к практике дистанционного тестирования, которое позволяет выйти за пределы местного рынка и привлечь любого онлайн-пользователя. Некоторые компании используют Mechanical Turk от Amazon (MTurk) в качестве инструмента для набора участников дистанционного тестирования. Там есть несколько сервисов, которые упрощают эту задачу. Многие приложения для дистанционного тестирования, такие как UserTesting, показывают профили пользователей, доступных для участия в тестировании. При этом объем доступной информации о потенциальных участниках может различаться. Некоторые сервисы предоставляют лишь общие данные, такие как пол, возраст, статус занятости и так далее; в то время как другие позволяют вам задавать пользователям свои собственные вопросы. При выборе приложения для удаленного тестирования убедитесь, что данный сервис предоставляет вам достаточную свободу в выборе задаваемых вопросов. Получение отзывов от клиентов, которые не относятся к целевому рынку – это пустая трата времени и денег, которая к тому же может увести вас в неверном направлении.
Задача достучаться до целевых клиентов может оказаться еще более сложной, если они не являются потребителями вашего продукта. Например, если вы только собираетесь заинтересовать своим программным решением руководителей отделов маркетинга или врачей. В этом случае одним из креативных способов привлечения является посещение конференций, форумов или других мероприятий, где соответствующие вашим критериям люди собираются вместе. У одного из моих клиентов как-то появилась идея создания продукта, связанного с торговлей углеродными компенсаторами. Изначально он планировал создать соответствующее веб-приложение, на что пришлось бы потратить много времени и денег. Вместо этого я посоветовал ему разместить минимально жизнеспособный продукт на Kickstarter, чтобы проверить ценностное предложение, прежде чем тратить деньги на кодирование полноценного веб-приложения. Он согласился и отправился на конференцию по альтернативной энергетике, прихватив с собой iPad. Общаясь там с посетителями, он выявлял тех, кто относится к целевой аудитории его продукта, и показывал им свою страницу на Kickstarter. Так за короткий промежуток времени ему удалось собрать множество ценных отзывов.
Посещение подобных мероприятий может быть хорошим способом получения концентрированной обратной связи. К сожалению, подходящие события, могут происходить поблизости от вас недостаточно часто, чтобы вы могли в приемлемые сроки провести итеративное тестирование. В этом случае придется вернуться к идее использования приложения для дистанционного тестирования, позволяющего производить частый и быстрый набор пользователей.
Существуют также компании, постоянно занимающиеся исследованием потребителей. Многие из них имеют постоянную аудиторию, из которой они могут набирать кандидатов для участия в очном тестировании. Такие компании часто предлагают комплексные услуги, которые включают в себя предоставление средств тестирования и модератора, но обычно вы можете просто заплатить им за подбор участников тестирования по указанным критериям. Цена за каждого респондента может варьироваться, но обычно составляет от 75 до 150$. Если ваши целевые клиенты относительно малочисленны и высоко ценят свое время – скажем, кардиохирурги или руководители компаний, – их привлечение может обойтись намного дороже или просто оказаться невозможным. По моему опыту, обращение в исследовательские компании – отличный способ привлечь местных пользователей для участия в очном тестировании. Главным недостатком является стоимость. Но получение ценной обратной связи часто с лихвой компенсирует затраты, особенно если вы хорошо поработали при подготовке скрининга и провели удачное тестирование.
Как избежать ловушки планирования
Довольно часто я сталкиваюсь с тем, что многие компании, которые хотят проводить тестирование на пользователях, испытывают трудности с логистикой планирования. Команды, работающие над продуктом, большую часть своего времени трудятся, не поднимая головы, над определением ценностного предложения, написанием пользовательских историй и разработкой вайрфреймов. Когда они оказываются готовы протестировать результат своего труда на пользователях, они, наконец, отрываются от созидательной работы и пытаются на скорую руку собрать пользователей. Однако набрать подходящих пользователей по щелчку пальцев обычно не получается. К этому моменту команда разработчиков, скорее всего, еще даже не задумывалась о скрининге или сценарии для тестирования. Если у команды нет специального сотрудника, занимающегося отбором и привлечением участников тестирования, эти обязанности часто ложатся на плечи продакт-менеджера или дизайнера. При этом у обоих и без того полно работы. Может пройти неделя или две (или больше), прежде чем все будет готово для проведения первого раунда тестирования. За это время команда, которая, скорее всего, находится под жестким прессингом со стороны требующего результатов руководства, поддается давлению и приступает к разработке высокоточного дизайна или даже написанию программного кода. Таким образом, к моменту получения результатов тестирования на пользователях, возможность безболезненного внесения в продукт каких-либо изменений будет упущена. После завершения одного или двух этапов разработки история с запаздывающим тестированием повторяется. Это в итоге ведет к полному разочарованию – сокращению итераций или даже полному отказу от проведения тестов на пользователях.
Как должна поступать команда разработчиков, придерживающаяся принципов бережливого производства?
Лучший способ выбраться из этой ловушки – просто запланировать сбор пользователей для тестирования на регулярной основе. Например, запланировать интервью с тремя пользователями на вторую половину дня по вторникам или с пятью пользователями на каждую вторую среду. Я называю это планированием «вслепую», поскольку при составлении такого расписания вы обычно еще не знаете, что именно придется тестировать. Зато при таком подходе, вместо потери времени на отбор и привлечение пользователей лишь после того, как продукт или артефакт созреют для тестирования, команда получает уверенность, что его участники будут доступны именно тогда, когда это потребуется. Это устраняет зависимость между сроками готовности продукта и пользователями для его тестирования и обеспечивает гораздо более высокую частоту итераций при существенно меньших затратах. Я также рекомендую командам разработчиков обзавестись специально выделенными сотрудниками, которые могли бы заняться отбором и привлечением пользователей для участия в тестировании. Эту работу можно было бы поручить младшему персоналу или стажерам, а также специалистам, нанятым на неполный день по договору подряда. По сути, для выполнения стоящих перед ними задач нужен просто хорошо написанный скринер.
Тестирование на посетителях Starbucks
Если вы сторонник партизанской тактики, вам подойдет вариант, который я называю «тестированием на посетителях Starbucks». Суть данного метода заключается в том, что вы проводите тестирование, набирая для него участников прямо в кафе. Его основными преимуществами являются низкая стоимость и оперативность. Главный же недостаток такого тестирования заключается в том, что в этом случае вы не можете контролировать принадлежность его участников к целевой аудитории. Конечно, если ваш продукт так же популярен, как, скажем, Google или Facebook, вполне вероятно, что, даже не выходя из кафе, вы сможете найти достаточное число представителей целевого рынка. Однако такой подход, скорее всего, не сработает, если речь идет о тестировании более специфического продукта. Вы можете лишь попытаться провести визуальный отбор потенциальных потребителей на основании их внешнего вида (например, по полу, примерному возрасту, стилю одежды, и т. п.).
Будьте готовы к изрядному количеству отказов; многим людям не нравится, когда к ним обращаются незнакомцы, или же они могут быть слишком заняты. Лично я считаю хорошей альтернативой кафе торговые центры, поскольку там люди кажутся менее занятыми и более открытыми. При этом решающее значение для получения согласия на участие в тестировании от незнакомого вам человека имеет ваша вступительная фраза. Возьмите за правило быстро информировать людей о том, что вам от них требуется, и какую компенсацию вы можете предложить за потраченное ими время. Например, вы можете использовать следующую фразу: «Здравствуйте, не найдется ли у вас 10 минут, чтобы поделиться своим отзывом о новом веб-сайте в обмен на карточку Starbucks стоимостью 25$?»
Оплата участия в тестировании
Кстати, об оплате. Сколько вы должны заплатить участникам тестирования за потраченное ими время? Обычно диапазон размера вознаграждения составляет от 75 до 125$ за час, но многое зависит от того, кто является вашими целевыми клиентами, и сколько стоит их время. Интервью с кардиохирургом, вероятно, обойдется вам гораздо дороже названных выше сумм, в то время как беседа со старшеклассником стоила бы гораздо дешевле. Многие изобретательные стартапы умудряются нанимать тестировщиков без выплаты какой-либо денежной компенсации, просто находя людей, проявляющих повышенный интерес к их продукту. Я, как и многие другие разработчики, использовал в качестве «заманушного пряника» эксклюзивный доступ к бета-версии продукта. Если у вашей компании есть возможность использовать в качестве вознаграждения свои «мерчи» (например, футболки, толстовки с капюшоном или спортивные куртки с вашей символикой), это тоже может сработать.
Для непосредственной оплаты труда тестировщиков существует несколько подходящих вариантов. Например, довольно удобным для обеих сторон средством платежа являются подарочные карты, поскольку их легко купить и использовать. При этом универсальная подарочная карта, такая как Visa или MasterCard, более привлекательна, чем сертификат конкретного магазина. Но, если вы проводите тестирование пользователей в Starbucks, то подарочная карта этого кафе вполне подойдет. Безусловно, прекрасно работает оплата наличными, однако получить их со счета компании может быть непросто из-за ограничений, относящихся к правилам ведения бухгалтерского учета. Если вы проводите тестирование на пользователях, уже являющихся вашими клиентами, то хорошей альтернативой денежной выплате может быть предоставление им скидки на оплату ваших услуг или будущих покупок.
Тестирование на пользователях в компании Intuit
Впервые я познакомился с пользовательским тестированием во время работы в компании Intuit, которая являлась пионером в этой области. После запуска каждой новой версии приложения Quicken менеджеры по продуктам проводили акцию «Проводи клиента домой». Они находились в магазине, где продавалось приложение, и когда кто-то покупал этот продукт, спрашивали разрешение проводить его домой и понаблюдать, как он устанавливает и использует Quicken. Возможность наблюдения за тем, как клиенты используют продукт в реальных условиях, обеспечила нас большим объемом ценной информации. Это было то, что сейчас называют «контекстуальным» или «этнографическим» методами исследования пользовательского опыта, которые подразумевают наблюдение за пользователями продукта в привычных для них условиях.
Впрочем, далеко не всегда является возможным или экономически оправданным идти туда, где находятся ваши пользователи; иногда имеет смысл, чтобы они сами приходили к вам. Компания Intuit создала ультрасовременную лабораторию юзабилити с несколькими помещениями для проведения тестов. Мы приглашали пользователей в эту лабораторию для проведения тестирования программного обеспечения по ходу его разработки. Модератор оставался в специальной комнате один на один с участником тестирования, но мы имели возможность наблюдать за происходящим благодаря встроенному в стену одностороннему зеркалу. Установленные в лаборатории камеры были направлены на экран компьютера, а также на лицо пользователя и передавали видеоизображение на мониторы в задней комнате.
Тестирование на пользователях по методу «Рамэн»
Лаборатория юзабилити Intuit производила неизгладимое впечатление, и мне как менеджеру по продуктам компании было интересно пользоваться предоставляемыми ей возможностями. Но на самом деле для проведения тестирования на пользователях иметь такое мощное оснащение вовсе не обязательно. С тех пор как я покинул Intuit, я работал во многих стартапах, которым обычно приходится быть гораздо более разборчивыми в своих расходах из-за ограниченности финансовых ресурсов. Я помогал им в проведении того, что я называю тестирование на пользователях по методу «Рамэн»[18]. Этот метод исключает все, кроме самых необходимых составляющих пользовательского тестирования. Вместо выделенного и специально подготовленного помещения вы используете конференц-зал в своем офисе. Вместо того чтобы нанимать профессионального модератора, кто-то из вашей команды (обычно это менеджер по продукту или дизайнер) берет на себя его функции. Если вы никогда не проводили тестирование, я рекомендую обязательно попробовать. Мой опыт подсказывает, что многие люди, которых изначально пугает идея примерить на себя роль модератора пользовательского тестирования, на самом деле просто нуждаются в небольшом поощрении. Это не ракетостроение – как и в большинстве других сфер, нужна лишь некоторая практика, чтобы в достаточной степени освоить этот навык. Однако необходимо учесть тот факт, что пытаться модерировать и одновременно делать заметки может оказаться непростой задачей, поэтому я рекомендую разделить эти обязанности между двумя сотрудниками.
Если это возможно, попросите участников захватить на тестирование ноутбук или другое устройство, которое они используют для работы с продуктом. Как правило, это дает намного лучший результат, чем в том случае, когда клиенты вынуждены использовать во время тестирования устройство, с которым они не знакомы. Я не раз наблюдал, как различия в операционной системе (Windows или Mac), клавиатуре, мыши или браузере заставляют пользователей нервничать и тем самым мешают тестированию. Напротив, весьма приятно наблюдать за тем, как клиенты используют ваш продукт на тех устройствах, которыми они пользуются дома или на работе. При этом вы даже можете выяснить для себя что-то новое, с чем не сталкивались в ходе внутренних обсуждений и тестов.
Я рекомендую модератору и записывающему во время сеанса сидеть за столом рядом с пользователем (по бокам от него). Это позволяет вам смотреть в одну сторону и видеть все происходящее на экране. Кроме того, в этом случае вы сможете наблюдать за его мимикой и улавливать другие малозаметные сигналы.
Я призываю всех членов команды разработчиков быть наблюдателями во время проведения тестов на пользователях. Гораздо эффективнее, когда свидетелями обратной связи одновременно являются сразу несколько человек. Пока вы находитесь в процессе поиска рыночного соответствия вашего продукта, пространства проблем и решений могут быть настолько размытыми, что гипотезы и мнения членов команды будут существенно различаться. Совместное наблюдение за процессом тестирования помогает достичь общего понимания. При этом вы не должны напрягать участников тестирования присутствием большого количества людей в одном помещении. Не менее важно, чтобы все присутствующие, кроме модератора и пользователя, сохраняли молчание и не нарушали процедуру тестирования. Если желающих наблюдать достаточно много, вы можете настроить веб-камеру, которая будет транслировать видеоизображение на монитор, установленный в отдельной комнате. Если размеры помещения, где проводится тестирование, позволяют это сделать, вы можете подключить проектор к ноутбуку пользователя и транслировать изображение на большой экран. При этом наблюдатели должны находиться за пределами поля зрения пользователя, но достаточно близко, чтобы слышать его комментарии.
Некоторые члены команды могут выражать желание посмотреть процесс тестирования не в режиме реального времени, а в записи. За свою карьеру я участвовал в огромном количестве тестирований, но никогда не видел, чтобы кто-то действительно просматривал такие записи. Если кто-то из членов вашей команды недостаточно мотивирован, чтобы присутствовать на тестировании лично, у него не появится достаточной мотивации и для того, чтобы потратить время на просмотр записи. Кроме того, многим участникам тестирования не нравится сама идея стать героем хранящейся где-то видеозаписи. Так что, если ваша команда видит в этом реальную необходимость и действительно собирается просматривать записи тестирования, тогда дерзайте – при условии, что пользователь даст на это свое согласие. В противном случае отбросьте эту идею и сосредоточьте все свое внимание на тестировании, происходящем в реальном режиме времени.
Как структурировать процедуру тестирования
Итак, вы успешно привлекли для тестирования несколько целевых потребителей, и первый из них уже находится в комнате с модератором. Как вы будете проводить тестирование? Во-первых, полезно заранее подготовить тестовый скрипт, в котором перечисляется все то, что вы планируете показать и о чем спросить участника. Это поможет не упустить из виду что-то важное и более эффективно распорядиться отпущенным вам временем. Тестовый скрипт должен четко описывать, какие именно артефакты дизайна или части продукта вы планируете показать пользователю, какие задачи он должен будет попытаться выполнить, и какие вопросы вы планируете ему задать. Все это должно быть перечислено в желаемом хронологическом порядке.
Может быть полезным проведение предварительной «обкатки» теста на ком-нибудь из членов вашей команды, чтобы устранить любые недочеты подготовки и просто потренироваться. Это особенно полезно в тех случаях, когда предстоящее мероприятие заставляет вас нервничать. Также вам может пригодиться распечатка тестового скрипта (или его сжатая версия), чтобы сверяться с ней по ходу проведения исследования.
Пользовательские тесты обычно длятся около часа, плюс-минус 15 минут. Это время может быть увеличено, если пользователь в восторге от продукта и дает вам много полезных отзывов. Я рекомендую потратить первые 10–15 минут сеанса на разогрев пользователя и выяснение его потребностей, а также того, какими решениями он пользуется в настоящее время. Затем я трачу от 40 до 45 минут на получение его отзывов о тестируемом продукте или артефактах дизайна. Заключительные 5-10 минут я отвожу на подведение итогов, во время которого отвечаю на вопросы пользователя и сам задаю вопросы, которые у меня остались.
Правильное начало играет очень важную роль. Поэтому будет разумным потратить минуту или две на болтовню, чтобы просто немного узнать собеседника. Установление взаимопонимания и создание комфортной обстановки обычно приводит к тому, что пользователь становится более открытым и предоставляет вам больше полезной информации в ходе тестирования. Не менее важно сразу рассказать участнику о ваших ожиданиях. Дело в том, что большинство людей ведут себя тактично и стараются обойтись без критических высказываний, особенно при личном общении. Они осознают, что вы, вероятно, являетесь членом команды разработчиков тестируемого продукта, и, соответственно, не хотят ранить ваши чувства. Плата за участие в тестировании также может привести к смещению реакции пользователя в более позитивную сторону. Чтобы помочь пользователю абстрагироваться от всех этих естественных устремлений, вы должны прямо сказать ему о том, что хотите получить объективную обратную связь, даже если она будет негативной. Объясните, что его честная оценка не затронет ничьих чувств. Напротив, критические отзывы помогут сделать продукт лучше, а ведь именно это и является основной целью проведения пользовательского тестирования.
Важно, чтобы во время проведения теста пользователь озвучивал свои мысли так, чтобы вы могли это услышать. У некоторых людей есть естественная склонность к проговариванию, в то время как другие, являясь по своей природе более замкнутыми, предпочитают оставлять свои мысли при себе. Чтобы убедиться в том, что вы получаете достаточно полную обратную связь, рекомендуется побуждать пользователя делиться своими мыслями вслух по мере их возникновения (то есть озвучивать поток сознания) на протяжении всего сеанса. Если пользователь продолжает молчать после вашей просьбы, нужно повторить ее еще раз.
Все перечисленные советы позволяют повысить шансы на получение ценной обратной связи, однако результат не гарантирован. Несмотря ни на что, некоторые люди так и не скажут ни слова критики о продукте, а другие дадут вам слишком мало. Вы можете обнаружить, что около 10 % участников тестирования окажутся «бесполезными». Если вы не получаете качественной обратной связи от значительного числа приглашенных на тестирование пользователей, вам стоит пересмотреть свои критерии отбора участников, тестовый скрипт или кандидатуру модератора – поскольку отсутствие нужного результата является признаком того, что что-то из перечисленного (если не все) явно нуждаются в улучшении.
Как задавать правильные вопросы
Ознакомительные вопросы отлично подходят для изучения проблемного пространства и формирования ценностного предложения с помощью пользователей. Вы можете начать интервью с вопроса о текущих потребностях участника, а также выяснить его мнение о ключевом преимуществе, которое вы планируете предоставить своим продуктом. Например, если бы вы были сотрудником Uber, то могли бы начать с того, что спросили бы, как часто участник тестирования пользуется услугами такси, какие виды поездок совершает и как находит такси, когда оно ему нужно. Вы также могли бы попросить подробно рассказать о недавнем опыте пользования данной услугой. Затем вы могли бы поинтересоваться, что ему нравится и что не нравится в существующих рыночных предложениях, а также выяснить общий уровень удовлетворенности услугами такси. Обратите внимание: до этого момента вы еще ни разу не упомянули про Uber. Вы просто пытаетесь понять потребности клиентов, то, каким образом они решают свои проблемы в настоящее время, что им в этом нравится, а что нет, и насколько они удовлетворены получаемым результатом. Таким образом, вы пытаетесь собрать качественную информацию, которую сможете использовать для подтверждения своих гипотез о целевом потребителе и ценностном предложении. Кроме этого, ознакомительные вопросы помогают плавно погрузить пользователя в контекст продукта еще до того, как предъявите его для тестирования.
Далее вы переходите к той части пользовательского тестирования, целью которой является получение обратной связи о продукте. На этом этапе задача модератора состоит в том, чтобы эффективно запрашивать отзывы пользователей, при этом никак не влияя на их содержание. Лучший способ исказить результаты состоит в том, чтобы задавать наводящие вопросы, такие как «Эту форму было легко заполнить, не так ли?» или «Вам ведь захотелось нажать здесь кнопку “Купить”?». Модераторы, которые задают подобные риторические и/или наводящие вопросы, больше заботятся о получении положительной оценки продукта вместо реальной и объективной обратной связи. Смысл тестирования продукта на пользователях не в том, чтобы заставить их похвалить вашу работу, а в том, чтобы получить достоверные отзывы от реальных клиентов. Степень объективности результатов, полученных в ходе тестирования, в огромной степени зависит от модератора. Понятно, что иногда бывает слишком трудно оставаться беспристрастным, тестируя продукт, над которым вы так долго и усердно работали, но это именно то, к чему следует стремиться. Лучшие модераторы знакомят пользователя с продуктом, не допуская личного вмешательства, насколько это только возможно. Они воздерживаются от каких-либо комментариев и оценок, ограничиваясь наблюдением и вопросами.
Если пользователь выполняет какие-либо действия с прототипом, не комментируя при этом, что и почему он делает, модератору следует побудить его дать объяснения, например, таким вопросом: «Я вижу, вы только что нажали на эту кнопку. Не могли бы Вы объяснить, почему?» Обратите внимание, что, вместо того чтобы просто спросить пользователя «почему?», модератор начал с описания того, что он заметил. Такое «обратное эхо» – мощный метод, позволяющий убедиться, что вы понимаете пользователя, и выяснить всю подоплеку его действий. Например, если пользователь отвечает: «Я нажал эту кнопку, потому что искал [_____]», модератор может задать следующий вопрос: «Почему вы искали [_____]?» Это напоминает метод «Пяти почему». Однако, если пользователь будет слышать вопрос «почему?» слишком часто, это может заставить его почувствовать себя защищающимся. Поэтому неплохо бы разбавлять это слово другими фразами, такими как «Не могли бы Вы рассказать мне об этом подробнее?», «Не могли бы Вы помочь мне понять [_____]?» или «О чем Вы подумали, когда делали [_____]?».
Обычно участники тестирования и сами задают вопросы модератору. Например, пользователь может спросить: «Должен ли я нажать эту кнопку, чтобы войти в систему?» Вместо ответа «да» или «нет» хороший модератор мог бы задать встречный вопрос: «А как Вы думаете, что произойдет, если нажать эту кнопку? – или просто сказать – Делайте все так, как будто рядом никого нет». Хорошие модераторы часто пользуются методом ответа вопросом на вопрос.
Открытые и закрытые вопросы
Существует значительная разница между открытыми и закрытыми вопросами. Открытые вопросы предоставляют пользователю большую свободу в ответе. Обычно они начинаются со слов: «почему», «как» и «что». В отличие от них, закрытые вопросы ограничивают возможные ответы (например, вариантами: «да» или «нет»). Задавать во время тестирования закрытый вопрос: «Выбираете ли вы рейс для бронирования билетов, исходя из цены?» – не будет настолько полезно, как если вы спросите: «От чего зависит ваш выбор рейса?» Закрытые вопросы часто начинаются с «Делаете ли вы…», «Есть ли у вас…» или «Хотели бы вы…». Выбор между открытым и закрытым вопросом зависит не столько от предвзятости модератора, сколько от уровня его квалификации. В обычной беседе, когда вы не выступаете в роли модератора, закрытые вопросы вполне уместны. Но при проведении тестирования их следует избегать. В этом может помочь включение списка предполагаемых вопросов в тестовый скрипт. Но хороший модератор должен уметь оперативно формулировать открытые вопросы (например, в ответ на что-то, что пользователь сделал или сказал). Полезный прием – выработать привычку проговаривать свой следующий вопрос в уме, прежде чем его озвучить. Тогда, если пришедший в голову вопрос окажется закрытым, у вас будет возможность переформулировать его прежде, чем он прозвучит.
Еще одна ошибка, которой следует избегать, заключается во включении в вопрос предпочтительного или возможного варианта ответа. Обычно такой вопрос начинается как открытый, но затем превращается в закрытый. Например: «Как бы Вы хотели, чтобы приложение сортировало Ваши транзакции? По дате?» Иногда неопытные модераторы не могут удержаться и добавляют к основному вопросу то, что, по их мнению, является наиболее вероятным ответом. Теперь, даже если пользователь собирался дать другой ответ, он может сказать «да» просто потому, что вы только что предложили свой вариант. Иногда это происходит из-за того, что модератор пытается «облегчить» пользователю задачу. Вы должны быть готовы к тому, что пользователю требуется время на осмысление увиденного и обдумывание своего ответа. Хотя такие длительные паузы выглядят неловкими в обычном разговоре, при проведении пользовательского тестирования они вполне уместны. Не стоит пытаться заполнить их, предлагая подсказки или свой вариант ответа. Задав свой вопрос, просто подождите, оставляя его открытым и обеспечивая пользователю свободу в выборе ответа. Часто это окупается тем, что вы узнаете вещи, которые ранее не приходили вам в голову. Это прекрасно (и может быть забавным) – пытаться предугадать ответ пользователя; и все же, во время тестирования необходимо держать свои предположения при себе, не высказывая их вслух.
Повторюсь, ваше вмешательство в процесс тестирования должно быть минимальным. Вы начинаете с показа пользователю конкретной части продукта или артефакта, в отношении которой хотели бы получить его отзыв; но сразу после того, как вы это сделаете, необходимо предоставить ему полную свободу действий. Пользователь может, взглянув на первую страницу, задать вопрос: «Так, и что мне теперь делать?» Я обычно отвечаю на это: «Представьте, что меня здесь нет. Просто поступайте так, как будто друг посоветовал Вам ознакомиться с этим продуктом, и Вы делаете это дома за своим компьютером». Если пользователь не выражает свои мысли словами, следует попросить его об обратной связи. Например, спросив: «Каковы ваши впечатления от этой страницы?»
Мне нравится позволять пользователю взаимодействовать с теми частями продукта, которые он обнаруживает самостоятельно (опять же без вмешательства модератора). Однако, если вам необходима обратная связь только в отношении определенного артефакта, который пользователь еще не обнаружил, вы можете направить его по нужному вам пути. Опять же, сделав это, вы снова должны «уйти в тень».
Когда пользователь в процессе тестирования продукта делает свои комментарии, вы, при наличии такой необходимости, можете и должны задавать ему уточняющие вопросы. Например, если пользователь после заполнения формы говорит: «Это было довольно сложно», – вам следует развить эту тему, например, спросив: «Не могли бы Вы пояснить, что именно вызвало сложности с заполнением?» или предложив: «Пожалуйста, расскажите об этом подробнее».
Принимайте реальность такой, как она есть
Если у пользователей возникают трудности с пониманием или использованием продукта, важно, как бы это ни было трудно, не приходить им на помощь. Ваша цель – сделать тест максимально приближенным к реальности; вы не сможете «водить за ручку» каждого покупателя продукта после его запуска, поэтому важно сделать продукт таким, чтобы в этом не было никакой необходимости. Во время тестирования вы должны вести себя так, будто вы муха на стене, и не выходить из этого образа во время получения обратной связи. Если пользователь жалуется на продукт или задает вопросы, следует воздержаться от объяснений, почему функция работает так, а не иначе, или что на самом деле имеется в виду в непонятном для пользователя тексте или пользовательском интерфейсе, а также от указаний, куда ему следует нажать. Тем более, не стоит хвататься за мышь и делать все самому (да-да, я видел, как модераторы проделывали такие штуки). Вы можете сообщить пользователям, что ответите на все их вопросы по окончании тестирования. Если качество или пользовательский интерфейс продукта или артефакта является настолько низким, что не позволяет пользователям эффективно взаимодействовать с ним самостоятельно, то вам следует прекратить тестирование и заняться решением этих проблем.
Нечасто, но я все же становился свидетелем ситуаций, когда модераторы в ответ на критику со стороны пользователей, занимали оборонительную позицию и пытались оспаривать их мнение, или даже обвиняли пользователя в неправильных действиях. Такое поведение непродуктивно и непрофессионально. Если пользователь не смог разобраться в продукте, очевидно, что в этом вина разработчиков, а не пользователя.
Завершение тестирования
Подведение итогов тестирования начинается после завершения работы пользователя с продуктом. Это самый подходящий момент для того, чтобы попросить участников поделиться своим мнением обо всем, что они увидели, а также озвучить свои общие впечатления. Возможно, вы захотите, чтобы пользователи оценили продукт в баллах. Например, вы могли бы спросить: «По шкале от 0 до 10, где 10 – это лучшая оценка, насколько полезным вы считаете это приложение?» или «Исходя из того, что вы сегодня увидели, насколько вероятно, что вы воспользуетесь этим приложением?». Вы также могли бы спросить: «Насколько просто было пользоваться приложением?» Вы можете задать свой вопрос устно или предоставить пользователю краткую форму для заполнения, что, кстати, способствует получению менее предвзятых результатов. По мере прохождения итераций, улучшающих прототип MVP, вы сможете наблюдать, как меняются оценки пользователей при ответах на те же вопросы.
Заключительный этап тестирования наилучшим образом подходит и для ответов на любые вопросы, как возникавшие во время тестирования, так и появившиеся у пользователя по его завершении. Если в процессе тестирования у пользователя возникли проблемы из-за известных разработчикам ошибок или неполадок, вы можете разъяснить ему эти моменты. По окончании сеанса вы также должны будете предоставить участникам подготовленное вознаграждение за потраченное ими время и поблагодарить их. Обычно я прошу пользователей подписать специальную форму, подтверждающую получение платежа. В этой же форме я предлагаю каждому участнику, по желанию, указать свой адрес электронной почты и номер телефона. Я также включаю туда два быстрых вопроса с вариантами ответа «да/нет»: «Хотели бы вы принять участие в будущих исследованиях?» и «Хотели бы вы получить уведомление, когда приложение появится в продаже?». Оба вопроса, на самом деле, являются скрытной проверкой степени заинтересованности. Если пользователь в ходе тестирования давал продукту исключительно положительные отзывы и оценки, но не дает ответ «да» на эти последние два вопроса, значит, в своей обратной связи он просто был излишне вежлив.
Однажды по завершении тестирования я не стал раздавать участникам для заполнения описанную выше итоговую форму. После того как я вручил им чеки и поблагодарил их, очень многие спросили меня, когда продукт будет запущен, и предоставили свои контактные данные, попросив уведомить их о начале продаж. Тестирование продукта прошло удачно, но такое дополнительное доказательство соответствия продукта рынку стало для нас приятным сюрпризом.
Как собирать и обобщать отзывы пользователей
В процессе тестирования вы пытаетесь получить сведения, которые подтверждают или опровергают гипотезы, выдвинутые вами на этапе подготовки кандидата в MVP: о целевых потребителях, их недостаточно удовлетворенных потребностях, отличительных особенностях вашего ценностного предложения и так далее. Получаемая от пользователей обратная связь будет касаться трех компонентов продукта: функциональности, пользовательского интерфейса и целевого месседжа. Отзывы о функциональности показывают, обеспечивает ли MVP нужные клиентам преимущества или нет. Пользователи могут пожаловаться на отсутствие какой-либо ключевой функции или сообщить, что какая-то из имеющихся функций, для них не важна. В таких случаях следует сопоставить полученную информацию с преимуществами и ценностным предложением продукта. Возможно, в нем на самом деле имеется нужный функционал, обеспечивающий требуемые преимущества, но плохо прописанный пользовательский интерфейс не позволяет пользователям оценить его в полной мере. Наконец, у продукта могут быть и все необходимые пользователю функции и дружественный интерфейс, но то, как вы подаете свой продукт и рассказываете о его возможностях и преимуществах – ваш целевой месседж – может не найти отклик у потребителя. Когда вы получаете от пользователей критические или положительные отзывы, бывает весьма полезно сопоставить их с тремя перечисленными высокоуровневыми категориями: функциональностью, UX-дизайном и целевым месседжем. Такая группировка обратной связи по результатам тестирования позволяет составить более четкое представление о том, что работает хорошо, а что нет.
Давайте обсудим наглядный пример фиксации пользовательских отзывов. В таблице 9.1 приведены сводные результаты тестирования с участием пяти пользователей. Вы можете видеть, что отзывы каждого из участников представлены в отдельном столбце. При этом все отзывы распределены по представленным выше направлениям: функционал, UX-дизайн и целевой месседж. Кроме этого, я включил в сводную таблицу оценки ценности продукта и простоты использования, которые запрашивал от каждого участника по окончании тестирования. Каждому виду как положительных, так и отрицательных отзывов отведена специальная строка. Я помечаю, кто из пользователей оставил соответствующий отзыв, символом «Y» вместо «Да». Это позволяет легко распознать имеющиеся закономерности. В правой колонке приведены сводные результаты с учетом мнений всех пяти пользователей (проценты и медианные оценки). Для простоты я не включил в таблицу те отзывы, повторяемость которых составила менее 40 %.
Таблица 9.1 Отслеживание ключевых результатов пользовательских тестов
Из таблицы вы можете видеть, что на данном этапе тестирования мы получили от пользователей положительные отзывы о функции X, профессиональном дизайне и изображении на домашней странице. Кроме этого, были выявлены четыре проблемы:
• 80 % пользователей пожаловались на отсутствие функции Y;
• 60 % пользователей не нашли ссылку «Зарегистрироваться»;
• У 60 % пользователей возникли трудности с регистрацией;
• 40 % пользователей не поняли наш слоган.
После того как полученная обратная связь будет учтена при улучшении продукта, мы проведем второй раунд пользовательского тестирования, по результатам которого ожидаем и надеемся увидеть прогресс в повышении степени соответствия продукта рынку по всем трем отслеживаемым направлениям. Во-первых, это должно выражаться в увеличении числа положительных отзывов, полученных от большего процента пользователей, особенно в отношении тех аспектов, которые связаны с нашим ценностным предложением. Во-вторых, те негативные отзывы, которые мы получили в ходе первого раунда тестирования, не должны будут появиться вновь. Вы должны понимать, что те пользователи, которые примут участие во втором раунде, не видели более раннюю версию продукта. Поэтому никто из них не скажет вам: «Вы отлично поработали над устранением проблемы [_____]». Таким образом, прогресс, достигнутый в этом направлении, должен отразиться в отсутствии тех же жалоб, которые вы получили в ходе предыдущего раунда тестирования. Третий показатель прогресса – медианные значения пользовательских оценок, относящихся к дополнительным показателям. Мы хотим увидеть, что после улучшения продукта, оценки его ценности и простоты использования (как и любые другие ключевые показатели) стали более высокими.
Юзабилити и соответствие продукта рынку
При проведении тестирования на пользователях крайне важно учитывать различие между обратной связью в отношении удобства использования и в отношении соответствия продукта рынку. Отзывы о юзабилити характеризуют продукт с точки зрения его простоты и удобства для пользователей, в то время как отзывы о соответствии продукта рынку связаны с тем, насколько ценным они находят продукт. Вы наверняка заметили, что в нижней части Таблицы 9.1 я привел оценки участников тестирования, относящиеся именно к этим двум аспектам.
На ранних этапах разработки MVP вы можете получать от пользователей множество критических замечаний, касающихся UX-дизайна. Недостаточно качественное юзабилити часто не позволяет пользователям в полной мере оценить ценность вашего продукта. Вы можете также обнаружить наличие ошибок, мешающих полноценному использованию продукта. Камнем преткновения могут стать и непонятные или не доходящие до пользователя месседжи.
По мере устранения этих факторов, вызывающих недовольство пользователей, ценность продукта может стать для них более явной, и тогда вы сможете получить более точное представление о степени соответствия продукта рынку. После внесения множества улучшений вы можете дойти до той стадии, когда пользователи будут с легкостью проходить все тестовые задания, не сталкиваясь с какими-либо проблемами юзабилити. Однако из этого вовсе не следует делать вывод о том, что продукт соответствует рынку. Такую оценку может дать только четкий ответ пользователей на вопрос, насколько ценным они считают ваш продукт.
Я испытал это на собственном опыте, работая над продуктом, который в режиме реального времени предлагал пользователям новости, подобранные в соответствии с их интересами. В ходе первого раунда тестирования MVP продукта пользователи предоставили нам обратную связь, содержащую ответы на множество вопросов, связанных с удобством использования. Мы также выявили несколько программных ошибок и неоднозначных текстовых сообщений. После того как эти недочеты были исправлены, мы провели второй раунд тестирования, в ходе которого выявили уже меньшее количество проблем, которые также были исправлены. На третьем круге пользовательские тесты стали гораздо более успешными. Большинство пользователей проходили их без проблем, что привело меня в восторг от достигнутого прогресса.
По завершении каждого теста я стал спрашивать пользователей, насколько вероятно, что они воспользуются нашим продуктом. Несмотря на то, что тесты прошли успешно, около 20 % опрошенных заявили, что не будут им пользоваться. Этот результат меня удивил, ведь негативных отзывов в ходе тестирования практически не было. Кроме того, большинство участников тестирования проявляли определенный интерес к продукту, позволявшему получать персонализированную подборку новостей, из чего я сделал вывод, что они достаточно точно соответствуют профилю нашей целевой аудитории. Когда я стал прямо спрашивать «отказников» о причинах, по которым они не стали бы использовать наш продукт, выяснилось, что определенный сегмент пользователей предпочитает получать новости вполне определенным способом. Это было замечательное, неожиданное озарение, которое побудило меня начать спрашивать людей, как именно они предпочитают получать новости. Теперь я задавал этот вопрос в ходе предварительного опроса. В итоге мне удалось обнаружить, что существует три совершенно разных способа, которыми люди предпочитают получать новости, и наш подход к разработке продукта в наибольшей степени соответствовал лишь одному из них. Данное открытие помогло нам лучше разобраться в рыночной ситуации. Онлайн-новости – это базовый потребительский продукт с большой аудиторией пользователей, поэтому неудивительно наличие на этом рынке сегментов с различающимися предпочтениями. Посовещавшись, мы пришли к выводу, что попытка создать проект, который охватывал бы все три различных способа получения новостей, граничит с сумасшествием и не сделает счастливой ни одну из категорий пользователей. Поэтому мы просто использовали полученные знания для уточнения описания нашего целевого потребителя.
Как видите, не только проблемы с юзабилити могут помешать вам оценить соответствие продукта рынку. Даже наличие отменных удобств использования продукта не означает, что он полностью соответствует рынку. Кроме этого, приведенный пример показывает, как тестирование с участием пользователей может помочь подтвердить и уточнить ключевые гипотезы (в данном случае, о том, кто является вашим целевым клиентом).
Тестирование на пользователях – это один из мощнейших инструментов, используемых в бережливом производстве. При правильном его использовании вы можете получить очень ценную обратную связь о своих гипотезах, относящихся к нескольким уровням пирамиды соответствия продукта рынку: недостаточно удовлетворенные потребности, ценностное предложение, набор функций MVP и UX. Однако важно отметить, что тестирование с участием пользователей по своей сути основано на предположении, что вы общаетесь с подходящим типом клиентов. Очень важно убедиться, что опрашиваемые пользователи действительно являются представителями вашего целевого рынка. Вы можете отлично поработать над определением своего ценностного предложения и набора функций MVP, создать потрясающий набор интерактивных вайрфреймов и качественно провести процедуры тестирования. Однако, если вы при этом разговариваете не с теми людьми, вы не получите нужные вам сведения. Хуже того, вы можете получить неверные данные, которые будут сильно отличаться от того, что сообщили бы вам настоящие целевые клиенты. Дальнейшее совершенствование MVP на основе данных, полученных от неподходящего типа пользователей, может направить вас в неверном направлении – вы полетите с обрыва вместо попадания в Землю обетованную соответствия продукта рынку.
Если, после того как вы преодолели все имевшиеся серьезные проблемы с юзабилити, пользовательские тесты показывают, что продукт все еще не соответствует рынку, вам, возможно, придется пересмотреть свои гипотезы о ценностном предложении, MVP и/или UX-дизайне. Однако необходимо учитывать, что на самом деле причина неудачного тестирования может скрываться в ошибочности изначальной гипотезы о вашем целевом клиенте. Поэтому всегда стоит провести дополнительную проверку, чтобы исключить такой вариант.
В следующей главе я расскажу о том, как использовать данные, полученные в результате пользовательского тестирования, для улучшения кандидата в MVP и как проводить быстрые итерации, приближающие продукт к рыночному соответствию.