Этой кнопке нужен текст. O UX-писательстве коротко и понятно Егерев Кирилл
Редактор А. Новресли
Главный редактор С. Турко
Руководитель проекта Л. Разживайкина
Корректоры Е. Аксёнова, Т. Редькина
Компьютерная верстка К. Свищёв
Художественное оформление и макет Ю. Буга
© Кирилл Егерев, 2021
© ООО «Альпина Паблишер», 2021
Все права защищены. Данная электронная книга предназначена исключительно для частного использования в личных (некоммерческих) целях. Электронная книга, ее части, фрагменты и элементы, включая текст, изображения и иное, не подлежат копированию и любому другому использованию без разрешения правообладателя. В частности, запрещено такое использование, в результате которого электронная книга, ее часть, фрагмент или элемент станут доступными ограниченному или неопределенному кругу лиц, в том числе посредством сети интернет, независимо от того, будет предоставляться доступ за плату или безвозмездно.
Копирование, воспроизведение и иное использование электронной книги, ее частей, фрагментов и элементов, выходящее за пределы частного использования в личных (некоммерческих) целях, без согласия правообладателя является незаконным и влечет уголовную, административную и гражданскую ответственность.
Моей жене:
Красотка, я тебя люблю:-P
От автора
Привет, меня зовут Кирилл. Я профессионально пишу за деньги и около десяти лет делаю это для интерфейсов. Да-да, за тот текст в меню, на кнопках, в предупреждениях, формах обратной связи, сообщениях об ошибках и в прочих подобных штуках тоже кто-то отвечает.
Раньше такие тексты писали менеджеры и дизайнеры. В лучшем случае их проверял на опечатки и пунктуацию кто-то с хорошим русским языком. Затем эту обязанность «сгрузили» на копирайтеров и редакторов. Теперь есть специальный термин и целая новая профессия – UX-писатели.
Идея написать эту книгу появилась как ответ на очередной вопрос «Что почитать по UX-писательству?». Пожалуй, она могла бы и не выйти, если б не дизайнеры, с которыми я сейчас работаю в Сбере. Спасибо, ребята. Спасибо за вопросы про прикладной текст и всем остальным, кто их задавал, – в «Яндексе», «Иннове» и «Айгайдсе», «Айфонсе» и «Аймобилке», где мне посчастливилось поработать. Ай, как много всего в России начинается на «Ай».
Отвечая на подобные вопросы, я много раз рекомендовал читать что-то о чистоте мыслей в голове и на письме – Корнея Чуковского, Нору Галь, Уильяма Зинсера. Все они хороши. Жаль, что не всегда это то, что надо. Никто из этих авторов не писал именно про текст в интерфейсе, хотя все ратовали за принципы, которых я сейчас придерживаюсь в своей работе.
Совсем недавно Максим Ильяхов собрал, осмыслил и модернизировал многое, о чём говорили в XX веке именитые писатели, редакторы и переводчики. Максим напомнил нам, что с тех пор ничего не изменилось. И это даже к лучшему: он, можно сказать, создал для многих пишущих людей хорошие рабочие места. На живых примерах Ильяхов показал владельцам продуктов, что платить писателю за каждую тысячу знаков – это даже не прошлый, а позапрошлый век. Текст не выйдет хорошим, если его цена растёт с объёмом. Цена растёт – ценность падает.
Илья Бирман, известный российский проектировщик, дизайнер и арт-директор, хорошо структурировал представление информации и нормально рассказывает про пользовательский интерфейс. Когда я пришёл к нему на интенсив в 2011 году, он спросил, зачем мне это нужно, ведь я копирайтер. Признаюсь, тогда у меня было лишь смутное представление о том, зачем мне это. Но я чувствовал, что так надо.
Уже тогда мне поступало много задач вроде «вычитать текст на лендинге, особенно кнопки и всё, что с ними непосредственно связано» и «глянуть скрипт для службы поддержки». Я смотрел то, о чём меня просили, и задавал странные вопросы: «А почему? Зачем? Для кого это? Как посетитель попал сюда и что будет после нажатия вот этой кнопки?» В современной рабочей среде такие вопросы – обычное дело. Но в начале 2010-х годов в большинстве случаев от копирайтера требовалось прочитать задание и выполнить всё, что в нём написано. В точности. А вопросы – для слабаков.
Уверен, Илья больше не спрашивает у своих студентов, зачем они пришли. Теперь всё настолько взаимосвязано, что невозможно чётко разделить процессы. Больше нельзя планировать по принципу «вначале мы только проектируем и рисуем дизайн, а слова вставим в самом конце». Хорошего результата не достичь, если выстраивать работу разных специалистов отдельно друг от друга.
Я решил написать эту книгу, чтобы упорядочить собственный опыт в UX-писательстве. Разложить всё по полочкам и для самого себя в том числе.
И, видимо, для вас, если вы её читаете. Для всех, кому интересно знать, как работать с UX-писателем или UX-писателем. Надеюсь, она поможет в обоих случаях. Я постараюсь рассказывать о своём опыте таким образом, чтобы было одинаково интересно начинающим редакторам интерфейсов и их нанимателям, дизайнерам, менеджерам – всем, кому приходится работать с писателями и с текстом в интерфейсе.
Хочется верить, что менеджерам книга поможет понять, зачем в команде UX-писатель и почему никто другой не должен брать на себя его обязанности. Мы же не заставляем иллюстраторов программировать, так почему же Фёдор из бухгалтерии должен вычитывать всё, что написали дизайнеры? Ну, пятёрка у него по русскому и врождённая грамотность, что с того?
Дизайнеры, скорее всего, найдут много общего между своей работой и работой редактора – поймут всю бессмысленность просьбы «написать текст вот сюда, потому что именно тут для него выделено определённое место». Или даже научатся сами писать с первого раза так, что редактору Виталине останется лишь «окнуть». Так тоже бывает.
Начинающим UX-писателям – бывшим журналистам, корректорам и людям прочих близких профессий – книга должна дать новые знания. А если нет, то хотя бы упорядочить те, что уже есть, и… помочь узнать что-то новое! Со мной такое много раз случалось – попытки всё упорядочить приводили к обретению знаний.
Надеюсь, результат этой моей работы подскажет и способы налаживания отношений в команде. Хочется верить, что из книги станет понятно, чем занимается и за что отвечает редактор, писатель, копирайтер, как бы вы ни называли пишущего человека в своей команде, и где его ответственность пересекается с ответственностью других профессионалов. Эта книга о том, как сделать всё хорошо и не переругаться в процессе.
Ну и никто не отменял других мнений. Всё изложенное дальше – описание только моего опыта. Если вы тоже давно и успешно пишете для интерфейсов, наши взгляды на профессию могут отличаться. И если вам есть что рассказать или о чём поспорить – сделайте это. Я постараюсь ответить. Возможно, ваша точка зрения окажется вернее моей, и в следующем издании книга выйдет исправленной и дополненной. Или вы найдёте время, чтобы выпустить собственную книгу, и сделаете всё лучше меня.
Я в самом деле надеюсь, что с утверждениями, приведёнными в книге, будут не только соглашаться, но она вызовет желание поговорить. И если молчать нет сил, напишите мне на [email protected]. Общаясь, мы отыщем истину и как-то поучаствуем в формировании новой профессии.
Предисловие
«Да ну на фиг!» – сколько раз я, вы, все мы выкрикивали это или даже нечто грубее. Не понимали, как работает что-то новое, и бросали попытки разобраться в этом. Это непонимание возникает у нас при использовании многих цифровых продуктов – сайтов и мобильных приложений. Неприятные ситуации происходят и повторяются вообще всегда, когда мы как пользователи сталкиваемся с чуждой нам логикой и непривычными механиками.
Команда разработки может придумывать и делат удивительные вещи. И все их предположения могут оказаться ненужными нам, пользователям. Или востребованные функции будут реализованы настолько неудобно, что мы примемся вот так вскипать и бросать даже самые замечательные продукты.
И наоборот, мы как пользователи можем требовать такую функциональность и такие механики работы, которые кажутся непонятными и даже неприемлемыми команде разработки. Не в силах представить, что «вот это кому-то нужно», создатели сервисов, бывает, отказываются делать что-то действительно необходимое. Диалог не выстраивается из-за их нежелания понимать свою аудиторию, и это приводит к ухудшению пользовательского опыта. К ухудшению не дизайна, видимой оболочки, а самой сути – нарушает принципы работы вещей.
Стоп, что? Да, дизайн – это лишь видимая часть того, чем мы пользуемся. А пользовательский опыт – то, как мы это делаем. Например, нарисованная на экране кнопка – это в большей степени её дизайн. Форма, размер шрифта внутри неё, тень – всё это признаки видимого интерфейса, которые обычно описываются в дизайнерских гайдлайнах.
Или в дизайн-системах – как удобнее. Это такие многостраничные документы с описанием графических компонентов и правил их использования. Гайдлайны и системы помогают разрабатывать дизайн новых страниц быстрее и качественнее, а ещё с их помощью проще поддерживать единообразие в уже работающих продуктах.
Место же, где находится та кнопка, и принцип её работы – уже область пользовательского опыта. Если кнопка заметная и к ней удобно тянуться – пользовательский опыт хороший, а если она спрятана, расположена неудобно – опыт плохой, нужно что-то менять. И вот тут разработчикам важно ориентироваться не на собственное видение или принятые в компании гайды, а на пользователей продукта: кто они, какие у них возможности и желания.
Сами посмотрите: ниже два совершенно одинаковых меню с одинаковым внешним видом – дизайном. Однако меню находятся в разных местах экрана – пользовательский опыт различается.
Чтобы дотянуться до меню на левом рисунке, нужно раза в два «растянуть» большой палец руки, в которой вы держите телефон, или задействовать вторую руку.
Меню в верхней части экрана унаследовано от старых устройств. Сначала такие элементы навигации скопировали из продуктов для компьютера на коммуникаторы со стилусами. Как на компе работает, так и на мобиле пускай будет. И это было нормально – пользователи всё равно управлялись с устройствами с помощью двух рук: в одной держали коммуникатор, а в другой – стилус, которым тыкали в экран. Потом эти верхние меню переехали как есть на смартфоны с ёмкостными экранами, которые воспринимают не точечное нажатие с усилием, а прикосновение пальца живого человека. И вот тут дизайнеры поняли, что на таких мобильных устройствах меню наверху – неудобно. Исправили это не сразу и не во всех продуктах – до сих пор встречаются «динозавры». Но в основном навигационные меню сейчас располагаются в нижней части экрана – как на примере справа. Вы можете убедиться в этом сами – посмотрите приложения на вашем смартфоне.
Текст присутствует почти везде, где люди взаимодействуют с вашим продуктом. Даже больше того: когда пользователь сталкивается с чем-то непривычным или до этого ему неизвестным, именно внятное объяснение помогает ему не растеряться. И будь это объяснение текстовое или голосовое – не важно, лишь бы продукт говорил с человеком на понятном тому языке. Не значками или картинками, которые каждый новый пользователь может понять по-своему, а нормально сформулированными фразами.
Бывает, люди даже читают всё, что написано на экране: пункты меню, объясняющие фрагменты текста, заголовки, надписи на кнопках, всплывающие подсказки, примеры заполнения форм, предупреждения, сообщения об ошибках и многое другое. Чаще всего подобное происходит при взаимодействии с совершенно новыми или значительно обновлёнными продуктами. Тут особенно важно, как вы всё сформулируете.
И это касается не только интерфейса самого продукта. Например, если речь идёт о новой версии мобильного приложения, то пользовательский опыт может транслироваться наружу – в тексте «Что нового» в магазине приложений. Можно сообщить об изменениях дежурно, сухо и без подробностей:
Исправили ошибки, устранили недочёты.
Но какие именно ошибки и недочёты? Изменили ли вы то, что так беспокоило меня весь последний год? А вот я помню, был серьёзный недочёт. Не помню, какой именно. Но точно помню, что был. Сейчас запущу приложение и сразу вспомню. Интересно, его вы тоже устранили?
Пользователям всегда лучше сообщать об обновлениях более развёрнуто и точно, ведь это всё сделано для людей. Например, можно выделить что-то конкретное:
Помните, как приложение вылетало при редактировании профиля? Так вот, разработчики говорят, что устранили все возможные причины этого.
И дополнить общим:
Заодно мы поправили разные мелочи. Попробуйте сделать всё то, что раньше вызывало ошибки. Если заработает как надо – хорошо. А если нет – напишите нам о недочётах на почту саппорт@нашапочта.ру. Постараемся помочь.
Во втором случае текста намного больше, что как бы нехорошо. Но есть как минимум два аргумента в пользу такого варианта: в нём говорится о конкретных ошибках и он приглашает пользователей к диалогу, сообщает им о том, что разработчики тоже живые люди и понимают человеческую речь. А ещё второй вариант обещает пользователям не больше того, что действительно сделали разработчики. Он сообщает о конкретной правке и ещё нескольких менее значимых. А если осталось что-то ещё – пишите, вот почта.
Идём дальше. Если в приложении появилось что-то полезное, не только исчезли ошибки, то при первом запуске сразу после обновления вы можете показать пользователям экран с рассказом о новинках. Или два, три экрана – насколько у вас хватит фантазии, а у пользователей – терпения:
Ладно, вот вы рассказали обо всех нововведениях. Или люди нажали на крестик в углу первого же сообщения и поспешили перейти к обычным сценариям использования приложения. Но вдруг что-то пошло не по сценарию и в приложении появилось сообщение об ошибке. Допустим, вы в любом случае увидите код ошибки в логах и поймёте её суть. А пользователю решили ничего не объяснять, для него написали максимально коротко и по делу:
Вроде ясно, что что-то пошло не так. Но непонятно, что именно, как исправить ситуацию, чтобы не увидеть это сообщение в следующий раз. Снова появляется работа для писателя. Он может пообщаться с командой, выяснить, допустим, что ошибка происходит из-за добавления слишком большого числа людей в получатели, и сообщить пользователю об ошибке примерно так:
Уже лучше. Человек понимает, как он может всё исправить прямо сейчас – хотя бы попытаться уменьшить число получателей. Но снова он остаётся отчасти в неведении. Пользователь не знает, что именно надо делать, чтобы больше не попадать в такие ситуации. Вынужден гадать с числами. И опять имеет лишь унылую кнопку тихого согласия с происходящим – «окей». Часто подобные ситуации можно улучшить, подсказав, что именно можно сделать сейчас и как поступать вообще. Писатель снова идёт общаться с разработчиками и выясняет новые подробности. Так у него получается лучшее сообщение, какое продукт может показать в этой ситуации:
Вот теперь наверняка ясно, что именно произошло и что делать, чтобы подобные сообщения больше не показывались.
Ещё раз взглянем на варианты. Первый, самый короткий, часто даже не пишут, а накидывают из-за отсутствия времени «на такие мелочи». Это скорее дежурная заглушка, которую иногда забывают заменить на что-то осмысленное, – так и уходит в релиз. Без обид и претензий – вариант разработчиков.
Второй вариант может написать копирайтер, которому как-то формулируют задачу – просят рассказать о том, что произошло. Такой текст пишется перед выпуском продукта, когда кто-то внезапно вспоминает: «Ой, у нас же там заглушка!»
Третий выдаст 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-х. Поэтому, когда ко мне приходят с просьбой «написать что-то вот сюда, потому что тут предусмотрели место для текста», я в ответ заваливаю заказчиков вопросами, смысл которых легко сводится к паре слов: «К чему?» Предусмотрели – хорошо. Спасибо, что позаботились и о писателе – обеспечили работой человека. Но почему пользователям непременно нужен текст – именно здесь и вот такого объёма? Что тем несчастным с этим блоком текста делать? Какой от него прок?
Например, в уведомлении ниже заголовок говорит о готовности чего-то, а текст под ним – о том, что показан какой-то пример. Так что оставлять их рядом – ошибка уровня тавтологии. Сами посмотрите, как некрасиво. И если вам захотелось избавиться от чего-то одного – уже хорошо. Лучше, конечно, от менее наполненного смыслом «готово».
Или вот ещё пример: кто-то когда-то сказал, что иногда в продукте возникают непонятные ситуации. И о них обязательно надо сообщать пользователю. Кто-то другой придумал, как это показывать. Ещё кто-то реализовал. В итоге решили показать реализацию писателю – вдруг где-то там ошибки и русский страдает:
Читать бесплатно другие книги:
