Перевод публикации Рианнон Джонс на Медиуме:
Эта история о том, как я стала ботаном в написании текстов ошибок.
Когда я пришла в команду Deliveroo в прошлом году, сообщения об ошибках были некоей унаследованной данностью быстрорастущего продукта. Им никогда не уделялось достаточно внимания и их часто писали разные люди — от инженеров-разработчиков до продуктовых дизайнеров. Иногда ошибки даже путали пользователей.
Так получалось в основном потому, что пользовательские сценарии совершенствовались, а тексты ошибок просто копировались из более старых версий продукта в новые. Часто в тексте не соблюдался нужный тон — ошибки были слишком фамильярными, когда надо было быть чуткими и внимательными к пользователю. Или, наоборот, когда можно было чуть расслабиться, от текстов веяло холодом.
И это совсем не редкий случай. Честно говоря, подобное отношение к текстам ошибок я не раз замечала и в других продуктах.
Однако сообщения об ошибках нужны хорошие. Они как орехи, болты, клейкая лента в контент-дизайне. Когда их нет или они не выполняют свои функции, всё остальное, что вы сделаете, становится неважным.
Поэтому мы взялись за них в первую очередь — решили вытащить комки пыли из таких углов, в которые никто не заглядывал со времён начала работы над продуктом. Нашей целью стало построить новое, понятное пользователям пространство, которое бы их не раздражало. Ну и, конечно, мы должны были удостовериться в том, что каждое наше падение было бы грациозным.
В итоге мы переписали каждое сообщение об ошибке в нашем проекте. И вот как мы это сделали.
Разделили ошибки на типы
Нужный тон сообщений об ошибках зависит от чувств, которые в момент их получения испытывает читатель. То есть, от обстоятельств, при которых их вынужден читать пользователь. В первую очередь надо учитывать, сколько времени человек провёл в интерфейсе — только ли сейчас он открыл приложение или он уже давно пытается что-то заказать. Может ли пользователь сам справиться с проблемой? Как проблема влияет на пользовательский опыт?
Взявшись за работу, мы разделили ошибки на два основных типа:
Системные — это такие ошибки, на которые пользователи не могут влиять, они возникают не из-за действий пользователя. Перебои в работе системы, внезапно закончившийся товар, отказы в формировании заказов.
Пользовательские — такие ошибки, которые возникают, когда пользователь пытается идти по сценарию, который мы не продумали или который не может быть завершён. Также это ошибки, возникающие, когда пользователь явно делает что-то не то. Например, ошибается в формате номера телефона или банковской карты, вводит неподходящий адрес доставки, ну или когда у него пропадает связь.
После этого мы ввели для каждого типа ошибок ещё по два подтипа:
Частичные — эти ошибки влияют только на часть функциональности системы и не останавливают пользователей на их пути к успеху. Допустим, пользователь хочет заказать еду из любимого ресторана, но ресторан оказывается закрыт. Конечно, обидно, но прямо сейчас всё ещё можно заказать еду в другом месте.
Тотальные — вот тут беда. При возникновении таких ошибок пользователи не могут заказать еду нигде. Говоря языком системы, это 500-е ошибки.
Мы пересмотрели все наши ошибки с помощью инженеров, сделали скриншоты, описали контекст — что происходило до возникновения ошибок и как пользователь может их решить — отнесли все ошибки к системным, пользовательским, разбили их на частичные и тотальные.
Так мы проделали примерно 80% работы, которую нужно было сделать.
А после оценили воздействие
Проще всего понять, что происходит с ошибками в интерфейсе — поместить их все на некую плоскость. Вот как на графике ниже, где одна ось определяет их как системные или пользовательские, частичные или тотальные, а другая — насколько сильно каждая ошибка влияет на пользовательский опыт. Мы остановились на трёх уровнях влиятельности — раздражающие ошибки, бесящие и напрочь ужасные.
Определить тон
Как только у нас появилась карта ошибок, мы поняли, как можно их сгруппировать. И для каждой группы ошибок мы определили верный тон. Вот как мы решили действовать:
Раздражающие ошибки — мягко объяснить, что происходит
Нужно объяснить проблему и заверить пользователя, что ничего страшного не происходит. Можно немного пошутить, если для продукта это норм. Но не стоит шутить, если это уведомление может появляться часто. Чем человечнее вы напишете это сообщение, тем лучше.
Бесящие ошибки — объясните и расскажите, как решить
Буквально разжуйте проблему. И дайте пользователю понятную инструкцию по тому, как её устранить, а заодно можно рассказать о том, что будет дальше.
Ужасные ошибки — извинитесь и дайте хоть какое-то решение
Когда нужно, стоит извиниться перед пользователем. А понимание проблемы и объяснение пользователю делает извинение лучше. Дайте людям понять, что вы уже решаете то, с чем им пришлось столкнуться. Заодно можно сказать, что пользователь может сделать прямо сейчас.
Получившийся у нас фреймворк упрощает работу. Согласования и вообще весь процесс стали быстрее. Финальные решения выходят более качественными и мы больше не тратим на них столько времени, как раньше.
Если понравилась публикация, подписывайтесь на мой канал здесь и в Телеграме. Я рассказываю о том, как писать, немного говорю про интерфейсы и логику нормального человека.
