Testing a design system against real citizens, not just designers

The NSW Digital Design System gave teams reusable foundations for public services. Each pattern could influence many journeys, so a weak convention would not remain a local design problem. It could make important citizen tasks harder across multiple agencies.

Consistency was valuable, but not the goal itself. The system needed clear, reusable direction without forcing unlike citizen tasks into the same interaction simply because a pattern already existed in the library.

Agreement among experienced designers was not enough to establish a pattern. Reviews revealed implementation concerns, but could not show whether citizens understood the resulting task. Internal familiarity risked being mistaken for public clarity.

We made citizen testing the release threshold. I took patterns into realistic service tasks, observed where people hesitated or misread the next action, then returned that evidence to the system team. Patterns progressed because citizens could use them, not because they looked settled in a library.

I designed and validated more than ten patterns, moving between interaction detail and conditions for reuse. Tests focused on comprehension, next action and recovery rather than preference. Findings were recorded against decisions so later teams understood why the guidance existed.

Evidence changed what we shipped. Patterns that worked across tasks progressed with usage guidance; those with recurring hesitation were revised and tested again. When behaviour depended strongly on service context, we documented the choice rather than pretending one arrangement was universal.

I did not standardise every variation we encountered. Some differences carried policy meaning or reflected task risk, which absorbing them into one component would hide. We deferred those cases until more services could provide evidence for a safe shared rule.

More than ten patterns were researched, tested and validated for the NSW Digital Design System. Citizen evidence joined design review and implementation needs in release decisions; unsupported patterns were revised rather than gaining authority through repetition.

Service teams received guidance on when a pattern applied, what testing supported and where judgement remained necessary. This made the limits of reuse explicit rather than leaving each team to infer them from the component. The broader effect on service completion was not measured.

A reusable pattern ships when people outside the team can use it, not when the team agrees it looks right. Real service tasks exposed where internal convention and public clarity parted ways. I now capture evidence consistently from the first test, so patterns can be compared and revisited as services change.