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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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