Requirements surfaced too late.
What documentation a bill needed wasn't clear until it had already entered review, turning avoidable gaps into correction cycles.
03 / GovTech / UX Research
CGDA
Making a five-role bill-clearance process visible
A research-led redesign of a multi-stage defence accounting workflow — starting from where the process actually broke, not from the screens.
Context
One bill, five roles, no shared view of where it stood.
Employee bill clearance at the Comptroller General of Defence Accounts moves through preparation, review, correction, and approval — different people, different responsibilities, different information needs, one workflow. I worked on the internal websites, applications, and accounting system supporting that process. Because it involves financial and employee data, this case study is a sanitised reconstruction — no real screens, records, or figures.
- Organisation Comptroller General of Defence Accounts (CGDA)
- Contribution UX research, process mapping, information architecture, wireframes, prototypes, and testing plans
- Status Professional work, presented here as a sanitised reconstruction
- Constraint No confidential screens, employee data, or financial records shown
Research & discovery
Map the process before touching the product.
The brief could have started with the existing screens. It started with the process instead — because a bill's five roles each had a different relationship to the same workflow, and no single screen audit would have surfaced that on its own.
Process mapping across every role
Working sessions with people at each stage of bill clearance — preparers, reviewers, approvers — traced the actual sequence of activities and decision points each role went through, rather than the org chart's idealised version of it. The gap between the two turned out to be most of the problem.
Auditing where paper habits still filled the gaps
Wherever the internal system fell short, an informal paper-based workaround had usually grown up to cover it — a separate reference sheet, a phone call, a physical file passed between desks. Mapping those workarounds against the digital system showed exactly where the designed process and the lived process had drifted apart.
Structuring around blockers, not screens
Findings were organised by what stopped a bill from moving to its next stage, rather than by the individual pages of the existing system. That reframing is what turned a screen-by-screen audit into a process-level diagnosis. Four blockers recurred often enough to drive the design direction:
"Pending" meant five different things.
A bill marked pending could be waiting on review, correction, or approval — or nothing at all — with no way to tell which without asking someone.
Every role saw the same flat view.
Reviewers and approvers worked through the same undifferentiated screen a preparer used, with no structure suited to what their part of the job needed.
A returned bill lost its history.
Corrections weren't connected back to what had been flagged, so a returned bill often meant re-learning the objection from scratch.
A sample of the recurring patterns behind that grouping, described in generalised terms:
Requirements
Required supporting documents for a bill type lived in a separate reference sheet, not the submission screen itself.
Requirements
Bills entered review missing attachments preparers had no way of knowing were mandatory until the rejection arrived.
Status
A "pending" label covered four distinct real states, with no way to tell which applied without contacting someone directly.
Status
Employees routinely called or visited the accounts office solely to ask where a bill currently stood.
Roles
Reviewers and approvers scrolled the same long, undifferentiated form a preparer used to enter the bill originally.
Roles
Nothing on screen distinguished which fields mattered to a reviewer's decision from which were preparer-only detail.
History
A correction request and the resubmitted bill lived in different places, with no visible link between the two.
History
Re-diagnosing an old objection after a bill's second or third return was common, since nothing preserved it in context.
This work involves financial and employee data, so specific figures and individual identities from the original process can't be published — the findings above are described in generalised form.
Design decisions
Make the next responsible party as visible as the status itself.
Each decision responds directly to one of the four research findings above.
- Requirements surfaced during preparation Organised required information and supporting documents around the bill-clearance task itself, so gaps showed up before submission, not after.
- Status as a stage, not a word Distinguished preparation, review, correction, and completion explicitly, so a bill's state also implied who needed to act next.
- Navigation split by responsibility Structured menus and tabs around each role's actual task, while keeping the fuller history reachable for anyone who needed it.
- Corrections tied to their cause Connected a flagged issue to the exact part of the submission it came from, so a returned bill kept its context instead of losing it.
Workflow
A visible path from preparation to approval.
Wireframes and prototypes made the proposed sequence reviewable before implementation, stage by stage.
1
PrepareRequired fields and documents surface as part of preparing the bill, not discovered later in review.
2
ReviewThe reviewer's view prioritises submitted evidence and exceptions over a flat copy of the preparer's screen.
3
FlaggedResolved
CorrectA returned bill shows exactly what was flagged and where, instead of the whole submission going back as a blank slate.
4
ApproveFinal approval shows the decision trail — what changed, what was reviewed, what remains — before it's finalised.
Validation
Test the workflow against every role it touches, not just one.
Because five different roles depended on the same record, prototypes were tested with preparers, reviewers, and approvers separately — checking whether the reworked structure actually served each role's part of the job:
- Preparation completeness Could a preparer tell what a bill needed before submitting it, without consulting a separate reference sheet?
- Review focus Did the reviewer's view surface exceptions and evidence first, instead of asking them to scan the full preparer form?
- Correction recovery Could a preparer see exactly what was flagged on a returned bill without re-reading the original objection from scratch?
Outcome
What changed, stated plainly.
Quantitative operational results from a defence accounting system can't be published. What follows is what changed structurally between the old process and the new one, and why it mattered to the people using it.
| Capability | Before | After |
|---|---|---|
| Bill requirements | Listed in a separate reference document | Surfaced inline during preparation, before submission |
| Bill status | A single "pending" label for four different real states | Explicit stages — preparation, review, correction, completion |
| Reviewer view | Identical to the preparer's full entry form | Prioritises evidence and exceptions relevant to review |
| Corrections | Disconnected from the original flagged issue | Tied directly to the specific field and objection |
Ownership became visible
A bill's status started implying who was responsible for the next move, cutting down on status-check enquiries between departments.
Fewer correction cycles
Surfacing what a bill needed during preparation reduced how often bills were bounced back purely for missing documentation.
Faster recovery from a return
Tying a flagged issue to its source meant a returned bill didn't require re-diagnosing the original objection from scratch.
Reflection
The research was the design work.
Nothing in the final structure came from a best-practice checklist. Every decision traced back to a specific blocker surfaced by mapping the process across five roles instead of one screen at a time. A bill-clearance interface does more than collect data — it has to help five different people trust the same record of a decision, and that only comes from understanding how each of them actually works, not just what they click.