Two weights, two sizes

Count the distinct font weights on your busiest screen. Then count the sizes.

Most codebases come back with five or six of each, and none of them was chosen. They accumulated: 500 because a component library shipped it, 300 because somebody thought a caption should look lighter, 600 and 700 both present because two people solved the same problem in different weeks.

There is a specific technical reason this got worse. CSS Fonts Level 4 defines font-weight as any number from 1 to 1000, with names mapped at each hundred, from Thin at 100 to Black at 900. With variable fonts, every one of those is free. No extra file, no extra request. The constraint that used to force a decision is gone, and nothing replaced it.

The subtraction

Colour is already doing most of your hierarchy work, and the previous chapters settled that. This one is about what is left, and the answer is: much less than you are currently using.

Two weights. One for normal text, one for emphasis. In practice 400 to 500 and 600 to 700.

Two sizes per component. One for the content, one for its label or metadata.

Everything else, every additional shade of importance you need, comes from colour you have already chosen, not from a new weight or a new step on the type scale.

The move

Two font weights and two font sizes per component. Anything you still need after that comes from colour, not from another value.

Where the outline overstates it, and where light weights actually hurt

The usual ranking is colour first, weight second, size last. That is a good rule for signalling importance without shouting, and it is Refactoring UI’s, so it is craft rather than measurement.

The independent research does not rank the dials that way, and it is worth knowing the difference. Size is the weakest lever on perceived importance and the strongest on legibility, which are different jobs. Do not shrink something to demote it if people still have to read it.

Where the evidence is unambiguous is at the light end. An eye-tracking study of light and ultra-light fonts concluded that “light and ultra-light fonts are less legible than their regular and bold counterparts” across two text variations. That is not a taste objection to font-weight: 300. It is a measured cost, and it lands on exactly the users least able to absorb it.

So the two weights you pick should both be at or above normal. The lighter one is 400, not 300.

BEFORE                            AFTER

font-weight: 300   caption        400   body, captions, labels
             400   body           600   headings, emphasis, the
             500   nav item             one thing per card that
             600   card title           matters
             700   page heading
             800   the CTA        14px  labels and metadata
                                  16px  content
11px  timestamp
13px  label                       everything else is colour:
14px  body                          #111 primary
15px  nav                           #555 secondary
18px  card title                    #888 tertiary
24px  page title
                                  two weights. two sizes per
six weights, six sizes,           component. three greys, already
none of them decided              chosen in move 16.

The floor nobody documents

There is one hard limit worth knowing, and it lives in a browser’s source rather than in a spec.

WebKit on iOS decides whether to zoom into a focused input by comparing its font size against a built-in standard. Set the text smaller than that threshold and the page zooms when a user taps the field, which is the origin of the notorious iOS form-zoom behaviour that teams usually fix by disabling zoom entirely.

Which is the wrong fix, because disabling zoom breaks it for anyone who needs to magnify. The right fix is to not go below 16px on inputs. That is not a design preference. It is the number that keeps a browser from taking over your layout.

What it costs

Two weights is genuinely restrictive on marketing surfaces. A landing page with one heading weight can look flat, and that is a real limitation rather than a discipline you should force. This rule is for product interfaces, where repetition across hundreds of screens is what makes consistency legible. Say which side of the line you are on before applying it.

And “two sizes per component” has no source. I could not find one, in Refactoring UI or anywhere else, so treat it as my working rule rather than received practice. What is defensible is the underlying point: every additional size is a claim that a new level of hierarchy exists, and most interfaces have three levels and eight sizes.

Try this week

Grep your stylesheet for font-weight and font-size and count the distinct values.

Then delete. Map every weight onto your two, and every size onto the smallest set that still lets each component distinguish its content from its labels. Most teams land at two weights and four sizes total across the whole product, not per component.

The screens will look flatter for about a day, until you notice that the hierarchy is still entirely legible, because it was being carried by colour the whole time.

And check your inputs for anything under 16px while you are in there. That one is not aesthetic.