Jobs to be Done + OOUX: Dlaczego te metodologie są naturalnymi sprzymierzeńcami? #EN333

To notatki z 80. odcinka The UX Level-Up Podcast, w którym Sophia Prater (twórczyni Object-Oriented UX) rozmawiała z Jimem Kalbachem (autorem „Jobs to be Done Playbook”). Wszystkie przemyślenia, obserwacje i porady przedstawione poniżej pochodzą od rozmówców – nie są to opinie autora notatek.

TL;DR

JTBD zajmuje się „czasownikami” (zadaniami, celami), a OOUX „rzeczownikami” (obiektami) – to idealne dopasowanie metodologiczne
Oba spowalniają pochopne skakanie do ekranów, chroniąc zespoły przed marnowaniem czasu na eksperymenty prowadzone bez jasnego kierunku
JTBD używa procesu Frame → Discover → Spin, rozkładając zadania na kroki, kryteria sukcesu, emocje i okoliczności
OOUX działa jak „trzeci diament” w modelu Double Diamond – most między definicją problemu a projektowaniem interfejsu
JTBD to język dla biznesu, co ułatwia przekonanie stakeholderów – framework pochodzi ze świata strategii biznesowej, nie tylko UX
OOUX to proces „garbage in, garbage out” – bez dobrych danych wejściowych z badań powstanie logiczny, ale niepotrzebny system
Można zacząć od małych kroków, stosując „quiet JTBD” lub „quiet OOUX” bez oficjalnego ogłaszania wielkiej zmiany

Dlaczego OOUX i Jobs to be Done się uzupełniają?

Kalbach od 2003 roku eksperymentował z Jobs to be Done. Około 2015 roku zaczął nauczać tej metodologii, testując ją na konferencjach przez pięć lat przed napisaniem książki. Jego doświadczenie zawodowe to information architecture – posiada nawet stopień z information science.

Prater od dawna obserwowała ciekawy wzorzec. Ludzie, którzy pokochali OOUX, często również uwielbiają JTBD. Nie jest to przypadek.

Czasowniki i rzeczowniki – idealne dopasowanie

Jobs to be Done koncentruje się na zrozumieniu problemu. Z kolei Object-Oriented UX zajmuje się architekturą rozwiązania. Jak podkreśla Kalbach, to dwa różne aspekty tego samego procesu produktowego.

Prater używa prostej, ale trafnej metafory: Kalbach zajmuje się „czasownikami” – zadaniami, celami, tym co ludzie chcą zrobić. Ona zajmuje się „rzeczownikami” – obiektami, na których te zadania są wykonywane.

JTBD dostarcza wysokiej jakości dane wejściowe dla OOUX. Proces Kalbacha pomaga zidentyfikować główne zadanie (Focus Job) i kryteria sukcesu. Proces Prater (ORCA) bierze te dane i przekłada je na solidną architekturę obiektów, relacji i atrybutów.

Oba frameworki mają wspólny cel – spowolnić zespoły, zanim rzucą się do projektowania ekranów i funkcji. Nie chodzi jednak o hamowanie postępu. Chodzi o zmniejszenie ryzyka tego, co wydarzy się dalej w procesie.

Wspólny język jako fundament

Prater od ponad dekady uczy profesjonalistów, jak uczynić najbardziej wartościowe – i często niewidzialne – części UX widocznymi dla wszystkich. Chodzi o rozplątanie struktury pod powierzchnią, zanim przeskoczymy do ekranów. Dzięki temu oszczędza się czas, pieniądze i unika bólów głowy.

Oba frameworki tworzą wspólny język, który przełamuje silosy organizacyjne. JTBD dostarcza języka do dyskusji o potrzebach użytkowników. OOUX daje z kolei język do rozmawiania o architekturze systemu.

To pomaga budować wspólne zrozumienie, które ustawia wszystkich na sukces. Zamiast sytuacji, gdzie projektanci mówią jednym językiem, ludzie z biznesu drugim, a dział techniczny trzecim – pojawia się struktura do rzeczywistej współpracy. Obie metodyki pozwalają jasno oddzielić dyskusję o problemie od dyskusji o rozwiązaniu.

Największy problem zespołów produktowych

