Monika Michalska z N:OPS 

Zanim zaczniemy skalować produkt, warto sprawdzić, czy podstawowe procesy naprawdę działają. To właśnie na nich produkt po cichu traci użytkowników, a firmy ograniczają swój potencjał wzrostu, próbując rozszerzać zastosowanie produktu przez nowe partnerstwa, czy segmenty, mimo że produkt nie został do tego przygotowany.

Najlepiej widać to w prostych procesach: zakupie, konfiguracji, płatności, rozliczeniu, obsłudze wyjątków. To, ile pracy musi wykonać w nich użytkownik, nie jest samą kwestią UX, tylko skutkiem decyzji o tym, jakie dane zbiera produkt, jak łączy ze sobą systemy i gdzie kończy się automatyzacja, a zaczyna ręczne dopinanie procesu.

Paradoks polega na tym, że firmy często inwestują w nowe funkcje, zanim upewnią się, czy obecna architektura pozwala w pełni wykorzystać potencjał tego, co już zbudowały. Tarcie rzadko występuje tylko na jednej warstwie, a problemy widoczne dla użytkownika są często skutkiem decyzji podjętych dużo wcześniej: w architekturze produktu, organizacji pracy lub projektowaniu procesów.

Warstwa widoczna: UX procesów

To jest to, co widzi użytkownik: ile kroków musi wykonać, żeby opłacić usługę, ile razy wpisuje te same dane, jak łatwo może obsłużyć produkt i jak łatwo może wrócić, poprawić błąd, dokończyć zaczęty proces.

Na tym poziomie tarcie bywa względnie łatwo dostrzegalne: „tu jest za dużo kliknięć”, „tu komunikat nic nie wyjaśnia”, „tu zgubiłam się w wyborach”.

Warstwa organizacyjna: procesy i zespoły

Nad produktem pracuje zwykle kilka zespołów naraz, często też nad kilkoma projektami równolegle. To, czy użytkownik doświadczy prostego procesu jako faktycznie prostego, zależy w dużej mierze od tego, czy te prace są ze sobą na bieżąco komunikowane. Jeśli nie, to później, na etapie wdrożenia w IT, okazuje się, że założenia się rozjechały i nikt nie wie, co finalnie ma trafić na produkcję.

Problem pojawia się, kiedy decyzje produktowe, technologiczne i biznesowe nie są spójne od początku. Przy skalowaniu i partnerstwach to właśnie tu warto patrzeć najpierw: jeśli dziś zespołom brakuje bieżącej komunikacji przy prostych rzeczach, to przy większej złożoności ten rozjazd się nie zmniejszy, tylko urośnie.

 

Warstwa niewidoczna: architektura

Pod prostym procesem opłat, rejestracji czy konfiguracji zwykle stoi kilka systemów, różne źródła danych, do tego różne założenia biznesowe i ograniczenia prawne. Tarcie może wynikać z tego, że:

• system nie jest wystarczająco spójny wewnątrz siebie i wymusza wpisywanie tych samych danych w kilku miejscach,
• dane między systemami czy partnerami nie są prawidłowo zintegrowane, więc to, co firma „wie” w jednym miejscu, nie jest dostępne w drugim,
• przy projektowaniu procesu dodano za dużo wyjątków pod corner case’y, co prowadzi do rozbudowanej logiki, którą trudno później utrzymać i rozwijać.

 

Wiele takich architektur da się jeszcze obsłużyć, dopóki robi to ten sam zespół, który je budował. Problem zaczyna się, gdy dochodzi ktoś nowy: kolejny deweloper, nowy zespół, partner integrujący się z systemem. Wtedy okazuje się, że architektura, którą wszyscy jakoś rozumieli, nigdzie nie została zapisana w sposób czytelny dla kogoś z zewnątrz i każda zmiana zaczyna wymagać głębokiej analizy, zamiast prostego wdrożenia.

Nieczytelna architektura nie zostaje tylko problemem zespołu, ponieważ prędzej czy później przenika też do samego produktu, którym posługuje się użytkownik. Jeśli struktura systemu jest chaotyczna wewnątrz, trudno zbudować na niej prosty, logiczny interfejs, bo sam produkt musi wtedy tłumaczyć użytkownikowi złożoność, której nie da się ukryć za jednym ładnym ekranem. Użytkownik nie widzi tabel i integracji, ale czuje ich skutki: menu, które nie ma logicznej struktury, ustawienia porozrzucane w kilku miejscach, funkcje, które teoretycznie robią to samo, ale nazywają się inaczej w różnych częściach produktu.

