Design Engineering and AI Interfaces

Work, authority, and interaction models

A project owner wants task records to reflect a planning meeting. The manual path is to read the notes, identify affected records, edit fields, and save. In the constructed design used here, assistance proposes changes; the owner inspects, revises, or declines them before authorizing selected updates. Proposal generation and record modification have separate completion boundaries. [1]

User control means practical abilities to inspect, change, decline, interrupt, and recover from assistance. Responsibility also includes waiting and handoffs: someone must resolve an unanswered ownership question or a failed update. Forward Deployed Engineering explains this broader workflow boundary. [2][3]

Mixed initiative means both person and system can propose the next step. Conversation can clarify a request while a persistent table holds the proposed updates. Direct manipulation means editing those visible records rather than describing every adjustment in text. Personal Agents develops persistent delegation as one setting for this combination. [4]

Discoverable capabilities and editable intent

An affordance is an action possible for a particular person in an environment. A signifier is a perceivable cue communicating an action or condition. A visible Apply label does not establish that applying is currently permitted. Norman's distinction separates the available action from the evidence through which someone discovers it. [9]

A mental model is a person's working understanding of system behavior. Clear capability statements and predictable controls help people express intentions and interpret results. Progressive disclosure initially exposes important options, with clearly labeled access to specialized detail. It differs from sequential task stages; consequential scope belongs in the primary view. Progressive Disclosure explains the distinction. [2][10]

The request “update the launch tasks” leaves scope and timing ambiguous. A reversible preview can expose the interpretation cheaply. Ask a targeted question when the unresolved detail changes a consequential action, such as which person receives an assignment. Preserve earlier selections and constraints when the answer arrives. [4][2]

Show which project and inputs inform the proposal. Project-scoped context offers a familiar boundary, but grouping alone does not establish technical isolation. Context Engineering covers input assembly; Agent Memory covers retained information. Here, users need to inspect and change the relevant scope. [11]

Uncertainty and useful next actions

System feedback is information the interface returns about an action, state, or result. Useful feedback connects a missing fact to an available response. The following four categories organize different problems in the task workflow; they are not a confidence scale. [1][12]

Appropriate reliance includes accepting useful assistance and rejecting erroneous assistance. Automation bias is undue deference to automated advice. Review must therefore expose evidence that can contradict a recommendation, not merely make the recommendation persuasive. [14]

Calibration means stated probabilities agree with observed frequencies for a specified event; Evals develops the measurement. Fluent wording or model-reported certainty is not that evidence. Test confidence displays for comprehension, and prioritize output-specific explanations that help users decide what to do. [12]

Actual progress, interruption, and return

Request acceptance, active work, usable output, and confirmed record changes are different milestones. A long-running operation can expose progress before producing its final result. [13]

Observability means investigating behavior through evidence; Observability covers the internal machinery. User-facing progress should connect activity to useful work. Missing updates do not establish stopped execution, as diagnostic coverage explains. [15]

Stopping presentation only hides updates. Cancellation requests execution to stop; confirmation requires checking its outcome. An operation may complete despite the request. The documented cancellation contract illustrates this distinction without promising rollback. [19]

Pause and resume require supported execution state. The Agent Continuations prototype returns suspended state so a process can shut down and resume later. That does not establish safe interruption of every in-flight tool. Changed instructions should enter a visible revision or supported pause boundary, rather than silently changing already dispatched work. [20][21]

Review and authorization of specific changes

Review evaluates a proposal; authorization permits an effect. A useful review surface exposes existing values, proposed values, supporting information, consequences, and unresolved assumptions. Reviewers also need evidence, expertise, time, authority, and alternatives—the general prerequisites explained in AI in Healthcare, without transferring clinical obligations to project management. [3][23]

Approval must bind to the inspected version and selected changes. If significant values change, renewed authorization is required. The execution boundary must enforce that binding; a dialog alone cannot. Privacy and Data Governance develops this responsibility. [24]

Review cadence has competing costs. Giant batches obscure assumptions; constant confirmations can encourage habitual acceptance. Meaningful increments should expose decisions before mistakes propagate. These are attention risks to test, not evidence for a universal batch size or prompt frequency. [25]

Correction, undo, and recovery

Editing an unapplied proposal changes no stored record. Regenerating selected content should preserve accepted portions and human edits. Recoverable versions support experimentation; they do not automatically reverse external effects. [26]

Compensation is application-specific corrective work after effects occur. It may not restore the original state, and it can fail. Restoring an old snapshot can overwrite concurrent changes. AI in Healthcare explains the general distinction between rollback and recovery. [27]

This example requires separately retained local edits, record-version checks, and authoritative lookup of an operation's result. Duplicate-submission safety is not assumed. Those requirements need implementation evidence. Ignoring an obsolete response protects presentation; it neither cancels server work nor preserves edits automatically. [28]

When automatic recovery cannot finish, identify the remaining effect, responsible person, and manual next step. A closed error message is not completed recovery; the person affected needs the resulting disposition and correction status. [29]

Feedback scope and follow-through

