Wywiad z Jimem Kalbachem część I – Jobs to be done

Mam przyjemność przedstawić wywiad z Jimem Kalbachem, jednym z najbardziej wpływowych liderów w dziedzinie projektowania, doświadczeń klienta i strategii. Jest autorem trzech książek: Designing Web Navigation (Projektowanie Nawigacji w Sieci), Mapping Experiences (Mapowanie wrażeń) oraz najnowszej – „The Jobs To Be Done Playbook„. Twórca Jobs to be Done Toolkit i pełni rolę głównego ewangelisty w firmie MURAL, jednej z wiodących platform do tworzenia tablic online. Więcej na temat jego twórczości możecie przeczytać na jego blogu: experienceinformation.com lub obserwując go na Twitterze.

Jim został zaproszony jako gość specjalny w ramach studiów podyplomowych User Experience Design / Product Design na Uniwersytecie SWPS w 2022 roku. 

Poniższy zapis jest wersją skróconą rozmowy, którą możecie obejrzeć pod linkiem: UXD: Q&A with Jim Kalbach

Wywiad został podzielony na dwie części. W pierwszej części poruszymy czym jest „Jobs to be done” i jak najefektywniej wykorzystać to narzędzie w pracy. Omówimy kiedy najlepiej wykorzystać Job story i Job Map, a kiedy User stories i Customer Journey Map. Jim podzieli się spostrzeżeniami wychodzącymi poza materiał z ksiąźki.

W drugiej części skupimy się na perspektywie zmian i trendów jakie następują w naszej branży. Zastanowimy się jak zmienia się rola projektantów UX w dużych organizacjach. Jim zdradzi, jakie heurystyki wykorzystuje w swojej pracy a także jak radzi sobie z wypaleniem zawodowym.

Spis treści części I:

Adam Michalski
Na początek porozmawiajmy o Twojej ostatniej książce. „Jobs-to-be-done” stało się ostatnio bardzo popularne. Czy możesz powiedzieć osobom, które może nigdy nie słyszały o „Jobs-to-be-done”, co to właściwie jest?

Jim Kalbach
Moje doświadczenie obejmuje UX, projektowanie produktów oraz strategię produktową, a ostatnio zainteresowałem się podejściem „Jobs to be Done”, jako frameworkiem dla innowacji napędzanej ludzkimi spostrzeżeniami. Dla projektantów UX czy osób zajmujących się projektowaniem zorientowanym na człowieka może to brzmieć znajomo, gdyż te dziedziny mają wiele wspólnego, jednak istnieją pewne różnice.

„Jobs to be Done” ma swoje korzenie w biznesie, wyłaniając się jako metoda projektowania kilka dekad temu. Pionierzy tej metody nie skupiali się na tworzeniu produktu i użytecznego interfejsu, lecz na zrozumieniu, jak obserwacja ludzi – niekoniecznie jako klientów czy użytkowników, ale jako wolnych jednostek – może przekształcić się w okazję do wzrostu i innowacji.

Druga różnica polega na tym, że „Jobs to be Done” pozwala bardziej skupić się na zadaniu niż niektóre metody projektowania skierowane na użytkownika. Posiadam doświadczenie z wieloma takimi technikami – napisałem książkę na temat mapowania doświadczeń, miałem styczność z etnografią, tworzyłem persony oraz przeprowadzałem sprinty projektowe. Jobs to be Done nie eliminuje tych metod, wręcz przeciwnie, uzupełnia je, wprowadzając inną perspektywę i precyzje.

Adam Michalski
W Twojej książce omawiasz koncepcję jobs stories. Czy uważasz ją za skuteczniejszą niż user stories? Jeśli tak, to w jakich okolicznościach mają one przewagę?

Jim Kalbach
Uważam, że job stories i user stories mają różne funkcje i potrzebujemy obu tych podejść.

Job stories skupia się na zadaniu, a nie na użytkowniku. Opisuje to, co ludzie próbują osiągnąć, nie odnosząc się do żadnej technologii czy rozwiązania. To opis problemu, jaki mają ludzie, niezależnie od rozwiązania, produktu czy interfejsu.

User stories pochodzi z metodyki Agile i opisuje część technologii, gdyż to jest jego celem. W metodzie Agile dzieli się duże projekty na mniejsze elementy, które projektanci, menedżerowie produktów i inżynierowie traktują jako drobne klocki składające się na całość. Następnie w ramach sprintu podejmuje się próbę zbudowania kolejnych elementów.

