A B2B table is not a set of database fields arranged into columns. It is a workbench where users locate exceptions, compare records, make decisions, and process items in bulk. More columns and features do not automatically improve efficiency.
A B2B table is not a set of database fields arranged into columns. It is a workbench where users locate exceptions, compare records, make decisions, and process items in bulk. More columns and features do not automatically improve efficiency.
01 Start With What Users Need to Accomplish
The same data can support very different tasks:
- Support needs to find a customer quickly and review recent issues;
- Finance needs to reconcile amounts, status, and dates;
- Operations needs to filter exceptions and process them in bulk;
- Managers need to compare trends and owner performance.
Putting every field in one table gives everyone a page with everything and nothing easy to find. Before designing, write the three most frequent tasks and identify which fields each task requires users to recognize, compare, filter, and act on.
02 Design Columns in Three Layers: Identity, Judgment, and Action
Identity Columns Answer “Who or What Is This?”
Usually placed on the left, these include name, ID, avatar, and entity type. The primary identity should link to details. Add secondary identifiers when needed to distinguish records with the same name.
Judgment Columns Help Users Decide Whether to Act
Status, amount, risk, update time, owner, and key outcomes belong here. Prioritize these columns and format them consistently for vertical scanning.
Action Columns Support the Next Step
Expose frequent row actions and place infrequent or high-risk ones in an overflow menu. Do not offer the same “View details” action as a button, name link, and full-row click; multiple redundant entries create uncertainty.
| Column Type | Design Guidance |
|---|---|
| Text | Preserve recognizable content and provide access to the full value when truncated |
| Number | Right-align and standardize units, decimal places, and thousands separators |
| Date and time | Define timezone and format; avoid only “yesterday” when auditability matters |
| Status | Lead with text; use color and icon as support, never color alone |
| Action | Keep placement stable and apply confirmation and authorization to high-risk actions |
03 Do Not Distribute Column Order and Width Evenly
The first viewport should preserve identity, primary judgment, and frequent actions. Reveal low-frequency fields through column settings, a details drawer, or expanded rows.
Follow these practices:
- Set minimum and maximum widths for text columns based on real content;
- Keep number, date, and status columns stable instead of letting content shift them dramatically;
- Pin key identity columns on the left and frequent actions on the right when helpful;
- Limit pinned columns or they will squeeze the browsable middle area;
- Shorten long headers first and put necessary explanations in help text.
04 Let Users Switch Information Density Instead of Imposing One Setting
Frequent operators may want more rows per screen, while occasional users need more explanation. Offer compact and standard density options, or set defaults by task.
Do not increase row height merely to add whitespace. A taller row earns its space when it carries secondary information, guidance, or multiple states. At any density, maintain a consistent rhythm between header and data rows.
05 Search, Filters, and Sorting Form One Retrieval System
Search Works for Known Targets
When users know a customer name, order number, or phone number, search is fastest. Explain its scope and handle no-result, spelling, and clearing states.
Filters Narrow the Set
Keep frequent filters visible and place complex conditions in a filter panel. Show applied conditions and let users remove one, clear all, and save common views.
Sorting Supports Priority Comparison
Enable sorting only for meaningful columns. Keep the active column and direction visible. Headers must be keyboard-operable and expose sort state to assistive technology.
A common failure occurs when users reach page five with several filters, open a detail view, and return to find all conditions lost. Preserve query state whenever possible, especially in a frequent-use workbench.
06 Selection and Batch Actions: Define the Scope First
After users select rows, state how many are selected, whether selection covers the current page or all results, and which actions are available. The batch-action bar should contain only actions relevant to the current selection.
A high-risk batch confirmation must restate the affected objects and impact. If some records are unauthorized or ineligible, explain this before execution rather than after the entire batch fails.
| Scenario | Recommended Presentation |
|---|---|
| Select all on current page | State “20 items selected on this page” |
| Select all across pages | Confirm “Select all 1,264 items matching current filters” |
| Some records are ineligible | Show executable count and reasons others cannot be processed |
| Asynchronous batch job | Provide progress, results, and failure details; allow users to leave the page |
07 Use Inline Editing Only for Short, Explicit Changes
Inline editing fits frequent fields such as status, owner, tags, and simple values. Changes involving multiple fields, complex validation, downstream effects, or explanation belong in a drawer or dedicated page.
Inline editing must define:
- How the user enters edit mode;
- Save, cancel, and keyboard behavior;
- Where validation errors appear;
- Whether failed saves preserve input;
- How concurrent changes are communicated;
- Whether users can undo or view history.
Do not make a cell look like static text until it suddenly becomes editable on hover. Editable state needs a persistent cue.
08 Status Cells Must Support Decisions, Not Just Look Good
Success, failure, and processing are only baseline states. Users need to know what happened, whether they must act, when the state changed, and what comes next.
Add cause, progress, or deadline near the status, but do not place an entire log in one cell. Complex information belongs in an accessible popover, expanded row, or detail panel that also works with keyboard and touch.
09 Design Six Nonideal States
Every table should cover at least:
1. First-use empty state: tell users how to begin;
2. No filter results: preserve conditions and offer a clear action;
3. Loading: keep structure stable so users do not mistake it for no data;
4. Load failure: explain whether retry is possible;
5. Partial data failure: identify the missing scope and update time;
6. Insufficient permission: explain current scope and the request path.
An empty-state illustration is not enough. The state must connect to the user's next task.
10 Pagination, Infinite Scroll, or Virtual Scrolling?
Pagination fits business tables that require stable location, return, and batch processing. Virtual scrolling fits continuous browsing at scale but must handle position restoration, selection, assistive technology, and export. Infinite scroll rarely fits precise administration.
Whatever the approach, backend queries, filters, and sorting must match interface rules. Sorting only loaded data in the frontend while implying the entire result set was sorted is a serious product defect.
11 Responsive and Accessible Does Not Mean “Just Scroll Sideways”
On narrow screens, first decide whether the task still belongs in a table. Preserve key columns and convert other information to detail cards where appropriate. For unavoidable horizontal browsing, maintain row and column relationships, pin identity, and make the scroll affordance clear.
For accessibility:
- Use correct table captions, headers, and structure;
- Make sortable headers keyboard-focusable and operable;
- Expose current sort direction to assistive technology;
- Give row controls clear names and a logical tab order;
- Do not rely on color alone for status, selection, or errors;
- With virtualization, communicate total rows and columns plus current position.
12 A Table Specification Ready for Delivery
| Item | What to Specify |
|---|---|
| Data object | What each row represents and its unique identifier |
| Core tasks | Find, compare, review, edit, batch process, or export |
| Default columns | Order, width, pinning, format, and truncation rules |
| Query capabilities | Search fields, filters, default sort, and saved views |
| Behavior | Row click, expansion, selection, batch, and single-row actions |
| Editing | Editable fields, validation, save, concurrency, and undo |
| States | Loading, empty, no results, failure, permissions, and asynchronous progress |
| Permissions | Data scope, action access, and hidden or disabled rules |
| Performance | Pagination, virtualization, maximum volume, and export strategy |
| Accessibility | Headers, keyboard, focus, sorting, and assistive-technology requirements |
Frequently Asked Questions
Are fewer columns always better?
No. Columns should serve tasks rather than minimalism. Show frequent fields by default, let users configure secondary fields, and avoid forcing repeated detail-page visits for simple comparison.
Should action buttons go on the left or right?
Either can follow established reading and selection patterns; stable position matters most. Identity and selection usually sit left, with frequent actions right. In horizontally scrolling tables, preserve record identity and action context.
Can we copy Excel interactions directly?
Only when users truly need spreadsheet-style editing and calculation. Ordinary business tables should not add hidden shortcuts, free-form cells, and complex selections merely to resemble Excel; these increase learning and implementation cost.
13 Put Research and Design Into Product Decisions
| Service | View |
|---|---|
| UI/UX design services | View service details |
| Project inquiry | Contact JVDS |
| Design and website articles | Read more related articles |
Link copied
