02 — ABOUT
ROLE
User Experience Designer
TEAM
Me · Senior Designer (reviews) · PM · 6 devs
TIMELINE
4 months (Mar - Jun 2023)
SCOPE
Whole request management system
STATUS
Shipped (1st Phase)
PROBLEM
Every change to a shopper's data, from mobile or email change to account deletion, went through the same unchecked step. No reason, no record of who acted, no difference between routine and irreversible.
WHAT I DID
Rebuilt the whole request system: one list for every type, one form pattern, and checks that scale with risk. Routine requests can auto-approve; high-risk ones need a reason and the head's approval.
OUTCOME
Phase one shipped in July 2023, a month after my internship ended. No post-launch data.
Before: the highest-risk case of mobile change request types
1
No reason
2
No warning
3
No sign of whose data
After
1
Mandatory reason
2
Privacy warning before submit
3
Shopper's profile in the form
01 - THE PROBLEM
The old tool handled every request type the same way, from a phone-number change to an account deletion
Every type in one list. No sign of who acted.
A data change in one click. No second check.
Irreversible, with no field for the reason.
04 - HOW I KNEW
Executives couldn't find requests, or act on them with confidence
Group session · ~20 executives
My walkthrough of the old tool
Freshdesk · Salesforce · mParticle
PM requirements
INFORMATION GAPS
Fragmented request tracking
Scattered customer notes
Limited access to information
PROCESS GAPS
Unclear decision authority
Escalation black box
A hard system to learn
THE GAP I TOOK FROM COMPETITIORS
Freshdesk-level speed with mParticle-level compliance.
03 - WHO AND WHAT
Two people use it. A third person's data is at stake.
Customer Service Executive
Raises every request
Customer Service Head
Approves the high-risk ones
The Shopper
Never in the room
In this Phase, i worked on
Every phase-one request type, rebuilt
One list, by request type and status
One form pattern across all types
Reason and comments on requests
Approve and reject for high-risk
Auto-approval for routine
Who raised and who changed, in the list
04 - REQUIREMENTS
Six pain points, three things every request type had to do
Any request, found in one place
from: fragmented tracking · limited information
Checks that match the risk
from: unclear decision authority · one form for everything
Every action leaves a trace
from: escalation black box · scattered notes
The sixth, a hard system to learn, was the reason for the whole revamp. So the answer couldn't be a better deletion form. It had to be one pattern every request type follows.
05 - THE SYSTEM
Every request type, sorted by what it can break
I designed all nine phase-one request types, not one. The question for each one was the same: if this goes wrong, can it be undone?
06 - From Problem to Principle
Checks scale with the risk
A · Everything waits for the head
B · Everything goes through
C · Checks depend on the request ✓
High-risk (mobile change, merge, deletion): reason required, waits for the head
General (email ID change, goodwill points…): can go straight through
▲ GAINED
The head's attention goes to what can't be undone.
▼ COST
Auto-approved requests get no second look.
Ordered like an SLA tool, without the timers
A · Full SLA timers
B · Sorted by date only
C · By type and status ✓
Answers the head's first question — what's waiting on me — without a clock on every row.
▲ GAINED
Phase one rebuilt what existed and shipped the privacy changes first.
▼ COST
Day one and day five look the same. Nothing flags overdue.
07 — THE DESIGN
One request, from raised to decided
One form pattern. Only the checks change.
One request, from raised to decided
Raise
Review
Decide
Resolve
Routine + auto-approval skips Review
Every type, one list
Who raised, who charged
Why, one hover away
The strictest path in the system
The reason goes back to the executive
In-product Guidance
Setup help at the verification field where the decision is made, replacing documentation that sat outside the product and went unused.
07 — Trade-Offs
What phase one gave up
Rebuild before adding
▼ No overdue signal
A denser list
▼ High-risk requests take more work than before
A denser list
▼ Heavier to scan; reason behind a hover
08 — The Outcome
Shipped after I left, so here's what I'd measure
STATUS
Phase one shipped, July 2023
A month after my internship ended. Walked PM and devs through end to end before handoff.
I'D MEASURE
Time to raise a high-risk request
Share auto-approved vs waiting
How long requests wait for the head
Time for a new executive to work unaided
WOULD PROVE ME WRONG
Wrong deletions, merges or mobile changes still getting through, or general requests slowing down.
09 — Reflection
What I'd do differently
Agree the metrics before handoff
So the outcome doesn't leave with me.
Design the unhappy paths first
A high-risk request when the head is unavailable.
Compliance belongs in the flow
Following the rule became the easiest way to finish.