Performance Tracking · Promotions & claims

From a qualifying sale to a claim someone can trust.

Performance Tracking connects sales activity to reward claims. This walkthrough examines the moments that shape trust: understanding eligibility, providing evidence and knowing whether a submission has been received or approved.

I owned the frontend implementation for the 2024 launch and later conducted the UX audit. The archived demonstration-program screens let me connect delivery to a critical review of the experience—without presenting audit recommendations as shipped changes.

Illustrative scene · AI-generated

My role: Frontend implementation + later UX audit
Launch: 2024
Evidence: Historical UI + October 2025 audit

Compare before & after

Original screens alongside new dark-mode prototypes. The redesigns are explorations, not shipped outcomes.

1The product problem

A reward promise depends on the quality of the claim.

The participant needs to know whether a sale qualifies and what proof to provide. The program team needs enough consistent information to validate it. A form sits between those needs, but the experience starts before the first field and continues after Submit.

My ownership covered frontend implementation and the later UX audit. This case follows that work as a distinct claims experience—not the rewards catalog, Quick Points code redemption or the six-month site migration.

2Before the form

Resolve the rule before asking someone to act.

My later audit examined the balance between instructions, reward messaging and the Enter A Claim action. Looking back at the capture also exposes a concrete inconsistency: the instruction line ends in 2025 while the reward block ends in 2024. The screenshot cannot tell us which rule is correct.

My priority would be to resolve that conflict with the program owner, then make the verified window and required evidence easy to find. A stronger call to action cannot compensate for uncertainty about whether the sale qualifies.

Before

Original UI

Promotion overview · desktop · historical UI cropLater demonstration-program audit. Branding excluded; conflicting dates preserved. No correction or current policy is implied. Local review only.

After

Dark mode prototype

Promotion overview · landscape tablet · proposed dark modeNew design exploration, not the shipped 2024 UI. The eligibility notice is a design-review placeholder; the conflicting historical dates remain unresolved.

Bring the eligibility rule, the required evidence and the next action into one view.

Separate promotion details from an invoice and product checklist.
Keep the unresolved date conflict visible until the program owner confirms the rule.
Distinguish sending a claim from receiving approval.

3Entering sales evidence

Keep the invoice, the product and the proof connected.

My frontend implementation work covered the claims module. The archived desktop form asks for an invoice number, sale date, product, quantity, sale amount and document upload. Product and quantity share a visual group; the remaining fields establish the transaction and its evidence.

There is also a dark control with no visible text in the capture. I would verify its purpose and accessible name in the live interface before prescribing a fix. The screenshot alone does not establish how it behaves—or whether validation and feedback exist.

Before

Original UI

Claim submission · desktop · original interface pixelsBrand header and footer cropped out. Empty fields and the dark control are unchanged; no accessible-name or runtime-behavior claim is made. Local review only.

After

Dark mode prototype

Claim entry · tablet · proposed dark modeNew design exploration, not the shipped 2024 UI. The original six fields are retained; the unexplained control is omitted pending verification.

Keep the same task, with a clearer path from sale details to supporting proof.

Invoice and sale date share a row; product and quantity stay together.
Persistent labels, consistent input sizing and a larger file-selection area.
Warm charcoal, cream and blue use the selected dark palette and portfolio type hierarchy.

4The same task on a phone

Stacking the fields is the start—not the whole answer.

The mobile capture stacks product code and quantity while retaining the invoice-to-upload sequence. It also retains the unexplained dark control. A responsive layout can preserve order without resolving uncertainty about the task.

I would test the complete entry flow with a phone keyboard and a real document-selection task. Persistent labels, reachable actions and recovery after an interrupted upload matter more than reducing the screenshot’s height.

Before

Original UI

Claim submission · mobile · exact historical cropActual mobile capture, not a reconstructed phone mockup. Header, footer and surrounding whitespace excluded. Local review only.

After

Dark mode prototype

Claim entry · phone · proposed dark modeNew design exploration, not the shipped 2024 UI. The full entry form is shown; keyboard, file-selection and submission behavior still need live testing.

Carry the same form hierarchy onto a phone, from invoice details through submission.

Stack fields in reading order and keep labels above their inputs.
Preserve the product-and-quantity group from the tablet layout.
Give file selection and Submit larger, clearly separated targets.

5Beyond a successful submission

Received, reviewed and rewarded are different states.

The archived instructions say claims are checked against the invoice and may take up to ten days to validate. That is historical program copy, not a current promise or a measured result. It does show why submission and reward approval should not be treated as the same event.

The captures do not include errors or post-submit states. The following scenarios are a validation plan, not evidence that the original product lacked these paths.

Recovery checks I would take into refinement

New analysis informed by the archived requirements. Proposed checks, not a shipped state model or exhaustive specification.

Unclear eligibility: Resolve the policy with the program owner before encoding a date rule or asking the participant to resubmit.
Missing or conflicting details: Identify the field needing correction, explain why, and verify that other entered values are retained.
Upload rejected or interrupted: Explain the file problem, offer a retry and check whether the rest of the claim can be preserved.
Submit interrupted or repeated: Verify whether a claim was received before encouraging another attempt; investigate duplicate handling with engineering.
Awaiting review: Distinguish receipt from approval and verify where the participant can see status or seek help.
Correction, rejection or approval: Confirm each supported decision, its explanation and the next action. Approval and points posting may be separate events.

Proposed recovery

Dark mode prototype

No historical recovery screen is available for comparison.

Missing invoice · phone · proposed recovery explorationProposed validation state, not captured in the original UI. Retained details and the separate review step illustrate behavior to validate, not an implemented guarantee.

Show the correction needed and give the participant a route back to their details.

Use an explicit error message and icon alongside the coral error border.
Place invoice selection beside the explanation of what is missing.
Explore preserving entered details while an invoice issue is corrected.

6What the evidence establishes

Delivered in 2024, then examined with a critical lens.

The archive makes the promotion-to-claim sequence inspectable across desktop and mobile. It also exposes a specific eligibility inconsistency and a control that needs live verification. Those are concrete discussion points for product, design and engineering.

I delivered the frontend implementation for the 2024 launch and later carried out the UX audit. The available evidence does not establish a measured completion-rate improvement or that the later recommendations shipped. I do not attribute those outcomes to this work.

7Reflection & next steps

Make the rules dependable before making the experience celebratory.

My later audit recommended more energy, stronger hierarchy and richer feedback. Looking back, my first priority would be the underlying contract with the participant: consistent eligibility, understandable requirements and a clear distinction between sending a claim and receiving a reward.

Progressive disclosure could shorten the page, but hiding essential rules would introduce a different problem. I would keep the verified prerequisites visible and test whether contextual guidance helps people complete the task without repeatedly going back.