Modernizacja ogólnokrajowego systemu obiegu dokumentów dla administracji

TL;DR

• Kontekst: ~13 miesięcy jako jedyny UX-owiec i lead modernizacji ogólnokrajowego systemu obiegu dokumentów dla administracji publicznej.
• Problem: System działał na desktopie od 2003 roku. Trzeba go było przenieść na web, zgodnie z instrukcją kancelaryjną i bez spowalniania urzędników, którzy wpisują w nim setki pism dziennie.
• Co zrobiłem: Poprowadziłem przeniesienie systemu na web. Zaprojektowałem moduł rejestracji korespondencji i konfigurowalny pulpit z widżetami, z myślą o doświadczonych użytkownikach.
• Wynik: Projekt był gotowy w ~95%. W testach wpis pisma w nowej wersji trwał tyle samo co w starej. System obsługuje ponad 210 instytucji w Polsce.

Diagnoza

Przez cały projekt musiałem pogodzić dwie rzeczy. Pierwsza to modernizacja bez utraty tego, co działało. Urzędnicy bardzo cenili stary program za szybkość i za to, że wszystko mieli pod ręką na jednym ekranie. Druga, ważniejsza, to projektowanie dla ekspertów. Typowe nowoczesne rozwiązania, czyli dużo wolnej przestrzeni, kreatory i jeden krok na ekranie, bardzo by ich spowolniły. Przyjąłem więc prostą zasadę: nie upraszczać systemu na siłę.

Co zrobiłem

• Prowadziłem przeniesienie całego systemu z desktopu na web. Byłem jedynym UX-owcem i nadawałem kierunek od pierwszego dnia.
• Zaprojektowałem moduł rejestracji pism, które wpływają do urzędu. Szybki wpis wymaga ~6 najważniejszych pól, a do przeglądania są zaawansowane filtry z zapisanymi ustawieniami.
• Zaprojektowałem konfigurowalny pulpit z widżetami z różnych modułów (urlopy, sprawy, przepustki). Każdy użytkownik dobiera je do swojej pracy, podobnie jak w pulpitach Jiry.
• Przeprowadziłem ~10 pogłębionych badań w ministerstwach i urzędach wojewódzkich, w tym obserwację urzędników przy pracy. Do tego co najmniej 2 rundy testów użyteczności na klikalnych prototypach w Axure.

flowchart LR
    A["Pismo wpływa do urzędu"] --> B["Rejestracja w przeglądarce<br/>~6 najważniejszych pól"]
    B --> C["Kategoria i przekazanie do modułu"]
    C --> D["Pulpit z widżetami<br/>informacje z wielu modułów"]
    D --> E["Urzędnik albo kierownik"]

    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. Potem przejęła go inna jednostka (więcej w „Jak to się skończyło”).
• System obsługuje ponad 210 instytucji w całej Polsce. W 2015 roku tylko ~32% urzędów miało jakikolwiek system obiegu dokumentów.
• W testach nowa wersja była tak samo szybka jak stara. Celem było przeniesienie systemu na web bez utraty szybkości i to się udało (druga runda testów).
• Wstępną rejestrację pisma skróciłem do ~6 najważniejszych pól. Reszta jest opcjonalna, więc urzędnik szybko wpisuje nawet dużą liczbę pism.
• Pulpit z widżetami działa w całym systemie. W jednym miejscu widać informacje z wielu modułów.

Problem

Jak wyglądał stary system?

To była aplikacja desktopowa z 2003 roku. Urzędnicy, którzy wpisują w niej setki dokumentów dziennie, bardzo ją lubili. Na ekranie rejestracji mieli wszystkie funkcje od razu widoczne. Z części korzystali przy każdym wpisie, z innych rzadziej. Interfejs był gęsty i zbudowany pod szybką pracę. Był jednak trudny w utrzymaniu, mało elastyczny i działał tylko na komputerach stacjonarnych, a dyrektorzy chcieli sprawdzać korespondencję także na telefonie.

Dlaczego to było trudne?

Nowoczesny web z dużą ilością wolnej przestrzeni, kreatorami i jednym krokiem na ekranie ładnie wyglądałby na zrzutach ekranu. Urzędników, którzy wpisują dziennie dużo pism, bardzo by jednak spowolnił. Odruch podpowiadał, żeby uprościć i rozjaśnić ekran. Obserwacja urzędników pokazała coś odwrotnego: gęsty ekran pozwala im pracować szybko, więc trzeba go zachować. Do tego dochodziły przepisy. Pierwsze dni projektu spędziłem na czytaniu instrukcji kancelaryjnej, bo to ona określa, co w ogóle można zaprojektować.

Odtworzony szkic. Nowy formularz ma wszystkie pola, a te rzadko używane są schowane niżej.

