Case study · KPMG
Design system
There was no design function and no shared language. I set both up, so the product suite could stop rebuilding the same components.
- My role
- Product designer
- Timeline
- 2022 - present
- Built with
- Figma · Blazor components · Docs site
- Stage
- In use across the Tax Technology product suite
01 Context & ownership
Every product was solving the same problems again
When I joined KPMG UK's Tax Technology practice, there was no product design function and no shared design language. Each product had its own buttons, forms and layouts. Clients moving between our tools met a different experience each time.
Without shared components, designers and engineers rebuilt the same things for every project. Handoff meant long specs and back-and-forth over details that should already have been decided.
I set up the design function and built the design system from scratch: the Figma library, the component standards and the documentation. I worked with engineering to make sure the coded components matched the designs.
02 Design decisions
Three decisions shaped the system.
1. Write the docs for engineers too
Each component page shows a live preview, the Blazor code and the props side by side. An engineer can see the component working and copy what they need without opening Figma.
The trade-off: docs and code must stay in step. A page that drifts from the real component does more harm than no page.
2. Build accessibility into the component
Keyboard support and the right roles live inside each component, so every product gets them by default. Teams do not need to remember them project by project.
The trade-off: components take longer to build the first time. That cost is paid once, and every product after that gets it for free.
3. Make status and change visible
Each component shows whether it is stable, and the docs carry a version number and release notes. Teams can see what is safe to use and what changed since they last looked.
The trade-off: versioning adds process. It is worth it once several products depend on the same components.
03 A closer look
Anatomy of a component page
The Accordion page above shows the pattern every component follows.
- A description of when to use it.
- Tags for the framework, accessibility and status.
- A live preview you can click, with the code and props one tab away.
- Search and a side menu, so any component is a click or two away.
04 Results & next steps
What changed
With the system in place, handoff time dropped by 66% and product launches got 75% faster. Every product in the suite now follows the same standard.
It also changed how the product and engineering teams work with design. Less time goes on settling details the system has already decided.
What comes next
- Grow from single components to whole flows that teams can reuse.
- Keep the docs and code in step as the system grows.
- Use the system as the base for AI-assisted builds, so generated UI stays on-brand.