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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кнопки

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

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

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

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

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

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

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

Переключатели и радиокнопки

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

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

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

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

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

Чекбоксы

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

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

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

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

Показывать на маршруте кемпинги и магазины. В экстренных случаях отправлять мои координаты избранным контактам и звонить 112.

Поле для ввода текста

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

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

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

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

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

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

Пункты меню

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

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

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

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

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

Текст

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

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

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

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

0
52 комментария
Написать комментарий...
Звенислав Николаевич

«Добро», «Ладушки», «Я тебя услышал» можно еще. И «Обкашлять вопросик» вместо «Спросить».

Ответить
Развернуть ветку
Ирина Фролова
Ответить
Развернуть ветку
2 комментария
greg chudnoff

"Океюшки" - зе бест

Ответить
Развернуть ветку
Yury S
уже накопилась куча клёвых штук
Поле для ввода текста — такая штука, в которую пользователю надо вводить текст 
Атомарный дизайн — одна из тех штук
Ух ты, вот тут штука, которую все ругают
А интерфейс — диалог. И в диалоге этом всегда присутствуют реплики пользователя — активные кнопки, ссылки и всё такое.
 ссылки и всё такое.

Пиздец. И это книга о текстах и об интерфейсе  

Ответить
Развернуть ветку
Mercator

О текстах для интерфейсов.

Ответить
Развернуть ветку
1 комментарий
Роботы

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

Ответить
Развернуть ветку
alex gour

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

Ответить
Развернуть ветку
3 комментария
alex gour

честно, пока дочитал, забыл про что читаю)) вернулся вверх и ок) полезно))

Ответить
Развернуть ветку
Дмитрий Шошин

Ок.

Ответить
Развернуть ветку
Незабудка классовой борьбы
редакторы, копирайтеры и прочие подобные люди.

очень уважительно, ничего не скажешь

Ответить
Развернуть ветку
Mercator

И прочие подобные уважаемые обидчивые люди.

Ответить
Развернуть ветку
Татьяна Митрофанова

Дизайн должен быть быстро читаемым. Потому что главное все же - контент сайта, а дизайн это так, обертка для конфеты. Поэтому ОК вместо "Соглашаюсь" и тумблеры - это необходимость 1)чтобы элементы не растягивались от длинного текста 2)чтобы все эти кнопки не отнимали много времени. Посетитель должен быстро глянуть, воспринять информацию и кликнуть.
Много текста повсюду будешь впихивать - сайт будет выглядеть одной большой свалкой, а элементы - растягиваться. ОК воспринимается быстро, "Мне все понятно" - нужно отвлечься и посмотреть, что там написано. Тумблеры - это быстро и компактно, а так как они есть повсюду, то не поймут, за что они отвечают, только те, кто недавно из-под камня вылез. 

Ответить
Развернуть ветку
Mercator

Автор не предлагает впихивать везде кучу текста.

Ответить
Развернуть ветку
Огурец Молодец

Что т столько много и заумно написано о простых вещах, что стало сложно :-\
Проще Ильяхова еще раз перечитать.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
12 комментариев
Ленин-гриб
 Атомарный дизайн — это система, в которой всё построено из маленьких элементов —атомов.

Какой же кринж, ору сцк, аффтар, не жалей выгорающие пиксели, жги 😂

Ответить
Развернуть ветку
Андрей Крамарь

Ты воспринял эту фразу буквально, да?

Ответить
Развернуть ветку
2 комментария
Никита

Предзаказал книгу и после прочтения немного расстроен. 2 из 3 глав совсем для новичков, если читал Ильяховаи и т.п. то будет скучно. Самое интересное это третья глава где есть практика и какие-то примеры. Ну и сама книга очень маленькая. Стоила бы она рублей 300 ещё ок.

Даже не знаю кому ее посоветовать кроме совсем новичков в теме.

Ответить
Развернуть ветку
Mercator

В какой теме? Ильяхов не пишет о текстах в интерфейсе.

Ответить
Развернуть ветку
2 комментария
Art.Spark

а сразу непонятно было что это вода ?))

Ответить
Развернуть ветку
1 комментарий
Art.Spark

целая книга,
на то что можно уместить в половину статьи.
"книга о названия на кнопке".
ждем третий том "почему круглое а не квадратное"

Ответить
Развернуть ветку
Anton Zhitarev

Количество ошибок зашкаливает и оно понятно - орфографический словарь утонул в воде из статьи.

Ответить
Развернуть ветку
Art.Spark

"я дизайнер, я так насрал"

Ответить
Развернуть ветку
Artem Glazkov

Надеюсь, книга написана не так, как эта статья — лаконичнее и безо всяких «таких штук» 😐

Ответить
Развернуть ветку
Mercator

Это отрывки из книги. Дословно.

Ответить
Развернуть ветку
1 комментарий
Art.Spark

хаха. смешно )))
само название "книга" вас не настораживает ?)))
...об ОДНОМ принципе, смысл которого умещается в два-три предложения.

Ответить
Развернуть ветку
Юрий Б.

Увидел текст и постановку проблемы, сразу подумал про Ильяхова. Что характерно, не я один подумал, как стало ясно из каментов. Но это не дотягивает до Ильяхова никак, извините.

Ответить
Развернуть ветку
Yury S

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

А про то, что касается текстов интерфейсах — на английском более чем достаточно материалов. Общие паттерны взаимодействия у нас практически одинаковые так что достаточно просто грамотно адаптировать best practices в русском контексте. Ильяхов кстати, тут как раз не особенно поможет потому что у него не про интерфейсы (там другая специфика и то, что подойдет для контента часто не получится натянуть на UI). 

Выше мало внимания тем моментам где текст в интерфейсе значительно больше чем слово/фраза на кнопке. Это разные onboarding, инструкции (guides), подсказки (tips), уведомления (notifications), напоминания (reminders), — все многообразие вспомогательных текстов, которые часто очень важны и неотъемлемая часть опыта. На кнопках/меню может без ошибок написать и программист (здесь это напрямую связан с внутренней логикой приложения). Но проработать все  тексты, как цельную систему, понятную, удобную и с приятным стилем общения это то за чем действительно существует UX-writing (да, сама фраза “ux-писательство" удивительно корявая, лучше оставить как есть)

Ответить
Развернуть ветку
Andrey Greenberg

Статья посвящается кнопке? Да, соглашусь. Многослипшихсябукв... 

Ответить
Развернуть ветку
Андрей Пятин

подождите, вы просто выложили фрагмент чьей-то книги?
зачем?

Ответить
Развернуть ветку
Андрей Крамарь

Чтобы о книге узнало большее количество людей, конечно. Или у тебя есть более гениальные теории?

Ответить
Развернуть ветку
3 комментария
Константин Рогов

ок

Ответить
Развернуть ветку
49 комментариев
Раскрывать всегда