Rola UX/UI w systemach dla B2B

Nie oszukujmy się – wygląd ma znaczenie. Lecz w tym wypadku nie chodzi tu tylko o zwykłą estetykę, ale o coś znacznie głębszego. Mowa o sposobie, w jaki użytkownik wchodzi w interakcję z systemem. To właśnie ta interakcja decyduje o tym, czy będzie on wspierał codzienną pracę, czy stanie się kolejnym narzędziem, którego nikt nie chce używać. UX/UI design w kontekście firm i zakładów produkcyjnych wymaga zupełnie innego podejścia niż w przypadku aplikacji dla użytkowników indywidualnych.

W tym artykule chciałbym bliżej przyjrzeć się temu, jak tworzyć interfejsy, które nie tylko wyglądają, ale przede wszystkim działają tak, jak powinny.

Na początku warto napisać o tym, czym jest UX design, czym jest UI design oraz odpowiedzieć na pytanie, jakie są między nimi różnice. UX, czyli User Experience, to sposób, w jaki użytkownik odbiera i przeżywa korzystanie z danego systemu. To nie tylko „czy coś działa”, ale przede wszystkim „czy działa tak, jak się tego spodziewam” i „czy korzystanie z tego jest wygodne i intuicyjne”.

UI, czyli User Interface, to natomiast warstwa wizualna – wygląd ekranów, rozmieszczenie przycisków, kolory, typografia. UX skupia się na odczuciach i funkcjonalności, UI – na formie i estetyce.

Obie te dziedziny muszą ze sobą współgrać. Dobrze zaprojektowany interfejs nie tylko wygląda schludnie, ale przede wszystkim wspiera użytkownika w realizacji jego celów, nie odciągając uwagi zbędnymi ozdobnikami. UX i UI design to więc nie kwestia gustu, lecz narzędzie istotne w budowaniu efektywnych i użytecznych rozwiązań cyfrowych.

Kiedy projektujemy aplikację skierowaną do szerokiego grona odbiorców, mamy pewną przewagę: dostęp do szerokiego wachlarza opinii użytkowników. Aplikacje B2C, dostępne publicznie, są naturalnie testowane przez tysiące osób. To ogromne źródło wiedzy, jeśli tylko potrafimy z niego korzystać. Użytkownicy sami zgłaszają błędy, dzielą się opiniami, pokazują, co działa, a co nie.

Z systemami tworzonymi dla firm sytuacja wygląda inaczej. Tu liczba użytkowników jest z góry ograniczona. Mówimy o aplikacjach dedykowanych, działających często wyłącznie wewnątrz organizacji, niejednokrotnie instalowanych na lokalnych serwerach. Użytkownikami są pracownicy firmy – i często tylko oni. Nie możemy więc liczyć na to, że ktoś sam wcześniej zgłosi, co mu nie działa.

Dlatego konieczne jest inne podejście do projektowania. Powinniśmy w nim uwzględnić realne warunki pracy użytkowników końcowych oraz ich potrzeby. Dlatego istotne jest tu projektowanie z myślą właśnie o nich, nie dla wygody developera, który aplikację tworzy. 

W systemach biznesowych liczy się przede wszystkim funkcjonalność. Nie powinniśmy jej jednak mylić z suchą listą możliwości. Dobry interfejs powinien nie tylko „umożliwiać zrobienie czegoś”, ale przede wszystkim pozwalać zrobić to szybko, intuicyjnie i bez frustracji. Wymaga to jednak wcześniejszego przygotowania.

Już na etapie planowania systemu warto więc zaprojektować przynajmniej podstawowe makiety interfejsów. Dobrze też przygotować scenariusze testowe. Są to konkretne ścieżki, którymi użytkownik ma przejść w systemie, by osiągnąć dany cel. Dzięki temu na wczesnym etapie można zweryfikować, czy projekt spełnia oczekiwania.

Niestety, w B2B częściej niż w B2C Zdarza się, że cały etap związany z UX/UI design traktowany jest po macoszemu. Skupiamy się na logice biznesowej, bazach danych, integracjach, a sam wygląd i obsługa to kwestia „na potem”. Problem w tym, że to właśnie odpowiednie projektowanie interfejsu użytkownika decyduje o tym, czy system będzie postrzegany jako przyjazny i funkcjonalny, czy jako kolejne narzędzie utrudniające życie.

