Data Table UX Design for B2B Software at 200 Rows

A B2B product earns its keep in its tables. A buyer reorders from one, a finance clerk reconciles invoices in one, and a warehouse lead works through the day’s picks in one. When a table lets those people down, nobody files a bug. They export to a spreadsheet, and your software turns into a data entry step.

Data table UX design is the work of making those screens hold up under real use, with 200 rows, long customer names and statuses nobody planned for. These are the decisions I make on every B2B table I design, roughly in the order I make them, and what each one costs when it goes wrong.

The spreadsheet sets the bar

Every B2B table I design gets measured against the spreadsheet it replaces. On goodport, a multi-tenant wholesale ordering platform, the old process ran on phone calls, PDFs and one spreadsheet per customer. On Roadcase, tour managers built budgets in spreadsheets that went stale the day they were shared. Both teams could already sort, filter, resize columns and paste a hundred rows in one go.

A product table has to match that speed, then earn its place with what a spreadsheet cannot do. That means permissions per role, live data, states that follow the business rules, validation, and a history of who changed what. Teams keep a product table open all day when it offers both halves. When it offers only the second half, the spreadsheet stays open beside it, and what that shadow spreadsheet tells you is covered in B2B workflow design.

Decide what a row is before you draw one

The row is the unit of work, so choose the one people act on. An order back office lists orders and keeps the lines inside each order. A picking screen lists lines, because a picker ticks off lines. Choose wrong and every bulk action, filter and permission after it works on the wrong thing.

With the row settled, column order follows the job. The identifier comes first, status second, then the fields that decide the next action, then everything else. These are the column rules I start from.

Two of these rules come straight from published standards. The GOV.UK Design System tells teams to align numbers to the right when people compare columns of numbers, and the CSS tabular-nums setting gives every digit the same width so those columns line up. The status rule is WCAG 1.4.1, which asks that colour is never the only visual means of carrying information. A red chip that also says “Overdue” passes, and it still reads on a washed-out warehouse monitor.

Density is a setting

IBM’s Carbon design system offers five row heights, from 24px to 64px, and keeps the tallest for rows that carry two lines of content. That range is the useful way to think about density. It works as a dial per role, set by how long people stay in the screen.

On goodport, the customer portal and the admin portal share one token set and one component library, and density is the only thing that changes between them. Buyers come in to reorder and get room to read. Sales, finance and logistics work in the admin portal all day and get more rows per screen. On a 13-inch laptop, with a typical app header and toolbar above the table, 40px rows show about sixteen records and 32px rows about twenty. Four extra records per screen adds up for someone checking orders all morning.

Compact rows still have a floor. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels, so the checkbox and the row menu keep that size while the text around them tightens. I default each role to the density it needs and let people move one step either way, saved to their account.

Find the record first

Most table work starts with a question. Where is this order? Which accounts are overdue? What ships today? The table’s first job is answering that before anyone scrolls, and it has three tools for it.

Search that knows identifiers. An exact order number or SKU jumps straight to the record. goodport’s customer portal offers quick order by SKU code for the same reason, since people who reorder already know their codes.

Filters you can see. Active filters sit above the table as chips, with a count such as “Showing 38 of 212 orders” and one control that clears them all. People forget a filter that sits inside a closed panel, and then they report missing data.

Saved views. Each role opens the same three or four slices every day, such as due today, backordered and my accounts. Save them as named views, keep sort and filters between sessions, and put the view in the URL so a shared link opens the same list. Why remembered settings build trust is in B2B dashboard design principles.

Sorting that holds still

Clicking a column header sorts by it, and a second click reverses the order. Choose the default sort on purpose, usually by urgency such as the promise date, so the first screen holds the rows people need to act on. Add a fixed secondary sort, such as the order number, so rows with equal values keep their places when the data refreshes.

For screen reader users, the W3C’s sortable table example puts aria-sort on the sorted column header, one header at a time, and wraps each sortable header’s text in a button so the whole cell works as the control. The table underneath needs real structure too. The W3C tables tutorial marks header cells with th and data cells with td, and adds scope wherever a header’s direction is unclear.

Bulk actions and the selection model

Operations work arrives in batches, so bulk actions carry much of a table’s value. The Fathom back office puts them on the orders list, which runs orders for five shops and a wholesale outlet from one place. Selection is where these tables most often go wrong, and four rules keep it predictable.

