Poniższy artykuł stanowi notatki z prezentacji Marca Stickdorna wygłoszonej podczas spotkania Service Design Network Dallas Chapter w kwietniu 2020 roku. Wszystkie obserwacje, przykłady i wnioski merytoryczne pochodzą od Stickdorna. Checklista, kluczowy insight i formatowanie to opracowanie redakcyjne na podstawie treści prezentacji.

TL;DR

Większość projektów wpływających na doświadczenie klienta pochodzi spoza działu designu: z IT, prawnego, operacji. Te zespoły podejmują decyzje bez myślenia o CX.
Journey Map Ops to system łączący hierarchię map podróży z codziennym zarządzaniem projektami w całej organizacji.
Trzy rodzaje map: warsztatowe (żyją tylko podczas sesji), projektowe (żyją podczas projektu), zarządcze (zawsze aktualne, połączone hierarchicznie).
Journey Map Coordinatorzy to rola mostkująca silosy. Koszt: dwa do czterech dni w miesiącu na osobę.
Councils to regularne spotkania, na których „ryba ląduje na stole”: ujawniają nakładki, konflikty i projekty, o których nikt nie wiedział.
Employee experience to najlepszy punkt wejścia dla service designu, bo daje natychmiastowy dostęp do badanych, danych i możliwości prototypowania.
ROI z service designu da się policzyć dla każdego projektu z osobna, co jest jedyną skuteczną odpowiedzią na pytanie o zwrot z inwestycji.

Dwa zespoły w tej samej firmie przez kilka miesięcy pracowały nad tym samym problemem, pod różnymi nazwami, bez wiedzy o sobie nawzajem. W efekcie zmarnowane zostały miliony. Marc Stickdorn, współautor This Is Service Design Doing i twórca oprogramowania Smaply, opisuje ten scenariusz jako typowy dla dużych organizacji i przedstawia konkretne rozwiązanie: Journey Map Ops.

Dlaczego agile w dużych organizacjach zazwyczaj nie działa?

Samo używanie słowa „sprint” nie czyni pracy iteracyjną. Schemat problemów jest powtarzalny: sprint zaczyna się dobrze, jednak potem pojawia się inny zespół z odmiennym zdaniem i zaczynają się spotkania wyrównawcze. Albo zaplanowane zasoby okazują się zajęte i projekt stoi. Albo nikt nie zapytał menedżera Mike’a. Finalny efekt pracy ląduje w czarnej dziurze.

Na poziomie całej organizacji sytuacja jest jeszcze bardziej złożona. Różne silosy używają różnych narzędzi, różnego języka i mierzą sukces innymi wskaźnikami. W rezultacie organizacja nie jest zorientowana na klienta, lecz na własne silosy.

Stickdorn stawia tu kluczowe pytanie: kto tak naprawdę wpływa na doświadczenie klienta? Odpowiedź jest niekomfortowa. Odpowiedzialne za to nie są głównie działy designu ani innowacji, lecz IT zmieniające oprogramowanie, prawny wdrażający nowe regulacje czy operacje modyfikujące procedury. Jako konkretny przykład Stickdorn wskazuje RODO: regulacja ta miała ogromny wpływ na doświadczenie klientów, jednak dział designu rzadko kiedy miał przy jej wdrożeniu cokolwiek do powiedzenia.

„Zastanów się, jakie projekty w organizacji wpływają na doświadczenie klienta. Tylko niewielki ułamek pochodzi od zespołu designu czy działu innowacji.„

Z tej obserwacji Stickdorn wyciąga wniosek, powołując się na Kim Goodwin: organizacje potrzebują decision system o wiele bardziej niż design system. Chodzi o to, by każda osoba podejmująca decyzję rozumiała jej wpływ na doświadczenie klienta lub pracownika, nie tylko specjaliści od projektowania.

Trzy rodzaje map, które warto rozróżnić

Zanim Stickdorn przechodzi do samego systemu, wskazuje na fundamentalne nieporozumienie widoczne u klientów: traktowanie wszystkich map podróży jako jednego narzędzia.

