Хорошо, если мы понимаем, что успех продукта зависит в том числе и от его речи – от того, как он говорит с пользователями. Так мы приходим к мысли, что пора нанять копирайтера. Сказано – сделано. Вот он уже в команде. И он ноет! Тут в интерфейсе ему места мало, там с логикой что-то не так. Здесь вообще, говорит, не нужна кнопка и текст не нужен. Или не нужно столько текста, сколько на него заложили места в прототипе. Начинает подвывать дизайнер. Разработчики, которые уже залили тексты прямо в код, тоже недовольны – им теперь приходится отыскивать «плохие» строки и менять их на «хорошие». А чем «плохие» плохи, если и с ними было неплохо?
Возникает впечатление, что не того человека писать тексты наняли. На собеседовании вроде нормальный копирайтер был, адекватный, а в команде сразу же повёл себя как капризный ребёнок. И если его сейчас уволить, то кто доделает работу? Новый придёт и тоже начнёт ныть, решит переписывать уже переписанное. Они же как программисты – каждый новый ругает предшественника и говорит, что раньше всё делали не так. Вот он-то – воплощение опыта и всего прекрасного. Он возьмёт ещё полгода и всё сделает как надо. А у нас уже нет половины года. Так продукт никогда не выйдет!
Может, просто первого поздно наняли? Точно! Вот в чём дело. Заменять текстовые заглушки в интерфейсе красивыми осмысленными формулировками в последний момент – одна из грубейших ошибок в разработке продуктов. И что же мы раньше об этом не подумали?
Смотрите, что происходит, когда копирайтера или редактора просят вписать осмысленный текст в уже или почти свёрстанный продукт. Всё начинается с заглушек с шаблонным описанием:
Дальше появляется смысл, но он никак не лезет в установленное кем-то ограничение:
И тут вроде надо расширить блок:
Но дизайнеры против, у них из-за этого всё разъезжается и выглядит некрасиво. И вариант написать в две строки им тоже не нравится. В таком случае ширина блока остаётся прежней, но увеличивается высота:
В итоге страдают все. Много лишней работы появляется не только у редактора, а ещё и у дизайнера и фронтендера. Руководитель группы разработки тоже не сидит на месте и тратит время на переговоры и организацию команды.
Вот рынок мы изучили, персонажей-пользователей собрали по кусочкам – как из деталей конструктора, продумали вроде нормальную логику работы приложения, протестировали прототипы, разработали дизайн и всё запрограммировали. Там процесс, здесь процесс. Всё по науке. Если не считать тексты, которые оставили на потом.
Привлекать писателя только в конце разработки – всё равно что впервые учить человека публично говорить в 22 года. Ему, судя по возрасту, пора защитить диплом, выпуститься из вуза и устроиться на работу, а он, простите, ни бе ни ме.
Не умея говорить и хотя бы рассказывать о себе, молодой специалист устраивается работать в лучшем случае стажёром. А чаще соглашается на место, никак не связанное с только что полученным дипломом. И онлайн-интенсив ораторства, который недавний студент прошёл перед защитой, вообще не помогает.
Обычная и довольно распространённая история – когда недавние выпускники понимают, что пять лет в университете не дали коммуникативных навыков, а с эмоциональным интеллектом и вовсе провал.
С продуктами всё так же. Если они не говорят со своими пользователями или говорят неумело, люди либо не подозревают о каких-то их возможностях, либо считают их использование необоснованно запутанным. В обоих случаях у продукта отсутствует голос, а сам продукт выглядит чем-то непонятным и кажется сложным. В итоге пользователи восклицают: «Фигня какая-то!» – и находят замену.
Глава 2
Что за голос продукта?
Мы – люди и общаемся друг с другом на человеческих языках. Их очень много, в мире насчитывается более 7000 диалектов. Наиболее распространённых, на которых говорит 4/5 населения планеты, – около 80. В России говорят на 37 языках, в том числе на очень редких. Государственный язык, который понимает большинство жителей страны, один.
И если вы выпускаете продукт в России, он точно должен уметь прилично говорить на русском. То есть не так:
Тут стоит задать сразу несколько вопросов разработчикам или менеджеру, который решил показать это сообщение пользователям. Вот что приходит на ум в первую очередь:
Что за запрос такой и почему может возникать ошибка?
Что такое ЦПФЛ?
Что можно сделать в этой ситуации, кроме как «окнуть»?
Зачем так орать на пользователя?
Не будем сейчас искать ответы на эти вопросы. Тем более что просто переписать сообщение по-русски обычно всё равно мало – даже на одном языке можно говорить совершенно по-разному. Ну, примерно на одном языке. Помните, как вы агрились, потому что вас не понимали взрослые? Всё приходилось им разжёвывать, как маленьким. Или, наоборот, как вы объясняли своему ребёнку, что такое лаконичность. Ну или ещё какое-нибудь мудрёное понятие. Вы искали всё новые слова, подбирали выражения вроде понятные, но на деле – ничего подобного. Всё работало против вас, и каждое новое использованное слово тоже приходилось объяснять, чтобы прояснить значение того первого. В итоге вроде простой вопрос выливался в утомительную лекцию.
Чтобы с вашим продуктом не возникало таких проблем, чтобы не приходилось объяснять каждый экран, мало просто расшифровать ЦПФЛ – всё равно не поймут. Продукт должен уметь общаться на простом современном русском языке. Это вам скажет любой человек, который хотя бы немного понимает в текстах.
Поэтому когда я прихожу на новый проект, то сначала стараюсь избавить его речь от всего непонятного и сделать её максимально простой, чтобы уяснить всё самому. Долой жаргонизмы, аббревиатуры и всё подобное. Для понимания какого-то слова нужен словарь? В топку это слово, и словарь туда же. Нужна сноска – слово или целое предложение летит следом. Ничего не понятно, а пальцы уже сами тянутся открыть новую вкладку браузера со статьёй в «Википедии»? Ищем простую и ясную замену.
Смотрите, что происходит, если оставить в интерфейсе непонятные аббревиатуры:
Не разобравшись с тем, что означает МП, автор текста присвоил ему мужской род. Что? Кошелёк. С ним что будет? Он будет отключён. А, ну так и напишем. Но если понять смысл коварной аббревиатуры МП, то оказывается, что всё надо переписать. МП – это мобильное приложение. Оно. И вернее говорить, что оно будет отключено.
И вот когда вы всё высушили и точно поняли, что вообще происходит, пора доставать разноцветные карандаши и ставить продукту голос. Тут действует то же правило, что и в дизайне. Там сначала мы выстраиваем пользовательский опыт и проверяем гипотезы на одноцветных прототипах, а после принимаемся придавать всему определённые формы и цвета.
И насколько скучно пользоваться дизайнерскими прототипами, настолько же скучно пользоваться продуктом, который говорит с нами хоть и понятно, но совершенно безыскусно, бледно. Вернём термины и жаргон, к которым