Do not start by asking what they want on it
A request for a dashboard is a solution somebody has already chosen, so the first job is to
recover the problem it was chosen for. If you open with what charts they would like, you will
get a list, you will build the list, and in three months it will be open in nobody's browser
because a chart nobody acts on is decoration.
So the opening question is about action, and it is worth asking almost literally: when you look
at this on a Monday morning and the number is bad, what will you do differently? A good answer
sounds like "I would move two people onto the exceptions queue" or "I would call the supplier
whose rejection rate is worst". A vague answer — "we would have visibility" — tells you the
decision has not been identified yet, and identifying it is now the work. Visibility is not a
requirement; it is the feeling somebody has when a decision they already make gets easier.
What to listen for in the first conversation
Alongside the decision, four things are worth extracting before you leave the room. Who will
open it, how often, and in what setting — a screen glanced at daily by a team leader is a
different artefact from a monthly pack a director takes to an executive meeting. What they do
today instead, because there is nearly always a spreadsheet, and that spreadsheet is the best
requirements document available to you. What triggered the request now, since a dashboard
request rarely arrives spontaneously: something went wrong, or somebody was asked a question
they could not answer. And who else will read the numbers, because a figure that leaves the
department will be challenged by whoever owns the source system.
The trigger is the highest-value question of the four. "The regulator asked us for our
complaint-handling times and it took us four days to answer" is a completely different brief
from "the new director wants to see the operation", and the second is far harder to satisfy
because there is no test for done.
Pin the words down before designing anything
Every metric contains at least one word that two people in the business define differently, and
the deadline dies on those words rather than on the build. Write the definitions out and get
them agreed in writing. A table like this takes an afternoon and pays for itself repeatedly.
Metric Active corporate customer
Definition Customer with at least one posted transaction in the trailing 30 days,
excluding internal transfers and reversals
Grain One row per customer per day; dashboard shows the daily count
Source core.transactions (posted date, not value date), core.customer
Excludes Accounts in closure, staff accounts, test customers (flag = Y)
Refresh Overnight batch, available by 07:00; not intraday
Owner Head of Corporate Sales agrees the definition; Data owns the source
Decision Whether to trigger the dormancy outreach campaign this week
Known gap Reversals are only flagged from Nov 2024; earlier trend overstates by
an unmeasured amount
Two lines in there are the ones that stop a late argument. Posted date rather than value date
will change the number, and somebody will notice. And a stated known gap in the historical
trend means the comparison to last year is caveated on the dashboard rather than defended in a
meeting.
Check the data before promising the picture
Now go to the data, early, and personally if you can. Query the source and see whether the field
exists, whether it is populated, at what grain, from what date, and whether it agrees with the
spreadsheet the business currently trusts. If it disagrees, you have found the real project,
because reconciling a new number with the number people already believe is usually a larger
piece of work than presenting either.
This step is what converts the deadline from a hope into a plan. Data that exists, is clean and
is already in the warehouse makes three weeks generous. Data that requires a new feed from a
supplier, or a field that operations have been filling in inconsistently, makes three weeks
impossible no matter how the charts are drawn — and knowing that on day two is worth more than
any amount of design.
Interrogate the date before accepting the scope
Ask what the deadline is attached to. A board meeting, an audit response, a regulatory
submission, a campaign launch and a new director's second week are five different constraints.
A fixed external event means the date is genuinely immovable and the scope must move, which is a
straightforward conversation once you say it plainly. A date with nothing behind it is usually a
proxy for impatience and can be renegotiated on evidence. Either way, establish what specific
thing must be possible on that date — often it is one number for one audience, in which case the
first release is small and the rest is a roadmap.
Then be explicit about the exchange, because this is the point candidates skip: accepting a date
before agreeing what is delivered on it means you have accepted an unbounded commitment. Fix the
date and fix the scope in the same sentence, in writing.
What you take back at the end of two days
The output of the first two days is not a design. It is a one-page note that the requester can
correct, containing the decision the dashboard supports and who makes it, the two or three
metrics with their agreed definitions, the source and refresh for each, what is in scope for the
date and what is explicitly deferred, the assumptions you are proceeding on, and the risks you
found in the data. Send it, ask for a reply confirming it, and start building against it.
If the requester reads that note and says the decision is wrong, you have saved three weeks. If
they cannot say what decision it supports even after seeing it written down, escalate that as
the finding rather than building anyway. A dashboard commissioned with no decision attached is
one that will be quietly abandoned, and being the analyst who says so early is more valuable
than being the one who delivered on time.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).