Return Request

Start a return with item selection, reason, condition, refund method, pickup or drop-off option, and eligibility clearly explained. This example brings Items and Reason together so shoppers can find the next task without losing context.

It includes representative records such as Choose items to return and Select return reason. Use the screenshot to study the layout, then adapt its components and product states to your own design system.

Return Request

Template facts

Screen

Form

Primary action

Submit return

Pattern

Form

State

Default, loading, empty, error, permission, success

Design system

Configurable product UI theme

What this screen helps users do

Finance and operations teams need to submit return while keeping eligible items, return window and exceptions visible. The interface should show what changed and who should act next.

Key elements

  • Main workspace: Items gives users an obvious place to start.
  • Supporting view: Reason keeps the related context close.
  • Primary action: Submit return stays visible when people need it.
  • First signal: Eligible items shows a useful value (3).
  • Second signal: Return window gives additional context (28 days).
  • Sample record: Choose items to return.
  • Next record: Select return reason.

States worth designing

  • Required field missing: say what changed, protect progress, and offer a clear next step.
  • Invalid value or incompatible data: say what changed, protect progress, and offer a clear next step.
  • Draft saved: say what changed, protect progress, and offer a clear next step.
  • Submitted for review: say what changed, protect progress, and offer a clear next step.
  • No permission to submit: say what changed, protect progress, and offer a clear next step.
  • Temporary save failure: say what changed, protect progress, and offer a clear next step.

Where this screen sits in the flow

Items → Reason → Submit return → Review outcome

Patterns used

Form, Items, Reason, contextual actions, error recovery

Why these choices work

Show requirements beside fields and retain values after failed checks. Validate only the affected input and make the next step unmistakable.

Pay attention to items and reason. People need to distinguish Choose items to return from Select return reason. Keep eligible items visible, especially when a record changes owner or status.

Before this screen reaches handoff, verify keyboard focus, empty and permission states, and what happens after someone chooses “Submit return”. Make error recovery as clear as the happy path.

Related screen examples to explore next: Order Detail, Checkout Success, Order Tracking.

Start from this in Figr

Design a return request screen inside our existing product. Use our current components, tokens and content language. Include Items and Reason views, credible records like Choose items to return, and a clear “Submit return” action. Use our product permissions and show loading, empty, error and success states. Keep the output editable in Figma.

Open Figr