Как писать интерфейсный текст

Подбирая правильные слова для вашего интерфейса, вы совершенствуете его дизайн.

Перевод статьи Кристины Брюс (Christina Bruce) How to write for interactions

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

Говорите по-человечески

Звучит очевидно, да? Но стоит повторить это еще раз. Мы слишком много лет потратили на взаимодействие с интерфейсами, которые разговаривают, как роботы.

Простой, человеческий язык воспринимается лучше, чем команды робота. Если вы не робот, конечно.

Совет: Пишите так, как если бы вы разговаривали с другим человеком. Вы когда-нибудь отвечали фразой «Запрос выполнен»? Конечно, нет. Но многие сайты и приложения даже сегодня общаются с нами именно так.

Беседа с пользователем не всегда уместна

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

Для названий наиболее важных действий пользователя тщательно обдумывайте каждое слово.

Советы

• Используйте «да» и «нет» с осторожностью — они могут противоречить желаемому результату и тем самым заставлять пользователя думать.
• Избегайте двойного отрицания.

Будьте последовательными

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

Это легко упустить из виду: обычно дизайн проходит несколько итераций, и мы больше сосредоточены на самой функциональности. Но когда приходит время для создания прототипа, дизайн-ревью или тестирования с пользователями, последовательность использования слов значительно влияет на юзабилити интерфейса.

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

В примере выше нет правильных или неправильных названий. По отдельности каждое поле выглядит нормально. Но когда мы проходим определенный путь, переходя от одного поля к другому, начинаются проблемы. Зачем заставлять пользователя думать даже лишнюю секунду?

Совет: Выберите один из вариантов и придерживайтесь его. Не уверены, какой лучше? Протестируйте оба! Подробнее об этом можно прочитать в другой статье.

Избегайте красивых слов

Когда вы выбираете текст для microcopy (надпись, которая транслирует какое-то небольшое сообщение внутри интерфейса: подсказка, кнопка CTA, инструкция, — все, что может как-то помочь, убедить или даже удивить пользователя. — Прим. пер.), лучше использовать что-то емкое и простое.

Используйте короткие и простые слова.

Начните с самых важных слов

Люди не читают каждое слово на странице или экране. Но они ищут информацию, которая может иметь для них значение. Ставьте в начале предложения наиболее важные слова, на которые должен обратить внимание пользователь.

Иногда может казаться, что теперь фраза звучит не очень естественно. Не беспокойтесь об этом.

Какие слова будет искать пользователь? Убедитесь, что вы поставили их в начале предложения. Так пользователям будет проще найти нужную информацию.

Не задавайте вопросов внутри подсказок

Подсказки могут стать отличным решением, если их правильно использовать. Они особенно полезны в следующих случаях:

• Пользователи обладают разным уровнем знаний;
• Сложные термины, которые требуют дополнительного объяснения;
• Правила и особенности, имеющие отношение к внутренней политике компаний.

Однако следует помнить, что за подсказками пользователь всегда обращается намеренно. Смысл такого обращения можно понимать как «Что это такое?» или «Узнать больше». В самой подсказке не нужно задавать вопросов или повторять слова из заголовка.

Повторение информации в подсказках излишне.

Проверьте, что заголовки отражают суть текста

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

Нет.

Если вы используете модальное окно, главная мысль должна быть отражена в заголовке.

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

Из названия ссылки или кнопки должно быть понятно, что произойдет дальше

Ссылки и названия кнопок должны быть ясными и давать исчерпывающее представление о том, что ждет пользователя дальше. Если вы даете какое-то обещание — сдержите его.

Кнопки можно сделать понятнее, если в их название добавить действие, которое намеревался совершить пользователь.

Совет: Используйте те же слова на следующей странице или экране. Так вы закрепите пользовательский опыт и оправдаете ожидания пользователей.

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

Не вините пользователя в ошибках

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

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

Не вините пользователя и не думайте, что он внимательно будет заполнять ваши формы. Кратко объясните, как можно исправить ситуацию.

В названиях переключателей не нужно использовать глагол

Сопротивляйтесь желанию добавить слово «включить» или какой-то другой глагол для названия переключателя. Сам вид данного элемента уже подразумевает состояния «включено» и «выключено», поэтому нет смысла добавлять глагол. Переключатель является аффордансом (от англ. afford — быть в состоянии; свойство или функция объекта, которая подсказывает, что с ним можно сделать. — Прим. пер.).

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

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

Совет: Из-за повсеместного использования в iOS и Android переключатели часто лучше работают на мобильных платформах.

Не используйте дополнительные глаголы

Избегайте дополнительных глаголов при описании действий системы. Зачем заставлять пользователя читать слова, которые не несут смысловой нагрузки?

Например, чем меньше слов вы используете для toast-уведомлений на Android, тем лучше они выглядят.