Building Enterprise-Scale Design Systems for Multiple Product Suites

About

Cross-platform design systems and pattern libraries for AI and SaaS product suites in healthcare and life sciences. The work spans stakeholder interviews, ecosystem audits, fresh AI product component discovery to build PoCs, and MVPs across web, mobile, and tablet experiences built with React, Angular, Vue, Veeva systems, and native iOS.

Challenge

Different technology stacks, legacy interfaces, and release constraints meant a shared design couldn’t always be implemented in the same way. The design system needed to establish where consistency mattered and where teams could adapt, with patterns that worked across environments.

At the same time, we needed to build the design system from the ground up to support AI-native products and tools that combined AI with automation workflows.

Outcome

The systems are now used across 40+ products in four business lines. Shared tokens, components, and interaction patterns give teams a foundation they can adapt to their workflows and technical constraints.

Implementation guidance connects Figma specifications with Storybook and production review, giving design and engineering a common reference for behaviour, reuse, and necessary variations. Consistency extends into how the products are built and maintained as the ecosystem grows.

✦ Introduction

When working on enterprise-scale design systems, I start by zooming out and looking at how the product suites connect, operate, and evolve. Typically, I’m part of a lean cross-functional pod: one senior and one junior from the client team, with me leading design. We dig into actual workflows, user journeys, and tech ecosystems.

I start with research. Designers and developers across internal, vendor-side, and cross-product teams have different needs. A team building a conversational AI interface thinks differently from someone working on a supply chain content platform. Before building a component library, I begin with a workflow audit to understand how and why each pattern exists.

✦ Starting with a product ecosystem audit, not a component library

I map the key systems in play, including internal portals, third-party tools, and headless platforms, then audit the workflows, components, and patterns in use. Alongside documenting what exists, I ask: Why was this layout chosen? What friction points do users face? Are these patterns optimised for how and where people actually work?

✦ Designing for multiple viewports

In manufacturing and supply chain environments, users often rely on tablets or large-format desktops on the shop floor, while quick mobile inputs are used for incident logging. Desk jobs need detailed dashboards on laptops or desktops.

I also look at the technical proficiency of each user group and how they will be using it in their real work environments - research labs, manufacturing setups, admin offices, etc.

✦ Designing for varying use-cases across product teams & users

Sometimes it makes sense to offer components with similar application logic because different projects and users need different options.

Toast Messages: We identified two types in our audits: a long banner at the top centre for desktop, and a bottom-right corner toast. Mobile users tend to prefer the bottom-right. Both styles offer similar usability benefits, so I keep both options available, provided they’re used consistently within a portal without mixing the two.

In-line Citations: Hover citations aren’t always feasible for back-end teams in a first release, so I designed a simpler option: users click the citation number to view references in a side panel or on a separate page.

✦ Prioritising patterns over components at scale

What starts as a single component, such as a button, card, or input, becomes part of a pattern in context. A card becomes a dashboard module. A table combines with filters, bulk actions, and pagination to form a data-management pattern.

I build with reusability and modularity in mind. Tokenising small design decisions gives me pieces I can combine into patterns for everything from GenAI interactions to supply chain escalation flows. The patterns need to work across different user roles, environments, and intents without breaking consistency.

✦ Launching GenAI-focused components, patterns, and hybrid components

Designing for GenAI means accounting for its logic and behaviour throughout the system. One principle I use is to help users visually distinguish between automated flows and GenAI-driven actions, so they understand what’s happening and can trust the system.

Across conversational platforms, document generation tools, and simulation systems, I’ve found pattern needs specific to each context. In a conversational AI interface, a chat bubble and system response pattern work alongside a “model system instruction” module. Casual users focus on query-response; advanced users rely on configurable system prompts to fine-tune behaviour. I need to account for both levels of interaction.

✦ Explorations with Claude, VS Code, and agentic tooling

One of the more recent shifts in this work has been bringing agentic tools into my design workflow. I’ve been using Claude to pressure-test component logic, draft and refine design documentation, and validate naming conventions across token layers, particularly for the Figma-to-Storybook handoff pipeline.

With VS Code, I can move between token specs and implementation faster, reviewing how tokens render in production and catching discrepancies before they become systemic issues. I use AI less as a writing tool and more as a thinking partner for systems work: mapping edge cases, auditing pattern coverage, and thinking through multi-viewport behaviour before a single frame is built.