Mapy warsztatowe powstają podczas co-kreatywnych sesji z pracownikami lub klientami. Służą wyłącznie uczeniu się od uczestników. Po warsztacie robi się zdjęcie, wyciąga wnioski i na tym kończy. Mapa jako taka nie przeżywa sesji.
Mapy projektowe to żywe artefakty w ramach konkretnego projektu. Zaczynają od założeń, są walidowane przez badania, z czasem ewoluują do map opartych na danych. Łączą core team pracujący nad projektem, jednak zazwyczaj giną po jego zakończeniu i lądują w szufladzie.
Mapy zarządcze stanowią serce Journey Map Ops. Są zawsze aktualne, regularnie uaktualniane i mają inną strukturę niż projektowe. To na nich skupia się cały system.

Dwa wymiary dobrej mapy zarządczej

Stickdorn podkreśla dwie cechy decydujące o użyteczności mapy na poziomie zarządczym.

Hierarchia i zoom. Analogia pochodzi z kartografii: patrząc na całą planetę nie widzi się żadnych detali, natomiast po przybliżeniu widać konkretną ulicę. Mapy podróży działają tak samo. Na poziomie linii lotniczej pojawiają się etapy: dreaming, orientacja, rezerwacja, przygotowanie, lotnisko, lot. Każdy z nich można rozwinąć do oddzielnej mapy, gdzie lotnisko staje się przebiegiem trwającym kilka godzin, a wejście na pokład procesem zajmującym dwadzieścia minut. Każda mapa jest połączona z mapami wyżej i niżej w hierarchii, jednak do takiego linkowania potrzebne jest odpowiednie oprogramowanie.

Mapa doświadczenia, nie mapa touchpointów. Mapa touchpointów pokazuje wyłącznie miejsca, w których marka wchodzi w kontakt z klientem. To koncepcja z brandingu lat 90., która pomija istotny fakt: klienci mają życie poza byciem klientem danej marki. Mapa doświadczenia obejmuje natomiast pełny przebieg, włącznie z tym, co dzieje się poza touchpointami. Dopiero taki obraz pozwala zrozumieć, w jakim kontekście klient trafia do organizacji i co robi po kontakcie z nią.

Jak działa Journey Map Ops w praktyce

System opiera się na trzech elementach: hierarchii map, roli koordynatorów i regularnych radach. Stickdorn umieszcza Journey Map Ops w szerszym kontekście: narzędzie to ma łączyć Design Ops, Research Ops i Dev Ops, czyli trzy ruchy rozwijające się równolegle w organizacjach technologicznych, które jednak rzadko ze sobą współpracują.

Hierarchia map

Organizacja buduje drzewo map: od „customer lifecycle” na samym szczycie, przez mapy poszczególnych etapów, aż do mikrointerakcji na dole. Każdy poziom jest powiązany z poziomami wyżej i niżej. Stickdorn zaleca przypisanie tej hierarchii do struktury organizacyjnej: od osoby najwyżej odpowiedzialnej za CX (idealnie CXO, choć nie każda organizacja taką rolę posiada) aż do wyspecjalizowanych zespołów.

Journey Map Coordinatorzy

Jest to nowa rola, nie pełnoetatowa. Stickdorn szacuje nakład pracy na dwa do czterech dni w miesiącu. Zadanie koordynatora polega na rozmowach z ludźmi z innych działów, wykrywaniu projektów mogących wpływać na doświadczenie w danym obszarze mapy oraz jej aktualizowaniu. W ten sposób koordynatorzy budują mosty między silosami, a informacja przepływa w górę hierarchii: od mikrointerakcji aż do mapy customer lifecycle.

Co widać na mapie zarządczej?

aktualne, planowane i historyczne projekty
powiązania ze starszymi mapami projektowymi i ich danymi badawczymi, co pozwala nie wymyślać koła na nowo
KPI: Stickdorn rekomenduje trzy do czterech wskaźników na mapę, zamiast jednego globalnego
pain pointy klientów i pracowników, powiązane z danymi na żywo z systemu ticketingowego

