Dlaczego projektowanie aplikacji biznesowych wyróżnia się na tle UX/UI? Moje kluczowe wnioski

Tekst napisany przez Michała Samojlika

Od lat tworzę wewnętrzne aplikacje biznesowe usprawniające przepływy pracy i optymalizujące procesy organizacyjne. Odkryłem, że takie projekty bardzo różnią się od projektowania UX/UI dla B2C i rozwiązań skierowanych do klientów. Poniżej wymieniają pięć kluczowych elementów, które sprawiają, że projekt jest wymagający, oraz czynniki, które należy brać pod uwagę podczas pracy nad taką aplikacją.

Przez aplikacje biznesowe — zwane też narzędziami pracy — rozumiem oprogramowanie zaprojektowane w celu wspierania i usprawniania różnych aspektów działalności firmy. Mogą wyglądać różnie i służyć różnym celom — zwiększają produktywność, współpracę, komunikację i ogólną efektywność w miejscu pracy. Mówiąc o aplikacji biznesowej, możemy mieć na myśli wewnętrzną aplikację dla geologów w branży naftowej i gazowej, system redakcyjny dla dziennikarzy w holdingu medialnym, wewnętrzną aplikację mobilną dla kurierów w firmie dostawczej lub oprogramowanie do zarządzania magazynem.

Jedno jednak mają ze sobą wspólne: ludzie spędzają z nimi cały dzień. Nie mówimy tu o aplikacji, z której korzysta się przez 10–15 minut dziennie, żeby zamówić jedzenie lub taksówkę. Mówimy o 8, a niekiedy 12 godzinach użytkowania — zarówno na komputerze biurowym, jak i na urządzeniu mobilnym, często w wymagających warunkach.

Pomyślcie o tym: jak powinna wyglądać aplikacja, z której korzysta się przez wiele godzin dziennie? Jak ten kontekst wpływa na projektowanie UX/UI? Co projektant musi uwzględnić, pracując nad nią? Podsumowałem pięć kluczowych wniosków, do których doszedłem na temat narzędzi pracy — i co oznaczają one zarówno dla projektantów, jak i ich klientów.

Zobacz: Jak zaprojektowaliśmy aplikację dla kurierów DPD

1) Mierzalność: kwantyfikowanie efektywności

Jedną z największych zalet projektowania aplikacji biznesowych jest ich mierzalność. Dzięki wbudowaniu analityki w narzędzia korporacyjne firmy mogą śledzić czas, jaki poszczególni pracownicy poświęcają konkretnym działaniom w aplikacji, i uzyskiwać wgląd w ich efektywność. Na przykład identyfikacja często wykonywanych scenariuszy i czasu poświęcanego na nie stanowi konkretny punkt wyjścia do obliczenia potencjalnych zysków lub oszczędności.

Wyobraźmy sobie scenariusz, w którym pracownik oszczędza 8 minut dziennie dzięki ulepszeniu UX/UI aplikacji. Jeśli przełożymy to na miesiąc, oszczędności są znaczące — przy 200 pracownikach korzystających z aplikacji to około 32 000 minut miesięcznie, co przekłada się na 6 400 godzin zaoszczędzonych rocznie dla firmy. Może to być znacząca oszczędność i bezpośrednio wpływać na przychody firmy.

Podkreśla to, że poprawa użyteczności to nie tylko kwestia estetyki — ma bezpośredni wpływ na wynik finansowy. Może oznaczać znaczące oszczędności kosztów i czasu: im bardziej usprawnione i intuicyjne narzędzia, tym więcej czasu pracownicy mają na wartościowe zadania.

Ale to ideał.

I zdarza się to nawet wtedy, gdy do przeprowadzenia takiej analizy nie potrzeba zaawansowanego systemu analitycznego. Pracownicy mogą latami korzystać z nieefektywnych narzędzi, wypracowując obejścia i dostosowując się do nieoptymalnych procesów. Część z nich odczuwa frustrację i decyduje się nawet zmienić pracę. Inni narzekają na narzędzia, ale zostają w firmie i opierają się wszelkim zmianom. Do przyczyn tego oporu wrócę w kolejnej sekcji — gdzie skupimy się na użytkownikach aplikacji biznesowych.

Poprawa użyteczności to nie tylko kwestia estetyki — może oznaczać znaczące oszczędności kosztów i czasu (zdjęcie: Midjourney)

2) Podejście skoncentrowane na użytkowniku

Lubię tworzyć narzędzia biznesowe, bo pozwalają wyjść poza analitykę webową. Możemy rozmawiać z osobami korzystającymi z aplikacji, nie opierając się wyłącznie na ankietach i analityce webowej (co jest typowe dla produktów zorientowanych na klienta).

