Dashboard

For a long time, seeing a number meant going through a person. The founder would ask how many people signed up last week, an analyst would write a query against the database, and the result would get copied into a table and carried into the meeting. Once, that is fine work. The problem was that the same question came back every week. Every Monday the same person ran the same query and rebuilt the same table, and nobody in the company learned anything new during that half day.

Time was not the only cost. When the person pulling the number changed, the number changed with them. A metric is a number defined in advance so a team can judge where things stand, and when that definition lives in somebody's head instead of in a document, a team ends up with as many definitions as it has people. Marketing walks in with 120,000 monthly active users and product walks in with 40,000. One side counted anyone who logged in at least once, the other counted anyone who created at least one document. That meeting spends thirty minutes deciding which number is real and ends without deciding what to do about either of them.

A dashboard cuts both problems at once. You pick the questions that keep coming back, write the calculation once, and let the result refresh on its own every day. The asking step disappears, and everyone reads the same value produced by the same calculation. Taking the person out of the loop pays off less in speed than in agreement. When the number is singular, a meeting has one less thing to argue about before it can start arguing about the decision.

A dashboard sits at the very end of the path data travels. Behavior gets recorded as it happens, those records get moved into one place and cleaned up, somebody defines what is worth counting, and the counted result gets put in front of the organization. The dashboard owns that last square, the one where results are set down where people can see them. So when a number on the screen looks wrong, opening the formula first is usually the wrong order. Check whether an event stopped being recorded, whether last night's load failed halfway, or whether the definition quietly changed last week.

The terms under dashboard fall into four groups: what the numbers get drawn as (presentation), how you get from a summary down to the detail behind it (exploration), who keeps the screen running and what it does while nobody watches (operation), and how numbers leave the screen entirely (output).

Presentation is the group that turns values into shapes. Data visualization is the work of picking that shape so the value is easier to take in. Twelve months of signups in a table forces the reader to scan for the month that dipped; the same twelve numbers as a line put the dip in front of them immediately. What you choose here is the type of picture. Change over time wants a line, comparing sizes across items wants bars, share of a whole wants a circle, and a circle stops working once it has more than four slices, because the eye cannot rank wedges that close in size. A badly chosen picture does not make the value wrong. It walks the reader to a wrong conclusion while showing a correct number. Start a vertical axis at 9,800 instead of 0 and a one percent move looks like a cliff face. Color carries the same risk: give every line its own color and by the seventh nobody remembers which was which, and unless meanings are pinned down in advance — blue for revenue, red for failures — the same color ends up pointing at different things on different screens.

Exploration is the group that opens up what sits behind a summary. Drill-down means clicking a total on the screen to reach the parts that add up to it. One line saying new signups fell from 3,000 to 2,000 leaves nobody with anything to do. Split that line by acquisition channel and it turns out paid traffic alone is down 900, which is a place somebody can actually go and check. The criteria you split by are chosen ahead of time and swapped one at a time — by channel, by plan, by the month a user joined — and cycling through them is how the bucket that dropped shows itself. This is usually where a dashboard stops being able to answer, which is why the summary view and the path downward get designed as one piece. A screen with no way down shows you a strange line and then hands the next step back to an analyst, which puts the team back where it started before anyone built a dashboard.

Operation is the group that decides whose hands the screen lives in, and it splits in two.

1. Self-serve analytics — an environment where people look at data without going through an analyst. It does not stop at reading the screen. It hands the reader the controls too: changing the range from the last 7 days to the last 90, or splitting the same chart by plan. This pushes the removal of the asking step one square further than the dashboard alone does. Opening the controls also opens room to misread what a value means, so most of the effort in this group goes not into building screens but into writing one line beside each metric name saying exactly what it counts.
2. Anomaly detection — a feature that flags values falling outside the usual range without being asked. The weakness of a dashboard is that it does nothing at all while nobody is looking at it, and outages rarely wait for Monday morning. If payment failures normally run at 0.4 percent and today they are at 3.1, this is the part that speaks up instead of waiting for somebody to open the page.

Output is the group that sends numbers past the edge of the screen. A report is a document that sums up where things stand on a fixed schedule and gets shared. Every organization has people who never open the screen, and some of them, like investors or outside board members, have no access to it in the first place. The monthly document Pagedeck sends its investors works this way: the numbers come from the same place, but what changed since last month and how the team reads it get added by hand.

The four groups overlap on one screen. Visualization forms the first impression, drill-down gives that impression somewhere to be checked, self-serve and anomaly detection keep the screen useful when its author is not in the room, and reports carry the numbers outside. Whether the screen is any good is judged not by how many numbers it holds but by whether anybody does something different after reading it. A number that nobody acts on is occupying space, and space on a screen is the scarcest thing about it.

"That number's already on the dashboard. Have a look before the meeting."

The value used to come from asking a person and now sits on a screen permanently, and this is also a request to stop asking the same question again.

"I built this six months ago and I'm the only person who opened it last month."

The screen is still running but no decision depends on it, which usually leads into a proposal to trim it or retire it.

"The screen and the monthly document disagree. Which one is right?"

Two places are calculating a value under the same name in different ways, and until the definitions are reconciled neither number is usable.

At Pagedeck, Monday morning starts with one screen. Mia puts it up and new signups, paid conversion, weekly active users and the payment failure rate come up together, each against the last eight weeks. Grace does not ask for numbers in that meeting, because they are already there. She points at whichever line bent and asks what happened.

Last month paid conversion dropped two weeks running. Mia clicked into the line and split it by plan: team plans were flat and individual plans were carrying the whole drop. The meeting ended there, and the work of finding the cause moved to Theo, who went digging through checkout error logs. The screen did not produce an answer. It narrowed down where to look for one, which is most of what a good screen does.

The first mistake is believing that a screen with more on it is a better screen. Forty numbers look like effort, and once they are up there, arguing for removal is awkward, because every one of them was added at somebody's request. But a person opening a screen can hold five or six lines at a time, and on a page with forty tiles you cannot even tell which line is unusual today. Left that way, people open the screen, read nothing, and close it. Six months later there is a page nobody visits, and the number that actually matters this morning goes back to being a request sent to an analyst. The question to ask while building is not whether a number is interesting, but who would do something differently if it moved. Lines with no answer to that belong in a query run on demand, not on a page that loads every morning. Teams that prune this way tend to end up with a page of six or seven numbers that everyone can recite from memory, which is a far better outcome than a wall of tiles nobody can summarize.

The second mistake is assuming the answer is on the screen. When values are already arranged into clean shapes, the interpretation looks finished too, so this one is easy to fall into. What a screen reports is what happened. Why it happened sits somewhere else entirely — in drilling down into the parts, in asking users directly, or in forming a guess and running an experiment to test it. Skipping that gap turns two lines that moved together into a claim that one caused the other. Signups rose the same week ad spend rose, but whether the ads brought those people in is not something the screen can settle. A competitor having an outage that week would have drawn exactly the same two lines.