Розбий моноліт! Kuberton — конференція для DevOps-ів & Python, Java, Ruby, GO розробників. 2-3 March, 2019
×Закрыть

Общаемся с пользователем через приложение. Гайд по написанию уведомлений

Продакт- и 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’у привязан. Так как подсказать пользователю адрес почты мы не можем, остается предложить зарегистрировать новый аккаунт.

Убедитесь, что понятен контекст

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

Medium

Смысл этого pop-up окна совершенно не понятен для неискушенного пользователя. Проблема усугубляется еще и тем, что появляется это окно при неочевидных условиях.

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

By Jira

Напишите, что именно требуется от пользователя

Очень часто пользователю вываливаются совсем иррелевантные уведомления, например такие:

UX Planet

Что бедный пользователь сделал не так, остается загадкой. Можно предположить, что ввел email в неправильном формате.

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

Вот гораздо более гуманный вариант:

UX Planet

Здесь очевидно, что пользователь пытается залогиниться с email’ом, которого нет в системе, а также введен неверный пароль.

Используйте популярные слова

Используйте как можно более избитые слова и формулировки: Save, Follow, Share и т. д. Это помогает пользователям быстрее сориентироваться и принять решение. Сами слова должны быть как можно короче и проще.

Вот «Yes» список:А вот этих слов нужно избегать:
  • Save
  • Follow
  • Cancel
  • Sign up
  • Share
  • Not now
  • Search
  • OK
  • Start
  • Supply
  • Invalid
  • Retry
  • Warning

«Кради как художник»

Если есть сомнения, как именно сказать пользователям о проблеме, — зайдите в Gmail, Airbnb, Booking, Slack и посмотрите, как написано у них. Очень много блоков функциональности повторяется в большинстве приложений: логин, восстановление пароля, личный кабинет, раздел уведомлений, форма заказа, оплата. Все постоянно подсматривают друг у друга решения, и это нормально :)

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

Избегайте двузначности

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

В примере ниже пользователю нужно 2 раза прочитать текст и выбрать нужный вариант:

Google Material design guide

Намного лучше, если вы повторите слово из заголовка, и action-кнопка будет глаголом:

Google Material design guide

Разные сообщения для разных событий

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

Freshsparks

Размещение

Ваше уведомление должно быть показано релевантно ошибке, в правильном месте и в правильное время. Если есть возможность предупредить пользователя до совершения какого-то действия, лучше это сделать. К примеру, рядом с кнопкой «Загрузить файл» можно написать требования к файлам, рядом с полем ввода пароля — требования к его сложности и т. д.

By Airbnb

Сделайте сообщение заметным

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

Вот плохой пример из сайта одной из киевских клиник:

А вот хороший:

UXmas

Лучший вариант отображения ошибки — 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 и механики работы приложения важно предупредить показ ошибок пользователю. Помните, что у него очень много отвлекающих факторов, а на пятки нам наступают конкуренты. Чем проще юзеру будет работать с продуктом, тем выше вероятность того, что мы на нем заработаем.

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

Вот несколько полезных ресурсов для тех, кто серьезно хочет погрузиться в тему:

LinkedIn

56 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Мабуть, неможливо написати статтю на таку тему, щоб всі одностайно погодилися з усіма тезами. Все одно UI — це в якійсь мірі про смаки. Комусь подобається такий термін, а комусь інший. Хтось радше прочитає довший мессидж, але з усіма деталями, а хтось все може зрозуміти з двох слів і довгий мессидж буде дратувати. Тому тут завжди треба балансувати і шукати оптимальний варіант, який навряд чи буде ідеальним для всіх.
Мені стаття сподобалася і була корисною для мене, дякую:)

Рада что понравилось :)

чтобы пользователь не смог выбрать невалидные данные (например, дата начала позже, чем дата окончания), сделайте поля взаимозависимыми и не давайте выбрать определенные значения;

