Why a table stops being true when it is read as text

A table is compression. Every cell is shorthand for a whole sentence, and the sentence is assembled from three places: the row label on the left, the column heading at the top, and the value in the middle. The reader does the assembly without noticing, dozens of times, in a few seconds.

That is why tables are good. Written out longhand, a delivery table becomes forty repetitive sentences that nobody would read, and the version in a grid is scannable and comparable. The compression is the point, and the argument here is not that you should stop using them.

The argument is that the compression only decompresses in a human head. A cell on its own means nothing at all. The number forty is not an answer to anything. It becomes an answer only in combination with two labels that sit somewhere else on the page, and every failure below is a version of those labels going missing.

Anything reading your page as text produces a sequence, and a grid has no natural sequence. The usual result is row by row, left to right, which puts the column headings once at the beginning and then never again. By the time the sequence reaches the fortieth row, the words that give those values meaning are thousands of characters behind.

Then the passage gets cut. Whatever length the chunks are, the cut will fall somewhere, and the odds that it falls exactly where the header row sits are small. Most passages taken from a long table contain values and row labels and no column headings whatsoever.

Several common table habits make this worse in specific ways. Units written once in the heading and not in the cells. Merged cells, which either repeat or vanish depending on the reader. Blank cells that mean the same as the row above, or mean not applicable, or mean nobody filled it in, with no way to tell which. And footnote markers, which are the purest form of the problem, since the marker survives and the footnote it points at is somewhere else entirely.

Price grids are usually two dimensional: plans across the top and features down the side, or products down the side and quantity bands across the top, or terms across the top and tiers down the side. The information is in the intersection and nowhere else.

The characteristic failure is not a made up number. It is a genuine number from your own table, attached to the wrong column. A monthly figure quoted as an annual one. The volume price quoted to somebody buying one. The rate for the tier above the one they asked about. Every one of those appears on your page, which means the answer survives a quick check by anybody who glances at the grid, and only fails when somebody tries to pay.

This is also the case where the visitor cannot detect the error. A person asking a price has no independent knowledge of what it should be. They take the figure, plan around it, and discover the problem at the point of purchase, which is the most expensive place in the whole journey to discover anything.

Size charts are long, narrow and repetitive: one row per size, several columns of measurements, and often two measurement systems side by side. The rows all look alike, which is precisely why a passage taken from the middle of one is so hard to place.

Two failures dominate. The first is units. When the system is named once in the heading and the cells carry bare numbers, a retrieved passage has values with no scale attached, and where two systems sit side by side there is nothing in the passage to say which column was which. The second is subtler and more common than it should be: whether the numbers describe the garment or the person wearing it. That distinction usually lives in a caption sentence above the table, which is exactly the sentence that does not travel with the rows.

The consequence is a returned item rather than an argument, which makes it easy to underestimate. It is still a delivery paid twice, a restocking cost, and a customer who now believes your sizing cannot be trusted, which is the sort of belief that ends a repeat purchase.

A zone matrix has places down the side and service levels across the top, with times or prices in the cells and, almost always, exceptions underneath. Islands, remote areas, oversized items, hazardous goods, addresses that are technically in the zone and practically not.

The exceptions are the whole risk. They are set below the table in smaller type, they are attached by a marker, and they are the part a customer needs most, because a person checking a delivery matrix is usually checking it precisely because they suspect they are an edge case. Separated from its footnote, the cell states a next day service to an address that has never had one.

There is a second failure here that the other two do not have, which is absence. A place that is not listed usually means a place you do not serve, and that fact is expressed by an empty space on a page. Nothing can retrieve an empty space. Unless the words are written somewhere, a question about an unlisted town has no matching passage at all, and the reply will be built from the nearest thing available, which is the row for somewhere else.

The fix is to state, in ordinary sentences, what the grid encodes, and to put those sentences on the same page. Each sentence has to be complete on its own: the row label, the column label, the value, the unit, and any exception that applies to it. Standard delivery to the mainland takes three working days and costs the standard rate. Next day delivery is not available to the islands.

For a large grid, do not write a sentence per cell. Write the boundaries and the common cases, which is what people actually ask about, and then write the rule if there is one. Most grids are generated by a rule that somebody knows and nobody published, and one sentence stating the rule is worth thirty stating its outputs. Where there is no rule and the values are genuinely arbitrary, cover the rows people ask about and say plainly where to look for the rest.

Then write the absences. If you do not deliver somewhere, say the words. If a size is not made, say so. Anything currently expressed by a gap in a grid needs a sentence, because a gap is the one thing that cannot be found.

The instinct after all this is to replace the grid with prose, and it is wrong. A person comparing four options wants a grid, and forty sentences is a worse page for them by a wide margin. You are not choosing between the two; you are adding the second one underneath the first.

Put the sentences below the table under a plain heading, or fold them into the surrounding copy where the page allows it. Yes, it is duplication on the page, and it is the same trade as writing out a fact that only exists in an image. The cost is a slightly longer page. The benefit is that your most precise figures become quotable rather than guessable.

This also pays back for readers who are not using their eyes to read the page at all, and for anyone on a narrow screen where a wide grid becomes a horizontal scroll. None of this is a concession to machines. It is what a well made table page looked like before anybody thought about retrieval.

First, caption it properly. Directly above the grid, write one sentence saying what it covers, what the units are, what date it takes effect from, and what an unlisted entry means. That sentence is short, it sits close enough to the table to be pulled with it, and it carries most of the context that the rows are missing.

Second, remove the tricks. No merged cells. No blank cells: write the value, or write not available, or write the same as above spelled out. No footnote markers pointing off to a note elsewhere on the page, because the marker travels and the note does not; put the exception in the cell or in the row's own sentence. Repeat the unit in every cell where the table is short enough to allow it.

Both of these make the table better for a person skimming it on a phone, which is a useful test for whether a rule of this kind is worth following. If a change only helps retrieval and makes the page worse for readers, it is usually the wrong change. These make the page better in both directions.