Z drugiej strony, job stories koncentrują się na streszczeniu problemu, który ma być rozwiązany. Myślę o tym w kategoriach przestrzeni problemu i przestrzeni rozwiązania. Jobs to be done koncentruje się na opisaniu przestrzeni problemu – jakie zadanie ludzie próbują wykonać niezależnie od technologii. W książce opisuję różne techniki związane z tym podejściem, takie jak tworzenie Job map (mapa zadań) czy przeprowadzanie ankiet.

Job stories jest tym miejscem, gdzie stawiasz zakład, wskazując, gdzie widzisz możliwość rozwoju. Następnie przekazujesz go zespołowi rozwiązującym problem i prosisz o zbudowanie czegoś, co pomoże ludziom wykonać to zadanie. „Job story” jest na początku fazy koncepcyjnej, przed rozpoczęciem budowy rozwiązania. Tymczasem „user stories” pojawiają się później – już wiadomo, co trzeba zbudować, i opisuje się to w „user stories”.

Stąd wynika, że „job stories” i „user stories” różnią się od siebie i mają inne miejsce w procesie projektowania.

Agile unika rozbudowanej dokumentacji i obszernych projektów na starcie, dążąc do tego, aby wszystko było skondensowane i klarowne. I to jest powód, dla którego tak bardzo doceniam „job stories”. Zespół tworzący rozwiązanie nie musi znać całego zakresu przeprowadzonych badań. Mogłem przeprowadzić rozmowy z trzydziestoma osobami, stworzyć Job Map (mapę zadań), przeprowadzić ankietę i  ustalić priorytety. Zespół nie musi jednak znać tych wszystkich szczegółów. Wystarczy, że wiedzą, iż ja i mój zespół ustaliliśmy priorytetowe „job stories”. Zwykle nie jest to jedno zadanie, zazwyczaj skupiamy się na trzech do sześciu „job stories”.

Jeżeli zespół zaufa badaniom, które przeprowadziliśmy, to otrzymują skondensowany, zgodny z filozofią Agile sposób opisania problemu. Jest to lekkie podejście – mamy tylko kilka paragrafów tekstu. Pytanie „Nad czym pracujemy?” jest jasne. Czy to oparte na badaniach? Tak. Nie muszę znać szczegółów badań, wystarczy wiedzieć, że są one podstawą dla naszych działań. To naprawdę pomaga skupić się jako zespół, jest to bardzo zgodne z filozofią Agile, przynajmniej tak mi się wydaje.

Adam Michalski
Czy możemy pracować jednocześnie nad mapą zadań (Jobs map) i scieźką doświadczenia klienta (Customer experience journey maps), a może traktować je jako oddzielne elementy procesu projektowego?

Jim Kalbach
Istnieje znacząca różnica koncepcyjna pomiędzy mapą zadań (jobs map), a ścieżką doświadczenia klienta (customer journey map). Job map nie przedstawia historii klienta czy użytkownika w kontekście interakcji z naszym produktem. Tego rodzaju narrację dostarcza mapa doświadczenia klienta, która odpowiada na pytania: jak klient dowiedział się o nas i naszej marce? Dlaczego zdecydował się na nasz produkt? Jak go używa?

Natomiast job map odwraca to równanie i zamiast skupić się na naszym produkcie, pyta: co ta osoba chciałaby osiągnąć, gdyby nasz produkt nie istniał? W tym kontekście nie nazywamy ich użytkownikami czy klientami.

Job map opisuje więc cele, które dana osoba chce osiągnąć w swoim życiu, niezależnie od technologii. To jest odmienna perspektywa, aczkolwiek obie są ważne. Ścieżka doświadczenia klienta – to wyjątkowo użyteczna technika, ale musimy być świadomi, że niesie ze sobą pewne uprzedzenia i założenia. Przede wszystkim, zakłada, że osoby, które obsługujemy, są naszymi klientami lub użytkownikami.

Z kolei job map nie zakłada niczego, ponieważ nie jest związana z konkretnym produktem. Jej celem jest opisanie ludzkiego zachowania. Obie perspektywy, mimo że różne, są ważne. Często porównuję je do opowieści zawartych na mapie – niezależnie od tego, czy jest to job map, czy mapa doświadczenia klienta, obie są mechanizmem narracji. Mówimy: mamy jednostkę – użytkownika lub klienta – i oto jest ich podróż. Mapa doświadczenia klienta i job map opowiadają jednak różne historie. Są to dwa odmienne podejścia, z których wynikają różne spostrzeżenia. To ważne, aby zdać sobie sprawę z tego, jak różne są możliwości wynikające z tych dwóch podejść.