Dzięki temu koordynator widzi, który pain point generuje aktualnie największą liczbę zgłoszeń, jak często występuje i ile kosztuje organizację. Priorytety przestają być subiektywne.

Councils: spotkania, na których ryba ląduje na stole

Koordynatorzy spotykają się regularnie. Częstotliwość zależy od branży i tempa pracy: producenci samochodów robią to kwartalnie, większość klientów Stickdorna raz w miesiącu, natomiast firmy softwarowe i startupy co tydzień lub co dwa tygodnie, w rytmie sprintów.

Stickdorn przywołuje tu skandynawskie powiedzenie: ryba musi leżeć na stole, bo schowana pod spodem zaczyna śmierdzieć. Na radach wychodzą zatem rzeczy, których nikt wcześniej nie widział:

nakładki między projektami: dwa zespoły robiące to samo pod różnymi nazwami
konflikty: projekt A, który rozwiązuje problem stworzony przez projekt B
projekty niepowiązane z żadnym realnym pain pointem klientów ani pracowników
projekty wynikające wyłącznie z decyzji kierownictwa, bez podstaw w danych

Pierwsze spotkania bywają bolesne. Jeden z klientów Stickdorna zadzwonił po pierwszej radzie z pytaniem, czy to normalne czuć się do niczego. Odpowiedź była twierdząca, bo właśnie odkryli, że dwa zespoły pracowały nad tym samym problemem przez kilka miesięcy bez wiedzy o sobie. Jednak świadomość problemu to pierwszy krok do jego rozwiązania.

Trzy problemy, które Journey Map Ops rozwiązuje

Stickdorn wskazuje trzy systemowe problemy dużych organizacji, które ten system rozwiązuje bezpośrednio.

Różny język. Różne działy nazywają te same rzeczy inaczej. Journey Map Ops wymusza wspólny język przez wspólny artefakt: mapę.
Różne narzędzia. System wymaga zgody na jedno narzędzie do mapowania w całej organizacji. Stickdorn przyznaje, że można to zrobić nawet w Excelu, choć tego nie rekomenduje. Narzędzie nie jest najważniejsze.
Brak wspólnej perspektywy. Różne silosy mierzą sukces innymi KPI, dlatego Journey Map Ops narzuca jedną perspektywę: klienta lub pracownika. W rezultacie organizacja przestaje być zorientowana na silosy i zaczyna być zorientowana na doświadczenie.

Jak sobie radzić z HiPPo?

HiPPo (Highest Paid Person’s Opinion) to klasyczny problem: ktoś wysoko w hierarchii podejmuje decyzję sprzeczną z danymi. Journey Map Ops tego nie eliminuje, jednak sprawia, że staje się to widoczne dla wszystkich.

Jeśli ranking największych pain pointów klientów i pracowników nie pokrywa się z listą aktualnych projektów, każdy to widzi. Decyzja podjęta wbrew danym nie znika, ale jej koszt staje się jawny. Stickdorn zaznacza przy tym, że jest miejsce na wizjonerskie decyzje kierownictwa. Problem pojawia się dopiero wtedy, gdy takie decyzje obejmują całą listę projektów. Nigdy nie warto wkładać wszystkich jajek do jednego koszyka.

Dlaczego zacząć od employee experience, nie od klientów?

Według Stickdorna największym sojusznikiem we wprowadzaniu service designu do organizacji jest HR. Projekty z obszaru doświadczeń pracowniczych mają cztery przewagi nad projektami skierowanymi na zewnątrz:

Badania: wystarczy wiadomość na Slacku, bez rekrutacji uczestników i budżetu.
Dane: HR przeprowadza regularne badania satysfakcji i zna największe pain pointy pracowników.
Prototypowanie: testowanie odbywa się wewnątrz organizacji, bez logistyki i dodatkowych kosztów.
Problemy: są przewidywalne, jak rezerwacja sali czy rozliczenie podróży służbowej. Wydają się błahe, jednak są powszechne i realne.