• The header checkbox selects what is visible. Selecting everything that matches the filter is a separate step that names the number, such as “Select all 212 orders”.
• The toolbar becomes a bulk bar while rows are selected. It shows the count and only the actions that apply to every selected row. Carbon calls this the batch action bar.
• Destructive actions confirm with the count and offer an undo afterwards.
• Partial failure is a normal result. “18 of 20 updated” keeps the two failed rows selected, with the reason beside each, so the person fixes them straight away.

Edit in the row or in a panel

Inline editing suits single values people change often, such as a quantity, a price override or a status. Roadcase’s live budget works this way. A tour manager adds a line item or edits a row in place, and the totals follow. A side panel suits records with many fields, a history, or anything that needs a reason recorded.

The dividing line I use is approval. A change that needs a reason or a sign-off goes in a panel. Inline edits save per cell with a visible saved state, and an edit in progress survives a sort, a filter or a refresh. One lost value is enough to make people double-check the table for months.

Pagination, infinite scroll or virtual rows

How the rows arrive shapes the work as much as how they look. This is how I choose.

At 200 rows I load them all and keep the header sticky, which keeps browser find working. Past a few thousand, I paginate on the server. Virtual rows need extra care for assistive technology, and the WAI-ARIA specification asks authors to set aria-rowcount and aria-rowindex whenever only part of the table is in the page.

Tables on tablets and phones

The people who live in B2B tables are often away from a desk. A warehouse lead checks stock from a tablet, and a sales rep looks up an account on a phone in a client’s car park. Each of them needs one smaller job done well, and a twelve-column table squeezed onto a small screen gets in the way of it.

On a phone I design the task first, then decide how much of the table it needs. Short records become cards that show three or four fields, with the rest one tap away. Long work lists keep a table that scrolls sideways with the identifier frozen. The most common job often gets a screen of its own. goodport on mobile carries the buyer’s jobs, the dashboard, the catalogue and quotes to accept, and leaves the admin tables to the desktop.

Test it with a production export

A table designed around a dozen tidy rows breaks on the first real account. Before I sign off a layout, I ask for an anonymised export of real data and look for the longest customer name, the order with the most lines, the oldest record and the status nobody mentioned in the brief. Those rows set the column widths, the truncation rules and the empty states.

Then I measure the jobs the table exists for. How long does it take to find a given order? How many clicks does the most common bulk action take? How often does someone leave for the spreadsheet? When I build the front end as well, the export goes straight into the working prototype, so real names decide the widths.

Frequently asked questions

What is data table UX design?

It is the design of screens where people read, compare and act on many records at once. It covers what a row is, which columns show and in what order, density, search, filters, sorting, selection, bulk actions, editing and loading. In B2B software those screens carry most of the daily work, so they decide whether the product gets used.

How many columns should a B2B data table show?

As many as the most common decision needs. On my projects that usually lands between five and eight at default width. Let people show, hide and reorder the rest, and save the choice to their account, so the few columns that matter stay in view.

Should a data table use pagination or infinite scroll?

For work queues, one scrolling list up to a few hundred rows and pagination beyond that. Infinite scroll suits feeds people browse. B2B tables get worked through and shared, and both of those need a stable position.

How do you make a data table accessible?

Use real table markup with header cells, put aria-sort on the sorted column, keep checkboxes and row menus at least 24 by 24 CSS pixels, and pair every colour with text. Tables that render only some rows also need aria-rowcount and aria-rowindex, so assistive technology knows the full size.

How should a data table work on mobile?

Start from the task. Cards suit short records, a sideways-scrolling table with a frozen identifier suits long work lists, and the most common job often deserves a screen of its own.

What does it cost to redesign a data-heavy screen?

In my pricing, one workflow or dashboard runs $2,000 to $4,000, and a product surface with several roles runs $4,000 to $5,000. The number moves with how many roles share the table and how many states a row can be in. The full breakdown is in what a dashboard redesign costs.

If your team lives in a table

I design dashboards and internal tools for B2B teams in the US, Australia and Asia, and build the front end when a team needs it. The tables are usually where the work goes, as goodport, Roadcase and Fathom show. Send me a screenshot of the table your team exports from most, and I will tell you where I would start. See how I work.