Спочатку б розстріляв таких горе-дизайнерів з базуки, потім зібрав до купи шматки та вже їх згвалтував, а потім ще раз розстріляв з базуки.
Це найгірша порада з усіх можливих — обмежувати введення даних. Користувач мусить просто вводити дані, а ваша задача вгадати, що малося на увазі. А от якщо вгадати не вдалося, тоді вже давати сповіщення або намагатися виправити самостійно (якщо це можливо) Оце — кращий інтерфейс.

eсли возникают ошибки при одновременном сохранении формы двумя пользователями — сделайте слияние версий

Залежить від даних. Фінансові дані краще так не мержити.

А вот этих слов нужно избегать: OK, Start, Supply, Invalid, Retry, Warning

Треба краще уникати радників, які радять такі речі.

Discard draft?

Тут посміявся. Варіант із Cancel/Discard ще гірший, ніж Yes/No. Проблема в запитанні, а не у варіантах дій.

Користувач мусить просто вводити дані, а ваша задача вгадати, що малося на увазі.

І що мається на увазі, коли людина вводить 2030 як рік свого народження?

Людина помилилася. Але якщо вона напише 85, то можна очікувати, що це 1985?

Я думаю, що ваші підходи не суперечать один одному. Можна і 85 переформувати в 1985, і можно 2030 заборонити:)

Заплановану дату народження онуків. :)
Або, що людина прибула з майбутнього.
Або, що зараз на сайті — тестер. :)

вибачаюся, я відредагувала свій коментар, бо спочатку неправильно зроміла коментар про 85..)

Проблема в забороні. Це нереально поганий шлях. Якщо заборонено, але дуже сильно хочеться, то можна. Саме так зроблять користувачі, коли їм щось заборонити робити. Ви отримаєте невалідні дані, а потім будете з ними мучатися, щоб дізнатися, що саме малося на увазі. Так можна одразу будувати таку систему, болі буде набагато менше.

Для мене це не прояв заборони, а прояв допомоги. Але як я написала вище автору, це все про вподобання і мабуть універсального рецепту немає...

Ви хоч раз попадали на глючну форму введення номеру телефону? Ладно, я промовчу про те, що код України 380, а не 38, але редагування через обов’язкове видалення, при чому тільки через бекспейс, оце реально бісить. Тому дякую, допомога через обмеження не потрібна.

з приводу дат й сам хотів написати — якщо мені треба поміняти період на більш ранній і я спочатку захочу змінити кінцеву дату так, що вона буде в цей момент менше початкової, я не хочу щоб мені не давали цього робити й примушували міняти тільки по порядку. це нереально не юзерфрендлі, і коли не дає вибрати дату в голові одразу: «бл# ну шо не так!»

Это всего лишь best ractice. Да, и ограничивать пользователя как раз таки нужно.. Но делать это нужно таким образом, чтобы он не заподозрил своей ошибки, автор как раз донес такую идею.
Существует множество техник, которые способны направить любого пользователя по течению. Это и встроенные возможности HTML5 и Маски и regexp.
Автор правильно заметил еще в самом начале:

Лучшее сообщение — никакого сообщения
Да, и ограничивать пользователя как раз таки нужно..

Навіщо? Що ви хочете оцими обмеженнями досягти? Надресерувати користувачів?
Давайте вам приведу приклад, який чітко показує наслідки вашого «дресування». В одній державній системі стояла система, яку писали «програмісти». В них була своя власна думка з приводу того, як мусить працювати форма введення адрес. Але халепа в тому, що в країні існують люди, які з якихось причин цієї адреси й не мають. За законом вона мусить бути, а в реальності — зась. Тут оператори системи спочатку попали в скрутне становище, а потім феєрично з нього вийшли. В базі з’явилися вулиці «Невідома», «Не встановлена», «-» тощо, яких, як ви вже могли здогадатися, не існує в реальності. Ви розумієте наслідки такого рішення? В базі тепер не можна відрізнити більш-менш реальні адреси від вигаданих. Тобто ми маємо повну базу сміття. А це сталося тому, що анкету було неможливо заповнити без обов’язкового заповнення адреси. Потім помилку виправили, але легше від цього не стало нікому.