Adam Michalski
Podczas tworzenia mapy podróży klienta (Customer Journey Map) lub mapy zadań (Jobs Map), nieodłącznym elementem jest przeprowadzenie wywiadów. Czy możliwe jest opracowanie uniwersalnego zestawu pytań do wywiadów, które umożliwiłyby jednoczesne tworzenie mapy podróży klienta i mapy zadań, czy też wymagane są do tego dwa odrębne badania?

Jim Kalbach
Pracowałem w zespołach produktowych i projektowych, gdzie nie zawsze miałem czas, budżet czy zasoby na przeprowadzenie pełnoprawnych projektów tworzenia map zadań (Jobs Map) lub ścieżek podróży klienta (Customer Journey Map). Musiałem zatem maksymalizować efektywność moich badań i działań projektowych.

Pomimo tego, nie jestem zwolennikiem łączenia tych dwóch aspektów w jednym wywiadzie. Jeżeli przeprowadzam rozmowę z kimś, nie chciałbym jednocześnie poruszać zagadnienia jakie zadania ma osoba do wykonania oraz jak ta osoba wykorzystuje nasz produkt. Dla mnie byłoby to nieco schizofreniczne – mój umysł miałby problem z przyswojeniem tak zróżnicowanych perspektyw. Uważam, że tak rozbieżne pytania mogą wprowadzić rozmówcę w stan dezorientacji.

W związku z tym, prawdopodobnie podjąłbym próbę oddzielenia tych rozmów. Najpierw dowiedziałbym się więcej na temat pracy, którą dana osoba wykonuje, a następnie przeniósłbym rozmowę na temat korzystania z naszego produktu. Raczej nie podejmowałbym obu tych tematów w trakcie jednej sesji.

Adam Michalski
Jakie są najlepsze metody prezentacji wyników badań? Czy masz jakieś praktyczne wskazówki?

Jim Kalbach
Myślę, że wiele pracy projektowej polega na ułatwianiu rozmów i tworzeniu zrozumienia między interesariuszami. Jako projektant lub badacz, często współpracujesz z menedżerami produktów, inżynierami, a także interesariuszami biznesowymi. W rzadkich przypadkach posiadasz pełną kontrolę nad projektem. Wszystko, czego nauczyłeś się na studiach UXD Product Design, ma swoje zastosowanie. Jednakże, kiedy ta wiedza jest stosowana w praktyce, rozmowy, które prowadzisz, stają się znacznie bardziej skomplikowane. Nie wystarczy jedynie doskonałe opanowanie rzemiosła projektowania, ale kluczowe staje się także umiejętność efektywnej komunikacji z różnymi interesariuszami.

Możliwe jest, że napotkasz na sceptycyzm wobec swoich badań, lub brak zainteresowania tym, co próbujesz osiągnąć. W takim kontekście, wymagane są silne umiejętności perswazyjne. Dużą część projektowania stanowi przekonywanie, komunikowanie i przekazywanie innym tego, co zaobserwowałeś. Czuję się uprzywilejowany jako projektant, ponieważ większość ludzi w organizacji nie ma możliwości bezpośredniej rozmowy z klientami, obserwowania, jak korzystają z produktu lub dyskusji na temat ich zadań do wykonania. Twoim zadaniem jest przekazanie tej zewnętrznej perspektywy do wnętrza organizacji.

Projektanci są świetni w obserwacji ludzi, ich potrzeb i interakcji. Musisz zabrać te obserwacje z powrotem do organizacji. Jednakże, nie możesz po prostu spisać 20-stronicowego raportu, ponieważ nikt go nie przeczyta. Zamiast tego, musisz zaangażować ludzi w rozmowę. Preferuję korzystanie z metod, ćwiczeń i aktywności, które pomagają ludziom samodzielnie dojść do wniosków. Zamiast świetnej prezentacji PowerPoint lub raportu, przeprowadź z ludźmi ćwiczenie i pozwól im powiedzieć: „Aha, rozumiem, o co ci chodzi, Jim”. O to właśnie chodzi w mojej innej książce, „Mapping Experiences”, a w pewnym stopniu także w „Jobs to be Done”. Widzę to jako narzędzia współpracy.

