lazypxls

UX & Product

Warehouse Operations Management Platform

UX LEADERSHIPDESIGN SYSTEMSSTAKEHOLDER MANAGEMENTREACT NATIVE

80%

Reduction in UI bugs

3 of 7

Apps delivered

Mentorship

Requested by junior designers

The designers, developers, and client weren't working from the same reality.

, Food & Flavour Manufacturer, Month 3

Client

Food & Flavour Manufacturer

Role

Design Lead (Embedded Team)

Timeline

Feb 2025, May 2025

Tools

Figma, FigJam, Mendix

THE SITUATION

A project three months in. Already in trouble.

Food & Flavour Manufacturer was replacing SAP with a suite of seven custom apps for their warehouse operators. When I joined as design lead, the client had lost confidence. Designs were off-brand and disconnected from real warehouse logic. Developers were building against multiple React component libraries simultaneously. And the process had a structural flaw that nobody had named yet: design was being excluded from the decisions that shaped the work before design even began.

THE REAL PROBLEM

"Design was excluded from initial scoping, and was the last to find out what that cost."

REFRAMING THE PROBLEM

Fix the process before fixing the screens.

The visible problem was design quality. The actual problem was that warehouse leads were seeing screens for the first time in PO review meetings, and their feedback was changing UX flows that had already been built. Every loop cost time nobody had. Fixing the screens without fixing the conditions that produced them would have changed nothing.

01

Get the right people in the room earlier

The functional team, warehouse leads, PO, BA, and design needed to align on prioritised features before any flows or screens were touched. That single change eliminated the source of most rework.

02

Design sits with the functional team

Instead of receiving technical flows as a brief, I sat with the functional team to understand them, surfacing UX constraints before screens began. Is the user moving from an RF scanning gun to a tablet? Do different warehouses need different views?

03

Warehouse leads sign off flows before screens

UX flows were confirmed with warehouse leads as a dedicated step, not as part of a full PO review. By the time screens were presented, there were no surprises. Feedback was refinement, not redirection.

PART ONE, THE WAY OF WORKING

Before and after, the process that changed everything.

BEFORE, HOW IT WORKEDAFTER, HOW IT SHOULD WORK01Functional team definestechnical process flows without design02Design takes technical flowsbuilds UX flows + screens off them03Presented to PO + warehouse leadswarehouse leads see screensfor the first time04Shock + confusionwarehouse input changes UX flowsscreens go back to redesignREWORK LOOPOUTCOMEBroken telephone. Wasted effort.Loops burned time nobody had.01PO, BA, functional team,design + warehouse leadprioritise features together02Functional team createstechnical process flows03Design lead sits with functional teamunderstands flows + surfaces constraintsRF gun → tablet? Different warehouse views?04UX creates flowsconfirmed with warehouse leadsbefore screens begin05Screens reviewed weeklyby whole team, no surprisesPO approval → dev handoverOUTCOMECoherent workflow. No loops.No wasted effort. No broken telephone.SCOPING CAN DETERMINE THE SUCCESS OR FAILURE OF YOUR PRODUCT., Iman El-Sayed, Food & Flavour Manufacturer
PROCESS REDESIGN

Where the loops came from, and how we stopped them.

In the old process, warehouse leads were seeing screens for the first time in PO review meetings. Their feedback, legitimate, informed, necessary, was arriving too late. Flows would change. Screens would go back. Time nobody had would disappear. The new process moved warehouse leads upstream: into feature prioritisation, into UX flow review, before a single screen was designed. By the time screens reached the weekly meeting, they already had operator buy-in. The PO was reviewing work that had already been stress-tested.

OPERATOR RESEARCH

The resistance wasn't irrational.

Warehouse operators were being asked to abandon SAP for something that felt imposed on them. I set up dedicated sessions with operators, separate from PO and business stakeholder sessions, to surface everything that hadn't made it into the formal requirements. What did they actually need? What were they worried about? What would break their day if we got it wrong? That research fed directly into the UX flows and into the sprint framework, where operator testing became a non-negotiable touchpoint in every cycle.

UX research timeframe, operator session planning and sprint touchpoints
Complexity spectrum framework, design work triage by effort level and governance requirements
UI UPDATE DOCUMENTATION1 / 11
Food & Flavour Manufacturer UI Updates title
Food & Flavour Manufacturer UI Updates title
Summary of all changes
PO Screen
Phase Screen
Bin List Screen
Component List Screen
Bin 1 Component List
Component A Bin List
Component Code Description
Component Detail
Weighing Screen

The full UI updates handover, 11 screens mapped as-is to to-be

DESIGN SYSTEM

One library. Both teams.

In parallel, I audited every previously designed screen against a new unified component system. The problem wasn't just process, developers were building against multiple component libraries simultaneously, making every handover a game of telephone that ended in bugs. We got design and development in the same room, agreed on a single source of truth, and mapped it to Food & Flavour Manufacturer's style guide. The UI updates document became the handover artefact: every screen shown as-is alongside to-be, with numbered annotations. 80% reduction in UI bugs followed.

