Skip to content
All posts
6 minTypographyUI Design

Seven Typography Rules That Change When You Design for Screens

Typography is the skill graphic designers are most confident bringing into UI work, and the one that breaks first. Seven rules that work differently once text becomes an interface.

The confidence is not misplaced. If you have set type for print you understand hierarchy, rhythm, contrast and restraint, and those instincts are real. But print typography is set once, at a known size, on a surface that does not move. Interface typography is set once and then rendered at a hundred sizes, on screens you have never seen, holding text you did not write. The craft transfers. The rules do not, because on screens the text is not yours.

Here are seven that change.

1. Size has a floor, not just a taste

In print you can set 8pt body copy and it will be fine, because paper is held at a predictable distance and the ink is not made of light. On screens, small text is a usability decision rather than an aesthetic one.

Browsers default body text to 16px, and that is a sensible floor for anything a user has to actually read. There is also a hard practical edge: on iOS, Safari zooms the page when a user focuses a form input whose text is smaller than 16px. Set your inputs at 14px and every login screen jolts sideways when someone taps the email field.

Small type in print reads as refined. Small type in UI reads as an oversight.

2. Line length is measured in characters

The old typographic guidance holds, somewhere between 45 and 75 characters per line, with 66 as the comfortable middle. What changes is that in print you enforce it with a column, and in UI nothing enforces it at all.

Put a paragraph in a container with no maximum width and on a wide monitor it will run to 150 characters. The reader's eye has to travel back across the full width to find the start of the next line, and it will land on the wrong one. That is not a subtle degradation. People stop reading.

Constrain your text containers. A max-width is a typographic decision.

3. Line height moves inversely to size

Body text needs air: around 1.5 times the font size. Large headlines need much less, closer to 1.1 or 1.2, because the gaps between lines scale with the type and a headline set at 1.5 falls apart into unrelated stripes.

In print you set leading once per block and you are done. In UI your headline is 48px on desktop and 28px on mobile, and if line height is locked to a fixed pixel value rather than a ratio, one of those two will be wrong. Set line height as a unitless multiplier so it scales with the type.

4. Contrast is a number you can fail

This is the one that catches people hardest. Light grey text on white is a legitimate print move which reads as quiet and expensive. In UI it is a measurable accessibility failure.

The WCAG AA standard asks for a contrast ratio of at least 4.5:1 between text and its background. Large text gets a lower bar of 3:1, where large means 18pt and up, or 14pt and up if bold. Interface components and meaningful graphics also need 3:1.

You do not have to eyeball this. Figma plugins and browser dev tools will both give you the ratio directly. The point is that "it looks fine on my monitor" stopped being an argument. It is a number, and you either pass it or you do not.

Placeholder text is where this fails most often. It is grey by convention, and by convention it fails.

5. A type scale replaces the font-size field

In print, every piece is bespoke. You choose the size that works for that poster and you never need it again.

In UI, arbitrary sizes multiply. Pick 19px here because it looked right, 21px on the next screen, 20px on the one after, and within a month you have forty type sizes across the product, none of them intentional, all of them now somebody's job to maintain.

Define a scale, five to seven sizes, from caption to display and treat anything outside it as a decision that needs justifying. The constraint is what produces consistency. You are not designing a screen, you are designing a system that will generate screens you never see.

6. Your typeface has to survive every state

Before committing to a typeface, check that it has:

  • A real weight range. You need at least regular, medium and bold to build hierarchy without resorting to size alone.
  • Legible numerals, ideally tabular. Any table or price column will misalign without them.
  • Distinct letterforms. Capital I, lowercase l and the numeral 1 should not be identical. Neither should O and 0.
  • The characters your users need. If you are designing for West Africa, French-speaking users are a click away. Check the diacritics before you commit, not after.

Aesthetics get you to the shortlist. These questions decide it.

7. Text is a component, not a layer

This is the underlying shift, and the rest follow from it.

In print, text is fixed. You set it, you look at it, and what you see is what ships. In UI, text is supplied at runtime by people who are not you. It wraps. It truncates. It arrives in a language 30% longer than English. The product name you designed around is eight characters in the mockup and forty-two in production.

So design the states, not the specimen. What happens when this heading runs to three lines? When this label is empty? When someone's full name does not fit the card? If your design only works with the copy you chose, it does not work.


None of this makes print typography wrong. It makes it insufficient. The eye you built setting type on paper is genuinely the hard part to learn, and most people entering UI design do not have it.

What you are adding is a second question. Not just does this read well, but does this still read well when it is half this size, twice this long, in someone else's language, on a screen I have never seen.

Get that question into your process and the rest is craft you already have.