Published 8/20/2025

Design Systems as a Protocol: The 7th Evolution for the AI Era

design systemsUX

In his work on design systems, Dan Mall identified six distinct types:

  1. Brand identities/visual language– The visual elements that make up a brand identity
  2. Tools– UI kits and component libraries that designers and developers use
  3. Products– Version-controlled software products with dedicated teams and backlogs
  4. Processes– The standardized methods for building digital products
  5. Services– Design system teams that function as internal agencies
  6. Practices– The most mature form where design systems become embedded organizational habits

But as we enter a new era of AI-assisted design and development, I believe we're witnessing the emergence of a seventh type:Design Systems as a Protocol.

Why We Need a New Definition: Design Systems as a Protocol

The AI revolution is fundamentally changing how design systems function in organizations. As Murphy T.observes in her recent analysis of agent-ready design systems:

"Design systems need to be less about what components look like, and more about how they function."

Rather than just being collections of components or processes, design systems are evolving into structured contracts that enable AI tools and human creators to work together effectively. The consumers of our systems aren't just designers and developers anymore—they're autonomous agents, AI design assistants, and automated workflows that need to interpret, compose, and generate interfaces without human guidance.

Why Protocol is the Right Mental Model

The biggest fundamental shift in this mental model from the previous models is that a protocol is built to serve both human and AI agents. It defines not just the components and specs, but design intent.

1. Protocols Enable AI and Human Collaboration

Just like HTTP lets different browsers and servers work together through a shared language, design system protocols help AI tools, developers, and designers collaborate. They make tasks like choosing components, applying styles, or generating code more automatic, consistent, and aligned with intent.

Example:

// AI querying a component by intent
getComponent({ intent: 'highlight key feature', layout: 'hero', device: 'mobile' })
// Returns: FeatureHighlight component with mobile-first layout and spacing presets

2. Protocols Set Clear Boundaries for Use

Rather than listing every single design detail, a protocol defines the "rules of the road"—what’s allowed, what’s expected, and what’s flexible. This allows both humans and machines to make decisions within safe, agreed-upon boundaries, while still enabling creativity.

Example:
{
"component": "PrimaryButton",
"allowedVariants": ["default", "danger", "success"],
"requiredProps": ["label", "onClick"],
"rules": {
"danger": "Use only for irreversible actions like deletion."
}
}

3. Protocols Encode Intent for Scalability

A good protocol doesn’t just document how things look—it captures what they’re for and how they behave. That intent can then be reused by anyone or anything (AI, new hires, tools) without needing constant review. It’s how a design system scales without breaking.

4. Protocols Are Built to Evolve

Design systems, like protocols, need to change over time. That means version control, structured updates, ways to phase out old patterns, and the ability to expand the system while maintaining compatibility. It’s not just documentation—it’s infrastructure.

“The consumers of design systems aren’t just designers and developers anymore—they’re AI agents and automated workflows.”

What Makes an Effective Design System “Protocol”?

An effective design system protocol goes beyond traditional thinking:

Structured Knowledge, Not Just Components

The fundamental shift from appearance-based to function-based design systems requires capturing not just what components look like, but what theydoandwhy:

  • Component relationships and hierarchies– Clear parent-child relationships and compositional contracts
  • Usage context and decision rationales– When to use each component and why it exists
  • Implementation rules and constraints– Explicit behavioral contracts, not just visual specifications
  • Historical decisions and their outcomes– The research and reasoning behind design choices. What if your design system had a clear understanding of the historical decision making behind a component? Or had access to qual/quant usability testing data? How much richer can AI-recommendations be with data encoded directly into the system — and not just bylines in a static reference website?

This means encoding design intent through semantic naming, explicit props, and structured relationships rather than relying on visual inference or tribal knowledge.

Context-Aware Guidance

Design system protocols must deliver situational recommendations that adapt to how and where components are being used. This means offering pattern variations suited for different screen sizes, user flows, or interaction modes. Instead of strict rules, guidance should be rooted in principles that allow flexibility, helping teams understand when it's better to conform and when it’s appropriate to deviate for better outcomes.

Bidirectional Learning

Effective protocols don't just push standards—they absorb insights from the field. As teams implement components, the system should capture lessons learned and refine itself over time. Feedback loops allow the design system to evolve in response to business outcomes, user needs, and emerging best practices. This creates an institutional memory that ensures future decisions build on past knowledge.

