Марио ТрендафиловПредставете си човек, който иска да поръча конкретен продукт с доставка до определен офис на куриер.
Намира продукта.
Избира правилния вариант.
Посочва количеството.
Избира офиса.
Завършва поръчката.
Интерфейсът ясно показва:
„Поръчката е приета успешно.“
В обобщението също ясно е записано къде ще бъде доставена.
Проблемът е, че там стои домашният му адрес, а не офисът, който е избрал.
Тоест интерфейсът коректно показва крайното състояние, което системата е създала.
Но самото крайно състояние е грешно спрямо задачата на човека.
Поръчката съществува.
Операцията е приключила успешно.
Обратната връзка е ясна.
Но резултатът не съответства на това, което човекът се е опитвал да постигне.
Точно тук е разликата между Обратна връзка и Резултат.
Обратната връзка отговаря на:
„Какво се случи след действието ми?“
Резултатът пита:
„Това, което се получи накрая, съответства ли на задачата, с която започнах?“
Резултатът се определя от задачата, не от последното действие
Лесно е да приемем за край на потребителската задача последния бутон в процеса.
Човекът е натиснал:
„Поръчай“
или:
„Изпрати заявката“
или:
„Резервирай“
и операцията е приключила успешно.
Но последното действие е само една стъпка от задачата.
Да приемем, че потребителят иска:
„Да резервирам тази услуга за петък в 15:00.“
Успешно създадена резервация за четвъртък в 15:00 не решава задачата му.
Или:
„Искам да заявя четири броя от конкретния вариант на продукта.“
Създадена поръчка за един брой е валидна поръчка, но не е правилният резултат.
Затова при анализа не е достатъчно да попитаме:
„Завърши ли процеса?“
Трябва да знаем:
„Какво трябваше да бъде вярно в края, за да кажем, че задачата действително е завършена?“
Какво трябва да бъде вярно, за да е правилен резултатът
Да вземем задачата:
„Искам да поръчам четири броя от продукт X, вариант Y, с доставка до офис Z.“
Крайният резултат не е просто:
„Има създадена поръчка.“
Няколко условия са съществени:
продуктът трябва да е X;
вариантът трябва да е Y;
количеството трябва да е 4;
доставката трябва да е до Z.
Ако някое от тях се промени по пътя, системата може да създаде напълно валидна поръчка, която не съответства на задачата.
Разбира се, не всяка задача има четири условия.
При друга ситуация може да има само едно.
При трета същественото може да бъде дата, адрес, получател, конфигурация или избрана услуга.
Не е нужен универсален списък.
Трябва да знаем кои характеристики на крайното състояние определят дали конкретната задача е изпълнена правилно.
Ако не сме определили достатъчно ясно задачата, трудно можем да кажем дали резултатът ѝ е правилен.
Всичко може да работи локално и задачата пак да завърши неправилно
Можем да имаме:
ясна навигация;
добре представени продуктови различия;
разбираемо действие;
ясна обратна връзка след него.
Всеки отделен момент изглежда правилно.
Но нека между избора и крайното състояние избраният вариант бъде заменен с друг.
Или адресът за доставка се върне към стойност по подразбиране.
Или промяна в количеството не бъде запазена.
Потребителят може да премине през добре проектирани интерфейсни стъпки и пак да завърши с неподходящ резултат.
Тогава проблемът не се вижда непременно в отделен компонент.
Вижда се в несъответствието между:
това, което човекът се е опитвал да постигне
и
състоянието, което е създадено в края.
Затова локално успешните взаимодействия не са достатъчни, за да оценим резултата на цялата задача.
Крайното състояние трябва да се оценява спрямо задачата
Да се върнем към поръчката.
Човекът е поискал:
четири броя;
конкретен вариант;
определен офис за доставка.
Ако крайното състояние е:
четири броя;
правилният вариант;
друг адрес за доставка,
задачата не е завършила с правилния резултат.
Тук въпросът вече не е дали интерфейсът ясно е показал състоянието.
Това е работа на Обратна връзка.
Тук проверяваме единствено:
съвпада ли създаденото крайно състояние със съществените условия на задачата?
Резултатът не е бизнес KPI
Успешният UX резултат и успешният бизнес резултат не са едно и също.
Поръчката може да отговаря точно на задачата на клиента и въпреки това да има неблагоприятен марж или друг бизнес проблем.
И обратното — добра бизнес метрика не показва сама по себе си дали конкретните потребителски задачи завършват с правилното крайно състояние.
Тук разглеждаме само резултата на потребителската задача.
Как бих проверил дали има проблем с резултата
Не бих започнал от финалната страница.
Бих започнал от задачата.
Какъв резултат трябваше да постигне човекът?
Не:
„Да натисне Поръчай.“
А например:
„Да създаде поръчка за четири броя от конкретния вариант с доставка до избрания офис.“
Кои критерии определят дали този резултат е успешен?
Кое е съществено за задачата?
Продуктът?
Вариантът?
Количеството?
Дата?
Място?
Избрана услуга?
Търсим само условията, при които различно крайно състояние вече би означавало различен резултат.
Какво е крайното състояние?
Какво реално е създадено, запазено или променено в края на процеса?
Съответства ли то на критериите за успех?
Има ли разлика между резултата, който задачата изисква, и крайното състояние, което процесът е създал?
Рамката е:
задача → критерии за успех → крайно състояние → съответствие
Ако крайното състояние отговаря на съществените критерии на задачата, имаме основание да кажем, че тя е завършила с правилния резултат.
Тази UX последователност завършва с проверката на резултата
Човекът започва с нещо, което се опитва да постигне.
Трябва да се ориентира.
Да намери релевантните възможности.
Да избере.
Да заяви решението си чрез интерфейса.
Да разбере как системата е реагирала.
И накрая остава още една проверка:
това, което е създадено в края, съответства ли на задачата, с която е започнал?
Интерфейсът може да е ясен на всяка стъпка.
Операциите могат да минат успешно.
Обратната връзка може да бъде коректна.
И въпреки това крайното състояние може да е грешно спрямо задачата.
Затова последният въпрос в тази UX последователност е:
„Полученият резултат съответства ли на това, което човекът всъщност се е опитвал да постигне?“