Kalbach pracuje w Mural i współpracuje z zespołami na całym świecie. Obserwuje jeden powtarzający się problem: skakanie do rozwiązań zbyt szybko.

To ludzka natura. Dostajemy wyzwanie i natychmiast myślimy o rozwiązaniu. Zaczynamy rysować ekrany. Ale według Kalbaha warto najpierw zadać kilka pytań – czy ludzie w ogóle tego potrzebują? Jak powinniśmy zaprojektować architekturę domeny wokół tego?

Prater dodaje własną obserwację. Trial and error w kółko jest po prostu wyczerpujący. Tak, zespoły chcą eksperymentować. Powinny być to jednak obliczone eksperymenty, nie podejście typu „strzelamy na ślepo i patrzymy co się uda”.

Kalbach używa mocnej metafory. Można zawęzić pole eksperymentów albo strzelać ze śrutówki w losowym kierunku. Zobaczyć że nie zadziałało, obrócić się i strzelić znowu. To jednak marnowanie trzech miesięcy pracy zespołu.

Jak działa Jobs to be Done w praktyce?

Kalbach wyjaśnia, że jego podejście do JTBD mocno ewoluowało. Jego książka „The Jobs to be Done Playbook” była zbiorem różnych metod – rodzajem zestawu sztuczek. Jednak w odpowiedzi na pytanie „od czego zacząć?”, Kalbach opracował bardziej precyzyjny Core Process.

Nowy proces składa się z trzech głównych faz: Frame, Discover i Spin. Każda faza ma dwa podkroki.

Frame – Ustalenie ram problemu

W tej fazie należy zdefiniować domenę, wykonawcę zadania (job performer) oraz główne zadanie (Focus Job). Chodzi o precyzyjne określenie, jaki problem będziemy rozwiązywać.

Discover – Odkrywanie kroków, potrzeb i emocji

Po zidentyfikowaniu Focus Job rozkłada się go na cztery kluczowe elementy:

Job steps – kroki zadania
Success criteria – kryteria sukcesu
Emotions – emocje towarzyszące zadaniu
Circumstances – okoliczności, w jakich zadanie jest wykonywane

Te elementy można priorytetyzować, żeby zidentyfikować niezaspokojone potrzeby.

Spin – Synteza i wdrożenie wniosków

Ostatnia faza to przekształcenie zebranych informacji w konkretne wnioski i kierunki działania.

Kalbach podkreśla, że JTBD nie mówi, co budować. Zamiast tego precyzyjnie wskazuje, jaki problem należy rozwiązać i gdzie leżą największe, niezaspokojone potrzeby.

Praktyczna lista kontrolna analizy JTBD

Kalbach wspomina, że jego proces Discover polega na rozbiciu głównego zadania na cztery kluczowe kategorie informacji. Można to przekształcić w praktyczną listę kontrolną do wykorzystania podczas badań:

Lista kontrolna analizy Focus Job:

Czy zebrałem informacje o krokach (Job Steps) – jakie są kolejne etapy, przez które przechodzi użytkownik?
Czy znam kryteria sukcesu (Success Criteria) – skąd użytkownik wie, że dobrze wykonał zadanie?
Czy rozumiem emocje (Emotions) – co użytkownik czuje na poszczególnych etapach?
Czy zidentyfikowałem okoliczności (Circumstances) – jakie konteksty wpływają na to, jak zadanie jest wykonywane?

Jak działa Object-Oriented UX w praktyce?

Prater przedstawia OOUX jako metodę budowania struktury systemu. Proces ten koncentruje się na „rzeczownikach”, czyli realnych obiektach ze świata użytkownika, zanim przejdzie do definiowania akcji i ekranów.

OOUX jako „trzeci diament”

Prater zauważa, że w popularnym modelu Double Diamond, OOUX działa jak „trzeci diament”. W rezultacie staje się on brakującym mostem. Łączy definicję problemu (pierwszy diament) z projektowaniem rozwiązania (drugi diament), syntezując badania w konkretną architekturę.

To wyjaśnia, dlaczego wiele zespołów ma problem z przejściem od badań do projektowania – brakuje im tego środkowego kroku, który przekłada zrozumienie problemu na strukturę systemu.

