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

Только не нужно втаскивать в интерфейс всё, что и в самом деле обычно пишут пользователи. Честность – хорошо, но в таком случае вы, скорее всего, проиграете, когда какой-то пользователь решит поругать ваш продукт и вы на автомате дёрнете в интерфейс часть его комментария. Все мотивирующие примеры в полях для ввода текста всегда пишет или согласовывает редактор. В противном случае и так не лучший продукт может стать ещё хуже – пользователи не обращаются в поддержку или к разработчикам просто так, в 99 % случаев они жалуются на проблемы. Чужое негативное мнение ухудшает отношение людей и заставляет их придираться к продукту по пустякам. Срабатывает стадное чувство: «Ух ты, вот тут штука, которую все ругают. Интересно, а за что могу поругать её я?»

Существует два вида меню: навигационное и контекстное. И следует применять разные формулировки, в зависимости от того, для какого именно меню мы пишем.

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

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

Контекстное менюпозволяет совершать действия, например, с содержимым экрана. Поэтому его пункты лучше формулировать именно действиями – глаголами, которые отвечают на вопрос «что сделать?»:

Правда, не всегда контекстное меню получается сформулировать только действиями. Например, глупо гнаться за однородностью и называть один из пунктов «Показать свойства», в то время как все пользователи привыкли к просто «Свойствам» – нажал на «Свойства» и посмотрел свойства.

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

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

Например, заголовок ошибки состоит из текста, подзаголовок или объяснение – тоже текст. Всякие подсказки – текст. Реплики AI-ассистента в чате или голосом – текст. Текстом же мы подписываем поля в форме обратной связи. Я сейчас про названия полей – локальные заголовки и подзаголовки, а не про подсказки в самих полях для ввода текста, о которых уже поговорили раньше. Обычный текст присутствует в значках, которые ещё принято называть иконками. Без текстовой подписи поди разберись, что означают все эти картинки. А с подписями вроде «Здоровье» или «Анализы» сразу понятно, что это за приложения, – там в целом о моём здоровье, а здесь только результаты анализов.

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

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

Такая ситуация: к редактору пришли с просьбой согласовать текст для кнопки. Вроде всё просто, надо подтвердить пару слов – «Получить код».

Даже без какого-либо контекста ясно, что нажатие кнопки отправляет какой-то код куда-то. Пользователю этот код, скорее всего, нужен для подтверждения при регистрации или при каком-то другом действии. Но редактор всё равно решает приложить немного больше усилий и спрашивает подробности: «Хорошо. Но на всякий случай: что именно эта кнопка делает и какое у неё окружение? Можно всю страницу посмотреть?» Конечно, да. В ответ ему присылают такой скрин:

Допустим, этот редактор – вы и вам решать, нормально ли сформулирована кнопка. Не читайте дальше, прямо сейчас попробуйте подумать над этой задачей самостоятельно – нужно ли здесь что-то улучшать и как именно вы бы поступили. Что предложили бы? А после мы сверим мысли.

Ну или сразу смотрите моё решение.

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

И если подумать о производимом действии, то можем ли мы гарантировать пользователю получение кода, если он нажмёт на кнопку «получить код»? А если он ошибётся и введёт чужой номер телефона? А если у нас возникнет какая-то ошибка, из-за которой код не отправится? А если ошибётся мобильный оператор? Да много что может случиться. И вот пользователь нажимает кнопку «получить код», долго ждёт, повторно нажимает «получить код», снова ждёт и ничего не получает. Хотя надпись на кнопке обещала, что пользователь обязательно всё получит.

Человек чувствует себя идиотом, потому что не может получить этот код. Но почему это идиот – он? Виновата система, которой он решил воспользоваться! И вот уже мы страдаем от того, что теряем человека, который мог стать нашим пользователем. Но мы разошлись с ним из-за одной неверно сформулированной кнопки.

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

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

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