Build it once, ship it everywhere
33%
less dev time
75%
less design time
301%
ROI
Case Study
Broadacre Design System
Concur.com had no shared design system. I led the effort to build one, from an unfunded audit to a governed, funded system shipping components to production.
See the Hypesite
The Hypesite: Broadacre Design System's internal launch page, pitching the case for speed and scalability to stakeholders.
Overview
Concur.com - SAP Concur's public marketing site - had no shared design system: every team built its own components, its own patterns, its own inconsistencies. I led the effort to change that, starting from an audit nobody had funded yet and ending with a governed system shipping real components to production.
The harder problem, and the one this case study is really about, was not designing components. It was convincing designers, developers, project managers, and leadership that a design system was worth building at all.
Scope
Audit and inventory, the business case, a stakeholder workshop, governance structure, and the component system itself across Concur.com, the Blog, Newsroom, Resource Center, and campaign microsites.
Team
A cross-functional working group I helped form and lead, made up of designers, front end developers, and project managers, with executive sponsorship from design and marketing leadership.
Tools and methods
Figma, Frontify, Pattern Lab, Drupal, JIRA, Adobe Analytics, stakeholder workshops, atomic design methodology.
Problem
Building the case, not components
By 2018, the pattern was familiar: a new campaign or page shipped, someone designed it from a blank canvas, a developer built it from a blank file, and neither the design nor the code got reused on the next project.
An internal audit I ran turned up over a hundred UI concepts, from typography and spacing to buttons and card patterns, none of them documented anywhere. Concur.com and the Resource Center within had each independently designed and built their own card component, doing the same work twice for the same purpose.
Cost 01 - Re-solving solved problems
Localizing a page to Concur's 26 international markets meant re-solving problems that had already been solved elsewhere on the site. By the time a project reached its second phase, the team had often lost the thread of the original design intent and started over.
Cost 02 - No one owns consistency
A design system competes for the same design and engineering time as the next campaign launch, and without a business case, it loses that fight every time. No one owns "consistency" as a line item.
Research
Research & discovery
Auditing the inventory
I used EightShapes' "picking parts, products, people" framework to catalogue every UI concept worth standardizing, from visual language (colour, type, iconography, spacing) through components, patterns, and page templates. This gave the effort a concrete inventory instead of an abstract pitch.
Grounding decisions in traffic
I pulled Adobe Analytics data across browser, device, and regional traffic to ground component and breakpoint decisions in actual usage rather than assumption, and to show stakeholders the technical footprint the system would need to support.
Outside evidence
A Forrester study cited by IBM found that over 70 percent of enterprise companies already had a design system by 2018, with adopters seeing roughly 75 percent less design time, 33 percent less development time, and a 301 percent ROI.
Our own best work as evidence
I used a recent award winning campaign that had nonetheless been built entirely from scratch as a case study in what a system would have saved. Its success made it more persuasive than a failure would have been: even our best work was leaving efficiency on the table.
Process
The design process here was really two processes running together: building the system, and building the case for it.
01
Making the abstract concrete
Rather than write a pitch deck and hope it landed, I built what I dubbed the Hypesite: a stakeholder facing presentation, structured like an actual site rather than a slide deck, that covered design system fundamentals, the strategy and goals specific to our organization, and the benefits broken out separately for designers, developers, project managers, and marketers. Each group needed a different reason to care, and a generic pitch wasn't going to move any of them.
02
Building the case with people in the room, not at them
I facilitated a three day workshop with design, development, and project management stakeholders. Day one didn't start with my definition of a design system, it started with the group building their own, through paired and small group exercises that forced consensus rather than accepting a definition handed down from design. We then walked through a recent, genuinely painful project, a homepage redesign with an international rollout, and let the group articulate for themselves what a design system would have prevented. Day two applied the same exercise forward, to an upcoming project, so the value wasn't hypothetical. Day three turned that shared understanding into refined business requirements from three angles: front end, back end, and team process.
03
Formalizing ownership
Buy-in without structure evaporates, so I helped stand up a cross-functional "V-team," a working group with a written charter, defined scope, and executive sponsors from design and marketing leadership. We set objectives and key results across four areas: reducing design and development debt, improving user experience, optimizing business processes, and increasing focus for subject matter experts, each with milestones at three, six, nine, and twelve months. This turned "we should have a design system" into a funded, staffed, time-bound commitment.
04
Choosing a methodology the team could actually build
For the system itself, I adopted Brad Frost's atomic design methodology (atoms, molecules, organisms, templates) paired with Nathan Curtis's workshop and storefront model: a working environment where design and development build and stress test components together, and a separate style guide surface for broader, cross-disciplinary consumption by marketers and other stakeholders who'd never touch Figma.
Key decision
Building the case with the group instead of presenting it to them. A design system handed down from design is a design initiative; one the room defined together is an organizational commitment.
The Hypesite
The pitch, as a site: "The Hypesite"
A stakeholder facing presentation built as an actual site rather than a slide deck, so the case for the system could be browsed, revisited, and handed to whoever needed convincing next.
Fundamentals up front, then strategy and goals specific to our organization, then the benefits broken out by audience. Each group needed a different reason to care, so each one got its own page.
Visit the Hypesite
broadacre.webflow.io
DesignersDevelopersProject managersMarketers
Why developers should care
Live
Audience-specific value propositions - the same system, argued four different ways.
Solution
A system, not a mandate
The system that came out of this had three parts working together.
Governance
The V-team itself: designers, developers, project managers, subject matter experts, QA, and executive sponsors, with a defined scope and a cadence for surfacing progress to the rest of the organization.
Infrastructure
A Pattern Lab environment connected to Figma libraries organized by atomic tier, documented in Frontify, and tracked through a dual ticketing system linking design tickets to their corresponding development tickets, so nothing shipped to the pattern library without both sides of the handoff being accounted for. I maintained a single source of truth pattern tracker recording every component's status across design, development, and production.
The Hypesite
The ongoing front door for buy-in: design system fundamentals, strategy, and audience-specific value propositions, used both for the initial pitch and for onboarding new stakeholders as the system grew.
ScreensComing soon
More screens coming soon
Additional screens from this project are being prepared for publication. Check back soon, or get in touch for a walkthrough.
Results
Impact & results
Within the roadmap's first year, the foundational layer reached production status across the Blog and core Concur.com properties, the first concrete proof that the system worked end to end from Figma to live code.
Year 1
Colour, typography, spacing, and buttons in production across the Blog and core Concur.com properties
100+
Undocumented UI concepts catalogued in the audit that started the effort
V-team
From an idea to a resourced, ongoing concern with named executive sponsors
The outcome that mattered most: the organization had agreed a design system was worth funding, not just building once and letting decay.
Reflection
What I'd do differently
I'd push earlier for a lightweight adoption metric, tracked publicly, so the case for continued investment didn't rest solely on the original pitch. Business cases decay. Nobody throws a parade for 'component adoption held steady this quarter' - the parade all goes to the next campaign launch. I'd build the case for the boring quarters in from day one next time, rather than relying on the initial workshop and Hypesite to carry the case indefinitely.