Garbage in, garbage out

Prater podkreśla kluczową kwestię: OOUX to proces typu „garbage in, garbage out” (śmieci na wejściu, śmieci na wyjściu). Jeśli badania są słabe lub powierzchowne, OOUX pomoże zaprojektować logiczny i spójny system. Będzie to jednak system, którego nikt nie będzie potrzebował.

Dlatego właśnie JTBD jest tak cennym źródłem danych wejściowych dla OOUX. Dostarcza precyzyjnych, ustrukturyzowanych informacji o potrzebach i celach użytkowników, które są niezbędne do procesu OOUX.

Przykład: etyczne zakupy (Species Saver)

Prater dzieli się swoim mapowaniem, pokazującym jak połączyła JTBD z OOUX. Wzięła konkretny przykład hipotetycznej aplikacji „Species Saver”, która ma pomagać konsumentom w podejmowaniu etycznych decyzji zakupowych:

Krok 1: Proces JTBD (Problem)

Podejście Kalbacha pomogłoby najpierw zdefiniować problem:

Domena: Etyczne zakupy
Job performer: Świadomy konsument (etyczny kupujący)
Focus Job: Identyfikacja produktów przyjaznych środowisku
Outcome: Podejmowanie decyzji zakupowych zgodnych z własnymi wartościami dotyczącymi praw zwierząt (żeby nie czuć się hipokrytą i unikać złych emocji)

Krok 2: Proces OOUX (Struktura)

Gdy problem jest zdefiniowany, proces OOUX (tzw. „noun foraging” – zbieranie rzeczowników) wyodrębnia kluczowe obiekty. W tym przypadku byłyby to:

Marka (np. Colgate, Hershey’s, Domino Sugar)
Produkt
Zwierzę (gatunek zagrożony)
Habitat (np. las deszczowy Borneo, Everglades na Florydzie)

Jobs to be Done: łączenie zagrożeń dla dzikiej przyrody z konkretnymi markami. Trzeba zrozumieć połączenie między lasem deszczowym Borneo a Colgate. Między Borneo a Hershey’s. Między Everglades na Florydzie a Domino Sugar.

Jak zauważa Prater, nawet w strukturze job statements zadanie ma bezpośredni obiekt (direct object). Robisz coś z czymś. To otwiera drogę do myślenia o obiektach na poziomie domeny i obiektach na poziomie zadania. Produkt ma swoje własne obiekty, które można „wyciągnąć” z zadań poprzez noun foraging.

W ten sposób JTBD precyzyjnie definiuje co użytkownik próbuje osiągnąć, a OOUX określa z czego musi składać się system, aby mu to umożliwić.

Gdzie metodologie się spotykają?

Prater stworzyła mapowanie pokazujące relacje między elementami. Main job ma relację one-to-one z job map, który ma relację one-to-one z job statement. To struktura kardynalności. Następnie main job ma relację z sub-jobami.

Domain składa się z obiektów, a jobs mają swoje obiekty. Kalbach dodaje, że w jego nomenklaturze job performer to osoba wykonująca zadanie. Warto też wybrać jeden termin – solution czy product – i konsekwentnie się go trzymać.

Prater używa terminu „hiring manager”, ponieważ zatrudniasz produkt do wykonania pracy. To jej własne określenie, nie Kalbaha.

Kluczowe połączenia między frameworkami:

Job performer (JTBD) odpowiada User/Actor (OOUX)
Job steps zawierają direct objects
Domain składa się z obiektów, które można mapować z OOUX
Jobs operują na obiektach – te same obiekty pojawiają się w architekturze rozwiązania

JTBD jako język dla biznesu

Jedna z najważniejszych obserwacji Kalbaha: Jobs to be Done nie jest narzędziem designerskim. Pochodzi ze świata strategii biznesowej.

To było dla niego główne przyciąganie do JTBD. Wszyscy zajmujący się UX robią human-centered stuff. Jest mnóstwo nakładających się metodologii. Unikalna rzecz w JTBD? Ludzie z biznesu tego chcą.

