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

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

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

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

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

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

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

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

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

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

⁂

Моей жене:

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

От автора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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