When the Output Becomes the Material
How product primitives will reshape AI-driven design systems
Design systems have historically been great at answering questions like:
“Which components should I use to build this?”
They’ve been far less effective at answering questions like:
“Which experience is right for this user in this moment?”
I tried adding context to Shopify Polaris several times. But context only matters if it’s built into the code. Otherwise, it’s just another set of disconnected docs. Now, our tools have changed. When AI understands not just what a component does, but why it exists, it can build UI that better solves user needs. You can already see this in tools like Notion AI. Give it a messy doc and ask for a project tracker, and it can pull out tasks and dates to generate a structured table or board.
Adding context to existing design system components is a good first step. But to see the real value of context-aware UI, we need to evolve the foundational elements of design systems.
I keep hearing that “design systems need to prioritize meaning over appearance” as we add more context to them. That’s true, except that appearance is meaning. What’s really shifting is where we place emphasis. Intent-driven interfaces turn traditional design system stars like buttons, inputs, and dropdowns into supporting characters. The new stars will be the actual objects people create and manipulate in their work. These objects need their own distinct design languages that adapt to how people use them in different contexts.
Adapt, don’t adorn
The best experiences don’t just assemble components; they adapt the interface’s shape to match the user’s intent.
The macOS Control Center and System Settings expose many of the same controls, but their shapes are completely different.
The Control Center is built for quick changes to common settings. It’s visual, tactile, and concise. Each setting uses icons and shapes that match its purpose. System Settings handles more detailed configurations. It’s dense and uses utilitarian controls with clear explanations.
What you don’t see is a middle ground: a collection of cards with generic sliders and toggles.
When design teams end up with solutions that feel vague or generic, it’s usually because they started with the component instead of the user’s goal.
Component first = “I need a slider with a volume label and a time picker.”
Goal first = “Users need to adjust playback speed and expand event durations.”
Spotify’s playback speed control is specifically designed for adjusting speed. The ticks look like time intervals. The default sits in the middle. In contrast, apps that use generic sliders need to adorn their UI with additional labels and colors to indicate the default speed.
It’s easier to design a purpose-built UI when most users perform the same tasks the same way. This is true for consumer apps in a specific domain or pro tools with a focused user base. It’s harder in tools where the actions, roles, and preferences are very different. That’s why enterprise products often rely on middle-ground forms. Their customers need to move from new user on day one to power user on day 100.
Day one users need guidance and focus. By day 100, these same users demand efficiency: shortcuts, power tools, and advanced settings. Successful products need to evolve alongside their users, providing scaffolding for beginners while transforming into power tools for experts.
In the past, we didn’t have the tools to meaningfully adapt UI for different types of work without losing continuity. We had to split tools into modes or suites. With AI-driven context awareness, this is changing. Now we can adapt interfaces dynamically without sacrificing continuity.
Adapting when actions are similar but behaviors vary
In my previous article, I talked about how composable primitives (like Shadcn’s Command and Popover) allow us to build flexible “Differentiators,” specialized pickers like CustomerPicker or TagPicker. These differentiators primarily focused on mapping domain-specific data into the base component’s item slots.
But even these composable Differentiators have a static presentation. They can’t adapt their interaction pattern or density based on users’ behavioral preferences.
A power user needs rapid input, keyboard navigation, and minimal visual clutter. The default mode takes up too much space and requires too much clicking.
A new user needs clarity and safe defaults that guide them towards action. The default is too overwhelming.
A user with restricted edit options needs a clear, non-editable read-only state, but they get a hard-to-read disabled control.
By adding an adaptive layer around individual Comboboxes or an entire properties panel, the UI can adjust dynamically based on mandatory and preferential context.
This wrapper defines the contexts or signals that AI can use to display an adapted UI.
Mandatory Context: Can the user edit?
Preferential Context: Does the user edit frequently?
From there, a set of rules defines how the UI should adapt to these signals.
Mandatory Context: user lacks permissions. Display a scan-optimized view with clear read-only badges.
Behavioral context: user can edit AND is a frequent editor. Display edit-optimized view with exposed input fields, higher density layout.
Behavioral Default context: user can edit AND is an infrequent editor. Display scan-optimized view with clear default states.
Instead of designing for the balanced default, this approach lets designers create the best solutions for the extremes. A context-driven architecture bridges the gap so users get the experience they need.
Adapting when the actions vary greatly
If the actions themselves are very different, that requires more adaptation.
In a Discount Code scenario, there’s a big variability in the clarity, scale, and precision of tasks. In this case, the surface needs to change more dramatically.
Today, these experiences usually happen in form-based UI. A new user who needs help choosing the right discount strategy has to make a precise data input before they’re ready. Guides or tooltips try to fill the education gap, but they only add adornment instead of adapting the experience.
With contextual adaptation, we can show a different experience for a new user. Instead of a generic empty state, the discount code object becomes a discovery surface. Users could start with a prompt, a goal-based template, or by making selections. If a user starts by choosing an expected lift, they get a strategic AI recommendation that fills in the discount card values. Users learn by using the tool, not by reading docs.
Over time, that same customer’s goals might shift to execution tasks at scale, like extending all active June discounts to July 1 and lowering thresholds. AI could show a spreadsheet view with all the discounts and clear diffs for the changes. If a user needs to edit a single discount, it opens in a panel. The discount code object is the same one from the discovery surface, but now it lives in a more efficient surface.
Adapting for scale
I recently needed to lengthen the duration of my SavvyCal intro call and update the confirmation email people get after booking. It took me four clicks to change the duration, then I had to go to another section to update the email text. This setup might make sense for a power user managing hundreds of events, I just needed to update two fields about the same event.
In an intent-driven experience, if a user wants to increase the duration of an event type by 15 minutes and update the confirmation email, AI could assemble a view with the event block. It would show a diff for the extended time and the email confirmation text. Instead of a time picker dropdown, the event block itself could be adjusted by dragging. This is a better representation of the action of extending an event length.
What’s clear in all of these examples is that in an intent-driven experience, the objects that users are creating and modifying (Discount, Event Type) become more prominent in the experience than the buttons that users click. This shift means that design systems also need to rethink their differentiating elements.
How design systems need to evolve
For the sake of clarity, I’m going to start with some definitions.
UI primitives: the UI elements that users must click or tap in a directive UI (e.g., Button, Text Field, Select)
Product primitives: the objects that users are creating or modifying (e.g., Task, Event, Document, Order, Discount)
Directive UI: an interface where a user accomplishes goals by clicking or tapping UI primitives
Intent-driven UI: an interface where a user accomplishes goals by stating the goal
Ok, now moving on.
Intent-driven UI will only work if AI has the right context. People can naturally infer intent, context, and nuance. Even with this intuition, people can still assemble design system components into predictable, generic interfaces. That means AI, which lacks that intuition, will absolutely default to the middle ground.
Adding context about UI primitives (What does this Button mean?) has some value, but I honestly don’t see how a Button’s meaning can vary that much across products. To get real leverage, we need to encode context about product primitives, which are increasingly coming to the forefront in products.
The output becomes the material
During our last Shopify Polaris redesign, we spent ages debating and fine-tuning the material of the Buttons. In a directive UI, it makes sense for UI primitives to be the differentiating material.
In an intent-driven experience, the output becomes the new differentiating material. We saw Apple preparing for this shift with the Liquid Glass design language.
Tools like Craft already push the UI primitives to the background, while the product primitives have a rich design language.
Design systems will need to define the language for product primitives the same way they currently define the language for the UI primitives.
What’s the visual signifier for this primitive? (Is it an avatar? A number? An icon?)
How do we represent that signifier consistently anytime this primitive appears?
How do this primitive appear across surfaces?
How does it adapt to states?
How do this primitive appear when nested inside another primitive?
Sudowrite is another tool that brings its product primitives to the forefront. You learn the rules governing these primitives through interaction, not banners and tooltips. For instance, you can drag a project into a folder or series, but not into another project.
Defining how product primitives behave
In directive UI, design systems define patterns for component assembly, like how to lay out a Card. But in intent-driven UI, AI needs deeper context. It needs to understand the objects themselves:
Anatomy:
What makes up this object? What are its essential pieces of data?
Relationships:
What does this object connect to? How does a Task relate to a Project or an Owner? What’s upstream and downstream?
Rules and states:
What can and can’t happen? What state transitions are allowed? For example, a Task can’t be completed if it’s blocked.
This is the level of structure AI needs in order to generate UI that reflects intent.
The role of the design system team
In this model, the design system team functions more like architects. They’re not responsible for defining the content of these product primitives—that belongs to the domain teams who actually own the product primitives.
Instead, the design system team defines the grammar: the patterns, templates, and interaction logic that let these objects live together coherently in the UI. Domain teams supply the vocabulary: the specific fields, rules, and behaviors of product primitives.
Design system teams can also define the required metadata for each product primitive. For example, every object must have a list view, a micro view, a summary representation, and clear rules for how it can be displayed or manipulated. This ensures that no matter which team defines the vocabulary, all objects speak the same visual and interaction language, and AI can reliably compose them.
Define surfaces, not layouts
In directive UI, a product primitive is a page: an event-type page, a discount-code page, a task page, etc. In intent-driven UI, product primitives need to be objects that appear on different surfaces.
Instead of defining a single rigid, static layout for the Event Type object, the system defines multiple surface states. For example:
The Canvas state: The full, editable, high-fidelity view used to compose a dedicated editing environment.
The Summary state: The minimal, compact view used for lists, grids, or side panels.
The Confirmation State: A concise, comparison view used for reviewing changes before committing.
This approach shifts the focus from fixed layouts to versatile, context-aware surfaces, allowing the same underlying product primitive to adapt dynamically to the user’s immediate needs.
Adapting to phases of work
Today, UI and AI tools often sit side by side but don’t speak the same language. They work as separate tools instead of two limbs on the same body. We need to treat phase as a design primitive and describe how UI and AI should adapt to it.
This is important for signaling which type of AI response is most valuable.
Most AI tools today lack phase-awareness. They’re programmed to reward completion and helpfulness. You could be brainstorming, but if the UI only shows a blank box, the AI doesn’t know how to adapt its response. It will do what it does best: offer grammar tips on sentences that might not survive the draft and suggest formatting a perfect, publish-ready post prematurely.
Stop blinking at me, man!
Sudowrite uses user interaction cues to adapt how its UI and AI tools respond. If you’re brainstorming, the AI suggestions look like little strips of paper. Deleting ideas is playful, not destructive.
In the writing editor, selecting a word prompts the AI inline editor to suggest synonyms, while selecting a paragraph prompts the AI editor to suggest expanding, rewriting, or describing in different tones. This is miles more helpful than a blank box that says “How can I help? Please tell me.” Tools built for specific tasks should especially have a point of view on how they can be most helpful.
Phase awareness can be built in as context in several ways. Designers can define explicit phase states like brainstorming, drafting, refining, or publishing, each with matching UI and AI behaviors. User actions can signal phase transitions. Rapid deletions and additions suggest exploration. Methodical edits suggest refinement. The system can also track session patterns to infer intent over time. When UI and AI respond together to work phases, users can get tailored assistance instead of generic help.
How Are You Adapting Your Experiences?
I’ve lived through a few major shifts in how we design products, but this moment feels different. It directly addresses a frustration I’ve carried for years: design systems made it easier to ship UI, but not necessarily better experiences. Back in 2020, I wrote that a design system that helps you efficiently ship a confusing interface has no value, and that our foundations weren’t enough to support truly user-centered experiences. At the time, that felt more aspirational than practical.
Today, it finally feels possible.
We’re still early in figuring out what adaptive, context-aware interfaces should look like in practice. I’d love to hear how you’re approaching this shift. Where are you adding context today? What feels promising? What still feels out of reach? The more examples we share, the faster we can move past generic UI and toward systems that adapt to the people using them.
Further reading
If you want to learn more about context-driven design systems, I recommend following TJ Pitre’s work, especially his article Context-Based Design Systems: A New Model for the AI-Driven Product Lifecycle