The changing work of design
A product team designs a new accounts page.
Designers decide which balances deserve emphasis, which columns belong in the table, and where the available actions should appear. Developers turn the design into components and connect them to account data. Quality assurance verifies the known states: one account, many accounts, an empty account list, a failed request, a narrow screen, a restricted user. The team releases a screen whose important variations can be named before it reaches production.
Runtime composition changes the object passing through this process. The team may still design an accounts table, while treating that table as one possible element of a page. For one task it may sit beside a cash-flow forecast. For another, two accounts may appear in a comparison. For a third, account balances may provide evidence for an explanation while remaining in the underlying data.
The final arrangement is decided after the user arrives. Design, development, and testing exchange the system that will produce it.
Those disciplines continue with a new subject:
predefined interface: design, implement, and test each important screen
runtime interface: define, build, and evaluate the system that may produce screens
The product team's responsibility expands from the quality of known artifacts to the quality of a space of possible experiences.
From screens to a possibility space #
A conventional flow can be represented as a finite graph. Screens are nodes; actions and links are edges. Even a large, conditional, and responsive graph leaves its principal paths available for inspection:
accounts → account details → new transfer → review → confirmation
An intent-driven system begins with combinations whose full set exceeds practical enumeration. Different goals, data, permissions, devices, histories, and levels of uncertainty can lead to different compositions. A request to “help me reduce next month's expenses” might produce a recurring-payment list, a comparison with previous months, a forecast, or some combination of them. A follow-up can reshape the workspace again.
The designer's focus expands from choosing final arrangements to shaping the rules under which arrangements become appropriate.
This resembles the difference between designing a sentence and designing a language. A sentence can be judged as a complete object. A language supplies a vocabulary and grammar from which many sentences can be formed. Its quality emerges across the expressions it supports: those it makes easy, those it makes difficult, and those it forbids.
For an interface system, the equivalent questions are:
- Which domain concepts can the runtime represent?
- Which elements may be combined, and in what relationships?
- What evidence makes each representation appropriate?
- Which information must remain visible when an action is offered?
- Which variations hinder the interaction, and which must be prohibited?
- When should the system preserve an existing arrangement, and when should it adapt?
Even a bounded possibility space can be large. A modest set of components, layouts, data bindings, and actions can produce many valid surfaces. The work is to ensure coherence across that space.
Designing the grammar #
Design systems already provide reusable components, tokens, content rules, and patterns. They make known screens more consistent and implementation more efficient. A runtime interface asks the system to carry more meaning.
A conventional component might say:
This is a card with a heading, body, and actions.
A semantic interaction element says:
This is a forecast.
It distinguishes observed values from estimates.
It names its time range and assumptions.
It can be compared with another forecast.
Payment authorization belongs to a separate capability.
The second description gives a composer something it can reason about and gives a validator something it can check. Its visual treatment remains important; its role in the interaction is now part of the design material.
The grammar also describes relationships. A destructive action may require a review region immediately before confirmation. An estimated balance may require its assumptions to be reachable from the value. A comparison may require a shared unit and time range. A warning remains visible and visually prominent beside a recommendation.
vocabulary forecasts, tables, explanations, forms, actions
grammar valid combinations and relationships
semantics what each element means and promises
invariants properties every composition preserves
These decisions are design decisions even when they are expressed as schemas, constraints, component contracts, or validation rules. The medium of design extends beyond the drawing of a screen.
Drawing the adaptation boundary #
The product team reserves some properties from runtime adaptation. Someone has to decide what may adapt, what may adapt under stated conditions, and what must remain stable.
Consider a generated payment experience. The surrounding workspace might adapt to the task. It could show the recipient's recent payments, a projected balance, or an explanation of an unusual fee. The action itself may have strict invariants:
- the source account, recipient, amount, date, and currency are explicit;
- values used for authorization come from the authoritative prepared transaction;
- fees and material consequences appear before confirmation;
- editing a material value invalidates the previous review;
- the confirm control has a consistent meaning and requires an intentional action;
- success, failure, and pending states are distinguishable and recoverable.
The runtime can compose around those rules. They govern every composition, including cases where the runtime predicts that a shorter path would be convenient.
Different parts of a product will have different adaptation envelopes. An exploratory analysis may permit broad variation. A recurring expert workflow may permit new suggestions while preserving its layout. A regulated disclosure may allow the surrounding context to change while keeping its wording and presentation fixed.
Designing the boundary requires ongoing judgment about consequence, reversibility, expertise, uncertainty, and the value of learned behavior.
In a runtime interface, consistency becomes a deliberately protected property upheld across many possible screens.
Designing for interpretation #
Predefined interfaces respond mostly to observable application state. A runtime interface also responds to an interpretation: what the system believes the user means, which facts it considers relevant, and what representation it thinks will help.
That introduces a new class of states for designers to make visible:
| Interpretive state | Design requirement |
|---|---|
| Intent needs more detail | Help the user add that detail while preserving progress |
| Several meanings are plausible | Present a useful distinction or ask a focused question |
| Evidence has gaps | Separate known facts from estimates and identify the data gaps |
| Requested action is unsupported | Explain the boundary and show valid alternatives |
| Composition has changed | Preserve user state and reveal the material change |
| Confidence exceeds the evidence | Make correction easy before confidence becomes consequence |
Interpretive failures require treatment beyond a loading skeleton or error message. A technically successful system can still misunderstand the task. It can retrieve correct records and arrange them into an irrelevant answer.
Design must therefore cover the conversation between interpretation and correction. How does the surface state what it is trying to help with? How are assumptions distinguished from facts? What happens when the user says, “I meant something else”? How much of the current workspace survives a change of direction?
The happy path includes both successful requests and a system whose understanding becomes more accurate while preserving the user's progress.
New design artifacts #
Static mock-ups remain useful. They show hierarchy, content, interaction details, and visual character at a precision beyond abstract rules. They become precise examples within a larger specification.
Teams may need additional artifacts:
- scenario sets that vary intent, context, risk, device, and user expertise;
- semantic component contracts describing meaning, data requirements, and valid relationships;
- invariant registers stating what the runtime must preserve;
- adaptation policies describing when to compose, preserve, clarify, or fall back;
- reference compositions that demonstrate good use of the interaction language;
- adversarial examples showing plausible arrangements that mislead users;
- evaluation criteria for relevance, continuity, clarity, accessibility, and consequence.
A prototype may act less like a clickable path through five frames and more like an instrumented environment. The team supplies different intentions and contexts, observes the surfaces produced, changes the available grammar, and looks for patterns across the results.
This creates an iterative relationship between examples and rules:
propose grammar
↓
generate across representative scenarios
↓
inspect useful and harmful compositions
↓
revise components, constraints, and evaluation
Individual examples still matter. A failure found in one generated surface should lead the team to ask whether the example is an exception or evidence of a weak rule that can produce many related failures.
Development builds the runtime #
Developers also move one level down from the final screen. Their task centres on building the machinery that makes composition dependable, from generated structures through action handling.
That machinery includes authoritative domain capabilities, typed data bindings, semantic interface schemas, deterministic renderers, policy checks, permission boundaries, state preservation, history, telemetry, and fallbacks. It separates a proposal about an interaction from the execution of a consequential action.
runtime proposes a valid interaction description
↓
system validates structure, data, permissions, and policy
↓
renderer produces approved controls
↓
domain capability prepares or performs the action
In this arrangement, the application surrounds the model. The model participates in a system whose deterministic parts establish what is true and what can happen.
Frontend engineering remains substantial. Responsive layout, keyboard behavior, focus management, performance, localization, direct manipulation, and state transitions all require explicit engineering beyond semantic intent. Solving them once in a trusted renderer becomes more valuable when the same elements can appear in many compositions.
Quality beyond test cases #
Quality assurance expands beyond a catalogue of screens and expected outputs. The number of possible compositions may be too large, and the same input may produce several acceptable arrangements.
Some properties remain suitable for deterministic tests:
- every action resolves to an authorized capability;
- required confirmation and disclosure rules are enforced;
- components receive valid data and labels;
- focus order and semantics survive every permitted layout;
- user edits and selections persist through local recomposition;
- interface descriptions that fail validation resolve safely to a known surface.
Other qualities require evaluation across a distribution of scenarios. Is the composition relevant to the stated goal? Does it omit a fact needed for a sound decision? Does it overstate an estimate? Does it preserve enough continuity after a follow-up? Does it systematically create worse experiences for a particular language, ability, account type, or level of expertise?
The test strategy becomes layered:
component tests known behavior of individual elements
constraint tests properties every valid composition must satisfy
scenario evaluations quality across representative tasks and contexts
adversarial evaluations harmful, deceptive, or incoherent edge cases
production observation behavior in unexpected situations
The first four layers lead into essential production observation. A runtime system will encounter combinations beyond the scenario set. Teams need to observe which surfaces are produced, where users correct them, which compositions are saved, where people retreat to a standard screen, and which actions are abandoned.
That observation must respect privacy and keep personalization accountable. A generated interface should be traceable to its task interpretation, input data, component versions, policies, and composition decisions. That record makes a harmful experience reproducible and explainable.
Runtime composition turns interface quality into an operational concern. Design, development, and QA continue after release because the artifact continues to be produced there.
Authorship moves, responsibility remains #
When a system arranges an interface at runtime, it is tempting to say that the AI has become the designer. That description confuses the production of one arrangement with responsibility for the system that made it possible.
The runtime may choose a table over a chart. The product team determined what each representation means, which data it can receive, what evidence the choice should depend on, and what rules the result must obey. The user contributes the goal and corrects the interpretation. Domain experts define what is valid and consequential. The particular surface has distributed authorship.
Responsibility remains with the organization that exposes the capabilities and deploys the system. The organization retains accountability for what the interface makes visible, what it hides, which actions it encourages, how it behaves across populations, and how a person can challenge its interpretation.
The disciplines may consequently overlap more. Designers work with schemas, policies, and evaluations. Developers make interaction semantics executable. QA helps define system-wide properties before implementation. Researchers study both whether people can complete a known flow and how they form goals, recognize misinterpretation, and recover across changing surfaces. Domain, legal, accessibility, security, and support knowledge shape the interaction language during construction and guide reviews of finished screens.
The familiar linear handoff gives way to stewardship of a living system.
What the team ships #
A runtime interface requires far more from product design than supplying components to a model. The team ships a position on how the software should meet a person:
the concepts the product can express
the capabilities it can safely offer
the evidence it uses to interpret a situation
the grammar through which it forms an interaction
the invariants that preserve meaning and trust
the evaluations by which its behavior is judged
Screens remain part of the work. Some should stay fixed. Some will serve as reference compositions and fallbacks. Some generated workspaces will become stable after repeated use. The complete product experience extends beyond any finite collection of screens.
Design moves from specifying every path to establishing the conditions under which useful paths can be formed. Development turns those conditions into a reliable runtime. Quality assurance evaluates properties of the resulting space. Together, these disciplines decide how much authorship the system may exercise and how much certainty it must earn before doing so.
Once that machinery exists, the screen becomes one natural boundary among several. The interaction can be assembled around a goal using capabilities that live behind many screens—and eventually, capabilities that live behind many applications.