czyli Kapitan UX vs Żelazny PM

Postęp technologii sprawi wkrótce, że będziemy tworzyć super projektantów i super Product Managerów niczym super żołnierzy w komiksach.

Już teraz możecie przeczytać o przygodach Kapitana UX’a i Żelaznego PM’a. Jako pretekst do porozmawiania o roli UX Designera, Product Managera i osób, które są ich sprzymierzeńcami posłuży nam luźna inspiracja filmem: “Kapitan Ameryka. Wojna bohaterów”.

I Ty młody UX Designerze, a także i Ty młoda Product Managerko możesz wyciągnąć właściwe wnioski dla siebie z tej opowieści. Poznaj co może ci grozić, a także dowiedz się, kto może być twoim sprzymierzeńcem…

Zapraszamy do obejrzenia filmu Tomasza Rybaka:

lub do przeczytania artykułu poniżej – dla każdego coś dobrego 😉
Wracając do fabuły – najpierw parę słów o bohaterach…

Kapitan UX

Posiada tarczę i nadludzkie moce, dzięki czemu jest ucieleśnieniem obrońcy użytkowników. Początkowo nie może zaciągnąć się do firmy z powodu słabego przygotowania do rozmowy kwalifikacyjnej. Ale potem bierze udział w tajnym eksperymencie i staje się super projektantem.

W końcu dostaje wymarzoną pracę.Kapitan UX wielokrotnie walczy o interesy użytkowników, na czym dobrze wychodził firma.
Zachowuje anonimowość. Tylko wybrani ludzie z branży znają jego prawdziwą tożsamość.

Żelazny PM

Superbohater, który nie dysponuje nadludzką siłą, ale radzi sobie dzięki ultranowoczesnym technologiom. Ma wspaniałą zbroję, jest chroniony przez Zarząd. Często lata po firmie i poza nią, potrafi wszystko załatwić.

Jak mało kto umie zarządzać ludźmi. Dba o to, aby firma realizowała świetne produkty i zarabiała kokosy. Nie ukrywa swojej tożsamości, wręcz przeciwnie, lubi skupiać uwagę na swojej osobie.

Co ich łączy?

Pracują w jednej super organizacji, dla której od lat tworzą cyfrowe produkty. Stanowią najlepszy zespół na świecie. Wiedzą, że nie da się przekonać wszystkich użytkowników do korzystania z ich produktu, ale nie odpuszczają.

Chcą uchronić firmę przed totalną zagładą i zapewnić klientom bezkresne szczęście. Zawsze mają na uwadze cele użytkowników, chcą pomagać ludzkości rozwiązywać ich problemy.
Wielokrotnie ze sobą współpracują ratując firmę przed złowrogą konkurencją i upadkiem firmy.

Tym razem będą musieli stawić czoła sami sobie…

Co ich dzieli?

Pomaganie ludzkości według Zarządu polega na tym, aby wszyscy stali się ich klientami, dzięki czemu firma będzie zarabiała kupę forsy. To jest ich główny cel biznesowy.
Nie podoba im się samowola zespołu. To oni chcą rządzić światem i firmą. Początkowo nazwali się HYDRA, ale okazało się, że już ktoś korzysta z tego akronimu i nie mają do tego wykupionych praw. Dlatego nazwali się HIPPO od skrótu: „Highest Paid Person’s Opinion”. Chodzi im o to, aby przywrócić zasadę, że o produkcie decydują osoby najlepiej zarabiające w firmie.

Zdołali wpłynąć na decyzje Żelaznego PM, który jest przecież odpowiedzialny za sukces produktów na rynku. Omotali go swoimi wątpliwościami, wywierali presję czasową…
Żelazny PM zdaje sobie sprawę, że musi patrzeć na tworzenie produktów pod kątem realizowania biznesowych celów firmy, jej misji i strategii.

Kapitan UX ma tymczasem na uwadze głównie cele użytkowników, klientów korzystających z produktu. Te cele mają móc realizować użytkownicy, a całe doświadczenie ma być pozytywne.
UX wychodzi z założenia, że jeśli oni będą zadowoleni z produktu, to się to przełoży na cele biznesowe.

Choć to PM jest odpowiedzialny zwykle za ustalenie priorytetów, ustalenie roadmapy, to te kwestie często są konsultowane z zespołem IT i na tym poziomie akceptowane. Czasem jednak UX designer może mieć inną perspektywę – perspektywę klienta, która różni się od potrzeb biznesu.

Okazuje się, że Żelazny PM od jakiegoś czasu zawiera ze wszystkimi kompromisy. Na przykład podejmuje decyzję, że zespół IT nie zaimplementuje tzw. „empty states”, czyli pustych ekranów przygotowanych dla świeżo zarejestrowanych użytkowników, bo nie ma na to czasu.

