Dashboard UX Best Practices: Creators Wanted Clarity, Not More Charts

Most dashboard UX best practices lists tell you to pick the right chart type and keep the layout clean. Fine, but that is not what made the difference on the dashboard I led at ViewStats, the creator intelligence platform built by the team behind MrBeast. The thing that mattered was a research finding: creators were not asking for more charts. They were asking "what should I make next?" They wanted confidence, not analytics. Once the dashboard was designed around that one question, the charts became supporting evidence instead of the product. This post walks through that use case the way I would explain it to a founder: the context, the user problem, what the product already did, the design decisions, the published results, and a checklist you can reuse on any dashboard where people are drowning in data and still not sure what to do.

The context: a product with every chart a creator could want

ViewStats is a creator intelligence platform. It tracks YouTube channels and videos, compares competitors, flags outliers, researches thumbnails and runs A/B tests. By the time I led design across web, mobile, the Chrome extension and the AI products, there was no shortage of data. If a creator wanted a number, it was somewhere in the product.

That is the trap most analytics products fall into. The team is close to the data, so adding one more chart always feels like adding value. The dashboard grows. The creator opens it, scans twenty panels, and leaves with the same question they arrived with.

The research inputs we used were ordinary and that is the point: creator interviews, onboarding analytics, feedback from the Discord community (which grew to more than 17,000 creators), support requests and internal workshops. You can read the whole project in the case study on designing creator tools for MrBeast's ViewStats.

The user problem: "what should I make next?"

Across every channel, the same thing came back. Creators did not describe their problem as "I cannot find my average view duration." They described it as uncertainty. They had an upload coming, a shoot scheduled, an edit half done, and they wanted to know whether the idea was right. Every feature request was a proxy for that.

So the dashboard's job was never to be a complete picture of the channel. Its job was to help a creator answer one question with enough confidence to act. I have written before that people rarely want more information, they want clarity. This is where I learned it.

The same lesson showed up in a very different product. At Accern, a no-code AI platform for finance teams, 95% of users never used the product alone; the data was all there and the path through it was not. I wrote that story in enterprise UX design when 95% of users never used the product alone. Different industry, same failure mode: information without a next step.

Dashboard UX best practices we actually applied

Here is what changed in how the dashboard and the features around it were designed, compared with the default analytics approach.

Dashboard element	Default analytics approach	What we did at ViewStats	Why it worked
Purpose	Show the state of the channel	Answer "what should I make next?"	Creators wanted confidence, not coverage
Features	Metrics grouped by data type	Outliers, Competitors Tracking, Alerts, Collections, Thumbnail Research, A/B Testing, each framed as an action	A feature named after the decision is easier to use than a chart named after the metric
Where it lives	Inside the app only	Also inside YouTube through the Chrome extension	Insight at the moment of the decision, no tab switching; 200,000+ users
Empty states	"No data yet"	A preview of the insight the connection would unlock	Show value first, ask for trust second; activation 13% to 65%+
Mobile	A shrunken desktop dashboard	Designed for in-between moments: quick checks between uploads, shoots and edits	Mobile is a glance, not a work session; 100,000+ downloads
Free vs Pro	Hide premium behind locks	Premium visible enough to show value without feeling locked	A paywall that hides value cannot sell it
Visual system	Charts styled one by one	Data visualization, tables and dashboard components in one design system across web, mobile, extension and marketing	Less design debt, faster shipping, same reading rules everywhere

Lead with the next action, not the status

The first screen a creator sees should move them toward a decision. Outliers is the clearest example of the thinking: instead of a full table of videos, surface the ones performing far outside the norm, because that is where the "make this next" signal is. Competitors Tracking and Alerts do the same for other channels: tell me what changed and what it means for me, not everything that exists.

Put the dashboard where the decision happens

A dashboard does not have to be a page. The Chrome extension put ViewStats insights directly inside YouTube, where creators were already browsing, comparing and getting ideas. It grew past 200,000 users and became a major acquisition and retention channel. I broke it down in how our Chrome extension UX reached 200,000 users. If your users make the decision somewhere else, bring the insight there.

Design the empty state as a promise

The most important dashboard state is the one with no data. At ViewStats, many creators signed up and never connected their YouTube channel, so they never saw a single chart. The fix was not on the dashboard itself. It was in onboarding moments, empty states and contextual prompts that previewed what the dashboard would reveal before asking for channel access. Channel connection went from 13% to more than 65%. Full write-up: onboarding UX best practices from a 13% to 65% activation fix.

Mobile is a glance, not a session

