The beautiful dashboard nobody used
A distribution company spent three months building a sales dashboard. It was genuinely impressive: interactive charts, drill-down by region, color-coded performance bands, month-over-month comparison, export to PDF. The BI consultant delivered it on time, within budget, and the presentation to the executive team went well.
Six months later, we asked the sales manager how often she used it. "Honestly? I check it maybe once a month. I get what I need from the weekly report my team sends me in a spreadsheet."
The dashboard wasn't wrong. The data was accurate. The problem was that it answered questions the company hadn't actually committed to acting on. The regional drill-down assumed someone had regional accountability — they didn't yet. The color-coded performance bands assumed agreed-upon targets — those were still being negotiated. The PDF export existed because someone in the meeting mentioned they'd want to share it in board meetings — which happened twice a year.
Three months of build time, mostly solving problems that didn't exist yet.
What goes wrong with first dashboards
The pattern repeats consistently. A company decides it needs "better visibility into the business." They hire a consultant or spin up a BI tool. The first deliverable is scoped based on what sounds important rather than what decisions it will actually change.
The result is a dashboard that reports the business without connecting to how the business is run. It shows what happened. It doesn't change what will happen — because it was never integrated into the decision-making process that could use it.
Three failure modes we see most often:
Designed for the demo, not for the Monday morning meeting. Dashboards built to impress in a presentation are often designed around visual variety. Real operational dashboards are used by one or two people, first thing in the morning, looking for specific answers. They should be boring.
Too many metrics. A 12-metric dashboard creates the same problem as no dashboard: if everything is visible, nothing is prioritized. Operational dashboards that get used consistently almost always have 3–5 key numbers, nothing more.
Data access resolved after design. The visualization is designed first, then somebody realizes the underlying data isn't clean enough, isn't in the right system, or requires a join that doesn't exist yet. The build stalls or ships with gaps that make the dashboard unreliable.
Start ugly, on purpose
The approach that actually produces dashboards people use:
Start with a spreadsheet. Before building anything in Looker Studio, Metabase, Power BI, or any other tool, answer the actual question in a spreadsheet. Manually. Pull the data from wherever it lives — export from the ERP, download from the CRM, copy from the report — and calculate the number by hand.
If you can't answer the question with a spreadsheet and two hours of work, you don't yet understand the question well enough to build a dashboard around it. The spreadsheet exercise forces clarity: what data do you actually need, where does it come from, and what calculation gives you the answer.
Validate with the person who will use it. Show the spreadsheet to the person who is supposed to act on the number. Ask them: if this number was 20% lower than it is today, what would you do differently? If the answer is "I'm not sure" or "it depends," the metric isn't operational yet. Either sharpen it or replace it.
Build only what passed validation. Once you have 3–5 metrics that someone will demonstrably act on, build the simplest possible version. No drill-downs until someone asks for them. No export buttons until someone needs to export. No historical comparison until someone asks how far back.
The first version should take days, not weeks. It should look like what it is: a fast answer to a clear question.
The numbers on iteration
A well-scoped first dashboard — built ugly and iterated based on actual use — typically finds its stable form in 3–4 cycles over 6–8 weeks. Each cycle adds one thing someone actually asked for and removes one thing nobody used.
A polished dashboard built upfront typically requires a full rebuild within a year, once the questions the business is actually asking become clear. The rebuild costs as much as the original.
The ugly-first approach isn't about saving the build cost. It's about spending the build cost on the right thing — which you can only learn by using a rough version first.
When you should invest in polish upfront
There are legitimate reasons to build a well-designed dashboard from the start:
External reporting. If the dashboard is shown to investors, board members, or clients, presentation quality matters. A spreadsheet screenshot sent to a board is different from a spreadsheet used internally for operations.
Fixed regulatory reporting. If the structure of what you need to report is mandated — financial statements in a specific format, compliance reports for an auditor — there's no discovery phase because the requirements are fixed. Build it right the first time.
Team-wide visibility displays. A dashboard displayed on a screen in a warehouse or call center floor, where the goal is ambient awareness rather than individual decision-making, benefits from visual clarity from the start.
But these are specific cases. For the general "we need better visibility into our operations" request — which is the most common one — ugly and fast beats polished and slow almost every time.
The practical starting point
If you're about to start a dashboard project, run this exercise first:
- Write down the three decisions you make every week that you currently make without reliable data
- For each decision, write down: what number would help you make it better?
- Pull that number from whatever source it lives in today — manually — and calculate it for the last four weeks
- Show it to whoever makes the decision and ask: is this the right number?
If you can do that for all three, you have the requirements for your first dashboard. It'll take a few days to build, not months. And because it's grounded in actual decisions, someone will actually use it.
If you're starting a data initiative and want to avoid the expensive first rebuild, we can help scope it from the question side rather than the tool side. Let's talk about your data and analytics needs.