Two jobs, one set of facts, not one decorative theme
Warehouse and accounts do not want the same screen. They want the same facts. The stall we see is a design file that looks like a SaaS dashboard — charts, seven fonts, a hamburger of modules — while the bay still runs on a paper list and a WhatsApp photo, and accounts still retypes an export. The useful interface is the one a supervisor can complete with dusty thumbs, and an accounts lead can agree without walking to the floor. That is a UI and UX job attached to a .NET system of record, not a marketing site with a login bolted on.
If you only design for the person who signed the cheque, you will ship a homepage of KPIs nobody in the bay can use. If you only design for the bay, you will ship a list accounts cannot export or undo. The first slice has to serve both, narrowly: today’s work, a way to correct it, and a trail finance will accept. Everything else is a later sentence.
Mixed literacy is the default, not an edge case
In a lot of plants and trading floors the person who does the job is fluent in the work and not fluent in English UI copy. Some read Malayalam more easily. Some read numbers and icons and ignore paragraphs. Some have never made an account on a website and will not start with yours. “Intuitive” as used on agency slides usually means “looks like the last app the designer used”. That is not the test. The test is whether a new temp on a night shift can complete today’s list after one stand-up, without calling the person who built it.
Write labels in the words the floor already uses. If they say “DC”, do not write “Despatch challan (outbound logistics artefact)”. If they say “bill”, do not write “AR document”. If two languages are in the room, put the action words in both, or pick the one the supervisor will teach, and stick to it. Do not switch language between screens. Do not hide the dangerous action under an icon that means something else in a consumer app.
Literacy also means numeric literacy under pressure. Large tap targets. One primary action. No tiny grey links for “confirm”. The destructive action — cancel this line, reverse this receipt — should be harder to hit than the next item, and should always ask a second time in words, not in a toast that vanishes. People will share a device. People will have wet hands. People will be interrupted. Design for that Tuesday, not for a Figma prototype on a laptop in Kochi air-conditioning.
Training that is a PDF in a shared drive is not a design. If the screen needs a manual, the screen is unfinished. A ten-minute floor walk with the real device is the spec. Photograph the current paper. The paper is the information architecture. Your job is to make that paper faster and harder to lose, not to replace it with a metaphor.
Phones in the bay, not a hidden desktop requirement
If the work happens standing up, the first client is the phone the supervisor already has — often a mid-range Android with a cracked screen, uneven light, and a network that drops between the rack and the gate. A layout that assumes a mouse and a 1400-pixel table will be used at the office desk and ignored on the floor. Then you will hear that “they don’t like the system”. They liked the paper. The paper fit the hand.
Today’s list should be the home screen for that role. Not a chart. Not a news carousel. Not a global search that needs a document number they do not have yet. Filter to this location, this shift, this status. Show the next action. Let them complete it in two or three taps. Offline-tolerant where the aisle has no signal — at least a clear “not saved” rather than a spinner that lies. When the network returns, do not duplicate the dispatch because they tapped twice. Idempotency is a UX feature. Staff should not have to understand the word.
Barcode or search-by-number beats typing long names with gloves nearby. Cameras on cheap phones fail in glare; always allow a manual fallback. Do not require an email to log in if nobody in the bay has one. A staff code plus a PIN, or a shared device with a personal unlock for the shift, is more honest than copying a consumer onboarding flow. Password-reset email is how you lock the night shift out.
Brightness, contrast, and type size are not polish. They are whether the line can be read under a tube light. Avoid pale grey on white. Avoid placing the only “save” on a sticky footer that also holds a chat widget. You do not need a chat widget in the bay. You need a back button that does not lose the list position.
Undo is how you earn trust in week one
The first week of a new screen produces mistakes. Wrong quantity, wrong customer, a line packed twice. If the only fix is “call the developer” or “we cannot reverse it, make a new one”, staff will keep a paper backup forever. Undo — a dated reversal they can do themselves, with a reason, visible to accounts — is not a nice-to-have. It is the difference between a system of record and a trap.
Undo has rules. You cannot pretend a GST-posted voucher never existed. You can create a reversing entry and show both. You cannot let anyone delete yesterday’s dispatch after the truck left without a role that accounts agreed. You can let the same supervisor cancel a line they created five minutes ago. Write those rules on the brief. Then put the button where the mistake happens, not three menus deep in an “admin console” only the vendor can open.
Show who did what, when. The bay will accept a firm undo. They will not accept a silent change. Accounts will not accept a delete. The UI is how those two constraints meet: a history on the record, a reversal that looks like a reversal, and a role that cannot rewrite the past. If your MVP cut undo to hit a date, you shipped a prototype. Call it that. Do not be surprised when the spreadsheet stays.
The same is true of “edit”. Editing a quantity after print is not the same as editing a draft. Use words the floor already has: draft, confirmed, sent, cancelled. Do not use “updated” for all of them. “Updated” is how two people fight about what the customer received.
Today’s list is the product
Directors like dashboards. The bay likes a list of what is left. Accounts likes a list of what is unmatched. If you have budget for one excellent screen in the first slice, build today’s list for the role that currently lives in WhatsApp, and an export plus unmatched queue for the role that currently lives in Excel. Charts can wait. Last year’s analytics can wait. A map can wait.
Today’s list should answer: what is mine, what is late, what is blocked, what I can do next. It should not answer “revenue versus target” for a person who is holding a box. Colour can mean late. Colour should not be the only signal — some phones are old, some people will not read red as you intended. Put the word “late” on the row. Put the count at the top. When the list is empty, say so in a sentence, and do not replace it with a motivational illustration.
Accounts’ version of today’s list is narrower: posted versus not, matched versus not, exported versus not. Same underlying movements. Different columns. Do not force them onto the warehouse layout and tell them to “change the filter”. Give them a URL that opens on their job. Shared facts, separate homes. That is cheaper than a “universal inbox” nobody understands.
Print and share still exist. A DC that cannot print or send is not done. A list that cannot be read aloud to someone on a feature phone is not done. Design the empty state, the error state, and the “we already sent this” state. Happy-path mockups are how you get a stall in week two.
What both sides must see — and what they must not
Both sides must see the same document number, the same quantities, the same timestamps, the same “who confirmed”. If those diverge, you have two systems. Accounts must see tax and ledger fields the bay should never have to fill. The bay must see location and pack instructions accounts should never have to interpret. Hiding a field is a design decision. Dumping every column on every role is how mixed literacy becomes mixed-up data.
- Warehouse: next action, quantity, destination, print/send, undo of their own recent mistake.
- Accounts: status, amounts, tax, match to payment or voucher, export, reversals they authorised.
- Both: the id, the audit, today’s count of blocked rows.
Permissions are UX. A clerk who can see salary or another branch’s margin will stop trusting the screen, or will gossip it. A supervisor who cannot see why a line is blocked will phone accounts. Put the reason on the row in words they can read: “waiting for Tally”, “payment unmatched”, “credit hold”. Then give the right role the button. Mystery statuses are how WhatsApp comes back.
What not to put on the first screen
- A customisable widget grid. Nobody in the bay will customise it. They will ask you to put the list back.
- Onboarding carousels. Walk the floor instead.
- Dark patterns for “engagement”. This is a tool. Empty is a successful shift.
- Stock photos of smiling warehouse staff. Use the real labels from their paper.
- A floating chat or a tour that blocks the first tap.
Those refusals keep the first slice honest. They are also how you stay inside an MVP: one job, real devices, measured use. If after two weeks the list is completed in the system most days, you earned a second screen. If it is not, do not add charts. Ask whether the list was the wrong job, or the phone was the wrong assumption, or undo was missing.
How we actually design and build this
We sit on the floor. We photograph the paper and the chat group. We write the in-list: login that works without email, today’s list, complete a line, print or send, undo, export for accounts. We put a build on the device they already carry. We watch a shift without narrating. Then we change type size, order of fields, and the words on the buttons. That loop is the design work. The implementation is ordinary ASP.NET screens with roles, audit rows, and lists that do not die at last year’s volume.
We will not start from a theme. We will not promise a unique visual language in week one. Consistency with the paper and with each other matters more than brand illustration. If you already have a public site, the logged-in tool can share a colour and a logo and still be a different definition of done. Sharing a header is not sharing an estimate.
A one-page brief for this work: who uses it standing up; who uses it at a desk; which language they teach; which device they hold; what “today” means; what they must never be able to delete; what accounts must export; how you will count success after two weeks. Send that page. If the reply is a mood board and no list, you have a studio. Studios are fine for a site. They are the wrong animal for the system people work in.
Screens warehouse and accounts will both use are not a compromise grey. They are two homes on one set of facts, built for mixed literacy, phones in the bay, undo, and today’s list. Get those four right and the spreadsheet has to argue for its life. Get them wrong and you will have a beautiful login that nobody opens after the festival. Write the four on the brief before anyone opens Figma. Then keep them when a director asks for a dashboard. The dashboard can wait until the list is true on a Tuesday when you are not in the building.