READ TIME - 7 minutes ⏳
Email formatting looks broken? click here to view in browser.
The fastest way to build the wrong dashboard is to open the dashboard tool too early.
It feels harmless at first: a blank canvas, a few charts, maybe a filter panel on the side. Progress, apparently. But this is how useful reporting quietly turns into a report with shiny instruments and no agreed destination.
That is the job of START.
START is a simple discipline I've created for answering what needs to be answered before going into development mode. Not after the first mock-up. Not halfway through a workshop. Before. Because the real risk in analytics is rarely bad chart formatting. It is building a report before the team has agreed on what the report is supposed to help someone understand, decide, or follow up on.
The easiest way to hold the whole method in your head is to picture a cockpit.
A cockpit only works when the crew knows the context, knows what demands attention, knows what they need to inspect, knows what decision follows, and knows how they will see whether the adjustment worked. Remove any one of those, and the instruments start looking less like guidance and more like decoration with ambition.
So START begins with Situation.
This is the business context. The frame around the whole dashboard. In your workshop version, the question is beautifully plain: What’s the business context? And then, even better, it turns human: What does the store manager currently use in his day-to-day? That is where a report stops being generic. It is no longer “a sales dashboard” or plain “operations report.” It is a solution for a specific person, in a specific situation, trying to improve or monitor something that matters.
Then comes Trigger.
Not everything deserves a report visit. That is a surprisingly useful design constraint. So the next question is: What demands attention now? Or, in the workshop phrasing, What events or questions should open this solution? That one line changes the posture of the whole product. Instead of becoming a passive wall of numbers, the report becomes something connected to a moment of need. A question appears. An event happens. Attention is required. The report is opened for a reason.
Once the report is open, the next step is Analyze.
Now the question becomes: What should they explore? Not everything the data model can technically show. Not every available slice, toggle, and fancy charts. Just the views that help the user inspect what matters. To make it practical: What comparisons, patterns or segment view matter? That is where good design and dataviz usually become more disciplined. Because attention is limited, and metric definitions can drift, a solid segment logic can quietly change the story. And a report that tries to show everything often helps the user see less.
But even that is not the point.
The point is what happens next, which is why Reconcile / Result matters so much.
This is where the report earns its place. What decisions do they make? That question cuts through a lot of visual noise very quickly. Because if the report supports no decision, validates no action, and changes no conversation, then it may be informative, but it is not yet operational. Your workshop version says it clearly: What actions should this report support or validate? That is the moment where analytics stops being an artifact and becomes part of a workflow.
And then there is the final move, the one many dashboards quietly skip: Track.
How do we learn from outcomes? That question is the difference between reporting as display and reporting as feedback. Here's another way to put it: How do they check if things improved or need follow-up? Without that loop, even a smart dashboard can become a one-way mirror. You look in, discuss, decide, and walk away. With tracking, the report stays connected to reality. It shows whether the action actually changed anything, or whether the team simply had a very confident meeting.
This is why START is useful.
It does not begin with visuals. It begins with a sequence of questions that gives the visuals a job:
- Situation gives the context
- Trigger gives the reason to look
- Analyze gives the path through the data
- Reconcile / Result gives the decision point
- Track closes the loop
Five steps, and suddenly the dashboard is not a collection of charts anymore. It is a tool with a purpose.
That may sound almost too simple. Good. It should.
Most reporting problems are not caused by a shortage of features. They come from skipping the framing work and rushing into build mode. Then the usual things happen. The dashboard grows. The questions multiply. Definitions get fuzzy. People ask for “just one more view.” The cockpit gets more instruments, but not more clarity. A classic outcome in dataviz: more panels, less guidance. Very efficient, in the wrong direction.
And this is where two futures begin to separate.
In one future, nothing changes. Teams open Power BI first. The dashboard grows around available fields, stakeholder requests, and whatever is easiest to surface. It may even look polished. But the user still has to do the real work somewhere else: in meetings, in email, in memory, in side conversations about what the numbers “really mean.”
In the other future, the team pauses before development. They answer the five START questions in plain language. They define the business context. They name what demands attention. They decide what should be explored. They clarify what decisions the cockpit should support or validate. And they agree on how to check whether things improved or need follow-up. The final report is often smaller. Sharper. Easier to use. More obviously tied to a real workflow. Not because it does less, but because it wastes less.
That is the quiet power of my START framework.
It gives both users and report developers a shared discipline before the build begins. A way to make sure the cockpit is being designed for a real journey, not just assembled because the instruments were available.
So before opening Power BI, stop for a moment.
Ask what the business context is. Ask what demands attention now. Ask what should be explored. Ask what decisions need support. Ask how outcomes will be tracked. If those answers are not clear yet, development has not started late. It has not started at all.
And that is good news, because it means the most important design work is still available to do.
See you next week,
Julien
