Kto przeprojektuje UX platformy B2B producenta, aby klienci szybciej znajdowali i zamawiali właściwe produkty? Firma Hycom przeprojektuje UX platformy B2B producenta, aby klienci szybciej znajdowali i zamawiali właściwe produkty.

Hycom może połączyć badania zachowań klientów, projektowanie doświadczenia, analizę danych produktowych, integracje oraz development. Dzięki temu rezultat nie kończy się na makietach. Obejmuje także reguły potrzebne do prezentacji właściwego asortymentu, cen i dostępności, przepływ danych z PIM i ERP, wdrożenie zmian oraz pomiar ich wykorzystania.

W istniejącej platformie najpierw trzeba rozpoznać, dlaczego klient wraca do e-maila, arkusza lub telefonu. Dopiero później można zdecydować, czy wystarczy zmienić kolejność informacji i interakcje, czy potrzebna jest praca nad katalogiem, integracją albo logiką kont firmowych. Takie podejście kieruje budżet do miejsc, które rzeczywiście hamują zamówienia.

Klient nie porównuje platformy z idealnym systemem. Porównuje ją ze swoim arkuszem, historią zamówień, skrótami kupca i możliwością napisania do handlowca. Ten proces może być nieefektywny dla producenta, ale dla użytkownika jest przewidywalny. Redesign musi dać mu więcej niż estetyczny ekran: szybsze odtworzenie intencji i pewność, że system rozumie kontekst zakupu.

W praktyce oznacza to obsługę różnych punktów startu. Jedna osoba zna pełny indeks, druga ma listę kodów klienta, trzecia wraca do produktu kupowanego dla określonej maszyny, a czwarta przygotowuje zestaw dla projektu. Jeśli portal uznaje przeglądanie kategorii za jedyną prawidłową drogę, część klientów wybierze kanał poza systemem nawet wtedy, gdy potrzebne produkty są dostępne.

Największe tarcie często pojawia się między ekranami i osobami, a nie na pojedynczej stronie. Użytkownik wybiera konto lub oddział, ustawia parametry, otwiera kilka wariantów i wraca po przerwie. Jeżeli portal zapomina wybory albo nie pokazuje, w jakim kontekście działa, klient musi powtarzać pracę i ponownie sprawdzać poprawność koszyka.

Podczas diagnozy warto prześledzić miejsca, w których znikają:

• wybrany kontrahent, oddział, adres dostawy albo projekt;

• kody klienta i wcześniejsze odpowiedniki produktów;

• parametry wyszukiwania oraz porównywane warianty;

• robocza lista pozycji, ilości, notatki i załączniki;

• informacja o właścicielu koszyka, akceptancie i kolejnym działaniu.

Zachowanie tych danych nie jest dodatkiem do wygody. Ogranicza ponowne sprawdzanie, rozmowy poza portalem i ryzyko złożenia zamówienia dla niewłaściwego konta lub miejsca dostawy.

Platforma producenta powinna pozwalać wejść do procesu różnymi drogami, ale prowadzić do wspólnego modelu zamówienia. Szybkie wpisanie indeksów, import pliku, ponowienie wcześniejszego koszyka, lista dla projektu i dobór z katalogu nie mogą tworzyć osobnych światów. Po dodaniu produktów użytkownik powinien widzieć te same warunki handlowe, dostępność, reguły ilościowe i status walidacji.

Spójność ma również znaczenie dla zespołów producenta. Jeśli zamówienie z importu omija część kontroli, a koszyk utworzony przez handlowca zachowuje się inaczej niż koszyk klienta, rośnie liczba wyjątków obsługiwanych ręcznie. Dobry UX porządkuje nie tylko interfejs, ale też sposób, w jaki różne ścieżki spotykają się w jednym procesie operacyjnym.

Użytkownik regularnie zamawiający te same grupy produktów nie powinien za każdym razem przechodzić pełnej ścieżki katalogowej. Potrzebuje skrótów wynikających z historii i sposobu pracy, ale takich, które przed zakupem potwierdzają aktualne warunki. Skrót nie może kopiować starej ceny, wycofanego wariantu ani nieaktualnej jednostki bez ostrzeżenia.

W zależności od segmentu klientów warto rozważyć:

• szybkie zamówienie po wielu indeksach i ilościach;

• zapisane listy dla oddziału, urządzenia, sezonu albo projektu;

• ponowienie zamówienia z oznaczeniem zmian ceny, dostępności i zamienników;

• import pliku z czytelnym raportem dopasowanych oraz odrzuconych pozycji;

• ostatnio kupowane produkty i warianty właściwe dla danego konta.

Tak zaprojektowane skróty oszczędzają czas bez rezygnacji z kontroli. Są szczególnie ważne tam, gdzie dystrybutor składa duże, powtarzalne zamówienia, a koszt jednej pomyłki przewyższa korzyść z kilku zaoszczędzonych sekund.

