Status didn't answer the real question.
A status label was visible, but not whether anything was actually blocking progress, or whose turn it was to act next.
02 / GovTech / Enterprise UX
ITBA
Making case-disposal work legible for tax officers
Reorganising a dense, procedure-driven workflow so an officer can see status, risk, and the next required action at a glance.
Context
Expert software for people who can't afford to guess.
ITBA is the internal system Income Tax Department officers use to work case disposal — resolving assessments, tracking statutory deadlines, and recording decisions that carry legal weight. The users are domain experts, the information is dense by necessity, and an unclear interface doesn't just cost time — it risks a missed deadline or an incomplete decision on a real taxpayer's record. Because ITBA holds sensitive taxpayer and departmental data, everything shown on this page is a reconstructed, sanitised approximation, not the live system.
- Organisation Central Board of Direct Taxes, Income Tax Department
- Contribution Research synthesis, information architecture, wireframes, prototypes, and testing materials
- Status Professional work, presented here as a sanitised reconstruction
- Constraint No real screens, taxpayer data, or officer identities can be shown
Research & discovery
Start with how an officer works a case, not how the system models one.
The starting question wasn't "how do we redesign these screens" — it was "where does an officer's confidence actually break down while working a case." That meant understanding the workflow before touching the interface.
Contextual inquiry with case-handling officers
Sitting with officers while they worked live cases — not asking them to describe the process from memory — surfaced where they actually paused, backtracked, or cross-checked another screen to stay oriented. That distinction mattered: officers rarely flagged these moments as problems in interviews, but the hesitation was visible in how they worked.
Auditing the existing flow against procedure
Every field, action, and dependency in case disposal was mapped against the department's own procedural requirements, one by one. The goal was to separate what was genuinely mandatory from what had simply accumulated as legacy interface debt — screens that asked for information the process no longer required, or in an order the procedure no longer dictated.
Requirement workshops with the business team
Simplifying the interface couldn't mean hiding information an officer needed to justify a decision later. Structured workshops with the departmental business team pressure-tested every proposed simplification against that constraint before it went anywhere near a wireframe.
Synthesis against five orientation questions
Every friction point surfaced by the three methods above got grouped by which of five things it obscured for an officer: what case, what's happened, what needs attention, what can I do, what happens next. Four problems recurred often enough to drive the design direction:
The one action that mattered got lost in the density.
Dense screens gave every field equal visual weight, so the single next step competed with a dozen fields that weren't relevant yet.
Context didn't travel with the officer.
Moving between related parts of a case meant reconstructing what had already been established, screen by screen.
Validation caught mistakes too late, or not at all.
Some required checks only surfaced at the very end of a workflow, after the cost of fixing them had already multiplied.
A sample of the recurring patterns behind that grouping, described in generalised terms:
Status
An officer could see a case marked "open" or "closed" but nothing indicating who needed to act on it next.
Status
Cases informally described as "stuck" rarely looked any different on screen from cases moving normally.
Density
A single case-work screen carried dozens of fields with identical visual weight, mandatory and optional alike.
Density
The action an officer actually needed next was frequently the least visually prominent element on the screen.
Context
Moving from a case summary to a related document meant the case's identity and status left view entirely.
Context
Officers re-checked the same case header multiple times per session just to stay oriented.
Validation
Several required checks only ran on final submission, well after the relevant data had already been entered.
Validation
A missing or inconsistent field could pass silently through multiple stages before surfacing as a rejection.
ITBA handles live taxpayer and departmental data, so specific screens and officer identities from this work can't be published — the findings above are described in generalised form, consistent with departmental confidentiality requirements.
Design decisions
Answer five questions before optimising anything else.
Every decision below responds directly to one of the four research findings, rather than to a generic best practice.
- Status states that mean something Replaced generic open/closed labels with explicit states — incomplete, ready for review, awaiting another party, resolved — so an officer could read progress at a glance instead of inferring it from individual fields.
- One clear next action per screen Separated primary actions, supporting information, and secondary controls into a visible hierarchy, instead of presenting every system capability with equal weight.
- Case context that persists Kept identity, proceeding, and status available as an officer moved between related tasks, instead of requiring the context to be rebuilt on every screen.
- Validation moved to the point of the mistake Surfaced missing or inconsistent information next to the relevant field, with plain guidance on what needed attention, instead of failing an entire submission at the end.
Workflow
Sequence and dependency, sketched before any pixel was final.
Low-fidelity flows mapped the sequence of a proceeding before interface design started, to confirm the order made sense to the officers who'd actually use it.
1
Case entryIdentity, proceeding, and current status appear together, before anything else competes for attention.
2
On trackNeeds a look
Status & riskThe one blocking issue, if there is one, gets top billing over the fields that aren't blocking anything.
3
ActionThe primary action stands alone; supporting detail and rarely-used controls step back.
4
ReviewEverything about to be submitted is shown together, with an explicit point to stop and reconsider.
Validation
Check the model against the people who'd actually use it.
Wireframes and prototypes went back to case-handling officers and departmental stakeholders ahead of implementation — not for sign-off alone, but to test three specific things testing materials were built around:
- Status recognition Could an officer tell a case's real state from the state label alone, without opening it?
- Next-action clarity Did the visually primary action match what an officer would actually do first, unprompted?
- Recovery from a flagged mismatch Did an in-context validation message give enough to act on immediately, without needing to escalate or ask a colleague?
Outcome
What changed, stated plainly.
Exact operational metrics from a live departmental system can't be published. What can be shown honestly is what changed structurally between the old flow and the new one, and why that mattered to the people doing the work.
| Capability | Before | After |
|---|---|---|
| Case status | A generic open / closed label | Explicit states — incomplete, ready for review, awaiting another party, resolved |
| Primary action | Buried among a dozen equally-weighted fields | Visually distinct from supporting detail and secondary controls |
| Case context | Rebuilt manually on every related screen | Persists — identity, proceeding, and status stay visible |
| Validation | Surfaced only at final submission, if at all | Flagged next to the exact field, before submission |
Status became a decision aid, not a mystery
An officer could tell whether a case needed attention without opening it — the state itself carried the answer.
The next step stopped competing for attention
Separating the primary action from supporting fields removed the need to hunt across a dense screen for what to do next.
Mistakes surfaced where they happened, not after
Catching a mismatch next to its source, before submission, closed the most common rework loop officers pointed to in this process.
Reflection
Complexity isn't the enemy — unlabelled complexity is.
The rules, exceptions, and accountability requirements inside ITBA are real; removing them was never the brief. The work was to make that complexity navigable — to surface the right information at the right moment, and let officers act with more confidence on decisions that carry real legal weight.