Designing for the five-hundredth line

Most business software is designed for the occasional user. The forms are generous, the confirmations are reassuring, and every action is discoverable. Then it meets the person who enters a 500-line order every morning, and all of that generosity turns into cost — because the thing that helps a novice on their fifth record punishes an expert on their five hundredth.

High-frequency entry is a distinct design problem. Three parts of our interface exist because of it.

1. Tabs, because people work on more than one thing

The default web pattern for "I need to look at something else for a second" is the browser tab. It works, and it is terrible for operational work: browser tabs are unlabelled beyond a truncated title, they lose their relationship to each other, and after twenty minutes nobody knows which of the seven open tabs is the order they were actually editing.

So the workspace keeps its own tab strip, and it is structured rather than flat. Each entity gets a tab group whose first tab is pinned — All Orders, All Cases — and never closes. Records you open append to the right of it, in the order you opened them.

The part that carries the mental model is the third level. Open something from inside a record — the account on an order, a line, a related case — and it does not become a peer of the order. It nests under it, in a second strip labelled Related documents. The order remains the thing you are working on; the account is something you opened while working on it. That distinction is the difference between a tab bar and a map of your attention.

A few decisions we would defend:

The tab set survives a reload. Refreshing, or being logged out by a network blip, does not cost you the six records you had open for the session.
Tabs are capped — fifteen record tabs per entity, ten nested children — and the oldest is evicted. A tab strip with forty tabs has stopped being navigation and become a second problem.
Hovering a tab previews the record after a short delay, using the tenant's own preview layout — deliberately faster than the browser's native tooltip, so what you get is the customer's name and status rather than a truncated URL.
A record with an edit in progress stays alive when you switch away from it. Everything else is re-rendered on return with scroll position restored. Keeping every pane mounted would be simpler and would make the twentieth tab hurt.

2. The Quick Add Panel, because the modal is the enemy

Adding a line to an order is the most repeated action in the product. The conventional pattern — click Add, a modal opens, fill it, save, modal closes, click Add again — costs two clicks and a context switch per line, and the modal covers the very grid you are building.

The Quick Add Panel puts the create form in the table header region, directly above the rows. It is not a special cut-down grid row; it is the entity's real Create layout, so it validates, prices and applies the same business rules as the full form, and a tenant decides which fields appear by designing that layout.

The behaviour that matters for the five-hundredth line is what happens after save. The panel does not close. It resets in place — without remounting, so there is no flicker — clears the previous values and errors, and re-applies defaults, including re-attaching the parent order. You are immediately in an empty form pointed at the right document, ready for the next line.

Being precise about the keyboard, because a UX article that gets its own shortcuts wrong is worse than useless: Ctrl/Cmd+S commits the line — it is scoped to the active card, so it saves the panel you are in and not some other form on the page, and it works from the moment the panel opens without clicking into it first. Moving between fields is ordinary Tab traversal. On a standalone entity list the form is a real <form>, so Enter submits natively; inside an order's Lines grid it deliberately renders as a <div> to avoid nesting one form inside another, and there Ctrl/Cmd+S is the commit. That inconsistency is a genuine rough edge and we would rather name it than let someone discover it at line 300.

One neat consequence of the panel being a real layout: other widgets can push into it. The Frequent Items tile publishes an item and quantity straight into the panel, so "the things this customer always orders" becomes a click rather than a lookup.

3. Item 360, because the answer should not be somewhere else

Here is the moment that actually costs time. A user picks an item and needs to know three things: is there stock, is there a scheme on it, and is there a substitute if there is not. Traditionally that is three lookups in three places, and the order line is abandoned in the middle while the user goes hunting.

Item 360 puts all three on the line itself, as a strip of summary cards that answer at a glance:

Item Stock — Available and In Hand as two figures with a meter, and a caption saying across how many branches and lots. Stock is scoped to the document's partner and branch, so it is your availability, not a global number that is true nowhere.
Scheme Recommendations — leads with the nearest scheme you have not qualified for and what is still needed to reach it. That is the commercially useful sentence: a line sitting just below a slab is money on the table for both sides.
Alternate Items — substitutes as chips, with a count, and live stock for each rather than a stored figure that cannot be right for every branch.

Clicking a card opens a drawer with the detail — stock broken out by branch and by lot, the full applied and eligible scheme lists, or the alternates list where selecting one swaps the line's item and clears the SKU and price so they re-resolve.

Two subtleties worth stealing.

The cards wait before they fetch. Nothing loads until the strip has been scrolled into view and the item, quantity and price have been unchanged for half a second. On a line form those values change several times in a row while the user settles on what they mean, and firing three queries per intermediate state is both wasted work and visible flicker. Quantity edits refresh only the schemes card, because stock and alternates do not depend on how many you are buying.

Empty states hold their place. By default a card with nothing to show stays and says "No alternates" rather than disappearing. A layout that reflows as data arrives is a layout where users click the wrong thing.

What we have not solved

Three honest gaps, because a page about efficiency should be audited by its own standard.

The keyboard path is not complete. After a line commits, focus is not returned to the first field automatically — so the fully hands-on-keyboard loop that a 500-line order deserves still has a gap in it. That is a small fix and it is the one we would make first.

Tabs are not arrow-navigable. Tab activation works with Enter and Space, and every tab is reachable, but there is no left/right arrow movement between them as the ARIA authoring practices describe.

The Item 360 cards are not keyboard-reachable. They are clickable cards without a button role, which is fine with a mouse and not fine otherwise. The view toggle beside them is properly labelled; the cards are not.

None of these stop the work. All three are the difference between an interface that is fast for most people and one that is fast for everyone.

What I would tell another design team

Find out how many times a day your heaviest user performs your most common action. If the answer is in the hundreds, you are designing a different product from the one your onboarding flow implies, and the two sets of decisions genuinely conflict.

Then attack looking-for-things before you attack clicks. Removing a click saves a second; removing a lookup saves a context switch, and the context switch is what actually ends the task. Every one of the three patterns above is the same move — put the answer where the question is asked.