Rozwiązanie jednego z takich problemów i pokazanie ROI sprawia, że pracownicy na własnej skórze przekonują się, że to samo podejście można zastosować wobec klientów zewnętrznych.

Jak wyliczać ROI z service designu?

Pytanie o zwrot z inwestycji w service design Stickdorn uważa za źle postawione. Nie pyta się przecież o ROI z zarządzania w ogóle ani z marketingu jako dyscypliny. Zamiast tego marketerzy pokazują wyniki konkretnych kampanii, a service design powinien robić to samo.

Przykład z prezentacji: projekt rozwiązuje problem generujący zgłoszenia do supportu.

Zapytaj dział supportu, ile czasu zajmuje obsługa jednego zgłoszenia dotyczącego tego problemu.
Pomnóż przez liczbę zgłoszeń miesięcznie.
Pomnóż przez koszt godziny pracy supportu.
Wynik to koszt problemu w skali miesiąca i roku.
Po rozwiązaniu problemu różnica stanowi ROI projektu.

Kluczem jest jednak mierzenie od pierwszego projektu, zanim ktokolwiek zacznie pytać o uzasadnienie.

Jak wprowadzić service design do organizacji bez buy-inu?

Punktem wyjścia jest diagnoza: skuteczne wdrożenie wymaga zarówno wsparcia z góry, jak i ludzi gotowych pracować w nowy sposób. Zamiast debatować, który kierunek jest ważniejszy, warto zidentyfikować, czego brakuje i od tego zacząć. Stickdorn zwraca uwagę, że „budżet” często nie oznacza pieniędzy: najczęstszym deficytem jest czas, nie finansowanie.

Nie pokazuj przykładów z Google ani Airbnb. Każda organizacja usłyszy „u nas jest inaczej” i będzie miała rację.
Zacznij od stealth projects. Małe projekty z niecharakterystycznymi nazwami, np. „optymalizacja procesu X”, pozwalają eksperymentować i dopasowywać service design do kultury organizacji bez wzbudzania oporu.
Licz ROI od pierwszego projektu. Twarde liczby otwierają rozmowę o metodzie, która za nimi stoi.

Co jest najbardziej niedocenione i najbardziej przereklamowane?

Najbardziej niedocenione: prototypowanie. Organizacje zaczęły rozumieć wartość badań, jednak prototypowanie wciąż bywa niedostatecznie doceniane. Problem jest wizerunkowy: kiedy dobrze opłacany zespół bawi się klockami Lego lub kartonami, a do pokoju wchodzi senior management, obserwuje grupę ludzi, która wydaje się nie pracować. Jedynym skutecznym remedium są case studies, przykłady i wyliczenia ROI.

Najbardziej przereklamowane: canvasy. Jest ich zbyt wiele, a Stickdorn przyznaje, że sam ponosi część odpowiedzialności za ten stan. Canvasy dobrze sprawdzają się do nauki i na etapie startu projektu, jednak nie do każdego zadania potrzebny jest canvas, podobnie jak nie do każdego problemu potrzebna jest aplikacja. Spośród nich Stickdorn wyróżnia Business Model Canvas jako narzędzie nadal wartościowe: proste, oparte na badaniach i faktycznie łączące różne perspektywy.

Dlaczego focus grupy są słabą metodą badawczą?

W sesji focus group brakuje boundary object, czyli artefaktu tłumaczącego między różnymi sposobami myślenia. Przykładem takiego obiektu jest właśnie mapa podróży: kiedy powstaje wspólnie z uczestnikami, sesja przestaje być focus groupą i staje się warsztatem co-kreatywnym, dającym zupełnie inne wyniki.

W klasycznej focus grupie, nawet z doświadczonym moderatorem, ujawniają się znane błędy poznawcze: uczestnicy podążają za najmocniejszą opinią, mówią to, co jest społecznie akceptowalne i deklarują jedno, robiąc drugie. Stickdorn powołuje się na badania Harvard Business School pokazujące, że wyniki focus grup wykazują zadziwiającą zbieżność z tym, co zamawiający chciał potwierdzić.