Jeśli zyskasz uwagę kogoś z biznesu i powiesz „nie rozwiązujemy właściwego job to be done”, ta osoba może pomóc zatrzymać problematyczny projekt. Albo go spowolnić. Może też wydzielić czas na właściwą analizę.

To właśnie przyciągnęło Kalbaha do JTBD mimo jego doświadczenia w information architecture. JTBD ma strategiczne implikacje, które rezonują z interesariuszami biznesowymi. Dlatego jest to sposób na zdobycie ich uwagi i wsparcia.

Jak wdrożyć to w organizacji feature factory?

Prater zadała kluczowe pytanie. Co powiedzieć UX designerom, którzy pracują w środowisku nastawionym na szybkie eksperymenty? W feature factory, gdzie ludzie pracują nad połową ekranu tu, funkcją tam. Gdzie to wygląda jak przestawianie krzeseł na tonącym Titanicu.

Kalbach przedstawił trzy główne rady, które można zastosować krok po kroku:

Zacznij od małych kroków

Jeśli pracujesz na dużym projekcie w critical path firmy, możesz nie być w stanie go spowolnić. Możesz jednak znaleźć mniejsze miejsce do eksperymentu. Nie próbuj zmieniać wszystkiego naraz na głównym projekcie.

Frameworki można stosować elastycznie. Nie musisz implementować wszystkiego od razu. Weź części, które mają sens w Twoim kontekście, i zacznij od tego, co możesz kontrolować.

Działaj w trybie quiet JTBD i quiet OOUX

Kalbach sam tak zaczynał z JTBD. Był UX designerem i po prostu to robił. Nie nazywał tego tak i nikomu nie mówił.

Istnieją covert sposoby wprowadzenia tego myślenia. Można powiedzieć „hej, a co jeśli spróbujemy tak?”. Prater nazywa to „quiet OOUX”. Kalbach zgadza się – można robić „quiet JTBD”.

Stosuj myślenie JTBD/OOUX bez oficjalnego ogłaszania. Przedstawiaj pomysły jako propozycje, nie jako rewolucję metodologiczną. Wprowadzaj zmiany stopniowo w swoim własnym procesie. Poczekaj z branżowym żargonem – najpierw pokaż rezultaty.

Znajdź business championa

Zidentyfikuj stakeholdera lub sponsora, który cię wesprze. Ponieważ JTBD ma implikacje strategiczne i pochodzi z biznesowego świata, często łatwiej jest zdobyć uwagę ludzi z biznesu.

Użyj języka biznesowego, nie tylko języka UX. Pokaż jak to zmniejsza ryzyko nieudanych projektów. Przedstaw to jako sposób na redukcję kosztów przeróbek. To sposób, żeby ludzie z biznesu rozumieli, że być może rozwiązujecie niewłaściwy problem.

Zbieraj dowody i dziel się nimi

Dokumentuj sukcesy małych eksperymentów. Pokazuj zaoszczędzony czas i pieniądze. Zbieraj feedback od zespołu, a następnie buduj case dla większego zastosowania metodologii.

Prater zachęca do dzielenia się doświadczeniami. Jeśli już łączysz JTBD z OOUX, możesz wejść na forum.ooux.com i opowiedzieć jak to działa. Oboje – Prater i Kalbach – chcą słyszeć od ludzi w terenie.

Slow down to speed up

Kalbach podsumowuje filozofię obu metodologii jednym zdaniem: „It’s slow down to speed up” – zwolnij, żeby przyspieszyć.

Nie chodzi o spowolnienie postępu. Chodzi o zmniejszenie ryzyka dalej w procesie. Warto pomyśleć ile mamy przeróbek, nieudanych projektów, tarć w procesach i churn w cyklach projektowych.

Poświęcenie momentu na spojrzenie na problem i naprawdę zrozumienie go z perspektywy JTBD i OOUX to nie tylko zdrowe podejście. To oszczędność czasu w długiej perspektywie.

Jak dodaje Prater – to może uratować zdrowie psychiczne. Bo trial and error w kółko jest wyczerpujący. Tak, zespoły chcą eksperymentów. Powinny być to jednak obliczone eksperymenty, nie rzucanie losowymi pomysłami na ścianę.