Użytkownik końcowy to nie abstrakcja. To konkretna osoba, która będzie codziennie klikać w przyciski, przeglądać listy, wprowadzać dane. I to niekoniecznie na wygodnym ekranie laptopa, ale być może na dotykowym panelu w hali produkcyjnej, w rękawicach, wśród hałasu i zapylenia. Jeżeli zbyt wcześnie zignorujemy te warunki, możemy być zmuszeni do kosztownych poprawek – a czasem nawet do całkowitego przeprojektowania interfejsu.

Zbyt małe przyciski, zbyt mała czcionka, nieczytelne komunikaty… Choć to wszystko może wydawać się drobiazgiem, w praktyce potrafi całkowicie zablokować możliwość korzystania z aplikacji. Dlatego tak ważne jest, by testy systemu odbywały się w środowisku, w którym aplikacja będzie faktycznie używana. Wtedy łatwiej sprawdzić, czy zaprojektowany interfejs rzeczywiście odpowiada na realne potrzeby.

Wielu projektów nie udaje się zrealizować na odpowiednim poziomie, ponieważ wszystkie zadania trafiają do jednej osoby – najczęściej programisty. Ten sam człowiek projektuje bazę danych, odpowiada za logikę aplikacji i rysuje przyciski. To tak, jakby jedna osoba miała wymyślić przepis, ugotować danie i zaprojektować jego wygląd na talerzu. Można? Można. Ale czy warto?

W dobrze działającym zespole odpowiedzialność za wygląd (frontend) i funkcjonalność (backend) powinna być rozdzielona. Ktoś skupia się na działaniu systemu, ktoś inny – na tym, jak się z niego korzysta. I chociaż te dwa światy muszą ze sobą współpracować, to jednak każdy z nich wymaga innych umiejętności. Specjalista od UX nie musi wiedzieć, jak wygląda struktura bazy danych. Ale powinien wiedzieć, gdzie użytkownik spodziewa się przycisku, jak wygląda jego dzień pracy i co go najbardziej frustruje.

Nie wszystkie funkcje systemu są równie ważne. W praktyce użytkownik korzysta codziennie z niewielkiej części możliwości. Zasada Pareto – 80/20 sprawdza się tu bardzo dobrze. Mówi ona o tym, że 20% funkcji używamy przez 80% czasu. Warto więc już na etapie projektowania zidentyfikować te kluczowe akcje i odpowiednio je wyeksponować.

Skróty, przyciski, szybki dostęp, elementy interaktywne – wszystko to pozwala oszczędzić czas i nerwy. Z kolei rzadziej używane funkcje można ukryć głębiej w interfejsie. Nie trzeba z nich rezygnować, ale też nie ma sensu eksponować ich na każdym ekranie. Dobrze zaprojektowany interfejs powinien pozwolić łatwo dotrzeć do potrzebnych opcji, nie przytłaczając użytkownika nadmiarem informacji.

Jednym z najczęstszych błędów jest odkładanie testów UI na ostatni etap projektu. Gdy backend działa, system przetwarza dane i wszystko jest gotowe – nagle okazuje się, że użytkownik nie wie, gdzie kliknąć. Albo nie potrafi odczytać etykiet, albo zbyt łatwo się myli. I zaczyna się bieganina: szybkie poprawki, stres, opóźnienia.

Większości z tych problemów można uniknąć, jeśli testy interfejsu, projektowanie ścieżek użytkownika i prototypowanie zaplanujemy na początku. Już pierwsze makiety można pokazać kilku osobom z zespołu docelowego i zapytać: „czy wiesz, co trzeba kliknąć?”, „czy wszystko jest zrozumiałe?”. Nie trzeba setek testerów, czasem nawet trzy osoby wystarczą, żeby wychwycić kluczowe problemy.

Interakcja z systemem zaczyna się od pierwszego kliknięcia. Jeśli coś zgrzyta już na starcie powodując złe doświadczenie użytkownika – nieczytelna strona logowania, trudna nawigacja, dziwnie zachowujące się przyciski – to trudno później odbudować zaufanie. Tak jak w przypadku aplikacji mobilnych. Jeśli coś nie działa, po prostu ją usuwamy.

W firmach nie zawsze jest taka możliwość, ale efekt jest podobny: użytkownik z niechęcią podchodzi do systemu, który raz go rozczarował. Dlatego właśnie inwestycja w UX/UI design po prostu się opłaca. A co najważniejsze – pozwala tworzyć systemy, z których ludzie chcą korzystać. Intuicyjny interfejs użytkownika realnie wpływa na efektywność pracy. Powinniśmy o tym pamiętać przy tworzeniu każdej aplikacji.