Существует множество техник, которые способны направить любого пользователя по течению. Это и встроенные возможности HTML5 и Маски и regexp.

Ага, краще б їх скоріше забули. Щоб більше не знущатися над користувачами.

В базі з’явилися вулиці «Невідома», «Не встановлена», «-» тощо, яких, як ви вже могли здогадатися, не існує в реальності

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

Лучшее решение в этой ситуации — скрыть поле ввода с адресом по умолчанию и открывать при определенном условии, например с вопросом желает ли пользователь указать адрес? Если да — то показываем поле ввода...
Тем самым — мы получаем более чувствительный контроль над пользовательскими данными и ведем сами его в нужное направление.

Еще лучший способ в этой ситуации (если проект настолько серьезный) то можно использовать предустановленный список подгружаемых адресов, тем самым сузив возможности пользователя и заставив его выполнить то что от него требуется ЕСЛИ он захочет... Программа полностью контролирует его поведение и никаких ошибок не возникнет. Как такой вариант ?

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

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

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

Так, ви не застраховані від цього ніяк, хоч з базою адрес, хоч без. Тому що в Україні а) не існує єдиної бази адрес; б) зміна назви відбувається на місцевому рівні.
Але є одне але. Ви можете вже точно знати, що людина пише це свідомо та давати їй по шапці. А не пише вимушено, тому що система диктує правила. Тобто рівень сміття в базі буде різнитися.

В случае с двумя датами или классическая валидация (красненькое сообщение если вторая дата раньше первой), или использовать UI-компонент range picker, который явно дает понять что нужно вбырать дву даты и эти даты образуют период (например). А вот если это будет два отдельных календарика — то ограничивать молча нельзя совершенно. Потому что выбрал пользователь одну дату из пары, жмёт для выбора другой, а там часть дат не кликается и почему — совершенно непонятно. Взаимозависимые поля это вообще плохо — их не всегда просто закодить и иногда их работа неявна для пользователя.

Хороший материал. Только пара моментов.

А вот этих слов нужно избегать

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

Лучший вариант отображения ошибки — (...) когда текст выводится непосредственно рядом с полем сразу после взаимодействия с этим полем.

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

Invalid — слишком общее слово, которое к тому же часто используют в текстах, написанных не-юзер-френдли языком. К примеру, SQL запрос вполне может быть «invalid». А вот если юзер вводит телефонный, а ему в ответ — invalid number. Как мне кажется, некоррекно такое юзеру писать. Вот как Гугл отвечает в этом случае: «This phone number format is not recognized. Please check the country and number.»

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

Навязчивая мгновенная валидация чаще раздражает чем выполняет свою функцию информирования об очевидном

Мне нравится такой вариант: если ошибок валидации нет, валидируем по нажатию на сабмит. При самом вводе ничего не трогаем. А вот если уже есть ошибки валидации (человек нажал сабмит и вылезла ошибка), то делаем валидацию при вводе (чтобы ошибка исчезла когда ввел правильно).

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

Просто есть техническая проблема событий, по которым валидировать. Например, если взять валидацию при потере полем ввода фокуса. Пользователь поставил курсор в поле, а потом вдруг убрал и решил начать заполнение с другого. И сразу срабатывает валидация. Тоже вроде плохо. По input/keyup — будет срабатывать как только начал вбивать имейл. В обоих случаях я ещё ничего не собирался сделать, а меня уже поругали и поле красненьким выделили. Разве что input/keyup с задержкой (debounce) в полсекунды, тогда не будет срабатывать во время печати. Если пользователь печатает быстро 😐

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

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

Если есть сомнения, как именно сказать пользователям о проблеме, — зайдите в Gmail, Airbnb, Booking, Slack и посмотрите, как написано у них

