Typography

For a long time, text on a product screen was not something anyone designed. Copy got written, someone pasted it in, and the size and line spacing came from whatever the tool happened to default to. So the values drifted. Body text was 14 pixels on one screen and 15 on the next, headings came in at 18, 20 and 22, and nobody had written down which was correct. A different person built each screen and there was no shared reference, so the drift was the predictable outcome rather than anyone's mistake.

The scattered numbers were less damaging than the missing vocabulary. What people actually said in a design review was that a screen "felt cramped." The only way to act on that was to read it as a size complaint, so the text went up a step, and larger text meant fewer characters per line, and fewer characters per line meant longer paragraphs, which felt cramped again. The real cause was usually that the lines sat too close together vertically, but no one in the room had a name for the distance between two lines, so nobody could point at it.

Without names, fixes didn't survive either. A screen that got tuned well once left no record of what made it work, so the next person started from scratch. The list screen ended up with a 20-pixel bold heading while the detail screen used 18-pixel regular, and users who could never articulate the difference still came away feeling the two screens belonged to different products. Engineering had a matching version of the problem. Every screen carried its numbers inline, so changing the body size meant opening dozens of files, which meant it usually didn't get changed.

Typography is the name for treating all of that as one connected set of decisions and giving each value inside it a label. Cramped becomes line height. Headings that don't read as headings become weight and a size step. A screen that only looks wrong on Windows becomes a fallback problem. Once the labels exist, the same conversation ends with "let's take line height to 1.6." Visual design keeps seven elements that build hierarchy, and since nearly everything a product screen communicates arrives as text, this is the element that carries the most of that work.

The terms under typography fall into two groups. Five are properties — the values a designer picks in a mockup. Two are implementation — the machinery that gets those values onto a real user's screen. Designers own the first group and engineers own the second, but skip the second and the values only hold on the machine they were drawn on.

The five properties are what you choose in the file. None of them is independent; move one and the others shift underneath it.

1. Typeface — the design that defines what the letters look like. Picking one looks like a matter of taste, but in a product the first filter is legibility. Can you tell a zero from a capital O, a lowercase l from the digit 1? In anything that displays payment amounts or verification codes, that single distinction moves support ticket volume. Korean typefaces carry a much larger character set than Latin ones, so half-finished families are common and rare characters can break, which is why teams test a candidate with real names and street addresses before committing.
2. Font weight — how thick the strokes are. The usual scale runs from 100 to 900 in nine steps, but a product realistically uses three or four: 400 for body, 600 for subheads, 700 for emphasis, and nothing else. Put 400 next to 500 and the one-step gap doesn't register, so the bold text stops reading as bold. Go the other way, below 300, and the strokes that looked elegant in the mockup disappear into the background on a phone outdoors.
3. Type scale — the fixed ladder of sizes running from body copy up to page titles. Six rungs is typical, something like 12, 14, 16, 20, 24 and 32, and new screens pick from the ladder rather than inventing values. Keep a consistent ratio between rungs and any two of them read as different when placed side by side. Someone will eventually need a 13 or a 15, and granting that once tends to mean four different body sizes six months later.
4. Line height — the vertical distance between lines. Body text usually lands between 1.5 and 1.7 times the font size, so 16-pixel text gets 24 to 27 pixels. Set the same paragraph at 16 and the lines press together into a wall; push past 2.0 and they drift apart until the paragraph stops reading as one block. Headings follow a different rule. Give a 32-pixel heading the same 1.6 and a two-line title goes slack in the middle. Bigger type takes a smaller multiplier.
5. Letter spacing — the distance between individual characters. Large headings usually need a small negative adjustment because the default spacing looks loose at that size, and small uppercase labels need the opposite. Body text is left alone by default, and reaching for this control there is normally a sign that the typeface or the size is the actual problem. Korean characters each fill a square box, so values carried over from Latin settings tend to look far too open.

The two implementation terms move those values to the user's device. Neither one shows up in a mockup, which is why problems here surface late.

