My secret formula for designing a typographic system for web
Typography Nerds of the interweb, I’m going to reveal my secret formula for how I designed a harmonious, yet kickass typographic system to use in our webapp at Firefly Learning. I used a mathematical scale as the inspiration for defining the type sizes and line heights, reducing the number of type sizes in the app from about a bazillion to just seven.
A bazillion styles you say…?
We’ve tended to choose type styles on a project by project basis which, whilst they aren’t a million miles from each other, has meant that all screens have a slightly different flavour.
When we come to work on new screens we found ourselves questioning, “which convention should I follow, the sub-header on this screen, or that screen?” “The labels like this, or like that?”
We have a strong design system and pattern library, that incorporates colour, components and page layout and accessibility, so now seemed like a good time to support this with a formalised type system.
Our vision
- We want a defined hierarchy of type styles, with the flexibility to grow and adapt if necessary.
- We want it to be easy to use by designers as we develop new screens and make improvements to old ones.
- We want it to be easy for front-end developers to implement it into the pattern library.
Let’s get this typography party started!
Any typographic system I come up with needs to fit well into the design system we already have. So I began by taking an audit of all the type styles we’re already using.
This gave me insight into the most common type sizes we are using, the sizes at the extreme ends we would need to cater for, what sort of visual hierarchy was needed, and where sizes tended to cluster together.
I noted down these sizes so that they would be easy to reference as I explored the options.
Modular scales
I wanted the type sizes to be chosen purposely and look harmonious together, therefore I looked into mathematical patterns I could use that so that all sizes would all have a common relationship with one another.
Modular scales have been popular in classic typography for a long time–they feature in Robert Bringhurst’s typography bible, The Elements of Typographic Style, and have become especially popular in web design recently with the ease of building them into front end pattern libraries.
Show me the numbers
Our audit revealed that 16px was by far the most popular type size. Like an unwritten rule, we had used it for most body text, labels throughout the app. As this is very legible, I wanted to stick to using 16px as our main size. I established this as the base size, which I could experiment with and apply different ratios to calculate the rest of the scale.
Our audit also showed that we used a lot of type sizes around 12 pt, 14pt, 18pt, 21pt, 24pt, 28pt, 32pt, therefore a scale would need to give us numbers within this range.
To achieve our vision, I needed to simplify this set down, so that there would be fewer type sizes so close together and the hierarchy would be clearer. I was on the lookout for a scale that would produce numbers within this range, but with fewer intervals.
The pure ratio method
I used this tool to quickly produce some scales to test out. Here are some of my experiments:
8:9 (you can calculate this by multiplying the base number by 1.125) gives us an almost identical palette of numbers as listed above. This would give us a lot of choices and would probably result in our design choices being as muddy as before.
5:8 ( multiply by 1.6) produces a nice clear hierarchy but has too few intervals, and with the interval below the base being a type size of10px, would mean that legibility would be compromised.
I tried a few more out (2:3, 5:6, 3:4) and none of them was quite right.
4:5 (1.25) however, produced a really promising set of numbers. The numbers were very close to the set listed above, but with fewer intervals. I figured there was a good chance the type size options with this ratio would work for us.
The downside is that a ratio like this doesn’t produce very memorable numbers, some numbers aren’t even whole. Whilst the pattern is pleasing, these numbers are forgettable, will make our working Sketch files messy, and ultimately fails point number 2 of our vision: We want it to be easy to use by designers.
I wondered whether I should scrap looking for a mathematical scale altogether and just come up with a set of nice round, whole numbers that would be easy to remember. But that didn’t sit well with me. I wanted the numbers to feel more purposeful and have a genuine relationship.
I decided to try a hybrid solution.
The hybrid method
The base number we naturally chose, sweet 16px, is a nice pleasant number. It’s even, it’s a multiple of 4 and pretty easy to remember.
I wondered what would happen if we rounded the numbers of the 4:5 ratio to the nearest multiple of 4.
12, 16, 20, 24, 32
I really like this selection. It covers the range of type sizes we need, it gives us the flexibility to choose depending on the need of the text, whilst retaining a really clear hierarchy.
The other designer in the team felt more content working with these numbers, and the front-end developer was happy to deviate from a pure ratio approach.
The real test would be to try it out on some of our screens. I focused on our most important screens in the product and produced mockups of the existing content with the text replaced in the new style. It looked great. The difference to individual screens was hardly noticeable, but when looking at the mockups together, it all looked more coherent and rhythmic.
Reading between the lines
The line height of type is closely related to the size of the type itself, and I wanted to define this at the same time.
Generally, the line height is a touch larger than the type size, which gives breathing space that helps legibility. I wanted to reinforce the relationship between the type sizes here too, so chose to use the same hybrid ratio, but for each type size, I applied the interval that’s one higher than the line height.
So for type size 16, the line height is 20. For type size 20, the line height is 24, for type size 32, the line height is 40.
There is one exception.
When testing these line heights out in the mockups I found that body text needed a more spacious line height than when it was used as a label.
Labels tend to be one line and short, but sometimes the text overflows and the text wraps. In this scenario it helps if the words remain fairly close together as it shows that the words are related to one another.
Body paragraphs tend to be longer blocks of text. You can use a larger line height to help the eye run along the line of text and avoid having the eye accidentally jumping between lines.
Therefore I decided to split the type styles out into Label and Body Text. Both have a type size of 16px, but Label has a line height of 20, and Body Paragraph has a line height of 24.
Mobile
There is one other tweak I made to the system.
When testing out the mobile I wondered if the headers needed to be so large. It makes sense on the desktop, there’s a lot of information competing for attention so the large sizes support the hierarchy. But much less information is visible at one time on mobile. I wondered if the scale needed to be so extreme?
I tried a scale with a smaller multiplying factor. The 8:9 ratio (where the base is multiplied by 1.125) looked promising here. The numbers close to the body text size of 16pt wouldn’t be affected when you round to the nearest multiple of 4, but the numbers at the far end would scale a bit less, which would result in a more balanced looking layout on mobile screens.
What next?
We’re pretty happy with the typography system we’ve developed. The next step is to start applying it as we design for new projects. We may find we need to make tweaks as we go, but that’s ok. We aim to minimise the number of exceptions to the rule, so that means if we want to add another type style in future, then we need to consider it in the context of the system as a whole.
We keep our system on Zeplin so that it’s easy for designers and front-end developers to refer to.
This project went on to form the basis of our spacing system, which gives the designers and the front end developers guidelines for how to add spacing around the elements on the page. That’s a separate project, and worthy of its own blog post, so I won’t describe it here. But essentially, we picked a base size of 16px again and used a multiplier to define the different options for spacing, just like we did for the type sizes.
It’s great to have a system that can evolve, be built on, and influence future solutions. If you’re working with a design system yourself, you’ll recognise the beauty when there’s a close relationship between all the visual elements.
