Тексты в интерфейсе: если строка не пишется, дело не в словах

Тексты в интерфейсе — это всё, что человек читает по дороге к цели: подписи кнопок, названия полей, подсказки, сообщения об ошибках, тексты пустых экранов и окна подтверждения. Их ещё называют UX-текстами или микротекстами, а работу над ними — UX-копирайтингом. Правило для всех одно: строка отвечает на вопрос, который у человека возник в этом месте экрана. Кнопка говорит, что случится после нажатия: «Оплатить 2 400 ₽» вместо «ОК». Ошибка говорит, что исправить: «Введите номер из 10 цифр» вместо «Неверный формат». Название поля стоит над полем и не исчезает, когда человек начал печатать. Пустой экран объясняет, что здесь появится, и даёт первую кнопку. Окно «Вы уверены?» появляется только перед тем, что нельзя отменить, и называет, что именно пропадёт.

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

Что из этого вообще читают?

Немного. Якоб Нильсен в 2008 году разобрал данные немецкого исследования: 25 человек, их обычная работа в браузере, 45 тысяч просмотров страниц. На средней странице было 593 слова. За визит люди успевали прочитать не больше 28% из них, а скорее около 20%. Хотя бы половину текста читали только на страницах не длиннее 111 слов.

Интерфейс — та же страница, только короче. Подписи пробегают глазами, подсказки пропускают, пользовательское соглашение пролистывают одним движением пальца.

Исключение одно — ошибка. Её дочитывают до точки, потому что дальше без неё не пройти. Человек застрял, торопится и злится. И именно в эту минуту он внимательнее всего читает ваш продукт.

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

Что писать на кнопке?

То, что случится после нажатия. Глагол и, если помещается, предмет: «Отправить заявку», «Удалить черновик», «Оплатить 2 400 ₽». Человек не должен перечитывать вопрос над кнопкой, чтобы понять, что значит «Да». Тем более, как выяснилось выше, вопрос он не читал.

Самая дорогая подпись кнопки, о которой известно, — «Зарегистрироваться». Джаред Спул рассказывал о форме крупного интернет-магазина. Человек собрал корзину, нажал «Оформить заказ» и попадал на экран с почтой, паролем и двумя кнопками: «Войти» и «Зарегистрироваться». На тестах новые покупатели не хотели регистрироваться: они пришли купить, а заводить отношения с магазином не собирались. Постоянные не помнили, с какой почтой и каким паролем регистрировались. 45% покупателей оказались зарегистрированы по нескольку раз. Сброс пароля запрашивали 160 тысяч раз в день, и три четверти запросивших покупку так и не завершали.

Кнопку заменили на «Продолжить» и добавили пояснение: регистрироваться не нужно, заказ можно оформить и так, а аккаунт при желании создадите по ходу. Покупателей стало на 45% больше. Первый месяц принёс 15 миллионов долларов сверху, первый год — 300 миллионов.

Важно, что именно починили. Старая кнопка была подписана честно: экран требовал регистрации. Никакое слово на ней не спасло бы дело — ни «Создать аккаунт», ни «Присоединиться». Сначала убрали требование. Только после этого появилась строка, которую стоило написать.

Как написать сообщение об ошибке?

Ответить на два вопроса: что не так и что сделать. Второй важнее. «Неверный формат даты» называет проблему и оставляет человека с ней наедине. Какой формат верный, угадайте сами.

Хороший образец — дизайн-система британских госуслуг. Там ошибку пишут теми же словами, что и вопрос. Спросили «Сколько часов в неделю вы работаете?» — ошибка «Введите, сколько часов в неделю вы работаете». Пустое поле получает инструкцию: «Введите имя». Слишком длинное значение — описание: «Имя должно быть не длиннее 35 символов». И отдельно перечислены слова, которых в ошибке быть не должно. «Неверно» ничего не добавляет. «Пожалуйста» звучит так, будто исправлять необязательно. «Извините» не помогает исправить. «Упс» и прочие шутки тоже мимо.

Оттуда же простая проверка: прочитайте сообщение вслух. Если живой человек так не скажет, перепишите.

Обвинять человека в тексте ошибки не нужно. У Nielsen Norman Group есть рубрика для оценки ошибок, и один из её пунктов такой: тон доброжелательный, без юмора, ответственность на системе. «Вы ввели неправильный код» и «Код не подошёл» сообщают одно и то же. Только первая строка ещё и показывает пальцем.

