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.
Nintendo's warranty and repair claims moved through a fragmented manual process, with no single view across the retail network or the consumers filing claims. Retailers, consumers, and internal staff each worked from their own picture of where a claim stood.
I designed the system end to end: a Retailer Portal for claim submission and management, a Consumer Portal for repair requests and real-time tracking, and Staff and Admin Portals for internal processing, with FedEx integration for repair logistics and secure payment handling built in.
I owned this alone, from ideation through hi-fidelity design, working directly with the CEO and the engineering lead to keep the build aligned with what the interface needed.
One claim,
four blind spots
A repair claim touched a retailer, a consumer, internal staff, and a shipping carrier, and none of them could see what the others saw.
No shared visibility
- Retailers and consumers had no way to track claim status
- Staff worked from separate records for the same claim
- Every update meant a phone call or an email
Manual, error-prone submission
- Claim details entered by hand at each step
- Shipping and payment handled outside the system
- No consistent record of what changed and when
Four audiences, one system
- Retailers need speed, consumers need reassurance
- Staff and admins need control and audit visibility
- One data model had to serve all four without confusing any of them
Goals
- Give every party a live view of their claim, not a status they had to ask for
- Cut submission errors by simplifying claim entry
- Bring shipping and payment inside the claim flow instead of around it
- Design role-based access so each portal shows only what its audience needs
Research
- One data model, four different views of it, kept the build simple
- Consumers wanted tracking, not a support form
- 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
Retailer & Consumer Portals
Retailers submit and manage claims in one flow; consumers file a repair request and follow it in real time. Same underlying claim, two purpose-built views.
Staff & Admin
Portals
Internal processing with customisable roles and permissions, so staff see claims that need action and admins see the whole network without either drowning in the other's view.
Shipping &
payment, built in
FedEx integration for repair logistics and secure payment processing, designed as part of the claim itself rather than a handoff to another system.
- 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
- Direct access to the CEO and engineering lead kept decisions fast without losing rigor
- Third-party integrations feel native when they're designed as part of the flow, not appended to it
Conclusion
A warranty process that ran on manual claims and guesswork became one platform where retailers, consumers, staff, and admins all see the same claim, updated in real time. Designing four audiences off one shared data model is what kept the system simple to build and simple to trust.
