Modernizacja systemu obiegu dokumentów dla administracji

TL;DR

Kontekst: ~13 miesięcy jako solowy UX i lead modernizacji ogólnokrajowego systemu obiegu dokumentów dla administracji publicznej.
Problem: System działał na desktopie od 2003 roku; trzeba było przenieść go na web, w domenie regulowanej instrukcją kancelaryjną, bez utraty szybkości dla power userów.
Co zrobiłem: Poprowadziłem modernizację systemu (moduł rejestracji korespondencji + widget-dashboard) na architekturę webową, projektując pod ekspertów, nie pod początkujących.
Wynik: Projekt doprowadzony do ~95% gotowości; testy potwierdziły parytet czasowy ze starym systemem; skala ~210+ instytucji w Polsce.

Diagnoza

Dwa napięcia napędzały cały projekt. Po pierwsze: zmodernizować legacy bez utraty tego, co działało — power-userzy (urzędnicy) kochali stary desktop za szybkość i to, że wszystko mieli na raz pod ręką. Po drugie, i ważniejsze: zaprojektować dla ekspertów, nie dla laików. Konwencjonalny instynkt UX-owy — whitespace, wizardy, krok-po-kroku — zwolniłby tych ludzi dramatycznie. Cały projekt opierał się na zasadzie: nie „ogłupiaj” systemu.

Co zrobiłem

Prowadziłem modernizację całego systemu z desktopu na web — byłem solowym UX-em, ustalałem kierunek od pierwszego dnia.
Zaprojektowałem moduł rejestracji korespondencji wpływającej do urzędu: szybki wpis (redukcja do ~6 kluczowych pól) + zaawansowane filtry z zapisanymi presetami.
Zaprojektowałem konfigurowalny widget-dashboard — cross-module: widgety z wielu modułów (urlopy, sprawy, przepustki) na jednym ekranie, dobierane do kontekstu użytkownika (analogia: dashboardy Jiry).
Poprowadziłem ~10 pogłębionych badań etnograficznych + shadowingu w ministerstwach i urzędach wojewódzkich, plus iteracyjne testy użyteczności (≥2 rundy) na klikalnych prototypach Axure.

flowchart LR
    A["Dokument wpływa do urzędu"] --> B["Rejestracja web<br/>~6 kluczowych pól"]
    B --> C["Kategoryzacja / routing do modułu"]
    C --> D["Widget-dashboard<br/>info z wielu modułów"]
    D --> E["Urzędnik / manager"]

    classDef neutral fill:#f0f0f1,stroke:none,color:#3f3f46,rx:14,ry:14
    classDef good    fill:#e6f2ea,stroke:none,color:#1f4d33,rx:14,ry:14
    class A,B,C neutral
    class D,E good
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

Wyniki

Doprowadziłem projekt do ~95% gotowości (przekazany dalej — patrz „Jak się skończyło”).
Skala systemu: ~210+ instytucji w całej Polsce; w 2015 tylko ~32% urzędów miało jakikolwiek system obiegu dokumentów — duża luka modernizacyjna.
Parytet czasowy potwierdzony w testach: czas wpisu korespondencji w nowym webowym module zrównał się ze starym desktopem. Cel brzmiał „zmodernizować bez utraty szybkości” — i to się udało (testy rundy 2).
Zredukowałem wstępną rejestrację do ~6 kluczowych pól (reszta opcjonalna), zachowując szybkość wpisu dużej ilości napływającej korespondencji.
Zbudowałem widget-dashboard jako platformową, modularną warstwę — jedno miejsce na kontekstowe info z wielu modułów.

Metryka	Wartość
Skala systemu	~210+ instytucji w Polsce
Adopcja systemów obiegu dokumentów (2015)	~32% urzędów
Zespół projektowy	~8–9 osób (3 BA, 3–4 dev, 1 UX)
Czas trwania	~13 miesięcy
Gotowość na handoff	~95%

Problem

Jak wyglądał stary system?

Desktopowa aplikacja od 2003 roku. Power-userzy — urzędnicy rejestrujący setki dokumentów dziennie — bardzo ją cenili, bo ekran wprowadzania korespondencji miał wszystkie funkcje od razu widoczne. Niektóre używali przy każdym wpisie, inne rzadziej. To był gęsty, ekspertowy interfejs zbudowany pod prędkość. Ale był trudny w utrzymaniu, mało elastyczny i działał tylko na desktopach — a dyrektorzy potrzebowali dostępu do korespondencji z urządzeń mobilnych.

Dlaczego to było trudne?

Tu było sedno. Standardowy, „nowoczesny” webowy UX — dużo whitespace, kreatory, jeden krok naraz — wyglądałby ładnie na screenshotach, ale zwolniłby urzędników wprowadzających dużą liczbę rekordów dziennie do bardzo wolnego tempa. Instynkt mówił „uprość i rozjaśnij”; prawdziwe potrzeby mówiły coś odwrotnego: zachowaj gęstość, bo gęstość to szybkość. Do tego domena silnie regulowana — pierwsze dni projektu to lektura instrukcji kancelaryjnej, która dyktowała, co jest możliwe.

