Кирилл Егерев

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

Редактор А. Новресли

Главный редактор С. Турко

Руководитель проекта Л. Разживайкина

Корректоры Е. Аксёнова, Т. Редькина

Компьютерная верстка К. Свищёв

Художественное оформление и макет Ю. Буга

© Кирилл Егерев, 2021

© ООО «Альпина Паблишер», 2021

Все права защищены. Данная электронная книга предназначена исключительно для частного использования в личных (некоммерческих) целях. Электронная книга, ее части, фрагменты и элементы, включая текст, изображения и иное, не подлежат копированию и любому другому использованию без разрешения правообладателя. В частности, запрещено такое использование, в результате которого электронная книга, ее часть, фрагмент или элемент станут доступными ограниченному или неопределенному кругу лиц, в том числе посредством сети интернет, независимо от того, будет предоставляться доступ за плату или безвозмездно.

Копирование, воспроизведение и иное использование электронной книги, ее частей, фрагментов и элементов, выходящее за пределы частного использования в личных (некоммерческих) целях, без согласия правообладателя является незаконным и влечет уголовную, административную и гражданскую ответственность.

⁂

Моей жене:

Красотка, я тебя люблю:-P

От автора

Как появилась идея всё это написать и зачем вам читать эту книгу

Привет, меня зовут Кирилл. Я профессионально пишу за деньги и около десяти лет делаю это для интерфейсов. Да-да, за тот текст в меню, на кнопках, в предупреждениях, формах обратной связи, сообщениях об ошибках и в прочих подобных штуках тоже кто-то отвечает.

Раньше такие тексты писали менеджеры и дизайнеры. В лучшем случае их проверял на опечатки и пунктуацию кто-то с хорошим русским языком. Затем эту обязанность «сгрузили» на копирайтеров и редакторов. Теперь есть специальный термин и целая новая профессия – UX-писатели.

Идея написать эту книгу появилась как ответ на очередной вопрос «Что почитать по UX-писательству?». Пожалуй, она могла бы и не выйти, если б не дизайнеры, с которыми я сейчас работаю в Сбере. Спасибо, ребята. Спасибо за вопросы про прикладной текст и всем остальным, кто их задавал, – в «Яндексе», «Иннове» и «Айгайдсе», «Айфонсе» и «Аймобилке», где мне посчастливилось поработать. Ай, как много всего в России начинается на «Ай».

Отвечая на подобные вопросы, я много раз рекомендовал читать что-то о чистоте мыслей в голове и на письме – Корнея Чуковского, Нору Галь, Уильяма Зинсера. Все они хороши. Жаль, что не всегда это то, что надо. Никто из этих авторов не писал именно про текст в интерфейсе, хотя все ратовали за принципы, которых я сейчас придерживаюсь в своей работе.

Совсем недавно Максим Ильяхов собрал, осмыслил и модернизировал многое, о чём говорили в XX веке именитые писатели, редакторы и переводчики. Максим напомнил нам, что с тех пор ничего не изменилось. И это даже к лучшему: он, можно сказать, создал для многих пишущих людей хорошие рабочие места. На живых примерах Ильяхов показал владельцам продуктов, что платить писателю за каждую тысячу знаков – это даже не прошлый, а позапрошлый век. Текст не выйдет хорошим, если его цена растёт с объёмом. Цена растёт – ценность падает.

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

Уже тогда мне поступало много задач вроде «вычитать текст на лендинге, особенно кнопки и всё, что с ними непосредственно связано» и «глянуть скрипт для службы поддержки». Я смотрел то, о чём меня просили, и задавал странные вопросы: «А почему? Зачем? Для кого это? Как посетитель попал сюда и что будет после нажатия вот этой кнопки?» В современной рабочей среде такие вопросы – обычное дело. Но в начале 2010-х годов в большинстве случаев от копирайтера требовалось прочитать задание и выполнить всё, что в нём написано. В точности. А вопросы – для слабаков.

Уверен, Илья больше не спрашивает у своих студентов, зачем они пришли. Теперь всё настолько взаимосвязано, что невозможно чётко разделить процессы. Больше нельзя планировать по принципу «вначале мы только проектируем и рисуем дизайн, а слова вставим в самом конце». Хорошего результата не достичь, если выстраивать работу разных специалистов отдельно друг от друга.

Я решил написать эту книгу, чтобы упорядочить собственный опыт в UX-писательстве. Разложить всё по полочкам и для самого себя в том числе.

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

Хочется верить, что менеджерам книга поможет понять, зачем в команде UX-писатель и почему никто другой не должен брать на себя его обязанности. Мы же не заставляем иллюстраторов программировать, так почему же Фёдор из бухгалтерии должен вычитывать всё, что написали дизайнеры? Ну, пятёрка у него по русскому и врождённая грамотность, что с того?

Дизайнеры, скорее всего, найдут много общего между своей работой и работой редактора – поймут всю бессмысленность просьбы «написать текст вот сюда, потому что именно тут для него выделено определённое место». Или даже научатся сами писать с первого раза так, что редактору Виталине останется лишь «окнуть». Так тоже бывает.

Начинающим UX-писателям – бывшим журналистам, корректорам и людям прочих близких профессий – книга должна дать новые знания. А если нет, то хотя бы упорядочить те, что уже есть, и… помочь узнать что-то новое! Со мной такое много раз случалось – попытки всё упорядочить приводили к обретению знаний.

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

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

Я в самом деле надеюсь, что с утверждениями, приведёнными в книге, будут не только соглашаться, но она вызовет желание поговорить. И если молчать нет сил, напишите мне на ux@egerev.ru. Общаясь, мы отыщем истину и как-то поучаствуем в формировании новой профессии.

Предисловие

Что такое пользовательский опыт и при чём тут слова

«Да ну на фиг!» – сколько раз я, вы, все мы выкрикивали это или даже нечто грубее. Не понимали, как работает что-то новое, и бросали попытки разобраться в этом. Это непонимание возникает у нас при использовании многих цифровых продуктов – сайтов и мобильных приложений. Неприятные ситуации происходят и повторяются вообще всегда, когда мы как пользователи сталкиваемся с чуждой нам логикой и непривычными механиками.

Команда разработки может придумывать и делать удивительные вещи. И все их предположения могут оказаться ненужными нам, пользователям. Или востребованные функции будут реализованы настолько неудобно, что мы примемся вот так вскипать и бросать даже самые замечательные продукты.

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

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

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

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

Сами посмотрите: ниже два совершенно одинаковых меню с одинаковым внешним видом – дизайном. Однако меню находятся в разных местах экрана – пользовательский опыт различается.

Чтобы дотянуться до меню на левом рисунке, нужно раза в два «растянуть» большой палец руки, в которой вы держите телефон, или задействовать вторую руку.

Меню в верхней части экрана унаследовано от старых устройств. Сначала такие элементы навигации скопировали из продуктов для компьютера на коммуникаторы со стилусами. Как на компе работает, так и на мобиле пускай будет. И это было нормально – пользователи всё равно управлялись с устройствами с помощью двух рук: в одной держали коммуникатор, а в другой – стилус, которым тыкали в экран. Потом эти верхние меню переехали как есть на смартфоны с ёмкостными экранами, которые воспринимают не точечное нажатие с усилием, а прикосновение пальца живого человека. И вот тут дизайнеры поняли, что на таких мобильных устройствах меню наверху – неудобно. Исправили это не сразу и не во всех продуктах – до сих пор встречаются «динозавры». Но в основном навигационные меню сейчас располагаются в нижней части экрана – как на примере справа. Вы можете убедиться в этом сами – посмотрите приложения на вашем смартфоне.

Всё это хорошо. Но всё же при чём тут слова?

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

Бывает, люди даже читают всё, что написано на экране: пункты меню, объясняющие фрагменты текста, заголовки, надписи на кнопках, всплывающие подсказки, примеры заполнения форм, предупреждения, сообщения об ошибках и многое другое. Чаще всего подобное происходит при взаимодействии с совершенно новыми или значительно обновлёнными продуктами. Тут особенно важно, как вы всё сформулируете.

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

Исправили ошибки, устранили недочёты.

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

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

Помните, как приложение вылетало при редактировании профиля? Так вот, разработчики говорят, что устранили все возможные причины этого.

И дополнить общим:

Заодно мы поправили разные мелочи. Попробуйте сделать всё то, что раньше вызывало ошибки. Если заработает как надо – хорошо. А если нет – напишите нам о недочётах на почту саппорт@нашапочта.ру. Постараемся помочь.

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

Идём дальше. Если в приложении появилось что-то полезное, не только исчезли ошибки, то при первом запуске сразу после обновления вы можете показать пользователям экран с рассказом о новинках. Или два, три экрана – насколько у вас хватит фантазии, а у пользователей – терпения:

Ладно, вот вы рассказали обо всех нововведениях. Или люди нажали на крестик в углу первого же сообщения и поспешили перейти к обычным сценариям использования приложения. Но вдруг что-то пошло не по сценарию и в приложении появилось сообщение об ошибке. Допустим, вы в любом случае увидите код ошибки в логах и поймёте её суть. А пользователю решили ничего не объяснять, для него написали максимально коротко и по делу:

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

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

Вот теперь наверняка ясно, что именно произошло и что делать, чтобы подобные сообщения больше не показывались.

Ещё раз взглянем на варианты. Первый, самый короткий, часто даже не пишут, а накидывают из-за отсутствия времени «на такие мелочи». Это скорее дежурная заглушка, которую иногда забывают заменить на что-то осмысленное, – так и уходит в релиз. Без обид и претензий – вариант разработчиков.

Второй вариант может написать копирайтер, которому как-то формулируют задачу – просят рассказать о том, что произошло. Такой текст пишется перед выпуском продукта, когда кто-то внезапно вспоминает: «Ой, у нас же там заглушка!»

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

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

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

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

Как читать эту книгу

Как многие нехудожественные издания, эту книгу можно читать почти в любой последовательности и даже не целиком.

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

Если вам нужно «только один хороший интерфейс написать», то будет достаточно третьей части. Полистайте её. После напишете всё максимально нейтрально по шаблону и сдадите проект, а дальше будь что будет.

Если вам захочется в самом деле понять, почему исходные примеры в третьей части плохие, зачем их переписывать и какими правилами можно руководствоваться в работе, начните читать книгу со второй части. В ней всего четыре главы, и все про принципы, которые я обычно применяю. Это они, те принципы, заставляют меня и многих других UX-писателей писать определённым образом. Во второй части я отвечаю только на один вопрос: «Как?»

В первой части, где я постарался найти ответы на максимум вопросов, больше всего слов и, по мнению некоторых, меньше дела. В ней есть советы и для UX-писателей по работе в команде, и для руководителей, которым бывает трудно понять людей относительно новой профессии. Первые несколько глав я говорю об обычных трудностях в команде и способах их решения.

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

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

Часть I

Глава 1

Кто прочитает всё это?

В начале работы над продуктом мы уже примерно понимаем его аудиторию – знаем всех, кто станет им пользоваться в первую очередь. Мы представляем себе определённые группы людей – им сколько-то лет, у них схожие привычки и доход, свой распорядок дня и ещё масса объединяющих группу параметров. Все наши будущие пользователи имеют выдуманные нами потребности, которые «закроет» наш продукт. С этим знанием у нас и появилась идея создать нечто новое.

Ну, или мы лишь примерно представляем себе, что нужно людям. Так тоже можно в самом начале. Мы примерно понимаем, что именно должны сделать, чтобы заполучить свою долю рынка, и этого уже достаточно.

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

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

Завершаем этап проектирования пользовательского опыта и начинаем «накидывать» реальный внешний вид продукта. Допустим, мы задумали выпустить мобильное приложение. У него появляются свои цвета и формы. Логика, о которой раньше мы только думали и которую закладывали в прототипы, обретает чёткие очертания.

Наступает тот момент, когда проект уже должен показать себя, – пора его представить людям. И тут мы понимаем, что не можем собрать приличную версию. Большинство текстовых блоков, сообщений об ошибках, подсказок и кнопок заполнено обычными «рыбными» текстами:

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

