Walk any distribution centre running SAP EWM and count how many people touch the desktop transactions. A handful. The warehouse monitor is open on the team leader's screen, an analyst runs the odd query, a superuser fixes a stuck task. Now count how many people hold an RF gun for eight hours. Most of them. The RF flow is the only part of EWM the majority of your workforce will ever touch, and it is almost always designed by people who will never use it.
That inversion is the whole problem. The config sits in the middle of the project, gets the design workshops, the review boards, the named architects. The RF screens get built near the end, from whatever the standard transactions happen to render, and shipped because there is no time left. The people who live on those screens meet them for the first time in training week. By then the shape is fixed.
Design it first, not last
The right order is the reverse of the usual one. Before you decide how storage control is going to work, decide what the operator sees when they scan the handling unit. Sketch the goods receipt flow as a sequence of screens on paper, tap by tap, and walk it with someone who has actually put away pallets. You will learn more about your storage-type strategy from that conversation than from a week of blueprint slides, because the physical flow and the data model have to agree, and the operator is the one standing where they meet.
This is not a plea for prettier screens. It is a claim about where the design risk lives. Get the config elegant and the RF flow clumsy and the floor works around you. Get the RF flow right and a slightly awkward config is invisible, because nobody downstream ever sees it. Spend the design energy where the humans are.
The tap economy
Every screen in an RF flow costs something, and the currency is taps. On a high-frequency transaction the cost compounds fast. Take a picker doing eight hundred lines a shift. Add one confirmation screen that exists only because the standard flow wanted a belt-and-braces acknowledgement, and you have added eight hundred taps. Across a team of twenty, that is sixteen thousand taps a shift for zero information gained. That is not a nuisance. It is a direct labour cost, and it is measurable.
So count taps like you count dollars. For every screen in a high-volume flow, ask what decision it supports. If the operator cannot act differently based on what that screen shows, it is not a screen, it is a toll booth. Auto-confirm the quantity when the scan already proves it. Default the destination bin when storage control has only one answer. Skip the intermediate acknowledgement when the next scan will confirm the same fact anyway.
Where the taps hide
The expensive taps are rarely the obvious ones. They hide in confirmation dialogs nobody questioned, in a serial-number prompt that fires on materials that are not serialised, in a quantity field pre-filled with a value the operator has to clear before they can type the real one. Sit behind a picker for one shift with a tally counter and you will find them. The savings are not theoretical: they show up in the pick rate the following week.
Designing for two operators at once
Every RF flow is used by two different people, and they want opposite things. The fast, experienced picker knows the flow cold. They want the fewest possible screens, keyboard-first entry, no hand-holding, and they resent anything that slows the rhythm they have built over months. The new starter, three days in, needs the screen to explain itself, needs the exception to say what went wrong and what to do, needs a path that does not assume they already know.
A weak design picks one of them and punishes the other. Build for the expert and the new starter drowns. Build for the new starter and the expert taps through prompts they stopped reading in week one. The tempting fix is a mode switch, a novice mode and an expert mode, but that is a trap: it doubles your test surface and someone always ends up in the wrong mode.
The better answer is a flow that serves both without a switch. Keep the happy path short enough that the expert never feels held up, and make the exceptions carry all the explanation. The fast picker scans straight through and never sees the help text, because the help lives on the branch they never hit. The new starter hits the exception, and the exception teaches. Same flow, both served, no mode to get wrong.
Exception design is the real work
The happy path is easy. Anyone can lay out the screens for a clean putaway where the bin is empty, the quantity matches and the stock is unrestricted. That flow will demo beautifully. It is also not where the floor decides whether to trust the system.
Trust is decided at the exception. The bin the system chose is already full. The handling unit will not scan because the label is torn. The quantity in front of the operator does not match the quantity on the screen. What the RF flow says at that moment, in those words, with that recovery path, is the entire product. A screen that reads “Error: bin blocked, contact supervisor” teaches the operator that the system is a dead end and the workaround is a person. A screen that says “This bin is full. Scan another bin in aisle 12 or press F4 for suggestions” keeps them inside the system and moving.
An operator does not experience your architecture. They experience your worst screen, on your worst day, at your busiest hour.
Write exception messages in the language of the warehouse, not the language of the data model. “No available storage bin found for the determined storage section” means nothing to someone holding a pallet. “No empty bin for this stock. Put it in the overflow row and scan the location” means something they can act on. And make the recovery faster than paper, because paper is the competitor. If the workaround is quicker than the system's own recovery path, the workaround wins, every time.
Scan sequence and physical reality
The order in which an RF flow asks for scans should match how a person actually moves and reaches, not how the data model is shaped. The system may find it tidy to ask for the destination bin before the handling unit, because that is the order the tables relate. But the operator has the HU in their hands and the bin is six metres away and above their head. Ask for what is in reach first. Every flow that fights the operator's body loses a few seconds a line, and a few seconds a line is the whole margin.
The things the design workshop forgot
Barcode placement decides whether a scan is one motion or a two-handed wrestle with a pallet. Gloves change which buttons are reachable and whether a touch target the size of the standard field is hittable at all. A cold-store operator is wearing thermal gloves and cannot use a capacitive touchscreen, so that flow has to be driven from the keypad end to end. Half the workforce holds the gun in one hand and a pallet or a rail in the other, so any step that needs two hands is a step they will skip. None of this appears in a blueprint. All of it decides whether the flow works.
This is why the design cannot be finished at a desk. The reachable button, the readable font under a sodium lamp, the barcode you can hit without setting the pallet down: these are physical facts about a specific building, and they only surface when you stand in it.
Test on the floor, not in a lab
A flow that tests clean at a desk can fail at a racking bay at peak. The desk test has good light, a standing operator, one transaction at a time, a fresh label and all the time in the world. The racking bay at peak has none of that. The label is scuffed, the operator is on their feet at hour seven, the network drops for a beat behind the steel, and three tasks are queued behind the one on screen. A design that only ever met the desk has never met its actual conditions.
So test where the work happens. Put the flow on a real gun, on the real network, in the real aisle, with a real operator doing real volume, before you call it done. Watch what they do when the scan fails on the third attempt. Watch where their thumb lands. Watch which screens they have already stopped reading. The floor will tell you in an afternoon what a month of desk testing never could, and it will tell you while there is still time to change the shape.
None of this is exotic. It is the discipline of treating the RF flow as the product it actually is: the surface where SAP EWM meets the human, designed first, costed in taps, built for both operators, proven at the exception, shaped to the body, and tested where it will live.