Commercial UI/UX for Codex

Refund approval screen — design specification

The screen helps support agents submit complete requests and finance approvers make traceable decisions. This is a design-only demonstration using fictional data; no interface was built or browser-tested.

Roles and assumptions

Support agents can create requests and view their own submissions; finance approvers can review requests within their assigned scope. Approval limits and permissions must come from the server. Amounts always display their currency; do not compare different currencies as if they shared one limit. Actual refund execution, customer notification and policy eligibility are separate backend decisions.

Desktop structure

Keep the existing app navigation. Use a page title, pending-count status and filters for status, currency and assignee above the compact table. Columns: request ID, customer reference, submitted time, amount/currency, reason, status and owner. Selecting a row opens a detail panel with the request, evidence, permission status and chronological audit trail. Keep approve/reject actions beside the relevant amount and reason. Avoid bulk approval for the initial design.

Fictional example: RF-1042, customer DEMO-018, USD 120.00, duplicate charge, awaiting finance review. Example policy: an approver has a USD 500.00 limit. These are demonstration values, not a recommended refund policy.

Main and recovery journeys

1. Support creates a request with an order reference, amount/currency and reason. Show field errors beside the relevant input and preserve the draft when submission fails.
2. Finance opens a pending request, checks the evidence, permission scope and decision history.
3. Approve opens a confirmation with request ID, customer reference and exact amount/currency. A second explicit confirmation submits the decision; the server revalidates permission, limit and current request status.
4. Reject requires a reason and shows the customer-facing consequences before confirmation. Preserve the reason on retry.
5. If another approver changed the request, retain the local context and refresh the latest status before allowing another decision.

State contract

Mobile and accessibility

At 375px, replace the dense table with request cards that retain ID, amount/currency, status and primary detail action. Open request details as a full page with sections for evidence and history. A bottom action bar must reserve enough content space so it never covers errors or the last audit entry. At 768px, use a list plus details only if both remain readable; at 1280px, use the compact table and detail panel. Keyboard users can reach every filter and action; labels, field errors and focus states must remain visible. Status uses text and icon cues as well as color.

Visual strategy and acceptance checks

Use the existing neutral surfaces, blue action color, spacing and radius tokens. Reserve warning/error colors for actual risk; do not turn the page into a marketing layout. Verify text contrast, focus order, confirmation cancel/escape behavior, field-error association, stale-data blocking, duplicate-submit protection, permission revalidation and mobile content clearance. A developer and product owner must validate these checks against the real interface and refund policy before claiming completion.