Później akceptuje, że nie zaimplementują także procesu onboardingu, bo przecież tego i tak nikt nie czyta.

Front end deweloperzy zmieniają ikonki zaprojektowane zgodnie ze style guide, na rzecz takich, jakie im się podobają – bo każdy w zespole jest projektantem.
I tak dalej, jest tego więcej…

Po złożeniu do kupy tych wszystkich, wydawałoby się drobnych elementów, okazuje się, że użytkownicy nie wiedzą co robić.

Podnosi się bunt deweloperów, którzy twierdzą, że Kapitan UX źle projektuje.
Firma nie zdobywa tylu klientów, ilu zakładano tworząc roadmapę. Wcześniejsi klienci są coraz bardziej rozczarowani zmianami i rezygnują z usług.

Tymczasem Kapitan UX widzi problemy i potrzeby zwykłych użytkowników. Wie, że prawdziwym problemem jest nietrafiony model biznesowy i błędne decyzje. Kapitan czuje się upokorzony. Nie był świadomy, jak inni ingerują po drodze w projekt, że każdy, zamiast dokładać kolejną cegiełkę, narusza fundament konstrukcji projektu i wszystko się wali.
Mimo woli konflikt się rozwija. Żaden z bohaterów nie chce ustąpić. Każdy chce bronić własnej wizji firmy do utraty tchu.

Kto nas wspiera?

Ani Kapitan UX, ani Żelazny PM nie są jednak sami. Obaj mogą liczyć na pomoc przedstawicieli innych zespołów wewnątrz firmy. Bo to, że klienci są mega wsparciem, to chyba oczywiste?

1. Biuro Obsługi Klienta

Ta grupa ludzi jest często niedoceniana, a ma znaczący wpływ na doświadczenia użytkownika związane z produktem. Pamiętam sytuację, kiedy chciałem zgłosić kilka błędów UX na stronie jednej z firm. Jedyne co mogłem zrobić to napisać wiadomość, potem oddzwoniono do mnie i niestety pracownik nie był w stanie skontaktować się ani z działem IT tej firmy, ani z reprezentantem działu UX. Nawet nie wiedział czy ktoś o takim zawodzie u nich pracuje. Powiedział, że oni nie mają kontaktu z innymi działami firmy. Brak kompleksowego podejścia do rozwiązywania problemów i podział na tzw. silosy występuje bardzo często w dużych firmach.

Tymczasem Twoim naturalnym źródłem pomocy jako UX’a (a także Product Managera) jest właśnie Biuro Obsługi Klienta czy Zespół Wsparcia. Pracownicy tego działu na co dzień mają do czynienia z problemami użytkowników i są naprawdę świetnym źródłem wiedzy. Poważnym błędem wielkich firm jest wydzielenie tego działu i blokowanie komunikacji z działem szeroko pojętego designu czy produktu. Nie należy traktować poszczególnych działów w firmie jakby były samotnymi wyspami. Firma to system naczyń połączonych, pracownicy powinni mieć świadomość, kto za co odpowiada, komu można zgłosić dany problem. Bug na stronie dodany jako ticket dla IT, to nie to samo, co błąd użyteczności.

Żeby jednak nie było tak idealistycznie, to muszę jednak przestrzec, że nie należy realizować na ślepo wszystkich pomysłów Supportu. Nie przesadzajmy. Część pomysłów należy odrzucić, o ile nie wnoszą realnych korzyści. Poza tym, teoretycznie może się zdarzyć, że trafisz też czasem na sfrustrowanych pracowników, którzy mogą mieć niezbyt obiektywny punkt widzenia. Jest to spowodowane tym, że mają do czynienia głównie z problemami (być może słabsze zarobki też mają wpływ).

Nieraz mogłem liczyć na to, że kierownik supportu był tak zaangażowany w pracę, że nawet po godzinach przygotowywał mi listę największych problemów, które kradną czas jego zespołowi. Jeśli naprawdę pomożesz rozwiązać problemy Biura Obsługi Klienta, to wierz mi, że będą chcieli z Tobą dalej współpracować.
Jeśli UX we współpracy z Product Managerem rozwiąże problemy użytkowników, to rozwiązuje także problemy zespołu wsparcia.

Przeanalizuj też czat firmowy, jest to świetny materiał do optymalizacji i poprawek.

2. Dział Sprzedaży

Inny niedoceniany zespół pracowników stanowi dział sprzedaży. Ci pracownicy mają także bezpośredni kontakt z klientami i znają wiele bolączek. Wiedzą z czego ludzie nie są zadowoleni, znają świetnie produkty konkurencji, wiedzą, co jest warte pozostawienia, a co koniecznie trzeba dostosować do oczekiwań klientów.

