Skip to content

Feature List

A Feature List presents key product attributes or technical details as a run of scannable label / data pairs — the specification block on a product page, the service features of a plan, the rows of a comparison table.

  • CSS

Maintained by Platform

Usable — may still change

DesignCSSAccessibility

The Feature List is a compact component that presents key product attributes or technical details in a structured, scannable way. It breaks complex information into digestible chunks, keeps dense product contexts readable, and lets people compare several items quickly. Reach for it on product pages, in comparison tables, summaries, and specification sections — anywhere a run of short attributes needs to be skimmed rather than read.

Anatomy

Section titled “Anatomy”

  • Fuel consumption

    43.4 - 45.5 (l/100 km)

  • Boot capacity

    580 LITRES

  1. Feature list
  2. Item
  3. Label
  4. Data
  5. Info button

The Feature list is the container that sets the rhythm between rows. Each Item is one attribute, stacking a Label — the muted line that names the attribute — above the Data, the emphasised line that carries the value. An optional Info button can trail either line where the attribute needs a word of explanation; here it sits on the value.

When to use it

Section titled “When to use it”

Use a Feature List when:

  • You are highlighting several product features that sit at equal hierarchy.
  • People benefit from quick scanning rather than deep reading.
  • You are presenting technical or semi-technical attributes.

Typical use cases are product specifications (battery, size, material), service features (delivery time, warranty, coverage), and plan comparisons (pricing tiers, included features).

Avoid a Feature List when:

  • The content needs long-form explanation or narrative — use body copy instead.
  • The content is highly visual, where icons or images carry the meaning better.
  • A single attribute stands alone, with nothing to scan against.

Properties

Section titled “Properties”

Label

The muted upper line that names the attribute — “Fuel consumption”, “Boot capacity”. It is deliberately quieter than the value so the eye lands on the data first when skimming a column of rows. Keep it short enough to stay on one line.

Data

The emphasised lower line carrying the value itself. This is the line people scan for, so it takes the heavier weight and the stronger foreground colour. Include the unit here rather than in the label.

Info button

An optional icon-only affordance that trails a line where the attribute needs clarifying — a measurement standard, a caveat, a footnote. Either line can carry one, independently, and an item is perfectly complete without any. Use it sparingly: an info button on every row is noise rather than help.

Size

Two sizes are available. The larger size gives the label a bigger, more prominent setting and opens up the space between rows, suiting a standalone specification block. The smaller size tightens both, suiting a dense column or a card. It is the label and the spacing that carry the change; the value’s own typography is set per size and per brand, so check it against the brand you are designing for.

Platform considerations

Section titled “Platform considerations”

Desktop

There is room for the larger size, and for two or three lists to sit side by side as columns of a comparison. Keep the labels short enough that each pair stays on two lines, so the rows align across columns.

Tablet

The same layout holds, with fewer columns side by side. Watch the longest label as the column narrows — a label that wraps to two lines breaks the alignment with a neighbouring list.

Mobile

Lists stack rather than sit side by side, and the smaller size usually reads better in the narrower measure. Let long values wrap rather than truncate — a clipped specification is worse than a taller row.

Best practices

Section titled “Best practices”

A Feature List earns its place when every row is the same kind of fact, phrased the same way, so the column can be scanned rather than read.

Do

Keep every row to the same shape — one attribute, one value — and phrase the labels consistently. Put the unit with the value. Order the rows by what matters most to the reader. Keep the list to a scannable length, and let long values wrap.

Don't

Don’t mix attributes with sentences, or let one row carry a paragraph. Don’t lean on the label and data colours alone to carry the hierarchy — the wording has to work in isolation too. Don’t attach an info button to every row, and don’t truncate a value that a reader needs in full.

Content guidelines

Section titled “Content guidelines”

Write labels as short noun phrases in sentence case, and keep them parallel across the list — “Boot capacity”, “Fuel consumption”, “Warranty”, not a mix of nouns and questions. Put the value and its unit together on the data line so the pair reads as one fact. Where a value needs a qualifier — a test standard, a condition — put it behind the info button rather than lengthening the line. If an attribute genuinely needs a sentence to explain it, it belongs in body copy, not in the list.