Designing Behavior, Not Just Interaction

Two earlier maps establish the materials. The product layers in Chapter 2 — state, memory, permissions, timing, confidence, orchestration, recovery, visibility — name what is beneath the interface. The negotiation loop in Chapter 3 names how the product moves between user and system over time. Behavior design joins them through active decisions: which questions to answer when a feature has the option to act on its own.

From clicks to choices

A button can initiate a simple command or a sophisticated chain of interpretation, tool use, review, and recovery. User-initiated behavior is not lesser behavior. A click-triggered prototype can test modern software well when the risk begins with an explicit command.

A behavior is different. Autosave is a behavior. The way a notification batches itself instead of firing six times in a minute is a behavior. The photos app that surfaces a “memory” from a year ago — picking the trip and not the funeral, picking the friend and not the ex, picking the morning the user is most likely to want it and not the moment they are walking into a difficult meeting — is a behavior.

Each of those is the system making a decision over time, sometimes without a click as the immediate trigger.

The shift is not from interaction to behavior as if one replaces the other. It is from treating the interaction as the full unit to designing the system's stance around it. The behavior’s job is to respond well — sometimes by acting, sometimes by waiting, sometimes by deferring, sometimes by preparing a recovery path.

The visible part of an interaction is often enough to understand its shape. The visible part of a behavior rarely is.

Products that feel intelligent rarely have a single feature you can point at. The intelligence is distributed across choices the system is making moment by moment, most of which never surface as a screen.

That is why behavior has become its own design material.

The layers beneath the interface produce behavior

A product lives beneath the interface: in state, memory, permissions, timing, confidence, orchestration, recovery, and visibility.

Those layers are not static architecture. They are what produce behavior.

State decides what is possible. Memory decides what carries forward. Permissions decide who has authority. Timing and confidence shape how boldly the system moves. Recovery and visibility decide whether that movement can be trusted after it happens.

A product behaves because those layers interact.

This is why behavior design is not the same as adding “smart” features. A product can have AI inside it and still behave badly. It may generate useful output while interrupting too often, acting without authority, hiding its assumptions, or asking the user the same question forever.

Behavior is not intelligence alone. Behavior is intelligence shaped by product judgment.

The questions behavior asks

There is a working set of questions a behavior designer asks for any system worth shipping. Each one looks small. Each one is the seed of a long argument.

What should the system notice?

Notice is the front edge of behavior.

The autosave that knows about pause length. The spam filter that knows about a sender’s history with you. The calendar that notices you keep declining a recurring meeting. The finance tool that notices a merchant appears every month but is categorized differently each time.

Anything the system does not notice, it cannot act on. Anything it notices that it did not need to is surveillance dressed as feature.

This is the first discipline of behavior design: deciding what the system has the right to observe.

What should it infer?

Inference is what the system does with what it noticed.

The expense category guessed from the merchant. The thread the half-finished message belongs to. The meeting intent inferred from a vague sentence. The “you usually wake up around seven” that lets an alarm be soft instead of jarring.

Inference is where uncertainty enters the work. The product needs evidence about how reliably the system handles this kind of case before it acts. That evidence should distinguish a fact, a pattern, an explicit preference, a guess, and a coincidence. A model's self-reported certainty is not a substitute for measured task performance; research on verbalized confidence shows that its calibration depends strongly on how the model is asked.

A product that cannot tell those apart will behave with the wrong posture.

What should it do?

Acting is the part teams over-design and under-decide.

Most “the system should…” sentences in a spec are wishful. The real question is which actions the system takes on its own authority, which it stages for review, and which it escalates.

It may need to save, suggest, send, archive, pre-fill, block, or ask someone else. Each option changes the product’s posture.

A system that always acts is reckless. A system that waits for an explicit command may be exactly right when the user should choose the moment. The craft is in deciding where initiative belongs for this task.

What should it ask first?

Asking is expensive.

Every confirmation dialog is a small admission that the system did not trust itself to act. Sometimes that admission is respect, not weakness.

Destructive actions, irreversible payments, legal commitments, public posts, sensitive messages, anything a user would feel betrayed by — these often deserve explicit confirmation.

But many confirmation dialogs are not respect. They are uncertainty pushed onto the user. A good behavior asks rarely, asks well, and remembers the answer.

It does not ask because the team was afraid to decide. It asks because the user’s authority matters.

What should stay visible?

Visibility is what lets a user trust a behavior enough to keep letting it happen.

The “saved” timestamp. The reason an email was filtered. The list of files an assistant just touched. The explanation for why a transaction was categorized. The note that a suggestion is based on last month’s pattern, not a rule.