Хотя гугл как раз валидирует обязательные поля при потере фокуса лол.

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

Є. Чим більше користувач грається із підбиранням собі вільного імені, тим менше шансів на те, що будуть заповнені інші поля, або вони будуть заповнені максимально детально та з більшою концентрацією. Зазвичай, після декількох невдалих спроб, бажання продовжувати брутфорсити систему стрімко зникає. Тому не відволікайте зайвий раз користувача валідаціями, сповіщеннями, помилками.

Чим більше користувач грається із підбиранням собі вільного імені, тим менше шансів на те, що будуть заповнені інші поля

Боюсь, что такие утверждения необходимо чем-то подкреплять, иначе не вижу смысла спорить. Например: статистика уходов со страницы, результаты юзер ресерча, А/В тестирование.

Якщо ви не можете на собі це перевірити, то розмовляти дійсно немає про що... Такі в нас UX дизайнери, як тільки щось виходить за рамки книжки або чужої статті, все, ступор, давай докази.

Ви реєстрували хоч раз доменне ім’я? Йдіть пограйтеся на сайт будь-якого реєстратора. А ще можете подивитися відео, яке пояснить вам просту річ: мозок лінивий та не бажає займатися дурнею. Як тільки ви зробите декілька невдалих спроб, оптимізаційні алгоритми вашого міжвушного ганглію одразу вам почнуть подавати сигнали, що далі щось робити немає сенсу, що ваша гра «вгадай вільну назву» — тупе прожигання ресурсів із низькими шансами на успіх. Тому Гугл пропонував вільні назви, щоб користувачеві можна було зіграти в іншу гру: «Бажаного не досягти, обирай поки дають з того, що є». Чим швидше ви вирішуєте «проблему», тим більше шансів на успіх. Написано в будь-якій книжці або статті по UX. Тут навіть без A/B тестування все зрозуміло.

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

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

Александр, во-первых остыньте.

До якої температури я мушу охолонути?

Вопрос «хотите ли вы знать об ошибке сразу или через минуту?» тривиален, а ответ очевиден.

В цьому й проблема. Відповідь не очевидна. Є як мінімум два типи людей, які поводяться із формами по-різному. Перші сумлінно вводять всі дані послідовно, хочуть одразу бути впевненими, що вони все ввели правильно, щоб потім не повертатися до заповненого ще раз. Інша група — люди, які заповнюють все як вийде, а потім виправляють вже як треба потім. Так ось, оператор якогось кол-центру буде попадати в другу категорію, а не в першу. Його інтерфейс мусить не задовбувати зайвими перевірками та уточненнями, валідаціями, сповіщеннями, а надавати можливість записати якомога більше даних під час дзвінку. Запитання все ще тривіальне?

Гипотеза же о том, будто юзер расстроится и уйдет обиженный, увы, не так очевидна и требует проверки.

Я вам вже казав, перевірте на собі. Йдіть та підберіть якесь нормальне доменне ім’я в зоні .com.

Є. Чим більше користувач грається із підбиранням собі вільного імені, тим менше шансів на те, що будуть заповнені інші поля, або вони будуть заповнені максимально детально та з більшою концентрацією.

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

Если пользователю очень нужно зарегистрироваться именно тут — то он приложит какие-то усилия.

Завжди існує прошарок людей, які пройдуть процедуру з початку до кінця. В UX це гра на збільшення успішності рішення, щоб максимізувати цей прошарок користувачів.

Хотя я в последнее время склоняюсь к мысли что все сайты должны в первую очередь предлагать логин при помощи гугла и фб

Є нюанси, але в цілому повністю підтримую!

В принципе, большинство советов разумны и полезны, но не это:

чтобы пользователь не смог выбрать невалидные данные (например, дата начала позже, чем дата окончания), сделайте поля взаимозависимыми и не давайте выбрать определенные значения;

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

Сокращайте текст

