Research · GovDigital redesign
How research shaped the redesign.
When the redesign started, I didn't want research to become a checklist of UX activities. Every method had a specific purpose and helped answer a different question about the product from mapping the ecosystem to building the Lazuli design system.
01 · Working Principles
Lessons from the process
01
Research comes before design.
Every feature started with a problem statement, not a Figma file. By the time interfaces were designed, the hard product decisions had already been discussed and documented.
02
The support team is research.
Support agents talked to municipalities every day. Their tickets and calls surfaced usability issues and feature requests that rarely reached the product backlog.
03
Assumptions aren't evidence.
The CSD Matrix separated what we knew from what we believed. It kept the team from jumping into solutions before the problem was clear.
04
Deliverables that keep working.
Personas, journey maps and workflow diagrams weren't handoff artifacts. They became working documents the team returned to when priorities shifted.
05
A shared language scales design.
Lazuli wasn't about reusable components. It was a common vocabulary between design and engineering as the product kept growing.
02 · CSD Matrix
With Product Owner & stakeholders
The first step was understanding the ecosystem. Together with the PO and stakeholders, we mapped business goals, technical constraints, ongoing initiatives, and assumptions that still needed validation — separating what we knew from what we believed and what still depended on evidence.
Certainties
- 01Municipalities used GovDigital daily to manage public services.
- 02Support handled recurring questions the backlog never captured.
- 03Different features had drifted into inconsistent patterns and spacing.
Suppositions
- 01End users struggled more with navigation than with individual features.
- 02Municipal stakeholders prioritized reliability over new functionality.
- 03A shared design language would reduce rework across teams.
Doubts
- 01Which flows caused the highest support volume?
- 02How much of Material Design 3 should Lazuli adopt directly?
- 03Where were teams solving the same problem in different ways?
03 · Affinity Wall
Support team · Municipal stakeholders · Desk research
Rather than relying only on end users, I spent time with the support team and joined meetings with municipal stakeholders. Their conversations, combined with competitive analysis of public and private digital services, surfaced the patterns below.
Cluster 01 · Support team interviews
Recurring support questions
- Note · 01"The same questions come back every week — we know exactly where people get stuck."
- Note · 02"Municipalities call us before opening a ticket. Half of it never reaches the backlog."
- Note · 03"There are workarounds we've been explaining for years."
Cluster 02 · Stakeholder conversations
Municipal operations
- Note · 01"Each municipality has its own routine, but the pain points overlap more than we expected."
- Note · 02"Digital services need to fit the reality of small teams doing many roles."
- Note · 03"Priorities depend on who's managing the service that quarter."
Cluster 03 · Product audit + desk research
Inconsistent patterns
- Note · 01"The same action looked different depending on the feature."
- Note · 02"Spacing, components, and language had drifted screen by screen."
- Note · 03"Public and private digital services showed patterns worth borrowing — carefully."
04 · Workshop Board
Recurring reminders across sessions
Note 01
Map the ecosystem before the screens.
Note 02
Support tickets = unfiltered research.
Note 03
Separate what we know from what we assume.
Note 04
Every requirement starts with a problem statement.
Note 05
Design system as shared language, not component library.
Note 06
Complexity is the material — don't design around it.
05 · Journey Map
From insight to requirement
Insights from research became personas, empathy maps, journey maps and workflow diagrams — working documents the team returned to as priorities shifted. Only after discovery felt mature did I begin defining product requirements: problem statement, functional requirements, flows, edge cases.
Phase 01
Ecosystem
Phase 02
Qualitative
Phase 03
Desk research
Phase 04
Synthesis
Phase 05
Requirements
Phase 06
Design
Align
Map goals, constraints and assumptions with PO and stakeholders.
Listen
Support team + municipal stakeholders. Ticket patterns, real routines.
Compare
Public and private digital services — navigation, accessibility, IA.
Organize
Personas, empathy maps, journeys and workflow diagrams.
Define
Problem statement, flows, edge cases, interaction documentation.
Ship
Figma exploration on decisions already validated and documented.
06 · Lazuli Design System
Inspired by Material Design 3
Why Lazuli
A shared language between design and engineering, not just a component library.
As more features shipped, different interaction patterns, spacing rules and components started to emerge across the product. Instead of solving consistency one screen at a time, I proposed Lazuli — a design system inspired by Material Design 3 and adapted to GovDigital's ecosystem.
The intent wasn't reusable components alone. Lazuli established a common vocabulary that could support the product as it kept growing — so design and engineering could discuss decisions using the same references.
Foundations
Color, type, spacing, elevation adapted from MD3.
Components
Documented patterns tied to real product flows.
Language
Shared vocabulary across design and engineering.
"The biggest lesson wasn't about any individual research method. Good product decisions emerge by connecting different perspectives, validating assumptions continuously, and making sure every design decision can be traced back to a real user or business need."