Every number has one footnote, three surfaces, and two tests
How WhatsWrapped keeps every statistic explainable with one shared note, three UI surfaces, and two build-breaking tests.
The constraint that shapes the whole pattern
The design choice is narrower than “add help text to statistics.” WhatsWrapped gives every non-obvious number a tappable (i) that explains what is counted, what is excluded, and why. That matters because the same explanation has to survive three different places: the screen, the printed recap, and the data sheet that sits behind the numbers. The copy lives in one file, so the app is not maintaining three slightly different truths.
This is a useful constraint because it forces the UI to behave like a documentation system, not a collection of badges. A reader can tap the number in place, see the explanation immediately, and move on without opening a separate help page. Builders get something else from the same rule: one copy source means one editorial decision, one review pass, and one place to update when a metric definition changes.
The article is not about generic “tooltips as nice UX.” It is about a checkable promise. If a number ships, it must have an explainer trigger. If the explanation changes, every surface changes together. That is the real product decision, because inconsistent definitions are worse than no definition at all. A metric can be visually small and still carry a lot of interpretive weight.
That is also why this pattern fits analytics-heavy products better than decorative footnotes do. The point is not to annotate prose after the fact. The point is to make each statistic self-defending at the moment a reader asks, “What exactly am I looking at?” The answer is always the same words, regardless of whether the user is on a phone, a printed page, or a supporting data view.
How one explainer becomes three UI surfaces
On screen, the explainer appears as a tappable (i). That keeps the statistic compact while still making its meaning available at the exact point of doubt. The interaction is intentional: the number stays visible, the explanation stays attached to it, and the user does not have to guess whether the caveat lives in some other panel. The (i) is not decoration, it is the contract that the number is defined.
In print, the same popover cannot exist, so the design converts it into numbered footnotes within the relevant section. That translation preserves the relationship between number and explanation without pretending the medium can support hover or tap. The reader gets a familiar printed footnote structure, but the underlying words are still the same copy used in the product. The surface changes, the definition does not.
The third surface is the data sheet. This matters because a chart or statistic often needs to be checked by someone who is not reading the polished recap. By keeping the explanation text centralized, the sheet can use the same language as the user-facing screen and the printed notes. The result is less editorial drift and fewer cases where the sheet says one thing and the UI quietly implies another.
That three-surface setup is what makes the system feel deliberate rather than improvised. A designer can treat the (i), the printed note, and the data sheet entry as different renderings of one canonical explanation. That is more disciplined than duplicating help copy wherever it is needed, and it scales better when a new statistic is added or an existing one needs a wording fix.
Why the print version behaves differently
Print changes the rules because it removes interaction. A popover depends on touch or hover, but paper only gives order and layout. So the design does the obvious thing and makes each explainer into a numbered footnote per section. That keeps the statistic readable in context, while also making the note easy to locate without jumping to some separate reference block far away from the number.
The important part is not the numbering itself. It is the decision to keep each explainer attached to the section that needs it. A reader does not have to scan an entire document for a generic note index. The section boundary becomes the organizing principle, which is exactly what you want when the explanation belongs to a specific group of metrics rather than to the whole product.
This also keeps the printed version honest about what it can and cannot do. There is no fake interactivity, no attempt to imply that the paper is behaving like the app. The footnote format makes the limitation visible. The same words still answer the same question, but the medium gets a layout that respects its own constraints instead of borrowing UI metaphors it cannot support.
For builders, this is the practical lesson: a good cross-medium explainer does not try to be identical in appearance. It tries to be identical in meaning. The screen uses a trigger. The page uses a numbered note. The copy file stays shared. That combination is what keeps the product from fragmenting into three separate editorial systems.
The tests are part of the product, not just the codebase
The clever part of the implementation is that the wiring is guarded by tests, not by hope. One test fails the build if a metric ships without an explainer trigger. Another test fails if a trigger is left out of its section’s footnote list. Those two checks cover both sides of the promise: a statistic cannot appear without a definition, and a definition cannot exist without being linked into the right section.
That matters because documentation bugs are usually silent. A missing note does not crash the app, and a broken reference can survive review if nobody clicks the right number. By turning the presence of the trigger and the completeness of the footnote list into build-breaking conditions, WhatsWrapped makes explanation coverage as enforceable as any other required field.
This is the kind of guardrail that only looks small from the outside. Internally, it changes how a metric is added. You are not just deciding the formula or label. You are also deciding where the explanation lives, whether it appears in the right footnote set, and whether the shared copy file includes the text that both the UI and print output will use. The workflow becomes harder to misuse.
The test design also reveals the product’s philosophy. The goal is not to let every statistic stand alone and then tidy up later. The goal is to make definition-bearing UI impossible to forget. If a number is important enough to show, it is important enough to explain, and important enough to fail the build when that explanation is missing.
Why this is better than scattered help text
Scattered help text creates a familiar problem. The screen says one thing, the print layout trims it, and the supporting sheet drifts into its own phrasing. Over time, the product accumulates near-duplicates that are technically related but not actually the same. That is how teams end up with explanation debt, where every small wording change becomes a manual audit across several places.
A single explainer file avoids that drift because it treats the definition as shared content rather than an implementation detail. The product can render it in different ways, but the meaning stays locked. That is especially valuable for non-obvious numbers, since those are exactly the ones most likely to trigger follow-up questions about counting rules, exclusions, or edge cases.
The pattern also supports trust without overexplaining everything. Not every number needs a paragraph, and not every statistic deserves a full methodological note. The rule is narrower: if the number is non-obvious, it gets a tappable explanation. That keeps the interface quiet where it can be quiet, and explicit where ambiguity would otherwise lead to guesswork.
For readers, the benefit is immediate. They can inspect the number at the moment it matters, then keep moving. For builders, the benefit is structural. One explanation, three renderings, two tests, and no room for a metric to slip out undocumented. That is a more durable design decision than any single tooltip style, because it treats explanation as part of the data product itself.
The real design decision is about ownership
The deepest choice here is not visual. It is about ownership of meaning. When a statistic is displayed, the product also owns the obligation to define it, keep it consistent, and prove that the definition is connected everywhere it should be. WhatsWrapped encodes that obligation in the UI, in print, and in automated tests, which makes the rule visible to the team and invisible to the user.
That is why the system feels more like a publishing workflow than a cosmetic layer. The explainer copy is authored once, reused everywhere, and checked by the build. The statistic is never left alone with its own ambiguity. If it needs interpretation, the interpretation travels with it, and if that interpretation breaks, the release stops until it is fixed.
For anyone building products with numbers in them, the lesson is straightforward. Treat explanation as a required artifact, not a nice-to-have note. Put it beside the number in the interface, convert it properly when the medium changes, and automate the checks so the rule holds when nobody is looking. That is how a small (i) becomes a serious design system.
The result is not just cleaner UI. It is a more defensible product. Every number is answerable. Every answer is shared. Every rendering is linked back to the same words. And because the build refuses to ship a number without its explainer, the promise is not aspirational. It is enforced.
Frequently asked questions
Because the copy lives in one file, so the popover text and printed footnotes stay identical across surfaces.+
Why does the same explanation appear in both the app and the printed version?
It becomes a numbered footnote within its section, since a hover or tap popover cannot exist in print.+
What happens to a popover on paper?
One test fails if a metric has no explainer trigger, and another fails if a trigger is missing from its section footnote list.+
How does the build catch missing explanations?
Only non-obvious numbers get a tappable (i) that explains what is counted, what is excluded, and why.+
Is every number in WhatsWrapped treated this way?