> «Oops! Looks like your printer isn’t connected properly».

А вот это уже пересол — и классический вариант leaky abstraction. Принтер может быть идеально подключен, но не включен — несмотря на наличие какой-нибудь лампочки «я в дежурном режиме», или же он принудительно в режиме ксерокса... даже тут можно запутать, а тем более в чуть более хитром случае.

Далее, если пользователь вводит email, называть ему сразу акаунт, который на него зарегистрирован — потенциальная дыра, а ещё и утечка персональных данных. Так делать нельзя. Можно дать кнопку «нажмите для получения на этот email напоминания про акаунт».

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

И это правильно, жалеть не о чем.

Принтер может быть идеально подключен, но...

«Looks like» уже каже про те, що достовірно невідомо, що саме не так. Просто відомо, що це пов’язано з принтером. Як на мене, то текст вдалий.

Тогда можно сократить до «Printer error. Please check.».

можна і так:) Трохи інша інтонація, але також гарний варіант, як на мене:)

В общем случае на форме логина нельзя показывать разные сообщения для «Invalid login» и «Invalid password». Потому что это упрощает подбор.

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

Очень многие более «правильные» по мнению автора решения стоят нехилой нагрузки на сервер.
Одно дело проверить есть ли код в списке активных, другое — проверить истек ли он.
Кроме того, те же коды часто воруют или получают на фрод сайтах, зачем подсказывать конкретную причину почему код не работает? Амазон имеет все что нужно чтобы проводить тысячи AB тестов и уверен что не просто так пришли к текущему решению. Более человеческие и подробные описания также противоречат заявлению авторам о том что юзерам лень читать.

У каждого решения есть история и техническая аргументация/оправдание

This post was liked by you. -> You liked this post.

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

Короче неплохо пробежались по формам популярных сервисов, но почти каждое заявление спорное и ничем не аргументировано. В идеале хотелось бы увидеть цифры изменения конверсии или вовлеченности после предложенных изменений в UX. А то понятие о «common sense» уж очень разное у каждого из нас.

Одно дело проверить есть ли код в списке активных, другое — проверить истек ли он.

Угу. Это уже несколько проверок:
1. Есть ли у нас такой код?
2. Активен ли он?
3. Не истек ли он?

Изменение предложенное автором полностью ломает логику данного меседжа.

Почему? Все в порядке с меседжем A, B, C liked this post.

Ну списки ставить в начале это аще аллес! Надо его весь прочесть чтобы дочитать до сути список чего это есть

A, B, C and 42 others kind of disagree :) Хотя в целом соглашусь, списки, длинные имена и прочие факты объективной реальности лишь усложняют задачу, и первый вариант безопаснее.

Очень многие более «правильные» по мнению автора решения стоят нехилой нагрузки на сервер.

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

Просто почему-то среди программистов распространено мнение, что важна только бизнес-логика, а логика отображения «и так сойдёт». А на самом деле поставьте себя на место пользователя — он не видит прекрасный оптимизированный код API. Он видит фронт. И если текст ошибки непонятен, то для пользователя такое приложение уже не идеально.

Если говорить о том, как должно быть в идеале с точки зрения пользователя — то всё в статье правильно. Просто в работе бывают ньюансы (например нельзя с точки зрения безопасности говорить правилен ли логин и тем более выдавать какие-то данные по имейлу или просто некогда вылизывать сообщения аж до «у вас тут собачки в имейле нет») из-за которых идеал недостижим

Вопрос «правильности» не стоит. Почти любую точку зрения можно аргументировать. Но, автор этого не делает, а просто говорит лучше это чем то. Про «собачку в мейле» это тупо подсказка тем кто делает акк с левыми данными. Если человеку сказать что имейл неверен он его прочтет и поправит. Излишества тоже вредны. И если что, то я не программист и не пишу чистый апи код. Я как раз двигаю продукты и помогаю с UX и от программистов требую доработок, чтобы было понятно и удобно. Но «шо занадто то нездраво»

