Защо "какво прави потребителят" не е достатъчно
Повечето дизайнери започват проект с въпроса "какво прави потребителят?". Рисуват user flows, правят wireframes, подреждат екрани. И това не е грешно, но е непълно.
Проблемът е, че "какво прави" описва поведение, а не мотивация. А когато не разбираш мотивацията, проектираш за сценарии, които изглеждат логични на хартия, но не решават истинския проблем на потребителя.
Тук влиза Jobs To Be Done (JTBD), framework, който обръща фокуса от "какво прави потребителят" към "какво иска да постигне". И тази разлика е по-голяма, отколкото звучи. В тази статия ще разгледаме какво е JTBD, как се прилага на реален проект и защо променя начина, по който задаваш въпроси като дизайнер.
1. Какво е Jobs To Be Done
JTBD е идеята, че хората не купуват продукти или услуги. Те "наемат" продукт, за да свърши конкретна работа в живота им. Класическият пример на Clayton Christensen: никой не купува бормашина, защото иска бормашина. Иска дупка в стената. Или по-точно, иска рафт, на който да сложи книгите си.
Когато мислиш през JTBD, спираш да описваш функции и започваш да описваш резултати. Не "потребителят натиска бутон за запазване", а "потребителят иска да е сигурен, че работата му няма да се загуби".
Формулата е проста:
Когато [ситуация], искам да [мотивация], за да мога [очакван резултат].
Тази структура изглежда елементарна, но когато я приложиш на реален проект, нещата се променят. Изведнъж спираш да мислиш за бутони и екрани и започваш да мислиш за контекст, емоции и очаквания.
2. Реален пример: редизайн на booking flow
Преди време работихме по проект за хотелска група (6 бранда, 6 сайта). Един от ключовите екрани беше процесът на резервация. Първоначалният бриф беше "направете резервацията по-бърза".
Ако бяхме тръгнали директно, щяхме да махнем полета, да намалим стъпките, да оптимизираме формата. Стандартна UX оптимизация. И вероятно щяхме да постигнем малко подобрение, но не това, което клиентът наистина имаше нужда.
Но когато приложихме JTBD мисленето, задахме друг въпрос: каква работа "наема" потребителят, когато резервира хотел?
Отговорите бяха различни от това, което очаквахме:
"Искам да съм сигурен, че няма да сгреша с избора" - хората не бързат. Те искат увереност. Грешната стая или грешният хотел означава развален уикенд.
"Искам да покажа на партньора си опциите" - решението не е индивидуално. Потребителят трябва да сподели, да обсъди, да получи одобрение.
"Искам да знам какво точно ще получа за парите си" - прозрачност, не скорост. Скритите такси и неясните описания са по-голям проблем от дължината на формата.
Резултатът? Вместо да правим резервацията "по-бърза", добавихме функция за сравнение на стаи, ясна разбивка на цената и лесен начин за споделяне на линк. Конверсиите се повишиха, защото решихме истинската "работа".
3. Как JTBD променя въпросите ти
Ето практическата разлика. Без JTBD задаваш въпроси като:
Колко стъпки има в процеса?
Къде кликва потребителят?
Какъв е bounce rate-ът на тази страница?
Тези въпроси не са грешни. Но описват само повърхността. С JTBD добавяш друг слой:
Каква е ситуацията, в която потребителят стига до този екран? Бърза ли? Разсеян ли е? На мобилен в метрото ли е?
Какъв резултат очаква? Бързина, увереност, контрол?
Какво го кара да се колебае? Страх от грешка? Липса на информация? Объркващ интерфейс?
Какво алтернативно решение ползва в момента? Excel, бележки в телефона, разговор с приятел?
Последният въпрос е особено мощен. Ако знаеш, че хората сравняват хотели в Excel таблица, преди да резервират, разбираш, че "работата" включва организиране и сравняване, не само покупка. И тогава проектираш инструмент за сравнение, не по-бърза форма.
4. Как да приложиш JTBD на практика
Не ти трябва двуседмичен research sprint. Ето три стъпки, които работят дори на малки проекти:
Стъпка 1: Напиши Job Stories вместо User Stories
Вместо "Като потребител искам да филтрирам продуктите, за да намеря това, което търся", пиши: "Когато имам 10 минути обедна почивка и искам да поръчам подарък за рожден ден, искам бързо да стесня вариантите, за да не се чувствам претоварен от избор".
Разликата е контекстът. Първата версия описва feature. Втората описва живот. Втората ти казва, че потребителят е под натиск от време и емоционално зареден (подарък за близък човек). Това променя дизайна.
Стъпка 2: Попитай "защо" 3 пъти
Когато клиент каже "искам бутон за филтри", попитай защо. "Защото потребителите не намират продуктите." Защо? "Защото имаме 2000 продукта в каталога." Защо толкова много са видими? Може би проблемът не е липсата на филтър, а лошата категоризация или липсата на smart search. Три нива "защо" стигат до коренния проблем.
Стъпка 3: Тествай с "switching interview"
Вместо да питаш "какво искаш от продукта", питай "разкажи ми за последния път, когато реши да смениш [продукт/услуга]". Какво се случи? Какво те накара да потърсиш алтернатива? Какво изпробва, преди да се спреш на текущото решение? Така разбираш реалната мотивация, не теоретичната.
5. Кога JTBD е най-полезен (и кога не)
JTBD не е за всеки проект. Ако правиш банер за кампания или landing page за еднократна промоция, не ти трябва framework за мотивация. Но е изключително полезен когато:
Проектираш нов продукт или значителна нова функционалност
Конверсиите са ниски и не знаеш защо
Клиентът описва решение ("искам X бутон"), а ти подозираш, че проблемът е другаде
Работиш в екип и ти трябва общ език за приоритизиране на функционалности
Redesign на съществуващ продукт, който "не работи", но никой не може да каже точно защо
В тези ситуации JTBD е инструмент, който те спасява от "правилно изпълнен грешен дизайн". А това е може би най-скъпата грешка в нашата професия: да вложиш седмици в решение, което изглежда перфектно, но решава грешния проблем.
Заключение
Jobs To Be Done не е магическа формула. Това е дисциплина на въпросите, които задаваш, преди да отвориш Figma. Когато разбираш какво наистина иска потребителят (не какво казва, че иска), дизайнът ти спира да бъде красиво предположение и става решение на реален проблем.
Следващия път, когато получиш бриф, не питай "какво да направя". Питай "каква работа трябва да свърши този продукт".
