In a design system, why does a layout grid's column count usually change with window size, and why are 12 columns so common?

## Why the count changes A column is only useful if it is wide enough to be meaningful. Take a phone window 360 units wide with 16-unit margins and 16-unit gutters: | Columns | Space left for columns | Each column | |---|---|---| | 12 | 328 - 11 x 16 = 152 | about 12.7 | | 4 | 328 - 3 x 16 = 280 | 70 | Twelve columns of under 13 units are useless, and the gutters would take more space than the columns. Four columns of 70 still let components span one, two or four. As the window grows, more columns become useful, so the count rises. ## Common counts and why | Window range | Common count | Why | |---|---|---| | Phone | 4 | wide enough columns; halves and quarters still possible | | Tablet | 8 | doubles the phone grid, so phone spans map cleanly | | Desktop | 12 | the most divisible small number | | Very wide or dense tools | 12, 16 or 24 | finer placement for dashboards and data views | These are **conventions**, not rules any standard sets. They are popular because each step doubles or divides neatly, which makes it easy to reason about spans moving between sizes. ## Why twelve Twelve is divisible by 1, 2, 3, 4, 6 and 12, so a page can be split into: - halves (6 + 6), - thirds (4 + 4 + 4), - quarters (3 + 3 + 3 + 3), - sixths (2 each), - uneven but whole splits such as 8 + 4 or 9 + 3. Ten columns, by contrast, cannot make thirds; sixteen cannot make thirds either. Twelve covers the most common layouts with a small number of columns. ## Spans per size Components do not have one span; they have a **span per window range**. In an applicant-tracking tool: 1. A **candidate card** spans 4 of 4 on a phone (one per row), 4 of 8 on a tablet (two per row), 3 of 12 on a desktop (four per row). 2. The **filter panel** spans the full width on a phone, where it becomes a sheet or a collapsible section, and 3 of 12 on a desktop. 3. The **candidate detail** spans 4 of 4, 8 of 8, and 9 of 12 beside the filter panel. Documenting spans per size in the component or layout spec means every team builds the same layout at every width. The doubling convention pays off here. Because 8 is twice 4, a component spanning 2 of 4 on a phone can span 4 of 8 on a tablet and keep the same proportion of the width. Moving from 8 to 12 is not a clean doubling, so spans there are usually chosen afresh: a half becomes 6 of 12, a quarter 3 of 12, and a third, which the 8-column grid cannot express, becomes available as 4 of 12. That is one reason desktop layouts often introduce three-column arrangements that tablets never show. ## The narrowest layout and Reflow At the narrowest widths, most layouts collapse to a single column so content reads top to bottom. That is also what WCAG 2.2 Success Criterion **1.4.10 Reflow** (Level AA) needs: content must work without scrolling in two dimensions at a width equivalent to 320 reference pixels for vertically scrolling content. The criterion excepts parts that need two-dimensional layout to be understood, such as a data table, which may scroll sideways inside its own region while the rest of the page reflows. The narrowest grid configuration is therefore not just a phone layout; it is also the layout people get when they zoom a desktop window far in. ## What to document - The column count, gutter and margin for each window range. - How spans map between ranges, especially where the count doubles. - Which regions may collapse, stack, or become sheets at small sizes. - Where the ranges start and stop, which is decided in the breakpoint strategy rather than in the grid itself. One warning: a count that differs between design files and code breaks every span, so the numbers belong in one shared place, such as layout tokens or a single grid definition both sides read.