Короче говоря, когда хороший UX-писатель отдаёт вам результат своей работы, что-то удаляет или говорит «окей», он уже:
● понял, как работает эта конкретная штуковина;
● знает о функциональности элемента или целого продукта всё, что известно продакт-менеджеру, или даже больше;
● может ответить на любой вопрос о том, что было «до» и что станет «после», приведёт вам примеры таких пользовательских ситуаций, о которых вы не могли помыслить;
● учёл кучу разных правил, требований и просто важных мелочей;
● защитил свой текст перед собой или другими профильными профессионалами и готов повторить для вас. А что? Ему ведь тоже интересно, и он не против себя перепроверить – вдруг где-то ошибся.
Глава 5
Что, если всё ещё не нравится? Хорошо, а какие предложения?
Менеджеры одной компании не могли объяснить, что не так с текстами писателя. Все варианты, которые он предлагал, «как-то не нравились». Не в силах определиться, те менеджеры устраивали общие голосования за названия новых возможностей и разделов продукта. Доходило даже до того, что они кидали клич в общем чате, где тусила вся команда – человек сто. Невольным участникам выборов они предлагали проголосовать за уже придуманные варианты или добавить что-то своё. Примерно так:
Коллеги, у нас в сервисе появляется новый раздел, и нам надо его как-то назвать. Мы уже придумали несколько вариантов. Пожалуйста, проголосуйте за один из них или предложите свой:) Вдруг мы что-то пропустили?
● Ромашка.
● Удав.
● Быстрая.
● Смотри!
● Что делать?
● Ничего из перечисленного, у меня свой вариант.
Конечно, люди в чате не старались хотя бы прочесть все предложенные варианты, не то что понять их. Они плевали на смысл и логику, потому что ни особого смысла, ни логики нет и в уже придуманных вариантах. Вместо этого люди замечали только последний пункт и сразу же генерировали десятки своих названий. Естественно, их варианты были такими же разнородными и непонятными, как уже предложенные на голосовании, – просто понравились. Подобный подход создаёт целую кучу проблем.
Во-первых, в поставленной задаче нет ни слова о смысле. Кто-то может возразить: мол, нет, вот же он – надо назвать новый раздел. Но это всего лишь обозначение требуемого результата, и единственный вопрос, который можно задать в этом случае, – «Что?».
– Что надо сделать?
– Назвать новый раздел.
– Подержи моё пиво.
Если мы хотим создавать самый клёвый продукт в мире, то хорошо бы почаще задавать вопрос «Зачем?». Это он заставляет нас искать смысл во всём, что мы делаем: зачем вообще новый раздел, зачем мы решили собрать всё это в нём, зачем не распихали по другим, зачем нам именно такое деление, зачем в качестве примера вы показали мне разнородный и лишённый логики список? Получи я ответы на все эти вопросы, я бы предложил варианты, которые не полетели бы в мусорку сразу. Ну, я на это надеюсь.
И я не говорю, что случайный нейминг не работает совсем. Когда редактор после общих голосований и мозговых штурмов просматривает получившийся список, он обязательно за что-то, да цепляется. В сотне-другой вариантов попадаются и удачные, которые можно объяснить чем-то кроме субъективного «вот это мне нравится». Но большая часть названий при таком бессмысленном подходе к выбору – без минимального погружения участников в тему – не годится.
Во-вторых, голосования в общих чатах отвлекают людей, которые вообще не настроены что-то придумывать и заняты своими задачами. Это наглое воровство времени и денег у компании. Если получатели вашей просьбы привыкли помогать, то они отвлекутся на ваше сообщение в рабочем чате. Ведь там вы с ними обсуждаете только самые важные вопросы, и им нужно прочитать новое сообщение, а может быть, даже ответить. А тут голосование – всё ещё серьёзнее.
И даже если ребята в чатике не отвлекутся прямо сейчас, то они сделают это потом. Вместо выполнения своих обязанностей окружающие вас люди начнут думать над вашей просьбой. Вот они уже задвинули свои задачи в дальний угол и заняты только тем, о чём вы их так нагло попросили. Браво, вы добились своего – всех отвлекли.
В-третьих, подобные кличи о помощи немного, а иногда и порядком унижают людей, которых наняли писать. Это немного личное, что скрывать.
Просить всех что-то вот так бессмысленно попридумывать – как при живом иллюстраторе просить всех членов команды нарисовать варианты логотипа в «Пейнте». Все же умеют немножко рисовать. О, есть вариант даже лучше: давайте попросим своих детей нарисовать логотип компании – места, куда мама или папа уходит каждый день и не возвращается до позднего вечера!
Не надо так. «Как же тогда решать проблемы с писателем?» – спросите вы. Избегать коллективной работы над непрофильными задачами обычно помогает простой разговор с исполнителем. Чтобы он начал писать в точности так, как вам нужно, его приходится направлять. Он же не от себя пишет. Если вы – тот менеджер, которому всё не нравится и который уже почти готов кинуть клич в общем чатике, выясните сначала причину своего недовольства текстами, а затем постарайтесь сформулировать её понятно.
И это не предложение сделать всю работу за того парня. Смотрите, что происходит, когда заказчик необоснованно отказывается принимать текст. Никакой коммерческий писатель не читает чужие мысли и не чувствует всего, что чувствуете вы. Но хороший писатель умеет слушать и всегда старается не просто решить задачу, а сделать это хорошо. Он привык решать её с учётом вообще всех данных, которые удаётся получить любыми способами, в том числе и из будничного трёпа на кухне.
И когда заказчик совсем перестаёт говорить и нормально объяснять, закрывается от исполнителей и превращается в персону-загадку, работа встаёт. Я считаю такое поведение руководителей саботажем – когда менеджеры выставляют себя жутко занятыми, начинают говорить обрывками фраз и шарадами. Вместе с тем они ожидают, что все вокруг начнут мыслить с ними в унисон. Но чудес не бывает, только слепая удача.
А если всё нравится?
Тормозить процесс может и обратная ситуация – когда вы оказываетесь с писателем на одной волне. В таком случае автор текстов осыпает продукт вроде классными вариантами. Вы вместе оказываетесь недостаточно решительными, и настает время а/б-тестов.
Вы наверняка в курсе, что это и как работает, но просто на всякий случай – это такой процесс, в котором мы моделируем разные ситуации и предлагаем их людям. Тот вариант, что вызывает меньше вопросов, берём в работу. При этом пользователи могут даже не замечать, что в чём-то участвуют, они просто тратят больше или меньше времени, чтобы найти то, что им нужно.
Тексты в продукте тоже можно тестировать – как отдельные кнопки или целые пользовательские истории. В некоторых компаниях тестирование именно текстов – уже давно обычная практика. Вливают в один интерфейс разные формулировки, показывают разные версии разным людям и смотрят, какая из них даёт лучшую конверсию.