Użytkownik doświadcza tego jako „czemu oni ciągle czegoś ode mnie chcą” lub „nie rozumiem, co mam zrobić” i przyczyna leży w tym, jak produkt jest technicznie i logicznie złożony.

Jak najlepiej sobie to wyobrazić

Trzymając się przykładu Autopay z poprzedniego artykułu, wyobraźmy sobie sytuację opłacania przejazdów na autostradzie aplikacją mobilną. Z perspektywy kierowcy jest banalnie: przejeżdżam przez bramkę, system rozpoznaje mój pojazd, płatność schodzi automatycznie, dostaję potwierdzenie. Jeśli ten proces jest dobrze zrobiony, użytkownik nie zastanawia się nad jego istnieniem, tylko po prostu korzysta.

Ale żeby do tego doszło, pod spodem musi się zgrać kilka różnych technologii, zasady operatorów autostrad, systemy płatności i rozliczeń oraz obsługa wyjątków (jak błędne odczyty tablic czy problem z kartą).

W takim procesie ukryte tarcie nie musi być widoczne od razu. Zaczyna się tam, gdzie produkt nie jest w stanie przeprowadzić kierowcy przez tę drogę bez utraty obietnicy prostoty, którą na początku złożył użytkownikom.

Dlaczego „najsilniejsze” produkty tracą użytkowników na prostych procesach?

Produkty dobrze rozpoznawalne, funkcjonalnie dopracowane, z sensowną ofertą potrafią przegrywać nie dlatego, że ktoś wymyślił lepszą funkcję, ale dlatego, że ich proste procesy są zbyt skomplikowane w wykonaniu. Przy większej skali widać wszystkie miejsca, gdzie brakuje automatyzacji, a użytkownik szybciej traci cierpliwość niż doceni wartość tego, co produkt oferuje. W długim czasie rośnie liczba porzuconych procesów: niedokończonych rejestracji, niedokonanych płatności. Partnerstwa stają się trudniejsze, bo każdy nowy kontekst zawiesza się na starym tarciu, a zespoły spędzają więcej czasu na gaszeniu pożarów niż na rozwoju.

Co z tym zrobić, jeśli nie chcemy sprowadzać tematu do UX checklisty

Najprościej byłoby potraktować ten problem jak kwestię ekranów i formularzy. Tymczasem tarcie często powstaje w miejscach, które nie są widoczne dla użytkownika, a mimo to decydują o tym, jak wygląda całe doświadczenie.

Kilka kierunków, które są bardziej uniwersalne niż konkretne metody:

• Przejść proces tak, jak robi to użytkownik i zobaczyć ile systemów i zespołów stoi za tym, co z zewnątrz wygląda na jeden krok.
• Sprawdzić, czy produkt nie prosi użytkownika o coś, co firma już wie z innego źródł
• Potraktować partnerstwo jako test jakości własnego procesu, a nie jako sposób na sprzedanie rozwiązania mimo tarcia.
• Sprawdzić, w którym dokładnie miejscu ścieżki użytkownicy rezygnują (nie na podstawie przeczucia, tylko danych), bo pytanie o dopasowanie architektury produktu do klientów nie jest tylko pytaniem technicznym. Jest też pytaniem o to, ile przychodu tracimy w miejscu, którego nikt nie sprawdził.

Badania produktu są tu równie ważne, jak przy stawianiu hipotez o nowych kierunkach rozwoju. Kiedy firma szuka nowego segmentu czy nowej funkcji, nikt nie buduje strategii na samym przeczuciu, tylko: sprawdza dane, testuje założenia, rozmawia z klientami. Ale ta sama dyscyplina rzadko dotyczy tego, co już istnieje. Architektura, która powstała kilka lat temu pod inne potrzeby, zostaje, bo działa i nikt jej nie kwestionuje, dopóki nie zacznie wyraźnie szkodzić. A przecież to samo pytanie, które zadajemy przy nowym kierunku „czy to pasuje do tego, jak faktycznie zachowują się dziś nasi klienci i czego potrzebują”, powinno wracać regularnie też do tego, co już zbudowane.

Pytanie, gdzie dokładnie produkt traci użytkownika: na ekranie, w zespołach czy w architekturze, poprzedza wszystkie decyzje o dalszym rozwoju – samodzielnie czy z partnerami. Bo partnerstwo nie naprawia słabego procesu, tylko go testuje.