Как проводить пользовательские тестирования, когда все идет не так

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

В какой-то момент появилось ощущение, что зря трачу время. Я не тестировала бумажные прототипы, не использовала программы записи экрана, не вела интервью по заранее подготовленному плану. Но со временем я поняла, что любое тестирование лучше, чем его отсутствие. И в этой статье я расскажу, как проходят мои «неправильные» юзер-тесты ? , какую они приносят пользу и как выкручиваться, когда все идет не так как планировалось.

Аудитория

Стартап, в котором я работаю, оказывает услуги интернет-магазинам. Для исследований я не могу набирать людей со стороны — я не могу тестировать прототип сервиса устранения кассового разрыва на людях, которые даже не знают, что такое кассовый разрыв (как я, когда только пришла в компанию).

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

Опросники по имейлу

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

Интервью

При личном тестировании не нужно объяснять или обсуждать интерфейс, а надо спокойно и дружелюбно задавать вопросы типа «Что вы думаете будет при нажатии на эту кнопку» и действовать согласно заранее подготовленному плану. На практике у меня так не получалось. Из вежливости респонденты отвечали на пару вопросов про кнопки и потом сразу начинали рассказывать, что им хочется от интерфейса (реже) и от сервиса в целом (всегда). Они с удовольствием готовы рассказывать о болях бизнеса, а вот смотреть «картинки» (и интерактивный прототип тоже) — как-то не особо.

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

Другие программы

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

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

Или «Я не люблю скайп, потому что он у меня на телефоне плохо работает, а я с телефона в основном в интернете» — значит, нам нужна мобильная версия нашего сервиса. Мобильную версию сервиса отправили в долгий лист ожидания? Значит придумываем другое решение — присылаем раз в день на почту отчет по самым важным показателям, чтобы не заставлять человека с телефона продираться через неадаптивный интерфейс.

Когда все идет совсем не так, но так даже лучше

Однажды я долго согласовывала время тестирование новой версии интерфейса с руководительницей крупного магазина и долго добиралась до места встречи. Стала показывать ей прототип, задавать вопросы, но сразу же появилось чувство, что что-то идет не так. Через 10 минут выяснилось, что она вообще никогда не пользовалась нашим личным кабинетом и даже не видела его. Им пользовались ее помощники, а ей лишь предоставляли отчет, да и в будущем она им пользоваться не собиралась. В первый момент я подумала, что это полный провал, но в итоге это интервью оказалось одним из самых полезных. Она выдала самое непредвзятое мнение об элементах интерфейса, увидев их впервые, но при этом понимая суть сервиса. Но самое главное — она очень подробно поделилась проблемами бизнеса, которые хотела бы решать с помощью нашего продукта. По результатам этой беседы были внедрены некоторые важные функции и появилось понимание, что наши пользователи — это не обязательно пользователи нашего интерфейса.

Один клиент спросил у нас про функцию, которую мы только разрабатывали — что-то типа страховки покупок. Я с ним созвонилась, разговор длился почти 2 часа, при этом про страховку покупок мы поговорили минут 10. Все остальное время он рассказывал про проблемы с недобросовестными покупателями, которые, собственно, и навели его на мысли о страховке. В итоге эти реальные случаи позволили нам посмотреть на проблему под другим углом и придумать более интересные решения, чем мы изначально планировали.

Прототип сервиса vs прототип интерфейса

При разработке нового сервиса аналитики для магазинов мы с коллегой ездили к клиентам с и обсуждали возможности, которые мы можем предложить. При этом я показывала не прототип интерфейса, а прототип сервиса — я создала в QlickSense (программа для создания разной аналитики, бесплатная при определенных ограничениях) кучу разных графиков на основе реальных данных клиентов, разместила оптимально со своей точки зрения на страницах и показывала клиентам на своем ноутбуке. Разговоры получались очень предметными с очень полезным фидбеком, и только после этих исследований я стала делать прототип интерфейса (его потом тоже тестировали).

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

Удаленное тестирование

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

Зато прототипы интерфейса, отправленные по электронной почте, неожиданно получили ценный фидбек, хотя не было никакой возможности увидеть реакцию или хотя бы задать уточняющие вопросы — все клиенты просто написали развернутые письма со своими комментариями. Тут я даже не знаю, то ли нам повезло, то ли это просто еще одна особенность аудитории (конечно, перед отправкой писем со всеми созвонились ? ).

Обработка результатов

С нашими клиентами много тестов одной функции в разумный промежуток времени провести сложно, поэтому данных после тестирования тоже обычно мало. О какой-то статистически значимой выборке говорить не приходится. Некоторые выводы делались на основе одного (!) мнения. И все же, лучше попробовать воплотить гипотезу, основанную на одном мнении реального клиента, чем делать только то, что придумали внутри команды. Благодаря таким вот одиночным мнениям в основном продукте появилась ключевая функция и два смежных сервиса.

Другие способы улучшить интерфейс

Если есть сервис-конкурент, можно стать его пользователем и прочувствовать все на себе — удачные решения и ошибки. Я так делала при разработке сервиса страховки покупок.

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

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

Выводы

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