The admin homepage showcases revenue, order counts, operating rates, inventory, and inquiry volume. The graphs look sharp, and numbers update in real time. Yet three months later, the only person opening it is the person who built it.
When dashboards commissioned from an agency fall out of use, subsequent reactions are almost identical: "I looked at it, but didn't know what action to take." The issue is not visual styling. It is that the screen answers a question no one was asking.
In an article published by Smashing Magazine on August 26, 2026, Meriem Benhabiles describes data visualization as "an intersection between two areas that don't usually talk to each other: data and design," emphasizing that one should start by asking questions before ever opening a design tool. For clients commissioning work, this sequence is no different.
Starting with "metrics we want to see" puts everything on screen
Requirements scoping sessions often unfold like this:
Someone asks, "What metrics would you like to see?" Stakeholders chime in. Sales wants order counts, accounting wants payment receipts, and operations wants utilization rates. Including everything offends no one, so it becomes the requirement.
The flaw in this process is that a justification to exclude something never surfaces. Once suggested by someone, dropping it requires saying "we don't need this." No one wants to create friction, so no one speaks up. Consequently, 15 cards end up crammed onto a single screen.
Users opening the page have no idea where to look first. An overwhelming screen never gets opened a second time.
Shifting the starting point from metrics to decisions
Instead, frame a single core question: "What will someone do immediately after looking at this screen?"
Take an order count graph as an example. What action follows viewing it? If the answer is "deciding where sales reps should focus their outreach this week," what is needed is not company-wide aggregate trends, but progress per representative and remaining days until deadline. Even for the same "order count," differing decisions demand entirely different presentations.
Other numbers yield no clear answer—those that can only be explained with "I just want to keep an eye on it." Such metrics belong in the realm of reports, not dashboards. Exporting them to a monthly PDF is plenty. Placed on an operational dashboard, they only bury the numbers needed for real-time decisions.
Nielsen Norman Group distinguishes dashboards into operational types that rapidly support time-sensitive decisions, and analytical types designed to explore trends and discover insights. These two serve completely different information densities and refresh cadences. The moment you attempt to cram both onto one screen, it becomes inadequate for either purpose.
Aiming for one decision per screen
A practical approach is to organize screens by decision unit.
- Screen to determine which deals require action today (Operational / Opened daily)
- Screen to forecast month-end performance (Operational / Weekly)
- Screen to explore which product lines are growing (Analytical / Monthly)
Splitting them keeps the elements per screen down to a manageable 3 to 5 items. Many might feel "information has been reduced," but what was actually eliminated was only the data irrelevant to the decision.
At this stage, also define who opens each screen and how often. Daily screens and monthly screens differ in navigation placement and required load speeds. The considerations behind where to locate monthly reports apply here as well.
Ask about real-time update costs before making it a requirement
Update frequency is easily overlooked during procurement. A request to "see things in real time" arises naturally, but it significantly impacts both implementation and operational costs.
Daily batch updates can simply aggregate data overnight and distribute static outputs. Real-time updates, however, require continuous aggregation workloads, trigger more queries to core databases, and necessitate load countermeasures. The screen looks identical, yet the price tag differs dramatically.
Working backward from the frequency of decisions ensures success. There is no need to engineer continuous updates for a decision made only once a week. Conversely, on a screen determining daily shipping authorizations, lag can be fatal. This is an assessment the client specifying requirements must make; the development agency cannot make it for you.
Acceptance criteria are not just about whether it opens
If acceptance testing ends at "the screen renders and numbers match," whether it actually gets used remains unverified.
Here is an alternative criterion to establish: Can the actual operator make the intended decision relying solely on this screen? Have the decision-maker try it during development and ask, "Looking at this, what do you do next?" If they hesitate, the selected metrics or visual layout are misaligned.
Much like documenting acceptance criteria for external system integrations in advance, proceeding with ambiguity leaves you with no basis for requesting adjustments later. "It feels hard to use" rarely justifies a specification change, whereas "we cannot make the intended decision" does.
Sometimes you can get by without building one
If there are only one or two decisions and a handful of stakeholders, you may not need a custom dashboard at all. In practice, exporting daily data to a spreadsheet is often more than enough. Choosing no-code internal business apps serves a similar purpose.
The turning point where building one makes sense is when decision points multiply, audiences cross departments, and manual aggregation can no longer keep pace. Building before reaching that threshold leaves you with recurring maintenance costs for a tool nobody touches.
What to do next
First, identify and name one quantitative decision made most frequently in your company today. Something at the level of "every Monday, determining which clients to visit this week" is fine. Measure how many minutes that decision currently takes.
Next, write down on paper only the numbers strictly necessary for that decision. If three suffice, your screen should feature exactly three metrics. If you end up listing 15, you have not yet narrowed your focus to a single decision.
GleamHub provides consultations on custom development, AI, and automation covering business system admin panel design, data aggregation architectures, and dashboard construction on existing systems. Because the right architecture depends on decision types and data structures, please consult us individually. Contact us via Contact Us.
