Business / Retail
Replacing spreadsheet chaos with a dashboard that tells warehouse staff exactly what to do next, not just what's true right now.
A regional retail distributor running three warehouses tracked stock through a single shared spreadsheet, updated manually whenever someone noticed a shipment arrive or leave.
The problem: Stock counts were often wrong by the time anyone acted on them. A recurring story: a worker fulfilling an order for stock already promised to another branch, discovered only when a customer arrived to collect it.
Business goals: One real-time view of stock across all three warehouses; fewer stockouts and over-promises; a fast, floor-friendly tool for staff who weren't desk workers and wouldn't tolerate a complicated system.
I interviewed five warehouse staff, two branch managers, and the operations director, and spent half a day on the warehouse floor watching how staff currently checked and updated stock.
Needs to check and update stock in seconds, standing, often one-handed.
Needs a daily view of what's low, overstocked, or in transit.
Needs a company-wide view for planning, without micromanaging daily floor work.
I reviewed Zoho Inventory (feature-rich but cluttered for floor use), a barebones open-source tool the client had already tried and abandoned (too rigid, no mobile-friendly view), and a custom POS add-on (strong on sales, weak on multi-warehouse transfer tracking). The gap: nothing built specifically for the floor-to-office handoff this business actually needed.
User flow: Three primary flows: a floor-staff stock update (large-target, tablet-first), a manager's daily review dashboard, and a cross-warehouse transfer request.
Information architecture: Split into a floor-facing "Update Stock" mode — tablet, minimal navigation, large controls — and an office-facing dashboard with denser data views, both built on the same underlying data model.
Wireframes: Prioritized the floor-facing flow first, since it carried the most usability risk, and tested paper wireframes with two warehouse staff before any visual design began.
A high-contrast, large-touch-target interface for the tablet mode, and a denser, table-driven interface for the manager dashboard — the same visual language at two different information densities for two different contexts.
Design system: A shared token set for color, spacing, and type across both modes, with a "floor" component variant (larger padding, bigger text, fewer choices per screen) and a "desk" variant of the same underlying components.
Typography: Space Grotesk for section headers and key numbers like stock counts and alerts; Inter for tables and dense data.
Key components: Stock card, large quantity stepper, transfer-request modal, low-stock alert banner, cross-warehouse comparison table.
Prototype: Tested the interactive prototype on an actual tablet, on the warehouse floor, with three staff members across two rounds — this surfaced glare and glove-usability issues no desktop test would have caught.
Accessibility: Tap targets sized to at least 48px for gloved and floor use, a high-contrast mode suited to warehouse lighting, and status always paired with an icon and label, never color alone.
Challenges: Reconciling two very different use contexts — a warehouse floor and an office desk — in one coherent product, without maintaining two separate apps. Transfer requests between warehouses also needed an approval step that couldn't slow down the floor worker who initiated it.
Solutions: One data model with two interface modes, sharing a single component system, resolved the floor/desk tension. For transfers, I moved the approval step entirely off the floor worker's screen — they submit and move on, while the manager approves asynchronously, with status visible back on the floor view without blocking the next task.
Reduced over-promising to customers, gave the operations director a real basis for restocking decisions instead of gut-feel estimates, and created an audit trail that resolved several long-running disputes between branches over missing stock.
Delivered a component-based Figma file with a documented token system, explicit states for online and offline use given inconsistent warehouse wifi, and a written spec for the transfer-approval logic, since it involved a state machine the dev team needed to get exactly right.
Lessons learned: The best usability insight of the whole project came from watching someone use a shared terminal wearing gloves — a detail no stakeholder interview surfaced, but was obvious within five minutes on the floor. In-context observation beat any amount of desk research here.
Next improvements: Barcode-scan stock updates instead of manual entry, low-stock predictive alerts based on historical velocity, and a lightweight mobile view for the operations director.
This project sharpened how I think about one product serving two contexts. Rather than designing a single responsive layout and hoping it worked everywhere, I treated the floor and the office as two different jobs the same data needed to do, and let the interface adapt to the job, not just the screen size.