Case Study · Government, Water Markets
Water Data,
Made Workable.
Regulatory water-trading platforms for the Bureau of Meteorology: dense rules made scannable.
In collaboration with the Bureau's design team.
The Challenge
Regulation is a reading problem first.
Australia's water-market reforms require near-real-time collection and publication of water-market decisions and trades. Behind every screen sits legislation, statutory data standards and provider obligations, and a go-live date set by parliament, not the project plan.
The design problem was making dense regulatory workflows readable enough that providers could comply, operators could monitor, and the public could trust what they saw.
1 July 2026
Legislated go-live for version 1, fixed before design began.
4 products
Provider portal, operator console, public website and data catalogue: one design language.
100s of pages
Of legislation, schemas and data standards translated into plain, scannable UI.
So I started where every provider does: the front door.

One Portal, Every Capability
Designed across the provider spectrum.
The same obligations bind a broker with an API team and an irrigation trust that submits one form a year. The portal had to fit both without forking.
Automated at scale
Design response
Machine-readable feedback, batch status views and clear schema errors, so failures surface without a phone call.
Occasional uploaders
Design response
Guided submission with validation at every step: errors caught in the form, not three days later in an email.
First-time, once-a-year
Design response
Plain-language flows that assume nothing. For some providers, this is the only government portal they touch.
Operators needed the opposite of onboarding: density, on purpose.

Readable also has to mean readable for everyone.

Delivery
Every screen answers to a use case.
End-to-end traceability, maintained: approved Figma designs embedded directly in development tickets, with UI reviews every sprint.
Legislation
Use case
Backlog
User story
Design
UX design
Delivery
Jira ticket
Shipped
Build & QA
Workstream 04 · AI Enablement
A Figma helper the designers could actually ask.
Government work cannot leave government systems, which rules out most of the AI tooling a design team would reach for. So I built the Bureau's designers a Figma helper agent in Microsoft Copilot, wired into Jira, Confluence and the rest of Atlassian. They asked it how to do things in Figma and Figma Make, and it coached them on writing prompts worth sending. The aim was a team that could prototype in Figma Make rather than hand-build every comp.
Inside the walls
Built in Microsoft Copilot and connected to the Bureau's own Atlassian stack, so nothing designers asked or shared left their systems.
Answers where they work
Figma and Figma Make questions handled in the tools the team already had open, without a tab switch or a licence request.
Teaches the prompt
Guidance on structuring a prompt properly, because a vague ask returns work nobody can use.
Aimed at speed
The point was designers prototyping in Figma Make instead of waiting on hand-built screens.
Outcome
Shipped on the day parliament picked.
1 July 2026
Version 1 live on the legislated deadline, a date set by parliament rather than the project plan.
4 products
Provider portal, operator console, public website and data catalogue: one design language across all of them.
WCAG 2.1 AA
Accessibility built into every reusable pattern from the first component, not audited in later.
The Water Data Hub was delivered by the wider Bureau program team, and recognised by Bureau leadership as delivered "on time, to scope and on budget."
My contribution, in collaboration with the Bureau's design team, sat in the UX/UI, accessibility and design-system stream supporting that launch.
Regulation is a reading problem before it's a compliance problem. Design for the reading, and the compliance follows.