The mobile app was designed for the moments between uploads, shoots, edits and meetings: check the channel, look at a ranking, spot a trend, switch between creators, close the phone. For free users the focus was clarity, discovery and fast access to core analytics. For Pro users it was deeper insight and faster research workflows. Those are two different dashboards on the same screen, and the balance was to keep premium tools visible enough to communicate value without the app feeling locked or frustrating.

Make the charts speak one language

The design system covered typography, color, navigation, data visualization, dashboard components, tables, forms, empty states, mobile patterns and color tokens, across web, mobile, marketing and the extension. The practical effect on the dashboard: a creator learns how to read a trend line once and that knowledge works everywhere. The practical effect on the team: less design debt and faster design and development, which mattered because I was also building React components in the codebase by then.

The published results

I only cite what the case study states. ViewStats grew to more than 500,000 users, 200,000+ extension users and 100,000+ mobile downloads, with 17,000+ creators in the Discord community, creator activation up from 13% to 65%+, and the product evolved into a profitable creator platform. I cannot attribute a single number to the dashboard alone, and I would be suspicious of anyone who claims that kind of precision for a dashboard redesign. What I can say is that every one of those surfaces was built on the same principle: clarity over information.

Dashboard UX best practices you can reuse

Here is the checklist I run on any dashboard now, whether it is for creators, energy customers or finance analysts.

• Write the one question. Before any layout, write the sentence your user is trying to answer. "What should I make next?" at ViewStats. "When should I run the dishwasher tonight?" at Greenely, the Swedish energy app where clearer price signals were the whole job. If you cannot write it, you are not ready to design.
• Name features after decisions. Outliers, Alerts, Competitors. Not "Video performance table."
• Rank by surprise, not by completeness. Show what changed and what is unusual first. Everything else is a click away.
• Design the empty state first. It is the state most new users see. Make it a preview of the value, then ask for the data connection.
• Decide what mobile is for. A glance between tasks is a different product from a desk session. Design the glance.
• Keep premium visible. Users cannot want what they cannot see. Show the locked insight, blur the detail, never hide the feature.
• Systematize the data viz. One set of chart components, one color logic for up and down, one table pattern. Then every new metric is cheap to add and easy to read.
• Measure the decision, not the view. Track whether people act after looking (connect a channel, set an alert, save to a collection), not how long they stared.

If you want an academic complement to this field checklist, the Dashboard Design Patterns project from Benjamin Bach and colleagues at the University of Edinburgh catalogs layout, content and interaction patterns from a systematic review of real dashboards. It is a good way to name what you are already doing.

Where this advice does not apply

If your users are analysts whose job is the exploration itself, a decision-first dashboard can feel patronizing. They want the full table, the filters and the export. At Accern the answer was to build the guided path for the 95% and keep the deep tools one level down for the few who lived in them. Also, "lead with the next action" assumes you know which action matters; early in a product, before research, you do not. Ship the simplest honest status view first, listen, then redesign around the question you actually hear.

One more limit: none of this fixes bad data. A confident dashboard built on numbers people do not trust makes things worse, not better. Designing AI features taught me the same thing: the hard part is designing trust.

Dashboard UX FAQ

What is dashboard UX?

Dashboard UX is the design of how people read, understand and act on a screen that summarizes data. It covers which metrics appear, in what order, how they are visualized, what happens when there is no data, and how the dashboard connects to the next action. Good dashboard UX is measured by decisions made, not by charts displayed.

What is the most common dashboard design mistake?

Showing everything. Teams close to the data add charts because each one feels valuable, and the user ends up scanning twenty panels without an answer. The fix is to write the one question the dashboard exists to answer and rank every element by how much it helps with that question.

How many metrics should a dashboard show?

As few as it takes to answer the main question with confidence, with the rest one click away. At ViewStats, features like Outliers and Alerts surfaced what was unusual or changed first; the full data lived underneath. There is no magic number, but if a user needs to scroll to find the point, there are too many.

Should a mobile dashboard show the same data as desktop?

No. Mobile is for in-between moments: a quick check of the channel, a ranking, a trend, then back to work. Design for the glance, keep the deep research workflows on desktop or behind a deliberate tap, and make sure the one question is answered above the fold.

Want a second opinion on your dashboard?

If your product has plenty of data and users who still ask "so what do I do?", that is the exact problem I like working on. You can see more of the work on my case studies page, try the interactive builds on my AI experiments page, or hire me as your product designer for a dashboard review. For the wider role behind this kind of work, I wrote what a product designer does.