Dashboard product designer: what metrics to monitor and how to read them

Most designers look at analytics once a month when a product sends a report or when something is clearly broken. It's a reactive approach: you learn about a problem when it's already done damage.

Dashboard is a transition to a proactive approach. You see metrics every day or every week, notice deviations earlier, find opportunities before the competition.

But the dashboard only works when you look at it. And look only at the one that shows the necessary metrics in an understandable way. This is the task of this article – to figure out what exactly should be on the dashboard of a product designer.

## Why does a designer need a dashboard

The product manager looks at product metrics. Marketer - on traffic and CAC. Analyst, all at once. The designer has his own perspective.

The designer is responsible for the quality of interaction. So the dashboard should show:

• How easy are users to perform key tasks
• Where there are problems in the interface
• How changes in design affect behavior

It's not the same as a generic grocery dashboard. There's retention, revenue, DAU. Task completion, error rate, flow completion, time on task.

## Dashboard structure: three levels

A good dashboard can be read in 5 minutes. This means that information should be structured according to priority.

### Level 1: Alarm signals (watch daily)

Metrics that require an immediate response when rejected. If they are normal, look further. If you don't, you're dealing with it right now.

• Error rate on key flow - a sharp increase means a breakdown
• Crash rate / Page errors - technical issues, but they directly affect UX
• Drop-off rate on key steps of the funnel - if someone has grown sharply, something is wrong

These metrics are better shown as time series with an anomaly detector or at least with thresholds - green / yellow / red.

### Level 2: Health Tracking (watch weekly)

Metrics that change slowly but determine the quality of a product in the long run.

• **Retention (D1, D7, D30) **
• Activation rate (onboarding completion, time to first key action)
• Feature adoption rate for key features
• NPS or CSAT (if collected regularly)
• Session length and session frequency

Dynamics is important here, not just absolute significance. “D30 retention = 35%” does not mean anything. “D30 retention rose from 28% to 35% for the quarter,” says a lot.

### Level 3: Deep metrics (see in iterations)

Metrics that are needed for specific research or evaluation of changes.

• Task completion rate for specific tasks
• Time on task on specific flow
• Heatmaps and scroll depth on specific screens
• A/B test results on current experiments
• SUS evaluation from usability tests

These metrics aren’t needed daily – but when needed, they should be available quickly.

## Metrics in detail: what exactly to watch

### Task completion rate

**Percentage of users who have successfully completed a specific task.

**How to count: * Number of users who have reached the end state of Flow / Number of users who have started Flow × 100%.

** What is the norm depends on the complexity of the task. For simple tasks (add to the cart, create a document) – 85%+. For complex (fill in a long form, adjust integration) – 60-75% is already good.

How to read: Look not only at the bottom line, but also at the drop-off steps. Where 20-30% of users leave is the point of improvement.

** Red flags:**

• A sharp drop after the release of changes
• Stable low score on one particular step
• Difference in completion rate between devices (mobile vs desktop)

### Funnel conversion rate

**What it is: * Percentage of users switching between funnel steps.

It is important to consider the funnel step by step, not just from start to finish. “70% of users have been onboarded” is useful information. “In step 3 of 7, 45% of users leave” – information that can be worked with.

Display Format: Step funnel with absolute numbers and percentages at each step. Show the conversion “to the previous step” and “to the first step” are different data.

** How to analyze:**

• Where the biggest drop is, there is the biggest opportunity
• Mobile vs. desktop is often a problem on just one platform
• Comparison of new and returning users – different patterns often mean different problems

### Error rate and error types

**How often do users experience errors (forms, actions, systems).

Mistakes are different:

• Validation errors - the user has filled the field incorrectly
• *System errors * Something went wrong on the side of the system
• User errors - the user did the wrong action (pushed the wrong button, deleted the wrong one)

**Why error rate matters: * Every error is a friction. Some users leave after an error. Especially critical in payment flow and registration.

What to monitor:

• Error rate on the registration form (especially in fields with special requirements - password, phone)
• Error rate in checkout
• Frequency of “cancellation” or “back” immediately after an important action (indirect error signal)

### Time on task

**How much time does the user spend on a specific task.

