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

Не надо так. «Как же тогда решать проблемы с писателем?» – спросите вы. Избегать коллективной работы над непрофильными задачами обычно помогает простой разговор с исполнителем. Чтобы он начал писать в точности так, как вам нужно, его приходится направлять. Он же не от себя пишет. Если вы – тот менеджер, которому всё не нравится и который уже почти готов кинуть клич в общем чатике, выясните сначала причину своего недовольства текстами, а затем постарайтесь сформулировать её понятно.

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

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

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

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

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

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

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

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

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

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

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