TL;DR
- Context: ~13 months as sole UX and lead of the modernization of a nationwide public-administration document-flow system.
- Problem: The system ran on desktop since 2003; it needed to move to the web, in a domain regulated by chancellery instructions, without slowing down its power users.
- What I did: Led the system’s modernization (correspondence-registration module + widget dashboard) onto a web architecture, designing for experts, not beginners.
- Result: Brought the project to ~95% completion; testing confirmed speed parity with the old system; scale ~210+ institutions across Poland.
Diagnosis
Two tensions drove the whole project. First: modernize legacy without losing what worked — power users (civil servants) loved the old desktop for its speed and for having everything at hand at once. Second, and more important: design for experts, not for beginners. The conventional UX instinct — whitespace, wizards, step-by-step — would have slowed these people down dramatically. The whole project rested on one rule: don’t “dumb down” the system.
What I did
- Led the modernization of the entire system from desktop to web — I was the sole UX, setting the direction from day one.
- Designed the incoming-correspondence registration module: fast entry (reduced to ~6 key fields) plus advanced filters with saved presets.
- Designed a configurable widget-dashboard — cross-module: widgets from multiple modules (leave requests, cases, passes) on one screen, picked for the user’s context (analogy: Jira dashboards).
- Ran ~10 in-depth ethnographic studies + shadowing sessions in ministries and regional government offices, plus iterative usability testing (≥2 rounds) on clickable Axure prototypes.
flowchart LR
A["Document arrives at the office"] --> B["Web registration<br/>~6 key fields"]
B --> C["Categorization / routing to module"]
C --> D["Widget-dashboard<br/>info from multiple modules"]
D --> E["Clerk / 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
- Brought the project to ~95% completion (handed off — see “How it turned out”).
- System scale: ~210+ institutions across Poland; in 2015 only ~32% of offices had any electronic document management — a large modernization gap.
- Speed parity confirmed in testing: the time to register a piece of correspondence in the new web module matched the old desktop. The goal was “modernize without losing speed” — and that held (round-2 tests).
- Reduced initial registration to ~6 key fields (the rest optional), preserving fast entry of large volumes of incoming mail.
- Built the widget-dashboard as a platform-level, modular layer — one place for contextual info pulled from many modules.
| Metric | Value |
|---|---|
| System scale | ~210+ institutions across Poland |
| Document-management adoption (2015) | ~32% of offices |
| Project team | ~8–9 people (3 BAs, 3–4 devs, 1 UX) |
| Duration | ~13 months |
| Readiness at handoff | ~95% |
The problem
What was the old system like?
A desktop application from 2003. Power users — clerks registering hundreds of documents a day — genuinely valued it, because the correspondence-entry screen had every function visible at once. Some they used on every entry, others rarely. It was a dense, expert interface built for speed. But it was hard to maintain, inflexible, and desktop-only — while directors needed access to correspondence from mobile devices.
Why was it hard?
This was the crux. The standard, “modern” web UX — lots of whitespace, wizards, one step at a time — would have looked great in screenshots but slowed clerks processing a heavy volume of records each day down to a crawl. The instinct said “simplify and declutter”; the real needs said the opposite: keep the density, because density is speed. On top of that, a heavily regulated domain — the first days of the project were reading the chancellery instruction that dictated what was even possible.
My role / scope
- Sole UX and lead of the modernization. I set the conceptual direction for the whole thing; business analysis was run by 3 BAs, the build by a team of 3–4 devs, the process was Scrum/sprints (the first place in my career with a proper Agile implementation).
- A team of ~8–9. I worked mostly with the business analysts (identifying the ~6 key fields was a joint effort) and the dev team.
- The insight from shadowing — that power users needed density, not simplification — was mine; it shaped the entire direction of the project.
Process
- Ethnography + shadowing (contextual inquiry) — ~10 in-depth sessions in ministries and regional government offices: mapping the clerks’ actual workflow before I designed anything.
- Clickable Axure prototypes → iterative usability testing (≥2 rounds). Round 1 produced feedback on required fields → shaped the ~6-field set. Round 2 confirmed the revised form was effective and reached speed parity.
- Scrum/sprints throughout; findings from research kept reshaping our take on scope.
flowchart LR
A["Ethnography + shadowing<br/>~10 sessions"] --> B["Axure prototypes"]
B --> C["Round 1 testing<br/>feedback on fields"]
C --> D["Round 2 testing<br/>speed parity confirmed"]
D --> E["~95% completion"]
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
- Don’t “dumb down” the system — design for experts, not beginners. The keynote insight of the whole project. Conventional UX (whitespace, wizards) would have slowed power users down. A dense interface where everything is within reach was deliberate, not unfinished. This is the most important lesson I carry forward.
- Fast entry reduced to ~6 key fields. Initial correspondence registration captures only what’s necessary; the rest is optional. Speed of entry for large mail volumes is preserved.
- Advanced filters + saved presets. Filtering across large data volumes plus predefined/saved views for frequent queries — a clerk doesn’t set filters from scratch every day.
- Cross-module widget-dashboard. Instead of many separate screens — one configurable dashboard where the user picks widgets from different modules (e.g., a manager: a leave-approval widget + a newly-assigned-cases widget). Analogy: Jira dashboards. This is platform-level, modular thinking.
- Mobile for browsing, desktop for entry. Registration stays on desktop computers (large volume, speed), but access to browse and manage correspondence has to work on mobile — directors and people involved in cases reacted on the go.
- Regulated domain — the chancellery instruction sets the bounds. The first days of the project are reading the regulation; that determines what can even be designed. High responsibility, no slack.
How it turned out
The project reached ~95% completion, and was then handed to another government unit as part of a reorganization and government decision. Unfortunate for the project, but that’s the reality of public-sector work — political and organizational decisions overrule any single project. The value I built (the research, the density insight, fast-entry, the widget-dashboard) was developed and finished outside my hands.
What I took away
- Designing for experts ≠ designing for beginners. The strongest lesson. Not every “modern, simple” decision is right — for power users, density and speed are features, not bugs.
- Legacy modernization is parity, not revolution. The goal wasn’t “build something entirely new”; it was “modernize without losing what worked.” Speed parity in testing was a hard success.
- Regulated domains demand humility at the start. The chancellery instruction set the bounds; the first days were reading, not sketches.
- The reality of public-sector work. Political decisions can undo years of good work — that taught me to value the scope I can actually influence, and to frame honestly what lies outside it.