Lesson 20 of 30

Data-Dense UI & Table Design

Q: You're asked to design a table for an admin dashboard that logically has around twenty columns of data. Walk me through how you'd actually handle that.

A strong answer covers: Reason about zebra striping versus whitespace: striping helps track a row across many columns, and is unnecessary noise on narrow tables where line-height alone already does that job; Mention sticky headers for long scrolling tables, and that they need an explicit opaque background to avoid scrolled content bleeding through; Align columns by data type — numbers right-aligned (ideally with tabular-nums) for comparison, text left-aligned for reading; Use progressive disclosure (expandable rows or a details drawer) for secondary columns instead of cramming all twenty into view at once.

A table is the hardest case for the spacing lesson's reasoning, because density is often the whole point: an admin table wants many rows visible at once, which pulls directly against 'generous whitespace equals clarity.' A few specific tools resolve that tension without cramming.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A table with only two columns and generous line-height adds zebra striping, and it ends up looking noisier rather than clearer. Why?

Zebra striping's benefit is tracking a row across many columns — with only two columns, line-height alone already does that job, so the stripes just add noiseZebra striping is never appropriate for any table regardless of column countThe striping colors chosen must have been too similar to the text color, causing a contrast failure

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Data-Dense UI & Table Design

What interviewers actually ask about this, and what a strong answer has to cover.

You're asked to design a table for an admin dashboard that logically has around twenty columns of data. Walk me through how you'd actually handle that.

A strong answer covers

Reason about zebra striping versus whitespace: striping helps track a row across many columns, and is unnecessary noise on narrow tables where line-height alone already does that job
Mention sticky headers for long scrolling tables, and that they need an explicit opaque background to avoid scrolled content bleeding through
Align columns by data type — numbers right-aligned (ideally with tabular-nums) for comparison, text left-aligned for reading
Use progressive disclosure (expandable rows or a details drawer) for secondary columns instead of cramming all twenty into view at once

Likely follow-ups

How would you decide which of the twenty columns are 'core' and shown by default, versus hidden behind disclosure?
Does a dense admin table and a spacious marketing page conflict with using the same underlying spacing scale, or can both be valid defaults on it?

Practice these with the AI interviewer →

The plain-language idea

A data table is where the density conversation from the spacing lesson gets genuinely hard, because for a table, showing more rows at once is frequently the actual goal — a finance table or an admin list is more useful the more of it fits on screen without scrolling. That pulls directly against the instinct that generous whitespace always reads as clearer. A well-designed table resolves that tension with a few specific, learnable tools rather than by just shrinking padding until things fit.

Zebra striping — alternating row background color — helps a reader's eye track one row horizontally across many columns without spending any vertical space on it; it's separation bought without a space budget. But it isn't universally correct: on a narrow table with only two or three columns, generous line-height already does that job on its own, and adding stripes there is just visual noise competing with the data.

Sticky headers keep the column labels pinned to the top of the viewport while the body scrolls, so column meaning is never lost two hundred rows down — arguably more important on a data table than almost anywhere else, because a mislabeled cell in a dense grid is easy to misread with real consequences.

See it in a real thing: a table that leans on alignment and disclosure, not cramming

thead th {
  position: sticky;
  top: 0;
  background: var(--color-surface-raised); /* must be opaque, or scrolled rows show through behind it */
  z-index: 1;
}

td.numeric {
  text-align: right;
  font-variant-numeric: tabular-nums; /* fixed-width digits, so the ones place actually lines up down the column */
}

Column alignment by data type isn't just a stylistic habit — it's how quick comparison actually works. Numbers are right-aligned so the ones place lines up down the column, making $12.00 and $104.50 instantly comparable at a glance; text stays left-aligned, matching natural reading direction. font-variant-numeric: tabular-nums is the detail that makes right-alignment actually pay off — without it, proportional digit widths mean even right-aligned numbers don't line up column-wise, just row-by-row.

For anything wider than the viewport comfortably holds, progressive disclosure beats cramming every column in: show the handful of columns central to the table's primary task, and put the rest behind an expandable row (a chevron that reveals a details panel inline) or a side details drawer opened per-row. This is the same instinct the spacing lesson argued for applied to columns instead of gaps — a small, deliberate default with more available on demand, instead of trying to show everything at once.

What people usually miss

Watch out

A sticky header needs an opaque background, not just position: sticky. Without one, rows scrolling underneath visibly bleed through the header text — a real, easy-to-miss bug, the same category as this track's own earlier opacity-on-contrast bug.
Zebra striping should be low-contrast, not high. An overcorrected, too-dark stripe competes with the actual data for attention instead of quietly supporting the eye's row-tracking — the stripe should be barely perceptible on its own and only "work" in aggregate.
Right-aligning numbers without font-variant-numeric: tabular-nums doesn't fully deliver the payoff — proportional-width digits mean two right-aligned numbers can still fail to visually line up at the ones place, undercutting the whole reason to align them that way.
Which columns are "core" versus hidden-behind-disclosure should come from the table's primary task, not an arbitrary or alphabetical cut. A billing table's core columns look different from an inventory table's, even if both have the same total column count.
Density is a legitimate default for the right surface, not a compromise to feel bad about. The spacing lesson's own point applies here directly: a dense admin table and a spacious marketing page can both be correct defaults for their context, on the same underlying spacing scale.

Why this matters in interviews

"Design a table for a dashboard with twenty columns" is a synthesis question in the same family as the auditing lesson — it's testing whether a candidate can apply density reasoning to the hardest real case, naming specific tools (sticky headers, type-based alignment, progressive disclosure) instead of a vague "make it more compact."