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

Клиентът е избрал продукта.

Знае цената.

Прочел е условията.

Добавил го е в количката.

Започнал е поръчката.

Тук вече е лесно да приемем, че най-трудната част е приключила.

Човекът иска продукта.

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

Трябва да измисли парола.

Формата не приема адреса му.

Не разбира защо е необходимо да попълни част от полетата.

Предпочитаният му начин на плащане липсва.

При натискане на бутона получава неясна грешка.

Опитва отново.

И напуска.

Крайното поведение е:

няма поръчка.

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

Човекът може да има причина да действа и въпреки това системата да му попречи да го направи.

Това е разликата между:

„Искам ли?“

и:

„Мога ли?“

Желанието не гарантира действие

В статията за мотивацията разгледах обратната ситуация.

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

Тук проблемът е друг.

Причината вече може да съществува.

Клиентът:

иска продукта;

има средства;

вярва на магазина;

приема риска;

готов е да действа.

Но между намерението и резултата има система.

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

Потребителят трябва да:

разбере какво се очаква от него;

намери правилното действие;

предостави необходимата информация;

разполага с нужните средства или метод за плащане;

премине през техническия процес;

разбере какво се случва след всяка стъпка.

Ако някое от тези условия липсва, желанието само по себе си не е достатъчно.

Затова изоставената поръчка не означава автоматично:

„Клиентът се е отказал от продукта.“

Може да означава:

„Клиентът се е отказал от процеса.“

Кога проблемът вече не е в убеждаването

Да приемем, че човек вече е стигнал до checkout.

Там отново му показваме:

„Най-продаваният продукт.“

„Отличен избор.“

„98% доволни клиенти.“

„Само днес.“

Може тези послания да имат функция.

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

Той вече не пита:

„Струва ли си продуктът?“

Пита:

„Как да продължа?“

Това е важна диагностична граница.

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

Може да добави повече ревюта.

Повече промоционални послания.

По-голям бутон.

Още reassurance.

И нищо от това да не промени резултата, защото човекът вече е убеден.

Той просто не може да завърши действието достатъчно лесно.

Триенето не е само броят на кликовете

„По-малко стъпки.“

„По-малко кликове.“

„Всичко на една страница.“

Това са популярни UX цели.

Но сами по себе си не определят дали един процес е лесен.

Checkout от три стъпки може да бъде значително по-труден от checkout от пет.

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

Мащабните usability изследвания на Baymard показват, че сложността на checkout-а не се свежда просто до броя стъпки, а до количеството и сложността на елементите, които човек трябва да обработи.

Актуалните им данни показват, че 18% от анкетираните американски онлайн купувачи са изоставяли поръчка, защото checkout процесът им се е сторил прекалено дълъг или сложен.

Източник: Baymard Institute, „Cart Abandonment Rate Statistics“, данни за 2025 г.

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

Колко усилие изисква системата, за да може човекът да постигне това, което вече е решил да направи?

Триенето може да приема различни форми

Понякога препятствието е очевидно.

Бутонът не работи.

Плащането дава грешка.

Полето не приема валидна стойност.

Но има и много по-тихи форми на триене.

Когнитивно триене

Човекът трябва да разбере:

Какво означава това поле?

Защо го питат?

Каква е разликата между тези два метода?

Какво ще стане, ако натисне бутона?

Дали поръчката вече е завършена?

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

Информационно триене

Системата изисква информация, която човекът няма в момента.

Например:

номер на документ;

точен продуктов код;

фирмена информация;

неочаквана техническа характеристика.

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

Може и никога да не се върне.

Техническо триене

Сайтът работи лошо на конкретно устройство.

Клавиатурата покрива полето.

Не може да се постави текст.

Captcha не се зарежда.

Страницата губи вече въведеното.

Плащането се връща без ясно обяснение.

Процесно триене

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

Например:

да създаде акаунт преди поръчката;

да предостави маркетингова информация;

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

В актуалните данни на Baymard 19% от анкетираните американски онлайн купувачи посочват задължителното създаване на акаунт като причина за отказ.

