Unlimited Design & Technology

User Experience

Make tables useful without relying on horizontal scrolling

A useful business table keeps identity, comparison, and action within reach. Choose a task-specific column set, preserve header relationships, and provide detail views instead of making every decision depend on horizontal scrolling.

UDT InsightsJul 8, 2026
A colleague rearranges a wide table into compact rows while a pin marks retained context. A seated operator uses a laptop.

A table can contain every available field and still fail the user who needs to make one decision. Horizontal scrolling may separate a record name from its status or hide the action needed next. Before debating column widths, agree what users compare and what they do with the comparison. A reporting export and an operational queue rarely need the same default view.

Select columns from the decision

Ask users to describe the next action after reading a row. For a renewal queue, identity, renewal status, owner, and an approaching deadline may matter more than every stored address field. Keep secondary information in a reachable detail view or a deliberate column choice.

Avoid removing context just to fit more values. An amount without a currency, or a status without the record it describes, can become ambiguous. If users choose columns, decide which identifying fields remain visible and whether the application remembers their selection.

Preserve meaning beyond visual alignment

WAI explains that accessible tables need markup identifying headers, data cells, and their relationships.[6] A visual arrangement of boxes does not supply those relationships by itself. Review the implemented table with assistive technology rather than assuming that a bold top row creates the required meaning.

WAI reflow guidance recognizes exceptions for content, including data tables, that requires two-dimensional layout.[5] That exception does not make unnecessary scrolling a good product decision. Recommend reducing the default columns and keeping any required horizontal movement inside the table region, with surrounding instructions still readable.

Hypothetical example: a subscription renewal queue

A hypothetical account coordinator reviews subscriptions approaching renewal. The first design includes technical metadata, several contact fields, and billing notes in every row. The renewal status appears far from the account name. The coordinator must repeatedly scroll sideways to establish which action belongs to which subscription.

A proposed task view keeps the account, renewal deadline, status, and next action together. Opening a row reveals contacts and notes. A separate comparison view retains additional columns for analysts who genuinely need them. This is a design scenario, not evidence of a measured reduction in handling time.

Check the tradeoff between overview and detail

A compact view adds detail-opening steps, while a dense view increases scanning demands. Test both with realistic long names, missing values, and mixed statuses. If column hiding makes important exceptions invisible, revise the default rather than expecting everyone to customize it.

Agree how sorting, filtering, selection, and detail navigation preserve context. These decisions deserve acceptance criteria alongside appearance. Passing a layout checklist alone does not establish formal accessibility compliance.

  • Define the decision and select essential columns for it.
  • Keep row identity clear beside status and actions.
  • Verify header relationships in the implemented table.
  • Test long values and zoom without losing surrounding controls.
  • Provide reachable detail for information omitted from the default view.

References

Discuss your next project

Talk with UDT about your needs and the next practical step.

Contact UDT
Zalo