UX is part of the system

A useful new capability may belong inside the software people already use. A record arrives with the right fields filled in. Search finds the relevant material. A routine handoff happens without another application to open.

Where a new interface is needed, it should be easy to understand and operate. Familiar controls, clear language and responsive feedback matter, as does a dependable way to return to unfinished work.

User experience, or UX, covers that whole journey. The user interface is the part through which people see and control it. Both belong in the initial engineering decisions: where the capability lives, what it asks of people and how it behaves when work takes time.

Start where the work happens

Follow the existing task before designing a new destination. Where does it begin? What information is already present? Where does the result need to go?

An integration may remove copying between systems. An inline suggestion may help someone finish a form. A background process may prepare information before it is needed. Each can make a capability useful without requiring another workspace.

Unobtrusive automation still needs a way to inspect results, correct mistakes and recover. Keep routine operation quiet while placing exceptions beside the affected work.

These choices can coexist. An existing application may not support a necessary comparison or review, in which case a dedicated interface is justified. Working alongside users helps establish where that boundary belongs.

Give conversation a specific job

Chat helps people express an intention in their own words and develop it through follow-up questions. It can make an unfamiliar task approachable without requiring someone to know the application's vocabulary.

A blank text box also asks a lot. The person must work out what the system can do, what context it has and how to ask. Requiring a typed request for a familiar action may add effort. Comparing options across several messages can make people remember information that a table could keep visible.

Bret Victor's Magic Ink argues for helping people understand through presentation, reducing the interaction needed to obtain information. Applied to an assistant, that suggests showing useful context before asking for another query: a status, comparison or source excerpt may already answer the question.

Show the conversation's scope and make it correctable. Ask for missing information when it changes the result. Let people edit a proposal directly, and preserve useful outputs somewhere they can return to without searching a transcript.

Make the next action predictable

A person should be able to anticipate an action and recognise its result. Use the vocabulary of the work, consistent names and familiar controls. Keep the information needed for a decision beside the action it affects.

Distinguish a proposed change from a saved one. Make pending work and recovery actions legible. A sparse screen still creates effort if it hides the context needed to proceed.

Preserve that context during ordinary movement. Opening a source and returning should restore the reading position. Inspecting an alternative should retain filters and selection. Leaving an edit should have a clear outcome for the draft.

The same tasks need to work with keyboard input, screen readers and enlarged text. Building accessible visual software develops this requirement for more complex interfaces.

Measure time across the task

There is the delay before an action receives feedback, the wait for useful content and the time until the operation finishes. There is also time spent finding controls, clarifying requests and checking results.

Craig Mod's Fast Software, the Best Software connects quick response with purposeful, understandable interaction. It is a design essay, not a benchmark. Its useful challenge is to examine the effort between intention and result as well as computation time.

Measure the delays separately. Immediate token streaming may still leave someone waiting for usable content. Several clarification rounds may take longer than filling in a well-designed form.

Fix the measured cause. Remove unnecessary sequential requests, keep expensive processing away from typing and navigation, and cancel superseded searches. Avoid letting an older result replace the current query's result. Cache where appropriate while preserving relevant freshness information.

Evaluate a simpler model or conventional operation when it can meet the same requirement. Include review and correction time, and test slow cases on representative devices and networks.

Respond promptly and describe the real state

An interface can acknowledge an action before the work finishes. An upload can enter a queue and a request can show that it has started. The feedback should name the state actually reached.

For longer work, show progress the system can observe. Avoid invented percentages or an indefinite typing indicator that gives no account of whether anything is happening. Let the person continue elsewhere and return to the result.

Apple's Designing Fluid Interfaces emphasises response, interruption and redirection. Applied to asynchronous work, the question is whether someone can revise a search, stop generation or leave a task. That is an application of the interaction principle, rather than a result evaluated by the talk.

Cancellation needs an honest outcome. Stopping visible generation may leave an external operation running. Show whether cancellation is pending or whether the action already completed. Likewise, distinguish a local draft from a server-accepted update when the difference matters.

Test the interrupted journey

As a constructed test, consider someone reviewing a proposed update. They open a source, change a field, leave to answer another request and return on a slow connection. The product should preserve the draft, explain whether anything was submitted and provide a clear way to continue.

Observe whether people can find the next action and explain what happened without coaching. Include empty results, long content and failed requests. Measure completion, waiting, correction and recovery.

For an AI capability, compare the journey with the existing process and a credible conventional interface. Choose where the capability belongs, make its actions understandable, and check that people can resume their work. Those details determine whether the new feature actually helps.