Informacje, które pojawiają się na mapie doświadczeń lub mapie zadań podczas ich tworzenia, nie zawierają gotowych odpowiedzi. Nie ma sytuacji, w której po stworzeniu mapy zadań, wszyscy ogłaszają: „OK, to nasza strategia na następny rok. Do dzieła, ludzie”. Odpowiedzi nie są podane na tacy. Musisz je wypracować ze swoim zespołem i ułatwić dialog. Jakie są Twoje przemyślenia na ten temat? Co wynika z badań? Co mówią pozostałe dane? Jak wygląda sytuacja finansowa? Jakie technologie są dostępne? Musisz dopasować te elementy tak, aby wszystko pasowało do siebie. Cały ten proces wymaga negocjacji w ramach rozmowy. W rzeczywistości, taka praca stanowi często 50% Twojego czasu, a czasem nawet więcej.

Zauważyłem, że „Jobs to be Done” nie zawsze jest pomocne. Stwierdziłem więc, zachowaj wszystkie swoje metody UX, mapowanie ścieżek klientów, persony, projektowanie marki, projektowanie skoncentrowane na człowieku i design thinking. Zatrzymaj to wszystko, ponieważ są to wartościowe narzędzia. Jobs to be Done pomogło mi jednak w stworzeniu bardziej przekonującej argumentacji. Ludzie mogą bowiem łatwo stwierdzić: „Tak, persony, nie wierzę w nie” i po prostu je odrzucić. Wtedy persony znikają, ponieważ ktoś tak postanowił. Z Jobs to be Done jest inaczej, trudniej je odrzucić, ponieważ metoda ta wywodzi się ze środowiska biznesowego.

Adam Michalski
Jeśli ktoś postanowi: „Dobrze, chcę wypróbować metodę Jobs to be Done w mojej organizacji, posiadam Twoją książkę, co powinienem zrobić, aby zacząć?

Jim Kalbach
W pewnym sensie dlatego napisałem tę książkę. Wiele dostępnych materiałów na temat „Jobs to be Done” ma charakter bardzo strategiczny i abstrakcyjny, a niekoniecznie operacyjny. Z drugiej strony, te bardziej operacyjne są często skomplikowane i trudne do powtórzenia, wymagają nawet do sześciu tygodni na ich wdrożenie.

Zauważyłem jednak w swojej pracy, jak również w literaturze, że istnieją pewne proste, indywidualne działania, które można podjąć. Właśnie te postanowiłem zgromadzić w mojej książce. Nie wymyśliłem żadnej z metodologii przedstawionych w „Jobs to be Done Playbook”. One już istniały. Ja po prostu je ze sobą połączyłem.

Uważam, że są dwa działania, które warto podjąć. Pierwszym i najważniejszym krokiem w stosowaniu „Jobs to be Done” jest stworzenie Job map. Wystarczy zdefiniować zadanie, które ma być wykonane, i identyfikować osoby, które mają je wykonać. Następnie przeprowadź rozmowy z sześcioma, ośmioma, czy nawet dwunastoma z nich i dowiedzieć się, jaki jest proces wykonania ich pracy. Chcesz zrozumieć chronologię wykonania tych zadań, niezależnie od technologii czy rozwiązań, i na tej podstawie stworzyć Job map.

Wielu technik prezentowanych w mojej książce wywodzi się właśnie z Job map. Zawsze możesz do niej wrócić i używać jako punkt odniesienia w innych działaniach. 

Niedawno przeprowadziłem takie działanie z zespołem w Mural. Stworzyłem Job map i zaprosiłem około dziesięć osób. Poprosiłem ich o wskazanie, gdzie według nich jest najtrudniej osiągnąć cel dla określonej grupy docelowej na Job map. To pomogło nam przeprowadzić prostą, ale skuteczną dyskusję.

Ważne jest, aby pamiętać, że tworzenie Job map staje się coraz prostsze z każdym podejściem. Gdy już opanujesz tę technikę, możesz ją realizować dość szybko. Jeśli jednak chcesz coś jeszcze prostszego, spróbuj napisać job story. Dowiedz się, gdzie leży problem osób, z którymi rozmawiasz, i zapisz ten problem jako job story, nie przywiązując się do żadnej technologii czy rozwiązania. Możesz skorzystać z formatu job story, który przedstawiam w mojej książce. W ten sposób, przed kolejnym sprintem, możesz mieć gotowe kilka job stories. Zastanów się nad swoimi badaniami, nawet jeśli nie są one przeprowadzone zgodnie z metodologią „Jobs to be Done”, spisz problem, który próbujesz rozwiązać, w formie job story. To może być dobry punkt wyjścia.