Где показывать ошибку и почему нельзя стирать введённое, разобрано в чек-листе UX-аудита. Здесь только слова.

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

Что писать в поле и подсказке?

Название поля — над полем, коротко: «Телефон», «Дата рождения». Пример формата — подсказкой под названием: «Например, 12.03.1990». Серый текст внутри поля исчезает с первой буквой, и человек остаётся с полем, про которое уже не помнит, что в нём просили. Хуже всего, когда серым внутри написано само название. Заполнив половину формы, приходится стирать введённое, чтобы проверить, туда ли писал.

Если поле вызывает вопрос «а вам зачем?», ответьте на него тут же, под полем, одной строкой. «Телефон нужен, чтобы курьер позвонил у двери». Самокат в своём гайде по текстам делает так с адресом: объясняет, что без него не показать товары, которые к вам привезут.

Что показать на пустом экране?

Пустой экран, или пустое состояние (empty state), видит каждый новичок: заказов нет, проектов нет, в отчёте пусто. Кейт Каплан из Nielsen Norman Group называет три его задачи. Показать, что система работает и здесь просто пока ничего нет. Объяснить, что тут появится. Дать прямой путь к первому действию. Совсем пустой экран, по её словам, заставляет сомневаться, работает ли система вообще.

«Нет данных» — это отписка. Лучше так: «Здесь появятся заказы, когда клиенты начнут покупать. Начните с первого товара» — и кнопка «Добавить товар». Если пусто из-за фильтра, скажите и это: «По запросу „гарнитура“ ничего нет. Сбросить фильтры?»

Пустой экран — редкое место, где новичок читает внимательно: больше читать нечего. Поэтому он учит лучше приветственной карусели из пяти слайдов. Подсказка появляется ровно тогда, когда нужна, и рядом с кнопкой, которую надо нажать. Каплан объясняет почему: подсказку на месте можно сразу применить, поэтому она запоминается лучше обязательного обучения при первом входе.

Когда спрашивать «Вы уверены?»

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

Где можно отменить, нужна отмена: «Письмо удалено. Вернуть». Где нельзя, окно называет последствия: «Удалить проект „Ремонт кухни“ и 48 файлов в нём? Восстановить их не получится». На кнопке — «Удалить проект». У GitHub в примере так же: «Удалить репозиторий» вместо «Да».

Кто должен писать тексты интерфейса?

Тот, кто рисует экран, и тогда же, когда рисует. «Текст кнопки» и «Lorem ipsum» в макете значат, что экран ещё не придуман до конца. В Т-Бизнесе UX-редакторы, судя по описанию вакансии, прорабатывают сценарии и логику интерфейса и вместе с дизайнерами отвечают за решение задачи пользователя. В Самокате редактор подключается до готового дизайна. Обе редакции пришли к одному: текст — часть того, как экран работает.

Отдельного редактора у небольшой команды обычно нет. Тогда тексты работающего продукта можно вычитать за вечер.

1. Соберите все строки интерфейса в одну таблицу: из макетов, файлов перевода, кода. Ошибки тоже — обычно они лежат в коде, вместе с проверками.
2. Найдите кнопки без глагола: «ОК», «Да», «Готово». Подпишите их действием.
3. Каждой ошибке задайте вопрос «а что мне теперь делать?». Нет ответа в строке — допишите.
4. Прочитайте всё вслух. Где звучит как справка из ЖЭКа, перепишите. Где одно и то же называется по-разному («заявка», «обращение», «тикет»), выберите одно слово и закрепите его в дизайн-системе.
5. Строки, которые не получилось написать коротко, не полируйте. Отнесите их дизайнеру или продакту как ошибку экрана.

Строка, которая не пишется

Пятый пункт полезнее остальных: трудная строка почти всегда описывает неудачный экран.

Подсказка к паролю на три строки — восемь символов, заглавная буква, цифра, спецсимвол, только не кавычки — это не плохой текст. Это правило, удобное системе, которое переложили на человека. Ошибку, которую нечем закончить, показывает экран, который сам не знает, что делать дальше. «Вы уверены?», на которое честный ответ «не очень», висит перед действием, которое надо было сделать отменяемым. Редактор здесь поможет примерно так же, как помог бы магазину у Спула подобрать слово для второй кнопки.

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