Why we went with a 16-point grid system
While both articles are great and I agree with what both are saying, there’s one main reason why my team and I chose to go with 16 as our starting point instead of 8; default font-size on the web. Our team is primarily working on responsive web apps and since we can set our base <html> font-size to 16, we can then use a base of 1rem to size everything in the app.
- Font sizes
- Line heights
- Fixed heights (rarely used)
We’re using multiples of 16 to get fine-grain control and have ended up with sizes that look like this:
- xs = 4pt (0.25rem)
- s = 8pt (0.5rem)
- m = 16pt (1rem)
- l = 32pt (2rem)
- xl = 48pt (3rem)
- xxl = 64pt (4rem)
In principle, using multiples of 16 is really the same as using multiples of 8, but I find that a baseline of 16 is more visually noticeable than a baseline of 8.
By having 16 as our default, I know that if something were to get built–without a lot of input from the Design team–using default sizes for padding, margins, etc. there should be the minimum amount of white-space around and inside each element. If 8 were the default, I’d be worried that a developer or junior designer could easily justify a design with too little white-space by stating that it adheres to the default grid.
Our typography also uses multiples of 16 for line-heights (with 16 being the smallest). Unfortunately this means that baselines for different sized type do not line up. We’re OK with this for now, because it means that everything still lines up at the block level. So, for example, things like page titles and buttons can be paired well together. We’ll see if we change our mind on this in the future.
I think that if/when we start to work more on native mobile apps, we may find that a baseline of 8 could make sense on those platforms. For example, in Material Design components use an 8pt baseline grid and type uses a 4pt baseline grid (this is the same as what Bryn is doing).
What do you think? I’m definitely interested in what other teams are doing!