Porządkowanie ścieżki transakcyjnej w panelu B2B

Złożony system, w którym proste zadania były trudne

Wewnętrzny panel B2B, w którym zespoły planują i sprzedają kampanie reklamowe, od wejścia w kampanię, przez koszyk i transakcję, po negocjacje, wymianę dokumentów i rozliczenie.

Złożoność nie brała się z jednego ekranu. Wynikała z nałożenia wielu ról, etapów procesu, statusów i warstw danych. Logiki biznesowej nie można było zmienić, więc przejrzystość musiała powstać po stronie struktury, architektury informacji i UI.

Projekt zaczął się jako krótkie zlecenie, poprawa wyszukiwania produktu i zakładania kampanii. Audyt UX pokazał, że problemy z użytecznością są systemowe i dotyczą całego workflow transakcyjnego, więc zakres rozszerzono do szerszego redesignu panelu.

Statusy nie tworzyły jednej ścieżki. Kampania, produkt i dokument miały własne, równoległe cykle życia, a użytkownik widział je jednocześnie. Produkt mógł być już zarezerwowany, podczas gdy kampania była wciąż w negocjacji, a dokument oczekiwał na podpis. Największe obciążenie poznawcze brało się nie z pojedynczego statusu, tylko z konieczności złożenia trzech warstw w jedną odpowiedź na pytanie: co mam teraz zrobić.

Osobnej decyzji wymagały stany wychodzące poza główną ścieżkę: produkt zawieszony lub usunięty, kampania wstrzymana. Każdy z nich musiał w przewidywalny sposób wpływać na dostępne akcje i na to, co dzieje się z pozostałymi warstwami.

Jeden workflow, nie pojedyncze ekrany

Redesign objął całą ścieżkę, od pierwszego punktu wejścia po rozliczenie. Różne punkty startu musiały zbiegać się w jeden przewidywalny workflow transakcyjny. Inaczej mówiąc, ekrany zaprojektowałam jako kolejne kroki jednej ścieżki, a nie osobne miejsca z własną, oddzielną logiką.

Rozproszony proces o wysokim obciążeniu poznawczym

• Przeładowane ekrany ze słabą hierarchią informacji.
• Niespójne wzorce UI między modułami.
• Nawigacja wymagająca wcześniejszej znajomości systemu.
• Wysokie obciążenie poznawcze dla nowych i okazjonalnych użytkowników.

W efekcie codzienne zadania były wolne i podatne na błędy.

Główne wyzwanie: Jak prowadzić użytkownika przez wielokrokowy proces decyzyjny, nie zmieniając logiki systemu, przy ograniczonym dostępie do użytkowników docelowych i napiętych, iteracyjnych terminach.

Redesign w twardych ramach

Wymusiło to pragmatyczne, systemowe podejście do UX.

Moja rola: zamiana złożonych flow w użyteczne wzorce UI

Odpowiadałam za całość procesu UX/UI: analizę istniejących flow, mapowanie scenariuszy, porządkowanie statusów, projektowanie punktów decyzyjnych i przekładanie złożonej logiki biznesowej na makiety i wzorce interfejsu.

Nie miałam dostępu do użytkowników docelowych po stronie klienta. Pracowałam więc z czterema planerami wykonującymi tę samą pracę w tej samej roli, od pytań o ich codzienną pracę z panelem, przez konsultacje kolejnych wersji ścieżek, po testy użyteczności rozwiązań.

Artefakty procesu

01

Analiza i mapowanie flow

Porządkowanie scenariuszy, punktów wejścia i zależności między etapami procesu.

02

Logika statusów i decyzji

Spójny system etykiet dla trzech warstw statusów, w kilku wariantach do różnych kontekstów: list, tabel i widoków szczegółowych.

03

Makiety i struktura ekranów

Projektowanie widoków z jasnym kontekstem, stanem procesu i możliwymi działaniami.

04

UI i spójne wzorce

Przekładanie złożonej logiki na czytelne, powtarzalne wzorce interfejsu.

Od osobnych ekranów do workflow prowadzonego statusem

Zamiast projektować kolejne osobne widoki, uporządkowałam proces jako sekwencję stanów i decyzji.

Status nie jest tu tylko etykietą, lecz wskazuje, co dzieje się teraz, jaka akcja jest dostępna i jaki będzie kolejny krok.

Dzięki temu użytkownik nie musi sam interpretować logiki systemu, bo interfejs prowadzi go przez proces.

Cztery obszary, jeden spójny workflow

W każdym obszarze ten sam schemat, problem, decyzja, efekt.

Obszar A · centrum decyzji

Koszyk jako centrum decyzji kampanii

