Кирилл Егерев написал книгу «Этой кнопке нужен текст» о том, как UX-писатели работают в продуктовых командах и как писать понятный и не раздражающий текст для ошибок, кнопок, переключателей и всех остальных элементов интерфейса.
Она хорошо и понятно написана (ну ещё бы) и тонкая. Опытные UX-писатели и дизайнеры интерфейсов, уделяющие внимание тексту в своих макетах, вряд ли узнают что-то новое. Но начинающим писателям и тем, кто хочет быть в курсе, книга должна быть полезна. Я выписал основные тезисы и добавил цитат.
Особенности работы
- В конце разработки UX-писателя привлекать поздно. Он работает с дизайнерами, проектировщиками и исследователями с нуля, когда есть только концепция продукта и ещё нет внешнего вида, интерфейса:
Привлекать писателя только в конце разработки — всё равно что впервые учить человека публично говорить в 22 года.
- Плохо, когда продукт разговаривает как робот — одним тоном в любой ситуации, он должен быть человечнее;
- В интерфейсном тексте не должно быть авторского стиля. Надо придерживаться гайдлайна, не уходить в себя, писать короткими итерациями и получать обратную связь от команды;
- У каждого интерфейсного текста должен быть смысл. Начинать надо с вопроса «Зачем?». Если понять смысл не выходит, здесь или не нужен текст, или ошибка в логике и UX;
- UX-писатель на то и UX, чтобы думать не только о тексте:
Такой специалист хоть и пишет, но это далеко не вся его работа — он сам немного дизайнер, исследователь, проектировщик и даже психолог. Он не просто «наваливает» текст в жёстко заданные рамки, а определяет эти рамки. Попутно указывает на сложности, которые могут возникнуть у пользователей, и расширяет «узкие горлышки».
- Он может общаться с командой целый день и написать всего две строчки или оставить текст без изменений. Видна лишь малая часть его работы, как айсберг:
Бывает, смотришь на результат его работы и диву даёшься: о чём он целый день трещал со всеми? Написал-то всего две строчки или даже всё удалил. Ещё и дизайнеры теперь задумали всё менять. Ну что за гнус? Человек — палка в любимом колесе вашей гладкой разработки.
- Иногда итоговый макет со всеми подсказками становится громоздким. Проблема в том, что исходный вариант был слишком выхолощенным и не учитывал проработанных UX-писателем ситуаций;
- Это нормально — написать для новой фичи не только интерфейсный текст, но и минимальный набор промо вроде пуш-уведомления, письма с анонсом, описания обновления для магазина приложений. Никто лучше UX-писателя о фиче не расскажет.
Общие рекомендации
- Если выбирать лучшие формулировки АБ-тестированием, со временем текст в разных частях продукта утратит связность, голос продукта может пропасть. И придётся это разгребать;
- Упрощайте, чтобы текст можно было прочитать вслух другу в баре;
- Проверяйте факты, чтобы текст не обманывал и случайно не вводил в заблуждение;
- Придерживайтесь однородности в формулировках (например, подписывайте все чекбоксы одной группы с использованием существительных) и в наименованиях (один и тот же объект в разных местах называйте одинаково, с этим поможет словарь);
- Текст должен быть лаконичным, то есть кратким, но сохраняющим понятность;
- Чем меньше текста, тем обиднее опечатки и ошибки;
- Смотрите, как текст вписывается туда, где он должен работать. Если новый пункт вертикального меню сильно длиннее остальных, стоит подобрать для него формулировку покороче:
Иногда, чтобы сделать текст немного красивее, не нужно пытаться остаться в созданных кем-то рамках. Лучше выйти за них, взглянуть на ситуацию в целом и попробовать изменить конкретные слова, сохранив общий смысл.
По отдельным элементам интерфейса
- Текст на кнопке часто — указание, что система должна сделать («Отправить»). Иногда — заявление, что пользователь что-то прочитал, понял и принял («Хорошо», «Понятно»):
Формулировать от лица пользователя в интерфейсе стоит только элементы, которые исполняются от его лица или запускают процесс исполнения. Такие активные элементы — это кнопки и ссылки, но точно не поля для ввода текста.
- Не стоит в русскоязычном интерфейсе писать на кнопке «ОК»;
- Чтобы кнопка «Согласен» не указывала на конкретный пол, можно писать «Принимаю» или «Соглашаюсь» — ответ на вопрос «Что делаю?»;
- Если после нажатия пользователю надо сделать что-то ещё, текст на кнопке лучше написать с троеточием («Поделиться…», «Выбрать файл…»);
- Если поиск работает плохо, на кнопке лучше писать «Искать», а не «Найти», чтобы не обещать пользователю результат;
- Названия переключателей часто формулируют существительными — так проще обозначать, что включается и выключается («Свет в ванной»). Но варианты с глаголами тоже бывают («Разрешать другим подключаться»);
- Плейсхолдеры для полей ввода часто начинаются со слов «Обычно» и «Например», чтобы показать, что вводят другие пользователи:
Этот приём помогает показать, о чём якобы пишут другие люди, «развязать язык» и быстрее покончить с этим делом.
- Во всплывающих подсказках к полям формы лучше писать, что конкретно нужно сделать, чтобы заполнить поле («Напишите адрес»);
- Пункты навигационного меню лучше называть так же как и страницы, на которые они ведут. Рано или поздно возникнет путаница, пользователь будет искать страницу «О компании» и не увидит ни одного пункта, начинающегося на «О»;
- Контекстное меню позволяет совершать действия. Его пункты лучше формулировать как указания, что система должна сделать. Но если все привыкли к пункту «Свойства», не надо гнаться за однородностью и писать «Показать свойства».
Есть и сомнительные рекомендации вроде отображения требований к длине пароля в плейсхолдере поля для ввода пароля. Но Кирилл сам пишет:
Очень надеюсь, что вы не надёргаете из книжки отдельных советов и не побежите прямо сейчас спорить со своим UX-писателем. Это не чёткое руководство к действию.
Технологии цифрового маркетинга — книга, где я был соавтором (параграф про создание сайта) и литературным редактором (привёл текст к единой стилистике и упростил формулировки). От 249 рублей.