Как писать сообщения об ошибках

Как писать сообщения об ошибках

Есть простой шаблон:
В заголовок — что призошло
Основным текстом — причина и что делать дальше
Кнопкой — действия
Код ошибки, если необходим

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

Если пользователь отправлял письмо, а оно не отправилось, то так и пишем: Письмо не отправлено

Хорошо:
✅ Не удалось загрузить сообщения
✅ Фотографии не отправлены
✅ Платёж не прошел

Плохо:
❌ Что-то пошло не так
❌ Ошибка!
❌ Память не может быть read

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

✅Хорошо для простого человека:
Не удалось сохранить документ. Документ слишком большой. Уменьшите размер документа до 800 символов или разбейте на части.
Разбить на 3 части
Закрыть

✅Хорошо для профессионала.
Не удалось сохранить документ. Размера файла подкачки не хватает для сохранения. Увеличьте размер файла подкачки до 1 ГБ или уменьшите размер вашего документа до 800 символов.
Увеличить файл подкачки
Разбить на 3 части
Закрыть

❌ Плохо:
Не писать причину
Писать профессиональным языком для непрофессионалов

Если причина неизвестна, то можно так и писать: Ошибка произошла по неизвестной причине. Помогите нам разобраться, отправьте отчёт.

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

✅Хорошо
Вы ввели неверный пароль слишком часто. Чтобы восстановить пароль, обратитесь в службу поддержки.
Позвонить в службу поддержки
Написать в службу поддержки
Закрыть

❌Плохо:
Вы ввели неверный пароль слишком часто. Чтобы восстановить пароль, обратитесь в службу поддержки.
Закрыть

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

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

Смена лого Google Maps

Смена лого Google Maps

Карты гугла обновили логотип и я, как преданный пользователь сервиса, ощутил на себе всю "прелесть" этого мероприятия. Под постом будет картинка До обновления и После.

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

Вот мой пользовательский опыт: я, как человек, который часто пользуется google maps, уже раза три ловил себя на том, что не могу найти приложение. Хотя оно находится на том же месте, где и всегда.

Мне приходилось вчитываться в подписи иконок, чтобы найти карты. То есть, вместо того, чтобы считать знакомый образ, я отваливаюсь на том, что не могу его найти.

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

UX-редактор как пчёлка

UX-редактор как пчёлка

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

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

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

Краткосрочная близорукость

Краткосрочная близорукость

Я думаю, что все мы рано или поздно оказываемся в ситуации, когда погрузившись в проблему и предлагая просто отличное решение, мы слышим: «Отлично! Но вот пока, как-то сложно это все реализовать... Может мы сможем что-то с этим сделать? А то долго просидим, а метрики упадут»

И что мы делаем в такой ситуации? Либо идём на поводу, изобретая компромисс. Либо режем все до MVP, а остальное уезжает в светлые будущие релизы. Но давайте откровенно, из этих светлых будущих релизов ещё ничего не возвращалось.

Автор следующей статьи называет этот феномен «краткосрочной близорукостью». И что при ней происходит с долгосрочными целями? Они просто уходят из вида.

И как бороться с подобной одержимостью краткосрочного скачка показателей на дашборде? Просто:

1) Задайтесь вопросом, а стоит ли вообще заниматься этой задачей? Я не шучу. Если задача вообще не соотносится с долгосрочной стратегией, то она попросту не стоит затрачиваемых усилий.

2) Что произойдёт, когда задача будет сделана? Что-то хорошее или всем будет все равно? Я как-то месяц работал над задачей, чтобы через полгода обнаружить, что после релиза функциональность физически не работает... И всем пофиг. Значит идея явно не стоила пота.

3) Держите в голове конечный результат и задайтесь вопросом: что я прямо сейчас могу сделать, чтобы все остальное стало проще или совсем ненужно?

4) Почитайте статью: https://uxdesign.cc/tackling-chronic-short-termism-f9058f04f8db там много интересного :)

