Comparison tables: when they help and how to design them

A comparison table helps when someone needs to choose among a few similar offers and weigh several attributes at once. It fails with a large catalog, a cheap item or options people can take together. In those cases, a filter or a plain list works better. Nielsen Norman Group, NN/g, recommends the table for small sets, usually up to five items, and a filter to cut a large set down before any comparison.

What the table is

A comparison table puts each offer in a column and each attribute in a row. Readers can cross price, limits, features and constraints without opening several pages. NN/g treats that layout as the standard: columns for products or plans, rows for characteristics.

It works for products, services, pricing packages, membership levels and feature bundles. It isn’t only a storefront tool. The same article lists pricing packages and membership levels as typical cases.

When it helps

The table serves compensatory decisions: people accept a loss on one attribute if they gain on another. NN/g places that mode when only a few alternatives remain, usually under five to seven. A slightly heavier laptop can win if the battery lasts much longer.

Before that, people often cut the set with a hard rule: max price, size or brand. That’s noncompensatory decision making. Filters and faceted navigation cover that step (NN/g, filters vs. facets). The table comes after, once the list is already short.

When it gets in the way

NN/g lists cases where the table is unnecessary:

the options aren’t mutually exclusive (two shirts can both go in the cart);
the item is simple and the choice is mostly aesthetic;
the item is cheap or easy to replace;
the offers are too unique to share the same attributes.

In those cases, forcing a comparison adds noise. Nobody needs six rows to pick a mug.

Static or dynamic

There are two types. A static table ships with the offers the site picked. It works well with up to five options, like three pricing tiers. A dynamic table lets people mark what to compare. It fits a larger catalog, after filtering (NN/g).

On phones, the same article notes that you rarely fit more than two columns. Sometimes the table turns into tabs. Side-by-side comparison disappears, and short-term memory pays the cost.

What to make explicit

The most common failure isn’t the layout. It’s the content. Missing attributes, vague labels or differences buried in prose. NN/g on explicit differences asks for two things: highlight what actually changes, and highlight what matters for the decision.

If only three attributes separate the plans, those three rise to the top. If many change, the copy marks the few that decide. Generic yes/no cells without context hurt. Numbers, limits and short units scan better.

Price belongs on that list. On B2B sites, NN/g treats price as the most requested piece of information. People who can’t find it go to a competitor. When the exact figure can’t be published, the common-scenarios article recommends representative examples instead of a heavy calculator.

How to build it

The practices in the comparison-tables guide boil down to this:

Cap the columns. Up to five in a static table. In a dynamic one, state the limit and let people remove items.
Stay consistent. The same attribute shows up in every column, with the same unit.
Help scanning. Short text, steady alignment, clear row separation. Avoid paragraphs inside cells.
Stick the header. On long attribute lists, the offer name stays visible while scrolling.
Translate the technical. Capacity in mAh becomes “phone charges” when the audience isn’t specialist.
Give control. A “differences only” switch or collapsible rows eases a long table.

In my own product

At Vexor, my own AI product for customer service on WhatsApp, the site publishes three pricing tiers side by side. The assistant is the same across all three. What changes is capacity: conversations per month, the daily ceiling and how many numbers are included. The monthly fee sits on the page, with the offer in structured data. On the annual plan, with 12 months paid upfront, the monthly fee drops 20% and there’s no setup fee.

That’s the terrain of a static pricing-package table: few columns, the deciding attribute named and the price in view. Readers compare volume against monthly fee without opening three pages. The case doesn’t claim a measured conversion. It only describes what the page shows.

Where the sources diverge

Filters and tables don’t compete for the same moment. Filters and facets cut a large set. The comparison table weighs what’s left. Swapping one for the other too early or too late is a timing mistake.

There’s tension on price too. Showing the price pushes for transparency. Common scenarios accept samples when the exact figure isn’t workable. Both agree that hiding everything pushes people away.

The common mistake

The most frequent slip is dumping the whole catalog into a table and calling that help. With ten columns, people stop comparing and go looking for a filter that isn’t there. Another slip is repeating the same value in different wording in each column, as if it were a distinction. The table only helps when the work of crossing attributes is already done in the content.