Хорошо, если мы понимаем, что успех продукта зависит в том числе и от его речи – от того, как он говорит с пользователями. Так мы приходим к мысли, что пора нанять копирайтера. Сказано – сделано. Вот он уже в команде. И он ноет! Тут в интерфейсе ему места мало, там с логикой что-то не так. Здесь вообще, говорит, не нужна кнопка и текст не нужен. Или не нужно столько текста, сколько на него заложили места в прототипе. Начинает подвывать дизайнер. Разработчики, которые уже залили тексты прямо в код, тоже недовольны – им теперь приходится отыскивать «плохие» строки и менять их на «хорошие». А чем «плохие» плохи, если и с ними было неплохо?

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

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

Смотрите, что происходит, когда копирайтера или редактора просят вписать осмысленный текст в уже или почти свёрстанный продукт. Всё начинается с заглушек с шаблонным описанием:

Дальше появляется смысл, но он никак не лезет в установленное кем-то ограничение:

И тут вроде надо расширить блок:

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

В итоге страдают все. Много лишней работы появляется не только у редактора, а ещё и у дизайнера и фронтендера. Руководитель группы разработки тоже не сидит на месте и тратит время на переговоры и организацию команды.

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

Привлекать писателя только в конце разработки – всё равно что впервые учить человека публично говорить в 22 года. Ему, судя по возрасту, пора защитить диплом, выпуститься из вуза и устроиться на работу, а он, простите, ни бе ни ме.

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

Обычная и довольно распространённая история – когда недавние выпускники понимают, что пять лет в университете не дали коммуникативных навыков, а с эмоциональным интеллектом и вовсе провал.

С продуктами всё так же. Если они не говорят со своими пользователями или говорят неумело, люди либо не подозревают о каких-то их возможностях, либо считают их использование необоснованно запутанным. В обоих случаях у продукта отсутствует голос, а сам продукт выглядит чем-то непонятным и кажется сложным. В итоге пользователи восклицают: «Фигня какая-то!» – и находят замену.

Глава 2

Что за голос продукта?

Мы – люди и общаемся друг с другом на человеческих языках. Их очень много, в мире насчитывается более 7000 диалектов. Наиболее распространённых, на которых говорит 4/5 населения планеты, – около 80. В России говорят на 37 языках, в том числе на очень редких. Государственный язык, который понимает большинство жителей страны, один.

И если вы выпускаете продукт в России, он точно должен уметь прилично говорить на русском. То есть не так:

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

Что за запрос такой и почему может возникать ошибка?

Что такое ЦПФЛ?

Что можно сделать в этой ситуации, кроме как «окнуть»?

Зачем так орать на пользователя?

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

Чтобы с вашим продуктом не возникало таких проблем, чтобы не приходилось объяснять каждый экран, мало просто расшифровать ЦПФЛ – всё равно не поймут. Продукт должен уметь общаться на простом современном русском языке. Это вам скажет любой человек, который хотя бы немного понимает в текстах.

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

Смотрите, что происходит, если оставить в интерфейсе непонятные аббревиатуры:

Не разобравшись с тем, что означает МП, автор текста присвоил ему мужской род. Что? Кошелёк. С ним что будет? Он будет отключён. А, ну так и напишем. Но если понять смысл коварной аббревиатуры МП, то оказывается, что всё надо переписать. МП – это мобильное приложение. Оно. И вернее говорить, что оно будет отключено.

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

И насколько скучно пользоваться дизайнерскими прототипами, настолько же скучно пользоваться продуктом, который говорит с нами хоть и понятно, но совершенно безыскусно, бледно. Вернём термины и жаргон, к которым привыкли пользователи. Стоп, что? Да, в использовании специальных словечек нет никакой проблемы, если они вписаны в интерфейс сознательно и гармонично, если их присутствие объяснимо.

На иллюстрации выше показана часть интерфейса приложения для заказа бетона в машине-миксере – бетономешалке. Обычно товары в магазинах складывают в корзину. Но согласитесь, класть четыре кубометра бетона в корзину как-то странно. Бетон куда логичнее и лучше заливать – он же жидкий. Однако в бетономешалку заливать бетон получается слишком длинно – слово длинное. Заливать в миксер? Скучно и чуть ли не по-научному. О! А давайте лить в барабан.

Допустим, пользователь всё понял, это написано на русском языке. Он ввёл четыре кубометра, но тут его что-то отвлекло. Оставил приложение на какое-то время без присмотра, а когда вернулся, то увидел такое:

Ещё одна неудача: продукт не знает, как общаться с человеком. И это снова мы упустили, не научили его.

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

Голос продукта – как голос человека. Если он достаточно для меня хорош, я заинтересуюсь, вступлю в диалог и с радостью продолжу интересное для меня общение. Если нет, то я просто пройду мимо или постараюсь поскорее закончить навязанную беседу.

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

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

Избавиться от подобного помогает добавление голосу тона и изменение этого тона в зависимости от ситуации.

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

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

Глава 3

А если автор видит иначе и хочет делать всё по-своему?

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

В процессе работы хорошего UX-писателя должен появляться текст без личного мнения и суперкреативного «вкусного» авторского подхода. Конечно, если «ароматное» видение автора совпадает с чётко определённым стилем продукта, то пускай автор пишет, как ему подсказывает сердечко. Однако это очень редкий случай.

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

И с этим может возникнуть проблема. UX-писатель – всегда человек. Я – человек. Могу не выспаться, и весь день насмарку, проснуться с мыслями о несговорчивом заказчике и о том, что сегодня мне снова придётся ему что-то аргументированно и последовательно доказывать. А он может не слушать. Я могу не успеть переключиться с одного проекта на другой в течение дня или просто задуматься о личных делах и в спешке отправить на согласование не лучший результат работы: «Самому стыдно, не понимаю, как я мог подобное написать и пытаться выдать за качественную работу». Ничего хорошего я в подобных случаях не делал и не сделаю.

Да, я делал плохо. Мне случалось переключаться с задачи на задачу, но забывать переключаться с проекта на проект. Иногда в течение одного дня я отправлял на согласование текст для условного «Проекта А», принимался за условный «Проект Б», погружался во второй, тут мне прилетали комментарии по тексту к первому проекту, я открывал письмо – и всё. Привет.

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

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

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

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

Да, бывает и редакторский гайдлайн. Он как устав или конституция целой страны, но не настолько масштабный. Вроде главного документа для всех, кто пишет в компании. Обычно он целиком про текст и голос в рамках одного продукта. Часто его создаёт главный редактор или приглашённые специалисты, нередко – единственный копирайтер или UX-писатель. Гайдлайном могут пользоваться все сотрудники, таким образом экономится много общего времени. Хочешь хороший текст – пишешь сам. Выходит плохо – правишь по гайдлайну.

Без гайдлайна продукт «загуляет». Если у него не будет чётко сформулированных характера, голоса и дозволенных тональностей, он так и останется чем-то бесформенным. Бесформенность эта породит вседозволенность, вседозволенность приведёт к тому, что всё написанное в какой-то момент придётся выкинуть и переписать с нуля. Результат получится настолько уродливым, что дешевле будет отказаться от него полностью, а не пытаться менять там и здесь.

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

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

Я пришёл к этой мысли на собственном опыте только в 2011 году, когда меня пригласили в «Иннову». Компания занималась адаптацией онлайн-игр, и в числе прочего нужно было писать рекламные ролики и лендинги для продвижения новинок и обновлений.

Мне доверили работу над лендингом серьёзного обновления Lineage II, и я «ушёл подумать» на два дня. Я честно трудился всё это время – перечитал много прошлых лендосов, расковырял форум, использовал свои новые знания и общее ощущение от продукта для решения задачи, выполнил каждый её пунктик. Смотрел на получившийся текст и радовался – таким задорным и хорошим он мне казался. А потом я показал его заказчику и рухнул с небес на землю. Оказалось, что оба дня я занимался какой-то чушью и сделал всё совсем не так.

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

Если коротко, то продукт не должен был отражать свою аудиторию, а мне не стоило искать вдохновения на форуме. Из-за этого тексты вышли бессвязными, громоздкими, слабыми и даже жуткими. От меня ждали другого. Я спросил, что же делать. Руководитель посоветовал мне не уходить в себя, а работать более открыто и короткими итерациями, поговорить с другими ребятами, которые уже давно на проекте и лучше его чувствуют. Неожиданно посоветовал почитать Чехова. Да, Антона Палыча. Тогда, во вторник, я последовал всем советам, и уже в пятницу у нас был лёгкий текст для лендинга, который всем понравился. Спасибо, Микаэл, я всё помню.

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

Глава 4

А нужен ли тут текст вообще?

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

А нужен ли тут текст вообще?

К чему он здесь?

Какую функцию он выполняет?

Какая от него польза для людей?

И чем он помогает продукту?

Во-первых, текст в продукте не должен и не может заполнять пустоту. Он – не современный российский сериал и не американский ситком 1980-х. Поэтому, когда ко мне приходят с просьбой «написать что-то вот сюда, потому что тут предусмотрели место для текста», я в ответ заваливаю заказчиков вопросами, смысл которых легко сводится к паре слов: «К чему?» Предусмотрели – хорошо. Спасибо, что позаботились и о писателе – обеспечили работой человека. Но почему пользователям непременно нужен текст – именно здесь и вот такого объёма? Что тем несчастным с этим блоком текста делать? Какой от него прок?

Например, в уведомлении ниже заголовок говорит о готовности чего-то, а текст под ним – о том, что показан какой-то пример. Так что оставлять их рядом – ошибка уровня тавтологии. Сами посмотрите, как некрасиво. И если вам захотелось избавиться от чего-то одного – уже хорошо. Лучше, конечно, от менее наполненного смыслом «готово».

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

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

Вообще, если писатель хороший, то это такая заноза, которая иногда больше спрашивает, чем отвечает. Бывает, смотришь на результат его работы и диву даёшься: о чём он целый день трещал со всеми? Написал-то всего две строчки или даже всё удалил. Ещё и дизайнеры теперь задумали всё менять. Ну что за гнус? Человек – палка в любимом колесе вашей гладкой разработки. Не переживайте. Скорее всего, те две строки будут нужными. А запланированное в интерфейсе может оказаться бессмысленным хламом, который давно пора переосмыслить. И хорошо, что дизайнеры видят это сейчас, а не за день до уже анонсированного релиза.

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

Текст всегда пишется с какой-то целью.

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

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

Знаю много красивых проектов, с которыми все носились неделю, две, месяц, а после забывали и забрасывали. Да, выглядели они просто замечательно, возможности предоставляли оригинальные. Но, как ни примеряли их пользователи, так и не поняли, что с ними делать. Вы, наверное, тоже вспомните такие.

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

Вы же не рисуете кнопки только потому, что их надо нарисовать? Вроде как в других продуктах делают, так и вашему подойдёт – скопипастить всё и задачу побыстрее закрыть. Нет, не ваш метод? И меню чужие вы не копируете «в ноль» бездумно. Даже если подсматриваете чужие примеры, как все делают, то всегда адаптируете их под свои нужды. И в работе каждого специалиста в вашей команде есть такой же смысл – менеджеры, дизайнеры и люди других профессий не делают ничего совсем без причины. Так позвольте эту роскошь и своему UX-писателю.

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

И кстати, текста не всегда выходит мало. Например, бывают ситуации, когда нужно рассказать всё очень подробно и впихнуть в экран кучу разных подсказок. Со мной, как с любым UX-писателем, такое не раз случалось. Приходил заказчик и формулировал задачу словами вроде «тут на пару минут, посмотри, нормально ли мы кнопку назвали». Я начинал задавать вопросы: «А что именно делает эта кнопка, что было до того, что будет после? А если её нажать, то что? А если что-то где-то пойдёт не так?» Задача из двухминутной превращалась в получасовую, затем появлялись ещё вопросы насчёт окружения кнопки, потом ещё. Задача растягивалась на час, полтора, два. Кнопка тем временем обрастала текстом, вокруг появлялись всё новые подсказки. Сама она в ходе обсуждения могла исчезнуть или быть заменённой на что-то более подходящее в нашей ситуации. Порой менялась механика, с которой приходил заказчик. И вот финальное согласование. Сидим, смотрим на получившийся экран, который вырос из просьбы глянуть всего одно слово. Сравнивая новый вариант с изначальным, мы видим две совершенно разные картинки, но результат нам обоим нравится.

