Марио ТрендафиловЧовек е избрал продукт.
Посочил е необходимия вариант.
Натиска:
„Добави в количката“
Страницата почти не се променя.
Някъде в горния десен ъгъл малката цифра до количката се увеличава от 0 на 1.
Потребителят не я забелязва.
Какво прави сега?
Може да изчака.
Може да натисне отново.
Може да отвори количката, за да провери дали продуктът е там.
Може да реши, че сайтът не е реагирал.
Самото действие вече е приключило. Проблемът не е в това дали бутонът е бил ясен или дали човекът е знаел какво да направи.
Новият въпрос е:
Как да разбере как системата е реагирала?
Тук под обратна връзка не разбираме мнението, което клиентът дава за сайта. Говорим за обратната връзка от интерфейса към човека след неговото действие.
Тя трябва да премахне неизвестността, която възниква веднага след момента на действие.
След действието трябва да е ясно в какво състояние се намира процесът
Не всяко действие завършва моментално.
Понякога системата може веднага да покаже:
„Продуктът е добавен в количката.“
Друг път трябва да обработи заявка, плащане, качване на файл или друга операция.
Затова обратната връзка не се свежда до съобщение:
„Готово.“
По-важно е човекът да разбира текущото състояние.
Например:
Действието е прието и още се обработва.
Действието приключи успешно.
Действието не беше изпълнено.
Това разграничение е важно, защото една и съща липса на видима промяна може да означава съвсем различни неща.
Системата може да работи нормално.
Може да е приключила успешно, но интерфейсът да не го показва достатъчно ясно.
Може да е възникнал проблем.
За потребителя резултатът е един и същ: не знае какво става.
Точно тази неизвестност трябва да премахне обратната връзка.
WCAG 4.1.3 разглежда по-тясно конкретен клас status messages: промени в съдържанието, които без промяна на контекста информират за резултат от действие, състояние на изчакване, напредък на процес или наличие на грешка. Критерият изисква тези съобщения да могат да бъдат програмно определени, така че помощните технологии да ги представят без необходимост съобщението да получава фокус.
Успешното действие трябва да показва какво се е случило
Да се върнем към добавянето в количката.
След натискането може да се появи:
„Успешно.“
Технически има обратна връзка.
Но успешно какво?
Ако човекът току-що е извършил едно очевидно действие, краткото потвърждение може да е достатъчно.
При по-сложна ситуация обаче може да има значение да стане ясно:
кой продукт е добавен;
кой вариант;
в какво количество.
Не защото всяко потвърждение трябва да показва всички възможни подробности.
А защото човекът трябва да получи достатъчно информация, за да разбере какво точно се е променило в резултат от последното му действие.
Представете си продукт с няколко сходни варианта.
Потребителят добавя конкретния вариант в количката и получава само малко известие:
„Добавено.“
Ако има съмнение дали е избрал правилния размер или конфигурация, той може да отвори количката единствено за да провери какво всъщност е станало.
Интерфейсът е върнал отговор, но не е затворил неизвестността.
W3C техника G199 показва един възможен подход за намаляване на това усилие при успешно подадени данни: явно потвърждение на успеха, вместо потребителят сам да трябва да го установява чрез други промени по страницата. Техниката е пример за начин на реализация, а не универсално правило, че всяко успешно действие трябва да използва точно такъв тип съобщение.
При грешка трябва да е ясно какво не е станало
В предишната стъпка — Действие — проверявахме дали предварително известните изисквания са били достатъчно ясни.
Но дори при добър интерфейс грешки ще има.
Връзката може да прекъсне.
Плащането може да не бъде прието.
Въведената информация може да не отговаря на изискванията.
Наличността може да се е променила.
В този момент задачата на обратната връзка е различна.
Човекът вече е действал.
Сега трябва да разбере:
че действието не е приключило успешно;
и
какво конкретно е попречило, когато причината може да бъде установена и тази информация е релевантна за потребителя.
Съобщение като:
„Възникна грешка.“
потвърждава, че има проблем, но често оставя основния въпрос нерешен.
Грешка в какво?
Плащането не е прието?
Заявката не е изпратена?
Има проблем с конкретно поле?
Системата временно не може да обработи операцията?
Когато разполагаме с полезна и достатъчно конкретна причина, общото съобщение оставя на потребителя повече неизвестност, отколкото е необходимо.
При автоматично открита грешка във входни данни WCAG 3.3.1 изисква проблемният елемент да бъде идентифициран и грешката да бъде описана на потребителя в текст. Критерият е конкретно за този тип автоматично открити input errors и не е общо изискване за всяка възможна системна грешка.
Тук обаче няма да превръщаме темата в ръководство за писане на съобщения за грешки.
По-важният принцип е:
когато причината за неуспеха може да бъде установена и е полезна за следващото разбиране на потребителя, интерфейсът не трябва да го оставя сам да я отгатва.
Когато процесът отнема време, липсата на реакция създава нов проблем
Представете си плащане, което изисква няколко секунди обработка.
Потребителят натиска бутона.
Следва тишина.
Страницата изглежда по същия начин.
След две секунди човекът вече може да се пита:
Натиснах ли?
След още малко:
Трябва ли да натисна пак?
И точно тук може да възникне второ действие, което човекът никога не е възнамерявал да прави.
Не защото първото е било грешно.
А защото системата не е показала, че го обработва.
Затова при операция, която реално отнема време, обратната връзка има междинна функция:
„Получих действието ти. Все още работя по него.“
Това не означава, че всеки процес се нуждае от сложна анимация или процентен индикатор.
При кратка операция може да е достатъчна ясна промяна в състоянието.
При по-дълъг процес може да е необходима повече информация.
Решението зависи от конкретното взаимодействие.
Но липсата на какъвто и да е разбираем сигнал оставя потребителя да решава сам дали системата работи.
А той няма достъп до тази информация.
Как бих проверил дали има проблем с обратната връзка
Проверката започва точно там, където приключи предишната статия:
човекът активира контрола.
От този момент бих проверил четири неща.
Разбира ли, че системата е реагирала?
Има ли достатъчно ясна промяна, която показва, че действието е регистрирано?
Не е важно непременно да има отделно съобщение.
Важно е човекът да не остава в съмнение дали изобщо се е случило нещо.
Разбира ли текущото състояние?
Ако операцията не приключва веднага, ясно ли е дали все още се обработва?
А след приключването — ясно ли е дали е успешна или не?
Разбира ли какво конкретно се е случило?
Ако действието е успешно, достатъчно ясно ли е какво е добавено, изпратено, запазено или променено?
Обратната връзка трябва да съответства на конкретната операция, а не просто да показва общ знак за успех.
Ако има проблем, може ли да разбере какъв е?
Знае ли, че действието не е изпълнено?
И ако причината може да бъде установена и е релевантна за него, прави ли интерфейсът тази
информация достатъчно ясна?
Така рамката става:
активирано действие → видима реакция → разбираемо състояние → ясно какво се е случило или какво е попречило
Едва след това има смисъл да решаваме дали конкретната реализация трябва да бъде съобщение, промяна в интерфейса, индикатор или друг подход.
Обратната връзка не е крайният резултат
Нека човекът добави продукт в количката.
Интерфейсът ясно показва:
„Продуктът е добавен в количката.“
Обратната връзка е свършила своята работа.
Човекът знае как системата е реагирала на последното му действие.
Но това не означава, че е постигнал причината, заради която е започнал.
Той вероятно не е дошъл в магазина, защото иска продукт в количката.
Може да иска да направи поръчка.
Да получи продукта.
Да резервира услуга.
Да изпрати заявка, която действително да бъде обработена.
Това е различен въпрос.
Обратна връзка пита:
„Какво се случи след действието ми?“
Следващата стъпка е:
„Получих ли резултата, който всъщност се опитвах да постигна?“
Това вече е UX → Резултат.