Представете си човек, който вече е избрал конкретен модел слушалки и знае, че иска черния вариант.

Решението е взето.

На продуктовата страница обаче бутонът „Добави в количката“ е неактивен. До него има няколко цветови варианта, но не е очевидно, че черният трябва да бъде избран изрично, преди действието да стане достъпно.

Човекът не се колебае кой продукт иска.

Не сравнява варианти.

Не му липсва информация за решението.

Той просто трябва да разбере как да заяви през интерфейса нещо, което вече е решил.

Точно тук започва Действие.

При Избор въпросът беше:

„Кое искам?“

Сега въпросът е:

„Как заявявам това решение чрез интерфейса?“

Решението е взето. Интерфейсът трябва да позволи то да бъде изпълнено

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

И въпреки това да постави нова пречка в момента, в който потребителят вече е готов да действа.

Това действие не е задължително покупка.

То може да бъде:

добавяне в количката;

искане на оферта;

изпращане на запитване;

резервация;

запазване.

Наличието на функцията само по себе си не е достатъчно.

Човекът трябва да разбира какво е необходимо преди действието, откъде се извършва и какво ще направи съответният контрол.

Ако след взетото решение възникне нов въпрос от типа:

„Добре, а сега какво точно трябва да натисна?“

интерфейсът е превърнал изпълнението в отделна задача.

Действието може да има необходими предпоставки

Понякога основното действие е напълно ясно, но преди него системата изисква допълнителна информация.

Например човекът трябва да:

посочи вече избран вариант;

въведе количество;

попълни задължително поле;

предостави информация, необходима за заявката.

Самите изисквания не са непременно проблем.

Ако бизнесът реално се нуждае от дадена информация, премахването ѝ само за да направим интерфейса „по-лесен“ не е автоматично правилното решение.

Проблемът е, когато необходимата предпоставка остава скрита до момента, в който човекът вече очаква да може да действа.

Да приемем, че потребителят е решил, че му трябват 12 броя от даден продукт.

Ако трябва просто да въведе 12 в полето за количество, това е част от действието.

Ако системата допуска максимум 10, но това ограничение никъде не е показано предварително, човекът трябва сам да открие предварително съществуващо ограничение, което интерфейсът е можел да покаже.

Същото важи за избрания вариант.

Ако човекът още решава между 8 GB и 16 GB, сме в Избор.

Ако вече знае, че иска 16 GB и трябва само да посочи тази стойност, за да продължи, сме в Действие.

Разликата е проста:

Изборът определя какво иска човекът. Действието му позволява да го заяви.

Правилното действие трябва да може да бъде разпознато

На една страница може да има повече от едно действие.

Например:

Добави в количката

Поискай оферта

Запази

Това не е автоматично UX проблем.

Проблемът е, ако ролята на тези действия не е достатъчно ясна.

Човекът вече знае какво иска да направи. Интерфейсът трябва да му позволи да разпознае контрола, който съответства на това решение.

Това не се свежда до размера или цвета на бутона.

Формулировката също трябва да дава достатъчен контекст.

„Добави в количката“ описва сравнително конкретна операция.

„Продължи“ може да е напълно достатъчно, когато от страницата е ясно какво следва. Ако обаче човекът не може да разбере дали следва преглед на поръчката, плащане или нейното финализиране, надписът оставя излишна неяснота.

Преди да го активира, човекът трябва достатъчно добре да може да предвиди какво ще направи този контрол.

Как системата ще покаже резултата след това е отделен въпрос.

Скритите правила превръщат действието в разгадаване

Интерфейсът често изглежда ясен до момента, в който се появи условие, за което човекът не е знаел.

Полето приема определен формат, но това не е показано.

Някаква информация е задължителна, но не е обозначена като такава.

Има ограничение на количеството, което се вижда едва когато потребителят се опита да го надхвърли.

Във всички тези случаи проблемът не е непременно в самото правило.

Проблемът е кога човекът разбира за него.

Ако дадено изискване е известно предварително и е необходимо за действието, интерфейсът има възможност да го направи ясно още преди опита.

При форма за искане на оферта например няма универсален правилен брой полета. По-важно е кои данни действително са необходими и дали човекът ясно разбира какво трябва да предостави, за да може да изпрати заявката.

Ако въпреки ясните предварителни изисквания бъде допусната грешка, начинът, по който системата ще я обясни след опита, вече принадлежи на Обратна връзка.

Действието трябва да е достъпно, когато необходимият избор е завършен

Не всяко действие трябва да бъде поставено на всяко възможно място.

При продукт, който човекът купува редовно и вече познава, директното добавяне от продуктов списък може да премахне ненужното отваряне на продуктовата страница.

При сложен продукт, при който още трябва да бъде избрана съществена конфигурация, същото действие може да се появи прекалено рано.

Затова въпросът не е:

„Трябва ли да има Add to Cart и тук?“

А:

„На това място необходимият избор вече завършен ли е?“

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

Ако съществена част от избора още предстои, първо трябва да бъде завършена тя.

Как бих проверил дали има проблем с действието

Тук започваме от човек, който вече е взел необходимото решение.

След това бих проверил четири неща.

Ясни ли са предпоставките?

Има ли стойност, количество, поле или друго условие, което трябва да бъде изпълнено преди действието?

Разбираемо ли е това предварително?

Разпознаваем ли е правилният контрол?

Може ли човекът лесно да установи кой бутон или друг интерфейсен елемент съответства на действието, което иска да извърши?

Ясно ли е каква операция ще бъде активирана?

Преди да действа, разбира ли дали контролът:

добавя;

изпраща;

запазва;

финализира;

или преминава към следваща стъпка?

Има ли правило, което ще бъде открито твърде късно?

Ограничение, задължителна стойност или изискван формат могат да бъдат напълно основателни.

Но ако могат да бъдат известни предварително, човекът не трябва да ги открива чрез проба и грешка.

Така гръбнакът на анализа става:

взето решение → предпоставки → разпознаваем контрол → предвидима операция → активиране

Едва след това има смисъл да решаваме дали промяната трябва да бъде в бутона, текста, полето, подредбата или друг конкретен компонент.

Действието приключва в момента, в който човекът активира контрола

Нека потребителят вече знае какво иска.

Изпълнил е необходимите предварителни условия.

Разпознава правилния контрол.

Разбира каква операция ще задейства.

Натиска бутона.

Тук приключва Действие.

Следващият UX проблем започва веднага след този момент:

Как разбира човекът как системата е реагирала?

Добавен ли е продуктът?

Приета ли е заявката?

Има ли грешка?

Какво се е променило?

Това вече е UX → Обратна връзка.