Goodbye Screens: Designing the Rules for AI-Built Interfaces

From design patterns to workflow recipes
(and why headless UX changes everything).

We're not designing pages anymore; we're designing recipes that any screen—or agent—can cook on demand.

TL;DR (North Star)

• Screens are on tap, not the product. The unit of design is now a 'recipe' the repeatable workflow that delivers an outcome, regardless of how the interface assembles itself.
• AI acts on behalf of humans. That changes the stakes from conversion rates to trust, accountability, and the question of who's responsible when something goes wrong.
• The new failure mode: too many cooks, not enough recipes. Anyone can generate UI now. Without workflow recipes and constraints, the experience fragments.
• Composable UX lives in five layers: Primitives, Promises, Policies, Proof, and Recipes. These are the rules that keep a product coherent when screens are generated on demand.

If this resonates: Steal this recipe format, try it on one workflow, and tell me where it breaks.

Screens are on tap

If you came here expecting a bait and switch with screens are dead, long live the screens; I'm sorry but you're going to have a bad time.

Remember when it was all about responsive web, then it was mobile first, then it was A/B tested conversion optimization. Those are all important factors of the user experience landscape, but they're no longer the primary differentiator.

To be precise: screens aren't dead; they're *on tap*, touch and engagement optimized but not in a pixel perfect human crafted way. The screens aren't in-fact disappearing, they're being demoted from "source of truth" to a rendering layer. The screen is no longer the product. The design recipe the delivers the expected outcome is.

The real differentiator now is how well the system can compose and govern itself; not just what it shows, but how it behaves across contexts, agents, and workflows. For a long time, digital design has behaved like procedural programming.

• A screen is defined. Mobile, Responsive web, or Desktop adaptive.
• A flow is drawn. Fill a shopping cart, process payment, confirm order.
• The user walks the path we anticipated. Create an account, verify email, login, and set preferences.
• The product offering is strong enough that our users/customers will “work” to complete the steps successfully.

That user experience model assumed a couple of key things:

• The user would do the work inside the interface.
• The user would follow a linear path.
• The user is a HUMAN and would interact with the interface in a predictable way.
• The interface would be stable.

In 2026, and going forward, these assumptions are dissolving.

We’re moving into a world where interfaces are assembled dynamically based on the user, the role, the top-of-mind intent of the moment, and the context of their device. That context could be a voice driven conversation, it could be on a mobile app screen, or on their behalf by a 3rd party. In that world, “designing screens” becomes the least scalable part of the job.

Similar to the same software coding process of procedural programs moving into object-oriented programming (OOP) principles, this analogy becomes useful as a design lens. We are now in the age where the procedural Business Processes must bend to Outcome-based Solutions.

• Procedural thinking optimizes for shipping one screen correctly.
  • workflows that follow internal business patterns
  • rigid, step-by-step execution
  • limited adaptability to user needs / rigid adherence to predefined paths
  • resistance to dynamic adaptation based on user context
• Object-based thinking optimizes for shipping a reusable set of behaviors correctly
  • focuses on modular, composable capabilities
  • enables dynamic assembly of user experiences
  • supports context-aware adaptation
  • login with single sign-on across contexts

Shifting attention from page-level perfection to system-level predictability. To a scalable world view / library that is designing the system that produces screens. Not with a design library of atomic elements for infinite novelty, but with a design library of composable behaviours. The goal is reliable variation: a range of valid experiences that still feel like one product.

Ending the idea that interfaces are static screens. The UX Designer, the Business Architect, and the System Architect are now responsible for designing composable behaviours that can be orchestrated / called-on in context to the outcome.

Patterns aren’t dead : they’re being promoted into workflow recipes

Our challenge in 2026, and going forward, is to define how we structure and govern these workflow recipes to maintain consistency while enabling dynamic assembly.

The interface is no longer just about assembling UI elements, but about orchestrating intelligent, context-aware workflows. In this new age of Outcome-based Solution Design, patterns matter because familiarity still matters. People don’t just learn interfaces, they internalize repeated sequences until those sequences become effortless.

But the context, the relationship with the underlying data is now more dynamic and fluid. And soon, as more and more AI shapes the product, the intended use, and situations where the feature/function is displayed; the pattern library can’t stop at component patterns anymore.

