Before the Dashboard

How Jess Steele and Insight x Design think about building data infrastructure

Step 1 — Start with the questions

Before touching a single system, Jess wants to know what you actually need to know — and why.

This sounds obvious. It is not obvious. Most organizations skip it entirely and jump straight to tools, dashboards, or whatever a funder asked for. And then they end up with data that answers someone else’s questions instead of their own.

“Lots of nonprofits, based on their size or scope, get stuck because they’re like, well, we can be scrappy — this funder wants this, that funder wants that, so we’ll just build systems to report against those. And then they’re missing the larger picture of what their program is actually doing.”

Here’s the thing about why that actually matters — and it’s something Jess learned watching her husband, a high school principal, bring program after program into his school. “The effectiveness varies every single year because of the person implementing it,” she says. “If you have a good person in that role, they could be running a mediocre program and the kids can still get phenomenal outcomes.” The instinct about what’s working is often right. But without data, you can’t see why it’s working, or where it’s not, or what factors are actually driving the difference. “Having the data gives you the segmentation and the ability to see — what are the factors that are making this successful? What are the factors leading to lower impact in that area? And that can be a really hard question to answer without it.”

The fix is a data strategy conversation — ideally with leadership, before anything else. Not a planning retreat. Not a full-day workshop. A real, focused conversation with the following questions:

• What are we trying to understand? 
• What decisions do we need to make? 
• What does good look like — and how would we know if we were getting there?

Jess runs these as individual interviews first — 30–45 minutes with executive and program leadership separately — and then brings the group together to align. The reason? People often have different answers. And surfacing those differences early is a feature, not a bug. 

“Do the individual interviews before the group session — always,” she says. “People tell you very different things one-on-one than they will in front of their colleagues, and you want to know that before you’re all in the same room.”

Step 2 — Audit what you have

Once you know what you need to know, the next question is: do you actually have the data to answer it?

This is the data audit — and it’s almost always more illuminating than people expect. Not because the findings are surprising. Usually they’re not. “The audit is rarely surprising to staff,” Jess says. “They usually already know what is and isn’t working. What it does is make the informal visible — the workarounds, the shadow spreadsheets, the data no one trusts.”

A real data audit maps three things:

The systems — Every place data lives in your organization. The official ones (your CRM, your database, your finance system) AND the unofficial ones (the 14 Google Sheets your program team is maintaining, the paper intake forms from 2019, the Gmail inbox where some of your referrals are living). All of it.

The ownership — Who is accountable for each data domain? Who’s responsible for day-to-day quality? If the answer is “no one,” that’s important information. Unowned data is unreliable data.

The quality — For each data source, how complete is it? How accurate? How consistent? And — critically — do the people who use it actually trust it? “Data that exists but no one believes is not useful data,” Jess says. “If your team is making decisions based on instinct because they don’t believe the numbers, that’s a quality problem even if the numbers are technically accurate.”

Here’s something worth saying out loud: you don’t have to bring every possible data source into the centralized infrastructure you’re building. The audit isn’t about cataloguing every system, spreadsheet, and inbox your organization has ever touched — it’s about understanding what you have relative to what you actually need to know.

Jess is direct about this: “Some leaders want every possible data source in there. But if you include everything, the cost in time and resources goes up — and you end up with a lot of data that isn’t actually helping you make better decisions.” The goal isn’t a perfect, complete picture of everything. It’s a clear enough picture to take confident next steps.

Start with the questions that matter most. Everything else can wait.

And yes, this is where it can get a little politically interesting. In one project, the executive director wanted everything centralized — including the finance data from QuickBooks. The finance team had a different opinion. “The CFO was pretty much like, nope, this is ours, we’re holding it — totally understandably,” Jess says. 

Her move in those moments: come back to the questions. What are we actually hoping to do with this data? Do we have proxies that already get us there? What problem are we really trying to solve? It doesn’t always resolve the tension, but it usually moves it forward.

Step 3 — Build the roadmap

The audit tells you where you are. The roadmap tells you what to do about it — and in what order.

This is where most organizations want to skip ahead. “Many organizations want to jump straight to a dashboard or start using AI for analysis,” Jess says. “The roadmap helps build the case for starting with the unglamorous stuff first: definitions, ownership, data entry standards. That’s what makes everything else trustworthy and possible down the line. The goal is to move slow to move fast.”

A good roadmap is phased — usually across 60, 120, and 120+ days — and prioritized by impact and feasibility. Not everything can happen at once. And some things have to happen before other things can work at all.

One of the most important (and most skipped) items on almost every roadmap: metric definitions.

This sounds small. It is not small. Even a single metric can take weeks to get right — because agreeing on what it means is only the first step. Jess worked with a program that needed to define “solve time” for a case management system. The questions came fast: Does the clock start when someone submits an intake form, or when they’re assigned to a staff member? What if the staff member is in a different time zone? Do weekends count? What happens when someone goes on leave and coverage shifts? “That one metric ended up as a four-page SQL query,” she says. “And that was the right outcome — because the number finally meant something everyone agreed on.”

The goal isn’t just the definition. It’s cementing it within the infrastructure itself — so it doesn’t exist in ten different places, meaning ten different things.

Data that exists but no one believes is not useful data. If your team is making decisions based on instinct because they don’t believe the numbers, that’s a quality problem even if the numbers are technically accurate.

Step 4 — Build the infrastructure

Now — finally — you build.

And because you’ve done Steps 1–3, you know exactly what you’re building and why. You’re not adding systems because a funder asked for them or because a dashboard looked cool at a conference. You’re building toward specific questions, with specific owners, defined metrics, and a clear sense of what good data quality looks like.

What this actually looks like varies enormously by organization — from a simple centralized spreadsheet with clear ownership to a full data system pulling from multiple sources in real time. But the principle is the same: bring the right data into one place, clean it up, make it usable, and make sure everyone who needs it can get to it.

The clearest picture Jess can offer of what’s possible when the foundation is solid? Virtual Support Services at Think of Us — a program she supported for several years.

The program had four data sources: a case management platform, a phone call transcription tool, customer satisfaction surveys, and an internal resource database. Jess and her team built a centralized infrastructure that brought all of it together. What came out the other side was remarkable. But what stands out isn’t the dashboards. It’s what happened to the people using them.

The analysis was only as good as the systems underneath it. And those systems were almost always severely lacking.

Community responders — the staff supporting people navigating housing instability and crisis — used to spend significant time on a scavenger hunt every time they had a returning client. No centralized view, no linked history. Just clicking around hoping to piece together what had happened before. After the infrastructure was in place, when a returning help-seeker came in, the system automatically matched them to every previous interaction, generated a comprehensive summary of their history and key takeaways, suggested next steps, surfaced every resource that had previously been recommended to them and summaries from any previous satisfaction surveys they had completed  — all in real time.

“The administrative burden dropped in an incredible way,” Jess says.

The ripple effects went further. Managers started using data dashboards as the basis for every one-on-one — staff coming in prepared with their own metrics, their satisfaction scores, their response times. Conversations that used to be vague became specific. And the relationship with funders shifted entirely. “The team was able to be proactive with the type of data they were able to produce,” Jess says. Using AI layered on top of the clean infrastructure, they could answer questions like: over the past month, what emerging themes came up with help seekers? What gaps in services are people running into? What’s bubbling up that’s important not just for our program quality but for the whole state?

The California Department of Social Services (CDSS) started coming to them directly — trying to understand why people were having such a hard time navigating services on their own, where the gaps were, and what needed to change systemically. “Funders really, really liked that part.”

None of it would have been possible without the foundation underneath it.