Miro czy Smaply? To zależy od celu

Narzędzia do whiteboardingu, takie jak Miro, Mural czy Lucidchart, służą do co-kreatywnych warsztatów: wielu uczestników pracuje jednocześnie na jednym canvasie, z pełną elastycznością. Jest to właściwe środowisko do zdalnych sesji badawczych i warsztatów projektowych. Natomiast specjalistyczne oprogramowanie do mapowania, jak Smaply, ma inny cel: standaryzację i skalowanie. Pozwala linkować mapy ze sobą, budować hierarchię, eksportować prezentacje i pracować z mapami innych zespołów czy agencji.

Najczęstszy błąd, który Stickdorn obserwuje u klientów: porównywanie tych dwóch kategorii narzędzi jako alternatyw. Pytanie „Miro czy Smaply?” jest tyle samo warte co pytanie „hammer czy śrubokręt?”. Oba są potrzebne, jednak do różnych celów.

Lumpers vs splitters: dlaczego etykiety nie mają znaczenia

Adam Lawrence, jeden ze współautorów This Is Service Design Doing, dzieli ludzi na dwie grupy: splitters szukają różnic między podejściami, natomiast lumpers szukają podobieństw. Stickdorn identyfikuje się z tą drugą grupą.

Dla niego service design, design thinking, UX design, human-centered design, experience design i customer experience management to w gruncie rzeczy te same aktywności pod różnymi nazwami. Dlatego szukając miejsca dla service designu w organizacji, warto nie ograniczać się do działów o tej konkretnej nazwie, lecz identyfikować kieszenie, które robią podobne rzeczy pod innymi szyldami, i łączyć je ze sobą.

Stickdorn przywołuje konkretny przykład z Austrii. Kraj ten był pierwszym na świecie, który wprowadził service design do curriculum szkół średnich. Jednak przy nazewnictwie przedmiotu świadomie zrezygnowano z terminu „service design” na rzecz „zarządzania serwisem i biznesem, w tym service design”. Powód jest prosty: większość ludzi słysząc „service design” automatycznie składa dwa słowa. Service kojarzy się z obsługą klienta, design z estetyką. W efekcie „service design” jest rozumiany jako „estetyka sposobu, w jaki kelner przynosi kawę”, co zupełnie mija się z rzeczywistością.

Checklista: wdrożenie Journey Map Ops

Opracowanie redakcyjne na podstawie prezentacji. Nie wszystko musi być wdrożone jednocześnie.

Hierarchia map

[ ] Zidentyfikuj najwyższy poziom mapy w organizacji (customer lifecycle lub odpowiednik)
[ ] Rozpisz kolejne poziomy hierarchii aż do mikrointerakcji istotnych dla danego kontekstu
[ ] Wybierz jedno narzędzie do mapowania jako standard dla całej organizacji
[ ] Połącz mapy ze sobą tak, by można było przechodzić między poziomami szczegółowości
[ ] Upewnij się, że mapy pokazują pełne doświadczenie klienta, nie tylko touchpointy organizacji

Journey Map Coordinatorzy

[ ] Przypisz koordynatora do każdego poziomu hierarchii
[ ] Zakomunikuj nakład pracy: dwa do czterech dni w miesiącu
[ ] Określ zakres: z jakimi działami koordynator kontaktuje się regularnie
[ ] Ustal format aktualizacji mapy po każdym cyklu

Councils

[ ] Zdecyduj o częstotliwości spotkań (kwartalnie, miesięcznie, co dwa tygodnie)
[ ] Ustal strukturę spotkania: kto prezentuje, co jest na agendzie
[ ] Dodaj do mapy zarządczej KPI: trzy do czterech na mapę, nie jeden globalny wskaźnik
[ ] Podłącz pain pointy do danych na żywo (np. system ticketingowy supportu)
[ ] Przygotuj zespół na to, że pierwsze spotkanie ujawni niekomfortowe informacje. To dobry znak.

