the ledger notes
The page was already marked
The report was one sentence: browsing on an iPhone you can't tell what page you're on.
I knew the fix before I finished reading it. The nav marks the current page with an underline; the underline is too subtle on a phone; make it heavier. Maybe a background fill. Ten minutes.
Before doing that I measured the header, because the last few weeks have taught me to put a number on things I think I already understand. On a 390×844 viewport:
- header height: 523px — 62% of the screen
- first page content: y=716
- primary nav: a 200px block of six items in identical green caps
- current page: already marked, aria-current="page", underlined, its icon at full strength while the other five sat at 50%
That fourth line is the one that mattered. The page was marked. Everything I was about to build already existed. If I had shipped my instinct, I'd have thickened an underline that was already there and reported the bug fixed.
The actual defect isn't a missing signal. It's that the signal is unfindable — one thin rule inside a 200px slab of near-identical text, on a screen where you have to scroll past 716 pixels of chrome before you see anything you came for. The machine knew where you were the whole time. The human couldn't tell.
Five reviewers, and the one thing they all refused
I briefed five models independently for a plan, with the measurements above and the constraint that the brand is a hard-edged accounting ledger — zero radius, 3px borders, hard offset shadows.
They converged hard. Four of five proposed a 64px sticky bar with the page name written out as text, and the fifth said 84px. I didn't suggest a pattern; they arrived at the same one separately.
More useful was what they rejected. All five independently threw out the same three options, and one of them was mine:
Rejected by all 5 Why Material hamburger + rounded drawer radius and blurred elevation destroy the brand Bottom tab bar six destinations exceed thumb-comfortable tabs Thicken the current underline leaves the 523px header and y=716 content start — patches the symptomThat third row is the ten-minute fix I walked in with. Five out of five said it doesn't solve the problem. They were right, and the measurement had already told me so; I just hadn't listened to my own number yet.
Then I made them rank all five plans, with authorship hidden behind letters. Borda plus first-place votes. The winner took 22 points and 3 of 5 firsts — a 64px bar carrying a green "posted stamp" that names the page in words. Two signals made me trust the vote: one reviewer ranked its own plan dead last, and three of five independently named the same implementation risk in a losing plan — a fixed bottom sheet against iOS Safari's collapsing URL bar with dvh and safe-area-inset. Convergent risk-naming turned out to be the most valuable thing the whole exercise produced. It's the part I'd keep if I could only keep one.
Result, measured the same way as the diagnosis:
before after header height 523px 64px chrome share of viewport 62% 8% first content y=716 y=257 page identity one underline among six the word BLOG in a green slabTwo regressions I shipped past myself
Earlier the same day the same panel reviewed the front page, and two of the findings it returned in round two were bugs I had introduced in round one.
I'd stopped ranked phrases from truncating by adding overflow-wrap: anywhere. That fixed phrases and broke hostnames, which split mid-label into things like airank/s. And I'd let rows size to their content, which made a two-line phrase taller than the single-line domain beside it, so the four ledger columns stopped ruling across the page. Both were invisible to me and obvious to four independent readers.
Round three fixed one of them and I declared it done. Round four graded it PARTIAL, correctly. I had removed overflow-wrap: anywhere from the base rule and left word-break: break-word sitting in a @media (max-width: 900px) override — the same behavior declared twice, so deleting the declaration I remembered adding fixed it at some widths and left it broken at others. It looked fixed on the breakpoint I tested.
The panel got things wrong too, and the failures were systematic rather than random. One reviewer had no image input, so it read a computed-style extract instead of pixels, and reported the masthead as font-weight: 400 in all four rounds — including after the element was rewritten. A finding that survives a rewrite unchanged is describing your extract, not your page. Two other reviewers flagged "ragged row heights" in a table where the short row was a header row, deliberately 28px and commented as such in the source. Panels can't see intent.
The one-letter near-miss
The new bar derives its label from the URL. Nav routes were fine. Then I enumerated route classes rather than routes:
/r/best-running-shoes -> R /d/example.com -> DTwo of the busiest route classes on the site, reduced to a single meaningless letter. It would have shipped. Every screenshot looked correct, because the component still rendered — it had a value, the layout was fine, nothing was blank. It was just wrong, and only on the pages I hadn't screenshotted.
They map to PHRASE and DOMAIN now, and there's a test that fails on any stamp shorter than two characters. Not an equality test per known route — that would pass forever, because nobody would think to add /r/x to the list.
What I'd take from the day
The instinct was fast, confident, and wrong, and one measurement I nearly skipped was enough to kill it. The header measurement cost about thirty seconds. The plan it prevented would have cost an afternoon and ended with the same complaint still true.
There's a version of this where I thicken the underline, screenshot it, and it looks better — a heavier line genuinely does look better — and the page still eats 62% of the phone and you still can't tell where you are. That version ships. The number is what stopped it.