Building a design system from the ground up

How I approached the migration

With a tight timeline and a simultaneous website redesign underway, I needed a clear, repeatable process to build the new system without losing momentum. I broke the work into ten phases, from user research and benchmarking through to component build, accessibility, and documentation.

Who uses the system and who uses the site

Our design system users included designers, developers, brand teams, marketing, product owners, and senior stakeholders. Primary users of the website were potential trial participants and caregivers. Understanding these two distinct audiences shaped how we structured the system's documentation and flexibility.

From atoms to pages: a shared design language

I researched Atomic Design, Brad Frost's methodology for breaking UI into small, independent components: atoms, molecules, organisms, templates, and pages. This framework gave us a shared vocabulary and a principled structure for building the new component library.

Applying atomic design to components

I applied atomic design methodology to analyze each component individually and within the broader system. Below is the clinical trial location card I designed for both desktop and mobile, followed by a breakdown of its structure using atomic design.

Benchmarking industry design systems

I studied the design systems of leading companies, including Atlassian, Salesforce, and Microsoft, to learn about design system best practices and how we should structure our own design system.

Interface inventory

I worked with a teammate to audit the existing Sketch library, cataloging every button, card, text style, and spacing rule. This exercise surfaced inconsistencies like undefined spacing, conflicting font weights, and duplicated component variants. The audit was the foundation of everything that followed.

Creating separate Figma files

I collaborated with two designers to streamline file organization for the clinical trial redesign. We built a reusable component library and structured Figma files for clarity and flow: one for internal iteration, one for client review, and two for post-launch updates as the design system evolved.

Documentation and guidance

I created detailed documentation in Figma to ensure long-term system clarity for developers and future designers. This included component usage guidelines, design rationale, accessibility notes, and instructions for maintaining the system as it evolved.

Accessibility built into the foundation

Accessibility and inclusivity were core to the experience from day one, not a final check. Design, copywriting, and code were all held to WCAG standards throughout. Building this into the component library meant every team working from it inherited those constraints by default.

Supporting every stage of the journey

The system was applied across recruitment experiences, disease program pages, search, and trial discovery workflows, showing how the library created consistency across multiple product touchpoints.

From component to experience

With the library built and documented, the real test was applying it. Reusable components streamlined key user journeys, improving clarity and enabling more seamless clinical trial exploration and sign-up. From the Find a Trial search experience to program-level recruitment pages, the system held up across every touchpoint: consistent, predictable, and built to scale.

From fragmented library to a unified system

Migrating from four disconnected tools to a single Figma system improved how every team worked. The interface audit was critical in enabling effective planning and resource allocation, laying the foundation for a scalable, maintainable system that improved consistency and delivery across teams.

A system that shipped and scaled

The new component library in Figma played a significant role in the successful redesign of pfizerclinicaltrials.com, which launched in January 2022 on schedule. Beyond the launch, the system improved how teams worked day-to-day.

What I'd do differently

The initial timeline assumed 680+ components could be built in 7–14 days. In hindsight, that was optimistic. The migration took significantly longer, partly because we were simultaneously executing a full website redesign, so the component library and new page designs evolved in parallel, requiring rework as upstream decisions changed.

Next time, I'd push for a phased rollout from the start: core atoms and high-priority templates first, expanding outward after. This would reduce rework and give the team clearer milestones.