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

От автора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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