Problem: Koszyk pełnił rolę pasywnej listy produktów, bez hierarchii statusu, gotowości, budżetu i kolejnych kroków, więc użytkownik nie wiedział, co wymaga jego decyzji.

Decyzja: Zamienić koszyk w miejsce oceny gotowości kampanii, eksponując status kampanii, gotowość produktów, budżet i kontekstowe CTA.

Koszyk jako centrum decyzji kampanii

1. 1Status kampanii
2. 2Gotowość produktu
3. 3Podsumowanie budżetu / wartości
4. 4Kontekstowe CTA
5. 5Produkty wymagające decyzji

EfektSzybsza ocena gotowości kampanii i jasny moment przejścia do kolejnego etapu.

Obszar B · szczegóły transakcji

Edycja transakcji bez utraty kontekstu

Problem: Edycja odbywała się w osobnych modalach lub ekranach, więc użytkownik tracił kontekst kampanii i wpływ swoich decyzji finansowych.

Decyzja: Pozwolić edytować szczegóły transakcji w miejscu, z zawsze widocznym kontekstem kampanii i zmianami od razu odzwierciedlonymi w podsumowaniu i statusie.

Edycja transakcji w kontekście kampanii

1. 1Kontekst kampanii stale widoczny
2. 2Edytowane dane transakcji
3. 3Wpływ zmiany na podsumowanie i status
4. 4Akcja zależna od etapu

EfektPłynniejsza edycja bez utraty orientacji i mniejsze obciążenie poznawcze przy decyzjach finansowych.

Obszar C · status prowadzi do akcji

Negocjacje jako sekwencja prowadzona statusem

Problem: Negocjacje i rozliczenia odbywały się w oderwanych modalach, więc użytkownik tracił kontekst kampanii i brakowało czytelnej sekwencji między negocjacją, dokumentami a rozliczeniem.

Decyzja: Jedna sekwencyjna ścieżka, w której statusy i akcje są powiązane z etapem, blokując działania niepoprawne i przedwczesne, a historia pozostaje dostępna bez opuszczania kontekstu.

Negocjacje jako etap z własnym statusem

1. 1Status transakcji
2. 2Aktualna propozycja
3. 3Historia dostępna na żądanie
4. 4Akcje zależne od statusu

StatusNowa

Dostępne akcjewyślij propozycję

Następny stanWysłana

StatusDo potwierdzenia

Dostępne akcjepotwierdź warunki

Następny stanZarezerwowana

EfektOchrona przed błędnymi i przedwczesnymi decyzjami, proces prowadzony statusem i mniej chaosu komunikacyjnego.

Obszar D · aktualny stan vs historia

Wymiana dokumentów i historia

Problem: Historia mieszała się z aktualnym stanem, więc główny ekran był zaśmiecony i trudno było ocenić postęp do finalizacji.

Decyzja: Oddzielić aktualny stan od historii. Główny ekran wspiera bieżącą decyzję, a historia żyje na osobnym panelu, na żądanie.

Dokumenty i historia (stan vs historia)

1. 1Aktualny status dokumentu
2. 2Wymagana akcja
3. 3Historia na żądanie (osobny panel)
4. 4Brak dublowania informacji

EfektPełna widoczność decyzji bez chaosu i jasny postęp do finalizacji.

Czytelny, skalowalny workflow transakcyjny

Finalne rozwiązanie obsługuje złożone negocjacje, a jednocześnie utrzymuje użytkownika zorientowanego i w poczuciu kontroli na każdym etapie procesu.

W praktyce oznacza to mniej cofania się w procesie, mniej samodzielnego interpretowania danych i mniejsze ryzyko błędnej decyzji, a do tego szybsze, pewniejsze przejście przez kolejne etapy.

Projekt realizowany przez około 14 miesięcy, iteracyjnie, we współpracy z zespołem i developerami. Redesign objął cały workflow transakcyjny w czterech rolach użytkowników, trzech etapach procesu i trzech warstwach statusów. Rozwiązania weryfikowane w testach użyteczności z czterema planerami oraz w bieżących konsultacjach z zespołem.

Nie pojedyncze ekrany, tylko zmiana sposobu pracy

Najważniejsza różnica nie jest na poziomie pojedynczych ekranów, tylko całego workflow.

Przed — stary, rozproszony widok

Po — uporządkowany workflow

Przed i po na poziomie całego widoku.

Porządkowanie złożoności bez jej ukrywania

Nie usuwałam złożoności procesu, bo wynikała ona z logiki biznesowej, której nie można było zmienić. Zaprojektowałam interfejs tak, żeby użytkownik nie musiał jej sam interpretować. Projekt pokazał, jak bardzo można zmniejszyć obciążenie poznawcze, gdy to logika systemu i status prowadzą działania użytkownika, zamiast zostawiać mu odczytywanie złożonego systemu B2B.