Adam Michalski
I zacznij rozmowę z programistami na temat problemu, który chcesz rozwiązać.

Jim Kalbach
Właśnie to daje Ci coś, co pozwala zmienić kierunek rozmowy. Ponieważ menedżerowie produktów będą się martwić o harmonogramy i reakcje rynkowe, inżynierowie będą się martwić o techniczną wykonalność, i zostajesz wciągnięty w tę rozmowę. Przeszedłem przez to, robiłem to przez całą swoją karierę. A potem prowadzisz rozmowę o technologii czy harmonogramach, a metoda „Jobs to be Done” pozwala Ci powiedzieć: „stop, jakie zadanie próbujemy rozwiązać, koledzy?” Czasami to właśnie tyle, to tylko rozmowa, która trwa 20 minut. Jakie zadanie staramy się wykonać? A tak przy okazji, mam te job stories, które napisałem. Co o nich sądzicie? Czy zgadzamy się, że to są zadanie, które użytkownik chce wykonać? Pozwala to zmienić kierunek rozmowy. Jeśli potrafisz to zrobić przy pomocy job stories, co moim zdaniem jest najprostszym sposobem, odniesiesz sukces. A następnym razem stwórz job map, potem przeprowadź ankietę dotyczącą oczekiwanych rezultatów, a kolejnym razem zajmij się bardziej strategicznymi zagadnieniami.

Adam Michalski
Jak sprawdzić, czy nasze działania przy tworzeniu „jobs stories” są skuteczne w organizacji z niską dojrzałością pod względem UX? Jakie wskazówki mogą nam pomóc?

Jim Kalbach
W książce poruszyłem ten temat, jednak gdybym miał okazję napisać jej uaktualnioną wersję, dodałbym tam kilka nowych elementów. Już teraz w niej można znaleźć pewne informacje na ten temat, ale są one ograniczone do zaledwie jednego zdania. Chciałbym poszerzyć temat walidacji oraz iteracji. Czasami oczekujemy, że metoda „Jobs to be Done” będzie przebiegać bardzo liniowo. Wybierasz zadanie, badasz je, następnie tworzysz Job map.. W rzeczywistości jednak, proces ten często przebiega iteracyjnie. Możesz zacząć od rozmowy z kilkoma osobami, aby sprawdzić, czy wybrane zadanie jest właściwe, zanim przystąpisz do jego badania.

Następnie przystępujesz do badań, przeprowadzasz trzy wywiady i zdajesz sobie sprawę, że musisz zmodyfikować swoje narzędzia badawcze, a właściwie wrócić i ponownie zdefiniować zadanie. Potem przeprowadzasz kolejne trzy wywiady, tworzysz job map, a następnie uświadamiasz sobie, że musisz wrócić i przeprowadzić więcej wywiadów. To nie jest proces liniowy, w którym „definiujesz zadanie, przeprowadżasz wywiady, a potem jest gotowe”. To cykl, w którym angażujesz wykonawców zadań, klientów czy jakkolwiek chcesz ich nazwać, osoby z rynku, którym chcesz służyć, i to moim zdaniem jest kluczowym elementem procesu walidacji. Jednym z atutów job map jest to, że po przeprowadzeniu iteracyjnych badań i stworzeniu modelu job map, który według Ciebie odzwierciedla sekwencję kroków niezbędnych do wykonania danego zadania, możesz wrócić do tych osób i pokazać im wyniki, pytając: „Czy ta mapa odzwierciedla kroki, które wykonujesz?

Co przeoczyłem? Gdzie jest dobrze, a gdzie źle?” A potem faktycznie ulepszasz swoją job map poprzez jej walidację. Job map to coś, co możesz wziąć i zweryfikować. To samo dotyczy job story. Możesz stworzyć kilka takich historii, a potem wrócić do osób, z którymi rozmawiałeś, aby uzyskać informacje na temat zadań, i zapytać: „Czy to rezonuje z Tobą? Czy coś pominąłem? Czy jest to coś, co mógłbyś sobie wyobrazić lub powiedzieć?” I wykorzystujesz to jako walidację. To nie jest prosta linia, to proces iteracyjny, w którym ciągle wracasz i sprawdzasz rzeczy. Ale dochodzisz do momentu, w którym przeprowadziłeś wystarczająco wiele badań i masz odpowiednią pewność jako badacz, że Twój model jest stabilny.

