The Problem With Data That Nobody Talks About
Most people dump a spreadsheet into a dashboard tool and call it done. The numbers are there. Nobody reads them. I watched a client spend three weeks building what they thought was a killer report, then realize the CFO opened it once, saw twelve charts, and went back to email. That's not a dashboard problem. That's a narrative problem. The core idea is straightforward, even if the framing sounds fancy. You're not just presenting data. You're designing an experience where the data leads somewhere. The narrative isn't fluff you add on top. It's the structure that makes the numbers matter to whoever has to act on them. Here's how it actually works in practice. I've used this framework across a dozen engagements now, mostly with mid-size companies that have solid analytics teams but keep producing reports that gather dust. The pattern is always the same: great data, zero retention. People close the tab. They never come back.
Start With The Question, Not The Data
This is where most people blow it. They open their analytics platform and start pulling metrics because they know how to. The right first step is writing down what decision needs to happen because of whatever you're building. Not "what insights can we surface?" but "what is the reader going to do after they see this?" I had a project where the client wanted a real-time supply chain monitor. Twenty widgets, live updates, drill-through capability. Beautiful. Useless. The actual decision was whether to reroute a shipment before it left the warehouse. They needed one number, a threshold callout, and nothing else. The twenty widgets were noise. We rebuilt it around a single green-red indicator with a timestamp. Adoption jumped from roughly 8% daily active users to about 74%. That's the difference between designing for curiosity and designing for action.
The Three-Layer Structure
Every piece of data work under this framework needs three layers. I know that sounds like consultant-speak, but it's not. It's just accounting for how human attention actually works. Your brain doesn't process a chart the same way it processes a headline. The layers are separate by necessity, not by preference. The first layer is the claim. One sentence that states what the data says. Not "Revenue trends" but "Revenue dropped 14% in Q2 due to a single supplier outage." The second layer is the evidence. The chart, the table, the supporting numbers that prove the claim. The third layer is the implication. What should happen next given what you just proved. I ran into an edge case recently that exposed a flaw in how people typically stack these layers. A healthcare analytics team built a sepsis detection dashboard using this three-layer model. The clinical leads approved it, the engineers built it, and then nobody used it. The problem wasn't the structure. It was the implication layer. The dashboard showed risk scores and trend lines but never specified what nurse should do at which threshold. It implied action without stating it. We added a clear protocol matrix mapping score ranges to specific interventions and response times. Usage went from intermittent to daily within two weeks. The data was always right. The narrative was incomplete.
Get the Full Details
Design Choices That Matter More Than You Think
Color isn't decoration. It's information. Red should mean something specific and consistent, not whatever looks good next to blue. I've seen teams use green for positive metrics and red for negative ones, which sounds fine until you have colorblind stakeholders who can't tell the difference. That's not inclusive design. That's an oversight that costs you readers. Chart type selection matters more than most people admit. A bar chart for time series data is a choice that signals you didn't think about what you're showing. Line charts for continuous measures over time. Bar charts for categorical comparisons. Don't use a pie chart unless you're comparing three items maximum and need to show parts of a whole. The people who say "it depends" are usually wrong. It rarely depends. Whitespace is a functional element. Crowded dashboards aren't dense with information. They're dense with friction. Every extra element competes for attention against every other element. If you have twelve metrics on one screen, you effectively have zero. I typically trim dashboards by half and then half again. The remaining elements get the attention they deserve.
When This Approach Fails
I should be honest about the limitations. This framework assumes the audience has time to read. It assumes they're being asked to make a decision, not just stay informed. If you're building something for regulatory compliance where the requirement is to display every available metric, narrative design won't help. You'll get the audit review, but nobody will actually understand what they're looking at. It also breaks down when your stakeholders are fragmented. A single narrative works when you have one primary reader. Give me a board of directors with seven members, each from a different department, and I'll give you seven different narratives they each need. The framework still applies, but you're really building seven different experiences, not one. That's a scope multiplier most people don't account for. There's also the latency problem. If your data refreshes hourly and your narrative depends on real-time decisions, you've got a fundamental mismatch. I worked with a trading desk that wanted narrative-driven reporting but their data pipeline had a forty-five-minute delay. No amount of good design fixed that. They needed infrastructure, not insight architecture.
A Practical Walkthrough
Let me walk through a recent engagement to show what this looks like end to end. A logistics company came to me with a driver performance dashboard. Fourteen KPIs, heat maps, leaderboards, comparison tools. Standard analytics portfolio stuff. They wanted drivers to improve. The data wasn't helping them do that. First, I stripped it down to three questions: Is the driver on time? Are they safe? Are they efficient? Everything else was secondary. Second, I built a single page per driver with one clear claim at the top, supporting charts below, and a coaching recommendation at the bottom. Third, I gave supervisors a weekly narrative digest, not a login requirement. Instead of pulling up the dashboard and figuring out what to do, they got an email with three bullet points per driver and a suggested conversation starter. The shift from exploratory tool to directed communication changed everything. The drivers stopped feeling surveilled and started feeling coached. The supervisors stopped ignoring the platform because it required too much cognitive effort to extract meaning. Driver improvement metrics moved from flat to a four percent quarter-over-quarter improvement within three months. Not because the data changed. Because the narrative did.
What To Do Monday Morning
Pick one dashboard or report that nobody uses. Write the claim it should be making in one sentence. If you can't, that's your first problem. Identify the single most important decision the reader should make after viewing it. Redesign around that decision, not around the data you have available. Cut everything that doesn't serve it. Add an implication layer that specifies what happens next. The Oshea Russell framework isn't a product you download. It's a discipline. The resources out there that claim to package it are really just teaching you to organize your thinking before you open any tool. That's the hard part. The tool part comes after. Once you can state what your data is claiming in one clear sentence, everything else gets easier. Most people never get that far. They skip straight to the chart library and wonder why nobody cares about what they built.