Да, в сравнении с оригиналом у нас в таких случаях получается что-то очень громоздкое. Но тут надо ответить себе на вопрос: «А можем ли мы что-либо выкинуть без потери смысла для пользователя?» Если ответ «нет» и все добавки на своих местах, то проблема как раз в излишне коротком оригинале – в той вылощенной и красивой пустоте. В этот раз бессмысленной. Из-за неё у пользователей могли и должны были возникнуть вопросы, ни на один из которых наш продукт не давал ответа. А теперь он даёт, и ещё как! Даже если что-то будет непонятно, что-то не получится с первого раза, люди смогут решить большую часть проблем на месте. Увидят все подсказки, сообщения об ошибках, им не придётся напрягать службу поддержки и тратить наше и их время. Ну, мы же предусмотрели все возможные пользовательские ситуации.

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

Короче говоря, когда хороший UX-писатель отдаёт вам результат своей работы, что-то удаляет или говорит «окей», он уже:

● понял, как работает эта конкретная штуковина;

● знает о функциональности элемента или целого продукта всё, что известно продакт-менеджеру, или даже больше;

● может ответить на любой вопрос о том, что было «до» и что станет «после», приведёт вам примеры таких пользовательских ситуаций, о которых вы не могли помыслить;

● учёл кучу разных правил, требований и просто важных мелочей;

● защитил свой текст перед собой или другими профильными профессионалами и готов повторить для вас. А что? Ему ведь тоже интересно, и он не против себя перепроверить – вдруг где-то ошибся.

Глава 5

Что, если всё ещё не нравится? Хорошо, а какие предложения?

Менеджеры одной компании не могли объяснить, что не так с текстами писателя. Все варианты, которые он предлагал, «как-то не нравились». Не в силах определиться, те менеджеры устраивали общие голосования за названия новых возможностей и разделов продукта. Доходило даже до того, что они кидали клич в общем чате, где тусила вся команда – человек сто. Невольным участникам выборов они предлагали проголосовать за уже придуманные варианты или добавить что-то своё. Примерно так:

Коллеги, у нас в сервисе появляется новый раздел, и нам надо его как-то назвать. Мы уже придумали несколько вариантов. Пожалуйста, проголосуйте за один из них или предложите свой:) Вдруг мы что-то пропустили?

● Ромашка.

● Удав.

● Быстрая.

● Смотри!

● Что делать?

● Ничего из перечисленного, у меня свой вариант.

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

Во-первых, в поставленной задаче нет ни слова о смысле. Кто-то может возразить: мол, нет, вот же он – надо назвать новый раздел. Но это всего лишь обозначение требуемого результата, и единственный вопрос, который можно задать в этом случае, – «Что?».

– Что надо сделать?

– Назвать новый раздел.

– Подержи моё пиво.

Если мы хотим создавать самый клёвый продукт в мире, то хорошо бы почаще задавать вопрос «Зачем?». Это он заставляет нас искать смысл во всём, что мы делаем: зачем вообще новый раздел, зачем мы решили собрать всё это в нём, зачем не распихали по другим, зачем нам именно такое деление, зачем в качестве примера вы показали мне разнородный и лишённый логики список? Получи я ответы на все эти вопросы, я бы предложил варианты, которые не полетели бы в мусорку сразу. Ну, я на это надеюсь.

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

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

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

В-третьих, подобные кличи о помощи немного, а иногда и порядком унижают людей, которых наняли писать. Это немного личное, что скрывать.

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

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

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

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

А если всё нравится?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А если вы тот писатель, который ничего не понимает, вам трудно и вы уже начали перебирать варианты вслепую – вдруг что-то понравится тому «бугру» в мягком кресле, – остановитесь сейчас же. Бросьте всё и идите разговаривать со всеми, кто поможет вам настроиться на нужный лад. Начните со своего заказчика. Не бойтесь показаться ему глупым. Задавать вопрос «Зачем?» лучше до того, как вы накинетесь на клавиатуру. И задавайте его, пока сами себе не сможете на него ответить. Плохо бывает, только когда вы не задаёте этот вопрос и принимаетесь писать вслепую.

Часть II

Глава 6

Без булшита и как будто для людей

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

В буквальном переводе с английского «булшит» означает «бычье дерьмо». Слово образовано из двух слов: bull (бык) и shit (дерьмо). Обычно употребляется в значении «чепуха, бессмыслица, бред».

За эталонным булшитом, как и 100 лет назад, далеко ходить не нужно. Вот текст объявления, которое появилось на двери одного крупного российского аэропорта в июне 2020 года:

Первое, что бросается в глаза в этом объявлении, это огромное «ВНИМАНИЕ» и два восклицательных знака подряд. Я не из робких, но в такие моменты мне становится не по себе. На меня только что проорали как минимум дважды. Первый раз ещё и капсом.

И да, слово «внимание» так часто употребляется в текстах, не заслуживающих нашего внимания, что его уже не замечаешь. Тут срабатывает аналог «рекламной слепоты». За несколько лет пользования интернетом мы так изменились, что нам уже не нужны расширения для браузеров, которые скрывают рекламные баннеры. Большую часть рекламы на экранах мы теперь просто не замечаем. Поэтому мы просто пропускаем и это «ВНИМАНИЕ». Хорошо, если не пропустим и то, что написано ниже.

И обращение «уважаемые» в этом случае не спасает. После того как мне вот так дважды проорали, я уже не чувствую себя уважаемым. Даже если бы не орали, всё равно это слово настолько растиражировано, что и без восклицательных знаков воспринимается не так, как раньше.

С началом вроде разобрались. Теперь попробуйте перечитать предложение: «В целях предотвращения…» Чувствуете это? Лично я вязну в длинных словах. Они как бы цепляются за меня, тянут на дно, где тихо и спокойно, где не орут вот так просто на людей. И мне всё спокойнее. Я сам не пробовал, но говорят, что похожее чувство возникает, когда по-настоящему замерзаешь и от смерти тебя отделяет всего несколько минут, – становится мерзко, умирать неохота, но в целом как-то спокойно, смиряешься и уже готов уснуть навсегда. Хотя стоп! В смысле, спокойно? То есть навсегда? Если я сейчас не пошевелюсь, то умру! А вообще, ну её в болото, эту жизнь, зачем бороться? В холоде так хорошо. Вот примерно такое чувство у меня, когда я «жую» все те длинные и вязкие слова.

Посмотрим, из чего вообще состоит предложение:

Служебные слова: в, и, в.

Существительные: цели, предотвращение, распространение, инфекция, вход, лица, аэровокзал.

Прилагательное: коронавирусная.

Отглагольные прилагательные: провожающие, встречающие.

Краткое причастие: ограничен.

В общей сложности 14 слов. Теперь вспомним определение предложения в русском языке:

Предложение – это единица языка, которая представляет собой грамматически организованное соединение слов (или слово), обладающее смысловой и интонационной законченностью.

Прикинем на нашу ситуацию. Обладает ли это предложение понятным и доступным смыслом для любого, кто его прочитает? Вряд ли. Чтобы понять, что именно происходит и что делать, мне пришлось перечитать объявление три или четыре раза. И я до сих пор не понимаю, почему в нём обращение к пассажирам, но ситуация напрямую влияет только на провожающих и встречающих.

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

Но всё равно не отпускает это ощущение вязкости, и оно точно не отвечает требованию интонационной законченности. Такое предложение хочется продолжать до бесконечности.

И где потерялись все глаголы? У нас тут 14 слов и полное отсутствие действия. Это надо быть гением, чтобы в 14 словах между двумя точками не употребить ни одного глагола, но умудриться воткнуть два предлога, союз, семь существительных, прилагательное, причастие и два отглагольных прилагательных. Полное отсутствие глаголов и действия никогда ни к чему хорошему не приводило. Так и в этом случае. Смотрите, пять существительных почти подряд:

В целях предотвращения распространения коронавирусной инфекции вход…

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

И зачем усугублять ситуацию казёнными «лицами»? А аэровокзал тут к чему? Тем более что в подписи-то «аэропорт». Наконец, что значит «вход ограничен»? Он теперь только по пятницам? Или в чётные часы? Или по два человека каждые десять минут? Ещё одно понятие, которое не вносит никакой ясности и только расстраивает.

В самой подписи тоже не всё гладко. И тут вспоминается сцена из «Крёстного отца», в которой к дону приходят люди и что-то просят. Если перефразировать реплику Вито, то получится что-то вроде:

Ты подписываешься полным наименованием своего юридического лица, но не указываешь рядом свои реквизиты…

Серьёзно, в качестве подписи было достаточно просто «администрации аэропорта» или даже «администрации». Это объявление на входе в аэропорт, в нём совсем не обязательно вываливать на людей свою «организационно-правовую форму хозяйствующего субъекта». Ну как, увязли сейчас в юридическом определении АО? Это оно ещё неполное, я постарался найти самое простое.

Не утверждаю, что текст ниже идеальный, но, возможно, так жизнь «провожающих и встречающих» стала бы лучше:

Больше действия, меньше булшита, более личное обращение, меньше казёнщины – всё это идёт на пользу тексту.

И этому можно научиться. В свои первые дни в «Яндексе» я трясся от одной мысли, что могу налажать. Нет, лажи я боялся и боюсь всегда. Но вот первые недели именно в «Я» оказались для меня самыми страшными.

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

Потом Вову сменил Володя – как удобно. В моменты, когда задач наваливалось очень много, он напоминал, как легко проверять свои тексты на булшит:

– Представь, что сидишь в баре или кафе с другом, и прочти ему свой текст.

– Но это же продуктовый текст, он стрёмный для разговора с другом. Я так не говорю.

– Во-о-о-от. А зачем ты наделяешь сложным стилем общения сервис, которым пользуются люди?

Не нужно переживать по пустякам, всё поправимо. Волноваться стоит, только если страшно произнести вслух всё, что вы написали.

Глава 7

Давайте по-честному

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

…порядка 336 млн человек, это в 2,5 раза больше населения нашей страны…

Так, стоп. Тут я не поленился разделить 336 на 2,5. Выяснилось, что, по версии редактора того госсервиса, в России сейчас проживает 134,4 млн человек. В то же время The World Bank и Eurostat уверены, что в 2018 году в России насчитывалось 144,5 млн человек. А в Росстате на 1 января 2020 года записали 146,7 млн.

Так страна легко растеряла от 10 до 13 млн человек, или 7–9 % населения. Это как взять и вывезти из Москвы почти всех зарегистрированных в городе москвичей. Или совершенно «обезлюдить» Швецию, Чехию, Грецию или Португалию. Примерно столько в них граждан.

Не знаю, что это, оплошность или намеренная неточность, но выглядит очень некрасиво в любом случае. Если первое, то автору стоит научиться считать. Редакторам больших сервисов приходится уметь много всего, в том числе и перед цифрами не робеть. Так что нормальная обязанность – быть ещё немного математиком. Если здесь второй случай и 2,5 вместо 2,3 использовано «для красного словца», то это называется намеренным введением в заблуждение. Специально считать неправильно ещё хуже, чем не уметь считать вовсе.

И вот вопрос, даже два: как сообщение о числе жителей страны относится к интерфейсным текстам и почему мы это тут рассматриваем? А вот ещё один, который поможет ответить на предыдущие: что такое интерфейс? По сути, это любой способ взаимодействия человека с окружающим миром и вещами.

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

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

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

Действительное, вполне реальное событие, явление. То, что произошло.

И вроде разница небольшая, какие-то две десятые, а потери – в миллионах. Напиши редактор в уведомлении 2,3, я бы продолжал думать, что эта глава не нужна. Но нет, ему надо было написать более «круглые» 2,5. И вот вместо 146 млн при пересчёте мы получаем всего 134 млн, а вы читаете это. И хорошее начинание, чья-то добрая инициатива, ради промо которой мне прислали это письмо, всё это потеряно для зануд вроде меня. Ну какое удачное знакомство начиналось с вранья? Я таких не знаю. Если организаторы вечеринки обманывают на входе, то они точно продолжат в том же духе и дальше.