A behavior that hides what it did has to ask for trust every time. A behavior that shows what it did can earn trust once and reuse it.

Visibility does not mean flooding the interface with system noise. It means making the right part of the behavior legible at the moment trust depends on it.

What should be reversible?

Reversibility is the safety net that lets a behavior take more risk.

An auto-archive that can be restored in one click is often a stronger product than an archive that asks first and lives forever. A draft rewrite that can be compared against the original lets the system be more useful. A bulk action with clear undo is less frightening than a product that asks for confirmation at every step because recovery is weak.

The cost of a wrong action is the time, attention, and anxiety it takes to undo it. Cheap undo lets the system do more. Expensive undo forces the product to ask, block, and hesitate.

Recovery is not what happens after behavior design fails. It is what makes better behavior possible.

When should it back off?

Backing off is the part most products never learn.

The photos app that stops surfacing memories from the same week after the user dismisses two in a row. The notifications that quiet themselves in the hour after you mute one. The interpretive step that hands control to an exact rule when its tested conditions are not met. The assistant that stops offering summaries for a thread after you repeatedly ignore them.

A behavior that does not know how to back off becomes noise. A behavior that backs off well becomes a colleague.

This is one of the clearest differences between a product that is merely active and a product that feels intelligent.

Intelligence is not only knowing what to do. It is knowing when the help has stopped helping.

These seven questions do not give you a product. They give you a way to argue about one. And that is already a great deal, because many weak products are not weak because the team lacked ideas. They are weak because the team never had the right argument.

Example: the feature request becomes a behavior spec

The running B2B example is illustrative. It represents an accounts-payable product, not published client work or measured performance.

A product team writes a small feature request:

“Review incoming invoices and prepare clean ones for approval.”

As an interaction, the request looks simple. Add an invoice queue, show extracted fields, and place an Approve button beside each row. As behavior, the request becomes more serious.

The system has to notice an invoice arriving, identify the supplier and legal entity, extract line items, apply exact validation rules, interpret uncertain coding and policy questions, and decide what to prepare. It must never confuse a plausible category with permission to post or pay.

A behavior spec would not stop at “show invoice row.”

It would say:

• Trigger: an invoice enters the monitored mailbox for an enabled legal entity.
• Inputs: the original file, verified supplier record, purchase order, receipt, company policy, and prior explicit mappings within the correct team scope.
• Exact rules: amount totals, currency, duplicate detection, legal-entity permission, and workflow state.
• Interpretive work: line-item coding, likely policy exception, and which reviewer has the relevant context.
• Evidence: keep every extracted value tied to its source region; record policy version and data freshness. Two sources that repeat one stale error still count as one weak origin.
• Measured reliability: use repeated representative trials for each field and exception class. Do not use a confidence percentage produced by the model as the release threshold.
• Authorization: prepare a clean invoice for review. Do not approve, post, schedule payment, or contact the supplier without the permission that action requires.
• Consequence and recovery: a wrong code can be corrected before posting; a scheduled payment needs cancellation rules; a settled payment requires compensation, not a fictional undo.
• Visibility and correction: mark facts, inferences, rule matches, missing evidence, and policy conflicts separately. Preserve the original and let the reviewer correct one field without discarding the rest.
• Backoff: route unsupported layouts, conflicting sources, and repeated corrections to manual review.

The artifact is not a longer feature spec. It is a behavior spec: a compact account of the system's attention, evidence, reliability, authority, consequences, visibility, correction path, and retreat condition.

The difference is not polish. The second version designs the system’s stance. It gives the team something concrete to argue about before the screen starts making the behavior feel decided.

One behavior across several interfaces

The invoice workflow may begin on a desktop, but it is not confined to one screen. An operator can inspect line items in a table, capture a missing receipt with a camera, ask by voice which invoices are blocked, or approve a prepared item through a system assistant. These are interfaces to one product, not four separate features.

Continuity comes from shared state and control. If the camera captures a receipt, the desktop review should show which field changed and why. If voice reports that an invoice is ready, “ready” must mean the same workflow state the table displays. If an assistant prepares an approval, the operator must still be able to inspect, pause, or cancel the same action elsewhere.

Each modality is suited to different work. A camera is good at capture and poor at resolving an ambiguous legal entity. Voice can retrieve a short status while someone's hands are occupied; it is a poor surface for comparing 20 line items or handling private data in a shared room. A desktop is strong for dense review. A system assistant is useful when the action can be expressed through a stable contract. Apple’s App Intents documentation is one current example of exposing the same actions and data to Siri, Shortcuts, Spotlight, widgets, and other system surfaces.

