Declaration Envelope Management

Arrow keys

Portfolio walkthrough · a recent project where I improved the user experience

The improvement was in the process

Ten minutes, in five parts — the change was in the process, and the interface had to carry it.

Declaration Envelope Management · Australian Electoral Commission · Indigo Program 2025–26

What we’ll look at, in order

  1. The process as it was Four lanes, twelve tasks, and the same details typed in three times
  2. The change Removing the duplicate handling rather than optimising it
  3. How the work was structured The backlog and the design file in the same shape
  4. The handover Page anatomies, the flows behind them, and the new components
  5. What remained What the team carried on using after the engagement

Before we start. The client’s screens do not appear here. Everything is rebuilt in my own design system with dummy data, and the process diagrams are drawn to explain the change — not lifted from the engagement.

Drawn from on-site observation, co-design, and the current-state record

The same information, handled again and again

Current state process model, four swimlanes A reconstructed swimlane diagram of vote envelope processing. An envelope arrives, the officer looks the record up on the old system and re-types the details into a second one, checks eligibility by hand and notes the outcome on paper. If oversight is needed the whole record is re-typed again for review. The decision is written on a paper register, collected in a batch and typed up later, with a chase-back loop when it does not match. The full step list is written out below the diagram. Envelope Processing officer Oversight Old system Vote envelopearrives Look up on theold system Re-type detailsinto the secondsystem Check eligibilityby hand Note the outcomeon paper Clear? Re-type it allfor oversight Review anddecide Record on thepaper register Register collectedin batch Type the registerinto the system Match? Chase themismatch Record stored clear second look yes no batch — not real time does not match typed 1st typed 2nd typed 3rd

Step in the process Same data entered again

The rule · attention on the judgement, not the data entry

Remove the duplicate handling rather than optimise it

Future state process model, four swimlanes The same reconstructed swimlanes as the current state. The envelope record is opened once, eligibility is derived from it rather than re-entered, oversight reviews the same record instead of a copy, the decision is recorded once and the two records match in real time. The removed steps are shown greyed out in their old positions. The full step list is written out below the diagram. Envelope Processing officer Oversight System no manual typing Re-type detailsinto the secondsystem Re-type it allfor oversight Register collectedin batch Type the registerinto the system Match? Chase themismatch the batch that no longer happens Vote envelopearrives Open the enveloperecord once Check eligibilityby hand Eligibilityderived, notre-entered Clear? Reviews thesame record Decisionrecorded once Matches inreal time clear second look

Step in the process Step that no longer exists

One designer, three solutions — developers had to find the design without asking me

The backlog and the design file were the same shape

The design file took the shape of the backlog: an epic is a solution and one Figma file, a feature is a page in it, a user story is a flow, and a sprint task is one part of that flow.

How the delivery backlog maps onto the design file A descending staircase of four levels. An epic is a solution and one Figma file. A feature is a page inside that file. A user story is a flow on that page. A sprint task is one part of that flow. Each level sits inside the one above it. EPIC A solution One Figma file · “Envelope Checking” FEATURE A page in that file “Voter Search and Matching” USER STORY A flow on that page Frames carry the story number SPRINT TASK One part of that flow Plus its page anatomy and states

The craft underneath

What a developer opens first

Handover was three things, not a folder of screens: the page anatomy, the flows behind it, and the components that were new.

The whole page on one frame — every component it uses and every state it can be in, assembled from the AEC design system the developers already worked in.

Then the notation. Every field, state and rule written on the artefact, so a developer does not have to ask.

Behind each anatomy, the flow — full screens, start to finish, with the interaction states in the order they happen.

And the states are only drawn for components that were new. Where the AEC design system had no pattern, I authored it and specified it here.

Page anatomy

What to build

1
2
3
4

One frame per page. Every state, every rule, written on it.

User flows

Why, and in what order

Full screens, start to finish. One flow per user story.

UI assets

What’s new to build with

Only what sat outside the AEC design system.

Indigo Core design system
Divisional officer · J. Nguyen

Process record

Processing interface Hidden in Review

There is a problem with this record

States

Enter a given name

On blur

Enter a given name.

Checked when the field loses focus — not while typing.

Match to electoral roll

0 results
Tran · 14/03/1961

No electors match this search

Check the date of birth, or search the roll by address instead.

Cancel

Enables when required fields are valid. Leaving keeps a draft.

The craft underneath

What a developer opens first

Then the notation. Every field, state and rule written on the artefact, so a developer does not have to ask.

User flows — one per user story

search
empty
invalid
confirm

Full screens, not fragments — so the developer can see the order, and what the officer sees when it goes wrong.

UI assets — the ones that were new

Outside the AEC design system — authored and specified here.

And each one, in every state

Rest

Hover

Selected

Label

Invalid

Disabled

The outcome

What was still there after I left

Every screen was assembled from components, and where the AEC design system had no pattern I authored it — a reviewed subset went into the core library for other teams.

Two of three built

Fully built at handover.

The core library

A reviewed subset, for other teams to reuse.

Notated specs

The wireframe was the developer contract.

Version-tracked

Component sets re-released, so teams did not drift.

What you have just seen

The improvement was in the process

Happy to go deeper on any part of it.

Declaration Envelope Management · Australian Electoral Commission · Indigo Program 2025–26

What remained

  1. Open the envelope record once Eligibility derived, not re-entered.
  2. Decision recorded once Matches in real time.
  3. Named the same Named the same in both places.
  1. The problem The same details typed in three times. The judgement itself was the fast part.
  2. The decision Remove the duplicate handling rather than optimise it — and two jobs, two interfaces.
  3. The handover Notated wireframes as the specification — every field, state and rule on the artefact.

A reminder. All of it rebuilt in my own design system with dummy data, and the process diagrams drawn to explain the change — not lifted from the engagement.

Full diagram