Checklista: liczenie ROI z projektu service design

Opracowanie redakcyjne na podstawie prezentacji.

Przed rozpoczęciem projektu

[ ] Zidentyfikuj konkretny pain point, który projekt ma rozwiązać
[ ] Znajdź mierzalny wskaźnik powiązany z tym pain pointem (liczba zgłoszeń, czas obsługi, wskaźnik błędów, czas onboardingu)
[ ] Zapisz wartość bazową wskaźnika przed startem projektu
[ ] Oblicz koszt problemu: liczba zdarzeń × czas obsługi × koszt godziny pracy

Po zakończeniu projektu

[ ] Zmierz ten sam wskaźnik po wdrożeniu
[ ] Oblicz różnicę i przelicz na wartość finansową
[ ] Udokumentuj nakłady: czas zespołu, narzędzia, koszty zewnętrzne
[ ] Wylicz ROI: (wartość uzyskana minus koszt projektu) / koszt projektu × 100%

Jak używać wyników

[ ] Zestawij trzy najlepsze projekty z ostatniego roku z ich ROI
[ ] Zestawij trzy projekty z najniższym ROI i wyciągnij wnioski
[ ] Gdy pojawi się pytanie o ROI z service designu w ogóle, odpowiedz tym zestawieniem

Podsumowanie

Journey Map Ops odpowiada na konkretny problem: organizacje pracują w silosach, nie widzą własnych nakładek i sprzeczności, a większość decyzji wpływających na CX zapada poza działem designu.

System działa, gdy istnieje hierarchia połączonych ze sobą map, koordynatorzy odpowiedzialni za każdy poziom oraz regularne councils, przez które informacja przepływa między silosami. Dane powiązane z realnymi KPI i pain pointami zastępują w tym układzie subiektywne priorytety.

Narzędzie do realizacji nie jest kluczowe. Łączyć mapy można nawet w Excelu, choć dedykowane oprogramowanie znacząco upraszcza pracę.

Najważniejsza zmiana ma jednak charakter mentalny. Mapa podróży przestaje być artefaktem projektu i staje się infrastrukturą zarządczą.

Kluczowy insight

Opracowanie redakcyjne na podstawie prezentacji.

Dział designu najmniej wpływa na CX

Standardowo myślimy: żeby poprawić doświadczenie klienta, należy wzmocnić dział designu lub UX, bo tam koncentruje się odpowiedzialność za CX.

W praktyce okazuje się, że: zdecydowana większość projektów realnie zmieniających doświadczenie klienta pochodzi z działów IT, prawnego, operacji i finansów. Ludzie w tych działach codziennie podejmują decyzje, które bezpośrednio trafiają w klienta, nie dysponując przy tym żadnym frameworkiem do oceny ich wpływu na CX. Jak wynika z prezentacji, organizacje potrzebują decision system o wiele bardziej niż design system.

Dlaczego to jest istotne: inwestowanie wyłącznie w kompetencje jednego działu pozostawia bez narzędzi dziesiątki osób, które na co dzień kształtują doświadczenie klientów. Nawet najlepiej zaprojektowany interfejs nie zmieni sytuacji, jeśli regulamin jest pisany pod kątem ochrony firmy, a nie zrozumienia przez użytkownika.

Test na jutro: zamiast pytać „co możemy zaprojektować?”, zapytaj „kto w naszej organizacji w tym tygodniu podjął decyzję, która wpłynęła na klienta, nie myśląc o kliencie?”. Wpisz trzy pierwsze odpowiedzi i sprawdź, z jakich działów pochodzą.

Źródło: prezentacja Marca Stickdorna na Service Design Network Dallas Chapter, 21 kwietnia 2020. Marc Stickdorn jest współautorem „This Is Service Design Thinking” (2010) i „This Is Service Design Doing” (2018) oraz współtwórcą oprogramowania Smaply.

Tag: Mapy Podrozy Klienta

Journey Map Ops: jak zamienić mapę podróży klienta w system zarządzania organizacją #EN384