Sensing adds ambiguity. A camera frame may cut off a total. Speech recognition may confuse a supplier name. The device may not have permission to use the microphone, camera, or document store. The product has to show what it sensed, ask for disambiguation when the uncertainty matters, and offer a manual path that reaches the same state without punishing the user.

Interruption is a product decision too. A voice flow can be cut off. A phone can lock during capture. An assistant can hand control back after finding a policy conflict. The work should resume from a legible checkpoint, not restart because the interface changed.

None of this makes a native app, camera, voice surface, or assistant mandatory. The modality earns its place when it lowers the risk or effort of a specific moment. The product remains the behavior and state beneath all of them.

Restraint is half the craft

Most behavior decisions are decisions about what not to do. The autosave that holds for a beat instead of firing on every keystroke. The transaction that does not auto-categorize when the merchant string is ambiguous. The smart reply that does not appear in a thread whose emotional weight the system has no right to flatten. The photos app that does not surface a memory when the system cannot tell whether the people in it are still in the user’s life. The system that does not act on a low-confidence inference, even though it could, even though acting would feel impressive.

Restraint is hard. Not because the design call is subtle, but because two structural forces work against it on every team.

Restraint does not demo well. A feature that does something is easy to show. A feature that wisely does nothing in the right context is invisible until the context arrives, and then is invisible because nothing went wrong. Teams that cannot tell the difference between “the system stayed quiet by design” and “the system stayed quiet because nothing was built there” will reliably under-invest in restraint.

Restraint also requires an operational release rule. To not act, the product has to detect when evidence, measured reliability, authorization, consequence, or recovery does not support action. That is a real engineering shape: uncertainty and authority propagated end to end, surfaced honestly to the part of the system that decides whether to step forward.

Most products lack that shape. The ones that have it tend to feel calmer than the ones that do not.

Restraint is what makes visible behavior trustworthy.

A system that acts every time it could is a system the user has to override every time they disagree. A system that acts only when it should leaves the user with energy to do their actual work.

This is one reason behavior design is more than interaction design with AI added. It is a discipline of initiative and restraint.

The argument inside the craft

Behavior design becomes real when a team can argue about it precisely.

Two senior people can disagree about whether a system should infer or ask, and the disagreement can be productive. It surfaces what each of them believes about authority and the cost of being wrong.

Should the assistant archive automatically, or stage the action?

Should the product ask every time, or only after a failed recovery?

Should a repeated correction become a preference, or remain local to the session?

Should weak evidence be shown explicitly, or expressed through more restrained behavior?

Those are not decoration questions. They are product questions with technical and ethical weight.

That kind of disagreement is not process noise. It is the craft becoming explicit.

Modern software is not only a sequence of screens. It is a pattern of behavior. And patterns of behavior deserve design.

Sources and revision note

Historical scope, confidence language, and cross-modality guidance revised 13 September 2026. The historical grounding follows the HCI sources linked in Chapter 1. The confidence qualification cites research on verbalized model confidence; the modality example cites Apple's App Intents documentation. The invoice workflow is illustrative and does not report deployed-product results.

Framework

Behavior Design Questions

A working list of questions to ask when designing behavior rather than interaction.

01 — Notice

What does the system observe, and what should it ignore?

Behavior begins with attention. Deciding what the system notices is also deciding what kind of power it has.

02 — Infer

What meaning does the system derive, and how confident is it?

The product must distinguish between facts, patterns, preferences, guesses, and uncertainty.

03 — Act

What can the system do without explicit instruction?

Initiative is useful only when it is bounded by measured reliability, authority, consequence, and recovery.

04 — Ask

Where does the system need consent, confirmation, or human judgment?

Asking should be a designed act of respect, not a substitute for product judgment.

05 — Reveal

What must stay visible for trust to hold?

The user needs to understand enough of the behavior to keep granting the system room to act.

06 — Reverse

How does the user recover from a wrong action?

Reversibility lowers the cost of recoverable mistakes. Irreversible consequences still require a different authorization boundary.

07 — Back off

When should the system stop helping?

A good behavior knows when its assistance has become interruption.

The framework is simple because the arguments are not. Use it whenever a feature starts to behave on the user’s behalf.

The seven questions open the discussion; they do not complete the specification. A behavior spec also records which rules stay exact, the quality and freshness of evidence, measured task reliability, authorization, consequences, and the recovery or compensation path.

Argues from Tenet II