The app never tells the manager
Waitwhile does not notify managers when an order is ready for its quality check, so the alteration team radios them instead. The order sits finished, waiting on a phone call that the software was bought to replace.
UX Research & Design
The pants were finished. Nobody told the manager.
UNIQLO UTC runs its alteration service on Waitwhile, a queue-management app. Every finished order is supposed to notify a manager for a quality check. It doesn’t — so the team picks up a radio instead, and the software everyone is logged into becomes a place where work is recorded rather than run.
I worked on that alteration team. Over seven milestones we shadowed the workflow, interviewed the store manager, and redesigned the two flows that break most — then tested it with the people who would have to use it, mid-shift.
Studied
UNIQLO UTC, San Diego
Worked with
Store manager, 2 alteration specialists
Built in
Figma
Delivered
Hi-fi prototype, 2 flows
How it works today
One order, start to finish, and the three places it breaks
Mapped from working the service and from a walkthrough with the store manager. Each column is a role and the order moves down the page — pick any step, or walk an order through. The same map runs through every UNIQLO project on this site; this is the WaitWhile view of it.
Lens
WaitWhile Alteration Workflow covers 8 of 12 steps.
Customer
Floor staff
Specialist
Manager
Send one lockstitch order through the service and watch where the minutes go.
What we found
The system works. The seams between people don't.
Observation on the floor, shadowing the alteration team, and a semi-structured interview with the store manager.
The SMS opt-in is a checkbox under pressure
Staff regularly forget to tick it during a rush. The customer then hears nothing at all and comes back on the estimate they were given at the counter.
Every detail is typed by hand
Name, phone, stitch type and inseam are all keyed in at checkout. A typo in a phone number is a notification that silently never arrives.
Yesterday is hard to find
The default view shows only today’s orders. Retrieval runs on the five-digit order number, so a customer who has lost their receipt turns a lookup into a search.
“The process works, but there are too many steps, and if one thing goes wrong, it affects the whole flow. Customers notice when we’re scrambling to find their order.”
“We’ve learned to just call on the radio because waiting for the app to notify managers doesn’t work most of the time.”
Unexpected
They trust the radio more than the app
The team had a tracking system and still confirmed order status out loud. That is not a preference for radios — it is an accurate read of which tool has been reliable.
Inconclusive
We could not tell whether customers rely on SMS
Staff said most customers never get the updates, but we could not establish whether customers actually depend on them or simply return at the estimated time. So we left it as an open question instead of pretending we knew.
Who it's for
Three people, one broken handoff
Each persona is the same failure seen from a different position in the store — which is why fixing the notification fixes three problems at once.
Alteration specialist
Jason Warren
26 · 4 years on the alteration team · UNIQLO UTC
“We’ve learned to just call on the radio because waiting for the app to notify managers doesn’t work most of the time.”
Needs
- A notification that reaches managers on its own
- Order tracking that does not need troubleshooting
- Fewer steps between claiming an order and finishing it
Frustrations
- Radioing managers for every quality check
- Manual entry that misplaces receipts and details
- Default settings that hide older completed orders
Built from the alteration team’s reliance on radio over Waitwhile — a lack of trust in the system, not a lack of training.
Store manager
John Anderson
33 · 8 years in retail management · UNIQLO UTC
“The process works, but there are too many steps, and if one thing goes wrong, it affects the whole flow.”
Needs
- Communication between the floor and the alteration team that does not run on radios
- To be told when an order is waiting on him
- Staff who can retrieve any order quickly
Frustrations
- Not being notified when orders are ready for quality check
- Breakdowns between teams that turn into delays
- Finding completed orders from previous days
The managerial view of the same break: the notification that never fires is what turns his day into interruptions.
Customer
Emily Williamson
27 · Young professional · Shops UTC for work and casual wear
“I don’t mind waiting for alterations, but it’s frustrating when I come back and my order isn’t ready — or they can’t find it right away.”
Needs
- Updates that actually arrive
- A pickup that does not turn into a wait
- Confidence the length is right the first time
Frustrations
- Missed SMS updates, so pickup time is guesswork
- Delays while staff locate a finished order
- Occasional inseam discrepancies — usually fixed quickly
The customer end of the staff-side failures: data-entry errors and retrieval problems reach her as silence and waiting.
What else is out there
| Tool | Direct? | Angle | Strength | Weakness |
|---|---|---|---|---|
| Qminder | Yes | Workflow stats and optimisation | Real-time tracking that surfaces where a service is bottlenecked. | More analysis than this store needs, pricier than Waitwhile, less customisable UI. |
| Qless | Yes | Real-time SMS and queue times | Customisable queueing that fits an appointment-shaped service like alterations. | Clunky, unfriendly UI with a high learning curve; cost scales with usage. |
| Doodle | No | Calendar-based scheduling | Scheduling is legible to customers and staff at the same time. | No SMS, very limited free plan, and a calendar is the wrong shape for a queue. |
| Suitedash | Yes | All-in-one business platform | Deep automation and custom client experiences. | Overkill and not specialised: no immediate queueing, no SMS, much steeper to learn. |
Nothing off the shelf was worth switching to. The gap was never the queue — it was the handoff inside it, which is a design problem, not a procurement one.
Design
Two flows, drawn badly on purpose first
Sketches before screens, two competing low-fidelity directions before one high-fidelity answer. Click anything to open it.
The flows
Step 1 of 5: On the visits page
The SMS step is gone from the flow entirely — the text sends because the order was created, not because someone remembered a checkbox.
Sketches
Two low-fidelity directions
Testing
The two specialists wanted opposite things
Both prototypes went in front of real staff on shift. One specialist loved the visual rack; the other could not use it on the phone in his pocket. That disagreement is what the final design is built out of.
Alteration specialist #1
Tested on shift, both prototypes
Preferred A- Due time should sort the list, not order of placement — an order taken later can actually be more urgent, like a customer in town for one day.
- Order ID matters more than the customer’s name, because the ID is what is printed on the receipt.
- Wanted the inseam entered from a dropdown rather than typed.
- Floated gamifying it: show a specialist their average time per pair, and whether they came in over or under.
Alteration specialist #2
Tested on an iPhone 8
Preferred B- Prototype A was too cluttered at that screen size — the thing the first specialist liked was the thing this one could not use.
- Preferred B’s list: all the necessary information at once, and workable one-handed.
- The checkmark on the right assigns in a single action; A forces the long route through the order.
Store manager
Tested the approval path
Wanted both- The bell should fire the moment pants are ready for a quality check.
- Admitted he probably would not go and look — so the notification needs to be a nudge that reaches his phone, not a badge inside the app.
Outcome
What changed, and what the feedback changed back
Kept B’s list, took A’s priorities
The list matched the mental model of the app staff already use. What A got right was what the list should be sorted and led by: due time and order ID.
SMS on by default, with an opt-out
The single most common failure was an unticked box. Defaulting it on moves the error from "customer hears nothing" to "staff chose to opt out".
Swipe became a button
Testers said a swipe means something else — switching screens, not advancing a job. The gesture was clever; the button is what people expected.
Undo on every stage change, redo for the manager
Stage changes were one tap from irreversible. An undo bar and a send-back put the mistake inside the flow instead of outside it.
Colour-coded the service type, not the whole row
Colour-coding entire orders was visually overwhelming and did not match how anyone thinks about the queue. The colour now carries one fact.
Icon replaced with the word "Assign"
We assumed the icon read as assign. The TA, our stakeholders and everyone we showed it to said otherwise.
The high-fidelity prototype
Before and after
- Walk the workflow again with both roles before building further — the two specialists wanted different things, and only one of them was in the room each time.
- Cut each row to the two facts that testing proved staff use: order ID and due time.
- Take the manager nudge out of the app and onto the phone, since that is where he said he would actually see it.
One more thing worth saying: this started as a different project. Milestone 1 studied a software engineer’s load-testing tool and a developer’s database console. The research was fine and the problem was real, but neither of us could get near those users again — and I could walk into the UNIQLO back room any shift I worked. We pivoted at Milestone 2. Access is a design constraint, and pretending otherwise produces case studies about people you never met twice.
Interactive prototype
A version you can actually click
I coded this one on my own so the queue could be used, not just looked at: claim an order, swipe it into progress, confirm it done, and undo any of it. Try it below, or open it full-screen.
Front end only, with no backend — refreshing resets it to the sample orders.
What this shows
- One order mapped across every role, to find where the handoffs break
- Two flows redesigned and tested mid-shift with the people who run them
- A working version of the queue, coded so it could be used, not just looked at
More work inUX researchDesignOperationsWeb
Next Project
← All work
Like work like this? Tell me what you're building.
Say hi →