Design Systems as Products: Treating Your Internal Tools Like External Software
Design systems have become one of the most significant investments in modern product organizations. A well-maintained design system — a shared library of components, patterns, tokens, and guidelines that product teams draw on to build consistent user interfaces — reduces design and engineering duplication, speeds up feature development, and creates a coherent user experience across a complex product surface. The investment is substantial and the potential value is real. And yet, design systems fail at a striking rate. They are built with significant effort, launched with enthusiasm, and then gradually abandoned as product teams continue to build their own one-off components rather than adopting the shared library.
The reason design systems fail is not technical — it is organizational. Design system teams typically treat their work as an infrastructure project: build the system, document it, make it available, and expect teams to adopt it. This model fails because infrastructure projects do not have users — they have dependencies. A design system does have users: the designers and engineers on product teams who are expected to use it. Treating those users with the same product discipline applied to external software — understanding their needs, measuring adoption, iterating based on feedback — is the difference between a design system that thrives and one that sits in a Figma library that nobody opens.
A design system is a product. Its users are the designers and engineers on your product teams.
The GE Predix Lesson: When Design Systems Need Product Thinking
GE's Predix design system, developed to support the company's industrial internet platform, offers an instructive example of what happens when a design system is treated as a product. When GE undertook the massive effort of building Predix — a platform for connecting industrial machines to data analytics — the design team recognized early that the platform's user experience consistency depended on product teams across the company using a shared design system. Rather than building the system and sending a documentation link to teams, the Predix design team applied product management discipline to the system itself.
They interviewed the designers and engineers who would be using the system to understand their workflows, constraints, and the specific points where they were most likely to deviate from system components in favor of custom solutions. They identified the adoption friction points — components that were too complex to implement, documentation that did not match engineering reality, patterns that did not account for specific use cases — and prioritized those friction points in their backlog. They measured adoption rates by component and by team. When adoption of a specific component was low, they treated that as a signal to investigate rather than a signal to communicate better. What they discovered was that low adoption was almost always a product problem — the component did not fit the real use case well enough — rather than a communication problem.
Defining Your Internal Customers
The first step in treating your design system as a product is identifying your internal customers with the same specificity you would apply to external users. 'Product teams' is not a customer segment — it is a category. The designers on those teams have different needs from the engineers. Senior engineers have different constraints from junior engineers. Teams building consumer-facing features have different requirements from teams building internal dashboards. The 'Who Does What By How Much' framework applies directly here: which specific user segment should do what with the design system, and how will you know when adoption has reached the level that delivers the system's intended value?
A useful exercise is to map the adoption journey for each customer segment: discovery (how does a designer first encounter the system?), first use (what is the first component or pattern they try to use?), regular use (which components do regular users rely on most?), and advocacy (what causes a user to recommend the system to a colleague?). Each stage of this journey has friction points that can be identified, measured, and reduced. Design system teams that map this journey discover that their highest-impact investment is almost never more components — it is reducing the friction at the stage where adoption most commonly stalls.
Adoption friction is a product problem, not a communication problem.
Measuring Design System Adoption Like a Product Team
Design system adoption metrics should look like product metrics: behavioral measures that indicate whether the system is delivering value to its users. The most useful adoption metrics are: component usage rate (what percentage of product team designs use system components rather than custom ones?), time to first use (how long after a new product team is formed do they begin using the design system?), support request volume (are teams asking for help with the system, and what are the most common issues?), and contribution rate (how many external teams are submitting component suggestions or improvements?).
Each of these metrics tells a different part of the adoption story. High component usage rate with high support volume suggests the system is being used but has usability problems. Low time to first use with low sustained usage suggests good onboarding but poor ongoing value. Low contribution rate in an organization with many product teams suggests the system is seen as owned by one team rather than a shared resource. OKRs for design system teams should be built around these behavioral metrics — not around the number of components shipped, the coverage of a design audit, or the completeness of documentation, which are output metrics that say nothing about whether the system is actually delivering value.
Building the Feedback Loop Into the System
A design system that treats its users as customers needs a systematic feedback loop — a mechanism for surfacing user problems and incorporating them into the system's backlog. The most effective mechanisms combine proactive and reactive channels. Proactive: quarterly design system users survey asking about friction points, adoption barriers, and missing components; monthly office hours where product teams can ask questions and share feedback in real time; embedded feedback requests in the documentation ('Was this component documentation helpful? What was missing?'). Reactive: tracking support channel requests for patterns that indicate systemic issues; monitoring design files for teams who are consistently building custom components in categories where system components exist.
The cultural shift required to make this feedback loop work is the same one that any product team needs to internalize: feedback is not criticism to be defended against, it is learning to be acted on. Design system teams that respond to low adoption of a component by improving the component rather than by improving the communication about the component are operating with genuine product discipline. Over time, this orientation builds the trust that is prerequisite to high adoption. When product teams see that the design system team is responsive to their real needs, they invest in using the system rather than building around it.
The Bottom Line
A design system is only valuable when teams use it. Usage only happens when the system solves real problems better than the alternative of building custom components. And solving real problems requires the same product discipline applied to internal tools as to external products: understand your users, measure adoption, treat feedback as learning, and iterate on the system itself rather than the communication about it. Design system teams that internalize this shift from infrastructure maintenance to product ownership consistently achieve higher adoption and deliver more value to their organizations.
Related Posts from Sense & Respond Learning
The Death of the Handoff: Why 'Over the Wall' Design Is Failing
Managing 'UX Debt': How to Track Design Fixes in the Agile Backlog
Why 'Velocity' Is a Vanity Metric (And What to Measure Instead)
Further Reading & External Resources
Design Systems — Alla Kholmatova — The definitive book on building and managing design systems at scale
Atomic Design — Brad Frost — The foundational methodology for constructing design systems from components
Design System Adoption Metrics — Zeroheight — Practical guidance on measuring whether your design system is delivering value
Want to go deeper? This post is part of the Sense & Respond Learning resource library — practical frameworks for product managers, transformation leads and executives who want to lead with outcomes, not outputs.
Explore the full library at https://www.senseandrespond.co/blog