Nie zrozumcie mnie źle — analityka webowa jest niezbędna w naszym procesie discovery (BBUD). Ale jest też wysoce bezosobowa i nie pokazuje pełnego obrazu. Dlatego zawsze łączymy jakościowe i ilościowe metody badawcze i angażujemy użytkowników końcowych podczas pracy nad aplikacją. Obserwowanie pracy pracowników, rozmowy z nimi i włączanie ich spostrzeżeń w proces projektowy zapewniają rozwiązanie, które odpowiada potrzebom użytkowników końcowych.

Co więcej, angażowanie użytkowników na etapie projektowania sprzyja współpracy. Poprzez iteracyjne sprinty użytkownicy wnoszą swoją wiedzę, dostarczając na bieżąco informacji zwrotnej na temat istniejącego narzędzia, dzieląc się punktami bólu i wpływając na kształtowanie bardziej przyjaznego rozwiązania. To podejście oparte na współpracy niweluje przepaść między nami — projektantami a użytkownikami końcowymi — i zapewnia, że finalny produkt odpowiada potrzebom i preferencjom osób, które korzystają z niego na co dzień. Daje też bezpośrednie zrozumienie ich przepływów pracy, punktów bólu, nieefektywności i — jak wspomniałem — przyczyn oporu wobec zmian.

Walka z nieefektywnościami a wyzwanie zmiany

Uprzedzę wasze wątpliwości: współpraca z użytkownikami końcowymi narzędzia nie oznacza, że poddajemy się „myśleniu życzeniowemu" i spełniamy każde życzenie. Wiemy, że pracując dla dużej organizacji, użytkownicy, z którymi przeprowadzamy wywiady, mogą nie być już w firmie w momencie wdrożenia aplikacji ze względu na naturalną rotację lub zmiany rynkowe.

Jesteśmy też świadomi, że istnieją różne grupy użytkowników. Nasze doświadczenie pokazuje, że część z nich będzie opierać się zmianom, bo używają danego narzędzia od lat i chcą zachować swoje przyzwyczajenia. Mogą też obawiać się, że nowe narzędzie będzie trudne do opanowania. Z drugiej strony, część nie chce, żeby istniejące narzędzie się zmieniało, bo wadliwy system służy jako wymówka za każdym razem, gdy coś idzie nie tak. Po naprawieniu narzędzia stracą tę wymówkę. Obie grupy mogą też kojarzyć nowe narzędzia z redukcją etatów i zwolnieniami, co skłania je do sprzeciwiania się zmianie. Wreszcie, zazwyczaj istnieje grupa, która szczerze nienawidzi swoich aplikacji roboczych i przyjęłaby każdą zmianę z otwartymi ramionami — będzie przesadnie podkreślać wady narzędzia i wyolbrzymiać swoje problemy.

Uświadomienie sobie, czego oczekuje biznes, wyznacza ramy całego procesu i pomaga unikać nieporozumień na późniejszych etapach. Opisaliśmy, jak to robimy, w tym artykule — zajrzyj, jeśli cię to interesuje.

Jeszcze jedna rzecz (która mogłaby być osobnym artykułem). Decydując się na transformację aplikacji biznesowych w organizacji, warto dwa razy zastanowić się, czy naprawdę chcesz zrywać z utartymi wzorcami i przyzwyczajeniami swoich pracowników. Czasem „lepsze" może być wrogiem „wystarczająco dobrego". Użytkownicy mogą odrzucić nowe narzędzie, bo nadal wolą stare. Dlatego czasem odpowiedzią na Twoje potrzeby nie jest rewolucja, lecz ewolucja. Może wystarczyć ulepszenie aplikacji i dodanie nowych funkcjonalności, by dać ludziom więcej czasu na przystosowanie się i adaptację.

3) Potrzeba skalowalności i elastyczności

Kolejnym czynnikiem, który musimy uwzględnić przy projektowaniu aplikacji korporacyjnej, jest przewidywanie przyszłości. Oczywiste jest, że firmy nie przeprojektowują swoich narzędzi co 2–3 lata — ze względu na czas i nakłady aplikacje te mają być rozwiązaniami długoterminowymi. Niemniej jednak, projektując konkretne narzędzie, powinniśmy brać pod uwagę, że może ono rosnąć i być rozwijane. Może z jednej aplikacji wyłoni się cały ekosystem? Dla nas oznacza to konieczność myślenia o modularnym i skalowalnym środowisku — zestawie elementów składowych, które można elastycznie konfigurować, tworząc dostosowane do potrzeb zestawy narzędzi.

To podejście odpowiada na potrzebę skalowalności i podkreśla znaczenie dostosowania strategii projektowych do szerszych celów biznesowych. Kluczem jest przekonanie interesariuszy, że przeprojektowanie narzędzi to strategiczna inwestycja optymalizująca koszty i zabezpieczająca operacje na przyszłość — z naciskiem na wartość dodaną przez trwałe zyski efektywnościowe.

