Не «ОК», а «соглашаюсь», «ладно», «хорошо» или «понятно»: как формулировать текст для чекбоксов, кнопок и переключателей

Отрывок из книги «Этой кнопке нужен текст. O UX-писательстве коротко и понятно» Кирилла Егерева, которая вышла в издательстве «Альпина Паблишер».

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

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

Я сейчас о тех, которые пишут много чего, в том числе для интерфейсов, и любят хвалиться, как между реально стоящими делами могут «даже страницу 404 написать». Мало у кого из пишущих, тем более у таких, которые «между делом», вы научитесь систематизациии организации дизайнерского уровня. Итак, атомы. Вот что интересного здесь есть для писателя:

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

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

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

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

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

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

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

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

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

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

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

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

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

Уменя есть пунктик, над которым кто-то тихо смеётся, другие его просто принимают, третьи дико гогочут и радостно вписывают очередную кнопку «ОК» в свой продукт.

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

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

Что такое «окей»? Что оно должно означать для пользователя? И зачем оно нужно, когда в русском языке есть куча слов с более конкретным значением? Надо с чем-то согласиться — лучше так и назвать кнопку: «соглашаюсь». Нужно получить от пользователя понимание произошедшего — «ладно», «хорошо», «понятно» — отличные варианты. От пользователя требуется полезное действие — тем более кнопке «ОК» места нет.

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

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

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

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

Список формируется из существительных — дописывайте новые пункты только существительными. Обычно радиокнопки связаны между собой одной сущностью, которую они помогают настраивать. И чтобы всё не разъехалось, нужно соблюдать единообразие внутри группы.

Вцелом поформулировкам тут почти полная свобода действий, потому что сами чекбоксы могут стоять как отдельно, так и в списках. Отдельный чекбокс— это почти всегда какая-нибудь околоюридическая история. В таком случае текст либо длинный, либо очень длинный:

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

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

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

Поле для ввода текста — такая штука, в которую пользователю надо вводить текст (Л — логика). Вроде не такая, в которой самому продукту стоит что-то писать. Но, во-первых, без подсказок вроде «пишите прямо здесь» пользователи часто не понимают, что делать и куда вписать своё сообщение.

Во-вторых, в интерфейсе каждый квадратный сантиметр на счету. Так почему бы не использовать всю доступную площадь с максимальной отдачей? Тем более что поле для ввода текста — это иногда и строка поиска. А что, пользовательский поисковый запрос — такой же текст, который кто-то вводит. Строка для ввода поискового запроса — это маленькое поле. Подсказку в нём можно сформулировать стандартно-дежурно:

А можно немного повеселиться. Только в таком случае надо учитывать контекст — насколько к месту окажется та или иная формулировка:

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

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

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

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

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

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

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

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

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

Всякие подсказки — текст. Реплики AI-ассистента в чате или голосом — текст. Текстом же мы подписываем поля в форме обратной связи. Я сейчас про названия полей — локальные заголовки и подзаголовки, а не про подсказки в самих полях для ввода текста, о которых уже поговорили раньше. Обычный текст присутствует в значках, которые ещё принято называть иконками.

Без текстовой подписи поди разберись, что означают все эти картинки. А с подписями вроде «Здоровье» или «Анализы» сразу понятно, что это за приложения, — там в целом о моём здоровье, а здесь только результаты анализов.

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

#uxредактура #интерфейсы