Хроники тестирования. Пролог: Зачем нам тестировать?

Vanilla Thunder
DesignSpot
Published in
5 min readSep 8, 2023

--

Не мало слов уже было сказано о том, что старые методы разработки утратили свою актуальность. Раньше мы могли тратить десятки миллионов просто на то, чтобы 4 года пилить какой-то продукт, узнать, что он никому не нужен, пожать плечами и двигаться дальше. Сейчас такой номер не пройдёт. Все хотят знать, будет ли идея работать до того, как потратят хоть цент. Эксперимент стал современной необходимостью, а без принципа “Fail fast” невозможно представить ни одно начинание.

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

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

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

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

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

С чего начинается тестирование?

Нельзя просто так взять и начать тестировать непонятно что. Сперва нам нужно обзавестись предположениями или гипотезами о том, какую реакцию пользователей или рынка вы ожидаете. Гипотезы могут и должны существовать ещё до начала тестирования, и даже инициировать его. Но откуда они берутся?

Вопрос очень хороший, спасибо, что спросили. Есть несколько способов генерации гипотез:

  • Они могут диктоваться доменом. То есть появлением новых технологий, позволяющих реализовывать всё более сложные функции, как, например, персонализация или имплементация LLM. Вы хотите проверить применимость новой технологии на вашем продукте и строите гипотезу.
  • Гипотезы могут рождаться полем, то есть авторитетными представителями домена, типа крутых компаний-конкурентов, которые запиливают новшество, и вам нужно понять, будет ли это работать в вашем контексте.
  • Гипотезы могут выводиться из здравого смысла и экспертного мнения, когда вы, обладая некоторым опытом в своём деле, можете провести экспертную оценку и методом банальной логики сформулировать предположения о том, как можно было бы улучшить взаимодействие или вообще создать нечто новое.
  • Гипотезы могут основываться на результатах обзорного исследования, где мы выявляем цели пользователя, его проблемы и ментальную модель. Предположения о том, что подогнав взаимодействие к этим данным мы сделаем пользователю хорошо, это и есть гипотезы.
  • Ну и конечно, моё любимое. Гипотезы могут вытекать из фонтана мысли вашего CEO или менеджера, только поступать они будут не в виде предположений, нуждающихся в доказательствах, а в виде директивных указаний.

Сейчас в мире преобладают представления о продуктовых гипотезах, которые строятся по следующему шаблону:

Если мы сделаем то-то (запилим новую фичу в продукте, изменим текущее поведение, создадим новый продукт и т.д.), то мы получим такую-то реакцию (привлечём новую аудиторию, пользователи станут довольнее, получим прирост конверсии и т.д.), что отразится на таких-то показателях (число активных пользователей, прибыль с пользователя, капитализация компании и т.д.).

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

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

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

Когда продукт уже готов, то с поиском предположений для проверки проблем обычно не возникает: мы можем своим мудрым глазом посмотреть на флоу пользователя и выделить предположительные «узкие места». Таким образом, гипотезы чаще всего предполагают какой-то эффект от действий с нашей стороны. Например, «Если мы изменим лейаут нашего каталога с карточек на листинг, то пользователям станет удобнее пользоваться каталогом». Самая, что ни на есть гипотеза, пока не пригодная для тестирования, но эту проблему мы обсудим позже. Но это, если у нас есть что пощупать. А когда нет?

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

Конечно, методы тестирования будут отличаться, ведь в одном случае у нас есть доступ к готовому продукту, у которого уже есть пользователи, и можно произвести базовые замеры, чтобы проводить сравнение. А во втором случае ничего нет, кроме рожденных сознанием фракталов. И что с ними делать, с первого взгляда, непонятно. С них, пожалуй, и начнем… или продолжим.

Также напомню, что у меня есть канал в телеграм, где я ненавязчиво делюсь новостями, статьями и своими мыслями к ним.

--

--