Warto myśleć o tym, że Twoja aplikacja biznesowa może rosnąć i być rozwijana (zdjęcie: Midjourney).

4) Wyzwania projektowania sprzętowego

Dzisiejsze narzędzia biznesowe to nie tylko oprogramowanie korporacyjne używane na komputerach firmowych w biurze. Wiele narzędzi przeszło na aplikacje mobilne działające na telefonach lub terminalach. Tu nacisk musi przesunąć się na kompatybilność ze sprzętem i odporność na zróżnicowane warunki środowiskowe — ekstremalne temperatury, deszcz, czy konieczność obsługi urządzenia w rękawiczkach lub jedną ręką.

Pociąga to za sobą kilka konsekwencji. Po pierwsze, projektanci muszą zbierać opinie od osób na różnych poziomach organizacji: kadry kierowniczej, menedżerów średniego szczebla, osób bezpośrednio odpowiedzialnych za codzienne operacje i samych użytkowników końcowych. Uwzględnienie tych perspektyw zapewnia, że projekt odpowiada na unikalne potrzeby, wyzwania i preferencje wszystkich interesariuszy.

Po drugie, interfejs użytkownika musi stawiać na dostępność i funkcjonalność w realnych scenariuszach — w mrozie i w upale, w nocy i w miejscach bez zasięgu mobilnego. Projektanci muszą też pamiętać, kto będzie używać narzędzia — często nie są to pracownicy z pokolenia Z, lecz starsze generacje, rzadko biegłe technologicznie, potrzebujące prostego, intuicyjnego projektu. Poza tym spędzą z aplikacją 8 lub więcej godzin, więc UX/UI musi być krystalicznie jasne. Warto rozważyć wdrożenie funkcji podwójnego potwierdzenia, mikrointerakcji, dźwięków i animacji, które „obudzą" kogoś, kto wykona daną czynność automatycznie po raz setny tego dnia.

5) Czynnik niezawodności

W mniejszych firmach motywacja do aktualizacji UX oprogramowania często wykracza poza metryki oszczędności czasu. Katalizatorem zmiany jest często starzejąca się infrastruktura systemów zbudowanych ponad dekadę temu. Te systemy legacy, niegdyś wystarczające, borykają się teraz z wyzwaniami technologicznymi, brakiem wsparcia i problemami z utrzymaniem. Powód aktualizacji oprogramowania leży w potrzebie dostosowania się do ewoluującej technologii i oczekiwań użytkowników, by uniknąć pułapek pracy z przestarzałymi, nieobsługiwanymi systemami.

Dlatego właśnie wewnętrzne narzędzia biznesowe muszą być niezawodne, przewidywalne i utylitarne. Funkcjonalność ma pierwszeństwo przed wyrafinowanym projektem. Nacisk kładziony jest na dostarczanie użytkownikom narzędzi, które niezawodnie pełnią swoje funkcje, ułatwiając płynne procesy operacyjne bez zbędnych komplikacji. Kluczem jest usprawnienie rutynowych zadań — dlatego warto poznać inne aplikacje i cały ekosystem, w którym operują użytkownicy, by mieć punkt odniesienia do ciągłego projektowania.

Obserwowanie interakcji użytkowników z różnymi narzędziami ujawnia powtarzające się wzorce, nawyki i rozwiązania. Choć celem nie jest uniformizacja, rozpoznanie tych znajomych elementów pozwala projektantom włączać elementy, które współgrają z utrwalonymi praktykami użytkowników — co wzbogaca ogólne doświadczenie użytkownika.

Projektowanie aplikacji biznesowych oparte na UX

Widziałem wiele firm, które nie doceniają znaczenia projektowania UX/UI swoich wewnętrznych narzędzi. Rzadko bierze się je pod uwagę podczas planowania strategicznego. Jeśli aplikacja spełnia swoje zadanie, UX staje się czynnikiem drugorzędnym. Wielu menedżerów wciąż nie zdaje sobie sprawy, że ogólną efektywność pracowników można poprawić dzięki UX/UI — i że ich KPI można przełożyć na projektowanie oparte na UX.

Daj mi znać, jeśli widzisz potencjał wzrostu poprzez UX/UI swoich wewnętrznych narzędzi. Jeśli tak, porozmawiajmy — mamy udokumentowane doświadczenie w tej dziedzinie i możemy pomóc Ci osiągnąć Twoje KPI dzięki projektowaniu opartemu na UX. Zajrzyj do naszych case studies i zadzwoń do nas — żebyśmy mogli zamienić Twój produkt w aplikację, z której użytkownicy czerpią przyjemność.