Кирилл Егерев - Этой кнопке нужен текст [O UX-писательстве коротко и понятно] [litres]

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

И когда заказчик совсем перестаёт говорить и нормально объяснять, закрывается от исполнителей и превращается в персону-загадку, работа встаёт. Я считаю такое поведение руководителей саботажем – когда менеджеры выставляют себя жутко занятыми, начинают говорить обрывками фраз и шарадами. Вместе с тем они ожидают, что все вокруг начнут мыслить с ними в унисон. Но чудес не бывает, только слепая удача.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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