In a design system, why should a team needing a denser data-usage table apply the compact density mode rather than override padding locally?

## The situation A product team working on a telecom self-service app wants the monthly data-usage table to show more rows per screen for customers who manage many lines. Two routes exist: switch that surface to the design system's **compact density mode**, or open the component and override its padding and row height locally. The first is almost always right, and the reasons are what the question tests. ## What the compact mode gives you A **density mode** is a coordinated set of sizing values (padding, gaps, row height, control height) that the design system defines once and swaps as a unit. Choosing it means: - **Consistency across components.** The table's rows, the filter field above it and the pagination buttons below tighten together, so they still share one rhythm. - **Floors already checked.** The system team designed compact so each pointer target still meets WCAG 2.2 criterion **2.5.8 Target Size (Minimum)**, level AA (24 by 24 CSS pixels or enough spacing), text stays legible and focus indicators are not clipped. A local override inherits none of that verification. - **Fixes on upgrade.** When the system retunes compact, say a new row height or a fix for a clipped focus ring, every surface using the mode gets it with the next system upgrade. A local override freezes the old numbers. - **One vocabulary.** Designers, engineers and reviewers can say the usage table is compact and all mean the same values, on the web and on native mobile. ## What a local override does instead | Concern | Compact density mode | Local padding override | |---|---|---| | Consistency | whole surface tightens together | one component differs from its neighbours | | Accessibility floors | designed and tested by the system | unknown until someone audits it | | System upgrades | receives fixes | may break or silently lose the override | | Review cost | nothing new to review | a one-off every reviewer must reason about | | Signal to the system team | visible as mode usage | invisible, so the gap is never fixed | Overrides are also where **drift** starts: the next team copies the override, and a year later the product has three compact tables with three row heights and no one knows which is correct. ## How to apply it correctly 1. Find the system's documented way to set density for a screen or region, and apply compact to the table's surface as a whole rather than cell by cell. 2. Read the guidance on where compact is intended: typically data-heavy views used repeatedly by experienced users, less often first-run or one-off flows. 3. Review the result on the smallest supported screen and with an enlarged text size, because density and user text size interact. 4. If compact still does not fit, raise it with the system team. A missing density step, or a component that ignores the mode, is a system gap that other teams probably share. ## When compact is not the answer Density only changes spacing. If the table is hard to scan because it has twelve columns, denser rows make it worse, not better. Sometimes the right fix is to drop or collapse columns, add a per-line summary, or let customers filter to one line. A strong answer notices that density is one tool, not the goal. ## Why interviewers ask this The question checks whether a candidate uses a design system as a system: preferring its modes, variants and documented options over local styling, and understanding that the system's value is that its decisions, including its accessibility decisions, travel with its parts. It also checks the instinct to report a gap upstream rather than silently patch around it, which is how a system improves for every consuming team.