Design thinking isn't about visual design. It's an innovation approach — combining structured analysis with iterative creativity — that's particularly useful in BI when the problem is real but the solution isn't yet visible.
"Think outside the box." "Look beyond the obvious." These are genuinely well-intentioned pieces of advice. The problem is they are never followed by any instruction on how, exactly, this is supposed to work in practice. Design thinking is my answer to that gap — a structured method for breaking out of the obvious when the obvious isn't working. Contrary to what the name implies, it has nothing to do with visual design. It is about adopting the iterative, hypothesis-driven mindset of a designer when solving any kind of problem.
In my consulting work, most problems have relatively straightforward solutions. They need some structure, some specific knowledge, or a push in the right direction, and the path forward becomes clear quickly. But there's a category of problem that requires something different — the ones where I hear things like "We have the data but we're not using it right" or "I just need the data to do this, but I can't quite explain what this is." That disconnect — between operations and leadership, or between operations and data — is where I reach for design thinking. Not because I know the answer, but because the method is how I find it.
I use design thinking when I know there is a problem or a better way, but I'm not sure exactly what it is.
Design thinking is an innovation approach that combines traditional analysis with intuitive creativity. It is characterized by experimentation and prototyping, and it keeps one thing at the center of everything: the user. The user is the driving force of the product, the primary reason for its existence, and — this is the key insight — the place where the solution will ultimately be derived from. Not from the data. Not from the technology. From the person who has to use the output to make a decision.
In a BI context, think about how a dashboard or reporting suite gets created. The preliminary question — what business question are we trying to answer? — is evaluated first. For example: How many sales will we see at present pace by quarter end? Or: Do we need to pivot our campaign allocation to reach our growth target? With that question defined, you now know three things you need to know before you build anything: the product (the answer to the business question), the components (the sales data, the marketing data, the customer data), and the user (the sales and marketing teams, and possibly leadership). Design thinking gives you the method to work with all three systematically.
The first phase is about learning as much as possible about the problem before proposing any solution. The focus is on understanding the product's components, the target audience, and the issues they face — from as many angles as possible.
Four questions anchor this phase: Who uses this product or service? What are the user's three biggest problems? What makes this product particularly specific to them? How might those problems be solved? You'll generate several answers to each — treat them as hypotheses, not facts, and test them through direct conversations with the actual users.
The discipline here is resisting the urge to jump to solutions. The exploration phase ends when you have a clear, validated picture of the problem state. Not before.
With a clear problem definition in hand, ideation is where you generate solutions — broadly at first, then converging. The goal is quantity before quality: get as many possible approaches on the table as possible before evaluating any of them.
The most useful ideation tool in a BI context is the user journey map — tracing the path a user takes from their first question through to the decision it informs. At each step, ask: what information do they need here? What format serves them? Where do they currently get stuck or go dark? The journey map makes visible all the moments where data could help but currently doesn't.
Ideation ends with a prioritized list of potential solutions — not a final decision. You're still in hypothesis mode.
Prototyping turns the knowledge from phases one and two into something tangible that users can react to. The prototype doesn't have to be functional — it has to be specific enough for users to give you honest feedback about whether it solves their problem.
In BI, a first prototype might be a static mockup in Figma, a rough Power BI layout with sample data, or even a hand-drawn sketch shared in a meeting. The point is not fidelity — it's to make the concept concrete enough to test. The prototype is a question, not an answer: Is this the right thing to build?
Prototyping is where most traditional reporting processes fail: the first version of a dashboard goes straight into production without ever being tested with users. By the time feedback arrives, the cost of changing it is high enough that it doesn't get changed.
Validation tests the prototype against the real problem. Does it actually solve what the exploration phase identified? Can users navigate it without explanation? Does it produce the decision-relevant insight it was designed to produce?
Validation in BI has two layers: usability (can users find what they need?) and analytical validity (do the numbers mean what the users think they mean?). Both matter equally. A dashboard that is easy to navigate but measures the wrong thing produces confident, wrong decisions — which is worse than no dashboard at all.
Validation is also the phase that authorizes iteration. If something isn't working, you return to the relevant earlier phase — not to zero. The method is a loop, not a waterfall.
Design thinking earns its overhead when the problem space is genuinely ambiguous — when the symptoms are clear but the root cause isn't, when users have strong opinions about what they want but aren't sure what they need, or when past solutions have failed in ways that suggest the problem was never quite right to begin with. Those are its conditions.
It is not the right approach for well-scoped technical problems, for work where the requirements are already clear and agreed upon, or for situations where the cost of iteration outweighs the cost of being wrong on the first attempt. A client who needs a specific Power BI report on a specific data source by next Friday doesn't need design thinking. They need execution. Knowing which mode you're in is itself a skill.
When someone in the room says some version of "I know this isn't working but I can't quite explain why" or "I know there's a better way but I don't know what it is" — that's the signal. That ambiguity is exactly what design thinking is built to resolve. It turns a vague problem into a specific one, and a specific problem into a testable solution.