1. Font fallback — the ordered list of substitutes to use when the specified typeface isn't available. If the font isn't installed and the download fails, the browser walks down the list. Leave the list empty and it drops to a browser default, which in Korean means a serif face nobody chose, and a layout that looked fine on a Mac gains a line on Windows. Different faces occupy different widths at the same size, so a wider substitute turns a two-line heading into three, and a table that fit in one row starts wrapping. The list is worth writing deliberately rather than copying from an old project, since the next name on it is what a large share of users actually see during the first second of every page load. Latin and Korean fallbacks get declared separately for the same reason.
2. Variable font — a single file that can be adjusted continuously across weight and width. Using 400, 600 and 700 used to mean three downloads and three delays before the first screen painted. A variable font generates everything in between from one file, so there is one download instead of three, and values off the ladder like 450 become available. The tradeoff is that the single file is larger than any one static weight, so a product using only two weights comes out behind. It also opens a door worth watching: because any value between the ends is now reachable, a team without a written ladder will drift back into using whatever number looked right that day.

The two groups run in one direction. Properties set the values, implementation delivers them, and what arrives builds visual hierarchy — the order in which a screen gets read, which on most screens is expressed through differences in text size and weight. To avoid re-deciding all of it per screen, the sizes, weights and line heights get bundled and named, and once that bundle lives in the design system a new screen stops choosing values and starts retrieving them.

"Body line height is 1.3, so the paragraph reads as a wall. Let's take it to 1.6."

Leave the size alone and open up the vertical space between lines.

"This label is the only 13 in the file and 13 isn't on the scale. Make it 12 or 14."

A value from outside the agreed ladder got in and should be pulled back.

"The fallback resolves to a different face on Windows and the heading picked up an extra line."

The specified typeface wasn't on the device, and the substitute changed the layout.

At Pagedeck the term first got real attention when Noa audited every screen. Body copy was running at 13, 14, 15 and 16, and headings came in seven sizes. Theo checked the code and found copies of the same component carrying slightly different numbers on each screen. Nobody had done it on purpose — each value was typed in under deadline and then stayed, and every later screen copied whichever version happened to be nearest.

Noa built a six-rung ladder, kept 12, 14, 16, 20, 24 and 32, and moved everything else to the nearest rung. Mia asked whether dropping 15 to 14 would make that information look less important, and Noa's answer was that widening the gap between body and heading inside one screen makes the body easier to read, not harder. The slow part of the work wasn't picking numbers. It was asking, for each place using 15 pixels, why it had to be 15. Most of the time there was no reason. In the two cases where there was one, the real issue turned out to be the spacing beside the text rather than the text itself.

What changed afterward went past the screens. The recurring conversation about sizes stopped happening on new work, and an experiment like bumping body text one rung became a single value to change and check everywhere at once.

The most common mistake is reading typography as typeface selection. It's the most visible of the seven decisions and the typeface name is the kind of thing that goes in a brand document, so the shorthand sticks. What actually determines whether text is comfortable to read is mostly size, line height and line length. Swap the typeface and leave the rest, and the screen barely moves — sometimes it gets worse, because the same pixel size renders visibly larger or smaller depending on the face. When a team spends two months on a typeface change and user response doesn't shift, this is usually where it went. Reversing the order works better: fix size and line height first, see the difference without touching the typeface, and then change the face, so you can tell which change did what.

Assuming that bigger text is easier to read is the other one. It's the fastest available response to "I can't read this," so it comes out reflexively. But line length grows along with size, and past a point that makes reading worse. Korean body text is comfortable at roughly 30 to 40 characters per line; run 16-pixel text across the full width of a 1440-pixel window and a line carries more than 100. Long lines cost you the return sweep — the eye travels back from the right edge and lands on the wrong line, so the same line gets read twice. The control to reach for isn't size, it's the maximum width of the column the text sits in. Cap the reading column around 680 pixels and the same size becomes easier to read. Leave the width alone and keep granting size increases and the request returns every quarter, until half the information that used to fit on a screen is gone and someone finally looks at the width.