Этой кнопке нужен текст

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

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

Особенности работы

  • В конце разработки UX-писателя привлекать поздно. Он работает с дизайнерами, проектировщиками и исследователями с нуля, когда есть только концепция продукта и ещё нет внешнего вида, интерфейса:

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

  • Плохо, когда продукт разговаривает как робот — одним тоном в любой ситуации, он должен быть человечнее;
  • В интерфейсном тексте не должно быть авторского стиля. Надо придерживаться гайдлайна, не уходить в себя, писать короткими итерациями и получать обратную связь от команды;
  • У каждого интерфейсного текста должен быть смысл. Начинать надо с вопроса «Зачем?». Если понять смысл не выходит, здесь или не нужен текст, или ошибка в логике и UX;
  • UX-писатель на то и UX, чтобы думать не только о тексте:

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

  • Он может общаться с командой целый день и написать всего две строчки или оставить текст без изменений. Видна лишь малая часть его работы, как айсберг:

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

  • Иногда итоговый макет со всеми подсказками становится громоздким. Проблема в том, что исходный вариант был слишком выхолощенным и не учитывал проработанных UX-писателем ситуаций;
  • Это нормально — написать для новой фичи не только интерфейсный текст, но и минимальный набор промо вроде пуш-уведомления, письма с анонсом, описания обновления для магазина приложений. Никто лучше UX-писателя о фиче не расскажет.

Общие рекомендации

  • Если выбирать лучшие формулировки АБ-тестированием, со временем текст в разных частях продукта утратит связность, голос продукта может пропасть. И придётся это разгребать;
  • Упрощайте, чтобы текст можно было прочитать вслух другу в баре;
  • Проверяйте факты, чтобы текст не обманывал и случайно не вводил в заблуждение;
  • Придерживайтесь однородности в формулировках (например, подписывайте все чекбоксы одной группы с использованием существительных) и в наименованиях (один и тот же объект в разных местах называйте одинаково, с этим поможет словарь);
  • Текст должен быть лаконичным, то есть кратким, но сохраняющим понятность;
  • Чем меньше текста, тем обиднее опечатки и ошибки;
  • Смотрите, как текст вписывается туда, где он должен работать. Если новый пункт вертикального меню сильно длиннее остальных, стоит подобрать для него формулировку покороче:

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

По отдельным элементам интерфейса

  • Текст на кнопке часто — указание, что система должна сделать («Отправить»). Иногда — заявление, что пользователь что-то прочитал, понял и принял («Хорошо», «Понятно»):

Формулировать от лица пользователя в интерфейсе стоит только элементы, которые исполняются от его лица или запускают процесс исполнения. Такие активные элементы — это кнопки и ссылки, но точно не поля для ввода текста.

  • Не стоит в русскоязычном интерфейсе писать на кнопке «ОК»;
  • Чтобы кнопка «Согласен» не указывала на конкретный пол, можно писать «Принимаю» или «Соглашаюсь» — ответ на вопрос «Что делаю?»;
  • Если после нажатия пользователю надо сделать что-то ещё, текст на кнопке лучше написать с троеточием («Поделиться…», «Выбрать файл…»);
  • Если поиск работает плохо, на кнопке лучше писать «Искать», а не «Найти», чтобы не обещать пользователю результат;
  • Названия переключателей часто формулируют существительными — так проще обозначать, что включается и выключается («Свет в ванной»). Но варианты с глаголами тоже бывают («Разрешать другим подключаться»);
  • Плейсхолдеры для полей ввода часто начинаются со слов «Обычно» и «Например», чтобы показать, что вводят другие пользователи:

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

  • Во всплывающих подсказках к полям формы лучше писать, что конкретно нужно сделать, чтобы заполнить поле («Напишите адрес»);
  • Пункты навигационного меню лучше называть так же как и страницы, на которые они ведут. Рано или поздно возникнет путаница, пользователь будет искать страницу «О компании» и не увидит ни одного пункта, начинающегося на «О»;
  • Контекстное меню позволяет совершать действия. Его пункты лучше формулировать как указания, что система должна сделать. Но если все привыкли к пункту «Свойства», не надо гнаться за однородностью и писать «Показать свойства».

Есть и сомнительные рекомендации вроде отображения требований к длине пароля в плейсхолдере поля для ввода пароля. Но Кирилл сам пишет:

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

Опечатка? Выделите её и нажмите кнопки Control и Enter.

Технологии цифрового маркетинга — книга, где я был соавтором (параграф про создание сайта) и литературным редактором (привёл текст к единой стилистике и упростил формулировки). От 249 рублей.