Multi-Modal Orchestration

A protocol-based system must support consistency across channels—web, mobile, email, and even voice—while adapting to the unique constraints of each. Rather than forcing uniformity, it should translate design intent into the right expression for each context. This orchestration ensures the brand and user experience remain coherent, even as the touchpoints vary.

Real Impact: What Changes for Your Team

When design systems are structured with the right metadata and semantic relationships, they transform how teams work:

For Designers:

Instead of:

❌ Manually hunting through documentation

❌ Creating yet another one-off component

❌ Explaining the same design principles repeatedly

❌ Spending hours on implementation details

Designers can:

✅ Ask AI to recommend components for specific contexts

✅ Generate appropriate variations that maintain system integrity

✅ Focus on solving novel problems while AI handles routine work

✅ Spend more time on user research and strategic thinking

For example, a designer working on a new feature could ask: "What notification pattern would work best for a time-sensitive alert in our mobile app?" The AI, understanding both the design system and context, can recommend the appropriate component with usage guidelines.

For Developers:

Instead of:

❌ Guessing at intended component behavior

❌ Manually checking design system compliance

❌ Recreating similar components across projects

❌ Navigating complex documentation

Developers can:

✅ Get precise specifications and edge cases automatically

✅ Receive AI validation against requirements

✅ Generate context-aware implementations that follow conventions

✅ Ask conversational questions about usage patterns

A developer could ask: "How should this dropdown behave when there are more than 100 options?" and receive guidance based on the encoded design intent, not just technical specifications.

Starting Your Journey: 3 Practical Steps

Here's how we're consulting companies to start taking advantage.

1. Audit Your Current System for AI Readiness

Action item:Schedule a workshop to identify which components would benefit most from enhanced metadata. Focus on your highest-usage components first.

Look specifically at:

  • Which components have the most variants?
  • Where do designers and developers miscommunicate most often?
  • Which patterns are repeatedly reimplemented?

2. Add Semantic Structure to Your Documentation

Action item:Choose one high-friction component and enhance its documentation with machine-readable metadata. For example, Modal components are often inconsistently used and implemented.


json
CopyEdit
{
"component": "Modal",
"purpose": "Display time-sensitive or interruptive information that requires user action or acknowledgment",
"variants": ["confirmation", "form", "info"],
"usage": {
"confirmation": "Use when asking the user to confirm or deny an irreversible action",
"form": "Use when requiring user input that cannot be collected inline",
"info": "Use to deliver critical system alerts or onboarding walkthroughs"
},
"relationships": {
"contains": ["Header", "Body", "Footer", "CloseButton"],
"related": ["Toast", "InlineAlert"],
"avoid": "Don’t use modals for non-essential content or passive information"
},
"accessibility": {
"aria-role": "dialog",
"requirements": [
"Must trap focus while open",
"Must be dismissible via Escape key",
"Initial focus must be on the first actionable element"
]
},
"behavior": {
"trigger": ["button", "link", "programmatic"],
"dismissal": ["overlayClick", "escapeKey", "explicitCloseButton"],
"animation": "fade in/out over 200ms"
}
}

This structured approach helps AI tools and documentation platforms make informed decisions about when and how to use a modal—preventing misuse and aligning design decisions with business intent and accessibility compliance.

3. Audit Workflows, Not Just Components

Map your team's real design-to-dev processes. Interview designers and developers to find friction points and gaps in understanding.

4. Create Feedback Loops for Continuous Improvement

Action item:Set up a process to capture implementation insights that refine your system.

This could be:

  • A simple Slack channel for system feedback
  • A monthly review of how components are being used
  • A process for documenting component extension decisions

The goal is to create a living system that learns and adapts based on real-world usage patterns, becoming more intelligent over time.

Real Results: Still early innings

Organizations that have just started implementing protocol-based systems broadly are experiencing significant gains, although I should note it’s still early days:

  • 30-40% reduction in implementation time
  • More consistent experiences across products
  • Faster onboarding for new team members
  • Increased capacity for creative problem-solving

What's Next?

The future isn't about AI replacing designers or developers—it's about creating systems that allow humans and machines to work together effectively. Protocol-based design systems are the bridge to that future.

I'd love to hear from you:

  • Has your team started structuring design systems differently for AI workflows?
  • What challenges have you faced when trying to make your design system more machine-readable?
  • Are there aspects of your design process that would benefit most from this approach?