How many type sizes does one interface actually need?

Most interfaces need only a small set of type sizes, each tied to a real role, and the practical ceiling is roughly four to six: something like display, heading, body, and caption, with a secondary heading and perhaps a small label rounding it out. The count follows the number of distinct jobs the type has to do, not a desire for visual variety. An interface bloats past that point the moment sizes start multiplying because a particular screen looked a little flat and a designer reached for a new size to spice it up. When that happens you no longer have a scale; you have a pile of nearly-equal sizes that no one can apply consistently.

The principle underneath is that a size should exist because a role exists. Body text is a role. Section headings are a role. Captions and metadata are a role. Each of those has a clear job and a clear place in the hierarchy, so each earns a size. What does not earn a size is “this paragraph felt like it wanted to be a touch bigger,” because that impulse produces sizes defined by mood rather than function, and mood is not repeatable. The next designer, or the same designer next week, will not know whether a given line is supposed to be the seventeen-pixel size or the eighteen-pixel size, since neither maps to a role, and the system quietly decays into inconsistency.

Picture a design system with a clean scale of five sizes mapped to display, heading, subheading, body, and caption. A new feature ships and someone needs a “slightly emphasized intro paragraph,” so they add a sixth size between heading and body. A month later another team needs an “eyebrow label” and adds a seventh, just under caption. Now a component library has seven sizes, two of which differ from their neighbors by a hair, and across the product the same kind of content shows up at three different sizes because nobody could tell which of the near-twins to pick. The interface did not gain expressiveness; it lost the ability to be applied the same way twice. The intro paragraph never needed a new size, it needed the body size with a weight or color change, and the eyebrow needed the existing caption in uppercase.

The case worth naming is that a complex product can legitimately need more than six, and that is fine when each addition still answers to a role. A data-dense application might genuinely require a distinct size for table cells separate from prose body, or a marketing surface might need an oversized hero display above the normal display size. The test never changes: name the role the new size serves, and if you cannot name one that the existing sizes do not already cover, the size is variety in disguise. More sizes than roles is the failure; more roles, honestly counted, is just a bigger product.

So build the scale from roles, not from a feeling that a screen needs more variation. List the distinct jobs your type actually performs, assign one size to each, and when you are tempted to add another, force yourself to name the new role first. If the answer is a role the scale already covers, reach for weight, color, spacing, or case to create the emphasis instead of minting a near-duplicate size that will erode the system’s consistency.