System delegacji
Wewnętrzny system B2B dla dużej grupy kapitałowej: trzy dedykowane doświadczenia dla pracownika, menedżera i księgowego, zbudowane na wspólnym design systemie.
Zobacz prototyp ↗
- Title
- System zarządzania delegacjami
- Industry
- B2B / Sektor technologiczny
- Role
- UX Research, UI Design, współpraca z QA
- Tools
- Figma, Jira, testy użyteczności z ankietami
- Date
- październik 2024 – wrzesień 2025
O projekcie
Jedna aplikacja,
trzy zupełnie różne doświadczenia
Rok pracy end-to-end: od diagnozy starego ERP i badań, przez projektowanie trzech dedykowanych interfejsów dla każdej roli, po wdrożenie i testy użyteczności z realnym feedbackiem.
Projekt miał dodatkowy wymiar: frontend generowany przez AI po raz pierwszy w tym zespole. Odpowiadałam za jakość na styku Figmy i kodu, żeby to, co zaprojektowałam, faktycznie dotarło do użytkowników.
→Wyzwanie produktowe
Pracownik, menedżer i księgowy mają w systemie delegacji zupełnie różne zadania i różne kryteria sukcesu. Jeden interfejs dla wszystkich trzech ról oznaczał, że żadna z nich nie dostaje doświadczenia dopasowanego do swoich potrzeb. Kluczowa decyzja projektowa dotyczyła architektury, nie wyglądu.
→Innowacja techniczna
Projekt powstawał z udziałem AI-generated code, po raz pierwszy w tym zespole. Kod powstawał szybko, ale przynosił rozbieżności między projektem a wygenerowanym interfejsem. Design system z warstwą tokenów był punktem odniesienia, który pozwalał te rozbieżności wykrywać i naprawiać zanim trafiły do użytkowników.
→Skalowalność
Design system stworzony dla Kolibra projektowany był od początku jako fundament dla całego ekosystemu oprogramowania grupy kapitałowej, oparty na tokenach. Fleet Management działa już na tych samych komponentach. Moduł HR jest w aktywnym developmencie.
→Wynik
Testy użyteczności po wdrożeniu potwierdziły, że kluczowy flow działa. Wyniki scenariusza rozliczeniowego wskazały konkretne miejsca do naprawy i wyznaczyły mapę drogową kolejnych sprintów.
Problem
Stary system
.png&w=3840&q=75)
.png&w=3840&q=75)
Stary system wyglądał jak wewnętrzny produkt IT z lat 2000. Tabele z 10–14 kolumnami wymagały poziomego przewijania, żeby zobaczyć wszystkie dane. Formularz delegacji zawierał dziesiątki pól na jednym ekranie, bez logiki kolejności, z każdą sekcją zbudowaną inaczej. Nad tabelą jednocześnie 4–5 przycisków akcji bez wizualnej hierarchii wskazującej, który jest ważniejszy. Kolory niebieski i zielony nie pełniły żadnej funkcji semantycznej.
Pracownik
Liczył diety w Excelu i wysyłał potwierdzenia mailem. Każda delegacja wymagała wypełnienia formularza od zera, nawet jeśli ta sama trasa co tydzień.
Menedżer
Nie wiedział ile dokumentów czeka na jego decyzję bez kliknięcia w listę wszystkich 450 rekordów. Widok domyślny pokazywał wszystkie dokumenty w systemie bez wyróżnienia tych wymagających jego decyzji.
Księgowy
Sprawdzał te same błędy ręcznych wyliczeń w kółko. Kwoty nie miały rozbicia na kategorie, więc żeby zrozumieć skąd pochodzi suma, musiał dzwonić do pracownika.
Największy problem nie leżał w warstwie wizualnej, ale w architekturze systemu: ta sama aplikacja obsługiwała trzy grupy użytkowników o zupełnie różnych zadaniach, priorytetach i definicjach sukcesu, traktując je jednakowo.
Metodologia badawcza i synteza danych
Ocena heurystyczna
Przeszłam przez wszystkie kluczowe przepływy starego systemu oczami każdej roli. Zanim zapytałam użytkowników „jak bardzo” coś boli, wiedziałam „co i dlaczego” jest zepsute. Zmapowałam naruszenia zasad projektowania w każdym przepływie.
„4–5 przycisków akcji naraz, żaden nie ważniejszy od pozostałych. Użytkownik sam musi zdecydować co kliknąć, zanim jeszcze wie co chce zrobić.”
Wywiady ze stakeholderami
Kierownicy projektów, product ownerzy, analitycy biznesu. Dwa odkrycia, które zmieniły architekturę produktu: pracownicy często powtarzają te same trasy, co można wykorzystać w interfejsie. Menedżerowie potrzebują inboxu z licznikami, nie przebudowanej listy dokumentów.
„Nie potrzebujemy widzieć wszystkich delegacji. Potrzebujemy widzieć tylko te, które wymagają naszej decyzji.”
Testy użyteczności po wdrożeniu
Trzy scenariusze odpowiadające kluczowym zadaniom każdej roli, z ankietami, czasem ukończenia i oceną intuicyjności. Dane nie tylko potwierdzają co działa. Wyznaczają mapę drogową do poprawy tego, co nie działa.
„System sam odczytuje kwotę z załączonych rachunków.”
Jira Lifecycle Management
Ciągły kanał po wdrożeniu: użytkownicy zgłaszali problemy, ja je odkrywałam, dokumentowałam i priorytetyzowałam w epikach. Codzienne spotkania z programistami backendowymi i frontendowymi, żeby każde zgłoszenie trafiło do właściwego sprintu. Testy dają migawkę. Jira daje ewolucję.
Persony
Trzy role, trzy definicje sukcesu
Pracownik / Delegowany
„Muszę to jeszcze raz liczyć w Excelu?”
Składa wniosek między spotkaniami, często bez biurka i pełnej koncentracji. Chce wybrać bilety, hotel i samochód w jednym miejscu, nie przeskakiwać między trzema modułami. Dietę chce zobaczyć wyliczoną przez system, bez ręcznych obliczeń. Definicja sukcesu: wniosek złożony, delegacja zatwierdzona, temat zamknięty.
Menedżer / Akceptujący
„Nie wiem ile mam do akceptacji, muszę klikać, żeby sprawdzić.”
Zatwierdza wnioski między innymi zadaniami. System delegacji to jedno z wielu narzędzi w jego dniu pracy. Potrzebuje jednego spojrzenia: ile dokumentów czeka, jakiego są typu, co wymaga akcji. Definicja sukcesu: wiedzieć co czeka bez przeszukiwania list.
Księgowy
„Sprawdzam te same błędy w kółko, bo pracownicy liczą ręcznie.”
Weryfikuje rozliczenia, dekretuje koszty na MPK i projekty. Każdy błąd w danych to telefon, mail, poprawka, opóźnienie. Potrzebuje rozbicia kwot na kategorie i pewności, że liczby się zgadzają, bez wgłębiania się w pełny kontekst delegacji. Definicja sukcesu: weryfikacja zakończona bez pytań do pracownika.
Jobs To Be Done
Co użytkownicy chcą osiągnąć
Zadanie
Bloker przed redesignem
Po redesignie
Zadanie
Złożyć wniosek o delegację w kilka minut
Przed
Osobne formularze dla biletów, hotelu, samochodu; przełączanie kontekstu i wielokrotne logowanie
Po
✅Trip basket: jeden wniosek, wszystkie składniki razem
Zadanie
Wiedzieć co czeka na moją akcję
Przed
Brak dedykowanego widoku; menedżer przeszukuje listę 450 dokumentów
Po
✅„Czeka na Ciebie”: inbox z licznikami per typ
Zadanie
Rozliczyć delegację bez Excela
Przed
Diety, ryczałty i kilometrówka liczone ręcznie, błędy wchodzą do systemu
Po
✅Automatyczne obliczenia wbudowane w formularz
Zadanie
Dodać załącznik z telefonu na miejscu
Przed
Tylko upload z komputera; paragon z restauracji wymaga transferu pliku
Po
✅5 ścieżek: komputer / QR + AI / bez załącznika / kilometrówka / ryczałt
Zadanie
Zrozumieć status dokumentu jednym spojrzeniem
Przed
Tabele bez wizualnego statusu, etap procesu ukryty w kolumnie tekstu
Po
✅Status jako chip + oś procesu widoczna po prawej
Zadanie
Zweryfikować rozliczenie sprawnie
Przed
Sumy bez rozbicia na kategorie; skąd pochodzi kwota, trzeba sprawdzić ręcznie
Po
✅Diety i ryczałty / Wydatki pracownika / Centrum Rezerwacji / Kilometrówka
Decyzja architektoniczna
Jedna aplikacja, trzy produkty
Stary system miał jeden interfejs dla trzech zupełnie różnych użytkowników. Pracownik chciał złożyć wniosek i zamknąć temat. Menedżer chciał wiedzieć, co czeka na jego decyzję. Księgowy chciał zweryfikować kwoty bez dzwonienia do nikogo. Żadne z tych zadań nie było podobne do pozostałych.
Warsztaty ze stakeholderami i analiza starego systemu pokazały, że problem miał charakter architektoniczny. Projekt przyjął kierunek: trzy dedykowane doświadczenia w jednym systemie, każde zaprojektowane pod jedną definicję sukcesu.
Pracownik / Delegowany
- →Wniosek o delegację to nie jest zadanie, któremu pracownik poświęca godzinę przy biurku. Robi to między spotkaniami, często w pośpiechu, często z telefonu. Cel jest jeden: złożyć wniosek w kilka minut i zapomnieć o nim.
- →Stary system wymagał przełączania między trzema osobnymi modułami: bilety, hotel, samochód. Każdy z własnym formularzem i własną ścieżką zatwierdzenia. Diety i ryczałty liczone poza systemem, w Excelu. Każda delegacja to był projekt sam w sobie.
- →Po zmianie pracownik składa jeden formularz zawierający wszystkie składniki wyjazdu, a obliczenia diet i ryczałtów wbudowane są bezpośrednio w system.
Menedżer / Akceptujący
- →Menedżer obsługuje kilku pracowników jednocześnie i zarządza dziesiątkami innych zadań. System delegacji to jedno z wielu narzędzi w jego dniu, nie centrum jego pracy. Potrzebuje sprawnie przejrzeć wnioski i podjąć decyzję, nie zarządzać listą dokumentów.
- →Stary widok to tabela ze wszystkimi delegacjami w systemie. Żeby znaleźć to, co wymaga jego decyzji, trzeba było filtrować, klikać i liczyć. Żeby wiedzieć ile ma do zrobienia, trzeba było wejść i sprawdzić.
- →Nowy widok startowy to dedykowany panel „Czeka na Ciebie” z licznikami wskazującymi ile delegacji i ile rezerwacji samochodów służbowych czeka na decyzję, widocznymi od razu po zalogowaniu.
Księgowy
- →Księgowy potrzebuje wsparcia w rozliczaniu delegacji nie dlatego, że nie zna przepisów, ale dlatego, że dane, które dostaje, są niedokładne. Ręczne obliczenia pracowników trafiały do systemu z błędami. Każdy błąd to telefon, mail, poprawka, opóźnienie. Ta sama pętla w kółko.
- →Nowy widok zawiera rozbicie na cztery kategorie: Diety i ryczałty / Wydatki pracownika / Centrum Rezerwacji / Kilometrówka. Każda kwota ma źródło widoczne bez pytania do pracownika. Klasa błędów, którą księgowy sprawdzał rutynowo, znika, bo system liczy zamiast pracownika.
- →Trzy dedykowane widoki oznaczają większą złożoność po stronie developmentu i utrzymania. To była świadoma decyzja: wyspecjalizowany interfejs dla każdej roli był ważniejszy niż uproszczenie architektury.
Kluczowe decyzje projektowe
Co i dlaczego zmieniłam
System koszyka: wyjazd to jeden wniosek, nie trzy oddzielne
Problem
Stary system widział delegację jako osobne moduły: bilety PKP, bilety lotnicze, hotel, wynajem samochodu. Każdy z własnym formularzem, własną ścieżką zatwierdzenia, osobnym kontekstem. Pracownik planujący tygodniowy wyjazd musiał złożyć trzy wnioski, które nigdzie nie były ze sobą połączone.
Rozwiązanie
Jeden formularz wniosku obejmuje wszystkie składniki wyjazdu: bilety PKP, bilety lotnicze, hotel, wynajem samochodu, w jednej ścieżce zatwierdzenia. Obliczenia diet i ryczałtów wbudowane bezpośrednio w formularz: system liczy zamiast pracownika. Pracownik składa jeden wniosek i zamyka temat.
„Czeka na Ciebie”: inbox zamiast listy 450 dokumentów
Problem
Menedżer wchodził do systemu i widział tabelę ze wszystkimi delegacjami: swoimi, zatwierdzonymi i czekającymi, oraz delegacjami innych menedżerów zgodnymi z jego uprawnieniami. Wszystko razem, bez podziału. Żeby znaleźć wnioski czekające na jego decyzję, musiał filtrować. Żeby wiedzieć, że w ogóle coś czeka, musiał pamiętać, żeby zajrzeć.
Rozwiązanie
Dedykowany widok startowy zbudowany wokół jednego pytania: co czeka na moją decyzję teraz? Liczniki per moduł: ile delegacji, ile nieobecności, ile wniosków HR, widoczne od razu po zalogowaniu. Akceptacji można dokonać bezpośrednio z karty wniosku. Do tego system powiadomień w aplikacji i na służbowym mailu. Po kliknięciu w wniosek otwiera się pełny widok zadania z rozliczeniem finansowym z rozbiciem na kategorie, komentarze i załączniki oraz panel Camunda z aktualnym stanem procesu i przyciskiem akcji.
Automatyczne obliczenia i personalizacja widoku danych
Problem
Diety, ryczałty i kilometrówka były liczone poza systemem, w arkuszach. Wyniki wklejane do formularza, często z błędem. Księgowy wykrywał te błędy przy weryfikacji i musiał wracać do pracownika z pytaniem, pracownik poprawiał, obieg zaczynał się od nowa. Ten sam błąd, ta sama pętla, w kółko. Osobny problem: jeden domyślny układ tabeli dla wszystkich ról oznaczał, że każdy widzi kolumny, które go nie dotyczą.
Rozwiązanie
Obliczenia wbudowane bezpośrednio w formularz. System liczy diety, ryczałty i kilometrówkę w czasie rzeczywistym na podstawie danych wpisanych we wniosku. Pracownik widzi kwotę, księgowy widzi skąd każda kwota pochodzi, bez pytania do pracownika. Do tego tabela z zaawansowanym filtrowaniem i możliwością konfiguracji własnego widoku: użytkownik wybiera kolumny, które potrzebuje, zapisuje je jako nazwany widok i wraca do nich kiedy chce.
Design system i AI
Problem
Koliber miał być pierwszą aplikacją w tym zespole, której frontend powstawał z pomocą AI. Kod powstawał szybko, ale nie zawsze wyglądał tak jak w projekcie. Bez wspólnego punktu odniesienia trudno było powiedzieć, gdzie coś się rozjechało i dlaczego.
Rozwiązanie
Na potrzeby Kolibra powstał nowy design system: biblioteka komponentów z warstwą tokenów definiujących kolory, typografię i odstępy jako nazwane wartości. Tokeny okazały się odpowiedzią na wyzwanie AI-generated code: rozbieżność między projektem a generowanym kodem stała się widoczna jako konkretna, mierzalna różnica. Do weryfikacji nowych rozwiązań zaczęły powstawać prototypy w Figma Make. Design system wyszedł poza jeden projekt. Na tych samych komponentach i tokenach powstała Flota, a moduł HR jest w trakcie budowy.
Interaktywny prototyp
Wypróbuj system
Klikaj po interfejsie, poniżej działa prototyp zbudowany w Figma Make.
Pomiar sukcesu
Testy użyteczności po wdrożeniu
Po wdrożeniu przeprowadziłam testy użyteczności z ankietami: trzy scenariusze odpowiadające kluczowym zadaniom każdej roli.
Wniosek o delegację
Kluczowy flow sprawdził się w testach. Większość uczestników przeszła przez scenariusz bez większych trudności. Pojawiły się jednak obserwacje do dalszej pracy: niejasny przycisk na widoku szczegółów wniosku oraz problem przy rezerwacji biletu lotniczego, który nie zachowywał się zgodnie z oczekiwaniem. Uczestnicy zgłosili też sugestię, która pojawiła się w kilku odpowiedziach: możliwość wpisania godziny wylotu lub wyjazdu bezpośrednio we wniosku.
Rezerwacja pojazdu
Najkrótszy scenariusz, najczystszy wynik. Większość uczestników ukończyła go bez trudności: uproszczony, wydzielony flow sprawdził się. Jeden punkt wymagający uwagi: etap wydania pojazdu po złożeniu rezerwacji był niejasny. Uczestnicy wiedzieli, że rezerwacja jest złożona, ale nie wiedzieli, co ma nastąpić dalej i czego się spodziewać.
Rozliczenie delegacji
Najtrudniejszy scenariusz. Żaden z uczestników nie ukończył go bez trudności: część zablokował błąd techniczny przy konkretnej delegacji testowej, część miała problem z tooltipami pozycji rozliczeniowych, które nie rozwijały się po najechaniu. Na plus: automatyczne odczytywanie kwot z rachunków uczestnicy zauważyli i docenili wprost.
Wyniki z rozliczenia bezpośrednio wyznaczyły mapę drogową do kolejnego sprintu: naprawa błędu technicznego blokującego obieg, poprawienie zachowania tooltipów z opisami pozycji, dookreślenie kolejnych kroków po złożeniu rezerwacji pojazdu. Równolegle użytkownicy zgłaszają przez Jirę uwagi i błędy aplikacji, które priorytetyzuję w epikach i kieruję do kolejnych sprintów.
Wnioski
Czego nauczył mnie ten projekt
Ocena heurystyczna i warsztaty ze stakeholderami dały odpowiedź zanim zaczęłam projektować cokolwiek nowego: interfejs nie wymagał odświeżenia, wymagał przeprojektowania od fundamentów. Trzy role z trzema zupełnie różnymi definicjami sukcesu nie mogły dzielić jednego widoku i dostawać dobrego doświadczenia. Ta diagnoza wyznaczyła kierunek całego projektu i poprzedziła każdą decyzję projektową.
Testy użyteczności po wdrożeniu przyniosły dwie informacje. Kluczowy flow wniosku o delegację działał tak jak powinien. Scenariusz rozliczeniowy ujawnił konkretne miejsca do poprawy: błąd techniczny blokujący obieg, niejasne tooltipy z opisami pozycji, nieprecyzyjny komunikat po złożeniu rezerwacji pojazdu. Każdy z tych punktów trafił do mapy drogowej kolejnego sprintu.
Design system stworzony na potrzeby Kolibra sprawdził się w kilku kontekstach jednocześnie. Jako biblioteka komponentów przyspieszył pracę na kolejnych ekranach i zapewnił spójność wizualną. Przy AI-generated code tokeny stały się punktem odniesienia, dzięki któremu rozbieżność między projektem a generowanym kodem była widoczna jako konkretna różnica do wyłapania zanim dotarła do użytkowników. Na tych samych komponentach i tokenach działa już Flota, a moduł HR jest w trakcie budowy.