Как сделать хорошие тексты в интерфейсе service desk? Советы UX-дизайнера

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

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

Чтобы продукт был по-настоящему полезным и удобным, важно продумать, какой UX-текст будет содержать каждый экран и придерживаться при этом определенных правил. 

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

Что такое UX-тексты и на какие метрики они влияют

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

Любая надпись в определенном месте экрана — не просто буквы, а возможность повлиять на важные для бизнеса метрики.

• Конверсия — доля пользователей, которые совершили нужное действие. 

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

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

• Удержание (Retention Rate) — доля пользователей, вернувшихся в приложение через определенное время. 

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

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

• Готовность рекомендовать продукт (Net Promoter Score) — уровень лояльности пользователей. 

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

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

• Количество обращений в поддержку 

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

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

4 вида UX-текстов: заголовки, кнопки, пуши, пустые состояния

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

• Заголовки и подзаголовки

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

Заголовок — обычно самый крупный текстовый элемент, основной предмет внимания. Он быстро доносит основную идею — над чем работают на странице или в разделе. Заголовок должен быть кратким, в 1-3 слова, и представлять собой название процесса или объекта.

Подзаголовок — дополняет и раскрывает содержание заголовка. Если содержимое окна достаточно объемное, несколько подзаголовков помогут разбить его на логические части и облегчить восприятие. 

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

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

• Кнопки

Кнопка — это предложение или требование совершить определенное действие. От того, как вы ее назовете, зависит, поймет ли пользователь, что произойдет после клика. 

Текст на кнопке чаще всего указывается в форме инфинитива и должен быть логически связан с заголовком контента, к которому он относится. Например, форма создания заявки  → кнопка «Создать». 

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

Кнопки-табы выглядят как существительные или прилагательные в значении существительных — «Договоры», «Услуги», «Заявки», «Уведомления», «Входящие». Не стоит называть табы глаголами, так как по сути это заголовки для папок с содержимым, которые ориентируют пользователя, а не побуждают его к действию.

Кнопки модальных окон, или поп-апов, часто называют «ОК» или «Отмена». Это не ошибка, но пользователю может быть непонятно, что именно произойдет после нажатия на кнопку. Лучше указывать конкретные действия — «Отменить», «Сохранить», «Отправить». Так получится устранить сомнения, какое действие выполнит система.

Кнопки-одобрения, которые закрывают онбординги и экраны успеха, обычно выглядят как «Хорошо», «ОК», «Понятно», «Отлично» или «Спасибо». Мы рекомендуем избегать фраз вроде «Уже бегу» или «Будет сделано», чтобы не вынуждать соглашаться с подобной позицией по отношению к продукту — это может вызвать негативные эмоции.

• Сервисные оповещения и push-уведомления

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

Пуш обычно состоит из заголовка, подзаголовка (основного текста), изображения и URL. Мобильные пуши могут состоять только из заголовка и подзаголовка. Главное правило — не дублировать информацию в этих двух элементах.

Заголовок — в нем размещайте призыв или самую важную информацию, оптимальный объем — до 25 знаков с пробелами. Начало заголовка должно содержать основное действие: «Решена заявка 35600», «Добавлен комментарий к заявке 35600», «Опубликована новость». Важно использовать позитивные формулировки и по возможности избегать частицы «не», так информация лучше воспринимается.

Подзаголовок — в нераскрытом пуше вмещает до 2 строк. В каждой — максимум по 25 знаков с пробелами. Если уложиться в это количество, пуш не придется раскрывать, что снижает усилия пользователя. Максимальная длина — 150 символов, но такого размера лучше не допускать.

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

• Пустые состояния

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

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

1. Определите контекст — контент пока не появился, уже удален, не найден по запросу или временно недоступен.
2. В заголовке расскажите, что произошло и почему пользователь видит этот экран.
3. В подзаголовке опишите, что делать дальше или можно успокоить, что данные не пропали.
4. Если применимо, в надписи на кнопке направьте к целевому действию — «Обновить», «Создать», «Отправить».
5. Подберите подходящее изображение, которое разбавит контекст и поможет быстрее считать текст.

Например, новым пользователям, которые не успели накопить данные, можно рассказать о пользе заполнения системы: «Добавьте первых сотрудников. Выберите, в каких командах они будут участвовать» или «Добавьте объекты в избранное. Так будет проще находить важные объекты».

Как проверять интерфейсные тексты: 6 советов

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

1. Контекст и эмоции. Оцените, в каком состоянии находится пользователь и насколько критична ситуация. Например, легкая шутка уместна только в нейтральных сценариях вроде пустых состояний.
2. Универсальность. Проверьте, работает ли формулировка для всех сценариев и кейсов, которые привели пользователя к тексту. Нужно учитывать все возможные ограничения и особенности системы.
3. Понятность. Убедитесь, что из текста сразу ясно, что произошло и какие действия доступны пользователю дальше. Если приходится перечитывать сообщение дважды — нужна переформулировка.
4. Тональность. Проверьте, соответствует ли текст вашему tone of voice — спокойный, дружелюбный или неформальный стиль должен быть единым во всем интерфейсе системы.
5. Логическая связь между элементами. Заголовок выражает основную мысль, подзаголовок дает контекст и объясняет ситуацию, а кнопка ведет к конкретному действию — все три элемента должны дополнять друг друга.
6. Грамотность. Вычитайте текст несколько раз перед публикацией — в коротком UX-тексте ошибка сразу  бросится в глаза и снизит доверие к интерфейсу.

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

Чтобы разобраться, как настроить систему и ее интерфейс в вашем конкретном случае, обратитесь в наш клиентский сервис — cs@itsm365.com

Если вы еще не являетесь пользователем нашей системы, заполните форму заявки на бесплатное тестирование, чтобы получить доступ к демостенду на 14 дней.