Baymard препоръчва ясно видима възможност за guest checkout и отлагане на регистрацията до след завършване на поръчката.

Източник: Baymard Institute, „How to Reduce Cart Abandonment“.

Тук проблемът не е в дизайна на полето.

Въпросът е:

Защо полето изобщо съществува?

Представете си клиент, който вече е решил

Клиент купува продукт за 250 лева.

Стига до checkout.

Първо трябва да избере:

„Вход“

или

„Регистрация“.

Guest checkout няма.

Следва:

име;

фамилия;

телефон;

имейл;

парола;

повторение на паролата;

адрес;

населено място;

пощенски код;

област.

След това трябва да потвърди имейла си.

Отваря друга програма.

Връща се.

Сесията е изтекла.

Това е краен пример, но добре показва проблема.

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

Иска акаунт, защото така обслужва клиентите по-лесно.

Иска потвърждение заради сигурността.

Иска област, защото така е направена системата.

Но клиентът не оценява архитектурната логика зад процеса.

Той изпълнява една задача:

„Искам да купя този продукт.“

А системата му отговаря:

„Преди това свърши още шест наши задачи.“

Точно тук възниква ненужното триене.

Не всяко усилие е ненужно

От това обаче не следва:

„Премахнете всичко.“

Понякога допълнителната стъпка има функция.

Когато човек изтрива важни данни, потвърждението може да го предпази от грешка.

Когато прави необратима операция, допълнителната проверка може да е оправдана.

Когато информацията е необходима за законово, финансово или логистично изискване, просто премахването ѝ не решава проблема.

Затова аз не бих оценявал триенето по правилото:

по-малко = винаги по-добре.

По-полезното разграничение е:

необходимо усилие — усилие, необходимо за какво?

срещу

ненужно усилие.

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

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

Защо клиентът плаща с усилие за ограничение на нашия процес?

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

Представете си форма с 15 полета на една страница.

Можем да кажем:

„Checkout-ът е само една стъпка.“

Но визуално и когнитивно задачата изглежда голяма.

Същата информация може да бъде разделена логично:

контакт;

доставка;

плащане;

потвърждение.

Сега имаме четири стъпки.

Броят им е по-голям.

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

Точно затова оптимизацията не трябва да започва от:

„Колко клика можем да премахнем?“

А от:

„Какво реално трябва да свърши човекът и как можем да намалим ненужното натоварване?“

Това е различен начин на мислене.

Способността зависи и от човека

Един и същ процес не изисква еднакво усилие от всички.

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

Друг може да не знае какво означава CVV.

Един човек може лесно да копира IBAN.

Друг извършва покупката на телефон, докато пътува.

Един има всичките си данни под ръка.

Друг трябва да ги търси.

Затова способността не е постоянна характеристика само на интерфейса.

Тя се появява в отношението между:

задачата

и

ресурсите на човека в конкретната ситуация.

Тези ресурси могат да бъдат:

време;

внимание;

познание;

информация;

физическа възможност;

подходящо устройство;

достъп до метод за плащане.

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

Ниската conversion rate не доказва проблем с триенето

Това е същият капан, който се появява и при другите мисли от „Поведение“.

Виждаме симптом:

хората не завършват поръчката.

И прескачаме към решение:

трябва да оптимизираме checkout-а.

Възможно е.

Но клиентът може:

да не е достатъчно мотивиран;

да не вярва на бизнеса;

да се съмнява в избора;

да не е готов точно сега;

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

Затова cart abandonment е сигнал.

Не диагноза.

Данните на Baymard показват висока средна степен на изоставяне на колички, но причините са различни и само част от тях са пряко свързани с UX на checkout-а.

Въпросът е:

Къде точно поведението се прекъсва и какво знаем за причината?

Как бих търсил ненужното триене

Бих започнал от желаното действие.

Например:

„Клиентът трябва да завърши поръчката.“

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

Нужни са:

идентификация за контакт;

адрес или друг начин за получаване;

избор на доставка;

начин за плащане;

потвърждение на поръчката.

После бих разгледал всяко допълнително изискване.