User feedback is a person's report, rating, explanation, or correction. Unlike system feedback, it travels from the person into the product's processes. Link a report to the relevant task or output, with its criterion and explanation, so a reviewer can understand what was judged. [30]

A correction can change the current input without changing model parameters. Machine Learning Fundamentals distinguishes inference from training. Feedback controls should promise only the scope and timing their implementation provides. [31][32]

Offer optional reasons rather than making every report an essay. Acceptance alone is a weak success label: someone may accept and then substantially edit or remove the result. Those later changes can indicate errors, preferences, or changed intent. [33][34]

An accountable reviewer decides whether a report warrants repair, a new evaluation case, or no change. Preserve that distinction in status messages. The Braintrust workshop illustrates attaching feedback to a particular execution span and reviewing cases before adding them to evaluation datasets. [34]

Accessibility across changing states

Accessibility enables people with disabilities to perceive, understand, navigate, and operate an interface, including through assistive technology. It concerns participation throughout the task, not merely reading the final output. W3C's introduction defines this scope. [35]

The Web Content Accessibility Guidelines, or WCAG, specify accessibility requirements. Keyboard operation, escape from focus traps, meaningful control names and states, and appropriately adjustable time limits apply across complete processes, subject to each criterion's exceptions. Reviewing and recovering must remain operable alongside generation. [36]

WAI-ARIA supplies semantics for assistive technologies. A live region exposes changing content for announcement. Polite updates generally wait; assertive updates can interrupt speech. Group streamed fragments into meaningful updates, using mechanisms such as aria-busy where appropriate. The specification supplies mechanisms, not an optimal announcement cadence. [38]

Focus identifies the active keyboard target, distinct from selection. New output should not unexpectedly displace it; removing a focused control needs deliberate placement. [37]

Prototypes for behavior and failure

Prototype fidelity should follow the unresolved question. A polished screen can still leave usefulness or execution behavior untested. Prototypes can investigate an artifact's role, its interaction experience, or its implementation; those are different claims. [39]

A Wizard-of-Oz prototype uses a person to simulate some system behavior. It can reveal how users interpret a proposal before automation exists. Keep the simulation consistent and explain its boundaries to the team: it cannot establish deployed model accuracy, latency, cancellation, or recovery reliability. [40]

Designers specify the interaction, engineers establish executable behavior, and researchers test understanding and task use. Establish a simple working baseline before adding agent complexity. Include disabled participants in early task prototypes rather than postponing accessibility until the implementation is expensive to change. [42][43]

Interface promises and implementation contracts

An interaction contract connects confirmed facts to displayed status, available controls, requested operations, and outcome evidence. Keep local interface state, generation state, and stored task changes distinct. Optimistic presentation anticipates success; it must not turn anticipation into confirmation of a consequential effect. [1]

Acceptance tests should exercise rejected transitions as well as successful ones: changed authorization must not apply, an old response must not replace a new selection, and reconnect must not erase an unsaved correction. The operation-identity and edit-preservation requirements above are obligations to implement and verify, not consequences of adding a status label. [24][28][21]

Assign owners for state meanings, accessible components, outcome checks, and unresolved recovery. Preserve stable navigation around variable generated content. Harness Engineering owns execution persistence and orchestration; the interface contract states what those mechanisms must make observable and controllable. [1][44]

Evidence of usable, accessible work

Usability concerns effectiveness, efficiency, and satisfaction for specified users, goals, and context. NIST's definition makes those conditions part of the claim. A fast review interface is not useful if intended users cannot detect an incorrect assignment or recover their edits. [45]

Moderated testing observes likely users attempting believable goals without revealing the intended solution. Think-aloud asks participants to express their understanding as they work; neutral follow-up questions clarify confusing behavior. Compare the manual and assisted workflows on matched task demands. [41]

The fabricated-alert study in exam review tested whether proctors—people reviewing possible misconduct—rejected erroneous assistance in previously certified sessions. Revised instructions required independent suspicious behavior. Model-estimated rejection increased from 50% to 71%, but sessions and periods differed rather than receiving simultaneous randomized assignment. Genuine operational alerts were also rejected more often; those alerts were not ground-truth misconduct. [14]

Automated accessibility tools assist inspection but cannot establish accessibility alone. Combine standards evaluation with disabled participants performing complete tasks, using suitable assistive technology. Report participant characteristics and tested scope; a few participants cannot represent every accessibility need. [47][43]

Open questions

1. 01

   Review cadence remains task-dependent. Frequent interruptions can burden users, while larger batches can conceal consequential assumptions. Progress requires testing decision detection and review effort together under realistic workloads, including whether reduced prompting preserves rejection of harmful changes. [52]

2. 02

   Accessible streaming needs evidence about announcement cadence and review navigation. Fragment-by-fragment speech can compete with task control, but excessive grouping delays useful information. Progress would demonstrate complete review and recovery with intended screen-reader users across tested announcement strategies. [38][43]

3. 03

   Successful recovery after reconnect remains an integration problem when local edits, saved execution state, and external effects diverge. A useful advance would demonstrate preserved edits and resolved operation identity under cancellation races and repeated submissions, without assuming that a checkpoint reverses completed actions. [53]