Если про «собачку в емейле» — это «вы забыли вставить собачку» — мне кажется, это вполне нормальная подсказка.
На так никто делать не будет, потому что придется делать несколько лишних проверок. Сейчас же все обходятся одной проверкой.

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

Так об этом же и речь. Просто закачику такой валидации нужно сказать «это займет ХХ часов по цене YY денег/час. Итого = XX*YY. Вам это точно нужно?» И дальше плясать от ответа. :)

Сервер у меня один. А клиентских компьютеров у меня много. Поэтому я предпочту перенести проверки с сервера на клиента. Пусть там процессор греется. :)
А ко мне пусть приходят предварительно отвалидированные данные.

Не спорю. Правда все равно придется валидировать и на сервере, так как клиентам нельзя доверять. Разве что валидация попроще будет. Комментарий о том, что «это создает нагрузку» — так себе аргумент. Всё создает нагрузку, но если это нужно пользователю, значит нужно.

Да, естественно. Но на сервере валидировать нужно один раз, а не по мере ввода данных.

Ага, я буду постити вам їх напряму, всіляке сміття, а ви будете довіряти цим даним.
А потім ваша система чомусь поламається. Випадково.

Я ніде не казаав, що я відмовляюсь робити серверну валідацію. Але навантаження на сервер буде значно меншим, якщо спочатку робити валідацію на клієнті.

Ви економите на сірниках. Навантаження на стороні сервера краще вже тому, що

  • Можна легко моніторити. Спробуйте зібрати показники з усіх можливих клієнтів.
  • Легко можна додавати ресурси. Спробуйте додати пам’яті в мобільний телефон клієнта
  • Дешеве. Так, ви не помилитися, воно в рази дешевше за навантаження клієнта. Бо воно розраховано саме на це.
  • Ви контролюєте все.
Перелічувати переваги можна ще довго. А тепер подивіться на прості речі. Ви все одне мусити валідувати дані. Тільки тепер ви робите це два рази, замість одного. На стороні клієнта та на стороні сервера. Вірогідність виникнення помилок стає більшою не в два рази.
Можна легко моніторити. Спробуйте зібрати показники з усіх можливих клієнтів.

Які саме показники? Невірного заповнення форм?

Легко можна додавати ресурси. Спробуйте додати пам’яті в мобільний телефон клієнта

А навіщо мені додавати пам’ять у мобільний телефон клієнта? JS-валідація багато пам’яті не потребує.

Дешеве. Так, ви не помилитися, воно в рази дешевше за навантаження клієнта. Бо воно розраховано саме на це.

Це ваше враження, чи є якісь дослідження?

Ви контролюєте все.

Я і так контролюю.

Тільки тепер ви робите це два рази, замість одного.

Це якщо кліент зразу вводить валідні дані. А якщо він починає щось перебирати — то на клієнті легко може бути з десяток валідацій. І тільки одна — на сервері.
До того ж у більш-менш пристойних фреймворках включення валідації на клієнті — це додати щось на кшалт «$this->clientValidation = true;» до коду форми.

Які саме показники? Невірного заповнення форм?

Показники навантаженності та використання ресурсів.

А навіщо мені додавати пам’ять у мобільний телефон клієнта? JS-валідація багато пам’яті не потребує.

Ок, запитань більше не маю.

Це ваше враження, чи є якісь дослідження?

Яке дослідження вам необхідно? Ви сервери хоч раз в житті бачили? Знаєте чому саме їх ставлять в ЦОДи?

Показники навантаженності та використання ресурсів.

Сервера чи клієнтського пристрою?

Ок, запитань більше не маю.

І це прекрасно. :)

Знаєте чому саме їх ставлять в ЦОДи?

Бо вони вимагають охолодження та швидкого зв’язку.
Увага, запитання з зірочкою: а чому сервери вимагають охолодження?

Подписаться на комментарии