Ладно, возможно, это за уши притянутый пример. Где ещё можно наврать в интерфейсных текстах? Далеко ходить не надо – в жанре «что нового» в магазинах приложений полно вранья. В том самом месте, где разработчики сообщают пользователям, что изменилось в очередной версии их любимой игры или программы. И тут тоже есть две возможности – соврать случайно или намеренно.

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

Специально соврать можно из лени или от нехватки времени. Когда получаешь исходник от разработчиков или менеджера продукта, часто возникают вопросы: «А как мы это сделали? Ну и как именно это работает? А тут теперь что?» С ответами на эти и другие обязательные вопросы текст «что нового» преображается, иногда почти полностью. Допустим, в редакции менеджера он был таким:

Нашли и пофиксили багу, из-за которой не сейвились настройки. Исправили отваливающийся интернет на старых «Андрюшах». Поработали над исправлением других ошибок и в целом улучшили стабильность.

Первый вопрос, который я задаю при таком раскладе: «Что значит “поработали над исправлением других ошибок и в целом улучшили стабильность”?» Это же классический булшит из прошлой главы. В первые недели работы в «Яндексе» я узнал одно очень важное правило: либо говорить о чём-то существенном, либо не говорить вовсе. Если у разработчиков нет конкретного обоснования, которым можно заменить дежурное предложение, то предложение это мусорное и не стоит внимания. Его надо удалить.

Дальше можно немного поработать над формулировкой и переписать пару первых предложений для обычных людей – для всех, кто не «факапит дедлайны», не «коммитится раз в спринт» и так далее. Чтобы «что нового» поняли все, кто живёт обычной жизнью, а не по аджайлу:

● Избавились от ошибки, из-за которой не сохранялись настройки.

● Нашли интернет, который пропадал на старых устройствах, и прибили его гвоздями куда следует.

Только править что-то было рано. Со мной случалось такое: показывал впопыхах переписанный вариант, а он оказывался не тем, что от меня ждали. Потому что задачи часто ставят недостаточно полно и точно.

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

● На большинстве устройств починили сохранение настроек. Если у вас осталась эта проблема, пишите нам через обратную связь в приложении.

● Починили интернет, который пропадал на старых Бла-бла-фонах.

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

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

Глава 8

С учётом контекста и однородно

– Здравствуйте. Что вы хотите?

– Мне, пожалуйста, упаковку молока, орешки, жидкость для моющего пылесоса и эпоксидную смолу.

– Хорошо, с вас 3200 и 250 за доставку. Итого 3450 рублей.

– Ой, подождите, давайте добавлю ещё орешки. И ещё упаковку. Они такие вкусные!

– Ладно. С вас 3520 рублей, доставка бесплатно. Завтра устроит? После обеда?

– Не, давайте лучше до обеда и послезавтра.

– Окей.

– «Эпл пэй».

– Заказ принят в работу. Спасибо. Ждите курьера.

Работу любого хорошего интерфейса можно пересказать в формате диалога. По сути, графический интерфейс и есть диалог, который на экране мобильного или компьютера состоит из диалоговых окон. Какое же это старое понятие.

Диалоговое окно в графическом пользовательском интерфейсе – элемент для вывода информации и получения ответов пользователя.

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

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

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

Но что, если бы мой диалог с магазином проходил так:

– Здравствуйте. Что-то конкретное искали?

– Мне, пожалуйста, упаковку молока, орешки, жидкость для моющего пылесоса и эпоксидную смолу.

– Хорошо, с вас 3200 и 250 за доставку. Итого 3450 рублей.

– Ой, у вас вроде доставка заказов от 3500 рублей бесплатная. А можно добавить что-то?

– Нет, нужно сформировать новый заказ, а старый отменить.

– Но я теперь не могу создать новый заказ, потому что у вас не хватает нужных мне товаров.

– А вы сначала отмените старый заказ, и с товаров в нём снимется резерв. Тогда вы снова сможете добавить их в корзину.

– Ладно, пришлось повозиться, но вот.

– Хорошо. Теперь доставка будет бесплатная. С вас 3520 рублей.

– Окей, у меня «Эпл пэй».

– Принимаем только банковские карты. Ещё можете расплатиться наличными с курьером.

– Я не знаю, где моя карта, не помню коды. Ладно, вот, всё нашёл.

– Сессия истекла, ваша корзина пуста, сделайте заказ заново.

– Да блин. Вот. Всё сделал.

– Платёж принят. Сможем доставить через пять дней в ближайшее к вам отделение почты.

– Не годится, мне нужна доставка раньше и домой.

– Это не сможем. Но легко отменим заказ. Деньги вернутся на карту в течение трёх недель.

– Ну, с вами каши не сваришь. Оформляйте возврат. А я пока пойду ещё магазы посмотрю.

– Спасибо за то, что воспользовались нашими услугами! Не забудьте подписаться на наши рекламные рассылки и заходите ещё.

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

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

И номинальное присутствие UX-писателя тут не спасёт. Таким присутствием я называю ситуации, когда на проект берут пишущего человека и требуют от него лишь проверять чужие тексты. Ну, ещё, если повезёт, просят подгонять уже написанное под дизайнерские макеты – чтобы «вот тут три строки, а здесь – две».

Не стоит также брать опытного специалиста на время – попросить всё глянуть по-быстрому, заплатить ему за проект и распрощаться.

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

Да, в современных цифровых продуктах есть каркас. С дизайнерской точки зрения, это нечто невидимое для пользователя, но очень важное для разработки. Как скелет живого человека, который вряд ли увидишь без рентгена и без которого невозможно жить. Только вместо мышц каркас обрастает разнокалиберными компонентами – структурированным меню, уведомлениями, подсказками, всякими контентными областями, формами обратной связи, сообщениями об ошибках, кнопками, тегами и многим другим. Я постараюсь рассказать о них побольше в следующей части книги.

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

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

Одни пункты сформулированы с использованием существительных, другие – глаголов. Выходит неоднородно. Помните ещё про требование к нормальному тексту – чтобы можно было зачитать другу и не покраснеть от стыда? Прочитать такое одним предложением точно не получится, требование явно не соблюдено. Вот так должно стать получше:

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

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

Например, странно сначала говорить так:

Потом вот так:

На двух маленьких кусочках экрана выше автор избегает говорить только про вход, поэтому вводит авторизацию. Или он вводит вход, чтобы хоть как-то разбавить авторизацию, с которой к нему пришли разработчики. У слова «авторизация» два недостатка: оно длинное и непонятное. «Вход» куда яснее. Ну и ещё одна беда этих двух экранов – куда вводить имя на этапе входа? Там, где продукт говорил о необходимости войти, он писал мне про имя. А дальше какой-то непонятный логин. Логин – не имя, я протестую!

Так же важно следить за единообразием в навигации. Скажем, если назвали головной раздел «Главным», пускай он таким и остаётся. Не надо внезапно отправлять пользователей в «Основное». Вряд ли много людей свяжут эти два понятия и попадут куда задумано. Запутаются, потеряются, выйдут из приложения и удалят его навсегда. Найдут замену.

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

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

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

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

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

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

Глава 9

Компактно, понятно, полезно и грамотно

UX-писательство иногда подменяют понятием «микрокопия» (microcopy). Якобы это одна сущность. Но конечно, это не одно и то же. И да, они тесно связаны.

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

Микрокопия – результат, который получается в процессе работы UX-писателя. Та самая надпись на кнопке, подсказка, что пароль набран неверно, побуждающая строчка в поле для ввода текста, сообщение об ошибке и многое другое, что помогает пользователям принимать решения и «общаться» с продуктами.

Приставка «микро-» тут не просто так. Она говорит о том, что текст маленький. И он, как правило, не просто маленький, он ещё и находится в очень ограниченном пространстве.

Это такой текст, который должен быть компактным. Не коротким. Сокращать, конечно, круто. Но сокращения часто приводят к потере смысла. Текст в интерфейсе должен быть именно компактным. Лаконичным, если угодно, несущим максимум пользы в минимальном количестве знаков и слов. И понятным. Естественно, текст в интерфейсе должен быть ещё и понятным. В противном случае польза от него сводится к нулю.

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

Представим UX-писателя настройщиком. А тексты в интерфейсе – капризным трёхструнным инструментом, при настройке которого нужно постоянно помнить о разумном балансе. Стоит слишком сильно натянуть одну струну, и вот ослабевают и расстраиваются другие две. Натянем ещё одну – всё равно остаётся третья, которая не звучит в унисон с другими. Перетянем её – и вот уже нужно подтягивать те две. Или ослабить перетянутую? Как поступить? При каких условиях все три струны зазвучат гармонично? Каждый день на работе я отвечаю на эти вопросы и настраиваю всё новые тексты в интерфейсе, как струны несуществующего музыкального инструмента.

Предположим ситуацию, в которой разработчики уже добавили в интерфейс такое сообщение:

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

При этом разработчикам всё ясно – получив эту ошибку, они пойдут смотреть, что не так с сервером 1x5024975–02, и, возможно, исправят проблему. Пользователи же не имеют никакого представления ни о номерных серверах, ни о серверах вообще. И не должны иметь – это не их забота. Поэтому в некоторых компаниях вводят запрет на употребление слова «сервер» в сообщениях, которые прочитают пользователи. Нельзя говорить о серверах даже без упоминания их номеров. И правильно делают: упоминание любого сервера – лишняя техническая подробность.

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

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

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

Фактически все верно, но вышло коротко и как-то нескладно. Пересушено и будто совсем не для людей. Да и «профиль не загрузился» – это снова факт. Как сообщение об ошибке, озаглавленное «Ошибка». То, что профиль не загрузился, пользователь, скорее всего, уже понял – на экране пусто. Но это полбеды. Смущает что-то ещё… Ах, вот оно что! Заголовок звучит слишком категорично и даже фатально. Можно сказать то же самое помягче:

Вот теперь, кажется, получилось достаточно хорошо. Я не утверждаю, что это идеал. Но из заголовка пользователь понимает, что случилось. А в тексте сказано, что делать в этой ситуации. Кнопка помогает закрыть прочитанное сообщение без ассоциаций с чудовищным несовершенством мира и тотальной предопределённостью. Помните тот старый мем с нарисованным человечком, который обречённо говорит: «Окей»? Я сейчас про него.

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

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

И уж поверьте, за ошибки в интерфейсе прилетает намного быстрее и сильнее, чем за ошибки, скажем, в пресс-релизах, которые теперь почти никто не читает. Посмотрите сами на эти два текста, а для интереса засеките время, которое потребуется на поиск ошибки:

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

И это только два самых распространённых типа ошибок. Также в относительно небольшие интерфейсы можно навалить неправильной грамматики, речевых ляпов, неверной логики и недостоверных фактов. Когда садишься за очередной текст длиной 50 символов, нужно написать его идеально, не меньше.

Да, нервы иногда просто на пределе – ответственность большая, давление дикое. Но если пользователи не придут после, не возьмут редактора за шкирку и не примутся тыкать его носом в результат работы – уже успех. Это значит, что редактор всё сделал правильно.

Часть III

Глава 10

Про химию форматов и формулировки для них

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

Атомарный дизайн – это система, в которой всё построено из маленьких элементов – атомов. Если очень упростить, то в его основе всё как в химии и биологии: атомы составляют молекулы, из молекул строятся организмы. Дальше в дизайне, правда, идут шаблоны и страницы, которые хорошо бы называть иначе, если уж оставаться в рамках естественных наук. Да простят меня все люди с научным складом ума. Но примем всё как есть.

Атомарный дизайн – одна из тех штук, из-за которых я советую начинающим UX-писателям держаться поближе к дизайнерам и не увлекаться тем, что говорят и творят редакторы, копирайтеры и прочие подобные люди. Я сейчас о тех, которые пишут много чего, в том числе для интерфейсов, и любят хвалиться, как между реально стоящими делами могут «даже страницу 404 написать». Мало у кого из пишущих, тем более у таких, которые «между делом», вы научитесь систематизации и организации дизайнерского уровня.

Итак, атомы. Вот что интересного здесь есть для писателя:

В принципе, это все мелкие элементы, которые очень редко работают сами по себе, совсем без окружения.

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

Итак, поодиночке атомы не работают. Однако когда они соединяются, то образуются полезные молекулы, из которых можно строить целые организмы и даже больше – те самые странные шаблоны и страницы.

Например, если соединить поле для ввода текста и кнопку, мы получим минимальную полезную единицу. Смотрите, вот сюда можно ввести текст, а это надо нажать, чтобы текст остался на странице и его могли прочитать другие люди.

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

Текст и кнопки образуют… много чего – подсказки, предупреждения, сообщения об ошибках. Такое универсальное сочетание помогает даже решать всякие юридические вопросы:

Точно так же, как в химии, в дизайне и UX-писательстве есть несовместимые атомы. Например, невозможно представить себе кнопку в переключателе и, наоборот, переключатель, вписанный в кнопку. Это как взять спелый помидор с огурцом, отрезать по половине от каждого, совместить разные половинки и сказать: «Растите». Ничего не получится, не вырастут.

Чекбокс при кнопке, как в примере выше, теперь скорее не нужен – разве что юристы потребуют оставить именно двойное подтверждение. Ладно, бывает. Но вот оцените тотальную бессмысленность такой истории:

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

Правда, время от времени появляются, казалось бы, невозможные сочетания. Например, поле для ввода текста можно встроить в меню – в виде поля для ввода поискового запроса. Вот пункты меню, а вот поисковая строка. Не ждали? Смотрите, как хорошо они уживаются друг с другом.

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

Кнопки

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

Кнопки представляют собой ответы пользователей на то, что им предлагает продукт. Поэтому тексты кнопок чаще всего формулируются от лица пользователей – в виде указаний системе, что ей делать:

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

У меня есть пунктик, над которым кто-то тихо смеётся, другие его просто принимают, третьи дико гогочут и радостно вписывают очередную кнопку «ОК» в свой продукт. На мой взгляд, «ОК» – не окей. Это самая ленивая и размытая формулировка. Когда-то давно, когда интерфейсы локализовывали как попало и через раз, это «ОК» даже не набирали кириллицей: «Да кто заметит разницу, и так сойдёт». Хотя разница есть – как минимум литера К в кириллических шрифтах отличается от латинской K. Когда я замечал нежелание переводчиков локализовывать «OK», то каждый раз жутко огорчался и думал: «Вот если я возьмусь за дело, так обязательно всё исправлю». Сейчас прямо всё исправлять не удаётся даже в своём продукте, не то что по сторонам смотреть, но я стараюсь.

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

Переключатели и радиокнопки

У переключателя в интерфейсе два состояния – как у классического выключателя на стене в любой комнате. Не того, который управляет ещё и интенсивностью и оттенком света, а у самого обычного, который что-то принципиально включает и выключает.

Поэтому названия переключателей часто формулируются существительными – так проще и логичнее обозначать, что именно включается и выключается:

А ещё переключателям можно доверить рутинные действия. В таком случае в формулировках появляются глаголы:

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

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

Чекбоксы

В целом по формулировкам тут почти полная свобода действий, потому что сами чекбоксы могут стоять как отдельно, так и в списках. Отдельный чекбокс – это почти всегда какая-нибудь околоюридическая история. В таком случае текст либо длинный, либо очень длинный:

Обычно это те галочки, без которых невозможно зарегистрироваться в очередном сервисе или отправить какие-нибудь файлы куда-либо.

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

Допустим, так могут выглядеть настройки приложения для занятий спортом:

Видите, без разницы, как на одном экране настроек будут сформулированы сами чекбоксы, лишь бы вместе с объединяющим подзаголовком каждую группу можно было переписать в одно предложение:

Показывать на маршруте кемпинги и магазины.

В экстренных случаях отправлять мои координаты избранным контактам и звонить 112.

Поле для ввода текста

Поле для ввода текста – такая штука, в которую пользователю надо вводить текст (Л – логика). Вроде не такая, в которой самому продукту стоит что-то писать. Но, во-первых, без подсказок вроде «пишите прямо здесь» пользователи часто не понимают, что делать и куда вписать своё сообщение. Во-вторых, в интерфейсе каждый квадратный сантиметр на счету. Так почему бы не использовать всю доступную площадь с максимальной отдачей?

Тем более что поле для ввода текста – это иногда и строка поиска. А что, пользовательский поисковый запрос – такой же текст, который кто-то вводит. Строка для ввода поискового запроса – это маленькое поле. Подсказку в нём можно сформулировать стандартно-дежурно:

А можно немного повеселиться. Только в таком случае надо учитывать контекст – насколько к месту окажется та или иная формулировка:

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

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

Только не нужно втаскивать в интерфейс всё, что и в самом деле обычно пишут пользователи. Честность – хорошо, но в таком случае вы, скорее всего, проиграете, когда какой-то пользователь решит поругать ваш продукт и вы на автомате дёрнете в интерфейс часть его комментария. Все мотивирующие примеры в полях для ввода текста всегда пишет или согласовывает редактор. В противном случае и так не лучший продукт может стать ещё хуже – пользователи не обращаются в поддержку или к разработчикам просто так, в 99 % случаев они жалуются на проблемы. Чужое негативное мнение ухудшает отношение людей и заставляет их придираться к продукту по пустякам. Срабатывает стадное чувство: «Ух ты, вот тут штука, которую все ругают. Интересно, а за что могу поругать её я?»

Пункты меню

Существует два вида меню: навигационное и контекстное. И следует применять разные формулировки, в зависимости от того, для какого именно меню мы пишем.

В навигационном меню пункты лучше называть так же, как называются те страницы, куда ведут клики:

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

Контекстное меню позволяет совершать действия, например, с содержимым экрана. Поэтому его пункты лучше формулировать именно действиями – глаголами, которые отвечают на вопрос «что сделать?»:

Правда, не всегда контекстное меню получается сформулировать только действиями. Например, глупо гнаться за однородностью и называть один из пунктов «Показать свойства», в то время как все пользователи привыкли к просто «Свойствам» – нажал на «Свойства» и посмотрел свойства.

Если доступное действие всего одно и это не изменится никогда, то лучше нарисовать в интерфейсе отдельную кнопку для этого действия. Но, когда есть малейшая возможность того, что в будущем появятся второй и следующие пункты, можно сразу оформлять первый в контекстном меню. И пускай сначала оно будет состоять всего из одного пункта. Тут ограничений нет – не строгая навигация.

Текст

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

Например, заголовок ошибки состоит из текста, подзаголовок или объяснение – тоже текст. Всякие подсказки – текст. Реплики AI-ассистента в чате или голосом – текст. Текстом же мы подписываем поля в форме обратной связи. Я сейчас про названия полей – локальные заголовки и подзаголовки, а не про подсказки в самих полях для ввода текста, о которых уже поговорили раньше. Обычный текст присутствует в значках, которые ещё принято называть иконками. Без текстовой подписи поди разберись, что означают все эти картинки. А с подписями вроде «Здоровье» или «Анализы» сразу понятно, что это за приложения, – там в целом о моём здоровье, а здесь только результаты анализов.

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

Вот и все основные атомы, из которых можно строить интерфейсные тексты – как дома из кирпичей. О том, как писать каждый из них, я расскажу в следующих главах.

Глава 11

Пишем кнопки

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

Даже без какого-либо контекста ясно, что нажатие кнопки отправляет какой-то код куда-то. Пользователю этот код, скорее всего, нужен для подтверждения при регистрации или при каком-то другом действии. Но редактор всё равно решает приложить немного больше усилий и спрашивает подробности: «Хорошо. Но на всякий случай: что именно эта кнопка делает и какое у неё окружение? Можно всю страницу посмотреть?» Конечно, да. В ответ ему присылают такой скрин:

Допустим, этот редактор – вы и вам решать, нормально ли сформулирована кнопка. Не читайте дальше, прямо сейчас попробуйте подумать над этой задачей самостоятельно – нужно ли здесь что-то улучшать и как именно вы бы поступили. Что предложили бы? А после мы сверим мысли.

Ну или сразу смотрите моё решение.

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

И если подумать о производимом действии, то можем ли мы гарантировать пользователю получение кода, если он нажмёт на кнопку «получить код»? А если он ошибётся и введёт чужой номер телефона? А если у нас возникнет какая-то ошибка, из-за которой код не отправится? А если ошибётся мобильный оператор? Да много что может случиться. И вот пользователь нажимает кнопку «получить код», долго ждёт, повторно нажимает «получить код», снова ждёт и ничего не получает. Хотя надпись на кнопке обещала, что пользователь обязательно всё получит.

Человек чувствует себя идиотом, потому что не может получить этот код. Но почему это идиот – он? Виновата система, которой он решил воспользоваться! И вот уже мы страдаем от того, что теряем человека, который мог стать нашим пользователем. Но мы разошлись с ним из-за одной неверно сформулированной кнопки.

Кажется, что вернее назвать кнопку другим действием: «Отправить код».

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

А вообще, кнопка здесь – не единственная беда. Внимательный редактор обязательно заметит, как плох заголовок в сочетании с нелепо повторяющим его текстом. Да и отдельно от всего текст выглядит, мягко говоря, не очень. Сами посмотрите, что получается даже с новой формулировкой кнопки:

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

Завершение – Завершить

Регистрация – Зарегистрироваться

При произношении «зарегистрироваться» толпа чертей свернула себе челюсти. Ладно, оставим «регистрацию» как есть. А вот «завершить» на смену «завершению» для нас вполне годится – произносится короче и звучит живее. Предложу вообще избавиться от «завершения регистрации» в заголовке, а в тексте – поправить этот момент:

Теперь начало и конец вроде неплохие. Осталось только в конце предложения поправить это кривое «когда получите». Оно ещё и логически смешное. Ясно же, что пока не получу код, я его не смогу ввести. Даже случайно подобрать и ввести его не смогу, потому что не знаю формата.

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

Только всё ли теперь верно? Заредактировавшись, я добавил в текст ошибку такого же порядка, от которой только что его избавил. Помните то «введите, когда получите»? Так вот, тут то же самое – отправка кода не завершит регистрацию, а только отправит код пользователю на телефон. А мы заявляем буквально: «Чтобы завершить, отправьте код». Глупая нестыковка. Но можно быстро всё исправить:

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

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

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

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

Давайте вы сейчас быстро ответите, достойна такая формулировка продукта или нет, и мы опять сверим наши мысли, сходятся ли.

На мой взгляд, в такой формулировке есть большая проблема: кнопка буквально заточена под мужской пол. На ней написано не «Согласна», а «Согласен» – я мальчик, я согласен. Но как тогда писать, если не «Согласен»? «Согласна» вроде тоже не можем, потому что в таком случае кнопка получится сугубо женской и будет выражать действие от лица девочек. Такой кнопкой мы обидим весь постсоветский патриархат.

Во всяких прогрессивных странах и на тематических сайтах уже формулируют кнопки от лица девочек – вроде компенсируют годы унижений и оскорблений. В других придумывают новые общие слова, чтобы побыстрее закрыть вопрос и не касаться этой темы. Русскоязычные редакторы стараются переформулировать кнопки и любые другие действия от лица пользователей таким образом, чтобы они звучали нейтрально. Например, в этом случае можно назвать кнопку как-то так:

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

Кстати, интересный факт: согласовывать действия, сформулированные от лица пользователей-мальчиков, чаще приходят заказчицы-девочки. Девушек реже смущает, что у них в интерфейсе всё в мужском роде, – «согласен», «принял» и так далее. Парни, с которыми мне удалось поработать, примерно в три раза чаще беспокоятся о чувствах пользовательниц. Мы вас уважаем! Слышите? Одно время я даже считал заказчиц и заказчиков, которые приходят с интерфейсами, сформулированными в мужском роде. В процентном соотношении получилось 74 к 26 соответственно.

Глава 12

Переключатели и радиокнопки тоже с текстом

Как-то я писал гайд по текстам в интерфейсе и настолько переборщил с правилами и ограничениями, что запретил формулировать переключатели действием.

