Internal Dashboards People Actually Use: A Practical Design Guide (2026)
How to design internal dashboards that get opened every week: start from a decision, pick a few metrics with owners and targets, lay them out for a glance, and keep the data trustworthy.
Key Takeaways
- Start from a decision, not from the data. “Do we need to move a technician to the backlog this week?” leads to a useful page. “Show me all the ticket data” leads to a graveyard.
- One audience, one screen. Microsoft’s Power BI guidance recommends fitting the dashboard on one screen and removing all but essential information. A dashboard for everyone is useful to no one.
- Every number needs context. A target, a comparison period or a threshold. “42 open tickets” means nothing; “42 open, up from 30, target under 35” means act.
- Make it a place to act. The best internal dashboards sit inside the tool that holds the work, so a click on “8 overdue approvals” opens those eight approvals.
- Trust is the whole product. One wrong number and people go back to their own spreadsheets. Define each metric in writing and show when the data was last updated.
Quick-Start Prioritization Framework
| Step | Question to answer | Output |
|---|---|---|
| 1. Audience | Who opens this, and when (Monday meeting, daily standup, month end)? | One named audience and moment |
| 2. Decisions | What do they decide with it? | Two or three decisions written as questions |
| 3. Metrics | Which number answers each question, with what target? | Three to seven metrics with definitions and owners |
| 4. Layout | What must be seen in five seconds? | Headline numbers top left, detail below |
| 5. Action | Where does a click on a bad number go? | Links to the filtered list of records |
| 6. Trust | Where does each number come from, and how fresh is it? | Definitions, a last-updated time and a data owner |
Most companies have a graveyard of dashboards. Someone spent two weeks building a beautiful page of charts, it was shown at an all-hands, and three months later the view count is zero. The problem is rarely the charting tool. It is that the dashboard was built to display data rather than to support a decision someone makes every week. This guide covers how to design an internal dashboard around those decisions: choosing the audience and the question, picking metrics with owners and targets, laying the page out so the important thing is seen first, making it actionable, and keeping the numbers trusted. The examples come from operations, IT and HR: a service desk, purchasing, and onboarding.
Why internal dashboards get ignored
Unused dashboards tend to fail in the same few ways. Recognizing them is half the cure.
- No decision behind them. The page answers a question nobody is asking.
- Too many charts. Twenty tiles mean nothing stands out.
- No context. Numbers without targets or comparisons don’t tell anyone whether to act.
- Stale or wrong data. One incorrect total destroys trust for months.
- A separate place. The dashboard lives in a BI tool nobody opens, away from where the work happens.
- No owner. When a metric breaks, nobody fixes it.
Start with the audience and the decision
Before choosing a single chart, write down who opens the dashboard, when, and what they decide. Microsoft’s design guidance for Power BI dashboards starts in the same place: consider how your audience uses the dashboard and which metrics help them make decisions.
Example: IT service desk
Audience: the IT manager, Monday morning. Decisions: Is the backlog growing? Which category is driving it? Is anyone overloaded? Which tickets are about to breach their target time?
Example: purchasing
Audience: the operations director and finance, weekly. Decisions: Are approvals stuck anywhere? Which departments are trending over budget? Are there repeated requests to the same vendor that should become a contract?
Example: onboarding
Audience: HR and IT, daily in the week before start dates. Decisions: Which upcoming hires have incomplete tasks? Which tasks are overdue and whose are they? Did everyone who started last month get their equipment on day one?
Choosing metrics
Aim for three to seven metrics per dashboard. Each one needs a definition, a target or comparison, and an owner.
| Dashboard | Metric | Definition (write it down) | Context to show |
|---|---|---|---|
| Service desk | Open tickets | Tickets not in Resolved or Closed | Last week’s value and a target |
| Service desk | Tickets older than 5 business days | Open tickets created more than 5 business days ago | Threshold; list them |
| Service desk | Median time to resolve | Median hours from created to resolved, last 30 days | Previous 30 days |
| Purchasing | Requests waiting more than 2 days | Submitted, not decided, older than 2 business days | By approver |
| Purchasing | Spend approved this month by department | Sum of approved amounts, by budget code | Monthly budget |
| Onboarding | Hires starting in 7 days with open tasks | Start date within 7 days and any task not done | By task owner |
Prefer medians and counts of exceptions
Averages get pulled around by one ticket that sat open for a month. A median, plus a count of items past a threshold, usually tells the story better and points to specific records.
Leading over lagging
“Tickets older than five days” warns you this week. “Customer satisfaction last quarter” tells you what already happened. Put leading indicators at the top.
One definition, everywhere
If finance and operations count “approved spend” differently, you will spend meetings arguing about the number instead of the decision. Write each definition on the dashboard itself, in a tooltip or a footnote.
Layout: built for a five-second glance
A dashboard is read in seconds before it is studied in minutes. Design for the seconds.
Most important at the top left
Microsoft’s guidance notes that most people read from top to bottom and recommends putting the highest-level data at the top left, with more detail as you move in the reading direction. Headline numbers go there, as large single-number cards with their comparison.
Fit it on one screen
The same guidance recommends having all tiles on one screen, avoiding scroll bars and removing all but essential information. If it doesn’t fit, you probably have two dashboards for two audiences.
Pick the plain chart
Bar and column charts for comparing categories, lines for trends over time, single numbers for status. Microsoft advises avoiding 3D charts and notes that pies, donuts and gauges aren’t ideal for comparing values. Keep colors consistent: if “Hardware” is blue in one chart, it is blue in all of them.
Round sensibly
Show “3.4 million,” not “3,400,000,” and don’t mix last month in one chart with a filtered month in another. Both points come straight from the Power BI design tips, and both apply to any tool.
Make it a place to act
The dashboards that get used every week are the ones where seeing a problem and fixing it are one click apart.
Click-through to records
“8 approvals waiting more than 2 days” should open a list of those eight, with the approver’s name and a reminder button. That is much easier when the dashboard lives inside the internal tool that holds the records rather than in a separate BI product.
Push the exceptions
Don’t rely on people visiting. Send a short scheduled summary on Monday morning, and an alert when a metric crosses a threshold (a ticket marked “down” waiting more than an hour). The dashboard becomes the place to dig in, not the only way to find out.
Personal views
A technician wants “my open tickets”; the manager wants the team. The same data, filtered by the viewer, often beats a separate dashboard per person. Apply the same access rules as the underlying records: a manager sees their team, not the whole company’s salaries.
Data freshness and trust
A dashboard is a promise that the numbers are right. Keep it.
- Show a “last updated” time on the page.
- Name a data owner for each metric who fixes it when it breaks.
- Reconcile once a month: does the dashboard’s count match a manual count of the records?
- Avoid copying data between systems on a schedule when you can read it where it lives; every copy is a chance to drift.
- If the source is a spreadsheet, expect limits as usage grows. Google’s Sheets API, for example, caps reads at 300 per minute per project.
- When a number is wrong, say so on the dashboard until it is fixed.
Where to build it
There are three common homes for an internal dashboard, each with a fair use.
A BI tool
Power BI, Looker Studio, Metabase and similar tools are strong when you combine data from many systems and have someone to maintain the models. The tradeoff is distance from the work: viewers usually have to go elsewhere to act.
Inside the internal tool
If the records live in your own internal app (tickets, requests, onboarding tasks), a dashboard page inside it can use the same data, the same permissions and link straight to the records. This is often the best home for operational dashboards.
A spreadsheet
Fine for a small team and a weekly review, especially while you are still deciding which metrics matter. Move when you need per-person views, alerts or click-through to records.
Common mistakes
- Building the dashboard before the tool that captures clean data.
- Including every metric someone suggested.
- Numbers without targets or comparisons.
- Averages hiding the one problem that matters.
- Mixing time periods across tiles.
- No last-updated time, so nobody knows whether the data is current.
- Giving everyone the company-wide view, including data they shouldn’t see.
- Never removing a tile, even after nobody has looked at it for a quarter.
If you’d rather not build it yourself
If you’d rather not do this yourself, Floot, the AI app builder that publishes this site, can add a dashboard page to an internal tool it builds, with click-through to the records, a Monday summary email from a scheduled job, and the same roles that protect the underlying data.
Frequently Asked Questions
How many metrics should an internal dashboard have?
Usually three to seven, chosen to answer two or three specific decisions for one audience. If you need more, you probably have two dashboards for two audiences.
What should go at the top of a dashboard?
The highest-level numbers, shown large with their comparison or target. Microsoft’s Power BI guidance recommends placing the highest level of data at the top left and adding detail in the reading direction.
Why does nobody use our dashboard?
Common causes are that it supports no specific decision, shows too many tiles, lacks targets, has stale or wrong data, or lives in a separate tool far from where the work happens.
Should operational dashboards live in a BI tool or inside the internal app?
BI tools suit cross-system reporting with someone maintaining the models. Operational dashboards that drive daily action are often better inside the internal tool, where they share permissions and can link straight to the records.
How do I keep people trusting the numbers?
Write a definition for each metric, show a last-updated time, name an owner, reconcile against the records monthly, and flag known errors on the page until they are fixed.
Sources
- Microsoft Learn, Tips for designing a great Power BI dashboard, 2025 https://learn.microsoft.com/en-us/power-bi/create-reports/service-dashboards-design-tips
- Google for Developers, Sheets API usage limits, 2026 https://developers.google.com/workspace/sheets/api/limits
- NIST, Glossary: least privilege, 2026 https://csrc.nist.gov/glossary/term/least_privilege