Building a useful trip can take longer than generating a paragraph.
The planner may need to understand the request, shape a route, divide the trip into days, research places, schedule activities, check the result, and save an editable itinerary. If the interface shows only an animated spinner, the traveler cannot tell whether the work is moving, stuck, or already lost.
Replacing the spinner with made-up progress is worse. Good progress design should explain real work without pretending to know more than the system knows.
Progress should come from durable state
A rotating list of reassuring sentences can make a wait feel friendlier, but it is not evidence of progress. The words will continue changing even when the backend has stopped.
Platix instead treats progress as part of the trip-creation contract. The planning workflow records a bounded stage as work advances. The browser reads that state; it does not infer progress from elapsed time or invent a percentage.
This distinction becomes important as soon as the traveler refreshes the page. If progress exists only in the browser, the experience starts over visually while the original job continues somewhere else. If the stage is durable, another tab or a returning session can show the same truthful position.
Translate machinery into traveler language
Internal execution labels are useful for software and poor copy for a person waiting for a holiday plan.
The interface does not need to announce queue leases, schema validation, provider adapters, or persistence transactions. It can translate those boundaries into a small number of understandable tasks:
- Understanding the trip
- Shaping the route
- Planning days along the route
- Finding suitable places
- Reviewing the itinerary
- Preparing the editable trip
These labels are specific enough to explain the sequence and broad enough to remain accurate when the implementation changes underneath them.
The wording also needs restraint. “Finding suitable places” does not promise that every venue is available or currently open. “Reviewing the itinerary” does not claim that a human travel advisor approved it. Progress copy should name the task, not overstate its outcome.
Do not fake precision
Percentages are tempting because they look objective. They are often misleading in AI workflows.
Planning seven straightforward days may be faster than planning three days with difficult transport constraints. Place research may finish quickly or wait on an external provider. A quality check may accept the first candidate or request bounded repairs.
Without a calibrated history for each kind of trip, a made-up display such as “73% complete” is theater.
A stage indicator and an indeterminate progress bar are more honest. The stages show which kind of work is underway. The motion shows that the client is still receiving active state. Neither claims an exact finish time.
If historical evidence later supports useful estimates, the product can add a range such as “usually a few minutes” for an appropriate cohort. It should not turn one average into a promise for every itinerary.
The first screen should follow the work
When trip creation starts, the traveler should move into a dedicated creation surface rather than watch the original form pretend nothing has changed.
That surface has one job: preserve confidence while the result is not ready. It should keep the request recognizable, show current progress, prevent accidental duplicate submission, offer a safe cancellation path when supported, and hand off directly to the resulting trip.
The same interaction language should apply whether creation began from a prompt, an inspiration, or selected collections. The underlying planning strategy may differ, but “route, days, places, review, save” remains understandable across those entry points.
Failure is also a progress state
A long-running workflow does not become trustworthy by hiding unsuccessful outcomes.
The product should distinguish at least three endings:
Completed means an editable trip was durably saved and is ready to open.
Needs input means planning paused on one traveler-owned decision. The question should explain what is missing without discarding the work already completed.
Could not complete means the operation reached a bounded failure. The interface should preserve the request, provide a safe retry when appropriate, and avoid claiming that a trip exists when it does not.
There is also a useful partial outcome. If the planner can create a coherent draft while disclosing unresolved details, that can be better than returning nothing. The key is to distinguish a usable draft from a complete and verified plan.
Recovery is part of the visual design
The progress screen and backend lifecycle have to agree.
A poll should only observe state, not create more work. A retry should be idempotent. A completed trip identifier should be the authority for navigation. A cancelled operation should reject a late write. A user who changes accounts should not inherit another session's progress.
The interface does not display those rules, but its calmness depends on them. A polished animation cannot compensate for opening the wrong trip, duplicating a plan, or returning to an endless loading screen after refresh.
Test time as well as output
Progress behavior needs tests that manipulate ordering and interruption:
- Refresh while each stage is active.
- Open the same session in two tabs.
- Repeat the start request after a timeout.
- Cancel while work is in flight.
- Deliver an old result after a newer revision exists.
- Complete with a partial but usable draft.
- Fail before any trip is saved.
The assertions should cover both durable state and visible language. A backend stage that the frontend cannot explain is incomplete. A friendly message unsupported by backend state is untrustworthy.
The durable lesson
Progress is not decoration around AI work. It is the user-facing projection of an execution contract.
When stages are durable, language is bounded, and interruption has been designed deliberately, a long-running planner can feel understandable without revealing implementation noise or inventing certainty. The traveler sees enough of the work to know that the system is moving, and enough honesty to know when it needs help.
Loading comments...