Наше тестовое задание

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

• Опрос, что слишком рано для нового продукта и не подходит под вопросы к исследованию.
  
• Фокус-группу, но не описывали разные сегменты пользователей, которых следовало на неё позвать.
  
• Интервью без юзабилити.

Но поскольку в задаче речь идёт о недавно запущенном продукте и нужно ответить на вопросы о задачах и опыте пользователей в других приложениях, то для начала важно изучить пользовательский контекст. Стоит проанализировать паттерны просмотра людьми сториз в других приложениях и узнать их мнения относительно сториз. Хорошим вариантом проверки может быть комбинация интервью и юзабилити. Уместны также фокус-группы с разными сегментами пользователей — это особенно хорошо для того, чтобы относительно быстро погрузиться в проблематику продукта. Также можно использовать метод дневников, если мы понимаем, что хотим поймать рефлексию человека по просмотру сториз в моменте.
Отсутствие гипотез или неверные формулировки гипотез
С гипотезами был целый набор проблем.
Нет гипотез. На юзабилити-тесте они обязательно должны быть, иначе есть риск не проверить важные моменты и после проведения исследования обнаружить, что нужны дополнительные итерации. К тому же, гипотезы здесь нужны для того, чтобы правильно выбрать и сформулировать задания на тест. Например, понять, уместны ли будут закрытые задания или же задания с опорой на опыт респондента.
Недостаточное количество гипотез. Когда мы планируем юзабилити-тест, важно продумать все гипотезы, которые нужно проверить в интерфейсе и которые помогут ответить на вопросы исследования. В задании с оценкой стоимости авто точно нужны были гипотезы о заметности оценок, их понимании, нехватке или достаточности информации. Часто ребята опускали один или два пункта.
Слишком общие формулировки гипотез. Если гипотезы сформулированы недостаточно конкретно, становится сложнее проверить их в исследовании.
Примеры таких гипотез: «пользователь проявит больший интерес к сервису, если будет просматривать истории» или «истории — наиболее эффективный способ подачи материала, позволяющий расширить охват и повысить активность аудитории».
На любую или почти любую гипотезу в качественном исследовании мы можем ответить «да» или «нет», а в количественном — чётко понимаем, как это измерить. С формулировками выше нельзя сделать ни то, ни другое, так как не понятно, что значит «проявит интерес» и что значит «больший». Больший, чем что?
Вторая гипотеза в примере грешит ещё и тем, что сформулирована нечётко. Из неё непонятно, о подаче какого материала речь.
Несколько гипотез в одной. Важно, чтобы гипотеза была сформулирована в виде одной законченной мысли. Тогда будет легко однозначно ответить, верна она или нет. Кроме того, в составе сложной гипотезы могут оказаться предположения, которые нужно проверять разными методами.
Пример такой гипотезы: «пользователь доверяет оценке сервиса по цене автомобиля, и это приведёт к целевому действию». Кстати, здесь тоже не хватает конкретики — лучше уточнить, что мы считаем целевым действием в данном случае.
Гипотезу нельзя проверить качественными методами. В предыдущем примере с оценкой есть ещё один недочёт — на юзабилити-тесте мы никак не узнаем, приведёт наша фича к целевому действию или нет. Тут стоит быть внимательнее и не выносить на качественное исследование предположения, которые нужно проверять на данных или же в количественном опросе.
Ещё пример гипотезы с подобной проблемой: «есть положительная зависимость между уровнем знания (восприятия) функции и решением о покупке автомобиля».
Такое предположение можно проверить только с помощью опроса или эксперимента, да и то скорее не связь между знанием о функции и покупкой авто, а связь между наличием метки на объявлении и количеством просмотров/контактов по нему. Проверить эту гипотезу юзабилити-тестом, как просит первое задание в тестовом, не получится. Кроме того стоит помнить, что в лаборатории мы не узнаем о фактическом решении пользователя купить машину.
Гипотезы, которые не нужно проверять, или самоочевидные. Встречались в ответах кандидатов формулировки гипотез, которые не нуждаются в проверке, потому что это факты из разряда, что если нагреть воду, то она будет горячей.
Например, «пользователь будет просматривать истории, если они будут содержать релевантный интересам пользователя контент». Конечно, люди будут смотреть развлекательный контент, который им интересен, это понятно и без исследования. Но даже если бы мы вынесли такую гипотезу на интервью или тест, то что потом с этой информацией делать? Здесь были бы уместны гипотезы о том, что именно может быть интересно конкретному сегменту аудитории.
Другой пример такой гипотезы — «аудитория не обращает внимания на отметки и будет выбирать автомобиль по другим показателям». Понятно, что на выбор машины влияет множество факторов. Наша же задача в исследовании более конкретна — понять, добавляет ли новая функция ценность для пользователя в его задаче поиска авто.
Утверждения о работе продукта вместо гипотез. Некоторые ребята выносили на исследование утверждения, которые нельзя назвать гипотезами, потому что они описывают работу фичи или сервиса. В этом они похожи на гипотезы из предыдущего пункта, но всё же хочется привести отдельные примеры и здесь.
Например, такая: «истории заменяют новостной формат, рассказывая о новостях приложения, функциях, актуальных товарах». Нам надо это знать, и это может не быть очевидным до исследования, но подобные утверждения — не предмет разговора с пользователями. Задача исследователя — до старта проекта разобраться в работе продукта, а на тест вынести предположения о взаимодействии клиентов с сервисом.
Бесполезные гипотезы. В заданиях встречались гипотезы, оторванные от реалий и задач бизнеса. Такие предположения нет смысла проверять, потому что они не помогут развитию продукта. Можно легко придумать много таких гипотез, не зная внутреннюю кухню компании. Но, если взять например, такую гипотезу: «сториз в Авито теряются на фоне сториз в других сервисах», то становится понятно, что:

• она сформулирована так, что не очевидно, как её проверить;
  
• поскольку Авито — не социальная сеть, то вряд ли у бизнеса будет задача сделать «лучшие в мире сториз».

Некорректное формирование выборки
По формированию выборки для первого задания с юзабилити-тестированием оценки стоимости авто ключевая проблема — описание её социально-демографическими критериями, таким как пол или возраст. Часть ребят понимали, что нужны характеристики, связанные с автомобилями, но и тут могли промахнуться. Многие выбирали респондентов, у которых есть права или авто, или опыт покупки автомобиля в прошлом.
В этих критериях самих по себе нет проблем, они могут быть дополнительными. Но главное для формирования выборки в первом задании — опыт респондента в использовании Авито и его текущая потребность в покупке авто.
Когда мы тестируем что-то новое в сервисе, стоит посмотреть в исследовании как на его опытных пользователей, так и на пользователей-новичков. Это гигиеническое правило. В случае Авито опытный пользователь — это тот, кто недавно искал авто на нашей площадке. Неопытный — тот, кто искал машину на других сайтах или на Авито более полугода назад. Проблемы, потребности и непонимания у этих двух групп могут быть разными. Например, у опытного пользователя может быть больше запрос к детальности и подробности информации, в то время как новичку будет сложно разобраться в многообразии функций незнакомого сервиса.
Что касается потребности в покупке, то для задания не подходят просто собственники автомобилей или те, кто покупал их в прошлом. Это важно, потому что юзабилити-тест — не игра «заметит оценку или нет» и не попытка узнать, что про неё думает случайный человек. Нужно, чтобы инсайты о том, упрощают ли отметки процесс поиска и какой информации в них не хватает, были получены от людей, которые заинтересованы в покупке машины прямо сейчас. Такие пользователи точно знают и могут рассказать и показать нам, как её ищут и на что обращают внимание.
Ошибки в сценарии исследования
Самая обидная ошибка в первом задании — попытка загнать респондента в рамки. Многие кандидаты давали закрытую задачу по поиску авто: просили найти конкретную марку с конкретными параметрами или даже ограничивали бюджет покупки. Однако в тестовом задании нет гипотез, которые стоило проверять именно так.
Желательно делать все задания в исследовании максимально приближенными к реальной жизни респондента. Даже если проверяемые гипотезы очень конкретны и касаются определённых элементов интерфейса, то лучше сначала дать человеку возможность показать, что он ищет для себя и как это делает. Пока он будет это показывать, мы поймём его контекст, отметим для себя, что для него важно, и в частности — обратит ли он сам внимание на наши оценки стоимости авто. И уже после этого наступит время для уточняющих вопросов и точечных задач.
По самим вопросам в сценарии были такие ошибки:

• Закрытые вопросы. Например, «замечали ли вы информационные блоки с анализом уровня цены и отметками „хорошая цена“ или „отличная цена“?». Во-первых, на такой вопрос легко ответить просто «да» или «нет», что малополезно в качественном интервью. Во-вторых, он содержит в себе подсказку, из-за которой мы не узнаем, сказал бы сам человек про эти отметки или нет.
  
• Вопросы или задания в тесте с подсказкой. Например, кандидаты просили найти авто с ценой ниже рыночной. Такая постановка вопроса уже фокусирует внимание респондента на цене и всём, что с ней связано.
  
• Сложные формулировки вопросов. Например, вопрос «были ли какие-либо аспекты системы, которые помогли выполнить задачи?». Для респондента исследование — это беседа на бытовые темы, в которой не место сложным конструкциям и профессиональной терминологии. Если человек не поймёт ваш вопрос, то он в лучшем случае почувствует неловкость, а в худшем не переспросит, и вы не получите точный ответ. Намного лучше задавать простые вопросы, такие как «а что вам помогло при поиске?».

Последняя ошибка в сценариях — это сообщение цели исследования. В разных случаях это может быть в разной степени уместно. Например, бизнес-пользователям может потребоваться более конкретная формулировка, чтобы они вообще согласились с нами общаться. В то же время, общаясь с частными пользователями, не стоит «наводить» их на цель исследования. Лучше сформулировать задачу чуть более абстрактно. Как вариант — сказать, что мы хотим понять, как люди ищут машину на Авито.
Чек-лист для самопроверки
Вот чек-лист, который повысит шансы пройти отбор на стажёра-исследователя по результатам тестового задания:

• Проверьте, что вашу работу легко посмотреть: желательно, чтобы она открывалась по ссылке, не нужно было ничего скачивать или где-то регистрироваться. Помните, что задания смотрят не только HR, но и специалисты по вашему треку.
  
• Подумайте о том, как оформить тестовое задание. Когда нужно проверить десятки работ, идеально, если работа каждого человека находится в отдельном файле, подписана его именем и аккуратно структурирована. Также, лучше не использовать для работы исследователя Фигму. Основной результат работы здесь — текст. Его логичнее оформить в гугл-документе, Notion или любом другом инструменте для работы с текстом, а Фигму оставить дизайнерам.
  
• Старайтесь избегать ошибок, опечаток и слишком сложных предложений. Лучше перечитать работу на свежую голову, или показать другу, чтобы убрать лишнее и переформулировать непонятное.
  
• Стоит выполнять задания так, как указано в тестовом. Если вы решили сделать по-другому, поясните, почему. Конечно, в исследованиях зачастую нет единственного верного ответа, но нам важно понять, как вы мыслите.
  
• Описывая выполнение задачи, постарайтесь дать всю необходимую информацию для оценки работы: параметры выборки, гипотезы, сценарий, то есть список вопросов к респондентам, расшифровки интервью и тестов, результаты и выводы.
  
• В то же время помните, что исследование для компании — это не курсовая. Лучше опустить лишние подробности по выполнению заданий, например даты, объект и предмет исследования. Добавляя информацию, спрашивайте себя, точно ли она будет полезна или это просто следование стандартам.
  
• Продумывая гипотезы, помните, что они должны быть сформулированы чётко, однозначно и предполагать ответ «да» или «нет». Они должны быть именно предположениями, требующими проверки, а не очевидными утверждениями. От формулировки гипотезы зависит выбор метода и формирование выборки, поэтому перечитайте её дважды и спросите себя: «я смогу проверить это предположение тем методом, который указан в тестовом?» или «какой метод лучше всего поможет проверить такую гипотезу?», если это задача от заказчика. Также убедитесь, что результат проверки гипотезы будет полезен продукту и поможет продвинуться в его улучшении.
  
• При формировании выборки держите в голове тех людей, которые смогут лучше всего ответить на ваши гипотезы, исходя из своего опыта и потребностей. Кстати, когда я хотела понять, насколько хороша эта статья, я попросила её посмотреть людей с разным опытом из нашей команды: самого опытного эксперта, чтобы оценить верность выводов, и нашего стажёра, как представителя ЦА.
  
• Когда составляете сценарий, начинайте разговор и задания с реального опыта респондента.
  
• При составлении сценария фокусируйтесь на открытых вопросах, чтобы не наводить человека на ответы. Конкретизировать всегда успеете по ходу теста.
  
• Помните, что в сценарии не место сложным конструкциям и профессиональному жаргону. Говорите с респондентом на его языке.

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

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

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

• [Учебный процесс в IT, Развитие стартапа, Управление продуктом] YC Startup Library на русском: Создавать продукт как небольшой стартап (Майкл Сибель) (перевод)
  
• [Управление разработкой, Управление проектами, Управление продуктом, Управление персоналом, Конференции] Управление разработкой в «горизонтальных» компаниях: расшифровка онлайн-встречи. Часть 2
  
• [Проектирование и рефакторинг, Управление продуктом] Как заставить руководство проникнуться техническим долгом (перевод)
  
• [Учебный процесс в IT, Венчурные инвестиции, Развитие стартапа, Управление продуктом] YC Startup Library на русском: Чем питч для инвесторов отличается от питча для клиентов (Майкл Сибель) (перевод)
  
• [Информационная безопасность, Совершенный код, Управление продуктом, Софт] Строим безопасную разработку в ритейлере. Часть 2, SAP-приложения
  
• [IT-стандарты, Терминология IT, Управление продуктом] Как определить метрики для Управления инцидентами (перевод)
  
• [IT-стандарты, Терминология IT, Service Desk, Управление продуктом] Как определить метрики для процесса Управления проблемами (перевод)
  
• [Учебный процесс в IT, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] YC Startup Library на русском: Как создавать и тестировать идеи для стартапов (Майкл Сибель) (перевод)
  
• [Управление разработкой, Управление продуктом] Настроили мониторинг. Что дальше?
  
• [Программирование, Управление проектами, Управление продуктом, Карьера в IT-индустрии] Pet-проекты: зачем они нужны, и стоит ли тратить на это время в 2020 году + опрос

Теги для поиска: #_usability, #_upravlenie_produktom (Управление продуктом), #_stazhirovka (стажировка), #_uxlaboratorija (ux-лаборатория), #_gipotezy (гипотезы), #_produkt_menedzhment (продукт менеджмент), #_blog_kompanii_avito (
Блог компании Авито
), #_usability, #_upravlenie_produktom (
Управление продуктом
)