Dlaczego brak product value niszczy współpracę Product Ownera i UX Designera?

Dobra współpraca Product Ownera (lub Product Managera) i UX Designera zaczyna się od jednego, absolutnie najważniejszego elementu: zdefiniowania i zakomunikowania product value. To najważniejszy składnik całego procesu projektowego - bez niego każda kolejna decyzja projektowa, techniczna czy biznesowa staje się spekulacją. 

Projektowanie UX to nie tylko makiety, to także dogłębne zrozumienie wizji produktu, którą PO powinien jasno przekazać zespołowi. UX Designer nie może trafnie zaprojektować ścieżek użytkownika, jeśli nie wie, jaki cel produkt ma realizować.  Architekt nie zaprojektuje dobrej struktury, jeśli nie zna założeń, jakie produkt ma realizować. Nawet dobrze skonstruowany backlog produktu nie obroni się, jeśli nie prowadzi do czegoś konkretnego.

Brak product value nie jest małym błędem do poprawki - jest punktem krytycznym, który zagraża całemu produktowi.

Zadaniem właściciela produktu jest nie tylko zarządzanie priorytetami, ale przede wszystkim stworzenie wspólnego kontekstu, czyli odpowiedzenie na pytania: dla kogo tworzymy, po co, i jak poznamy, że nam się udało. Tylko wtedy UX może świadomie dobierać komponenty, proponować ścieżki i przewidywać ryzyka. Tylko wtedy architekt systemu wie, co naprawdę budujemy. Tylko wtedy zespół działa w tym samym kierunku.

Zespoły, które mają jasno określoną product value, podejmują lepsze decyzje i zwyczajnie pracuje im się łatwiej. W BB8 staramy się iść o krok dalej - nie tylko oddawać makiety, ale też wychwytywać błędy, sugerować zmiany i pokazywać, co może nie zadziałać. Nie dlatego, że ktoś tego od nas oczekuje, tylko dlatego, że wiemy, jak bardzo to wpływa na jakość produktu. Coraz częściej pomagamy zespołom wdrażać model Product Trio, w którym PO, UX i Tech Lead działają jako równorzędni partnerzy w definiowaniu wartości produktu. Ten sposób pracy znacząco skraca pętlę decyzyjną i eliminuje nieporozumienia wynikające z braku wspólnego kontekstu.

Kolejne problemy we współpracy na linii PO - UX może nie są tak fundamentalne jak brak product value, ale często są właśnie konsekwencją jego braku. 

Ignorowanie wyników badań UX - częsty błąd Product Ownerów

Zdarza się, że Product Owner zamawia badania UX, uczestniczy w nich, dostaje wynik i nic się dalej nie dzieje. Wnioski trafiają do raportu, który ląduje na dysku, a decyzje produktowe i tak podejmowane są według wcześniejszych założeń. A to właśnie w tym miejscu rola Product Ownera wymaga nie tylko umiejętności analitycznych, ale także zdolności do wyciągania wniosków z informacji zwrotnych i wdrażania ich w życie. To moment, w którym pojawia się pytanie: jaki był cel tych badań, skoro nikt z nich nie korzysta?

Brzmi ostro, ale problem jest bardzo konkretny. Jeśli użytkownicy jasno mówią, że jakaś funkcjonalność jest dla nich nieczytelna, niepotrzebna albo myląca, a mimo to nic się nie zmienia - tracimy nie tylko ich uwagę, ale i zaufanie. W efekcie:

• rozwiązania, które miały coś ułatwiać, stają się barierą,
• produkt robi się mniej intuicyjny,
• zespół UX przestaje widzieć sens w kolejnych badaniach, bo i tak nic z nich nie wynika.

Jednym z najbardziej kosztownych błędów jest traktowanie badań jako formalności. To nie jest  dodatek, który warto mieć w procesie, jeśli akurat jest czas. To narzędzie do sprawdzenia, czy kierunek, w którym idziemy, ma w ogóle sens dla użytkownika. Więcej o badaniach w artykule "Dlaczego badania UX to najtańsza forma zabepieczenia produktu?".

Z perspektywy Product Ownera najważniejsze jest to, że dane z badań muszą mieć realne odzwierciedlenie w backlogu. Jeśli raport pokazuje, że użytkownicy nie rozumieją jakiegoś przycisku, to nie jest insight do przemyślenia, tylko gotowe zadanie do sprintu. Jeśli coś wymaga zmian, trzeba je zaplanować, nawet jeśli nie są one priorytetem biznesowym. W przeciwnym razie aplikacja zaczyna działać przeciwko użytkownikowi, a wtedy traci także z punktu widzenia biznesu.

Rola UX Designera w zespole produktowym - to więcej niż projektant makiet

Jednym z najbardziej utrwalonych błędów we współpracy między Product Owerem, a UX-em jest podejście, w którym UX trafia do projektu dopiero w momencie, gdy wszystkie decyzje są już podjęte, a jego zadaniem jest jedynie narysować makietę. Na tym etapie często jest już ustalone co ma być, gdzie ma być i jak ma wyglądać, UX Designer ma tylko ubrać to w interfejs. 

