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

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

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

Например, странно сначала говорить так:

Потом вот так:

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

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

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

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

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

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

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

UX-писательство иногда подменяют понятием «микрокопия» (microcopy). Якобы это одна сущность. Но конечно, это не одно и то же. И да, они тесно связаны.

Приставка «микро-» тут не просто так. Она говорит о том, что текст маленький. И он, как правило, не просто маленький, он ещё и находится в очень ограниченном пространстве.

Это такой текст, который должен быть компактным. Не коротким. Сокращать, конечно, круто. Но сокращения часто приводят к потере смысла. Текст в интерфейсе должен быть именно компактным. Лаконичным, если угодно, несущим максимум пользы в минимальном количестве знаков и слов. И понятным. Естественно, текст в интерфейсе должен быть ещё и понятным. В противном случае польза от него сводится к нулю.

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

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

Предположим ситуацию, в которой разработчики уже добавили в интерфейс такое сообщение:

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