The Statistics Are the Easy Part
Calculating another metric is usually straightforward. The harder product problem is deciding which story the evidence supports, how to tell it and how much detail a person needs.
A screen I can read too easily
At some point in my early teens, Football Manager taught me to look at a crowded screen of numbers and feel completely at home.
I could open a player profile, scan the attributes, form, history and comparisons, and begin assembling a view of the player almost immediately. The interface did not feel dense to me. The density was part of the pleasure.
A career in finance reinforced the habit. Spreadsheets, performance reports, ratios and variance tables became normal working material. Over time, you learn where to look. You develop a fairly high tolerance for information presented without much ceremony.
That fluency is useful. It is also a dangerous assumption to carry into a consumer product.
Most people do not open an app hoping to study a dashboard. They arrive with a question. They may want to know whether their sleep has improved, where their time went this week, or whether the way they speak with someone has changed. A table may contain the answer, but that does not mean the table has told them anything.
Generating the statistic is often the easy part. Helping a person understand what it means is where the difficult product work starts.
When analysis outgrows presentation
I have felt this problem sharply while building Mimoto.
The starting material is a message archive chosen by the person using the product. At a basic level, software can count messages, compare activity, calculate response patterns and arrange people into rankings. Those results can be useful, and the calculations are usually quite tractable.
As Mimoto has developed, the context it can derive has become richer. It can identify changes in questions, encouragement, shared links, response habits and other communication patterns that are difficult to see while living inside the conversation itself.
Every new result creates a second set of problems. Where should it appear? How important is it? Which period makes the comparison fair? What language should explain it? How can someone inspect the messages behind it? Is the result strong enough to show at all?
A result can be correct and still be presented in an unhelpful way.
“You exchanged 18,432 messages” is a valid statistic. The person may really be asking, “Has the way we talk to each other changed?” Moving from the first statement to a responsible answer to the second requires more than another calculation.
A chart cannot choose its own tone
This challenge is sometimes discussed as a user-interface problem: select the right metrics, choose the right graph and arrange the journey in a sensible order.
Those decisions matter, but the text matters just as much.
The words around a metric influence whether it feels descriptive, judgemental, celebratory, alarming or falsely certain. A 12% fall in a communication measure could be presented as an accusation, a warning or a neutral observation. The number has not changed. The experience of receiving it has.
With personal data, that distinction carries real weight. A sentence about a relationship lands differently from a line in a sales dashboard. “You ask fewer questions now” can sound like a verdict on someone’s character or level of care. “Questions appeared less often in this period” is narrower and leaves room for context. Even then, the product should show the period, evidence and limitations behind the observation.
Language is part of the analytical responsibility. Vocabulary, sentence complexity and tone need the same attention as the chart type. A general reader should be able to understand the result without being patronised, while a data-literate reader should be able to move past the summary and inspect the detail.
That balance is fiddly, and there is no universal setting called “clear”.
The archive determines the question
The available data also limits the story the product can reasonably tell.
Imagine two conversations. The first has run for more than ten years, contains over 100,000 messages and shows activity on almost every day. The second began two months ago and contains fewer than 200 messages.
Both may matter enormously to the person looking at them. They do not support the same analysis.
The long-running conversation can support questions about eras, persistent habits, changing rhythms and whether a pattern returned after disappearing. There is enough history to compare years, distinguish a temporary burst from a longer movement and explore how the relationship developed.
The newer conversation invites more modest questions. When do the participants tend to talk? Who usually starts the exchange? Which early patterns are visible? What might become more meaningful when more history exists? Trying to impose a ten-year narrative on two months of messages would manufacture confidence that the archive has not earned.
| Evidence shape | Questions worth exploring | Product posture |
|---|---|---|
| New or sparse | What is beginning to emerge? What simple activity patterns are visible? | Orientation, plain facts and explicit limits |
| Established but intermittent | How does the rhythm vary? Which active and quiet periods matter? | Period-aware comparisons with gaps clearly qualified |
| Long-running and dense | What changed, persisted or returned? How do different eras compare? | Longer narratives, trends and deeper drill-downs |
A single fixed report tends to serve neither case particularly well. It will overstate what a sparse archive can support and waste the depth of a mature one.
The context therefore needs to shape the journey: the questions offered, the confidence of the language, the comparisons selected and the amount of detail shown. Sometimes the most truthful result is simply that there is not enough history yet.
Start with the outcome and work backwards
The most useful way I have found to approach this is to begin a design review with two questions:
- What should this help the person understand?
- Does the available evidence allow the product to answer that responsibly?
Only then should the conversation move to charts, colours, metric order or final copy.
For a Mimoto result, the desired outcome might be understanding a change, revisiting the messages that shaped it, feeling reassured, deciding to begin a conversation, or simply noticing something without acting on it. The product does not need to prescribe a decision. It should make the pattern legible and let the person decide what it means in their life.
I tend to think about the presentation in layers:
- The main story the evidence can support.
- The context that qualifies the story.
- The examples or signals a person can inspect.
- The full data for deeper exploration.
The privacy boundary matters here too. Mimoto processes the chosen message archive on the person’s device. Private conversations do not need to be uploaded and turned into someone else’s dataset before they can become useful. But local analysis does not remove the need for restraint. A confident-sounding interpretation can still overreach, wherever it was calculated.
Reference points, not templates
Apple Health and Screen Time are useful reference points because they both deal with large quantities of personal data for people who may have little interest in becoming data analysts.
Health lets someone pin important categories, see highlights and trends, then open the underlying graphs and longer time ranges. Screen Time offers daily and weekly summaries, app categories, pickups and notifications, with controls such as limits and downtime nearby. Both create a route from orientation into detail rather than demanding that everyone begin inside the full dataset. (Apple Health guide; Apple Screen Time guide)
They are reference points rather than perfect answers. A Screen Time summary can still feel judgemental. A Health graph can still leave someone wondering whether a movement is important. Presenting less information does not automatically create understanding.
There is also a real audience for the heavy data. Some people want every graph, filter, comparison and export. I often do. The same person may want a two-minute explanation on one day and a detailed investigation on another.
Good progressive disclosure respects both kinds of curiosity. It gives the story first, shows how strongly the evidence supports it and provides somewhere deeper to go. It also changes the route when the evidence is sparse, stale or uneven instead of treating an empty chart as a smaller version of a complete one.
The editor inside the product team
As analytical systems become more capable, product design starts to involve a surprising amount of editorial judgement.
Someone has to decide which story the evidence supports, what tone it deserves, what should appear first, what needs qualification and what should remain available underneath. Someone also has to decide when the product should say less.
Finance taught me to interrogate data. Football Manager made that enjoyable long before it became part of my job. Building products has taught me that this fluency needs to be handled carefully. The interface cannot assume everyone wants to do the same analytical work, but it should not prevent the people who do.
This is why the final product review should spend as much time on the order, wording and tone of an insight as it does on whether the metric calculated correctly. The calculation is the foundation. The product experience is the route by which it becomes useful.
The difficult part is deciding what the available data genuinely supports, then explaining it in language that helps a person without making the product sound more certain than it should.
It is a wonderful professional challenge. Not an easy one, admittedly, but it sits exactly where technical capability becomes a human experience, which is why I keep coming back to it.