The Screen With 200 Fields: How to Design Enterprise Forms

A client sends over the spec for one screen. It’s a purchase order form, and the field list runs to 200 entries. Some are dates, some are lookups against tables you’ve never seen, and four of them are called something like Cost Center Override. Your first instinct, trained on landing pages and mobile checkouts, is to cut it in half.

Don’t. Not yet.

Enterprise forms look bloated because the business behind them genuinely is that detailed, and the person filling in that screen will do it forty times before lunch. The design problem isn’t reduction. It’s making 200 fields feel like a task instead of a wall. That takes a different set of moves than anything a consumer product asks of you, and the moves are learnable.

The Field Count Isn’t a Design Failure

Almost every piece of form advice you’ve read was written about strangers. A visitor lands on a checkout, owes the company nothing, and leaves if the third page asks for a fax number. That research is solid: Baymard Institute’s checkout studies put the average checkout at 11.3 form fields, down from 12.7 in 2019, while most sites need only about eight. Cut fields, win conversions.

An ERP receiving screen inverts every assumption in that sentence. The user is an employee who was trained on the system, opens it every shift, and cannot leave. They aren’t deciding whether to buy something. They’re recording something that already happened, in enough detail that finance, tax, and the warehouse all get what they need out of one entry.

The cost of a removed field isn’t lower friction. It’s a missing purchase order number that turns into a two-week reconciliation fight in March.

It also changes what you’re optimizing for. Consumer form work is judged on completion rate, because the alternative to completing is leaving. Enterprise form work is judged on time per record and error rate, because the alternative to completing is completing it badly. Ask which of those numbers the client is trying to move before you touch the layout, and you’ll design a different screen.

Find Out Where Every Field Came From

Every field on that screen has a story, and nobody wrote it down. It’s a column in a table. It’s a state tax requirement. It’s on a report the CFO opens on Friday mornings. Or it was added in 2017 for a customer who churned in 2019, and no one has dared touch it since.

So your first job here isn’t wireframing. It’s annotation. Ask for the field list in a spreadsheet and get three columns filled in next to each row: who fills it, what breaks if it’s empty, and where the value goes afterward. If the system is being built or replaced by a custom ERP development company, that mapping usually exists already as a data dictionary or an integration spec, and asking for it beats a week of guessing. On older in-house systems the answer tends to live with one long-tenured analyst who will be pleased that somebody finally asked.

What comes back sorts into three piles. Fields required by audit or law, which you can’t move off-screen without a conversation. Fields feeding a downstream report, which can often be defaulted or calculated instead of typed. And fields nobody has read in years, which is where your 200 quietly becomes 140.

Group by Task, Not by Table

Most enterprise screens you inherit are laid out in the order the database stores things: header fields, then line items, then flags, then notes, because that’s the shape of the tables underneath.

People don’t work in that order. A warehouse supervisor confirming a delivery works through three questions. What showed up, does it match what we ordered, and what’s wrong with it. Group the form around those questions and the total field count stops mattering as much, because the user only ever reads one group at a time.

Sequence matters as much as grouping. If the paper receiving slip lists quantities before condition notes, the screen should too, because the person is reading off paper and typing with one hand.

Name the groups in the user’s language while you’re at it. “Line Item Attributes” is a table name. “What arrived” is a question the person standing at the dock is already answering in their head. The fields underneath don’t change. The screen stops feeling like a database and starts feeling like a task.

Don’t Hide What They Fill Every Time

Progressive disclosure is the reflex fix for a crowded screen, and on enterprise forms it backfires more often than it helps. Hiding a field the user needs on nine out of ten entries adds a click to nine out of ten entries, forever, for somebody who does this all day. Nielsen Norman Group’s research on complex applications makes the same point from another angle: expert users in specialized domains optimize for speed and predictability, not for a clean first impression.

A few rules that hold up:

If a field gets filled more than half the time, it stays visible.
Collapse by exception, not by category. “Returns and damages” can hide. “Quantity” cannot.
Never put a required field inside a collapsed section. Someone will submit, get an error pointing at something they can’t see, and stop trusting the screen.
Put a filled-count badge on every collapsed section, so nobody has to open it just to check.

Density is the other tool, and it’s underrated. Tighter row heights, smaller labels, and multi-column layouts are appropriate here in a way they never are on a marketing page. A screen used by trained staff on a 27-inch monitor carries several times the information of a consumer page without feeling worse to use.

When the Answer Really Is Two Screens

Sometimes the field list isn’t one form. It’s two jobs that got merged because both touch the same record.

