Show director dashboard design around three questions

The report opens on a Monday morning after a weekend of registrations. Fourteen tiles, two charts, a filter bar with six controls, and a title block giving the last refresh time in UTC. The show director looks at it for about as long as it takes to decide it is not going to tell her anything useful, then messages the data lead to ask whether Chicago is ahead or behind where it was last year.

That number was on the page. It was tile nine, third row, second column, labelled Reg YoY.

Show director dashboard design is mostly the problem of deciding what earns the front page and what goes one click behind it. The deciding gets much easier once you write down what a show director opens a report to find out, because the honest list is short and it has not changed in twenty years.

What does a show director actually ask?

Sit with three of them for a week and the questions repeat. Am I ahead of the last edition. What moved since I last looked. Who do I need to call.

That is the whole set for the weekly read. Every other question a director asks is either a follow-up to one of those, which means it belongs on a detail page, or it belongs to a different rhythm entirely: the annual budget, the post-show close, the board pack. Those deserve their own pages and their own cadence, and putting them on the weekly screen is how a weekly screen dies.

Stephen Few's Information Dashboard Design, published by O'Reilly in 2006, defines the thing precisely enough to be useful as a constraint. Few's dashboard is a "single-screen display of the most important information people need to do a job, presented in a way that allows them to monitor what's going on in an instant." Two words in that sentence do most of the work. Single-screen rules out the version that keeps growing downward. Job rules out the version built from whatever the warehouse happened to expose.

The reason to start from the questions and work backwards to the data, rather than the other way round, is that the other way round produces a page nobody can defend tile by tile. Kaplan and Norton opened their 1992 Harvard Business Review article on the balanced scorecard with the line "What you measure is what you get", and the corollary for a show director's front page is that the tiles you put in front of somebody every Monday become the things their week is about. A tile is a claim that this number should shape behaviour. Fourteen of them is fourteen claims, and most teams cannot argue the case for more than five.

Mapping fourteen tiles onto three questions

Take the page described above and do the mapping on paper. Write the three questions across the top and put every existing tile under the question it answers. A tile that answers none of them goes in a fourth column.

The fourteen tiles were: total registrations, registrations year on year, registrations this week, verified attendance last edition, exhibitor count, net square feet sold, net square feet year on year, rebooking rate at last close, revenue booked, revenue against budget, top ten exhibitors by spend, registration by country, registration by job function, and website sessions.

Question one, ahead of the last edition, is answered by registrations year on year, net square feet year on year, and revenue against budget. Three tiles.

Question two, what moved this week, is answered by registrations this week. One tile, and only just, because a weekly count with no comparison to the prior week is a number without a verdict.

Question three, which account do I chase, is answered by top ten exhibitors by spend, which is close but wrong, since it ranks the accounts already spending the most rather than the ones about to stop.

The fourth column, answering nothing the director asked, holds nine tiles: total registrations, verified attendance last edition, exhibitor count, net square feet sold, rebooking rate at last close, revenue booked, registration by country, registration by job function, and website sessions. Every one of them is a real measurement that somebody needs. None of them is the reason a show director opens this page on a Monday.

So the front page becomes five tiles. Three comparison tiles for question one, sized and positioned as the primary read. One movement tile for question two, rebuilt to show the change against the prior week alongside the change against the same point in the prior edition. One action tile for question three, rebuilt as a ranked list of accounts whose renewal signal has deteriorated, with a name and a number beside each.

Nine tiles moved to a detail page. Nothing was deleted. That distinction matters when you take the proposal to the people whose tiles you are moving, and it is the difference between a redesign that ships and one that becomes a six-week negotiation.

The movement tile is where most pages fail

Question two is the one teams get wrong most often, because a movement tile has to carry two comparisons at once and most implementations carry neither properly.

