Background & Content
Risk & Analytics products were being delivered by independent Willis Towers Watson’s Risk and Analytics division builds data-driven tools used globally by underwriters, actuaries, and analysts. By the time I joined, the division had a portfolio of more than eight enterprise products, each built by separate squads, each with its own interface logic, component patterns, and visual language.
Nothing was shared. Nothing was consistent. And nobody had formally identified that as the problem worth solving.
This case study is about the design system that changed that. If you have read the GPD case study, you will have seen one example of what the system enabled. This is the story of how the system itself came to exist.
How it started
I led the initiative end-to-end — from auditing the existing design debt There was no design system brief. No dedicated team. No formal mandate.
What there was, was a division-wide effort to rebuild a family of ageing enterprise products, and a growing realisation partway through that work that rebuilding interfaces on top of a broken foundation would not solve the underlying problem. Every product was being designed and developed in isolation. Components were duplicated across codebases. Design decisions made on one product had no bearing on another. The inconsistencies were not just visual, they ran through the delivery process itself.
I identified the need, made the case for addressing it properly, and took on the system work alongside the product redesign that was already underway. That context matters because it shaped everything about how the system was built. It had to be practical and immediately useful, not a theoretical framework that teams would adopt eventually. Products were being rebuilt in parallel. The system needed to keep pace.
The Challenge
The scale of the design debt was significant. Dozens of different colour values, inconsistent type scales, spacing rules that varied by product, components that existed in multiple slightly different versions across multiple teams. Legacy Sketch files that could not support modern collaborative workflows. No documentation. No shared language between design and development.
The practical consequence was slow, unpredictable delivery. Designers were solving the same problems repeatedly. Developers were building from specifications that differed between products. QA cycles were long because there was no agreed reference point. And when something changed in one product, there was no way to propagate that change consistently across the others.
Building a design system was not the obvious answer to everyone at the start. It felt like additional scope on top of work that was already underway. The case I made was straightforward: the cost of not building it would compound with every product that shipped without it.
The Approach
I started with a thorough audit. CSS inventory across existing products, review of legacy design files, interviews with designers, developers, and product managers to understand where the real friction sat in the delivery process. The audit was not just about cataloguing inconsistencies. It was about understanding the working patterns that had created them, because a design system that does not fit how teams actually work will not get adopted regardless of how well it is built.
The Sketch to Figma migration happened as part of this phase. It was a necessary step rather than a centrepiece of the work.
From the audit I established the foundations: a tokenised colour system built around WTW’s brand refresh, a typographic scale on rem units, a spacing system, and an accessible component architecture designed to work across the full range of products in the division.
Every component was built to WCAG 2.1 AA from the start. Accessibility was not a pass at the end of the process. It was a constraint that shaped every decision from the foundations upward, which made compliance significantly easier to maintain as the system grew.
Building the system
Over 70 modular, responsive components were built and documented. The scope ranged from atomic foundations through to complex patterns specific to data-heavy enterprise contexts: data tables, filter systems, risk visualisation components, dashboard layouts.
Each component was documented in Zeroheight with usage guidance, behaviour notes, accessibility annotations, and developer specifications. The documentation was not an afterthought. Getting teams to adopt a shared system requires making it easier to use the system than to build outside it. That meant the documentation had to be genuinely useful rather than technically complete.
Tokens were aligned with front-end variables so that design decisions translated directly into code without interpretation. That single change, more than anything else in the process, reduced the gap between what was designed and what was built.
The rollout happened gradually and practically. Shared Figma libraries published to all squads. Onboarding sessions. Regular reviews with engineering leads. A feedback loop that allowed the system to evolve based on real usage rather than assumed requirements.
The Outcomes
The system became the foundation for rebuilding more than eight products across the Risk and Analytics division. GPD was one of them. Climate Diagnostic, Supply Chain Diagnostic, and others followed, all built on the same component library, the same token structure, the same documentation.
Design to development time dropped meaningfully in pilot projects as teams stopped solving the same problems repeatedly. Rework reduced because there was a shared reference point that both designers and developers trusted. Accessibility compliance became a baseline rather than a goal. And new products or features could be scoped and built significantly faster because the design decisions underpinning them did not need to be made from scratch each time.
The most significant outcome is probably the one hardest to measure. The division shifted from a way of working where design and development operated in loose parallel, to one where they shared a common language and a common source of truth. That shift outlasted the project itself.
Reflection
Building something at this scale without a dedicated team requires a particular kind of discipline. Every decision has to be made with adoption in mind, not just quality. A component that is beautifully built but difficult to implement will sit unused. Documentation that is comprehensive but hard to navigate will be ignored. The system only works if people use it, and people will only use it if it makes their job easier.
The thing I would do differently is formalise governance earlier. As the system grew across more products, versioning and contribution models became increasingly important and we were slower to establish those than we should have been. That is the work that keeps a system healthy over time rather than just at launch.
What this project demonstrated is that design systems are not a design team deliverable. They are organisational infrastructure. Getting that recognised early, and building with that framing in mind, was what made the difference between a system that got adopted and one that would have gathered dust.
A NOTE ON THE GPD CASE STUDY
The Global Peril Diagnostic was one of the first products rebuilt on this system. That case study covers the product redesign in detail, including how the design system work and the UX redesign ran in parallel and why that decision mattered. The two pieces are designed to be read alongside each other.