Small things aren't always good. Too small can mean that the user has not completed the task, but has abandoned it.

How to interpret:

• Set a target time for a task (e.g., “It should take < 3 minutes to create a project”)
• Measure the deviations both ways
• Very high time – the user is stuck or confused
• Very low time on a task that needs to be thought through – maybe the user doesn’t get into it

Where to get the data: If there are no special tools, you can count events (beginning of flow → end flow) in analytics through timestamp.

### Feature adoption rate

What percentage of active users use a particular feature at least once in a period.

This is an important metric for evaluating design decisions. If the feature is not used, users do not need it, or they do not find it, or it is too complex.

** How to analyze:**

• Feature with adoption < 10% - either niche (and that's OK) or there's a problem
• Look at adoption in the first 7 days after registration - key features should be opened quickly
• Comparisons of adoption between user segments (new vs. experienced, tariff A vs. tariff B)

### Heatmaps and scroll depth

**What it is: * visualization where you click, where the mouse moves, how far you scroll.

Heatmaps are useful for:

• Understand if users see CTAs (clicking nearby but not on a button is a problem with click targeting)
• Find unexpected patterns (click on a non-clickable element – it may look like a button)
• Check whether the landing page is finished to the key sentence

Scroll depth: is important for landing pages. If 80% of users go to the key CTA, either move the CTA higher or improve the first screens.

Tools: Hotjar, Microsoft Clarity (free), FullStory. For mobile, separate SDKs.

## How to collect a dashboard: practice

### Tools

There is no single right tool. Choose from what is already on the team:

• Amplitude / Mixpanel - full-fledged product analytics, cohort analysis, funnel analysis
• Google Analytics 4 - Basic Behavior Analytics, Good for the Web
• Hotjar/Microsoft Clarity - heatmaps, session recordings
• Looker / Metabase / Redash – BI tools for building custom dashboards from data
• Figma + FigJam - for manual analysis and visualization of data in the form of schematics

Ideal stack: product analytics (Amplitude/Mixpanel) + heatmaps (Clarity) + BI for aggregation (Metabase).

### How to Build the First Dashboard in a Day

** Step 1.** Identify the 5-7 metrics you want to track. No more - otherwise the dashboard turns into a wall of numbers.

Step 2. For each metric, understand where the data comes from. Analytics? Server? Polls? Make sure the data is collected at all.

Step 3. Build the first version in any tool. This can be a table in Notion, a dashboard in Amplitude or just a Google Sheet with updated data.

** Step 4.** Put a reminder to look at the dashboard once a week, on the same day. Dashboard without regular viewing is useless.

Step 5. A month later, review: Which metrics were useful, which were never used? Put it away, add it.

## How to read metrics: basic principles

### Look at dynamics, not absolute values

“Task completion rate = 72%” – what does that mean? Nothing without context. The Task completion rate has risen from 58% to 72% in a month.

For each metric, you need a basline and a direction of movement.

### Compare the segments

The same metric can be very different for different user groups:

• New vs. experienced
• Mobile vs. desktop
• Different rates
• Different channels of attraction

Aggregate data hides problems. Segmentation reveals them.

### Look for correlations with change

The metric changed - what was going on at that time? Was there a release? A marketing campaign? Seasonal? Change to onboarding flow?

Making changes next to a dashboard is good practice. After 3 months, it’s hard to remember what you did in a particular week.

### Don't confuse correlation and causation

Two metrics move together – it doesn’t mean that one causes the other. A/B tests are needed to establish causal relationships.

## What to do with data: from observation to action

Dashboard is not the end point, it is the beginning. Data should lead to concrete action.

** Data processing:**

1. *Notice a deviation - the metric fell or grew abnormally
2. **Hypothesis: Why did this happen
3. ** Check the data** - look at related metrics, break down by segment
4. • Formulate a problem** – if a problem is found, describe a specific task for the design
5. Make a change and measure - A/B test or before/after with a control group

Data without action is just numbers. Action without data is just intuition. Good work with metrics is both together.

## Dashboard example for SaaS product

─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
Alarm Signals (updated daily)
Objective
Error rate onboarding: 2.3% (norm < 5%)
Checkout error rate: 8.1% рма (norm < 3%)
404 errors today: 143 рма (norm < 50)
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─

─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
Product Health (updated weekly)
Objective
D1 Retention: 48% (+3% compared to last week)
D7 Retention: 31% (+1%)
← D30 Retention: 22% (-2%) ← Need to figure out
Objective
Activation rate: 64% (+5%)
Time to activation: 4.2 min (-0.8 min)
Objective
NPS: 42 (a quarterly survey)
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─

─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
← Key Flows (updated weekly)
Objective
Onboarding funnel: ♥
← Registration → Step 1: 91%
Step 1 → Step 2: 78%
Step 2 → Step 3: 52% ← Problem
Step 3 → Activation: 89%
Objective
Checkout funnel: ♥
Payment: Payment: 74%
Payment → Confirmation: 61% ← Problem
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─

This is not a perfect kind of dashboard - it will be different for different products. But the structure of “anxiety → health → details” works universally.

## What shouldn't be in a dashboard

Vanilla metrics. Number of pages viewed per session, bounce rate without context, number of "likes" - metrics that look good, but do not affect anything.

If there are 40 charts on the dashboard, you look at it diagonally and you see nothing. 7±2 is the working volume.

Data without context. A figure without a baseline, a trend, and a norm is almost useless.

Metrics that lead nowhere. **If the data never led to a specific action for the quarter, why are they on a dashboard?

## How to Automate Data Collection for Dashboard

A dashboard that is updated manually dies. Data is entered irregularly, then forgotten, then cease to be used.

Automation is not a luxury, it is a condition for the survival of the dashboard.

### Levels of automation

** Level 1: Ready-made dashboards in analytical tools.** Amplitude, Mixpanel, Google Analytics all have built-in dashboards. Configure once, the data is updated automatically. Cons: Limited flexibility in visualization.

Level 2: BI tool with automatic update. Metabase, Looker, Tableau, Power BI connect to the database and update the data on a schedule. You can build any kind of visualization. It requires customization, but more flexibility.

** Level 3: Custom dashboard.** For teams with engineering resources – own dashboard on React/Vue with direct reference to the analytics API. Maximum flexibility, maximum cost.

** Level 0 (anti-pattern): Google Sheets with manual filling.** It only works for the first 2 weeks. Then the data becomes obsolete and the dashboard becomes an archive.

### What to connect to the dashboard

• ** Product Analytics:** Events from Amplitude/Mixpanel - retention, funnel, feature adoption
• Web analytics: GA4 – traffic, sources, website behavior
• Support: Zendesk, Intercom – number and categories of appeals
• Monitoring: Sentry, Datadog - errors and performance
• Polls: NPS, SUS results from Typeform or proprietary system

## How to Read Data in Uncertainty

The data is rarely unequivocal. They often create questions rather than answers. The ability to work with uncertainty is a key skill.

### The Principle of Multiple Hypotheses

When you see a deviation in the metric, do not rush to the first explanation. Formulate 3-5 possible reasons before moving to a conclusion.

Example: D7 retention fell from 38% to 31%.

Possible causes:

1. Onboarding changes (was there a release last week?)
2. Change in traffic quality (changed channel?)
3. Seasonality (vacations, holidays?)
4. Technical Failure During Retention Period (Application Errors?)
5. Changing competitive environment (a new competitor?)

Only after testing each hypothesis with data can a conclusion be drawn. You're treating the wrong disease.

### Correlation causation: always

The most common erroneous conclusion from the data is that “X changed because we changed Y.” Simultaneousness is not causality.

Rule: If you want to assert causation, you need a controlled experiment (A/B test). If there is no A/B test, the correlation remains a hypothesis.

### How to deal with incomplete data

Data is often lacking for the full picture. This is not a reason to abandon analysis, but a reason to clearly label uncertainty.

“According to the data we have, it seems that step 3 is the problem. It's a hypothesis, we need X to confirm" - honestly and usefully.

“The data show that the problem is in step 3, we need to urgently redo” – without sufficient data, this is a delusion.

## Dashboard for different roles in the team

One dashboard for the whole team is rarely a good idea. Product, designer, developer, CEO have different questions and different levels of detail.

CEO level: Business metrics (MRR, churn, LTV, CAC). Updated monthly. Highest level possible. No need for details of funnels and feature adoption.

Product Level: Product KPIs (retention, activation, feature adoption, NPS). Updated weekly. Average level of detail.

Designer level: UX metrics (task completion, error rate, funnel for specific flow, test results). Updated as needed.

** Developer-level:** Technical (error rate, performance metrics, uptime). Updated in real time.

Everyone should have access to their level – and the ability to “fall down” deeper if necessary.

## Frequent mistakes in working with dashboard

### Mistake: Datacentricity without action

We collected data, built a beautiful dashboard, we watch every week. But the data doesn't lead to change. This is data paralysis.

Solution: Each metric is linked to the “owner” and SLA reactions. If the error rate exceeds the threshold, the responsible person must respond within 48 hours.

### Mistake: Dashboard only for reporting

Dashboard is used to “show what we’re doing” in meetings with management. Not for decision-making.

Sign: No one is looking at the dashboard between meetings. Solution: Ask the question “What decision will we make on this data?” for each metric. If there is no answer, the metric is superfluous.

### Mistake: Too much dashboard

40 metrics, 20 graphs. No one is looking at the whole dashboard - for too long.

Rule: If it doesn’t fit on one screen without scrolling, too much. Start with 5-7 key metrics, add only when you have a specific task.

### Mistake: No historical data

Dashboard only shows current values, with no history. No trend, no context.

Solution: A minimum of 12 months of history for all key metrics. This allows you to see seasonality and long-term trends.

## AI and Dashboard: How to Analyze Metrics and Find Problems Fast

AI does not replace an analytical tool, but it helps interpret data, formulate hypotheses, and turn numbers into design tasks.

### Prompt: understand the data for the week

Instead of interpreting a set of numbers yourself, give them to Claude with context:

Here is our product data for the last 4 weeks:

Week 1: D7 retention 34%, activation rate 51%, error rate 6%
Week 2: D7 retention 36%, activation rate 53%, error rate form 5.8%
Week 3: D7 retention 29%, activation rate 48%, error rate 7.2%
Week 4: D7 retention 27%, activation rate 45%, error rate form 8.1%

In Week 3 we [describe product/marketing changes/if nothing, say so].

What's most likely going on? What hypotheses explain this dynamic? What should be checked first?

### Prompt: formulate hypotheses on anomaly

In our dashboard we see:
Conversion to registration decreased from 4.2% to 2.8% in two weeks
Traffic to the landing site has not changed
Bounce rate on the registration page increased from 32% to 51%
Error rate on the form has not changed (3% remaining)

What could have caused this anomaly? Offer 5 hypotheses from most to least likely. For each - how to check for 1-2 days without development.

### Prompt: choose metrics for dashboard

I am a product designer in [company/product type].
My area of responsibility is [onboarding/key flow/conversion/etc.].
The analytics tools we have are [Amplitude/GA4/Mixpanel/nothing/other].

Help me choose 7 metrics for my working dashboard.

Criteria:
Metrics should be measurable with our tools.
- It should give a signal to action (not just information).
- It should cover both UX quality and relationship to business output.

For each metric:
- Why is she?
- How often to watch (daily/weekly/when changing)
- What deviations are worth reacting to

### Prompt: Write a summary of the dashboard

If you need to tell the team about the status of the metrics, Claude will help to structure.

Here is our product data for the [period]:

[insert key numbers]

Write a short (5-7 sentences) weekly summary for the team:
- What's good (with specific numbers)
- What causes questions (with specific numbers)
- What we suggest to check out next week

Tone: Direct, without water, action-oriented.

### Working with raw data: CSV in conclusion

If you have data upload, you can upload it directly to Claude:

Here is the CSV with our analytics event data for the month:
[download file or insert table]

Columns: user id, event name, event date, properties

Calculate:
1. Funnel from [beginning event] to [completion event]
2. Median time between [event A] and [event B]
3. Percentage of users reaching [key event] in first 7 days

Show the results and the interpretation.

Claude is able to count cohorts, build funnels and find patterns right in a conversation - without SQL and without an analyst.