Designing a warehouse system for buildings that are all different

Build an MVP that lets a mid-sized warehouse run end to end, for a client whose sites vary in layout, process, and staffing.

The brief was to cover the basics well: a web app for warehouse managers to monitor operations, a Pick Pack app for floor workers using RFID so data updates without manual entry, and a workflow builder able to cover different warehouse processes.

The hard part was not the feature list. Warehouses vary widely in layout and process, with no single standard to design for, so anything designed around one site would break at the next.

The project also started without the usual scaffolding, which shaped how the work had to be run.

I owned the full design process: translating business requirements into user flows, running the research, and syncing weekly with the Design Manager and dev team on technical constraints.

With no other designer on the project, decisions that would normally be debated in a design team had to be made and defended alone, then validated against engineering feasibility each week.

None of us had designed for warehouse operations before, so the first move was to go and watch one work.

We visited one of India’s largest warehouses to see firsthand how packages move from intake to delivery. Seeing the floor is what surfaced the constraints that mattered most: workers moving constantly between locations, gloved hands, scanners rather than keyboards, and steps that could not pause for a screen to load.

Alongside that, we benchmarked the WMS platforms already in use by Jio’s other vendors, to understand what the client’s teams were already fluent in.

• Vineretail
• Unicommerce
• SAP
• Increff
• Stock One

Each constraint had a design response. Naming those responses early is what kept a 0 to 1 build from becoming a pile of one-off screens.

PLACEHOLDER: this section carries the most weight with hiring managers. Replace the draft below with the decision you would actually defend in an interview.

The obvious path was to design the flow we had watched on our site visit and ship that. It would have been faster and it would have worked, for exactly one warehouse.

Instead I treated process variation as the core requirement rather than an edge case. The workflow builder meant a new site could be configured rather than redesigned, which is what let a single MVP serve warehouses that organise their floors differently.

PLACEHOLDER: add the trade-off. What did configurability cost, in build time, in interface complexity, or in what you had to leave out of the MVP?

Low fidelity wireframes drove the structural decisions: cards to segment dense content, and clear headlines and breadcrumbs so people could tell where they were in a deep hierarchy.

The final UI ran on a minimal set of page templates rather than one-off layouts, with content surfaced through white cards on a light background.

Inbound listing and detail. Consignments show status at a glance and stay tracked at item level until stock enters inventory. The form’s left nav stays fixed on scroll, so workers can jump to any section instantly.

Task screens for floor workers. Workers scan an item code at each step, which tracks its status through the system without manual entry.

Task completion. Once all items are scanned, a barcode generates automatically through the OMS API and the worker marks the order packed. Each scan gives immediate feedback and auto-advances to the next item, so the interaction works by scanner or by touch without changing the flow.

The system was tested and shipped, and the numbers that mattered were operational rather than cosmetic.

PLACEHOLDER: add one or two sentences on what these numbers meant in practice. For example, what item level traceability changed for a supervisor chasing a missing consignment, or what 10% manpower efficiency was worth to the client.

Live product: fynd.com/en-in/wms

PLACEHOLDER: this section is currently missing from the case study and hiring managers look for it specifically. Two or three paragraphs is enough.

Prompts, in case they help. What would you do differently now? One site visit informed the whole design, so would you have validated with floor workers sooner or more often? Did designing for configurability turn out to be the right call, or did it add complexity that a simpler system would have avoided? What did being sole DRI teach you about making decisions without a design team to argue with?