The clock was running on someone else's desk.

02 / Problem & audience

A familiar screen. An uncertain next step.

ITBA is the internal application Income Tax Department officers use to manage cases, track statutory deadlines, and record decisions. This case follows a single assessment proceeding - arrival, notice, referral, order - because that one sequence is where the department's statutory deadlines, handoffs between offices, and record-keeping obligations all land on the same desk at the same time.

Officers knew the procedure. The interface still made them reconstruct case history, interpret generic status labels, and hunt for the action that mattered.

03 / Role & constraints

Making room for clarity within real constraints.

As a Senior UX Designer, my contribution covered research synthesis, information architecture, wireframes, prototypes, and testing materials. I worked within a team of three designers, with a PM, engineers, departmental subject-matter experts, and reviewing officers.

04 / Research & findings

The workarounds revealed the problem.

Contextual inquiry, a procedural audit, and stakeholder workshops connected what officers did with what the process required. Prototype walkthroughs then tested the proposed structure.

Generalised observations from the study; these summaries are not participant quotations or measured production effects.

05 / Evidence review

Nine years of public record, read alongside the fieldwork.

Fieldwork tells you what is happening at a desk this month. It does not tell you what has already been tried, answered, and quietly allowed to return. So the officer research ran alongside a documentary review of the public record from 2017 to 2026 - association correspondence, the system owner's published responses to field complaints, security circulars, and the 2026 transition material.

Two reasons it was worth the time. ITBA serves roughly 45,000 personnel across about 780 offices, and no realistic sample speaks for that spread - the written record reaches parts of it fieldwork never will. It is also the strand that can be published: everything here is public-domain, which is why it carries citations where the fieldwork can only carry paraphrase.

The same complaint classes have persisted for eight years

This is the finding that changed the recommendation. Laid side by side, the 2018 record and the 2026 record describe the same categories of failure - and the 2018 responses show why.

Every 2018 response added capacity, added training, or reframed the problem as user error. Not one of them made the system's internal state visible to the person accountable for the case. That is the mechanism by which the same complaints came back - and the reason this project argued against leading with a redesign.

What the record says people do, as against what the rules say

The say-do gaps above came from watching officers work. These came from the documents - a harder kind of evidence, because each is a behaviour the organisation has written down about itself.

Read together with the observed gaps, the pattern is consistent enough to state as a principle: every one of these sits at a point where the system transfers cost to the user - time, uncertainty, or personal risk - and returns nothing. No status, no explanation, no control.

Forty-plus symptoms, six causes, and an honest line about which ones design owns

Collapsing the full symptom inventory produced six systemic causes. The column that matters most to me is the last one: a research recommendation that quietly implies design can fix infrastructure is a recommendation that will fail in front of an engineering lead.

Two of the six are the ones a disposal flow actually touches, so they are the two that shaped this work. The remaining four are real and were reported as found - they simply belong to the platform rather than to this case.

06 / Strategy & trade-offs

Prioritise the decision an officer needs to make.

Every decision below responds directly to one of the four research findings, rather than to a generic best practice.

07 / Workflow & wireframes

Four moments in one case's life.

Low-fidelity flows mapped a single assessment proceeding end to end before interface design started. The sequence below is that case. Each of the four moments is one where the answer to is this still mine? changed - and where the old screen left the officer to work it out.

08 / Testing & iteration

Three things testing made us change.

Wireframes and prototypes went back to participants from across the six cadres and to departmental stakeholders ahead of implementation - not for sign-off alone, but to test whether the model actually held.

How the sessions were run

Moderated, one officer at a time, on a clickable prototype. Tasks were framed as case work, not interface tasks - a case has come to you, take it as far as you can - so the officer chose the path rather than being walked down it. Nothing was explained in advance; where an officer asked what something meant, the question was the finding.

What each round tested, and what counted as passing

• Status recognition Could an officer tell a case's real state from the state label alone, without opening it? Passing meant naming both the state and whose turn it was, unprompted.
• Next-action clarity Did the visually primary action match what an officer would actually do first, unprompted? Passing meant reaching for it first, not arriving at it after a full scan of the screen.
• Recovery from a flagged mismatch Did an in-context validation message give enough to act on immediately? Passing meant correcting it without escalating, opening another screen, or asking a colleague.

09 / Final experience

The same case at four moments.

One assessment proceeding, shown at each of the four moments from the flow above. The Before column is the part worth watching: across all four it barely changes. The same field list, the same four equal buttons, the same word - Open - whether the case has just arrived or is twelve days from its limitation date. That is the finding, drawn rather than described.

ITBA holds live taxpayer data, so none of the real interface can be published. These are reconstructions - dummy references, invented case details, no departmental content. They exist to make the four decisions legible, not to reproduce what shipped.

Moment 1 - Arrival

Demonstrates case context that persists: identity, proceeding and the limitation clock in one place, before any field competes for attention.

Moment 2 - Notice issued

Demonstrates status states that mean something: an explicit record of what completed and what is now owed.

Moment 3 - Referred out

Demonstrates ownership in the status itself. This is the moment the old label was least useful, and the reason the project exists.

Moment 4 - Order

Demonstrates validation at the point of the mistake: the mismatch named where it occurred, rather than at the end of a submission.

Illustrative reconstructions only. No screen, field label, case reference, or record shown here is taken from the live system - the case numbers, dates, and masked references are invented for this page.

10 / Delivery & outcomes

What changed - and what the evidence supports.

The work produced a revised assessment flow, wireframes, prototypes, and testing materials. The evidence below comes from validation sessions and officer feedback; it does not establish a measured production improvement.

Delivery scope shown here: design and validation. The public case study does not specify rollout dates or implementation coverage. Operational time-to-resolution and escalation rates were not instrumented for a controlled before/after comparison.

What I would instrument, and why each one is narrow

No production metric was captured. That is a gap I can at least be specific about: each measure below tracks a behaviour this study watched fail, and would move only if one of the four design decisions worked.

That rules out the measures it would be most tempting to claim - dispatch time, processing delay, report freshness. The root-cause table above assigns those to queue throughput and management culture, which interface work does not control. A measure that cannot fail because of my work is not evidence for it.

One system-level measure belongs alongside these without belonging to this work: the share of orders pushed through manual upload. It needs no new instrumentation, and it converts a question about feelings into one about what officers do when nobody is asking. It tracks the computation-trust deficit rather than this interface, so it is not a claim I would make for this design - but it is the number I would fight hardest to have collected.

11 / Reflection & next steps

Keep the complexity. Make it navigable.

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.

What travels beyond assessment is the frame, not the screens. The five orientation questions are what any officer needs answered in any ITBA module, and the status vocabulary and in-context validation were built to be reused that way. The fields, statutory checks and sequence are assessment's own, and would have to be re-derived for appeals or exemption rather than copied across.