Now, buttons, inputs and view-states are contextual to the checklist of elements expected for a given outcome. And those can be modularly served up, or requested on-demand to fulfill that task at hand.

Users (and agents) don’t want “a table of UI elements”. They want “show me what matters to complete this task, let me change what’s allowed based on my role/context, and help me finish the task without surprises.”

In this next age of UX, screen designs are being promoted from UI patterns to workflow recipes. These recipes define the expected sequence of actions and states needed to achieve a specific outcome. These recipes can be served / invoked when a user intent appears.

How you prevent the drift that AI systems naturally introduce

In 2020, user experiences were atomized and recombined into design patterns. In 2026, user experiences are atomized and recombined into workflow recipes; where the "recipe" defines not just UI elements, but the entire sequence of actions, data flows, and contextual states needed to achieve a specific outcome.

These recipes become the source of truth for how each task should be completed, ensuring consistency even as the interface adapts dynamically across different contexts and user roles. This approach ensures that regardless of how dynamically the interface is assembled, the core workflow remains predictable and aligned with business objectives.

That’s the new comfort: a product that keeps its promises, no matter how the interface is assembled. And the recipes work backwards from the "what does success look/feel like". The 'job-to-be-done' persists regardless of the interface or the user/AI agent who's working through their task. Every variation still serves the same fundamental purpose through the recipe to served front-end artifact.

The rules layer: Primitives, Promises, Policies, Proof, Recipes

If composability is the future, then 'governance' needs a friendlier name. Until wiser industry pundits co-opt the framework, let's call it the *rules layer*.

The *rules layer* defines what primitives should accomplish (ingredients), what the composition of the primitives are allowed to do (promises), and what the success criteria will check (policies).

Carrying through the kitchen analogy: if workflows are recipes, then the *rules layer* is the kitchen experience. It defines the tools, the processes, and the standards that ensure every recipe can be executed consistently.

Primitives are the building blocks the system is allowed to use. An extension of the design library and atomic elements that define the core interactions, data structures, and states. Not just components; concepts.

The nouns like Account, Invoice, User, Ticket. The verbs like Create, Approve, Escalate, Export. The states like Empty, Pending, Failed, Archived, Completed. The view-states, view only, edit, etc. If your primitives are vague, the rendering layer/system will guess. If they're clear, the system can compose.

Promises are the non-negotiables. The world-building rules of the application. Terminology stays consistent. Important actions are always confirmable. Destructive actions are reversible when possible. Accessibility isn't optional. Latency and layout stability are part of the experience, not "engineering details" to sort out later. Promises turn "design quality" into an enforceable contract; something the system can check, not just something a designer hopes for.

Here's what top-level promises look like in practice: users can start a workflow without being interrupted for a login. New accounts don't require a password - just an email or phone number to confirm access. Friction is minimized at every step, with optional "if you have time" prompts to deepen engagement later. These aren't features. They're commitments that keep a interactions coherent and purposeful.

Policies are the boundaries that prevent harm. This is where permissions, scope, and governance become real. Role-based access control. Outcome-based and role-level security becomes an attribute of the outcome. Allowed vs forbidden actions by context. The policies are both within the visualization, and enforced at the data, API, and access layers.

Here's the shift:

• Policy (Old): Grey out the button if the user is unauthorized.
• Policy (New): The API rejects the "Approve" verb for Role: Junior. The UI doesn't even know the verb exists.

If the UI is dynamic, policies cannot be a UI concern. They must live underneath, in the layers behind the interface, enforced regardless of how the viewstate assembles itself. When an AI builds a screen, how does it know the policy? The policy is in the metadata, not the CSS.

Proof is what keeps composable UX debuggable; and in a world of AI hallucinations, it's the feature users will pay for. Proof ensures every action is traceable: through logs, replayable sessions, and clear decision trails. Users and agents need to verify, debug, and trust what happened.

Replayability is a big factor, "what did the user / AI agent see when it made that decision?". Traceable decisions "why did this workflow happen this way?" Chain of thought and/or log of activity that enables users (Ai agents) to see their own activity and decisions. And enables those inside the platform, and as users to reverse engineer their activities. What's good for the blockchain, is good for the platform.

