Stable ground: trust, control, and discovery

Published:

A predefined interface gives the user more than controls. It gives them somewhere to stand. The navigation remains in the same place. A transfer button continues to mean the same thing. A report reopened tomorrow has familiar columns. Even when the data changes, the surrounding structure lets people recognize where they are, anticipate what an action will do, and recover from a mistake.

A situational interface can improve the fit between a goal and the software. It can remove irrelevant controls, combine information that normally lives on separate screens, and choose a representation for the present task. The same flexibility can also remove the landmarks through which the user understands the product.

If every intention produces a different surface, several ordinary questions become difficult:

Where am I?
Why am I seeing this?
What else can the system do?
What changed since last time?
How do I return to something I recognize?

They are design requirements for runtime composition. The interface may be fluid only if the relationship between the user and the system remains intelligible.

Familiarity is functional #

Consistency is sometimes treated as a visual preference: buttons should look alike, spacing should follow a scale, and screens should share a style. Its deeper value is that repeated structure becomes knowledge.

A person who uses an application regularly develops spatial memory. They stop reading every label and begin acting through recognition. They know that primary actions appear in one region, filters in another, and account identity remains visible near the top. An expert can operate a dense interface quickly because much of its structure no longer requires conscious interpretation.

Generated interfaces can accidentally discard that accumulated knowledge. A system may produce a locally sensible arrangement on every visit while moving controls, renaming concepts, changing representations, or hiding actions it considers irrelevant. Each surface may be clear in isolation. Across time, the product becomes unlearnable.

Adaptation therefore needs continuity. A runtime may choose which information belongs together without freely changing every convention through which that information is understood.

Some landmarks can remain stable across situational views:

  • the identity of the product, user, account, or workspace;
  • the location and meaning of global actions;
  • the visual treatment of warnings, estimates, and confirmed facts;
  • the behavior of selection, editing, saving, undo, and confirmation;
  • the vocabulary used for domain objects and consequential actions;
  • a reliable route back to familiar navigation and saved work.

These invariants form a shell around the generated surface. They reduce the number of new decisions a person must make before attending to the task itself.

Show the interpretation #

An authored screen usually has an evident reason for its contents. A transactions page contains transactions because that is what the page was designed to contain. A situational interface has made additional decisions: it has interpreted an intention, selected relevant information, excluded other information, and arranged the result around an inferred task.

Those decisions should not disappear behind a polished surface.

Consider a system answering:

Can I afford a $3,000 holiday next month?

An estimate of $2,150 available appears precise, but it depends on assumptions. The system may have included expected salary, excluded a joint account, estimated ordinary spending from recent history, and preserved an emergency reserve. If those choices are invisible, the user cannot judge whether the answer deserves trust.

A generated surface should distinguish among:

authoritative facts     current balances and scheduled payments
derived values          forecast cash position
assumptions             expected spending and desired reserve
uncertainties           incomplete dates or unknown obligations
proposed actions        create a savings plan

This requires a visible path from the result to its basis. The user should be able to inspect why information was included, change a material assumption, and identify which system or record supports a claim.

The interface should also expose its understanding of the task. A heading such as Holiday affordability for September does useful work. It lets the user notice that the system has interpreted “next month” incorrectly, chosen the wrong trip, or answered a narrower question than intended.

Trust comes less from the system sounding certain than from making its reasoning open to correction.

Preserve continuity #

Intent develops during interaction. A user changes a date, adds an account, selects a transaction, or asks a follow-up question. The runtime may then have reason to alter the interface.

Recomposition should not feel like replacement.

If a chart becomes useful, it can appear beside the existing summary rather than causing the entire workspace to regenerate. If an assumption changes, affected values can update while selections and notes remain in place. If the system reorganizes a substantial part of the surface, it can show what changed and why.

stable regions
    +
local, visible updates
    +
preserved user state
    =
continuous interaction

This resembles good behavior in conventional applications, but runtime composition makes it more important. A predefined screen has a limited set of known transitions. A generated workspace may have many valid next forms. Without continuity, every adaptation asks the user to rebuild their mental model.

