Представете си човек, който отваря категория „Лаптопи“ в онлайн магазин.

Какво иска?

Най-лесният отговор е:

„Иска да купи лаптоп.“

Възможно е.

Но за UX анализ това не е достатъчно.

Един човек може вече да знае точния модел и просто да проверява цена и наличност.

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

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

Четвърти има конкретен бюджет и търси подходящ вариант в него.

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

Всички са на една и съща страница.

Всички могат в крайна сметка да купят.

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

В тази статия под намерение ще разбирам именно това: непосредствената потребителска задача в конкретния момент.

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

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

„Иска да купи“ е прекалено общо

Покупката може да бъде крайният резултат.

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

Човек може да се опитва да:

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

разбере кой тип продукт му е необходим;

сравни няколко варианта;

провери съвместимост;

намери продукт в определен бюджет;

разбере условията за доставка;

потвърди, че вече избраният продукт е правилният;

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

Ако съберем всичко това под:

„Потребителят иска да купи“

губим информацията, от която UX анализът има нужда.

Интерфейсът не подпомага абстрактната „покупка“.

Той подпомага конкретни задачи по пътя до нея.

Мотивацията и задачата не са едно и също

Човек може силно да иска нов лаптоп.

Това е мотивация.

Но когато отвори категорията, непосредствената му задача може да бъде:

„Искам да разбера кои модели са подходящи за видеообработка.“

Друг човек може да има сходна мотивация за покупка, но друга задача:

„Знам точно кой модел искам. Трябва да проверя дали е наличен.“

Мотивацията отговаря на въпроса:

Защо има причина да действа?

UX задачата пита:

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

Разликата е важна.

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

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

Една и съща страница може да обслужва различни задачи

Да се върнем към категорията с лаптопи.

На нея има:

търсачка;

категории;

филтри;

сортиране;

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

цени;

характеристики.

Дали това е добър интерфейс?

Още не можем да кажем.

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

Ако знае точния модел

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

Ако не знае какъв модел му трябва

Същият интерфейс може да не е достатъчен.

Филтри като:

16 GB RAM;

32 GB RAM;

Intel Core Ultra 5;

Intel Core Ultra 7;

IPS;

OLED

могат технически да работят отлично.

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

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

Ако вече сравнява два модела

Тогава основната задача е друга — да разбере съществените различия между вариантите.

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

Това не е противоречие.

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

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

Изречение като:

„Филтрите са удобни.“

е непълно.

Удобни за коя задача?

За човек, който знае точните характеристики, които търси?

Вероятно.

За човек, който още не знае кои характеристики имат значение?

Може би не.

Същото важи за:

търсачката;

менюто;

сравняването на продукти;

продуктовата страница;

конфигуратора;

формите;

препоръките.

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

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

Затова вместо:

„Как да подобрим категорията?“

по-полезният въпрос често е:

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

Вътрешната структура на бизнеса не е непременно структурата на задачата

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

Бизнесът има свои:

категории;

подкатегории;

марки;

серии;

технически характеристики;

вътрешни продуктови групи.

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

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

„Трябва ми решение за малко помещение.“

„Това трябва да работи с оборудването, което вече имам.“

„Търся вариант до определен бюджет.“

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

Това не означава автоматично, че категориите са грешни.

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

Видимият UX проблем може да е неправилно разбрана задача

Да приемем, че потребителите използват малко филтрите.

Една възможна реакция е:

„Филтрите не са достатъчно видими.“

Това е хипотеза.

Може да е вярна.

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

Възможно е:

филтрите да използват термини, които хората не разбират;

да съдържат характеристики, които не съответстват на начина на избор;

потребителят още да не знае по какво да филтрира;

много хора да търсят конкретен продукт и да нямат нужда от филтри;

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

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

По-краткият път не е автоматично по-добър

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

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

Човек, който знае точния продукт, вероятно има полза от кратък път:

търсене → продукт → покупка.

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

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

Затова не оценяваме стъпката само по това, че съществува.

Питаме:

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

Как установяваме каква е задачата?

Не е достатъчно да кажем:

„Нашият клиент иска това.“

Това е хипотеза, която трябва да бъде проверена.

Не е нужно и да разполагаме с един „идеален“ източник. По-полезно е да търсим съвпадение между различни сигнали.

Вътрешното търсене

Какво пишат хората в търсачката?

Търсят ли:

конкретни модели;

характеристики;

употреба;

проблем;

съвместимост?

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

Клиентското обслужване

Кои въпроси се повтарят преди покупка?

„Това става ли за...“

„Каква е разликата между...“

„Кой модел е подходящ за...“

„Имате ли вариант с...“

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

Поведението в сайта

Връщат ли се хората между категория и продукт?

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

Преминават ли многократно между сходни продукти?

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

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

Продуктовият контекст

Самият тип продукт може да ни помогне да формулираме разумни начални хипотези.

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

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

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

Наблюдение и разговори с хора

Понякога най-прекият начин е да наблюдаваме как човек изпълнява задачата и да попитаме:

Как би намерил подходящия продукт?

Какво би проверил първо?

Кое не разбира?

Какво трябва да знаеш, преди да продължиш?

Въпросът не е:

„Харесва ли ти сайтът?“

А:

„Как се опитваш да решиш задачата си?“

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

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

Един сигнал не е достатъчен, за да измислим задача

Да приемем, че много хора използват филтъра „Цена“.

Можем да заключим:

„Цената е най-важният фактор.“

Но това не следва автоматично.

Може този филтър просто да е най-разбираемият.

Другите могат да бъдат трудни за използване.

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

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

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

Как бих формулирал задачата

Не бих започнал с:

„Трябва да подобрим UX на продуктовата категория.“

Това описва областта, в която ще работим.

Не задачата на човека.

По-полезна формулировка е:

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

Тук вече знаем:

В каква ситуация се намира човекът?

Знае употребата, но не разбира техническите различия.

Какво вече знае?

Знае какво иска да постигне с продукта.

Какво се опитва да постигне сега?

Да стесни избора.

Какво му е необходимо, за да продължи?

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

Едва след това има смисъл да оценяваме конкретния интерфейс.

Задачата не определя автоматично решението

Да приемем, че сме установили:

„Потребителят трябва да разбере кой от няколко сходни продукта е подходящ за неговия случай.“

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

„Трябва таблица за сравнение.“

Може да са подходящи:

по-ясни продуктови карти;

обяснение на ключовите разлики;

по-подходящи филтри;

въпроси, които стесняват избора;

по-добра категоризация;

по-ясни характеристики.

Първо определяме задачата.

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

И едва тогава избираме решение.

UX анализът започва преди компонента

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

В каква ситуация се намира човекът?

Какво вече знае?

Какво се опитва да постигне сега?

Какво му е необходимо, за да продължи?

След това вече можем да зададем UX въпроса:

Как интерфейсът подкрепя или пречи на тази задача?

Това е по-полезна отправна точка от:

„Добро ли е менюто?“

„Достатъчно видим ли е бутонът?“

„Трябват ли още филтри?“

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

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

Те са само средства.

Той идва да свърши нещо.

Първата работа на UX анализа е да установи какво точно е това нещо.