See the risk.
Know the next step.
I redesigned Seller Central’s Account Health experience so sellers could understand risk and take the next step. The design shipped, following eight weeks of audit, design and specification.
Prioritize the policy issues affecting your rating.
Reconstructed example · illustrative rating · original audit metrics
- My role
- UX consultantAudit, design-system alignment and interaction specification
- Core team
- Solo consultantEmbedded with the Amazon team
- Scope
- 8 weeks / Audit to specificationDashboard architecture and resolution flows
- Figma
A lot of information.
Too little direction.
The audit exposed a gap between the stakes and the interface. A deactivation warning shared visual weight with promotions, while thousands of policy issues offered no clear place to start.
Account figures reported in the original case study. The capture below directly documents policy, service and shipping metrics.
The complete interface I audited. Choose a finding above to locate the evidence; the original stays fully visible.
Four findings shaped the redesign.
Heuristic evaluation, task analysis, cognitive-load review and seller-forum review. No primary seller interviews were conducted.
The warning comes first.
The next step comes with it.
I separated health monitoring from promotions and placed unresolved risk first. Switch layouts to compare the hierarchy.
Compare the dashboard hierarchy.
Promotions move out of health monitoring; service metrics, trends and tools stay available below the urgent work.
One summary.
Clear boundaries.
The original exploration brought the account picture into one summary. This rebuilt example checks that idea against Amazon’s published AHR rules, keeping policy, service and shipping signals distinct.
Explain the signal. Keep the detail.
16 points below the Healthy threshold. Prioritize policy issues.
Explore how the published rating changes at 100 and 200.
AHR reflects policy compliance and selling activity over 180 days. Service and shipping retain separate targets.
Service can meet its target while policy risk needs attention.
Also in the capture: 0% cancellations / 7 days; 99.98% valid tracking / 30 days.
About this reconstructed rating example
The archived design exploration included a weighted score: 40% service, 35% policy and 25% shipping, with four custom bands. This rebuilt example uses Amazon’s published three-band AHR and keeps performance metrics separate. It illustrates the design rationale; it is not an exact capture of the shipped interface.
Familiar service, policy and shipping categories remain available for detail. Each metric keeps its own measurement window, so the summary stays truthful.
2,445 issues.
A deliberate starting point.
I grouped issues by type, brought consequential issues forward and made same-type batch appeals available. Counts establish workload; the individual issue determines severity.
A small group can carry
a serious consequence.
The audit identified suspected IP violations as a priority to investigate. The redesign brings that work forward instead of letting the largest group lead.
Count shows workload. The individual policy issue determines severity.
Consequence before count.
Prioritize potential suspension risk before volume.
Review policy → collect evidence → submit an appeal.Keep the next step
within reach.
Each action opens the relevant work with its context intact. Compare three routes, then follow one policy issue through an appeal.
Fewer detours. More context.
Keep the policy citation beside the affected listing.
The issue, evidence requirements and response stay together.
Prepare the evidence, review the response and track the decision in the example below.
Prepare, submit, track.
- Prepare
- Review
- Decision
Understand the issue.
Review the affected listing, policy citation and consequence before choosing a response.
- Affected listingListing A / illustrative listing
- Cited policyRead the exact policy cited for this issue
- Reason for the violationUnderstand the concern before responding
A clearer path,
shipped in Seller Central.
My eight-week contribution connected the audit to four design solutions, aligned with Katal and documented for implementation.
How I would measure the impact.
Original improvement targets, not measured post-launch results. Select a target to see the design behind it and the test measure.
Time to identify issues
Test plan- 01 / Design changePersistent risk warning
- 02 / Seller actionReview policy issues
- 03 / MeasureTime to first actionDashboard load → first critical-alert action
What I would test next.
Research with sellers who have experienced suspension, alongside support specialists and ticket patterns, would sharpen the next iteration.
Can sellers complete the work?
Test policy understanding and appeal completion, including exceptions to the rating. Track reactivation and dashboard return as downstream signals.