Building for the Person, Not the Dashboard

The meeting was going well until someone asked the question that always makes the room smaller:

“But how will we measure it?”

Not whether it worked. Not whether it helped. Not whether anyone would miss it if we removed it.

Measured as in: a number we can put on a slide.

So the idea changed shape in real time.

We shaved off anything that would take longer than a week to move. We replaced “feel safe” with “daily active users”. We translated “less anxious” into “time on feature”.

By the end, the product didn’t exist for a person anymore. It existed for a dashboard.

This is one of the quiet tragedies of modern software:

We build for what we can count, and then pretend what we counted is what mattered.

The dashboard is not evil (it’s a tool that wants to eat your product)

Metrics are not the enemy. Feedback loops are sacred. If you can’t tell whether something helps, you’re guessing.

The failure is subtler:

1. We choose metrics because they are available, not because they are meaningful.
2. We optimize the organization’s legibility to itself (reports, graphs, certainty).
3. We call the resulting numbers “truth,” and treat lived experience as anecdote.

This produces a specific kind of product: clean, trackable, addictive, emotionally thin.

It creates the illusion of control while leaking reality out of the seams.

A small taxonomy of “dashboard-driven” features

You can often spot the dashboard product by the shape of its features.

1) The “nudge” that exists to be counted

Notifications, streaks, badges, popups, re-engagement emails—many of these are built because they move a number.

The user experience becomes a delivery mechanism for the metric.

If a feature makes the user feel like a lab rat, it probably came from a dashboard.

2) The “workflow” that exists to create data

You’re forced to tag, categorize, set statuses, fill fields, “complete steps”.

Some structure is helpful. But when the structure is there mostly so the system can know you, it stops being support and starts being extraction.

3) The “engagement” loop that replaces the actual outcome

Instead of helping you finish something, the product helps you continue.

It’s easy to measure continuation. It’s harder to measure closure, relief, repaired relationships, regained confidence, or the return of attention.

So we ship the easy thing.

The actual design problem: legibility vs. care

Dashboards reward a particular value system:

• predictable
• comparable
• fast-moving
• centrally visible

But people are not centrally visible systems. A life is not a pipeline. Meaning is not a KPI.

When we build for the dashboard, we end up:

• teaching people to perform progress
• turning care into compliance
• mistaking “used” for “helpful”

And we lose the hard, intimate question:

What does a good day feel like for the person using this?

Principles for building for the person

These are practical constraints I use when I’m trying to protect a product from legibility addiction.

Principle 1: Measure the result, not the ritual

If you can only measure the “daily habit” and not the benefit, your metric will slowly force everyone into the habit shape.

Better questions:

• What does success look like outside the app?
• What ends when this works?
• What becomes easier, quieter, less defended?

Sometimes your best metric is downstream and slow. That’s not a bug. That’s the domain.

Principle 2: Prefer “user sovereignty” metrics over “user capture” metrics

“Time spent” is often a moral failure disguised as a win.

Try metrics like:

• time-to-done (how quickly can someone get what they came for?)
• time-to-confidence (how quickly do they feel oriented?)
• reversal rate (how often do people undo an action because the system pushed too hard?)
• return-with-intent (do they come back because they want to, not because they were nudged?)

If your metric rewards captivity, your product will learn captivity.

Principle 3: Make the system forgiving when life is messy

Dashboards like clean streaks.

Humans have:

• sick days
• grief weeks
• new babies
• broken cars
• neurodivergent variability
• seasons of focus and seasons of collapse

Build for that. Your system should not weaponize the user’s irregularity against them.

If a feature reliably produces shame, it is not a productivity feature. It’s a judgment feature.

Principle 4: Keep the inner experience in the loop (without pretending it’s a number)

This is where many teams panic, because the dashboard can’t see it.

You still can.

Use:

• interviews and open text prompts
• “tell us about last week” check-ins
• small group sessions
• support tickets and stories
• qualitative “signals” tracked like a lab notebook, not a scoreboard

Your organization must stay in contact with the felt experience as data, even if it can’t be graphed cleanly.

Principle 5: Let the product be boring when it’s working

A good tool often disappears.

If the product must constantly announce itself to justify its existence, you will add noise. You will add “engagement”. You will add dashboards for the dashboard.

The best compliment for many tools is:

“Honestly, I don’t think about it much. It just works.”

A practical rubric (for meetings where dashboards speak louder than people)

When someone proposes a metric, I like to ask three questions:

1. What behavior does this metric reward—even if we don’t intend it to?
2. What important outcomes does this metric not see?
3. If we hit this number, could the user still be worse off?

If the answer to (3) is “yes,” the metric is not a success metric. It’s a monitoring metric.

Monitoring can be fine. But it should not be your north star.

Closing: build for the person who doesn’t get invited to the analytics review

The dashboard is a kind of language: it compresses reality so a group can coordinate.

But compression has loss.

The person using your product lives in the parts that don’t compress well:

• the contradictory motivations
• the private shame
• the half-formed hope
• the fragile momentum
• the week where everything falls apart and they try again anyway

Build for that person.

Let the dashboard serve the work. Don’t let it become the reason the work exists.