Продакт- и requirements-менеджеры каждый день сталкиваются с разными вариантами поведения системы в своих продуктах. И каждый раз возникает вопрос: что сообщать пользователю? И сообщать ли вообще?
Эта статья о том, как писать тексты в продуктах. В частности, алерты, предупреждения, уведомления, статус-сообщения, названия кнопок, заголовки страниц и т. д.
Сразу проясним, кто должен заниматься написанием текстов. C моей точки зрения, это только продакт- (requirements) менеджер / бизнес-аналитик. Никто другой лучше с этой задачей не справится: дизайнер должен заниматься визуализацией интерфейса, у разработчика нет всей полноты картины, technical writer довольно редко встречается в команде, а у клиента/топ-менеджера и так забот полно.
Разберем 3 составляющих сообщения для пользователя: содержание (контент), формат и стиль.
Лучшее сообщение — никакого сообщения
Придумайте, как не показывать сообщения об ошибках своим пользователям. Измените механику приложения, устраните ошибки, которые юзеры могли бы допустить, дайте пользователю выбрать из нескольких вариантов или наоборот — решите за него.
К примеру:
- чтобы пользователь не смог выбрать невалидные данные (например, дата начала позже, чем дата окончания), сделайте поля взаимозависимыми и не давайте выбрать определенные значения;
- eсли возникают ошибки при одновременном сохранении формы двумя пользователями — сделайте слияние версий или постоянное сохранение изменений через сокеты;
- если по требованиям безопасности пользователя должно вылогинивать после 5 минут неактивности — можно показать окно-предупреждение и сохранять все введенные данные.
Чем меньше текста и уведомлений ваш пользователь увидит — тем меньше он будет напрягаться. А соответственно, увеличится простота применения вашего продукта, пользователь достигнет своих целей быстрее.
Содержание
Максимальная простота
Если все же ошибку/предупреждение/уведомление необходимо показать, постарайтесь сделать так, чтобы смысл должен быть кристально понятен с первого раза. К сожалению, у современных пользователей нет привычки читать сообщение до конца, не говоря уже о том, чтобы два раза его перечитывать. Их ждут дома дети, кот и мигают непрочитанные сообщения в Фейсбуке — так что проще кликнуть «ОК» (или что там у вас) не читая и побежать дальше.
Объясните, что именно произошло
Для начала сообщите пользователю статус (даже если все очень плохо) и почему так произошло. К примеру, ошибка на попытку применить промо-код:
By Amazon
Пользователю остается только догадываться, почему промо-код не применяется. Неправильный код? Истек срок промо? Код не применяется к выбранным товарам? Код уже был использован? На любой из этих вариантов можно вывести свой вариант ошибки. И если вы проектируете систему, постарайтесь сделать так, чтобы пользователю было комфортно.
Вот еще плохой пример ошибки:
- «Printing failed».
А вот как это можно исправить:
- «I couldn’t print your document. Check your printer or connection».
- «Couldn’t print your file. Check your printer or refer to troubleshooting documentation».
- «The file didn’t print. Is your printer turned on?».
А как сообщать очень плохие новости? Точно не так:
Moving Fulcrum
А лучше так:
Tumblr
Скромное, но одновременно развернутое объяснение, что все не работает (а такое может быть с любым сервисом). И убедитесь, что система мониторинга настроена и ответственный инженер получит уведомление, когда нужно.
Сокращайте текст
Good
«Oops! Something went wrong between your printer and me. Please check if your printer is turned on, connected to the network or printing settings».
Better
«Oops! Something went wrong between your printer and me. Better check to see if everything is OK».
Best
«Oops! Looks like your printer isn’t connected properly».
Но не сокращайте слишком сильно
Medium
В самых коротких сообщениях не хватает контекста. Такая серьезная постановка вопроса меня лично пугает.
Расскажите, как исправить ситуацию
Если это возможно, дайте пользователю варианты действий: попробовать другой логин-пароль, обновить страницу через время, залогиниться в другой аккаунт или написать в поддержку. К примеру, если email для восстановления пароля не найден, предложите пользователю попробовать ввести другой email или зарегистрироваться.
Вот не самый лучший пример:
Spirit
Сообщение показывается на странице регистрации. Странно предполагать, что человек уже зарегистрировал аккаунт, а потом решил сделать себе еще один. Гораздо логичнее предложить пользователю залогиниться с этим email’ом.
А вот пример гораздо лучше:
By Microsoft
Самый вероятный вариант — пользователь просто не зарегистрирован или же забыл, к какому email’у привязан. Так как подсказать пользователю адрес почты мы не можем, остается предложить зарегистрировать новый аккаунт.
Убедитесь, что понятен контекст
Повод, по которому пользователю показывается какой-то текст, не всегда очевиден. Более того, всегда предполагайте, что пользователь впервые в приложении, плохо видит и слегка пьян. Соответственно, дайте ему больше информации и опишите, что происходит, как можно более ясно.
Смысл этого pop-up окна совершенно не понятен для неискушенного пользователя. Проблема усугубляется еще и тем, что появляется это окно при неочевидных условиях.
Вот более приятный вариант, когда из текста понятно, о чем предупреждают пользователя:
By Jira
Напишите, что именно требуется от пользователя
Очень часто пользователю вываливаются совсем иррелевантные уведомления, например такие:
Что бедный пользователь сделал не так, остается загадкой. Можно предположить, что ввел email в неправильном формате.
Часто это становится результатом интеграции с API, которое не отдает адекватные коды ошибок. В этом случае попробуйте перенести максимум логики на сторону своего приложения и обработать самые распространенные кейсы самостоятельно.
Вот гораздо более гуманный вариант:
Здесь очевидно, что пользователь пытается залогиниться с email’ом, которого нет в системе, а также введен неверный пароль.
Используйте популярные слова
Используйте как можно более избитые слова и формулировки: Save, Follow, Share и т. д. Это помогает пользователям быстрее сориентироваться и принять решение. Сами слова должны быть как можно короче и проще.
| Вот «Yes» список: | А вот этих слов нужно избегать: |
|
|
«Кради как художник»
Если есть сомнения, как именно сказать пользователям о проблеме, — зайдите в Gmail, Airbnb, Booking, Slack и посмотрите, как написано у них. Очень много блоков функциональности повторяется в большинстве приложений: логин, восстановление пароля, личный кабинет, раздел уведомлений, форма заказа, оплата. Все постоянно подсматривают друг у друга решения, и это нормально :)
Не нужно стесняться, что вы скопировали решение, ведь этим вы делаете жизнь пользователя проще.
Избегайте двузначности
Проверяйте, чтобы ваш текст не могли воспринять в ином смысле, чем вам бы хотелось.
В примере ниже пользователю нужно 2 раза прочитать текст и выбрать нужный вариант:
Намного лучше, если вы повторите слово из заголовка, и action-кнопка будет глаголом:
Разные сообщения для разных событий
Если позволяют требования к безопасности, ответы API и прочие условности, выводите на каждую ошибку отдельный текст. Это позволит пользователю быстрее сориентироваться, а также сильно облегчит жизнь вашим тестировщикам.
Размещение
Ваше уведомление должно быть показано релевантно ошибке, в правильном месте и в правильное время. Если есть возможность предупредить пользователя до совершения какого-то действия, лучше это сделать. К примеру, рядом с кнопкой «Загрузить файл» можно написать требования к файлам, рядом с полем ввода пароля — требования к его сложности и т. д.
By Airbnb
Сделайте сообщение заметным
Если же вы показываете сообщение об ошибке, важно, чтобы оно выделялось и ясно указывало, что нужно исправить.
Вот плохой пример из сайта одной из киевских клиник:
А вот хороший:
Лучший вариант отображения ошибки — inline-валидация, когда текст выводится непосредственно рядом с полем сразу после взаимодействия с этим полем. Вот пример с одного из моих проектов.
Вариант «До» — авторизация, которая была сделана на скорую руку в первый спринт проекта. Сообщение об ошибке даже не попадало на первый экран.
Потом все же руки дошли до оптимизации и получился следующий вариант:
Второй вариант, помимо адекватного текста, также отображает ошибку в релевантном месте, где пользователь ожидает ее увидеть.
К сожалению, по стандартам безопасности клиента, мы можем только идентифицировать ошибку пары логин+пароль, поэтому указать, где именно пользователь ошибся, мы не могли. Регистрация также в системе не предусмотрена.
Стиль написания
Наверное, не стоит напоминать, что на пользователя не нужно «кричать», стиль написания должен быть очень мягким и доброжелательным. Однако до сих пор встречаются нелицеприятные сообщения об ошибке.
Используйте неформальный стиль (если это уместно)
К примеру, можно пошутить:
By Yahoo
Но не стоит использовать юмор в критических ситуациях: когда утеряны данные, заполненная форма или другие дорогие пользователю вещи.
Не вините пользователя
By Tumblr
Если пользователь увидел ошибку или приложение не работает, как ожидалось, в любом случае это на совести создателей. Напишите сообщение так, чтобы юзер вас простил и продолжил пользоваться вашим продуктом.
Вот пример хорошей тональности сообщения:
By Dropbox
Подчеркивайте роль пользователя
Используйте формулировку, которая бы подчеркнула действия пользователя, а не просто произошедшее событие:
This post was liked by you. -> You liked this post.
Password needs to be changed after first login. -> Please change password after your first login.
Это дает человеку чувство сопричастности, уменьшает объем текста и побуждает пользователя сделать нужные действия в приложении.
Проверяйте текст у носителя языка
Каким бы продвинутым не был ваш уровень владения языком, не будет лишним дать прочитать ваши тексты носителю. Этот шаг уберег меня в свое время от многих ошибок :)
Выводы
Изначально при планировании UX и механики работы приложения важно предупредить показ ошибок пользователю. Помните, что у него очень много отвлекающих факторов, а на пятки нам наступают конкуренты. Чем проще юзеру будет работать с продуктом, тем выше вероятность того, что мы на нем заработаем.
Помните о содержании текста, форме подачи и размещении. Текст уведомления должен быть простым, кратким и четко описывать, что следует делать дальше. Не забывайте показать его в правильном месте и в правильное время, а также уважительно обратиться к пользователю.
Вот несколько полезных ресурсов для тех, кто серьезно хочет погрузиться в тему:
- Apple Human Interface Guidelines (PDF)
- Modern Apple design guidelines for iOS
- Material design guidelines