Я руководствовался примером из материального мира. Вот есть переключатель на стене, он включает и выключает свет. Есть кнопка на микроволновке – она запускает и останавливает микроволновку. Если вынести эти переключатели с микроволновки и стены на отдельную панель, разместить их рядом друг с другом – как в настройках телефона, то нам придётся их как-то подписать. Первый я в таком случае назвал бы «светом», а второй – «микроволновкой». Вроде логично – на что переключатель влияет, так его и назовём. Действию тут не место.

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

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

Но ближе к делу. Скажем, к вам пришли с таким текстом:

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

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

Здесь же, с такой формулировкой, мы предлагаем пользователям разрешить телефону пропускать звонки. Он и так будет пропускать их в режиме «не беспокоить». Только вот «не беспокоить» – более мягкая формулировка. «Пропускать» – полная жесть.

Но подождите, что это? Если перечитать объяснение заказчика, то всё выходит наоборот. Оказывается, разрешение пропускать звонки – не о том, что телефон не будет о них сообщать, а о том, что он как раз будет сообщать о каждом втором звонке с одного номера, – пропускать звонки как болельщиков на стадион, если угодно снова вернуться к футбольным ассоциациям. Вроде действие-то не такое плохое. Даже хорошее. Но зачем его тогда называть так плохо?

Слова с двумя и большим числом значений – не лучший выбор для интерфейса. Одни пользователи их прочитают так, другие – этак. Поэтому их лучше заменять или удалять. Я решил, что мне подходит второй вариант:

Но что такое «повторные звонки»? С глаголом было неоднозначно, а теперь стало просто непонятно. Возвращаемся к комментарию заказчика – тому, в котором говорится про механику, – и дополняем текст переключателя:

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

Таким образом мы перестанем «пропускать звонки» – как мяч в свои ворота – и не заставим пользователей делать сложный выбор и экспериментировать с непонятно сформулированными возможностями продукта.

А вот так иногда заказчики объясняют задачи для радиокнопок:

Привет! У нас в приложеньке кое-что обновляется и появляется больше возможностей, расширяются настройки. Пожалуйста, можешь проверить и поправить или окнуть? Вот тут новые штуки:

Что скажете, разойдёмся по углам и снова немного поразмыслим?

Я насчитал примерно… много недочётов в таком небольшом объёме текста.

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

Чтобы увидеть вторую проблему, нужно по очереди прочитать первую строку в сочетании с каждым пунктом. Радиокнопки должны быть сформулированы однородно. А ещё в таких случаях, как выше, они должны составлять читаемое предложение с первой строкой:

Определять ваше местоположение всегда.

Определять ваше местоположение, когда приложение запущено.

Определять ваше местоположение раз в 1 час.

Определять ваше местоположение Не определять.

Даже если вы раньше пропустили, то теперь-то точно заметили? Ну кто пишет «Не» в середине предложения с большой буквы? И что это за предложение такое: «Определять моё местоположение Не определять»? Пора переписать:

Не идеал, но уже лучше. Вспомним, что радиокнопка – почти как классическая кнопка, только у неё много значений. Как и обычная прямоугольная, радио– всегда про действие пользователя. И в этом случае нельзя говорить от лица продукта. Тут надо изъясняться от имени пользователя. То есть так:

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

А вот ещё задача – о мужском и женском роде и нейтральных формулировках в интерфейсе:

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

Вот номер раз:

Вторую группу лучше смотреть с вопросом, так должно быть проще всё переписать:

В третьей, возможно, тоже будет полезным вопрос:

Попробуйте всё исправить сами. Книжка подождёт сколько надо.

Решение может быть простым, если прибегнуть к маленькому трюку. Совсем не обязательно пытаться сохранить слова, которые использовал автор оригинального текста, лишь немного их изменив. Важно сохранить смысл, а сами слова можно заменить. Например, я предложил бы подписать первый набор радиокнопок так:

Интерфейс лишился активных пользовательских элементов в мужском роде – уже лучше.

Ответ «не пользовался» во второй группе я бы заменил на «ни разу». Так, ко всему прочему, он станет мягче, потеряет категоричность и сохранит общий смысл – человек ни разу не пользовался сервисом:

Про уверенность насчёт приоритета надо бы всё переписать:

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

Глава 13

Чекбоксы – галочки в рамках

Немного раньше я писал, что юридические чекбоксы переписать по-русски либо очень сложно, либо вовсе невозможно. Если вы когда-нибудь обсуждали юридические формулировки с юристами, то, скорее всего, знаете, о чём идёт речь и как это тяжело. Раз за разом приходится предлагать всё новые варианты, а они не хотят их даже читать и стоят на своём.

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

Я не буду расписывать здесь искусство переговоров. Про это есть книги и курсы. А то, как можно улучшить юридические чекбоксы, попробую объяснить.

Допустим, к вам пришли с таким текстом:

Прикинем, можем ли мы пропустить это в продукт. Если хочется ответить «да» и дополнить утверждение словами «это всего лишь формальность», то вернитесь к главе «Без булшита и как будто для людей». Если вы решили делать хороший продукт, делайте его без лишних уступок. Тем более в таких местах, где пользователь ещё не совсем ваш. Он только думает зарегистрироваться и попасть в ваш дивный мир, а вы ему предлагаете такое препятствие.

В первую очередь в глаза бросается длина этого предложения – 298 знаков. Без учёта пробелов, конечно. С ними выходит ещё длиннее и страшнее – 349. Так длинно получилось не только из-за желания юристов походить на Льва Николаевича Толстого, но ещё из-за кучи лишних слов, от которых хорошо бы поскорее избавиться. Это по их вине сообщение в интерфейсе походит на фрагмент юридического документа. И этот текст даже не ссылается на тот большой документ, потому что уже не требуется.

Следующее, что я бы сделал, – обратил внимание на очередное вкрапление мужского рода. Ну почему только гражданин? А что там с гражданками? У нас же не строгий официально-деловой стиль. И вообще, мы не в суде, делаем продукт для людей. Так давайте и говорить нормально – перестанем называть всех «гражданинами».

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

Кажется, я собрал уже достаточно комментариев к оригинальному тексту, чтобы выдать собственный вариант для чекбокса:

Да, вот так коротко. Юристы, скорее всего, окажутся против такой формулировки и придут к вам со встречным предложением – оставить всё как было. Так начнутся переговоры. Вы расскажете им про чистоту пользовательского интерфейса и высокую цену каждого слова в нём. Будете говорить про канцелярит, с которым пытались бороться ещё Чуковский и Галь. Вы расскажете юристам про мужской род. И напоследок – о формальности этого чекбокса, который можно сформулировать коротко и дать ссылку на полный текст пользовательского соглашения. Всё равно оригинальный вариант, который написали юристы, содержит не все условия, так почему мы одно вытаскиваем туда, где пользователь точно это увидит, а другое оставляем «за кадром»?

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

Идём дальше. Где ещё бывают чекбоксы? В настройках! Смотрите, какие некрасивые, давайте поправим:

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

Вот так станет немного лучше:

Немного лучше – потому что это ещё не идеал. Я привёл все пункты к более-менее единому формату, и теперь пора поработать со смыслом.

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

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

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

И вроде теперь всё стало намного лучше. Только всё равно что-то смущает. Попробуйте сами решить, что именно здесь не так. Или не утруждайтесь и просто продолжайте читать.

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

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

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

Глава 14

Поле для ввода текста

Начну эту главу с простого – поля для ввода поискового запроса. Однажды ко мне пришли с таким вопросом:

Привет. У нас графически очень чистый и простой сайт. Поэтому мы не хотим делать стандартное поле для поиска с кнопкой. Думаем оставить только поле и вписать в него текст с кнопки – «Найти». Что думаешь? Мы бы сами всё сделали, но мнения разделились, поэтому решили обратиться к тебе.

Что думаете, редакторы? Я уже могу вас так называть? Книжка скоро закончится, пора становиться профессионалами. И с полем что – можно назвать его действием от лица пользователя?

Конечно, нет. Даже думать о таком – дурной тон, не то что спрашивать или предлагать.

Формулировать от лица пользователя в интерфейсе стоит только элементы, которые исполняются от его лица или запускают процесс исполнения. Нажал, изъявил свою волю, и вот всё сделалось. Такие активные элементы – это кнопки и ссылки, но точно не поля для ввода текста. Ну нажму я на это поле «Найти» – и что получу? Ничего. Чтобы там что-то закрутилось и я получил результат, нужно дополнительно что-то ввести, а потом нажать на кнопку «Ввод» на физической клавиатуре или такую же, но нарисованную в интерфейсе.

Поэтому я не смог ответить ребятам ничего, кроме «А давайте не будем так делать, пожалуйста?». Начались переговоры. И позже в ходе обсуждения выяснилось, что поисковую строку можно прилично растянуть и вписать в неё нормальный мотивирующий текст:

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

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

Ребята из разработки вернулись и сказали: «Ладно, если мы напишем в поле “Поиск”, станет лучше?» Я ответил что-то вроде: «Лучше станет, если вы напишете в строке поиска “Поиск…”»

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

Мораль этой истории простая – экспериментировать и пробовать новые подходы можно и это даже хорошо. Примерно так же хорошо, как прислушиваться к пользовательскому опыту и стараться не менять чужие привычки. Знают пользователи, что поиск по сайту там, где написано «Поиск…», – назовите поле для ввода запроса привычно и больше не трогайте.

К слову, о действии «найти». Одно дело, когда кнопку с таким названием размещают у себя поисковые гиганты. Там, скорее всего, найдётся то, что ищут пользователи. «Яндекс» даже утверждает, что «найдётся всё!». И совсем иначе дела обстоят на небольших сайтах с внутренним поиском, который может найти… ничего в сравнении с тем же «Яндексом». Хотя в слове «найти» кроется гарантия, что сейчас-то это свершится. Можно сказать, что, используя такую кнопку для внутреннего поиска, мы обманываем пользователя. Избавиться от этого помогут более нейтральные формулировки, обозначающие не результат, а процесс, – тот же «поиск». Ну ещё есть вариант с действием «искать».

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

Я считаю, что это хорошая замена. Императив в таких местах не очень-то побуждает к действию, кого-то даже оттолкнёт. А вот вопрос, заданный более непринуждённо, раскручивает пользователя на разговор. Этим приёмом, кстати, часто пользуются блогеры. Хотите развести всех на долгую беседу – поднимите провокационную тему, не высказывайте своё мнение, чтоб от вас не отписывались потенциальные оппоненты, и обязательно задайте вопрос со смыслом: «А как вы считаете?» Холивар в комментах обеспечен. Точно так же «Фейсбук» теперь провоцирует нас, чтобы мы скорее делились всем, что у нас прямо сейчас на уме:

– О чём вы думаете, Кирилл?

– Да всё больше о том, как дописать эту книжку и не написать об этом тебе, «Фейсбук». А то ведь все узнают раньше времени.

Впрочем, не всегда стоит отказываться от императива. Часто чёткое указание нужного действия – единственный способ быстро и понятно подсказать людям, что вообще нужно сделать для успеха. Мало у кого возникают вопросы по поводу указаний в красных подсказках – тех, которые пользователь видит, когда уже сделал что-то не так:

Ну и нет такого правила, которое запрещало бы подсказывать людям, что им делать. Часто такое использование полей для ввода текста экономит место в интерфейсе и время:

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

А ещё поля для ввода текста – неотъемлемая часть не только формы обратной связи, но и формы регистрации. В этом случае и текст не нужен, достаточно примеров того, что продукт ждёт от пользователя:

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

Глава 15

Как написать меню

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

Что можно тут подумать? Название написано по-русски, суть отражает.

Но не стоит торопиться. Во-первых, нужно поместить это название в среду, где оно будет находиться, и глянуть, насколько хорошо оно впишется в продукт. Вот каким станет то меню после добавления нового раздела:

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

Но, когда пункт располагается под пунктом, от «воздуха» в правом верхнем углу, как на первой иллюстрации, и вовсе становится дурно.

Ну кому нужно столько пустого места и как можно столь расточительно им распоряжаться? Помните ещё про драгоценную площадь в интерфейсах? Каждый квадратный сантиметр стоит очень дорого, а тут их, пустых, сразу несколько.

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

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

