The user
Ops managers flying blind
The people running campaigns couldn't answer basic questions — how many hoodies are left in Europe, did that send actually arrive — without emailing a warehouse and waiting.
Case study Reachdesk · Inventory
Know where everything is.
Clients were shipping thousands of items through global warehouses with no way to see what they had or where it was. On a new squad, I helped build the inventory system from zero — turning a spreadsheet-and-email guessing game into a place you could simply look.
One item, tracked end to end — In transit
Send N-4471
In transit
Ordered
Mon 09:12
Picked & packed
Mon 14:03
Left warehouse · Europe
Tue 08:40
In transit
Now
Delivered
Est. Thu
01 Context
You can't manage what you can't see.
Reachdesk sends physical gifts and swag on behalf of its clients, held in warehouses around the world. But clients had no window into that stock — how much was left, what was moving, what had gone wrong. My squad's job was to build that window from nothing.
The gap
No system, just spreadsheets
Stock lived in disconnected spreadsheets and inboxes. There was no shared source of truth, so numbers drifted, sends stalled silently, and trust in the platform eroded.
The brief
Build the section from zero
A brand-new squad, a blank canvas, and one goal: a proper inventory area where clients could see, track and act on their stock themselves.
02 Research
I started with the questions people were emailing to ask.
Before designing a single screen, I mapped the real questions ops managers and warehouse staff were firing back and forth — because the inventory section only had to do one thing well: answer them instantly.
M1
Shadowing ops managers
Watching how clients actually chased stock and shipments — the workarounds, the panic before a big campaign, the questions that had no fast answer.
M2
Warehouse-side interviews
Understanding how the physical operation really worked — picking, packing, states, exceptions — so the data model matched reality, not a wish.
M3
Support-ticket teardown
Reading months of "where is my order" tickets to find the handful of statuses and views that would deflect most of them.
M4
Prototype walkthroughs
Testing the list, filters and item view against real campaign scenarios, watching where people still felt unsure and tightening until they didn't.
01
The list was the product
People didn't want dashboards or charts first — they wanted one scannable list where the answer to "what's happening" was visible without clicking into anything.
So what
The default view is a dense, calm table, tuned so status and location read at a glance.
02
State was the anxiety
Every worried email came down to one unknown: what state is this in? "In transit", "delivered", "cancelled" carried real emotional weight for someone mid-campaign.
So what
State became a first-class, colour-coded element — consistent everywhere, never buried.
03
Trust needed a trail
A status alone wasn't enough; people wanted to know the story behind it — when it shipped, where it was, what happened. Without that, they still emailed to double-check.
So what
Each item opens to a timeline of its journey, so the status is always backed by evidence.
03 The design
One list, one state, one trail.
The whole section rests on three decisions that turned an invisible operation into something a client could simply read.
Decision 01
Answer at a glance
A single, scannable inventory list is the front door. Item, warehouse and state sit on one line, so the most common questions are answered before anyone clicks — or filters — anything.
The list replaced the "where is my order" email
Decision 02
Make state legible
A small, consistent set of colour-coded states — processing, in transit, delivered, cancelled — used identically across the list, the item view and every notification. Learn it once, read it anywhere.
Status stopped being a guess
Decision 03
Back it with a trail
Open any item and its full journey is there — ordered, packed, shipped, delivered, with times and locations. The status is never asserted without the evidence behind it.
A status you could actually trust
Product The inventory list
Everything, on one calm screen.
The default view: every send with its items, warehouse and state, tuned so a busy ops manager can scan the whole page and know exactly what needs attention — and what doesn't.
Inventory
Live stock and shipments across your warehouses
List
Shipping notices
Low stock
RefRecipientItemsWarehouseSentState
N-4471
AK
Amina Khan
Field marketing
📦Welcome hoodie
🍿Notebook set
+1 more item
Europe
Tue, 08:40
In transit
N-4468
EL
Erik Lund
Sales, EMEA
☕Ceramic mug
🍿Notebook set
Europe
Mon, 16:20
Delivered
N-4463
MR
Maria Reid
Customer success
📦Welcome hoodie
+2 more items
Europe
Mon, 11:05
Cancelled
N-4459
DO
David Osei
Partnerships
🏆Award plaque
☕Ceramic mug
Europe
Sun, 09:30
Processing
N-4455
PS
Priya Sharma
Events
📦Event kit
+3 more items
Europe
Fri, 14:15
In transit
Showing 1–5 of 128 sends
Previous
123
Next
01
Scannable by default
Items stack inside the row so a whole send reads on one line, without the table exploding.
02
State you can trust
Four consistent, colour-coded states — the same everywhere they appear across the product.
03
Filters that fit the questions
Filter by the two things people actually asked about: what state it's in, and which warehouse holds it.
Product The item journey
Every status, backed by its story.
Open a send and the full journey is there — ordered, packed, shipped, on its way — with times and locations. The status on the list is never a claim you have to take on faith.
Send N-4471 · Amina Khan
In transit
Journey
Ordered
Send created and confirmed
Picked & packed
Rotterdam warehouse
Left warehouse
Handed to carrier · DHL
In transit
Out for delivery soon
Delivered
Awaiting confirmation
The trail is the trust
A status on its own invites a follow-up email. A status with a timestamped journey behind it ends the conversation — the client can see for themselves.
4 statesthe entire model rests on a small, learnable set — used identically everywhere
01
Evidence, not assertion
Times and locations at every step, so "in transit" means something specific and checkable.
02
Consistent language
The same four states and the same colours as the list — no new vocabulary to learn on this screen.
03
Honest about the unknown
The final step is clearly "awaiting confirmation" rather than faking certainty the system doesn't have.
Product Stock at a glance
The numbers that stop a campaign going wrong.
Above the list, a quiet health strip surfaces the things worth knowing before you hit send — what's running low, what's stuck, what's moving — so problems are caught early instead of discovered mid-campaign.
Items in stock
3,420
across 4 warehouses
Low stock
6 SKUs
reorder recommended
In transit
214
items moving now
Delivered this week
1,180
↑ 12% on last week
01
Warnings, not noise
Only the numbers that change a decision get surfaced — low stock and stuck items earn the amber.
02
Same colour language
Amber means "needs attention" here exactly as it does on the list — the system stays coherent.
03
Glanceable, then gone
It sits quietly above the list; it informs the scan without competing with it for attention.
04 Trade-offs
Three calls where less was more.
How many states?
Warehouse ops tracked a dozen granular statuses. Clients needed a handful they could actually reason about.
Ops detail⇄Client clarity
Decision
Map the many internal states down to four client-facing ones — clarity for the client, full detail kept underneath.
List first, or dashboard first?
A metrics dashboard demos well. But research said people wanted to scan a list, not read charts.
Impressive⇄Useful
Decision
Lead with the list; keep the health numbers as a quiet strip above it, not the main event.
Density vs. breathing room
Ops managers wanted a lot on screen; too much would make it unreadable and stressful.
See everything⇄Read anything
Decision
Stack items within a row and hold generous spacing, so the table is dense but never overwhelming.
Process Building from zero
A new squad, a blank canvas, a shared model.
There was no inventory section to iterate on — so the first job wasn't screens, it was agreement. I worked with engineering and warehouse ops to define the data model and the states before any UI, so we were all building the same thing.
01 · Define
The states, agreed first
I facilitated the squad to nail down the client-facing states and what each one truly meant, mapping them to the warehouse's real operational statuses. That shared vocabulary became the backbone of the whole section.
My partI framed the model in the language of the client's questions, not the warehouse's process.
02 · Prototype
Screens the team could pressure-test
I prototyped the list, item view and filters quickly so ops, engineering and client success could react to something real — surfacing edge cases like partial shipments and cancellations early, while they were still cheap to solve.
My partI turned the abstract model into screens people could argue with and improve.
03 · Ship & learn
Launched, then tightened
We shipped the core list and item journey, then watched real usage and support tickets to see which questions still slipped through — feeding the stock-health strip and low-stock view that followed.
My partI kept the section honest to its one job: answer the question without an email.
05 Outcome
An operation you could finally see.
Stock became self-serve
Clients could answer their own "what do I have and where is it" questions without emailing a warehouse
Fewer "where is my order" tickets
The list and item journey deflected the routine status chases that had filled support inboxes
A foundation, not a feature
The states and model became the base other inventory features — low stock, notices — were built on
What came next
- Low-stock alerts and reorder prompts, built on the stock-health foundation.
- Shipping notices, so inbound stock was as visible as outbound sends.
- Warehouse-level breakdowns for clients operating across multiple regions.
- Exportable views for finance and campaign reconciliation.
Rahman Malik — Product designer
Reachdesk · Inventory, built 0→1