Zespół sprzedaży może wesprzeć tworzenie produktów. Poza tym, mogą pomóc przy podejściu Customer Development. Kto, jak nie oni, zbuduje bazę klientów z prawdziwego zdarzenia? Mogą pomóc z ankietami dla klientów biznesowych, może nawet przeprowadzą wywiady z klientami.

3. Deweloperzy

Programiści chcą budować świetne produkty. Wielu z nich nie ma oporów, by powiedzieć otwarcie, że ktoś podjął ich zdaniem błędną decyzję. Myślą bardzo logicznie i precyzyjnie, idą krok po kroku bez przeskoków, jak to mają niektórzy projektanci (takie są moje obserwacje, nie oznacza, że wszyscy tak mamy). W końcu znajdują luki, których nikt wcześniej nie wziął pod uwagę. Nie ma sensu obruszać się na ich uwagi.

Ważne jest słuchanie opinii innych ludzi. Nie zawsze ich obawy mają uzasadnienie, bo nie ma oczywiście osób, które nigdy się nie mylą.

Czasami ograniczenia technologiczne sprawiają, że mała zmiana powoduje duże problemy. Raz np. chciałem dodać w interfejsie jeden mały element, ale ilość zmian po stronie backendu byłaby zbyt pracochłonna. Logika była przygotowana według innych założeń. Po rozmowie z jednym z programistów znalazłem inny sposób na to, aby użytkownik mógł zrealizować cel i jednocześnie aby ta zmiana była prosta w realizacji i nie zaburzała logiki działania systemu.

Część programistów poważnie myśli nad własnym biznesem. Są pełni pomysłów i mówiąc potocznym językiem – mają łeb na karku. Pamiętam, jak podczas moich pierwszych kroków jako UX byłem zdziwiony, jak bardzo część programistów rwała się do przeprowadzania testów z użytkownikami. Nagrywali sesje i notowali uwagi – naprawdę wykonywali kawał dobrej roboty. Dobrze jest pielęgnować wsparcie i krzewić nastawienie na badania w firmie.

4. Testerzy

Po realizacji implementacji po stronie deweloperów warto, aby testerzy zwrócili także uwagę na kwestie związane z szeroko pojętym designem. Oczywiście nie mają wyręczać UXa, ale mogą pomóc w sprawdzeniu, czy produkt działa zgodnie z założeniami i czy interfejs wygląda tak, jak został zaprojektowany.

Testerzy, gdy biorą udział w projekcie od początku, znają jego założenia, stanowią naprawdę cenną pomoc dla projektanta doświadczeń użytkowników.

Sceny walki

Niestety mój budżet na efekty specjalne wynosi zero złotych, więc muszę Was poprosić o użycie własnej wyobraźni. Kapitan UX tłucze się z Żelaznym PM, w rozróbie biorą też udział inni pracownicy.

Słychać łubudubu, brzdęk i bam!
A potem ratatata, ziuuum i pac!

Jak to bywa z chłopakami, gdy dali sobie po gębie, to zaraz się pogodzili i zostali najlepszymi przyjaciółmi.

Jak uniknąć konfliktów?

Co zrobić, aby uniknąć wspomnianych konfliktów pomiędzy UX Designerem a Product Managerem i tworzyć jeszcze lepsze produkty?

Przydatna jest tzw. inteligencja emocjonalna. Nie będę teraz wchodził w szczegóły, ale chodzi o związane z tym kompetencje takie jak: współpraca, przywództwo, empatia, asertywność, samoświadomość, perswazja, motywacja czy zdolności adaptacyjne. Może zrobię na ten temat kiedyś odcinek. Na pewno jest to bardziej praktyczne podejście niż abstrakcyjny iloraz inteligencji, i testy z tym związane, które ponoć są wykorzystywane, o zgroza w procesach rekrutacyjnych.

Poza tym na pewno warto schować ego do kieszeni. I szlifować swoje umiejętności miękkie, bo w tego typu stanowiskach są niezwykle przydatne.

Pomocne będzie także dokładniejsze określenie zakresu obowiązków, żeby było nie było wątpliwości, kto za co odpowiada. Niekonieczne trzeba się trzymać w tej kwestii schematów. Jeśli PM robi świetne wywiady z użytkownikami i lubi to robić, to dlaczego ma się tym nie zająć, jeśli wymaga tego sytuacja?

Warto zadbać o szczerość i respektowanie drugiej strony. Wiele można załatwić twarzą w twarz, tylko najważniejsze kwestie udokumentować lub zostawić ślad po spotkaniu w postaci e-maila.

Post scriptum

Wszystkie wydarzenia i osoby zostały zmyślone. W trakcie pisania nie ucierpiał nikt o zdrowych zmysłach…