Вроде неплохо вышло. Пустого места осталось намного меньше, меню получилось компактнее. А освободившуюся площадь мы точно придумаем, как использовать.

Вот ещё ситуация: заказчики перечитали умных книжек по редактуре и везде пытаются добавить действие:

Это вроде даже интересно – открыть страницу в браузере и внезапно заметить действие среди статики. Ух как бодрит! Но кому это нужно? Меню не такой длинный формат, в котором стоит заигрывать с пользователями и стараться не усыпить их монотонностью. Вот если меню будет состоять из десятков пунктов и уже почти превратится в каталог, то придётся как-то решать проблему. И то не стоит делать это, меняя формулировки в каждом из пунктов.

А ещё из-за глагола пункт вышел слишком длинным, и снова образовалось пустое место. Этого можно избежать, если переписать пункт существительным в одно слово. Скажем, так:

Ну, больше неоригинально. Но как минимум так же понятно. Или понятнее. И теперь меню получилось однородным в любом смысле – как по длине отдельных пунктов, так и по их формулировкам.

А вот ещё история. Иногда проблема кроется не в самом навигационном меню, а в неоднородности в целом – такой, которая пронизывает весь продукт насквозь. Например, пункт меню может называться «Компания», а страница, на которую пользователь попадает по нажатию, – «О компании»?

Компания → О компании

Вроде одно и то же – там компания, здесь компания. Но люди будут путаться и теряться в таком разнообразии. Рано или поздно вы станете отправлять их в раздел «О компании», они будут искать что-то, что начинается с «О…», не понимая, что в меню им нужен пункт, который начинается с «К…». Люди часто не прочитывают слова целиком, а только ищут «якори» – отдельные символы, которые они заприметили сами для себя и которые должны помочь им в конкретной ситуации. Без этих якорей пользователи тратят впустую много времени. И в таком случае стоит переименовать либо пункт меню, либо саму страницу.

Чтобы грамотно сформулировать контекстное меню, нужно немного больше – знать, что именно произошло только что, что можно сделать сейчас и что будет потом. Похоже на то, как писать тексты сообщений об ошибках. Давайте возьмём это знание и попробуем справиться с такой задачей:

Привет. У нас появляется новая функция в продукте – собираемся пильнуть контекстное меню. Будет на десктопе и в мобиле. На разных платформах вызывается немного по-разному. В браузере на компе надо нажать правую кнопку мыши, в мобильном приложении – держать палец на элементе. Выглядеть везде должно одинаково. Все действия со значками наших внутренних сервисов – почти как со значками на рабочем столе телефона. Можно удалить, изменить порядок. Только для этого надо делать выбор в меню, само по себе долгое нажатие только вызывает его. А ещё можно объединить значки в папку. Для этого тоже жмёшь и выбираешь соответствующий пункт, таскать значки друг на друга нельзя. Вот, что мы придумали, посмотри, пожалуйста, старались называть пункты покороче:

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

Что значит «Удалить»? Включаем пользователя-брюзгу. Если я как пользователь нажму эту кнопку, то я безвозвратно удалю целиком мой любимый сервис? Навсегда? А как его потом вернуть? Знаю я вас, разработчиков, понаделаете ерунды, потом пользоваться невозможно вашими приложениями хвалёными.

А «Изменить» – это про что? Я могу менять мои сервисы, что ли? Или название изменить? Нет, это вроде везде называется «переименованием». Но что я могу изменить прямо здесь и сейчас? Внешний вид всего экрана? Вы добавили темы оформления? А может, сменить внешний вид значков? Лучше не буду экспериментировать и не стану нажимать и эту кнопку вашего нового меню. Хоть бы обучение какое-нибудь добавили, а то ничего не понятно. Сделали новую фигню, и она оказалась фигнёй.

И вот это «В папку» – про что вообще? В какую папку? Я пользуюсь этим приложением 12 лет, ещё на первый айфон устанавливал, в жизни не видел тут никаких папок. Я сам себе папка. Точнее, не себе, но это уже детали. Как бы то ни было, не надо ничего «в меня».

Ладно, пора возвращаться в свою шкуру. Представив всё это, я, возможно, переборщил. Конечно, не бывает таких пользователей. А если бывают, то это огромная редкость и работают такие люди тестировщиками. Или UX-писателями. Но лучше выдумывать для себя таких персонажей до релиза новой версии, чем сталкиваться с ними после. Так я ещё раз посмотрел на это меню и вернулся с вопросами к разработчикам. Они ответили:

«Удалить» удаляет значок ненужного сервиса. Если потребуется, то его можно восстановить в настройках приложения. «Изменить» позволяет изменить порядок значков на экране. «В папку» предлагает поместить значок в уже имеющуюся папку или создать новую и поместить в неё.

Я немного переписал:

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

«Изменить порядок» – не идеал, но хороший компромисс между совсем уж непонятным «Изменить» и слишком длинным «Изменить порядок значков».

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

Осталась только пара вопросов: действительно ли нужно называть первый пункт так длинно? Неужто нет способа сказать то же самое попроще и покороче? Есть как минимум один вариант. Тем более что он уже прозвучал при объяснении того, что происходит после нажатия кнопки, – значок скрывается.

Заодно я бы убрал скрытие значка пониже. Да-да, это тоже работа редактора – вытаскивать на видное место предпочтительные действия и прятать всё, что невыгодно продукту. Менять порядок – пожалуйста, раскладывать значки по папкам – кайф. Удалять и скрывать? Но… ведь тогда пользователи перестанут открывать скрытые сервисы! Как так?! Спрячу эту возможность под другими пунктами:

Мне кажется, получилось лучше, чем было, и достаточно хорошо – не коротко, а лаконично.

Глава 16

Просто текст – самый дикий

Обычный текст – самый универсальный элемент, который легко соединяется со многими другими атомами в интерфейсе.

В ошибках он прилипает к кнопкам, потому что без него непонятно, что вообще происходит, и неясно, стоит ли нажать вот эту кнопку или лучше ту. Например, приходят к вам с такой задачей – что станете делать?

Привет! У нас не всё хорошо с сохранением настроек на лету, и в сложные моменты хотим показывать в углу экрана сообщение об этом. Это будет стандартная красная плашка. Как только сохранение завершится, плашка должна автоматически пропадать. Но если пользователю будет мешать красная фигня на экране, он сможет скрыть её сам. В таком случае мы оставляем маленький кликабельный кружок на её месте, чтобы показать, что с сохранением всё ещё что-то не то. При клике на кружок сообщение вновь раскрывается, и можно уточнить, что там происходит. Уведомление временное, в будущем планируем сделать отсроченное автосохранение и меньше беспокоить людей. Сейчас нужно, чтобы пользователи не уходили с экрана несохранённых настроек, а немного задерживались на нём. Иначе не сохранится – люди будут волноваться. Написали такой текст для уведомления:

Что скажете о тексте, редакторы? Норм или удалить всё и написать заново?

Я бы переписал – в этом тексте снова почти «булшит-бинго». Разве что с пунктуацией и орфографией всё хорошо.

Например, в такой формулировке, как в любой другой, не нужно обилие «не» – сплошной негатив. И без того сообщение на контрастном фоне, так оно ещё с горой неприкрытого негатива в тексте.

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

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

О! Давайте попробуем заменить кнопку «Закрыть» на здоровенный крестик. Если не понравится, всегда можно вернуться к более понятным словам и назвать действие словом «скрыть». Нажимать «Скрыть» в нашей ситуации будет не так страшно, как «Закрыть».

И ещё: как пользователю узнать, когда именно сохранятся настройки и можно будет уже уйти с этой страницы? Продукт пишет, «пока это не произойдёт». А когда это произойдёт? Больше никакого уведомления не предусмотрено. Да в общем, и не нужно оно, если написать, например, так:

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

«Не закрывайте страницу» можно сказать без «не» – предложением оставаться на странице. Суть одна, негатива меньше – вроде стало лучше. Фразу «пока это не произойдёт» тоже можно заменить более понятной, если перечитать сопроводительный текст от продакт-менеджера: «Как только сохранение наладится, она автоматически должна пропадать». То есть красное уведомление о несохранённых настройках пропадает, когда настройки сохранятся. А пока вы видите это сообщение, настройки ещё не сохранились. Поэтому «Оставайтесь на странице, пока видите это сообщение».

В результате уведомление стало длиннее, но понятнее. Разве что не хватает добавки про красный кружок в тексте: «…Оставайтесь на странице, пока видите это сообщение или красный кружок в углу экрана». Я бы написал про него, только чтобы спасти логику нормального человека. Ведь сейчас в тексте говорится только про уведомление. А если его скрыть вручную, то не будет смысла и оставаться на странице.

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

Красный кружок в углу экрана. Ничего не напоминает? А если он станет мигать? А если добавить к нему подпись REC? Вроде это обозначение того, что идёт запись. Запись чего именно – пользовательского экрана или видео с веб-камеры? Не надо так. Сейчас мы, конечно, не будем решать эту проблему. Но с ней как минимум надо идти к дизайнерам и рассказать им о том, что вы чувствуете, когда видите красный кружок в углу экрана.

А вот ещё классическая ошибка: «что-то пошло не так». Помните же, что прежде, чем писать такое сообщение, нужно выяснить, как пользователь к этой ошибке пришёл и как он сам может всё исправить?

У нас тут ситуация: пользователь зашёл в свой профиль, а данные не загрузились. Это вообще не только местная проблема, она может возникать и на других страницах. Поэтому мы хотели максимально общее обозначение ошибки – чтобы можно было использовать его и в других местах. Сделать особо ничего нельзя, только попробовать перезагрузить страницу сейчас или позже. Мы видим это так:

Во-первых, ошибка, озаглавленная «ошибкой», – это большая ошибка. Если заголовок используется вот так, то его можно удалить и ничего не изменится. Сами посмотрите, суть не поменялась совсем:

Тут по-прежнему сказано, что именно произошло и вроде что можно сделать, чтобы исправить ситуацию.

Но, раз нам позволена такая роскошь, как заголовок, мы можем использовать его и рассказать пользователю о произошедшем – переместим в него строку «Данные не загрузились».

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

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

По ходу дела я избавился от лишнего, подвигал нужное и добавил немного пользы. И всё это была работа только с текстом.

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

Снова всё по-русски написано. Но можно ли так формулировать всплывающие подсказки? Когда пользователь видит такие штуки, он уже сделал что-то не по сценарию – что-то такое, что невыгодно продукту и, скорее всего, не нужно пользователю.

По сути, сама ситуация, когда надо показать пользователю всплывающую подсказку, – ошибка. А всплывающая подсказка – как сообщение об ошибке, только неполноценное. Если в привычном сообщении об ошибке есть место для объяснения произошедшего и предложения возможных действий, то тут нет. И оставлять нужно что-то одно.

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

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

Напоследок – в целом о неактивных наборных блоках на примере списков. К вам пришли согласовать текст для «что нового» в магазине приложений. Что ответите?

Начну с последнего пункта, потому что он никак не вяжется с первыми двумя. Что значит «ещё красивее»? Понятно, что теперь оно (приложение) «ещё красивее». Но в таком случае и первые два пункта стоило сформулировать без действия. А раз там, в тех двух пунктах, действие есть, то и здесь должно быть. Ну хотя бы написать «стало ещё красивее».

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

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

Ну и третье – исправлять орфографию, пунктуацию и типографику нельзя. Исправляют ошибки – орфографические, пунктуационные и типографические.

Кстати, о последних – типографических ошибках. Раз на то пошло, хорошо бы показать приложению этот список из «что нового» и нормально его оформить. Если оно в самом деле научилось чему-то такому – пускай поработает.

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

Чуть не забыл! Текст «что нового» часто пишется от первого лица – в формате «что мы сделали». И что у меня получилось в результате:

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

Ссылок в описании – как у ютуберов – не будет. А если у вас появятся вопросы по этой книге или в целом по UX-писательству, то можете присылать их на почту ux@egerev.ru и задавать в чатике телеграм-канала «Текст в тесте» @txtin.

Глава 17

Большая задача

Как обещал, в конце большое практическое задание. Я постарался написать его таким образом, чтобы вы смогли поработать с каждым из типов интерфейсных текстов.