History provides another form of continuity. A useful situational view should be saveable when the task persists, restorable after a detour, and discardable when it does not. Undo may need to cover changes to the interface as well as changes to the underlying data.

The user should be able to say, in effect:

return to the previous arrangement
keep this view for next week
stop adapting this region
show me the standard screen

A generated interface becomes safer when its transformations are reversible.

Control over adaptation #

Personalization often happens silently. A feed changes its ranking, a dashboard promotes a metric, or a recommendation system selects what to show. Silent adaptation becomes more consequential when it changes not only content but the structure through which a user can act.

People need control at several levels.

At the task level, they should be able to correct the system's interpretation. At the surface level, they should be able to keep, move, hide, or restore useful regions. At the product level, they may need to choose how much adaptation they want.

Different situations justify different defaults:

Situation Appropriate adaptation
One-off exploration Freely propose representations and supporting information
Repeated expert work Preserve a stable workspace and offer changes explicitly
High-risk action Use constrained, reviewed patterns with explicit confirmation
Accessibility requirement Preserve the user's chosen presentation and input conventions
Uncertain interpretation Show assumptions and ask before restructuring the task

Control does not mean presenting a preference for every compositional decision. A system that asks permission before every useful adjustment would merely replace navigation work with configuration work. The goal is meaningful control over changes that affect orientation, interpretation, or consequence.

A practical model may combine automatic composition with boundaries the user can set:

adapt this view
suggest changes but do not apply them
keep this arrangement stable
always use the standard workflow for this action

The system can learn preferences without treating inferred preference as permanent consent. What it has learned should remain inspectable and resettable.

Discovery without a map #

Fixed interfaces make capabilities visible through menus, navigation, controls, and empty states. Their information architecture may burden the user, but it also acts as a catalogue. Browsing the product teaches people what the product can do.

An empty prompt provides little of that knowledge.

What would you like to do?

The question offers freedom only to someone who already understands the available possibilities. A user may not know that the system can compare scenarios, explain a fee, prepare a dispute, combine several accounts, or save a recurring workspace. They cannot express an intention around a capability they do not know exists.

Natural-language interaction therefore does not eliminate information architecture. It changes how that architecture is exposed.

A situational system can support discovery through several layers:

  • a stable capability map for browsing the product's objects and actions;
  • examples that demonstrate the kinds of outcomes the system can pursue;
  • contextual suggestions based on the current data and task;
  • visible actions attached to generated results;
  • progressive disclosure of related capabilities;
  • search that returns actions and explanations as well as records;
  • familiar screens that remain available as anchors and fallbacks.

Suggestions need particular care. “You might also…” can reveal a useful next step, but it can also become advertising, manipulation, or noise. A trustworthy suggestion should have an understandable relationship to the current task. It should not quietly substitute the product's commercial objective for the user's intention.

Discovery also requires negative knowledge. The system should be able to communicate what it cannot access, what it is not permitted to do, and which actions require another application or person. A capability boundary is part of the map.

A stable layer #

The likely interface is neither a permanent set of screens nor an endlessly regenerated surface. It is a layered system:

stable product identity and interaction conventions
                         +
browsable capabilities and familiar fallbacks
                         +
saved work, history, and recovery
                         +
situational views composed for the present task

The stable layer gives generated interfaces meaning across time. It lets a user transfer knowledge from one situation to another, distinguish product behavior from runtime interpretation, and return to a known state when adaptation fails.

The situational layer does different work. It reduces the distance between a goal and the information or actions needed to pursue it. It can be temporary without being disorienting, and personal without becoming opaque.

The design challenge is to decide which qualities belong to each layer:

Let the arrangement respond to the situation while identity, meaning, consequence, and control remain stable.

That division changes the work of product teams. Designing every final screen is no longer sufficient, but neither is supplying a set of components and asking a model to arrange them. Someone must define the grammar of adaptation, the invariants beneath it, and the evidence by which a space of possible interfaces can be judged.

The changing interface implies a changing practice of design.