Warranty and repair
on one ledger
Nintendo's warranty and repair process ran on manual claims with no shared visibility across retailers, consumers, and staff. I designed a multi-portal platform, solo, from first sketch to hi-fidelity, that gave every party a real-time view of their claim.
One claim, four blind spots
No shared visibility. Retailers and consumers had no way to track claim status, staff worked from separate records for the same claim, and every update meant a phone call or an email. Nobody trusted where a claim actually stood.
Manual, error-prone submission. Claim details were entered by hand at each step, with shipping and payment handled outside the system, so errors surfaced only after a claim was well underway.
Four audiences, one system. Retailers need speed, consumers need reassurance, and staff and admins need control and audit visibility. One data model had to serve all four without confusing any of them.
My role & process
Solo designer, from ideation to hi-fi, working directly with the CEO and engineering lead.
- 01
Discover
Stakeholder alignment and claim workflow mapping to follow one repair claim across a retailer, a consumer, internal staff, and a shipping carrier.
- 02
Define
Modeled roles and permissions, then an information architecture where four portals share one data model. Working solo, that had to be right before any screen was drawn.
- 03
Design
User flows and hi-fidelity prototypes for all four portals, with shipping and payment designed into the claim flow.
- 04
Review
Weekly check-ins with the CEO and engineering lead kept scope honest and decisions fast.
What research showed
Stakeholder alignment, claim workflow mapping, role and permission modeling, and information architecture all pointed the same way: one data model with four different views kept the build simple, consumers wanted tracking rather than a support form, and shipping had to sit inside the claim, not as a separate step. Weekly check-ins with the CEO and engineering lead kept scope honest.
Strategy into interface
Key decisions
- 01
One data model, four views
Retailers need speed, consumers need reassurance, staff and admins need control. Every portal reads the same claim but shows only what its audience needs, which kept the build simple.
- 02
Tracking instead of a support form
Consumers wanted to know where their repair was, not another form to fill in. Claim state is always visible, never something anyone has to ask for.
- 03
Shipping and payment inside the claim
FedEx logistics and payment were designed as part of the claim itself rather than a handoff to another system, so integrations feel native instead of bolted on.
Learnings
One data model with role-based views scales better than four separate builds. Working solo across four portals means the information architecture has to be right before any screen gets drawn, and third-party integrations feel native when they're designed as part of the flow, not appended to it.