Этой кнопке нужен текст. O UX-писательстве коротко и понятно

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

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

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

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

Вы ведь ещё помните о голосе продукта? Так вот, а/б-тестирование в процессе – когда вы работаете уже над публичным продуктом – нередко меняет его до неузнаваемости и даже расстраивает. И не только продукт. Из-за радикальных изменений или локальной дичи могут расстроиться и пропасть пользователи.

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

Так как узнать, хороший ли текст?

Коридорными опросами и кличами в рабочих чатиках нельзя, а/б-тесты тоже могут всё разладить. Что же делать? Спокойно, всё не так плохо и безнадёжно. Например, когда в самом деле появляется время на исследование интерфейсных текстов, можно проводить клоуз-тесты.

Этот метод впервые описал в 1953 году Уилсон Тейлор, а сам тест применялся, чтобы проверить понимание контекста. Учащиеся знакомились с материалом, после чего получали связанный с ним текст, который содержал массу пробелов. От студентов требовалось заполнить пробелы теми словами, которые им казались наиболее подходящими для восстановления оригинального смысла. Затем преподаватель собирал работы и сверял с единственным верным вариантом. Чем больше оказывалась доля совпадений, тем выше была оценка. Позже такие тесты стали использовать в изучении иностранных языков.

Здесь всё работает так же. Берёте текст, считаете количество слов в нём, заменяете каждое энное прочерком. В интернете пишут, что в текстах длиной 150–300 слов можно смело скрывать каждое пятое. В интерфейсе, конечно, надо резать каждое третье или даже второе – удаление одного из пяти слов в коротких текстах не даст нужного эффекта.

Затем само тестирование: дайте людям контекст и предложите заполнить пробелы. Когда они справятся с задачей, останется лишь сравнить их варианты с оригинальными. Если респондентам удастся восстановить контекст и содержимое совпадает хотя бы процентов на 60–70, то в оригинале тексты хорошие. Можно оставить всё как есть. Если совпадений меньше, то, возможно, стоит всё переписать и повторить.

В таком способе тестирования меньше математики со статистикой и больше смысла. Пускай намного больше ручной работы. Но только так удаётся узнать не что принципиально лучше – «вариант а» или «варик б», а протестировать единственный текст, который хочется видеть в продукте.

Когда нет времени на тестирование и решить нужно прямо сейчас

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

Так что когда вам не нравится результат работы писателя, либо нормально объясните, что именно не так, либо лейте в продукт вариант «болие-лимение» (и такой мем есть).