Work an example. The edition holds 8,940 registrations, up 612 on last Monday. Last week the increment was 498, and the week before 471. So the weekly increment is accelerating, roughly 23 per cent up on the prior week, which is a genuine signal in a campaign eleven weeks out. The tile that shows only 8,940 hides all of it. The tile that shows 8,940 and plus 612 shows half of it. The tile that shows 8,940, plus 612, and a small series of the last six weekly increments shows the whole thing in the space of a card.

Note what the third version costs: one sparkline and about forty pixels of height. Note what it buys: the director can see the shape without opening anything. Whether that shape should also carry a pacing index against a prior edition is a decision about which comparison the show is actually managed against, and building the multi-year band behind such a comparison belongs to the audience acquisition cluster rather than here.

What goes behind the tab, and how it gets found

The nine relegated tiles need somewhere sensible to live, and the failure mode is a detail page that is just the old dashboard with the good tiles removed.

Group the detail page by the question that leads to it. A director who reads the year on year tile and wants to know why goes looking for composition: registration by country, by job function, by registration type. A director who reads the space tile and wants to know why goes looking for the exhibitor detail: count, net square feet, average stand size, category mix. Two groups, clearly headed, each one the answer to a follow-up rather than a dumping ground.

The navigation between the front page and the detail page deserves a deliberate design, and picking one hierarchy per page so the reader always knows which filter is applied is a subject in its own right. What matters for the front page is that the link exists, that it is on the tile rather than in a menu, and that the detail page opens already filtered to the show the director was looking at.

Why does the front page keep growing back?

Because the page has no owner and every request to add a tile is individually reasonable.

Somebody in marketing asks for website sessions during a campaign push. Somebody in operations asks for badge collection status during show week. Somebody in finance asks for revenue against budget in the month the reforecast lands. Each request is a real need at a real moment, and each one is granted, and none is ever revoked, because revoking a tile requires telling a colleague their number matters less than they think.

The fix is procedural. Give the front page a fixed slot count and make additions a swap. When somebody asks for a tile, the question back is which of the current five it replaces. That converts an unbounded queue of additions into a bounded argument about priority, and the argument gets settled by the person who owns the page rather than by whoever asked last. Deciding what a new tile is meant to change about somebody's week is the requirements conversation that should have happened before anyone opened a report editor, and holding the swap rule is what forces it to happen.

There is a second reason worth naming. Tiles get added because adding is visible work and deleting is not. A data team measured on requests closed will accumulate tiles at whatever rate requests arrive. If you want the page to stay at five, somebody's job has to include keeping it at five.

Where this stops

The three questions are a good default for a weekly read on a single show. They are wrong in two situations, and it is worth knowing which one you are in before you build.

The first is show week itself. During the four or five days the doors are open, a director is not asking whether the edition is ahead of the last one, because the answer is fixed and nothing can be done about it. The questions become operational: where are the queues, which halls are empty at two in the afternoon, has the keynote room filled. That is a different page with a different refresh cadence, and trying to serve both from one screen produces a page that is stale for one audience and overloaded for the other.

The second is the portfolio view. A chief executive holding eight shows does not want three questions per show, because that is twenty-four tiles and back where we started. The roll-up needs its own compression, usually one row per show with a small number of columns and a rule for which rows get highlighted. Deciding how many tiles a page can carry before nobody reads any is a related but separate calculation, and it is the one that governs the roll-up.

Both limits share a cause. The three questions come from a role and a rhythm. Change either and the questions change, and a page designed for the old pair will quietly stop being opened rather than loudly fail.

Take your current show director page this week and do the mapping on paper. Three columns for the three questions, a fourth for tiles that answer none of them, and every tile assigned to exactly one column. If the fourth column has more entries than the other three combined, you have found the redesign, and you have found it in about twenty minutes without touching the report. What you do with the survivors, and in particular where each one sits on the page, is the next decision, and it is worth making deliberately rather than by drag and drop. The whole exercise sits inside the wider question of what a reporting layer for event business intelligence is for, which is to change what somebody does on Monday.