U2.16.1Tables for exact valuesdesignresearch

Tables beat charts when exact values are needed

Aliases: exact value lookup · table readout

What it is

"What was East region's figure this month?" — when the task's deliverable is a specific number, the table is the shortest path: row and column headers address a cell, and the digits hand over the answer with no precision loss and no conversion. A chart's answer is always one layer away: the position must first be converted back to a value (against the axis, interpolated against gridlines), and error comes with it. For lookup, reconciliation, audit, and report citation tasks, a table is not "a plainer chart" but the correct medium; forcing such needs into charts drives readers to smother the chart in data labels — which is really a table in disguise.

Why it happens

Table lookup is symbolic addressing: dimension values (row and column headers) reach the cell by text match, and what is read is the true value itself. Chart lookup is an inverse mapping: reconstructing the value from mark position, with precision bounded by tick density, gridline spacing, and noise in position perception — even though position along a common scale is the most accurate of the visual channels, "most accurate channel" is not "accurate." Data labels can patch in-chart readout, but a fully labelled chart ruins shape reading and still cannot hold hundreds of rows — evidence that chart structure itself does not fit bulk value retrieval.

Studying it

The cognitive fit tradition (Vessey) systematically compared tables against graphs across task types: value-retrieval (symbolic) tasks match tabular format and relational (spatial) tasks match graphical format, with speed and accuracy both degrading under format-task mismatch — not a ranking of media but task determining medium. The paradigm transfers to any concrete setting: render the same data as table and chart, time task-stratified readers, count errors, and a significant format × task interaction confirms the match effect.

Where it stops holding

This leaf rules only on "retrieve a number" tasks; trends, comparisons, and anomaly discovery go to the group's chart side. Mixed tasks (mostly trend-watching with occasional lookups) take sparkline tables or a chart with a side table, not a forced either-or. Lookup over huge tables (thousands of rows) is done through search and filter interaction — the analytical-interaction family's territory, outside the static table's boundary.

Applying it

  • At requirements review, ask what the deliverable is: "numbers or conclusions?" Value tasks (reconciliation, citation, audit) go straight to a table, no chart.
  • In-chart data labels are garnish only (a few peaks and latest values); readout at scale returns to tables.
  • Verification: have readers retrieve the same value from chart and from table; markedly faster and more accurate table retrieval confirms the ruling.

Related

  • Same group: U2.16.2 Charts beat tables for discovering patterns and comparing trends · U2.16.3 With little data and few dimensions, tables are denser · U2.16.4 Sparklines in tables serve readout and trend at once · U2.16.5 Row ordering does the same work as category ordering in charts
  • Nearby: U2.15.5 Small multiples compare shapes, not precise values · U2.01.2 Define the question before choosing the chart
  • Search terms: table lookup · exact value · cognitive fit · tabular format

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/U2.16.1