Why the visual should be the last decision you make, not the first.
READ TIME - 5 minutes ⏳
Email formatting looks broken? click here to view in browser.
Here is a scene you will recognize.
A request lands in your inbox. "Can you build me a dashboard to track our sales?" Before you have even finished reading it, your hand is already moving. You open Power BI. You drag a field onto the canvas. You start picking colors.
Fifteen minutes in, you have something on screen. While it feels productive, it is not.
Because you just answered a question nobody asked, with a solution nobody validated, for a user you have not spoken to. And three weeks from now, when the feedback comes in and everything has to change, you will wonder why.
The visual was never the hard part. The thinking that should have come before it was.
The need is not the request
The single most useful habit I have built over the years is this: when someone hands me a request, I assume it is already a solution in disguise.
"I want a table with these twelve columns" is not a need. It is a solution someone arrived at on their own, usually because a table is the only format they know how to ask for. The actual need is buried underneath: a decision they have to make, a question they keep getting asked, a fire they are tired of fighting.
Your job is to dig that need back out. And you cannot do it from inside Power BI. You do it in conversation, before a single visual exists.
The three people in every report request
Every report request, whether anyone admits it or not, involves three people.
Charles is the end user. He was never consulted. She opens the report every morning, then quietly rebuilds her own version in Excel on the side, because the dashboard does not tell her what she actually needs to know. Nobody knows she does this.
Donatien is the requester. He knows exactly what he wants. Or he thinks he does. He expresses the need in two lines, in an email sent on a Friday at 5pm, and he validates the result without really looking at it.
Julia is the report builder. She receives the request and opens Power BI before she has even hung up the phone. She does her best with vague specs and spends most of her time guessing what other people actually want.
(see what I did there? :) )
The tension is right there in the setup. Julia builds for Donatien, but it is Charles who should be driving the whole thing. And Charles has never been in the room.
Good design process is, more than anything, the discipline of getting Charles into the room before you build.
The double diamond, applied to reports
There is a simple framework from the design world that maps almost perfectly onto report building. It is called the double diamond, and it has four phases across two distinct movements.
The first diamond is about the problem. You start by diverging: explore what is really being asked, who reads it, what decision it supports. Then you converge: define the actual problem worth solving. Most report requests die here, because nobody bothered to define anything. They jumped straight to building.
The second diamond is about the solution. Again you diverge: what could answer this problem, sketch options, consider formats. Then you converge: pick the approach, and only then choose the visuals that serve it.
Notice where the visual lives. Far right. Last phase of the second diamond. It is the consequence of good thinking, never the starting point.
So where does Power BI come in?
At the end. Genuinely at the end.
By the time I open the tool, I already know who the report is for, what decision it supports, how often it will be read, and which question needs to land in the first three seconds. The visual choice at that point is almost mechanical, because every constraint that should drive it has already been defined.
That is the whole reframe. Opening Power BI early feels fast, but it is the slowest possible path, because you build, get it wrong, and rebuild. Opening it late feels slow, but it is the fastest, because you build the right thing once.
To remember
- The request is usually a solution in disguise. Your job is to find the need underneath it.
- Get the real end user into the room before you build, not after the complaints arrive.
- The visual is the last decision in the process, never the first reflex.
- If the key answer is not visible in 3 seconds, your layout is working against your user.
Next issue: the design tokens that turn a one-off report into a system. Until then, here is my question for you: what is the worst "give me a table with everything in it" request you have ever had to unwrap? Hit reply, I read everything.
See you in two weeks,
Julien
