Designing for frontline work
The people who use operations software are often holding a carton, wearing gloves, standing in a cold room with one bar of signal, while a driver waits or a queue grows. Screens designed at a desk fail them. This lesson shows you how to design for the hands, the place, the network, the shift and the peak day, and how to test it where the work happens.
By the end you can
- Describe the working conditions with a conditions card and turn each condition into a design rule
- Design scan-first flows with large targets, clear feedback and no dead ends
- Decide, action by action, what works offline, what waits to send and what needs a network
- Plan for shift changes, shared devices, temporary staff and several languages
- Run a field test in the hardest store and a peak-day readiness check
The everyday picture
A recipe website is designed for someone on a sofa: long paragraphs, photos to scroll past, a list of ingredients at the top. Now try to use it at a restaurant stove during the 8 pm rush, with wet hands, three pans going and a waiter shouting an order. It fails, and nothing about it is wrong for the sofa.
The restaurant uses something else: a ticket rail. Each order is a slip printed in large letters, readable from two metres away. Cooks never type. The head chef calls orders out loud and cooks answer "yes, chef", so everyone knows the order was heard. If the printer jams, someone writes the ticket by hand and the kitchen keeps going. That is the brief for frontline software: glanceable, very few inputs, feedback you can hear, and a way to keep working when something breaks.
Start from the conditions, not the screen
Frontline software is used in conditions a design review in an office never sees. Before anyone draws a screen, write a conditions card: one page describing the place, the body and the pressure the work happens under. You collect it on a field visit (Watching the work), and every line becomes a design rule.
| Condition | What it breaks | Design rule |
|---|---|---|
| Hands: gloves in the cold room, one hand holding a carton, wet or dusty fingers | Small buttons, typing, swipes, two-handed gestures | The scanner trigger does the main action; other targets are large and at the bottom, in thumb reach |
| Eyes: glare at the dock, a dim storeroom, the screen at arm's length | Grey text, thin fonts, meaning shown only by colour | High contrast, large text, status as a word plus a colour plus an icon |
| Ears: compressors, forklifts, music on the shop floor | Quiet beeps, alerts nobody notices | Different sounds for success and error, plus vibration |
| Network: no signal in the cold room or at the back dock | Anything that waits for the server | Work continues offline; the screen shows what is waiting to send |
| Time: a driver waiting, a customer queue | Long paths, confirmation dialogs, slow screens | The common case in the fewest steps; undo instead of "are you sure?" |
| Attention: interrupted every few minutes | Multi-step forms, timeouts that lose work | Save on every scan; resume exactly where the person stopped |
| People: shift work, festival temps, several languages, different reading levels | Text-heavy screens, jargon, one language | Short words, icons with labels, the languages staff read, a guided first use |
| Device: a shared rugged handheld, sometimes three or more years old | Heavy screens, long sign-ins | Test on the oldest device in use; quick personal sign-in |
Some numbers help. WCAG 2.2, the web accessibility standard, asks for touch targets of at least 24 by 24 CSS pixels at level AA and 44 by 44 at the stricter level AAA. Android's accessibility guidance asks for at least 48 by 48 dp. Treat these as the floor for a person with bare fingers sitting still. A person in gloves with a carton in the other hand needs more, so test with the gloves staff actually wear. For text, WCAG's minimum contrast for normal text is 4.5 to 1; glare at a loading dock makes higher contrast worth it.
The device's own settings are part of the product. Rugged handhelds often have touch modes for gloves: Zebra's Touch Manager, for example, offers modes such as "Glove and Finger" and "Stylus and Finger" on many of its devices. Whether that mode is on in 320 stores is a configuration decision for you and IT, and it belongs in the spec.
Quick check
On a field visit you see a clerk take off her glove, tap the screen, and put the glove back on, eight times during one cold-room delivery. Which change addresses the condition?
The condition (gloves in a cold room) won't change, so the design has to. The scanner trigger needs no touch at all, large targets work through gloves, and the device setting helps the rest. SOP reminders and thinner gloves push the cost onto staff, and a theme doesn't fix touch.
Scan first, type last
Every input costs seconds and invites errors, and at Mangrove those seconds repeat in 320 stores every day. Rank inputs from best to worst and design down the list only when you must:
- No input: the system already knows. The delivery's expected lines come from the supplier's advance shipping notice, so nobody types a purchase order number.
- A scan: the barcode on the delivery note, each carton, a shelf label, a staff badge.
- A large choice: two to four big buttons such as "Short", "Damaged", "Wrong item".
- A short list: pick from five reasons, most common first.
- A number pad: only for quantities that can't be scanned.
- A keyboard: last, and never on the main path.
Feedback has to work without looking. Each scan gets a sound, a vibration and a large on-screen change at once, with a clearly different sound for an error ("wrong supplier", "not on this delivery"). Errors are stopped at the scan, where they are cheap, and never become dead ends: if an item isn't on the delivery, staff can add it with a photo and the reason, and someone sorts it out later.
One decision needs product judgement. Showing the expected quantity next to each line is fast, but people start tapping "matches" without counting. Blind receiving hides the expected quantity, so the count is independent, but it is slower. A middle path is to scan each carton, show a running count, and reveal differences only at the end. Choose based on which costs more for that supplier: time at the dock, or errors in stock.
Large retailers design the same way. In 2021, Walmart said it would give more than 740,000 US store associates a Samsung Galaxy XCover Pro phone with its in-house Me@Walmart app, replacing shared handhelds for many tasks. The app put scheduling, clock-in, push-to-talk and its "Ask Sam" voice assistant in one place, and Walmart described a planned camera feature that highlights boxes ready to go to the shop floor instead of scanning each box, which it said takes a third of the time of the old manual process. Fewer inputs and fewer apps were the design goal.
Quick check
The new receiving screen shows the supplier's expected quantity on every line with a big "Matches" button. In the pilot, receiving is fast, but stock counts a week later show more gaps than before. What is the most likely cause, and the fix?
A pre-filled quantity with a one-tap confirm invites confirming without counting, and the errors show up later as stock gaps. The design caused it, so the design should fix it. Retraining fights the design every day. The notices are still useful for loading the expected lines.
Offline is a product decision
"Works offline" is not a requirement anyone can build or test (User stories and acceptance criteria). The engineering of queues, sync and conflicts is in Offline-first apps and data sync. The product decisions are yours, and you make them action by action:
- Works fully offline: scanning, counting, recording exceptions, taking photos. Everything is saved on the device at every scan.
- Waits to send: posting the receipt so the goods received note (GRN) reaches the ERP. Staff can finish and walk away; the app sends it when signal returns.
- Needs a network: actions that depend on fresh data or another person, such as a manager approving a price override from head office. Say so on the screen, and give a fallback.
Then decide what staff see. A banner that reads "3 receipts waiting to send, last sent 10:42" removes most "did it go through?" calls. Decide the conflict rules too: if two people count the same shelf offline, are the counts added, does the later one win, or are both flagged for the manager? If sales happened during the count, which stock figure is the count compared with? These are business rules, so they need a business owner.
Finally, decide what happens when the server says no. A delivery received offline may be rejected later, for example because buying closed the purchase order an hour earlier. The receipt must never disappear. It comes back to the store with the reason and an action, as the diagram shows.
On company-owned handhelds, one more product decision sits with IT: whether to lock the device to your app. Android's lock task mode runs devices in a kiosk-like way where only allowlisted apps can run. It stops staff from changing settings or wandering into other apps, and it also stops them from opening the camera or a calculator you forgot to allowlist. Decide which apps a store handheld needs before you lock it.
Offline rules people can rely on
Write the offline behaviour as a table in the spec, one row per action, and test every row with the network switched off on the store's own handheld. If staff ever lose work offline, they go back to paper "just in case" and the paper never goes away.
Quick check
During a two-hour outage, staff keep receiving. When signal returns, the server rejects one receipt because buying closed its purchase order. What should the design do?
The goods are physically in the store, so the record must never disappear, and the person who can fix it needs the reason in plain words. Dropping it creates a stock gap. Posting it anyway breaks the purchase order rule and moves the problem to finance. A code with no explanation, followed by a full re-receive, wastes the store's time.
Shifts, shared devices, temps and languages
Shift changes. Work in stores doesn't end when a shift does. A delivery the morning clerk started may be finished by the afternoon clerk. Design "resume": any open task can be picked up by another person, with a record of who did which lines. Show open tasks on the home screen at the start of every shift.
Shared devices. About 1,000 handhelds serve Mangrove's 1,920 store staff, so most devices pass between people. Each person needs their own quick sign-in, such as a badge scan or a short PIN, or the audit trail can't say who did what (pm-16). Sign-out after inactivity protects the device, but it must never discard unsaved work: the interruption test below catches this.
Festival temps. Before a festival rush, stores add temporary staff who may get ten minutes of training. Give them a guided first use: the first delivery shows a hint at each step, and the hints disappear after a few successful receipts. Design for them and everyone benefits.
Languages and reading. Support the languages your staff read, not only the language head office writes in. Translated text is usually longer than English. The W3C's guidance on text size in translation quotes IBM figures: English strings of up to 10 characters can grow by 200 to 300% in European languages, and longer strings by less. Short button labels are the ones that break, so leave room, and never put text inside images. Pair key words with icons, prefer plain words to codes ("Short delivery" rather than "SHT-DLV"), and test the translated screens on the store's own handheld with staff who read that language.
Quick check
In the pilot, a clerk is called to the till halfway through receiving. She returns six minutes later; the app has signed her out and the last four scans are gone. Which rule was missing?
Interruptions are a normal working condition. Saving each scan and resuming the task means sign-out can protect the device without costing work. A warning only helps if she is still holding the device, and training against interruptions fights the job itself.
Design for the peak day, then test where the work happens
Mangrove's app orders rise to about 4 times normal at festival peaks, deliveries to stores rise with them, temps join, and every interruption doubles. Design decisions that look tiny on a normal Tuesday get multiplied on the worst day:
10 extra seconds per line
x 30 lines per delivery x 4 deliveries per store per day x 320 stores
= 384,000 seconds = about 107 staff hours a day, on a normal day
Festival weeks, with deliveries nearly doubling: about 200 hours a dayFour peak-day rules:
- Set a speed budget on the slowest device, with festival data volumes: the biggest delivery, the longest price-change list (pm-16 shows how to write it).
- Load test the server side at four times normal, including the burst when hundreds of handhelds come back online together after an outage and send their queues at once (Speed numbers and back-of-the-envelope math).
- Decide what to switch off under strain. An ops toggle (pm-20) can turn off nice-to-have screens, such as reports, so the core task keeps working.
- Print the fallback. A one-page paper procedure for receiving when handhelds fail, practised once before the festival, so a paper GRN can be entered later without guesswork.
Then test in the field, in the hardest store, at the busiest hour, with ordinary staff rather than only the keenest. Five tests find most problems:
- Glove test: do the whole task in the gloves staff wear in the cold room.
- Glare test: at the dock door at midday, can a person read the status at arm's length?
- Dead-zone walk: walk the store with the handheld and mark where signal drops; then receive a delivery in each dead zone.
- Interruption test: stop the clerk mid-task for five minutes, then hand the device to someone else.
- Peak test: two deliveries arrive together while a temp receives one of them.
Measure time on task with a stopwatch and from the app's timestamps, count errors and recoveries, and write down every moment someone hesitates or looks at a colleague. Hesitation is the cheapest signal you will get.
Quick check
Which test is most likely to find that receipts pile up and fail when 300 handhelds reconnect at once after a city-wide outage?
The failure is a burst of traffic, which only a load test that simulates reconnection can show. Glove, glare and usability tests are about one person and one device, and they can all pass while the server falls over at 6 pm on a festival Friday.
Do it
Write a frontline design brief for one task: the conditions card, the input plan, the offline table, the people rules, a field test plan and a peak-day check.
-
Write the conditions card from a field visit
Visit at the busiest hour. Write what you saw, not what people told you.
Markdown# Conditions card: receiving a delivery (store 214, Tuesday 6:00 to 9:00) - Device: shared rugged handheld with scanner, about 3 years old, 2 per store - Hands: gloves in the cold room; one hand often holds a carton - Eyes: glare at the dock door after 8:00; storeroom lighting dim - Ears: compressor noise next to the cold room; music on the floor - Network: no signal in the cold room and at the back dock - Time: driver waits; median delivery 51 min today, 21 of them workarounds - Attention: clerk called to the till 3 times in 3 hours - People: 2 receivers per shift; temps before festivals; staff read 3 languages - Workarounds seen: paper tally sheet, photo of delivery note to chat group -
Design the flow scan-first and count the inputs
Write the common path step by step with the input type for each. Count inputs and estimate seconds for a typical delivery. Every keyboard step needs a reason.
Markdown| Step | Input | Feedback | Seconds | |------|-------|----------|---------| | Start delivery | scan delivery note | lines loaded, sound | 3 | | Each carton (about 40) | scan | count +1, sound + buzz | 2 each | | Exception | big button: Short / Damaged / Wrong | photo prompt | 15 | | Post | big button | "Posted" or "Waiting to send (n)" | 2 | Typical delivery: about 40 scans + 3 taps. No keyboard on the main path. Quantity rule: running count; differences shown at the end (blind for suppliers with a shortage rate above 5%). -
Fill in the offline behaviour table
One row per action. Test each row with the network off on the store's own device.
Markdown| Action | Offline? | Saved where | What staff see | When it sends | If the server says no | |--------|----------|-------------|----------------|---------------|-----------------------| | Scan carton | yes | device, every scan | count +1 | with the receipt | n/a | | Record exception + photo | yes | device | "Photo saved" | with the receipt | n/a | | Post receipt | waits | device queue | "Waiting to send (3), last sent 10:42" | on signal, in order | "Needs attention" + reason to manager | | Manager price override | needs network | - | "Needs signal. Use the paper override slip" | - | - | Conflict rule: two counts of the same line are both kept and flagged for the manager. Owner of this rule: head of store operations. -
Plan for shifts, shared devices and languages
Answer each line in the brief; most of these become acceptance criteria.
Markdown- Resume: any open task can be continued by another signed-in person; lines show who scanned them - Sign-in: badge scan or 4-digit PIN in under 5 s; sign-out after 10 min idle keeps all work - Temps: guided first use with hints on the first 3 deliveries - Languages: English plus the 2 most read in stores; labels tested at 3x length - Words: plain names, icons with labels, no codes on screen -
Run a field test in the hardest store
Two stores for two weeks: one average, one hard. Ordinary staff, real deliveries, a stopwatch.
Markdown# Field test plan: scan to receive Stores: Ama's store (average), store 214 (cold room, dock dead zone) When: 6:00 to 10:00, two weeks; at least 12 deliveries Tests: glove, glare, dead-zone walk, interruption, peak (2 deliveries at once) Measure: minutes per delivery (median, p90), inputs, errors, recoveries, receipts waiting to send and for how long, hesitations Success: median under 35 min; no lost scans; no paper tally sheet used Who watches: Imran, Leila, the tech lead; one store champion -
Check peak-day readiness before the festival
Walk the list with operations, IT and support four weeks before the rush.
Markdown# Peak-day readiness: festival week - [ ] Speed budget met on the oldest handheld with the largest delivery - [ ] Server load-tested at 4x, including 300 devices reconnecting at once - [ ] Ops toggles listed: which screens switch off under strain, who decides - [ ] Paper fallback printed in every store and practised once - [ ] Spare handhelds charged; chargers checked in the 20 busiest stores - [ ] Temps' guided first use switched on - [ ] Change freeze dates agreed with every system team (pm-38, pm-39)
Bring it to your team
Ask these in your next design review for a frontline feature.
- Have we reviewed this on the store's own handheld, standing up, with one hand full?
- Which steps need typing, and why can't they be a scan or a big choice?
- For each action: does it work offline, wait to send, or need a network, and what does the person see?
- What happens to the work if the person is interrupted, signed out or replaced by the next shift?
- Which languages do staff in our stores read, and have we tested the longest translations on the device?
- What does this cost in staff hours on the busiest day of the year?
Red flags
- Designs are only ever shown on a laptop.
- "Are you sure?" dialogs on every step.
- Status shown by colour alone.
- The spec says "works offline" with no table of actions.
- Sign-out discards unsaved work.
- The pilot stores are the newest stores with the best Wi-Fi.
Practice
Critique a cold-room count screen
A vendor has designed a stock-count screen for the cold room. Description: a white screen with grey 12-pixel text; each item has small plus and minus buttons about 32 pixels wide; a "Confirm count?" dialog appears after every item; items counted are shown in green and items not counted in red, with no other marking; English only; a "Sync" button at the top right that needs a network; automatic sign-out after 2 minutes of inactivity. Find six problems, name the condition each one fails (hands, eyes, ears, network, time, attention, people or device), and propose a fix for each.
- Six distinct problems, each linked to a working condition
- Fixes favour scanning and large targets over typing and small buttons
- The colour-only status is fixed with a word or icon as well
- The sync button is replaced by automatic sending with a visible waiting count
- The sign-out problem is fixed by saving and resuming, not by a longer timeout alone
Show a model answer
- Small plus and minus buttons (hands, gloves): make scanning each item the main input, with a large number pad for cases; turn on glove touch mode.
- Grey 12-pixel text on white (eyes): high-contrast, larger text; key numbers large enough to read at arm's length.
- Confirm dialog after every item (time, hands): remove it; show the last count large with an undo.
- Green and red only (eyes, people with colour blindness): add a tick icon and "Counted", and show "12 of 40 counted".
- Manual Sync button that needs a network (network): save every count on the device and send automatically, with "Waiting to send (n)" on screen.
- Sign-out after 2 minutes (attention, cold-room breaks): save every count and resume the open count after sign-in; a longer idle time on top is fine.
- English only (people): add the languages staff read and test the longest labels on the device.
- No sound or vibration for each count (ears): add both, with a different pattern for errors.
Write the offline table for price checks
Store staff walk the aisles checking shelf labels against system prices. Actions: (a) scan a shelf label and see the system price; (b) record a mismatch; (c) print a corrected label on the back-office printer, which is on Wi-Fi; (d) approve a price correction above $5, which only a supervisor may do; (e) see today's list of price changes. Signal is weak in the back aisles. For each action, decide whether it works offline, waits to send, or needs a network; say what staff see, and give the rule for when the server rejects something.
- Scanning and seeing the price works offline because today's prices are downloaded to the device in advance
- Recording a mismatch works offline and waits to send
- Printing and supervisor approval are treated differently from scanning, with a clear message and a fallback
- Every row says what staff see, including how many items are waiting
- There is a rule for a rejected item that keeps the record and tells someone
Show a model answer
| Action | Offline? | What staff see | Rule |
|--------|----------|----------------|------|
| (a) Scan label, see price | yes: prices for the store downloaded at 6:00 and after each change file | price, and "prices as of 06:02" | if the list is over 24 h old, show a warning |
| (b) Record mismatch | yes, waits to send | "Mismatch saved. Waiting to send (4)" | sends in order when signal returns |
| (c) Print label | waits: the print job is queued on the device | "Label queued (2). Prints when the device reaches Wi-Fi" | labels print at the back office in aisle order |
| (d) Supervisor approval over $5 | needs network | "Needs a supervisor and signal. Saved for approval" | the item stays in the supervisor's list; price unchanged until approved |
| (e) Today's price changes | yes: downloaded with the price list | list, with time of last download | same 24-hour warning |
Rejected by the server (for example, the article was delisted): the mismatch
stays in the store's list as "Needs attention" with the reason; nothing is deleted.Check yourself
Riders complain that the Rider app's "Delivered" button is hard to hit while holding a phone and a bag at the customer's door, and some deliveries are confirmed late. Which change fits the conditions best?
The rider has one hand, little time and maybe weak signal, so the fix is a big target in thumb reach, no extra step, and a confirmation that can't be lost offline. A dialog and a menu add steps; a reminder pushes the design problem onto the rider.
A new screen adds 6 seconds per scanned line. Stores receive about 4 deliveries a day of about 30 lines each across 320 stores. Roughly how many staff hours a day does it add on a normal day?
6 seconds × 30 lines × 4 deliveries × 320 stores is 230,400 seconds, which is 64 hours a day, and more in festival weeks. Small per-line costs become full-time jobs at the scale of a chain, which is why seconds belong in the spec.
You can pilot the new receiving flow in two stores. Which pair teaches you the most?
A field test should expose the conditions that break designs, so include the hard store on purpose, alongside an average one to compare with. New, nearby or keen stores make the pilot look good and hide the cold room, the dead zone and the language problems until all 320 stores have the app.
Flashcards
Key takeaways
- Start every frontline design from the conditions: hands, eyes, ears, network, time, attention, people and device.
- Scan first and type last; give feedback you can hear and feel; stop errors at the scan without creating dead ends.
- Decide offline behaviour action by action, show what is waiting to send, and never let the server's "no" lose the work.
- Design for shift changes, shared devices, temps and several languages, because they happen every day.
- Multiply every second by the peak day, and test in the hardest store at the busiest hour before you call it done.
Sources and further reading
- Understanding SC 2.5.8: Target Size (Minimum), W3C, WCAG 2.2
- Text size in translation, W3C Internationalization
- Lock task mode, Android Developers documentation
- Touch Manager, Zebra Technologies developer documentation
- Walmart unveils all-in-one associate app, Me@Walmart, Walmart, June 2021
- Martin Kleppmann, Adam Wiggins, Peter van Hardenberg and Mark McGranaghan, Local-First Software, Ink & Switch, 2019 (essay)