W pewnym momencie twoja job map przestaje ulegać zmianom, a twoje historie zadań również stają się stabilne. Być może nie osiągniesz 100-procentowej pewności. Ale w metodologii „Jobs to Be Done” dochodzisz do punktu, w którym jesteś pewien, że Twoja job map, twoje job stories lub jakiekolwiek inne techniki, które wykorzystujesz, są niezawodne i istotne. I gdy już osiągniesz ten punkt, utrzymanie go na długi okres staje się możliwe, ponieważ jedną z zalet metodologii „Jobs to Be Done” jest to, że rzadko ulega zmianom z biegiem czasu, ponieważ jest niezależna od technologii. Po stworzeniu mapy pracy lub historii zadań, możesz do nich wrócić po roku, po dwóch latach. Przyglądałem się nawet rzeczom sprzed pięciu lat i to nadal jest sposób, w jaki ludzie dzisiaj wykonują pracę. Staje się to bardzo stabilnym źródłem informacji z czasem. Możesz zmienić etykietę lub czuć się nieco inaczej odnośnie danego etapu pracy niż trzy lata temu. Ale jest ona w zasadzie ważna przez długi okres czasu.

Adam Michalski
Zastanawiam się, czy zaobserwowałeś jakieś zmiany w zakresie „Jobs to be done” spowodowane pandemią. Z pewnością obecnie zauważyliście w Mural ogromny wzrost liczby użytkowników. Czy sposób współpracy między nimi uległ zmianie?

Jim Kalbach
Nie sądzę, aby praca rzeczywiście uległa zmianie. Przed pandemią, patrząc na przykład na Mural, uważałem, że podstawowym zadaniem, które wykonujemy, jest wspomaganie zespołów w rozwiązywaniu problemów w sposób wizualny. I to nie uległo zmianie podczas pandemii. Myślę, że to, co się zmieniło, to okoliczności. „Jobs to Be Done” to ramy dla innowacji, które oparte są na ludzkich spostrzeżeniach i przekształcają je w możliwości. Robią to przy użyciu bardzo konkretnego języka. Ramy te stanowią podstawową kategoryzację. Bierzesz spostrzeżenie i umieszczasz je w kategoriach, a jedną z tych kategorii są etapy do wykonania, które stają się częścią job map. Inną kategorią są, jak nazywam je w książce, wyniki, czyli potrzeby ludzi. To właśnie sposób, w jaki ludzie mierzą sukces w realizacji zadania. 

Kolejną kategorią są czynniki emocjonalne i społeczne. Następna kategoria to, jak nazywam ją, okoliczności. Myślę jednak, że lepszym podejściem jest traktowanie tego jako czynników. Jakie są czynniki determinujące sposób, w jaki ktoś może wykonać daną pracę? I to, co uległo zmianie podczas pandemii, to raczej te czynniki. Muszę współpracować z zespołem, aby rozwiązywać problemy w sposób wizualny, prawda? A przed pandemią mogło to odbywać się głównie osobiście, z tylko kilkoma osobami pracującymi zdalnie. Wtedy zmieniającym się czynnikiem było to, że wszyscy zaczęli pracować zdalnie. Jednak praca pozostaje taka sama. Może też ulec zmianie sposób, w jaki ludzie priorytetowo traktują potrzeby. W związku z tym, gdy przed pandemią miałem pewne potrzeby podczas wykonywania tego zadania i układałem je hierarchicznie w określonym porządku, pandemia mogła sprawić, że zacząłem je inaczej hierarchizować, ponieważ okoliczności uległy zmianie. Mapa pracy i proces pozostają jednak dokładnie takie same. Chodzi o to, jak układam hierarchicznie potrzeby i jakie czynniki są teraz najważniejsze.

To koniec pierwszej części wywiadu. Drugą część wywiadu przeczytasz tutaj: Wywiad z Jimem Kalbachem część II – przyszłość UX znajdziesz w niej odpowiedzi na poniższe pytania:

Opublikowano

w

, ,

przez

Adam Michalski

Tagi:

, , , , , , , ,