Защо съществува?

Каква грешка предотвратява?

На клиента ли служи?

На бизнеса ли служи?

Задължително ли е?

Може ли системата сама да намери информацията?

Може ли човекът да го направи по-късно?

Какво се случва, ако не го направи?

После бих проверил реалното поведение.

На кои полета хората грешат?

Къде се връщат назад?

Къде прекъсват?

Кои грешки се повтарят?

Кои устройства имат повече проблеми?

Какво казва екипът за обслужване?

Какво показват session recordings, usability тестовете или реалните оплаквания, когато имаме такива данни?

Така диагностичната верига става:

желано действие → необходим ресурс → изискване на системата → препятствие → функция на препятствието → необходимо или ненужно триене → промяна

Това е много по-конкретно от:

„Checkout-ът трябва да стане по-лесен.“

Понякога проблемът не е в интерфейса

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

Можем да разработим чудесен компонент за избор.

Да добавим филтри.

Да направим tooltip-и.

Да сортираме опциите.

Но защо съществуват 12 почти еднакви метода?

Може проблемът да е в договорите с куриери.

В начина, по който са дефинирани услугите.

В продуктовата логика.

В складовата система.

В интеграцията.

Тогава интерфейсът отново показва резултат от решение, взето другаде.

И ако просто направим сложността по-красива, не сме я премахнали.

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

Улесняването не трябва да отнема контрол

Има и друга крайност.

В опита си да направим всичко „frictionless“ можем да започнем да вземаме решения вместо човека.

Предварително маркирани опции.

Автоматично добавени услуги.

Незабележими абонаменти.

Бутон, който изглежда като следваща стъпка, но всъщност потвърждава нещо друго.

Това може да намали броя действия.

Не означава, че подобрява преживяването.

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

От 399 проверени сайта и приложения 148 съдържат поне един от разглежданите видове dark patterns.

Източник: European Commission, „2022 – sweep on dark patterns“.

Следователно добрият UX не е този, при който човекът прави възможно най-малко.

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

Клиентът не трябва да работи повече заради нашата система

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

Не трябва отново да го убеждаваме защо продуктът е добър.

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

Понякога това означава:

по-малко полета;

guest checkout;

по-ясна грешка;

подходящ метод за плащане;

запазване на вече въведената информация;

по-добра мобилна версия;

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

Но понякога интерфейсната промяна няма да е достатъчна.

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

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

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

Триенето става видимо в интерфейса, но причината за него може да е много по-назад.

Затова добрата оптимизация не се състои в механично премахване на елементи.

Тя започва с по-прост въпрос:

Какво действително е необходимо на клиента, за да завърши действието?

След това можем да сравним това с онова, което системата реално изисква от него.

Разликата между двете е мястото, което трябва да изследваме.

Лесният процес не е този с най-малко действия

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

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

Затова понякога една допълнителна стъпка е полезна.

По-важният въпрос не е:

„Можем ли да премахнем тази стъпка?“

А:

„Каква функция изпълнява тя и оправдава ли усилието, което изискваме от човека?“

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

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

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

Оптимизираме отношението между необходимото действие и необходимото усилие.

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

Едно незавършено действие не ни казва автоматично защо човекът е спрял.

Затова ниската conversion rate, изоставената количка или прекъснатият checkout са началото на анализа, а не неговият край.

Първо трябва да установим:

Иска ли човекът изобщо да продължи?

Знае ли как?

Има ли необходимата информация?

Разполага ли с нужните средства и възможности?

Какво точно изисква системата от него?

Кое от това изискване е действително необходимо?

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

Понякога резултатът ще бъде UX промяна.

Понякога техническа корекция.

Понякога промяна на процес.

Понякога интеграция.

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

Това е причината „Клиентът не завърши поръчката“ да не е достатъчна диагноза.

Въпросът е:

„Искаше ли да я завърши и ако да — какво му попречи?“

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

В първия случай трябва да разберем мотивацията.

Във втория трябва да погледнем към собствения си процес.

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

Трябва просто да не застава на пътя му.