Problem polega na tym, że UX to nie jest usługa graficzna ani etap wdrożenia. W praktyce UX Designer (lub Product Designer) współpracuje z UX Researcherem oraz UI Designerem, aby dostarczyć nie tylko wizualne, ale i funkcjonalne rozwiązania. UX to proces projektowania ścieżek użytkownika, tworzenia komunikatów, projektowania interakcji i zapobiegania błędom poznawczym. Decyzje o pop-upach, powiadomieniach, pushach czy alertach to nie są detale, to elementy, które w złym kontekście po prostu nie działają. Dlatego UX musi być obecny wtedy, kiedy te decyzje dopiero się rodzą, nie wtedy, kiedy są już nieodwracalne.

UX Designer ma kompetencje, by zadawać pytania, które wyłapują luki: co użytkownik zobaczy po kliknięciu? Czy na pewno zrozumie, co się wydarzyło? Czy interfejs nie obiecuje więcej, niż faktycznie się dzieje? Jeśli tych pytań nikt nie zada na etapie discovery, to później ich konsekwencje zobaczymy na call center, w statystykach porzuceń i we frustracji zespołu.

Włączenie UX-a w moment podejmowania decyzji to nie fanaberia, ale sposób na ograniczenie ryzyka. UX to nie końcowy etap, to część procesu tworzenia produktu.

Komunikacja między Product Ownerem a UX Designerem - najczęstsze nieporozumienia

Współpraca Product Ownera z zespołem UX często nie przebiega prawidłowo nie dlatego, że popełniono konkretne błędy, tylko dlatego, że najważniejsze informacje nie zostały nazwane wprost.  Praktyki stosowane w branży UX, takie jak monitorowanie postępów, analiza zachowań użytkowników i iteracyjne testowanie, to elementy budowania sukcesu produktu. Jeśli jednak informacje nie są przekazywane na czas, pojawiają się rozbieżności.

Jeden z typowych przykładów: użytkownicy chcą zobaczyć działający fragment systemu na demo, ale nikt nie zakomunikował, że coś ma trafić na produkcję. Sprint trwa trzy tygodnie, a dopiero w ostatnich dniach okazuje się, że są konkretne oczekiwania. Zespół o tym nie wiedział, wdrożenie nie zostało zaplanowane, więc pojawia się frustracja po każdej ze stron.

W takich sytuacjach nie chodzi o brak dobrej woli. Każdy ma jakieś informacje i własny punkt widzenia. Jeśli jednak te informacje nie są przekazywane na czas i w sposób zrozumiały dla wszystkich, pojawiają się rozbieżności. Z perspektywy UX-a oznacza to pracę bez pełnego kontekstu, a więc większe ryzyko błędów, nieporozumień i dodatkowych iteracji.

Kiedy cele i ograniczenia są nazwane konkretnie i z wyprzedzeniem, wszystkim pracuje się łatwiej. Product Owner unika zbędnych napięć, zespół może planować, a użytkownik szybciej dostaje wartość.

Jak Product Owner może skutecznie korzystać z pracy projektanta UX? 

Jeśli chcesz, żeby UX realnie wspierał rozwój produktu, nie wystarczy wręczyć brief i czekać na makiety. Ważne jest stworzenie warunków, w których UX wie, po co coś robi, kiedy to się wydarzy i kto tego potrzebuje. Rola Product Ownera (czasami menedżera produktu) to nie tylko zarządzanie backlogiem produktu, ale także umiejętne zarządzanie projektami, gdzie ważne są zarówno cele, jak i sposób realizacji powtarzalnych zadań.

Oto, od czego warto zacząć:

1. Mów jasno, jaki jest cel funkcji, nie tylko co ma robić, ale po co to robimy.
2. Dziel się ograniczeniami: czasowymi, technologicznymi, biznesowymi.
3. Angażuj UX-a wtedy, gdy decyzje jeszcze mogą się zmienić.
4. Jeśli masz feedback od użytkowników - przekaż go. To często więcej warte niż 10 ticketów.
5. Sprawdź, czy projektowane widoki są zrozumiałe również dla zespołu developerskiego. To jedno z Twoich podstawowych oczekiwań wobec UX-a i podstawa sprawnej implementacji.

‍

W BB8 nie tylko projektujemy makiety, ale też pomagamy Prodcut Ownerowi w uporządkowaniu backlogu, precyzowaniu celów i budowaniu przepływu informacji między UX a devami. Kiedy zespół tego potrzebuje, potrafimy zapanować nad komunikacją, skrócić pętlę decyzji i zmniejszyć liczbę nieporozumień. 

Jeśli chcesz uporządkować współpracę PO - UX - Dev i zminimalizować nieporozumienia przed startem sprintu, porozmawiaj z nami. Zobaczymy, gdzie brakuje kontekstu, jakie umiejętności analityczne warto rozwinąć w zespole, jak skutecznie wdrożyć monitorowanie postępów i co można usprawnić w projektowaniu UX.