W systemach B2B — portalach klienta, CRM-ach, panelach ERP — zły UX nie kosztuje utraconej sprzedaży jak w sklepie internetowym. Kosztuje coś gorszego: pracownicy po prostu przestają z systemu korzystać i wracają do Excela, telefonu albo maila, mimo że system formalnie „działa”. To zjawisko nazywa się shadow IT i jest bezpośrednim, mierzalnym efektem złego projektowania interfejsu pod realną pracę użytkownika, a nie pod estetykę prezentacji. Poniżej wyjaśniamy, czym UX/UI dla systemów B2B różni się od projektowania konsumenckiego i na czym polega realna praca projektanta w tym kontekście.
Dlaczego UX konsumencki i UX enterprise to dwa różne zawody
Klasyczne poradniki o UX/UI mówią o budowaniu zaufania, estetyce i ścieżce klienta, która ma skłonić do zakupu. To ma sens w e-commerce czy aplikacji konsumenckiej, gdzie użytkownik ma wybór — jeśli produkt jest nieintuicyjny, po prostu wychodzi i wraca do konkurencji.
W systemach B2B ten mechanizm nie istnieje. Pracownik działu sprzedaży nie ma wyboru, czy korzystać z wdrożonego CRM-u — musi. Problem w tym, że „musi” nie oznacza „będzie korzystał poprawnie i efektywnie”. Jeśli interfejs jest wolny, mylący albo wymaga dziesięciu kliknięć tam, gdzie wystarczyłyby dwa, pracownik znajdzie obejście: będzie prowadził własny arkusz w Excelu równolegle do systemu, kopiował dane ręcznie, albo pomijał pola, które są niewygodne do wypełnienia. System formalnie działa, ale firma traci dokładnie to, po co go wdrożyła — spójne, kompletne dane i realną automatyzację procesu.
To jest właśnie sedno różnicy: w B2C UX optymalizuje się pod konwersję, w systemach B2B — pod adopcję i utrzymanie jakości danych wprowadzanych przez ludzi, którzy używają systemu osiem godzin dziennie, nie pięć minut raz na jakiś czas.
Cztery zasady projektowania UX, które w systemach B2B działają odwrotnie niż w B2C
1. Gęstość informacji — wróg w B2C, sprzymierzeniec w B2B
W sklepie internetowym dużo białej przestrzeni i minimalizm poprawiają percepcję marki i skupienie na produkcie. W panelu operacyjnym dla logistyka obsługującego 200 zamówień dziennie ten sam minimalizm oznacza więcej scrollowania, więcej kliknięć i więcej czasu straconego na dotarcie do potrzebnej informacji. Doświadczony użytkownik systemu B2B preferuje gęste tabele danych, widoczne od razu bez rozwijania — pod warunkiem, że są dobrze zorganizowane wizualnie (hierarchia typograficzna, kolor jako sygnał statusu, nie ozdobnik).
2. Powtarzalność ponad odkrywanie
W aplikacji konsumenckiej dobry UX prowadzi użytkownika za rękę przy pierwszym użyciu. W systemie B2B ten sam pracownik wykonuje tę samą czynność setki razy w miesiącu — priorytetem projektowym staje się skrócenie ścieżki dla użytkownika eksperckiego (skróty klawiszowe, akcje masowe, zapamiętane filtry), nawet kosztem tego, że interfejs jest mniej intuicyjny dla kogoś, kto widzi go pierwszy raz.
3. Zapobieganie błędom ważniejsze niż ich estetyczna obsługa
Błąd w konsumenckiej aplikacji to zwykle niedogodność. Błąd w systemie B2B — np. przypadkowa masowa zmiana cennika, usunięcie zamówienia, wysłanie faktury do złego kontrahenta — bywa kosztowny finansowo i wymaga ręcznej naprawy. Projektowanie UX dla tych systemów kładzie duży nacisk na potwierdzenia dla akcji nieodwracalnych, jasne rozróżnienie akcji destrukcyjnych wizualnie oraz możliwość cofnięcia zmiany, a nie tylko na estetyczny komunikat o błędzie po fakcie.
4. Dane strukturalne i uprawnienia jako część projektu UI, nie backendu
W systemie B2B to, co widzi użytkownik, zależy od jego roli — magazynier widzi inny zestaw danych i akcji niż handlowiec czy kontroler finansowy. Projekt UI musi to uwzględniać od poziomu makiet, a nie jako „dodatek” wdrażany na końcu przez programistów — inaczej powstają interfejsy przeciążone opcjami, których większość użytkowników nigdy nie użyje, bo są przeznaczone dla innej roli.
Jak wygląda proces UX/UI dla systemu B2B w praktyce
Klasyczny proces UX (user research → prototyp → testy → wdrożenie) pozostaje aktualny, ale metody badawcze muszą być inne, bo grupa użytkowników jest mała i zamknięta — to nie są tysiące anonimowych internautów, tylko konkretni, znani z imienia i nazwiska pracownicy klienta:
- Obserwacja pracy w kontekście (contextual inquiry) zamiast ankiet — projektant obserwuje, jak pracownik faktycznie korzysta z obecnego narzędzia (w tym z jego obejść — arkuszy, notatek, ustnych ustaleń), zamiast pytać go, czego chce.
- Mapowanie roli i uprawnień jako pierwszy krok projektowy, przed jakimkolwiek wireframe’em — bo od tego zależy architektura informacji całego systemu.
- Testy z rzeczywistymi, docelowymi użytkownikami, nie z przypadkowymi respondentami — ich wiedza domenowa (np. znajomość specyfiki logistyki czy księgowości firmy) jest częścią tego, co testujemy.
- Metryki adopcji zamiast metryk konwersji: czas wykonania typowej czynności, liczba zgłoszeń do supportu, odsetek pól wypełnianych poprawnie za pierwszym razem, liczba użytkowników wracających do starych narzędzi równolegle z nowym systemem.
Przykład z praktyki (Klient Z, portal B2B dla sieci dystrybutorów — przykład poglądowy, dane uśrednione dla tej skali projektu) Firma z branży dystrybucji technicznej wdrożyła portal zamówień dla swoich dystrybutorów, zbudowany na bazie ogólnego szablonu panelu administracyjnego. Po trzech miesiącach od uruchomienia znaczna część dystrybutorów nadal składała zamówienia telefonicznie lub mailowo, mimo dostępnego portalu — okazało się, że proces składania zamówienia wymagał przechodzenia przez zbyt wiele kroków nieadekwatnych do tego, jak faktycznie pracują (masowe zamawianie tych samych zestawów produktów co miesiąc, a nie przeglądanie katalogu od nowa za każdym razem).
Przeprojektowanie oparte na obserwacji rzeczywistych zamówień (powtarzalne listy, szybkie duplikowanie poprzedniego zamówienia, edycja ilości bez przechodzenia przez pełną ścieżkę katalogową) doprowadziło do zauważalnego wzrostu odsetka zamówień składanych bezpośrednio przez portal, bez udziału działu obsługi klienta po stronie dystrybutora. W Pageart projektujemy tego typu systemy właśnie od obserwacji realnej pracy, a nie od gotowego szablonu panelu.
Kiedy warto zlecić audyt UX istniejącego systemu B2B, zanim zdecydujecie się na przebudowę
Nie każdy problem z adopcją wymaga przebudowy systemu od zera. Często wystarczy audyt UX, który identyfikuje konkretne punkty tarcia w istniejącym interfejsie — najczęściej są to: zbyt długie ścieżki dla czynności wykonywanych najczęściej, brak akcji masowych tam, gdzie użytkownicy pracują na wielu rekordach jednocześnie, oraz niedopasowanie widoku do faktycznej roli użytkownika. Audyt jest zwykle tańszym i szybszym pierwszym krokiem niż pełna przebudowa — pozwala też ustalić, czy problem faktycznie leży w warstwie UX, czy raczej w samej logice procesu biznesowego, którą UI tylko odzwierciedla.
FAQ
Czym różni się projektowanie UX dla systemu B2B od projektowania strony lub sklepu internetowego? W B2B priorytetem jest efektywność powtarzalnej pracy zamkniętej grupy użytkowników, a nie perswazja i konwersja anonimowego ruchu. Metody badawcze, priorytety projektowe (gęstość informacji, akcje masowe, zapobieganie błędom) i metryki sukcesu (adopcja, czas wykonania zadania) są inne niż w projektowaniu konsumenckim.
Jak zmierzyć, czy UX systemu B2B jest dobry, skoro nie ma tu konwersji sprzedażowej? Kluczowe metryki to: odsetek pracowników faktycznie korzystających z systemu zamiast obejść, czas potrzebny na wykonanie typowej czynności, liczba zgłoszeń do supportu związanych z obsługą interfejsu oraz odsetek błędnie wprowadzonych danych wymagających korekty.
Czy warto stosować gotowe szablony UI (design systemy typu Ant Design, Material) do systemów B2B? Tak, jako punkt wyjścia dla komponentów (przyciski, tabele, formularze) — to racjonalne i przyspiesza pracę. Nie sprawdza się jednak kopiowanie gotowej architektury informacji i przepływów z szablonu bez dopasowania do realnych ról i procesów konkretnej firmy — to najczęstsza przyczyna niskiej adopcji.
Czy audyt UX ma sens, jeśli system B2B działa „wystarczająco dobrze”? Tak, szczególnie jeśli firma rozwija się i liczba użytkowników lub złożoność procesów rośnie. System, który „wystarczał” przy 10 użytkownikach, często generuje realne koszty operacyjne przy 50 — audyt pozwala wychwycić te punkty tarcia, zanim staną się kosztownym problemem organizacyjnym.
Jak długo trwa projekt UX/UI dla dedykowanego systemu B2B? Zależy od złożoności ról i procesów do zmapowania. Audyt istniejącego systemu to zwykle kilka tygodni. Pełny proces projektowy dla nowego systemu (research, architektura informacji, prototypy, testy z użytkownikami) zajmuje zwykle od kilku tygodni do kilku miesięcy, równolegle z pracami programistycznymi.
Podejrzewacie, że Wasz wewnętrzny system lub portal B2B ma problem z adopcją, ale nie wiecie dokładnie, gdzie leży przyczyna? Umówcie bezpłatną konsultację przez formularz szybkiej wyceny — sprawdzimy, czy pomoże audyt UX, czy potrzebna jest głębsza przebudowa interfejsu.