Moja rola / zakres

Solowy UX i lead modernizacji. Ustalałem kierunek koncepcyjny całości; analizę biznesową prowadzili 3 BA, budową zajmował się zespół 3–4 deweloperów, proces Scrum/sprinty (pierwsze miejsce z porządnym wdrożeniem Agile w mojej karierze).
Zespół ~8–9 osób. Współpracowałem głównie z analitykami biznesowymi (identyfikacja ~6 kluczowych pól była wspólnym wysiłkiem) i dev teamem.
Insight z shadowingu — że power-userzy potrzebują gęstości, nie uproszczenia — był mój; to ukształtowało cały kierunek projektu.

Proces

Etnografia + shadowing (contextual inquiry) — ~10 pogłębionych sesji w ministerstwach i urzędach wojewódzkich: mapowanie obecnej ścieżki pracy urzędników, zanim cokolwiek zaprojektowałem.
Klikalne prototypy Axure → iteracyjne testy użyteczności (≥2 rundy). Runda 1 dała feedback o polach wymaganych → ukształtowało zbiór ~6 pól. Runda 2 potwierdziła, że poprawiony formularz jest skuteczny i osiąga parytet czasowy.
Scrum/sprinty przez cały projekt; wnioski z badań na bieżąco zmieniały nastawienie do scope’u.

flowchart LR
    A["Etnografia + shadowing<br/>~10 sesji"] --> B["Prototypy Axure"]
    B --> C["Testy runda 1<br/>feedback o polach"]
    C --> D["Testy runda 2<br/>parytet potwierdzony"]
    D --> E["~95% gotowości"]
    E --> F["Handoff<br/>reorganizacja"]

    classDef neutral fill:#f0f0f1,stroke:none,color:#3f3f46,rx:14,ry:14
    classDef good    fill:#e6f2ea,stroke:none,color:#1f4d33,rx:14,ry:14
    classDef accent  fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
    class A,B,C,D neutral
    class F good
    class E accent
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

Kluczowe decyzje i trade-offy

Nie „ogłupiaj” systemu — projektuj dla ekspertów, nie dla laików. To kluczowy insight całego projektu. Konwencjonalny UX (whitespace, wizard) zwolniłby power-userów. Gęsty interfejs, w którym wszystko jest pod ręką, był celowy, nie niedopracowany. To najważniejsza nauka, którą zabieram dalej.
Szybki wpis zredukowany do ~6 kluczowych pól. Wstępna rejestracja korespondencji tylko tego, co konieczne; reszta opcjonalna. Szybkość wpisu dużej ilości dokumentów zachowana.
Zaawansowane filtry + zapisane presety. Filtry po dużych wolumenach danych plus predefiniowane/zapisane widoki na częste zapytania — urzędnik nie ustawia filtrów od zera każdego dnia.
Widget-dashboard cross-module. Zamiast wielu osobnych ekranów — jeden konfigurowalny dashboard, gdzie użytkownik dobiera widgety z różnych modułów (np. manager: widget akceptacji urlopów + widget nowo przypisanych spraw). Analogia: dashboardy Jiry. To platformowe, modularne myślenie.
Mobile dla przeglądania, desktop dla wpisu. Rejestracja zostaje przy stacjonarnych komputerach (duża objętość, szybkość), ale dostęp do przeglądania i zarządzania korespondencją musi działać mobilnie — dyrektorzy i zaangażowani w sprawy reagowali w locie.
Silnie regulowana domena — instrukcja kancelaryjna dyktuje granice. Pierwsze dni projektu to lektura regulacji; to określa, co w ogóle można projektować. Duża odpowiedzialność, zero luzu.

Jak się skończyło

Projekt doszedł do ~95% gotowości, po czym został przekazany innej jednostce administracji w ramach reorganizacji i decyzji rządu. Niefortunne dla projektu, ale to realia pracy w public sector — decyzje polityczne i organizacyjne przekraczają pojedynczy projekt. Wartość, którą zbudowałem (research, insight o gęstości, fast-entry, widget-dashboard), została opracowana i dokończona poza moimi rękami.

Co z tego wyniosłem

Design dla ekspertów ≠ design dla laików. Najmocniejsza nauka. Nie każda „nowoczesna, prosta” decyzja jest właściwa — dla power-userów gęstość i szybkość to features, nie bugs.
Modernizacja legacy to parytet, nie rewolucja. Cel nie był „zrobić coś zupełnie nowego”; cel był „zmodernizować bez utraty tego, co działało”. Parytet czasowy w testach był twardym sukcesem.
Silnie regulowana domena wymaga pokory na starcie. Instrukcja kancelaryjna dyktowała granice; pierwsze dni to lektura, nie szkice.
Realia sektora publicznego. Decyzje polityczne mogą przekreślić lata dobrej pracy — to nauczyło mnie doceniać scope, na który mam realny wpływ, i ramować uczciwie to, co leży poza nim.

Modernizacja ogólnokrajowego systemu obiegu dokumentów dla administracji