Somebody told me the text in my articles did not feel right on a phone, and then, one message later, put their finger on it: the differences between the sizes were too small. They were right, and the interesting part is that nothing in the type scale was wrong. Every step was a considered value with a comment explaining it. The scale was fine. The article was not using it.
Here is what a reader actually got, measured on a phone at 390 pixels wide.
Title at 20. Section heading at 17. Standfirst at 16. Body at 14. Four roles inside four pixels, with a sub-heading the same size as the paragraph under it, and a title three pixels above a section break. On a desktop it was 24 / 20 / 17 / 15, which is not much better, but the eye forgives more when everything is larger.
Why this happens to fluid scales specifically
Almost every modern type scale is a set of clamp() steps: a size on a phone, a size on a desktop, and a smooth ramp between. It is a good technique and it has one failure mode that is easy to miss.
The ceilings get designed. Somebody sits with the desktop layout, picks 40 for the display size and 28 for a section heading and 15 for body, and it looks right, because that is the screen they were looking at. The floors get derived. They are usually chosen as "one rung down", or worse, by taking the desktop set and subtracting a few pixels from each.
Subtracting a constant from a set of sizes destroys the ratios. Going from 24 to 20 is a fifth off. Going from 15 to 14 is a fifteenth. Do that across a scale and the large steps compress hard while the small ones barely move, so the whole thing flattens as the screen narrows, which is exactly where you have the least room to signal hierarchy by any other means.
The fix at the token level is not clever: choose each floor against its neighbours rather than against its own ceiling. A sub-head that sits directly above the lede has to keep clearing it at 320 pixels, or it is not a sub-head there. Write that down as a test if your scale is big enough to warrant it.
The part that was actually my fault
In my case the tokens already did this properly. The floors were argued, the comments in the file said which value was chosen against which neighbour, and there was even a test holding the ordering.
The articles simply were not using them. The article title was set to the same token as a card title, on the reasoning that "the article sits in a card too". Section headings were on the sub-head step. Sub-heads were on the long-form body step. Every role was sitting one or two rungs below the one the design system had documented for it.
That is worth naming as its own failure, because it is invisible in both of the places you would look. Open the token file and the scale is well argued. Open the page and every individual element looks deliberate. The fault is in the mapping between them, and nothing renders a mapping.
The comment that justified the wrong one had been written in passing, in a bulk refactor, and it was not wrong so much as answering a different question. "The article sits in a card" is a fact about the container. It is not a reason for the page's own title to be the size of the things listed inside other cards.
Two wrong turns, both instructive
Fixing the headings left one pair still colliding: the standfirst and the first paragraph were the same size. The paragraph won, because it was eight lines long and the standfirst was three, and at equal size the longer block simply occupies more of the screen. Same size is not the same weight.
First wrong turn: I made the standfirst bigger. It worked, in the narrow sense that the summary then outranked the paragraph. It was solving the pair rather than asking whether the pair should exist.
Second wrong turn is the useful one. The person reading it came back with "isn't this too much layering?" and the fix was in their own next sentence: if the first paragraph is just body text, the subtitle does not need to be big either. Take the lede's special treatment away and the competition disappears, so the standfirst can go back down and simply be the one thing between the title and the prose.
The first paragraph had carried two different treatments over the course of an afternoon, a size step and then full-ink colour, both aimed at marking where the piece starts. The standfirst directly above it was already doing that. The answer was not to balance two introductions. It was to have one.
There is a comment where that rule used to be, saying so, because the alternative is that somebody adds it back next year for exactly the reason I added it the first time.
That comment is doing the same job a decision record does, one level down: it is not describing what the code does, it is preserving the argument so the next person cannot undo it by accident.
What I would check on any article layout
Four things, in the order they cost me time.
Measure the floors, not the ceilings. Open a phone width, read the computed sizes off the elements, and write them in a row. If four roles fit inside four pixels you have found it, and no amount of looking at the desktop will show it to you.
Check that each role uses the token that names it. If your system has a display step and your article title is on the card step, the mapping is the bug and the scale is innocent.
Count the introductions. A title, a standfirst and a specially treated first paragraph are three things doing one job before the article has started. Two is usually one too many.
Ask what the smallest step is separated by. If two roles are one pixel apart, they are being told apart by weight, family and colour, not by size. That can be fine. It is only fine on purpose.
None of this is difficult and none of it is visible from the place most of us do the work, which is a large screen with the design file open beside it. The measurement takes a minute. I had gone years without taking it.