Юрий Ветров #2 - о дайджесте, конкурсе и продуктовом дизайне.

Директор по дизайну в Mail.Ru Group (продукты под брендом “Mail.Ru”).
jvetrau.com

— Ты ведешь одну из самых популярных групп в фейсбуке про продуктовый дизайн. С какой целью?

Я в любом случае читаю уйму статей, чтобы оставаться в теме и находить новые направления для развития дизайна в Mail.Ru. Это очень здорово ускоряет изменения (и помогает писать талмуды про UX-cтратегию (uxstrategy.co)). Почему бы не поделиться этим с сообществом? :) Я трачу на это не сильно больше времени относительно чтения, зато лучше структурирую собственные мысли.

— Как происходит процесс сбора материалов для дайджеста? Сколько времени у тебя на это уходит?

У меня про это есть отдельная презентация (slideshare.net/jvetrau/wud2014-yvetrov-background-research) :) Где-то полчаса-час в день уходит на чтение. У меня тонна подписок в Feedly, это основной источник — читаю от корки до корки (блоги дизайн-команд и конкретных дизайнеров, специализированные журналы, пара других дайджестов). Есть издания, которые читаю отдельно (Engadget, периодически Fast Co Design), оттуда тоже иногда приходит. После этого сохраняю лучшее в Pinboard (pinboard.in/u:jvetrau), оттуда постепенно публикую в соц.сети, а в конце месяца собираю дайджест в разных форматах (часа 3 в месяц, причём по возможности просто обновляю черновик статьи по ходу каждого поста в соц.сети, так что к концу периода остаётся только вставить картинки).

— Какие темы продуктового дизайна сейчас наиболее актуальны?

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

— Вы уже пять лет проводите Russian Design Cup. Почему в этом году так мало участников, по сравнению с предыдущим?

Скорее, количество вернулось к позапрошлому году после взрыва в прошлом :) Мы, конечно, рассчитывали на рост относительно прошлого года, а не возврат назад, но есть две гипотезы — слишком сложная задача на отборочном оттолкнула часть людей (хотели хайпануть по ICO, а в итоге перемудрили), плюс сменилась команда пиар-поддержки (прошлые совершили чудо с трёхкратным ростом). К следующему разу серьёзно поменяем формат, чтобы стало интереснее для участников и проще для нас.

— Вы приглашали к себе на работу участников с хорошими кейсами?

Да, регулярно берём кого-то из лидеров рейтинга. RDC показывает, что дизайнер может решать разные задачи в ограниченное время, что его или её успешные решения — не случайность.

— Бургеры и пиво или вино и стейк?

Оба хороши, но первое чаще и более компанейское :)

— Что произойдет с интерфейсами за следующие 5 лет?

Если говорить про формат работы над продуктами, то можно будет делать гораздо больше меньшими средствами. Это видно по развитию веба и мобильных — если раньше простейшие вещи делались полностью руками и через боль, то сейчас всё собирается из готовых компонентов и можно фокусироваться на продуктовых задачах. Дальше будет ещё лучше — алгоритмический дизайн (algorithms.design) уберёт кучу рутины, более добротная проработка по куче аспектов станет ещё дешевле и быстрее.

Второй момент — это платформы и связанные с ними парадигмы взаимодействия с интерфейсом. Ключевыми вехами были персональные компьютеры и смартфоны, они были действительно массовыми и изменившими рынок. Все, конечно же, ждут следующей такой платформы (тем более, что смартфоны постепенно замедляют рост), но пока безуспешно. Если какая-то из новых платформ всё-таки выстрелит — увидим очередной рывок в профессии :)

Ура! Переходим к поиску решения!

На этом долгий процесс описания нашего исследования закончен, самое время перейти к описанию решения, к которому мы пришли.
Но сначала пару слов о проведенном исследовании.

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

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

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

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

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

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

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