Год назад произошло интересное – придумали необычный способ тестировать наш продукт. Подход повлиял на все процессы в компании и сказался на росте клиентской базы. Сейчас проведено уже более 50 тестов, и есть чем поделиться.

Метод скорее относится к инструментам Customer Development и затягивает в анализ всю команду разработки. Каждый тест с интересом смотрят и программисты, и дизайнеры. Мгновенно разгораются споры и обсуждения, как пофиксить баг или UX-проблему.


График роста числа активных пользователей системы в день

Пробовал рассказать про подход другим продуктовым командам, но без примеров тема остается не раскрытой. Одна команда из четырех попробовала – и тоже получила отличный результат.
Под катом – попробую рассказать подробно о том, как не совсем обычно мы тестируем YouGile, с примерами и деталями.

Суть подхода в 4 предложениях

1. Описываем кейс использования системы, например: «Представьте, что вы – небольшая веб-студия, и вам нужно расписать задачи по разработке сайта на 5 человек...»
2. Идем на фриланс и выкладываем задание с описанным кейсом: «Организуйте рабочий процесс в системе управления (без предварительного изучения системы) и запишите свой опыт на экранное видео» (500 руб./час или чуть больше).
3. Получаем 10-15 откликов, заказываем 2-4 теста, смотрим на двойной скорости с перемоткой, обалдеваем от реальной картины использования системы, после чего 1-2 самых удачных ролика отправляем команде.
4. Вносим правки и фиксим баги, повторяем цикл и добиваемся почти идеального решения кейса со стороны случайных пользователей.

Профит — интересные моменты из тестов интерфейсов

Важные детали

• Нужен опыт использования, а не мнение. Нам нужно, чтобы тестировщик комментировал именно ход своих мыслей и действий, пока выполняет задачу. Но по умолчанию люди пытаются сразу предлагать идеи о том, как улучшить систему. По этой причине чаще всего ролики бракуются. Полезен только наглядный опыт первого использования продукта случайным человеком, а не мнение о том, как надо «допилить вот эту фичу».
• Необходимо ставить задачи «верхнего уровня». То есть не «Найти кнопку», а «Организовать рабочий процесс». И не стараться в формулировке задания подсказать пользователю, как решать задачу, тем более, если варианты решения могут быть разными.
• Это не количественный тест, а качественный. Не нужно нанимать много людей и создавать репрезентативную картину. Главное понять – могут ли люди справиться с заданием и устраивает ли продуктовую команду, как это происходит (мучительно или не очень). Достаточно заказать 3-4 теста, чтобы гарантированно получить один содержательный или обратить внимание на несколько эпизодов из разных тестов.
• Не обязательно искать тестера именно из своей ЦА. Подходит почти любой уверенный пользователь ПК, по крайней мере для нашего продукта. Если продукт изначально очень сложный, то кейс должен быть простым. Например, для сложной мед программы: “… найти куда загрузить данные эксперимента, запустить обсчет и получить результат, далее сохранить в файл...”.
• Проводить тесты необходимо на незнакомых людях. Случайные люди всегда лучше, чем круг общения. Друзья и знакомые быстро закончатся, да и не все из них захотят «подвисать» целый час над интерфейсом. А нам важен именно первый опыт взаимодействия с продуктом. Тестирование нужно проводить регулярно, и нужны пользователи со «свежим» взглядом.

Главная ценность подхода

У команды продукта появляется азарт смотреть, что получается.

Именно азарт! Команда с нетерпением ждет появления новых видеозаписей после релиза, с интересом просматривает тесты.

За 11 лет участия в развитии продуктов — это один из лучших CustDev методов, который я для себя открыл. Лучший именно с точки зрения влияния на команду.

Смотрят дизайнер и разработчик, как Алексей из Перми 5 минут пытается отыскать кнопку «Создать проект» – и хорошо понимают, что и как поменять.

Что еще можно тестировать?

Конкурентов

Мы постоянно так делаем. Точно знаем, как глазами пользователей выглядят гиганты на нашем рынке. За какое время, например, удается решить задачу организации простой команды в Trello, Jira или Asana и разумеется сравниваем с собой. Из таких тестов, кроме багов конкурентов, можно увидеть действительно работающие решения.

То, как люди ищут информацию

Мы попросили фрилансеров найти в интернете системы управления проектами и отобрать для себя ТОП-3 для дальнейшего тестирования. Наблюдали, через какие каналы они могут найти нас, по каким критериям делают выбор. Смотрели: открывают они списки на сайтах-агрегаторах или выбирают рекламные объявления, читают статьи с подборками систем или доверяют тем сайтам, которые находятся в топе поисковой выдачи.

Статьи

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

Пример, как тестируется эта статья

Если кто-то вдохновится материалом и проведет такой тест, скиньте в комментарии запись. Очень интересно посмотреть и обсудить, что получается.