Building a Design System That Could Grow With the Product
Enterprise UX ✦ Product Discovery ✦ Information Architecture ✦ Strategic Design ✦ End-to-end UX
Context
This platform served five distinct user groups across multiple local authorities, supporting everything from food licence applications through to inspections and enforcement. Alongside the broader UX work, I took ownership of the design system within this environment, building a shared foundation that could scale with the team and stay practical under real delivery pressure.
Company
Enterprise Creative Cloud
Platform
Mobile and Desktop - Web, Tablet - Native
Duration
Apr 2022 - Ongoing
My Role
Lead designer - Design Systems
Context
Understanding the Problem
Working within a small technology company building enterprise compliance software meant design decisions rarely existed in isolation. The platform served five interconnected portals across five distinct user groups, each operating in different contexts, on different devices, with different professional pressures.
As part of a two-person design team, I took ownership of the design system. The product was growing quickly, timelines were demanding, and there was no room for a system that required constant maintenance or explanation. It had to be clear, scalable, and useful to the people building with it every day.
The challenge of consistency across complexity
Five portals. Three device types. Users ranging from business owners completing licence applications on their phones, to Environmental Health Officers conducting inspections on tablets in commercial kitchens.
The challenge was not simply visual consistency. It was designing a shared foundation that could flex across genuinely different contexts without losing coherence. Forcing identical patterns across all five portals would have ignored meaningful contextual differences. Designing each portal independently would have fragmented the experience and made the product unsustainable to maintain.
The system needed to hold both of those realities at once.
The approach: Atomic Design
I structured the system using Atomic Design principles, working from the foundational level upward through five layers of composition: Atoms, Molecules, Organisms, Templates, and Pages.
The value of this methodology in a multi-portal, multi-device product was significant. Decisions made at the atomic level cascaded naturally through every layer above. A spacing value defined once propagated consistently across components, layouts, and pages without requiring repeated specification. A colour decision made with compliance semantics in mind carried that meaning wherever the colour appeared.
Each layer had a clear role. That clarity made both design and development more predictable.
Patterns that emerged from real product problems
Some of the most useful parts of the system were not planned from the beginning. They emerged from noticing where the product was creating unnecessary friction, and formalising a better approach.
The Record Viewer
I formalised this into a deliberate, reusable structure and applied it consistently across every record type in the product.
The impact was meaningful. Users moving between an inspection record and a business record encountered the same structural logic. The cognitive effort of navigation reduced. The pattern also made new record types faster to design and implement, because the decisions about structure had already been made.
Records sit at the centre of the platform. Inspection records, business records, event records, enforcement records. Each carries a significant volume of information and supports a range of actions depending on user role and context.
In the earlier stages of the product, each record type had been approached somewhat independently. The result was a product where the underlying logic was consistent, but the experience of navigating between record types felt slightly disorienting. Users had to reorient themselves each time.
The pattern that had emerged across different record types was already doing most of the right things.