Kalbach zgadza się z tym podejściem. Można zawęzić pole eksperymentacji. Czy mamy właściwy problem? Czy mamy właściwe modelowanie domeny? Dopiero wtedy warto robić eksperymenty w tym obszarze. Zamiast strzelać ze śrutówki w złym kierunku, potem się odwrócić i strzelić znowu. To marnowanie czasu.

Takie podejście pozwala uniknąć kosztownych błędów i marnowania miesięcy pracy zespołu na budowanie niepotrzebnych lub źle zaprojektowanych funkcji.

Stań się systems thinker

Oboje zgodnie podkreślają, że obie metodologie pomagają w czymś kluczowym – w stawaniu się systems thinkers. Jak mówi Prater, to właśnie tacy ludzie są desperacko potrzebni w zespołach. I szczerze mówiąc – w całym świecie.

Chodzi o patrzenie na całość, nie tylko na pojedyncze funkcje. O rozumienie relacji, nie tylko elementów. Wreszcie o projektowanie systemów, które rzeczywiście działają.

Zasoby i dalsze kroki

Jim Kalbach prowadzi dwa rodzaje szkoleń:

Self-serve video course online
Live training (bardziej intensywny, hands-on)

Live training to trzy dwugodzinne sesje w ciągu tygodnia (poniedziałek, środa, piątek) w stylu bootcamp.

Wszystkie zasoby dostępne na jtbdtoolkit.com:

Jobs to be Done Canvas (darmowy download)
Online course
Informacje o live training

Polecane źródła

Jobs to be Done Playbook – Jim Kalbach Praktyczny przewodnik po metodologii JTBD z canvas’ami i narzędziami do zastosowania w pracy produktowej.

Competing against luck – Clayton Christensen Klasyczna pozycja o Jobs to be Done, która pokazuje jak innowatorzy wykorzystują tę metodologię do tworzenia produktów, które klienci rzeczywiście kupują.

Kluczowy insight

Paradoks sojusznika biznesowego

Standardowo myślimy: Musimy „sprzedać” lub przekonać biznes do wartości badań UX i myślenia skoncentrowanego na użytkowniku, używając naszego projektowego żargonu i tłumacząc skomplikowane procesy.

W praktyce okazuje się, że: Jak podkreśla Jim Kalbach, Jobs to be Done nie jest narzędziem projektowym – to narzędzie wywodzące się ze strategii biznesowej. Biznes już myśli w kategoriach rynków, potrzeb i zadań (jobs), jakie klienci chcą wykonać. To ich naturalny język.

Dlaczego to jest istotne: Zamiast walczyć o „czas na UX” i przekonywać do wartości badań, możemy użyć języka, który biznes już zna i rozumie (JTBD). Dzięki temu natychmiast zyskujemy posłuch i sojusznika do rozmów o wartości dla klienta. Nie musimy tłumaczyć dlaczego badania są ważne – mówimy wprost o problemach rynkowych i niezaspokojonych potrzebach.

Test na jutro: Następnym razem gdy będziesz rozmawiać z Product Managerem lub interesariuszem biznesowym, zamiast mówić o „empatii” lub „procesie projektowym”, zapytaj: „Jaki 'job’ (pracę) tak naprawdę próbuje wykonać nasz klient na tym rynku?”. Sprawdź, jak zmienia się dynamika rozmowy i jak szybko zyskujesz zaangażowanie.

Metadane artykułu

Słowa kluczowe: OOUX, Jobs to be Done, JTBD, Jim Kalbach, Sophia Prater, proces projektowy UX, architektura informacji, strategia produktu, systems thinking, feature factory, quiet OOUX, noun foraging

Główne słowo kluczowe: OOUX i Jobs to be Done

Zajawka (150 znaków): Jak połączyć OOUX i JTBD? Notatki z rozmowy Jima Kalbacha i Sophii Prater o tym, jak JTBD definiuje „problem”, a OOUX „rozwiązanie”.

Description (150 znaków): Jim Kalbach (JTBD) i Sophia Prater (OOUX) łączą procesy. Zobacz, jak zdefiniować problem (JTBD) i zbudować jego architekturę (OOUX).

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: The UX Level-Up Podcast – Episode 080: OOUX and Jobs to be Done with Jim Kalbach