Recipes are the repeatable workflows that turn capability into trust. Recipes can be static, cached flows for common tasks. They can be dynamic, composable flows that still follow constraints.

If user goals and activities are the menu / meal plan of options, the recipes are the actual meals. They're what prevent "creative assembly" from turning into chaos. The ingredients (components, data, policies) and outcomes also prevent teams from reinventing the same flows over and over.

These recipes can be templates that fill in data, and are grounded in meaning. When recipes exist, the system can be flexible without being unpredictable. Just as a breakfast vs dinner menu has a specific theme, and expected results; recipes provide a framework for flexibility while maintaining consistency.

What UX ships now
(even when screens are generated)

In a composable world, the outputs that matter most are often invisible to the systems. But to the people and agents using them, they are the most important part of the experience.

"On Behalf Of A Human." - this is going to be the biggest challenge for UX in the next decade. Who is accountable for the decisions made on behalf of a human? Is this the responsibility of the user, the agent, or the platform?

• "I want to book a flight from LAX to JFK (on behalf of a human)"
• "I want to find a restaurant for dinner (on behalf of a human)"
• "My parent (or child) needs care help and I need to find a provider
  (on behalf of a human)"

The risk of getting this wrong doesn't just impact the user experience; it can impact legal and ethical responsibility. It's the gravity of accountability that makes this next age of User Experience so challenging.

And yet, these accountability structures won't show up in a Figma file. You won't demo them in a stakeholder meeting. But they're the reason the product holds together.

The new UX is about designing better business processes and artifacts that empower people (and AI) to build better experiences. The documents are almost recipes, and the business is serving up outcomes.

UX as a recipe of rules, and businesses as a cookbook of outcomes

A recipe library - canonical workflows for the jobs-to-be-done that actually matter.

• Variation ranges - what's allowed to change, and what's locked. Not everything needs to flex. The skill is knowing where rigidity creates trust.
• Multi-state defaults - because empty states, first-run states, error states, and recovery states are where users actually spend their time. Get those wrong and the happy path doesn't matter.

There's also the vocabulary map - consistent naming across UI and API surfaces. This sounds boring until an agent calls a tool with the wrong noun and your support queue explodes.

Guardrails for agents - scopes, confirmations, reversibility, safe fallbacks. Agents are going to act on behalf of users. The question is whether you've decided what that means, or whether you're going to find out the hard way.

And finally, success metrics that include trust - predictability, time-to-outcome, error recovery, support deflection. Conversion rate is still important. But in a composable world, trust compounds. This is where UX becomes less about drafting screens and more about shaping the ecosystem that produces them.

Closing: Goodbye screens. Hello rules.

This isn't the end of design. It's the end of a specific era of design.
The era where UX meant shipping a fixed set of screens and hoping the user (and eventual AI agents) would follow a prescribed path is closing. The next era is composable, where UX lives in primitives, promises, policies, proof, and recipes.

The shift: we are moving into a world where an AI agent acts 'on behalf of a human', the stakes are no longer just conversion rates and NPS scores. They're trust, chain of thought logs and audit trails. Accessibility meets accountability and transparency. And the question of who's responsible when something goes wrong is clearly defined up front.

None of that is a UX issue, but the designers and architects who thrive in this era will understand the outcomes, and create cookbooks of recipes to serve up those experiences. They won't be the ones shipping the most screens, the platforms will generate them on demand. The outcomes will define the experience, and the rules will be the foundation that made every screen—generated. Potentially, each interaction starts with a promise and lands on an outcome.

If you want to stay close to where this is going, Subscribe to the blog. I'll keep publishing frameworks and working models for what UX becomes when interfaces assemble themselves.

But here's the real ask: Steal this recipe format. Try it on one workflow in your product. Message me where it cracked. I'll publish the fixes in a follow-up; or we can jam on it in the socials @Vveerrgg via X (formerly Twitter) or in the DM's via LinkedIn.

Note: Originally this was going to be a whole series of articles. But the more I worked on it while brainstorming with Windsurf-Cascade, Claude, Kimi and Gemini; the more it felt right to ship it as one comprehensive piece. The distillation of the current age of UX into this new future is both fascinating and humbling. My hope is that this framework helps you think differently about how you approach UX in the age of AI-native interfaces.