The tell is the fill pattern. If half the fields are completed by a different person, at a different time, on a different trigger, they don’t belong on one screen. A purchase order gets raised by a buyer on Tuesday and matched against an invoice by accounts payable a month later. Same record, two screens, two sets of defaults, two permission sets.

Resist the wizard, though. Multi-step flows work on consumer signups because the user does it once and wants the reassurance of a progress bar. A person entering forty records a shift experiences that same wizard as four extra clicks per record, and they will find the workaround: a spreadsheet they keep on the side and paste in before they clock out. If you hear about that spreadsheet during research, you’ve found the real requirement.

Labels Should Sound Like the Room

Sit in on one shift handover and write down the words people actually use. They won’t be the words in the spec. The spec says “vendor”; the floor says “supplier”. The spec says GRN; everyone says “the receiving slip”. Ship the floor’s vocabulary, and put the formal term in help text if the audit trail needs it.

Then keep the label visible. Placeholder-only labels are the most common shortcut in dense forms and the most expensive one. Nielsen Norman Group’s form usability testing found that placeholder-only labels increased both errors and completion time across every group tested, with older users hit hardest. On a form this long, where people tab through and then review, a label that disappears the moment you type isn’t a minor annoyance. It’s a re-reading tax on every pass.

Use placeholders for format hints instead: “MM/DD/YYYY” or “e.g. PO-24188” next to a real, persistent label.

Validate on Blur, Not on Every Keystroke

Inline validation belongs on enterprise forms, but the timing decides whether it helps or hurts. Baymard’s usability testing of inline validation found that checking a field once the user leaves it reduces errors, while validating on every keystroke increases them, because the user gets corrected for an incomplete entry they were halfway through typing.

The error copy matters more than the pattern does. “Invalid format” tells a person nothing at 6 a.m. “Needs 8 digits, no dashes” tells them exactly what to do next. And once someone has hit one confusing validation error, Baymard’s researchers watched test users go defensive on later fields, typing “N/A” into anything they weren’t sure about rather than leaving it blank. Every one of those is dirty data your form invited.

Two more things trained users need that consumer forms rarely provide: a way to save a partially complete record, and an error summary at the top that links down to each failed field. Hunting for one red outline in a 200-field screen is its own usability failure.

Design for the Keyboard, Then the Glove

Watch somebody experienced use an ERP screen and you’ll notice they barely touch the mouse. They tab, type, tab, type, and hit a shortcut to save. If your tab order jumps around because of how you arranged the columns, you’ve slowed down the most repeated action in the building. Walk the tab order yourself, in the browser, before handoff.

The same screen often runs on a tablet out on the floor, held by someone wearing gloves, which is a different problem entirely. WCAG 2.2 sets a floor of 24 by 24 CSS pixels for interactive targets at level AA, and it really is a floor: the AAA criterion asks for 44, and both Apple’s and Google’s platform guidance sit around that size. For a gloved thumb next to a moving forklift, design past all of it.

Ask early which screens are desk work and which are floor work. They rarely want the same layout, and finding out during QA is expensive.

What to Hand Over With the Mockup

A tidy frame isn’t a deliverable on this kind of project. What the developers need is closer to a spec:

Every field’s states: empty, focused, filled, disabled, error, read-only.
The permission variants. A buyer, a warehouse clerk, and an auditor see three different versions of this screen, and somebody has to decide which fields each role can edit rather than only view.
Defaults and calculated values, marked as such, so nothing that should auto-fill ends up as a typed input.
Behavior on a slow connection: saving states, and what the screen does when a save fails after 40 fields of work.

Include the empty and error versions even though nobody asked for them. That’s where enterprise software usually falls apart, and they’re cheap to draw while the file is already open.

Final Thoughts

Enterprise forms reward a different skill set than portfolio work does, and fewer designers have it, which is exactly why the work pays. Start with the field list and its provenance, not the layout. Group around the user’s task rather than the database’s structure. Keep labels visible, validate on blur, and check the tab order with your own hands. Then hand over the states and the permission variants along with the mockup. The screen will still have a lot of fields on it. It just won’t feel like 200.

Author
Recent Posts

Bogdan Sandu

Bogdan Sandu is a seasoned designer who has been designing websites since 2008.

Renowned for his expertise in logo design and visual branding, Bogdan has developed a multitude of logos for various clients.

His skills extend to creating posters, vector illustrations, business cards, and brochures. Additionally, Bogdan's UI kits were featured on marketplaces like Visual Hierarchy and UI8.

He also wrote in the past years on sites like Design Your Way, WebDesignerDepot, WPDean, Designmodo, Speckyboy, Slider Revolution, and more.