Правда, не всегда контекстное меню получается сформулировать только действиями. Например, глупо гнаться за однородностью и называть один из пунктов «Показать свойства», в то время как все пользователи привыкли к просто «Свойствам» – нажал на «Свойства» и посмотрел свойства.
Если доступное действие всего одно и это не изменится никогда, то лучше нарисовать в интерфейсе отдельную кнопку для этого действия. Но, когда есть малейшая возможность того, что в будущем появятся второй и следующие пункты, можно сразу оформлять первый в контекстном меню. И пускай сначала оно будет состоять всего из одного пункта. Тут ограничений нет – не строгая навигация.
Текст
Неактивный текст, на который нельзя нажать и получить результат, – универсальный атом. Он встаёт вообще куда угодно и сочетается почти со всеми другими элементами в любом интерфейсе.
Например, заголовок ошибки состоит из текста, подзаголовок или объяснение – тоже текст. Всякие подсказки – текст. Реплики AI-ассистента в чате или голосом – текст. Текстом же мы подписываем поля в форме обратной связи. Я сейчас про названия полей – локальные заголовки и подзаголовки, а не про подсказки в самих полях для ввода текста, о которых уже поговорили раньше. Обычный текст присутствует в значках, которые ещё принято называть иконками. Без текстовой подписи поди разберись, что означают все эти картинки. А с подписями вроде «Здоровье» или «Анализы» сразу понятно, что это за приложения, – там в целом о моём здоровье, а здесь только результаты анализов.
Так как текст легко встаёт везде, его можно формулировать множеством способов. Лишь бы в итоге всё выходило гармонично, грамотно, понятно, полезно и легко.
Вот и все основные атомы, из которых можно строить интерфейсные тексты – как дома из кирпичей. О том, как писать каждый из них, я расскажу в следующих главах.
Глава 11
Пишем кнопки
Такая ситуация: к редактору пришли с просьбой согласовать текст для кнопки. Вроде всё просто, надо подтвердить пару слов – «Получить код».
Даже без какого-либо контекста ясно, что нажатие кнопки отправляет какой-то код куда-то. Пользователю этот код, скорее всего, нужен для подтверждения при регистрации или при каком-то другом действии. Но редактор всё равно решает приложить немного больше усилий и спрашивает подробности: «Хорошо. Но на всякий случай: что именно эта кнопка делает и какое у неё окружение? Можно всю страницу посмотреть?» Конечно, да. В ответ ему присылают такой скрин:
Допустим, этот редактор – вы и вам решать, нормально ли сформулирована кнопка. Не читайте дальше, прямо сейчас попробуйте подумать над этой задачей самостоятельно – нужно ли здесь что-то улучшать и как именно вы бы поступили. Что предложили бы? А после мы сверим мысли.
Ну или сразу смотрите моё решение.
Во-первых, кнопка плохая. Она заставляет пользователя думать о получении и никак не связана с текстом на странице, в котором говорится об отправке кода. Отправка и получение – два совершенно разных действия, которые никак нельзя синонимизировать. Это антонимы, которые логичнее развести по разным углам.
И если подумать о производимом действии, то можем ли мы гарантировать пользователю получение кода, если он нажмёт на кнопку «получить код»? А если он ошибётся и введёт чужой номер телефона? А если у нас возникнет какая-то ошибка, из-за которой код не отправится? А если ошибётся мобильный оператор? Да много что может случиться. И вот пользователь нажимает кнопку «получить код», долго ждёт, повторно нажимает «получить код», снова ждёт и ничего не получает. Хотя надпись на кнопке обещала, что пользователь обязательно всё получит.
Человек чувствует себя идиотом, потому что не может получить этот код. Но почему это идиот – он? Виновата система, которой он решил воспользоваться! И вот уже мы страдаем от того, что теряем человека, который мог стать нашим пользователем. Но мы разошлись с ним из-за одной неверно сформулированной кнопки.
Кажется, что вернее назвать кнопку другим действием: «Отправить код».
Так, нажимая её, пользователь будет не получать код, что мгновенно невозможно, а отдавать продукту указание отправить его – как король, царь, начальник или владелец, кому что нравится. Код по нажатию будет формироваться, потом сколько-то идти, пересылаться с одного узла на другой, гулять по интернету туда-сюда. И только после всех неожиданных и неизвестных пользователю поворотов он получит код.
А вообще, кнопка здесь – не единственная беда. Внимательный редактор обязательно заметит, как плох заголовок в сочетании с нелепо повторяющим его текстом. Да и отдельно от всего текст выглядит, мягко говоря, не очень. Сами посмотрите, что получается даже с новой формулировкой кнопки:
«Завершение регистрации» в заголовке и «Для завершения регистрации» в тексте – самая нелепая трата драгоценного места в интерфейсе. От чего-то точно надо отказаться. А ещё стоит попробовать не впихивать в короткий текст по два существительных подряд, тем более отглагольных. Смотрите, насколько лучше и проще может быть кратко сформулированное действие:
Завершение – Завершить
Регистрация – Зарегистрироваться
При произношении «зарегистрироваться» толпа чертей свернула себе челюсти. Ладно, оставим «регистрацию» как есть. А вот «завершить» на смену «завершению» для нас вполне годится – произносится короче и звучит живее. Предложу вообще избавиться от «завершения регистрации» в заголовке, а в тексте – поправить этот момент:
Теперь начало и конец вроде неплохие. Осталось только в конце предложения поправить это кривое «когда получите». Оно ещё и логически смешное. Ясно же, что пока не получу код, я его не смогу ввести. Даже случайно подобрать и ввести его не смогу, потому что не знаю формата.
Два императива, два призыва к действию и буквально указания – не лучшее, что можно помещать рядом в одном предложении. Самые нежные и требовательные пользователи могут убежать из-за такого текста в продукте. Поэтому я постарался избавиться от «отправьте» и «введите», оставил только первое. Так текст остался без указания ввести код, и я подумал: «Что, если заявить о пользе кода? Намекнуть, что дальше он пригодится». Вроде неплохая идея.