PART TWO, THE APPS

Three apps. Designed from the warehouse floor up.

RF barcode scanner used by Food & Flavour Manufacturer warehouse operators

The RF gun, one device type, small screen, used one-handed throughout every Movement app flow

WAREHOUSE CONSTRAINTS

You cannot design for a warehouse from a desk.

Operators always had one hand occupied, holding an RF barcode scanner. Every interaction had to work single-handed, with thick gloves. Tap only. Large targets. No scrolling. Scanning wasn't a secondary feature. It was built into the core of every flow, appearing at multiple points in every task. Before designing anything, we had to learn the warehouse, the terminology, the physical sequence of each process, how stock actually moved through the space. Two device types added another layer: a small-screen RF gun for Movement, a tablet for Weigh & Dispense. Some processes required switching between them mid-task.

TAP-ONLYNO SCROLLONE-HANDEDSCAN-AWARETWO DEVICE TYPESWAREHOUSE-SPECIFIC TERMINOLOGY
APP 01, AGGREGATOR

One entry point. Every app.

The Aggregator was the home screen of the connected worker platform, the place operators landed when they opened the device, and the launchpad for every other app. The UX problem it solved was navigation: with multiple apps available depending on role and task, operators needed a clear, role-aware entry point that surfaced the right tools without cognitive overhead. Designed for tablet.

DEVICE: TABLETROLE-AWARE NAVIGATIONENTRY POINT FOR ALL APPS
Food & Flavour Manufacturer Aggregator app, home screen and entry point for the connected worker platform

The Aggregator, role-aware home screen combining all apps in one entry point

Weigh & Dispense app screens, tablet UI showing bin list, component selection, weighing and dispensing flows

UX flow diagram for the Weigh and Dispense app, shift start-up scale verification proposed flow

Proposed UX flow, shift start-up scale verification showing weight ID entry, validation states, and confirmation paths

APP 02, WEIGH & DISPENSE

Locate. Weigh. Dispense. Repeat.

Operators used this app to locate, weigh, and dispense the ingredients that go into food flavouring recipes. The flow differed by warehouse layout, two validated paths through the same task depending on how stock was organised. At the start of every shift, operators verified their scales using reference weights, with the screen showing progress toward the target in real time. A back-weighing mode let operators remove material from a batch and track what was taken against what was needed.

DEVICE: TABLETTWO WAREHOUSE PATH TYPESSCALE VERIFICATIONBACK WEIGHINGSCAN-AWARE
APP 03, MOVEMENT

Small screen. One hand. One action at a time.

The Movement app tracked components moving in and out of the warehouse, and between storage locations within it. The device made this the hardest design challenge: RF guns have small portrait screens, held in one hand while the other scans. One action per screen. One decision at a time. Nothing else. The flows covered standard location-to-location moves and split moves, where a batch needed to be divided before part of it moved. All of it on a screen roughly the size of a credit card.

DEVICE: RF GUNSMALL SCREENBIN-TO-BINSSCC SCANNINGSPLIT QUANTITY FLOWSONE ACTION PER SCREEN

Movement app screens, RF gun UI showing bin-to-bin movement, SSCC scanning and split quantity flows

UX flow diagram for the Movement app user story 2926, bin to bin and single B2B split movement flows

UX flow for US 2926, Movement app showing SSCC scanning, split quantity logic, and destination bin validation paths

PO Traceability Report app, purchase order tracking and status view

PO Traceability Report, full purchase order visibility in a single structured view

APP 04, PO TRACEABILITY REPORT

Every purchase order. Full visibility.

The PO Traceability Report gave warehouse managers and supervisors a structured view of purchase orders moving through the supply chain, tracking status, location, and progress at each stage. Before this, traceability required navigating multiple systems and manually correlating data. The report surfaced that information in a single structured view, making it possible to answer the question 'where is this order and what's happening to it' without leaving the platform. Designed for tablet.

DEVICE: TABLETPURCHASE ORDER TRACKINGCROSS-SYSTEM DATA UNIFIEDSUPERVISOR VIEW
What This Taught Me

Scoping can determine the success or failure of your product.

In three months, I got up to speed with how warehouses work, learned the terminology, fixed the ways of working, unified the component library, and helped deliver four of the seven planned apps. But it became clear the task was bigger than anyone had scoped. The risks I flagged and the conversations that followed made the client realise the original project scope wasn't realistic, something that traces directly back to design not being involved at the start. They made the call to move to Tulip, a low-code platform built specifically for warehouse management. More cost-effective than building everything from scratch. The right decision for them. Still one of the most valuable engagements I've had.

The Office gif

Me realising the scope was never going to fit in three months.

More Work