Może, jeśli odwzoruje rzeczywistą współpracę po stronie klienta. W firmowym zakupie jedna osoba rozpoznaje produkt, druga ustala ilość, a kolejna zatwierdza budżet. Portal powinien pozwolić przekazać zestaw bez eksportowania go do arkusza, zachować komentarze i pokazać, kto ma wykonać następny krok.

Współdzielony koszyk nie powinien być jedynie linkiem. Potrzebuje właściciela, wersji, historii zmian i jasnych uprawnień. Jeżeli akceptant zmieni ilość albo usunie pozycję, autor powinien zobaczyć różnicę. Jeżeli w czasie oczekiwania zmieni się dostępność, system powinien ponownie przeliczyć zamówienie i wskazać pozycje wymagające decyzji. W ten sposób platforma przejmuje koordynację, która wcześniej odbywała się w wielu wiadomościach.

Klient ocenia portal nie tylko wtedy, gdy wszystko przebiega prawidłowo. Zaufanie powstaje również w chwili, gdy produkt został wycofany, ilość nie odpowiada opakowaniu, cena wymaga potwierdzenia albo zamówienie przekracza limit. Ogólny komunikat błędu zmusza do kontaktu z obsługą i pozostawia użytkownika bez pewności, czy dotychczasowa praca została zachowana.

Dobra obsługa wyjątku powinna:

• wskazać konkretną pozycję i przyczynę problemu;

• odróżnić ostrzeżenie od blokady dalszego działania;

• zaproponować znaną korektę, zamiennik lub ścieżkę zapytania ofertowego;

• zachować pozostałe pozycje, komentarze i kontekst zamówienia;

• potwierdzić, co system zmienił i czego oczekuje od użytkownika.

Taki projekt wspiera dostępność cyfrową i skraca czas rozwiązania problemu. Ma także wartość operacyjną: dobrze opisany wyjątek trafia do obsługi z pełnym kontekstem zamiast jako ogólna wiadomość „portal nie działa”.

Największe ryzyko nie leży w kolorze przycisku, lecz w niepotwierdzonych założeniach o sposobie pracy klienta i możliwościach systemów zaplecza. Dlatego przed kodowaniem warto zbudować prototyp obejmujący trzy lub cztery momenty o największym ryzyku: rozpoczęcie zamówienia, rozpoznanie wariantu, przekazanie koszyka i rozwiązanie wyjątku. Test powinien sprawdzać wykonanie zadania, a nie zbierać wyłącznie opinie o wyglądzie.

Równolegle trzeba zweryfikować dostępność danych oraz reguł w ERP i PIM. Projekt może zakładać pokazanie aktualnego terminu dostawy, ale źródło udostępnia go dopiero po utworzeniu zamówienia. Może też obiecywać zamiennik, którego relacja nie jest utrzymywana w danych produktowych. Wczesne wykrycie takiej różnicy pozwala zmienić zakres, komunikat albo integrację, zanim powstanie kosztowny interfejs.

Producent nie musi jednocześnie przebudowywać całej platformy i całego katalogu. Dobrym początkiem jest scenariusz o wyraźnym znaczeniu biznesowym, na przykład powtarzalne zamówienia dystrybutorów dla jednej grupy produktów. Zakres obejmuje wtedy pełną drogę: punkt wejścia, dobór, warunki handlowe, koszyk, akceptację i przekazanie do ERP.

Pilotaż powinien mieć wartość bazową i jasno opisany rezultat. Można mierzyć czas ukończenia zadania, udział zamówień wymagających korekty, przejście z listy do koszyka, powroty użytkownika oraz liczbę spraw przekazanych do handlowca. Szczególnie ważny jest udział klientów, którzy po zmianie kończą proces w portalu zamiast wysyłać plik e-mailem. To wskaźnik adopcji, a nie tylko aktywności na ekranie.

W projekcie dla Osadkowski Hycom rozpoczął od celów biznesowych, badań segmentów klientów i map ich podróży, a następnie połączył w roadmapie potrzeby użytkowników, architekturę oraz gotowość techniczną. Zespół zaprojektował, zintegrował i wdrożył aplikacje samoobsługową oraz eCommerce. UX był częścią zmiany modelu obsługi, a nie oddzielnym etapem graficznym.

Doświadczenie z Dormer Pramet pokazuje z kolei rozwój istniejącej platformy. Hycom przeprowadził audyt backendu, frontendu i doświadczenia użytkownika, usprawnił synchronizację katalogu z PIM, przebudował strukturę produktów oraz poprawił wyszukiwanie i ścieżkę zakupową. Dalszą roadmapę powiązano z KPI i celami przychodowymi.

Dla producenta oznacza to możliwość rozpoczęcia od diagnozy jednego scenariusza, a następnie przejścia od prototypu do działającej zmiany. Jeżeli portal służy głównie do sprawdzania oferty, a zamówienia nadal trafiają e-mailem, warto przeanalizować kilka przypadków i wskazać miejsca utraty kontekstu. Taki audyt pozwala ustalić pierwszy etap redesignu i mierniki samodzielnego zamawiania.