Moja rola / zakres

• Byłem jedynym UX-owcem i prowadziłem modernizację. Nadawałem kierunek całości. Analizę biznesową robiło 3 analityków, a system budował zespół 3–4 developerów. Pracowaliśmy w sprintach, w Scrumie. To było pierwsze miejsce w mojej karierze, gdzie Agile był wdrożony porządnie.
• W ~8–9-osobowym zespole najwięcej pracowałem z analitykami (razem ustaliliśmy ~6 najważniejszych pól) i z developerami.
• Wniosek z obserwacji, że urzędnikom trzeba zostawić gęsty ekran, był mój. Na nim oparł się kierunek całego projektu.

Proces

• Obserwacja przy pracy. Zanim cokolwiek zaprojektowałem, przeprowadziłem ~10 pogłębionych sesji w ministerstwach i urzędach wojewódzkich. Rozpisałem, jak dziś wygląda praca urzędników.
• Prototypy w Axure i testy. Zrobiłem co najmniej 2 rundy testów użyteczności. Pierwsza dała feedback o wymaganych polach i z niego wyszło ~6 najważniejszych. Druga potwierdziła, że poprawiony formularz działa i jest tak samo szybki jak stary.
• Przez cały projekt pracowaliśmy w sprintach, a wnioski z badań na bieżąco zmieniały zakres.

flowchart LR
    A["Obserwacja urzędników<br/>~10 sesji"] --> B["Prototypy w Axure"]
    B --> C["Testy, runda 1<br/>feedback o polach"]
    C --> D["Testy, runda 2<br/>ta sama szybkość"]
    D --> E["~95% gotowości"]
    E --> F["Przekazanie<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

• Projektowanie dla ekspertów. To najważniejsza decyzja w całym projekcie. Typowe nowoczesne rozwiązania spowolniłyby urzędników. Gęsty ekran, na którym wszystko jest pod ręką, zostawiłem celowo. Według mnie to najważniejsza rzecz, jakiej nauczył mnie ten projekt.
• Szybki wpis w ~6 polach. Przy wstępnej rejestracji pisma wymagane jest tylko to, co konieczne, a reszta jest opcjonalna. Dzięki temu urzędnik szybko wpisuje dużo dokumentów.
• Zaawansowane filtry z zapisanymi ustawieniami. Danych jest dużo, więc filtry są rozbudowane. Najczęstsze zestawy można zapisać, żeby nie ustawiać ich od zera każdego dnia.
• Jeden pulpit z widżetami z różnych modułów. Zamiast wielu osobnych ekranów jest jeden pulpit, na którym użytkownik układa widżety. Kierownik może mieć na przykład widżet do akceptacji urlopów obok widżetu z nowymi sprawami. Działa to podobnie jak pulpity w Jirze.
• Telefon do przeglądania, komputer do wpisywania. Rejestracja zostaje na komputerach stacjonarnych, bo tam wpisuje się dużo i szybko. Przeglądanie korespondencji i decyzje muszą jednak działać na telefonie, bo dyrektorzy i osoby prowadzące sprawy reagowały w biegu.
• Instrukcja kancelaryjna wyznacza granice. Na starcie czytałem przepisy, bo to one mówią, co w ogóle można projektować. Odpowiedzialność była duża, a pole manewru małe.

Odtworzony szkic. Każda rola składa pulpit z widżetów różnych modułów (podobnie jak w Jirze).

Jak to się skończyło

Projekt doszedł do ~95% gotowości. Potem, w ramach reorganizacji i decyzji rządu, przejęła go inna jednostka administracji. Niestety tak wygląda praca w sektorze publicznym. Decyzje polityczne i organizacyjne często są większe niż pojedynczy projekt. To, co zbudowałem (badania, wniosek o gęstym ekranie, szybki wpis i pulpit z widżetami), dokończyli już inni.

Co z tego wyniosłem

• Doświadczeni użytkownicy potrzebują czegoś innego niż początkujący. Nie każde „nowoczesne i proste” rozwiązanie jest dobre. Dla kogoś, kto wpisuje setki dokumentów dziennie, gęsty ekran i szybkość to zaleta.
• Modernizacja nie musi być rewolucją. Celem było przeniesienie systemu na web bez utraty tego, co działało. Ta sama szybkość w testach była dla mnie konkretnym sukcesem.
• W regulowanej branży zaczynam od czytania przepisów. Instrukcja kancelaryjna wyznaczała granice, więc pierwsze dni to była lektura, a nie szkice.
• W sektorze publicznym nie wszystko zależy od projektu. Decyzja polityczna może zatrzymać dobrze prowadzoną pracę. Nauczyło mnie to skupiać się na tym, na co mam realny wpływ, i uczciwie mówić o tym, na co go nie mam.