AI-assisted editorial with original illustrative UI. Examples are fictional; no client performance or user-study results are claimed.
A good answer can still lead to a broken journey
An AI journey breaks when the interface cannot carry a person’s intent, choices and corrections into the next meaningful step. The model may understand a request while the surrounding product forgets it. A chat answer recommends three options, a results screen resets the budget, and a contact form asks for the same details again. Each screen can look reasonable in isolation; the hand-offs make the experience fail.
The central design problem is continuity. In our fictional home-search flow, a user selects two bedrooms, rejects an expensive option and saves a quieter alternative. Returning to the shortlist should preserve those decisions. This is a proposed interaction model, not a report of observed behaviour in a deployed service.
Model the task separately from the transcript
A transcript records what was said. A task state records what the product currently knows, what has been selected, what remains uncertain and what has been done. These are related records, but they are not interchangeable. A changed budget should have a clear current value rather than remain buried somewhere between earlier messages.
We propose a compact task record with five groups: explicit constraints, provisional assumptions, selected items, pending decisions and action receipts. Every surface reads the appropriate part of that record. The chat can explain a change, while the results view reflects it and the review screen carries it forward. In production this needs an actual data contract; visual consistency alone cannot guarantee shared state.
Show what changed, not just that something happened
When a person corrects a constraint, acknowledge its scope. “Budget updated; your saved shortlist is retained” communicates more than a generic success toast. If the correction invalidates an option, explain why before silently removing it. Some people want to keep a deliberately imperfect option for comparison.
Google’s guidance distinguishes explicit feedback from behaviour inferred by the system and asks teams to communicate its effect. [1] Our practical application is a change summary attached to the task: what changed, which results were refreshed and what was left alone. A thumbs-down on a response should not secretly become a permanent preference about every future search.
Disconnected steps
Selections and progress become harder to follow between screens.
A continuous journey
Keep the brief, selected options and recovery point visible.
Carry the task forward
Try the controls. This is an original, local prototype using fictional sample data.
Your brief
Two bedrooms · Quiet area · Annual budget 120,000 AED
Session-only illustration. No account, live search or cross-device storage.Design interruption as an ordinary state
People leave a product to answer a call, check a map or discuss an option. A returning state should summarise the task without pretending that live information has remained current. Separate “your saved criteria” from “results last checked.” Persistence and freshness solve different problems.
The prototype lets you move between a brief, shortlist and review, then simulate leaving and returning. Its state stays inside this article session. It is not a signed-in service, a live property feed or proof of cross-device persistence. The purpose is to make the continuity contract visible enough to discuss and test before building it.
Recover at the point of failure
If a search service fails, keep the brief. If a message cannot be delivered, keep the draft and show whether delivery is unknown or confirmed failed. If an action is irreversible, explain that before approval. “Try again” is only a good recovery action when the product knows what retrying will do.
Google’s graceful-failure guidance includes giving users a path forward when AI cannot help. [2] For this sample, the proposed recovery is to retain editable criteria and expose a conventional browse path. A production implementation must decide how requests are identified and reconciled so that retrying a timed-out operation does not produce a duplicate action.
Measure transitions, not only screens
Test a scenario that crosses surfaces: express a goal, revise one constraint, inspect an explanation, save an exception, leave, return and continue. Ask participants what they think the system remembers and what still needs approval. Watch for mismatches between that expectation and the actual record.
A useful event plan might distinguish a changed constraint, a restored draft and a confirmed action. A page view cannot tell you whether the user had to repeat the same information. Define the completion condition for the entire task, then investigate failure at its boundaries. This article does not report a conversion lift, drop-off reduction or usability-study result.
Audit one boundary this week
Pick a single transition between a conversational surface and a conventional UI. Write the state immediately before it and immediately after it. Check what is dropped, inferred, duplicated or made stale. Then design an explicit recovery for the most consequential mismatch.
The fix may be a shared data object, a clearer acknowledgement or a better review screen rather than another prompt. The product starts to feel coherent when the user can predict what will carry forward. That coherence matters more than making every individual screen appear intelligent.
Sources & editorial notes
Sources checked on 22 October 2026. The frameworks and prototypes are our editorial interpretation, not an endorsement or collaboration with the source organisations.
Have a product or identity challenge? Start with the real task.
Discuss a project
