Government work teaches you humility fast. You can't assume your users have a fast connection, a new device, or perfect eyesight. You can't assume they chose to be using your system at all. When the brief is "build something that serves everyone," your design instincts get tested in ways that commercial projects rarely demand.
The Brief That Changed How I Design
Earlier this year we delivered a public-facing service for a government agency. The brief was straightforward on paper: a responsive web application that lets people find information, complete forms, and track their progress. Standard enough.
Then we started the user research. The people using this system weren't tech-savvy professionals on MacBooks. They were community workers on shared office computers. Older New Zealanders on tablets their grandchildren set up for them. People in rural areas where the internet drops out halfway through a form submission. People who navigate with keyboards because a mouse is painful.
That's when "responsive design" stopped being a technical checkbox and became a design philosophy.
What Government Taught Me
Clarity is not optional. In commercial design, you can be clever. You can use subtle visual cues, assume familiarity with common patterns, lean on animation to guide attention. In government digital services, clever fails. Every interaction needs to be obvious. Every label needs to say exactly what it means. Every error message needs to tell the person exactly what to do next.
I redesigned our form patterns three times on this project. The first version was clean and modern. The second was clearer. The third was clear enough that a person who'd never used a web form could complete it without help. That third version is the one we shipped, and it's the one I'm proudest of.
Font size matters more than you think. We set our base font size to 18px for this project after watching users in testing sessions lean forward to read 16px text on government-issued monitors. That 2px difference changed the entire feel of the interface. The content breathed. People stopped squinting. Reading speed increased visibly.
I've since adopted 18px as my default for any application where users will spend real time reading.
When you design for the person with the worst device and the least confidence, everyone benefits. That's just good design.
Rainui Teihotua
Chief Creative Officer
Testing With Real Public Servants
The most valuable two days of the project were the usability testing sessions. We sat in a government office in Wellington and watched actual public servants use the system. Not the project sponsors or the IT team. The people who would use it daily.
Three things came out of those sessions that we hadn't anticipated:
Tab order mattered enormously. Several users navigated primarily by keyboard, tabbing through form fields faster than mouse users could click. Our initial tab order followed the visual layout but didn't follow the logical task flow. We restructured the forms so the tab order matched how people actually think about the information.
Loading states needed to be explicit. On slower connections, there were moments where the interface appeared frozen. No spinner, no progress indicator, just silence. Users assumed it was broken and refreshed the page, losing their form data. We added clear loading indicators and saved form state on every field change. The frustration disappeared.
Colour alone couldn't carry meaning. We had error states marked only with red text. In testing, two users didn't notice the errors at all. One had colour vision deficiency. The other was using a low-contrast monitor. We added icons, border changes, and explicit text labels alongside the colour. The error discovery rate went to 100%.
What I Brought Back to Every Project
Government projects aren't glamorous. The budgets are tight, the approval processes are long, and the design constraints are real. But the discipline they demand has made every project since better.
I now test every design against these questions:
- Can someone complete this task on a five-year-old Android phone?
- Can someone who's never used this type of system understand what to do?
- Can someone navigating by keyboard get through the entire flow?
- Can someone with low vision read every piece of text?
Those questions aren't just for government work. They're for every enterprise system where the users didn't choose the tool and can't choose a different one.
The Gap in NZ
New Zealand is doing better than most countries on government digital standards. The Web Accessibility Standard is real and agencies are taking it seriously. But there's a gap between compliance and quality. You can pass a WCAG audit and still deliver a service that frustrates the people using it.
The opportunity for teams like IDESIGN is in that gap. Not just building systems that meet the standard, but building systems that genuinely serve the people they're built for. That requires design thinking, not just accessibility checklists.
Government work isn't where designers go to be creative. It's where they go to be useful. I'd recommend it to every designer who wants to get better at their craft.