01 / context
One order. Many systems behind it.
A customer sees one marketplace, while sellers, delivery providers, support teams and payment systems each own a part of the experience. This self-initiated concept asks how those parts can communicate one understandable promise.
The scope runs from seller selection and checkout through delivery exceptions, returns and refunds.
02 / diagnosis
Operational status is not always a useful answer.
The design hypothesis is that customers need to know what was promised, whether it is still on track and who owns the next step. Separate seller, carrier and refund states can push the work of interpretation onto the customer.
03 / decisions
Make continuity the design unit.
Existing interface concepts from the original project. The screens use illustrative data and are not live client interfaces.
An all-in offer
Compare price, shipping, seller confidence and delivery information together, before a commitment is made.
A visible order promise
Explain package splits and expected delivery windows during checkout, then keep that expectation visible after payment.
A recoverable exception
When the promise changes, show ownership, available options and a return or refund timeline in one continuous experience.
04 / service
The interface depends on service ownership.
A promise cannot be maintained by screen design alone. The concept also depends on usable seller data, reliable fulfilment events and clear ownership across support and payment processes.
The proposed service model connects the visible customer timeline to those backstage responsibilities. Without that connection, a status display can become another place where the customer has to seek an answer.
Price, contents, delivery expectation and applicable conditions.
Translate service events into a clear expectation and next action.
Give a named owner, options and visible recovery progress.
05 / validation
Measure the journey across its seams.
A proposed study would test seller comparison, split-order comprehension and recovery tasks. It would check whether people can identify the owner, next step and expected resolution from the interface.
06 / outcome
A service model to evaluate.
A promise model spanning selection, fulfilment and recovery. Its effect on confidence and service outcomes remains to be evaluated.
Next project