(Вы читаете перевод ускоренного курса UX. Курс включает 30 вопросов, которые встречаются на старте карьеры: UX Crash Course: 30 Std Questions. Если вы здесь впервые, то лучше начните сначала).
Что стоит проA/B-тестировать?
Суть A/B-теста в том, что вы проектируете более одной версии чего-либо, одновременно запускаете эти версии и равномерно распределяете пользователей, чтобы понять, на какую из версий больше кликают, где больше покупают и т.п.
Определив лучшую версию, вы оставляете лишь ее и убираете все остальные.
Так что же тестировать таким способом?
Глупый ответ:
“Можно A/B-тестировать все, что захотите!”
Нет, с технической точки зрения это реально, но 99% из того, что вы можете протестировать, того не стоит.
Настоящий ответ:
Пусть ваши A/B-тестирования будут сфокусированы на ключевых бизнес-метриках. Конверсия, продажи, вовлеченность, просмотры страницы, показатель отказов на лендинге — и прочие подобные им.
И еще, стоит тестировать те вещи, к которым сложно подобраться через опросы пользователей и сбор данных.
Психологические вещи.
Если у вас магазин, торгующий товарами, — сконцентрируйтесь на продуктовых страницах и страницах оплаты. Ну, может быть, еще на результатах поиска.
В общем, на том, что ведет к покупкам.
Если вы генерируете лиды для продаж, тестируйте только те вещи, которые заводят посетителя дальше лэндинга: например, формулировка заголовка, фотографии продукта, контрастность кнопки, дизайн форм и т.п.
В общем, то, что даст вам больше лидов.
А если у вас сайт со звериным порно, тогда тестируйте … ну, например … короче, суть вы поняли.
Вот почему этот вопрос совсем не глупый:
Вы тестируете не элементы дизайна. Вы тестируете гипотезы.
Я постоянно сталкиваюсь с A/B тестами, которые направлены на проверку случайных догадок. А иногда опции тестируются только потому, что два человека, далеких от UX, не смогли решить, какой вариант нравится им больше.
Они, например, могли бы тестировать такие варианты кнопок:
Вариант А: “Нажми сюда!”
Вариант Б: “Начать сейчас!”
Вариант В: “Сексуальные трусики!”
Когда тест будет завершен, они будут знать, какой вариант лучще, но никогда не узнают почему.
Вместо этого, нужно разработать гипотезу, которая опишет причину, по которой люди кликают (или не кликают) на кнопку. И тестирование нужно для того, чтобы проверить эту гипотезу.
Гипотеза: “Пользователь нажмет на кнопку, если будет знать, что перейдет на страницу с игрой”.
Вариант А: “Начать сейчас!”
Вариант Б: “Играть сейчас!”
“Начать сейчас” не имеет никакого отношения к игре, поэтому, если гипотеза верна, этот вариант должен проиграть.
“Играть сейчас!” явно сообщает, что игра начнется сразу после нажатия на кнопку, так что этот вариант должен выиграть.
А если гипотеза не верна, результаты будут отличаться от предполагаемых.
Контролируйте результаты.
Старайтесь, чтобы варианты А и Б вашего тестирования были максимально похожи друг на друга — так вам будет понятнее, какая именно деталь влияет на результат.
Например, если бы мы провели подобный тест с такими вариантами…
Вариант А: “Начать”
Вариант Б: “Играть в удивительную игру недели прямо сейчас!”
… то фактором выбора могла бы быть длина фразы, а не только упоминание игры.
Если хотите “поиграть” с длиной фразы, тестируйте сопоставимые по длине варианты. Кроме того, вы можете параллельно протестировать различные формулировки, вот так:
Вариант А: “Начать!”
Вариант Б: “Играть!”
Вариант В: “Начать сейчас!”
Вариант Г: “Играть сейчас!”
Вариант Д: “Начать это сейчас!”
Вариант Е: “Играть в игру сейчас!”
Если изначальная гипотеза верна, версии, в которых упоминается игра, обойдут версии, где она не упоминается. Если вы тестировали вторую гипотезу, что короткие формулировки лучше длинных, то короткие версии должны одержать победу над длинными.
Этот тест займет больше времени — ведь в нем больше вариантов — но вы проверите сразу две ващи.
(Лучшие A/B-тесты — и лучшие UX-дизайнеры — тестируют только одну вещь за раз. Так что не увлекайтесь).
Завтра мы ответим на вопрос: “Сколько стоит A/B-тест?”