Modernizing a nationwide document-flow system for public administration

TL;DR

• Context: ~13 months as the only UX designer and lead of modernizing a nationwide document-flow system for public administration.
• Problem: The system had run on desktop since 2003. It had to move to the web, in line with the official records-management rules and without slowing down clerks who enter hundreds of documents a day.
• What I did: I led moving the system to the web. I designed the incoming-mail registration module and a configurable dashboard with widgets, with experienced users in mind.
• Result: The project reached ~95% readiness. In tests, registering a document in the new version took as long as in the old one. The system serves more than 210 institutions in Poland.

Diagnosis

Throughout the project I had to reconcile two things. The first was modernizing without losing what worked. Clerks valued the old program highly for its speed and for having everything at hand on one screen. The second, more important one, was designing for experts. Typical modern solutions, meaning lots of white space, wizards and one step per screen, would have slowed them down a lot. So I adopted a simple rule: don’t simplify the system for the sake of it.

What I did

• I led moving the whole system from desktop to the web. I was the only UX designer and set the direction from day one.
• I designed the module for registering documents that come into an office. Quick entry needs ~6 key fields, and for browsing there are advanced filters with saved settings.
• I designed a configurable dashboard with widgets from different modules (leave, cases, passes). Each user picks the ones that fit their work, similar to Jira dashboards.
• I ran ~10 in-depth research sessions in ministries and regional offices, including observing clerks at work. On top of that, at least 2 rounds of usability testing on clickable Axure prototypes.

flowchart LR
    A["A document arrives at the office"] --> B["Registration in the browser<br/>~6 key fields"]
    B --> C["Category and handoff to a module"]
    C --> D["Widget dashboard<br/>information from many modules"]
    D --> E["Clerk or 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

Results

• I brought the project to ~95% readiness. Then another unit took it over (more in “How it turned out”).
• The system serves more than 210 institutions across Poland. In 2015 only ~32% of offices had any document-flow system at all.
• In tests, the new version was as fast as the old one. The goal was to move the system to the web without losing speed, and it worked (second round of tests).
• I cut the initial registration of a document to ~6 key fields. The rest is optional, so a clerk can enter even a large number of documents quickly.
• The widget dashboard works across the whole system. Information from many modules is visible in one place.

The problem

What did the old system look like?

It was a desktop application from 2003. Clerks who enter hundreds of documents a day in it liked it a lot. On the registration screen they had all functions visible at once. They used some of them with every entry, others less often. The interface was dense and built for fast work. But it was hard to maintain, not very flexible, and ran only on desktop computers, while directors wanted to check correspondence on their phones as well.

Why was this hard?

A modern web interface with lots of white space, wizards and one step per screen would have looked nice in screenshots. But it would have slowed down clerks who enter many documents a day. Instinct said to simplify and lighten the screen. Observing the clerks showed the opposite: a dense screen lets them work fast, so it had to stay. On top of that came the regulations. I spent the first days of the project reading the official records-management rules, because they define what can be designed at all.

A reconstructed sketch. The new form has all the fields, and the rarely used ones are tucked further down.

My role / scope

• I was the only UX designer and led the modernization. I set the direction for the whole thing. Business analysis was done by 3 analysts, and a team of 3–4 developers built the system. We worked in Scrum sprints. It was the first place in my career where Agile was implemented properly.
• In a team of ~8–9 people I worked most with the analysts (together we settled on the ~6 key fields) and with the developers.
• The conclusion from the observations, that clerks need to keep a dense screen, was mine. The direction of the whole project was built on it.

Process

• Observation at work. Before I designed anything, I ran ~10 in-depth sessions in ministries and regional offices. I mapped out how clerks work today.
• Axure prototypes and tests. I ran at least 2 rounds of usability testing. The first gave feedback on required fields, and the ~6 key ones came out of it. The second confirmed that the improved form works and is as fast as the old one.
• We worked in sprints throughout the project, and research findings kept changing the scope as we went.

flowchart LR
    A["Observing clerks<br/>~10 sessions"] --> B["Axure prototypes"]
    B --> C["Tests, round 1<br/>feedback on fields"]
    C --> D["Tests, round 2<br/>same speed"]
    D --> E["~95% readiness"]
    E --> F["Handoff<br/>reorganization"]

    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

Key decisions & trade-offs

• Designing for experts. This is the most important decision of the whole project. Typical modern solutions would have slowed clerks down. I kept the dense screen, with everything at hand, on purpose. In my view, it’s the most important thing this project taught me.
• Quick entry in ~6 fields. For the initial registration of a document only what’s necessary is required, and the rest is optional. Thanks to that, a clerk enters many documents quickly.
• Advanced filters with saved settings. There’s a lot of data, so the filters are extensive. The most common sets can be saved, so nobody has to set them up from scratch every day.
• One dashboard with widgets from different modules. Instead of many separate screens, there’s one dashboard where users arrange widgets. A manager might have a leave-approval widget next to a new-cases widget. It works much like Jira dashboards.
• Phone for browsing, computer for entry. Registration stays on desktop computers, because that’s where a lot gets entered quickly. But browsing correspondence and making decisions have to work on a phone, because directors and people handling cases reacted on the go.
• The records-management rules set the limits. At the start I read the regulations, because they say what can be designed at all. The responsibility was big and the room to maneuver small.

A reconstructed sketch. Each role builds a dashboard from widgets of different modules (similar to Jira).

How it turned out

The project reached ~95% readiness. Then, as part of a reorganization and a government decision, another administrative unit took it over. Unfortunately, that’s what working in the public sector looks like. Political and organizational decisions are often bigger than a single project. What I built (the research, the conclusion about the dense screen, quick entry and the widget dashboard) was finished by others.

What I took away

• Experienced users need something different from beginners. Not every “modern and simple” solution is a good one. For someone who enters hundreds of documents a day, a dense screen and speed are an advantage.
• Modernization doesn’t have to be a revolution. The goal was to move the system to the web without losing what worked. The same speed in tests was a concrete success for me.
• In a regulated field, I start by reading the rules. The records-management rules set the limits, so the first days were reading, not sketching.
• In the public sector, not everything depends on the project. A political decision can stop well-run work. It taught me to focus on what I can really influence and to be honest about what I can’t.