The Grid You Inherited

The twelve-column grid is a genuinely good default. Twelve divides by two, three, four and six, which covers most of the arrangements a page needs, and it has the enormous practical virtue of being what everyone else is using. None of that makes it a design decision. It makes it a convention that we have collectively stopped noticing we are following.

The trouble shows up when the content has a natural rhythm that twelve cannot express. A catalogue of five product families. A comparison of seven regions. A table with an awkward number of measured columns. In each case the twelve-column grid forces a choice between an uneven arrangement that looks accidental and a re-grouping of the content that serves the grid rather than the reader. Designers almost always choose the second, and almost never say out loud that they have edited the meaning to fit the furniture.

Deriving the grid from the content is not complicated. Count the things. Look at what they divide by. Look at the longest and shortest item and at how many words the caption needs. Then choose a column count that fits those numbers rather than one that fits the framework. A seven-column grid is not exotic; it is simply what a page of seven regions wants.

The cost is real, and it is engineering rather than design. A bespoke column count means bespoke breakpoints, and it means every developer who touches the project afterwards has to learn a system rather than recognise one. On a long-lived product with many hands that cost is usually not worth paying. On a book, a report, a campaign or anything with a fixed and finished extent, it almost always is.

The rule we use now: if the thing will be edited by strangers for years, take the convention and spend your attention elsewhere. If the thing is finished when we finish it, count the content and let it choose. Most of the arguments about grids are actually arguments about which of those two situations you are in, conducted without either party naming it.