Можете выполнить его, можете не выполнять. Меня всё равно нет рядом, и я не смогу проверить и начать гундеть, что все дедлайны остались в прошлом. Можете просто подумать и ответить на вопрос: «А как бы вы это сделали?»

Если решите попробовать и вам будет интересно получить комментарии, присылайте результат на почту ux@egerev.ru. Быстро ответить не обещаю – зависит от числа выполненных и присланных заданий, но, в принципе, должен.

Предыстория такая: вы работаете в компании, которая занимается адаптацией чужих и созданием собственных онлайн-игр в России. Все игры условно бесплатные. Всё, что нужно сделать игроку для начала, – скачать и установить общий установщик, программу вроде Steam, выбрать игру, установить её, запустить – и всё, можно играть. Монетизация для 2020 года стандартная – компания зарабатывает на продаже внутриигровых предметов и подписок.

Аудитория совершенно разная – от 14 до 50 лет. Точно есть несколько игроков и за 60. Десятки тысяч рублей в месяц заносят игроки постарше, примерно от 25 до 40 лет. Это люди, которые зарабатывают приличные деньги и могут вот так их тратить – на внутриигровые предметы. В основном платящие игроки заносят до 10 000 рублей в месяц. Естественно, физически при этом они ничего не получают, но повышают удовольствие от процесса – быстрее развивают своих персонажей и с большей вероятностью побеждают в схватках с другими игроками. На рейдах – когда идут группой побеждать какого-нибудь мощного босса – такие игроки, как правило, берут на себя руководство остальными. Остальные игроки не против, потому что им перепадают ценные вещи и прочие ресурсы.

Вот что написал заказчик:

Привет! У нас грядёт крупное обновление, и к нему нужно много текстов. Суть простая – появляется новый раздел в мобильном приложении и на сайте, и нам надо его как-то коротко назвать. В раздел будут автоматически попадать все внутриигровые предметы, на которые объявлены скидки.

Есть несколько рабочих названий:

● Скидки.

● Скидоны.

● Распродажа.

● Стафф дешевле.

● Просто жирный знак процента, который будет выделяться на фоне других пунктов меню, – %.

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

Дополнительно нужно максимально полно рассказать о новом разделе:

1. При заходе на сайт планируем показывать залогиненным пользователям поп-ап про новый раздел. Его размер и формат почти не ограничены – заголовок, текст, кнопки для перехода в раздел и закрытия поп-апа. Вот что мы с тобой сделали в прошлый раз к другому обновлению:

В этот раз хочется хотя бы на треть меньше текста. Не надо пересушивать, хотим рассказать нормально про скидки. Но вроде можно сделать это покороче. Если нет, то ладно. Как уже сказали, в объёме мы тут почти не ограничены. Лишь бы игроки загорелись и повалили в новый раздел покупать стафф со скидками.

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

В этом формате заголовок должен уместиться в 32 символа, текста под ним выходит две строки по 35 символов каждая. К сожалению, больше нельзя, это давно существующий формат, который никто сейчас менять не будет, даже если очень захотеть. В прошлый раз ты написал нам такой текст:

Кнопок нет. Для перехода в магаз пользователю нужно будет просто нажать на любое место в напоминалке, кроме крестика. А крестик её закроет.

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

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

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

4. Для мобильного приложения, как всегда, нужен текст «что нового» – запилим его при публикации. В этом релизе больше ничего не появится, только новый раздел. Но зато про него можно рассказать аж на целых 500 символов. Хотя, скорее всего, столько объёма не понадобится. Ну не знаю, ты ж писатель, напиши что-то достаточно короткое, приятное, понятное, увлекающее – всё как ты умеешь. Мы хотим, чтобы пользователи почувствовали нашу любовь к этой особенной версии. Думаю, тут можно добавить даже чуть пафоса. Люди давно просили нас организовать этот раздел, чтобы было удобно искать, что там со скидками. Мы сделали.

Вот что у нас было в «что нового» про стариковский гундёжемёт:

Завезли в магаз «СимСтара» новую пушку – гундёжемёт! Чем старше твой персонаж, тем опаснее эта штуковина окажется в твоих руках. Если оформлена подписка на новости, подробности уже должны быть у тебя в почте, а точные технические характеристики новинки есть в магазине. Гундёж – молодым!

5. Наконец дошли до самого интересного для тебя – меньше промо, больше дела. В настройках мобильного приложения и на сайте также появится новый блок с опциями рекламных пушей о распродажах.

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

По умолчанию, как мы любим, все выключатели должны быть в положении «включено».

Ещё раз, на всякий случай: давай постараемся не называть эти пуши в настройках рекламными. Пользователи всегда спешат отписаться от рекламы, а если не подписаны, то и не подписываются. Реклама – это наша выгода, а пользователям надо показать их выгоду.

6. Вот ещё что! Нужен небольшой онбординг – несколько коротких текстов в баблах, которые пользователь увидит при первом входе в обновлённое приложение. Дизайна пока нет, но текст уже лучше накидать, с ним и дизайнеру будет проще. Это должны быть тексты в пару предложений, символов до 120–140 максимум на каждом экране. Вот о чём мы хотим рассказать в онбординге:

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

● Карточка товара будет содержать перечёркнутую обычную цену, цену со скидкой и процент скидки.

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

Ну как, редакторы, возьмётесь за задачу? Соберу список покороче, и посмотрим, что именно от нас требуется:

● название из списка заказчика или своё;

● поп-ап, который будет показываться при входе на сайт и в приложение всем авторизованным пользователям;

● напоминание, которое увидят через два-три дня все, кто скроет первый поп-ап;

● письмо на почту и пуш-уведомление от приложения;

● текст «что нового» для App Store и Google Play;

● дополнительный блок в настройках;

● онбординг при первом входе в приложение после обновления.

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

UX-писатель обычно работает над фичами с момента появления идеи, буквально с фразы: «О! А давайте вот такую штуковину в продукт добавим – пользователи будут благодарны, инфа-сотка». И когда к писателю приходят с просьбой описать фичу не только интерфейсными текстами, но и минимальным набором промо, это нормально. Никто больше не расскажет о новых возможностях в продукте так же качественно.

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

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

И прежде чем начать стучать по клавиатуре, вспомните, что UX-писательство – это всегда сначала размышления о пользовательском опыте в определённом контексте, а уже потом непосредственно писанина. Даже в названии этой относительно новой профессии UX стоит вначале.

Удачи!

Послесловие

Если в задачах вы выступаете как заказчик, я очень надеюсь, что вы не надёргаете из книжки отдельных советов и не побежите прямо сейчас спорить со своим UX-писателем. Не нужно и комментировать его или её тексты на основании всего, что я тут написал. Это не чёткое руководство к действию – без непосредственной занятости и приличного погружения в ваш продукт такое я бы создать не смог. Помните? Я писал об этом – что не знаю вашей ситуации, не владею не то что подробностями, но даже примерной инфой о том, что именно вы делаете. А это очень важно – понимать суть, чтобы писать хорошо.

Если вы заказываете тексты, я очень надеюсь, что эта книга помогла или поможет вам понять специфику работы UX-писателя. Я хотел, чтобы она дала ответы на вопросы вроде: «Ну что он так долго копается с одной кнопкой? Опять этому текст на вычитку отдавать? Он же весь процесс затормозит и снова нам релиз запорет. Но почему нельзя использовать нашу формулировку?»

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

Если вы сами пишете, то эта книга должна подсказать вам не только как работать, но ещё и как объяснять результат своей работы и отстаивать лучшие варианты.

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

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

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

Что ещё почитать, чтобы писать для интерфейсов лучше

Эту книгу я написал отчасти ради быстрого ответа на вопрос «Что почитать по UX-писательству и всему такому?». Естественно, есть много прекрасных изданий, которые помогли мне и вам должны быть полезными.

Чтобы узнать, как в принципе работать с современным прикладным текстом, смело читайте «Пиши, сокращай» Максима Ильяхова и Людмилы Сарычевой. Америку не открыл, ага?

Если бы у меня спросили «что почитать по коммерческому писательству?» в 1970-х, я бы ответил: «Читайте Нору Галь, вот у неё вышло “Слово живое и мёртвое”, отличная книжка». Ещё раньше я бы советовал читать «Живой как жизнь» Корнея Чуковского. Да-да, он написал не только «Мойдодыра» с «Федориным горем», но ещё прекрасную статью, а позже и книгу про развитие русского языка. Именно Корней Иванович первым объяснил понятие «канцелярит» – тот самый, с которым мы боремся и сейчас.

Уильям Зинсер выпустил первую редакцию своей книги «Как писать хорошо» спустя четыре года после выхода «Слова живого и мёртвого» Норы Галь. Книга на английском и про английские тексты. Вышла, можно сказать, на другом конце света, а проблемы те же. Замусоренность и канцелярит. С недавних пор она есть на русском языке в клёвом переводе Владимира Бабкова.

Если не пасуете перед книгами на английском и готовы на лету адаптировать англоязычные примеры, также советую почитать книгу Нья де Леон «Микрокопия: Как маленькие фрагменты текста делают приложения и сайты привлекательными» (Microcopy: Discover How Tiny Bits of Text Make Tasty Apps and Websites). Книга очень короткая и исключительно практическая. Автор рассказывает о том, как писать конкретные элементы по отдельности и вместе – как я в третьей части этой книжки.

«Справочник издателя и автора» Мильчина и Чельцовой читать, конечно, не нужно. Но это такая книга, которая должна быть на рабочем столе всякого UX-писателя. Я не могу назвать более полезного издания для себя. Держать в голове все эти правила оформления нереально, а в справочнике их можно подсмотреть в любой момент. Удобный алфавитный указатель есть на последних страницах и прямо на обложке.

Если не книги, то есть блоги и рассылки, совершенно бесплатные или с платой за каждый выпуск. В интернете полно предложений.

И в чём писать

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

Во-первых, если вы работаете над цифровыми продуктами с дизайнерами, то сейчас просто невозможно обходиться без Figma. На мой взгляд, это лучший инструмент для совместной разработки интерфейсов. И он доступен прямо в браузере!

Для черновиков есть Ulysses. Это простой текстовый редактор без лишних наворотов, шрифтов, кеглей, гаммы цветов и прочего оформительского инструментария. Поддерживает разметку markdown, есть светлая тема для работы днём и тёмная – по ночам. Многие редакторы и писатели предпочитают более дешёвый и простой iA Writer, а мне нравится то, как в Ulysses устроена навигация по документам. Например, ориентироваться в частях и главах рукописи этой книги в iA Writer мне было бы намного сложнее.

Когда надо поделиться каким-то текстом, вместе его обсудить и поредактировать, помогает сервис Google Docs. Опять же, не представляю, как раньше авторы согласовывали рукописи. Теперь это стало проще, слава интернету.

Ну и мессенджеры. На наших телефонах установлено по несколько мессенджеров для общения. Помимо стандартных СМС и почты я только что насчитал у себя ещё пять. В том же «Телеграме» есть возможность сохранять что угодно, отправляя себе сообщения.

Вот теперь точно конец. Пишите хорошо.

Content

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

От автора

Предисловие

Как читать эту книгу

Часть I

Глава 1 Кто прочитает всё это?

Глава 2 Что за голос продукта?

Глава 3 А если автор видит иначе и хочет делать всё по-своему?

Глава 4 А нужен ли тут текст вообще?

Глава 5 Что, если всё ещё не нравится? Хорошо, а какие предложения?

Часть II

Глава 6 Без булшита и как будто для людей

Глава 7 Давайте по-честному

Глава 8 С учётом контекста и однородно

Глава 9 Компактно, понятно, полезно и грамотно

Часть III

Глава 10 Про химию форматов и формулировки для них

Глава 11 Пишем кнопки

Глава 12 Переключатели и радиокнопки тоже с текстом

Глава 13 Чекбоксы – галочки в рамках

Глава 14 Поле для ввода текста

Глава 15 Как написать меню

Глава 16 Просто текст – самый дикий

Глава 17 Большая задача

Послесловие

Что ещё почитать, чтобы писать для интерфейсов лучше

И в чём писать