I was in a service blueprint session. We were mapping a client onboarding process end to end, the kind that spans multiple teams, multiple specialties, and had been running manually for longer than anyone could remember.
We called it "sum of the parts" because no single team owned the whole thing. Everyone owned a piece. Nobody owned the seams.
When we got to the backstage (the systems, the data flows, the handoffs nobody sees) we ran into a problem. One swim lane wasn't enough. It was worse than that. One swim lane was irresponsible. There were three systems of record, loosely defined, occasionally overlapping. One of them was an Excel spreadsheet.
The data was a mess. And the more we mapped, the clearer it became why.
The process had started analog. Phone calls. Emails. Document exchange. Information collected informally, passed manually, re-entered by hand at every stage. Teams downstream never had everything they needed because teams upstream had no structured way to give it to them. The swivel chair was real. People were doing the same work twice because the data didn't travel with the process.
Nobody designed it that way. There are no bad dogs here. It grew organically from a time before there was a digital process to initiate from. The question nobody had ever asked was the one that stopped us cold in that session: how do you implement a system of record when the process starts with a phone call?
That's not an engineering problem. That's a design problem that created every other problem downstream.
I've heard senior leaders say that data doesn't matter to design in practice. "That's what ontology is for."
That's wrong, but not because ontology doesn't matter. An ontologist defines what data is across a system. A designer determines what it has to survive in the real world. Those aren't competing jobs. They're the same coin. And both of them require designers who actually care about the data.
Going toward that problem, the one that looked like someone else's, turned out to be the most clarifying work I've done. The data that needed to populate our systems arrived by phone call, email, and informal conversation, and was never designed to be captured at all. That gap between what a data model expects and how information actually moves through an organization is a design problem. It always was.
Here's why this is getting more expensive.
Every AI feature, every ML model, every LLM integration you're hoping to unlock is only as good as the data underneath it. Garbage in, garbage out has been a cliche for decades. But nobody says out loud who creates the garbage.
We do.
When we design a free-text field instead of a structured input. When we let users skip the fields that matter. When we build an onboarding flow optimized for completion rate that captures nothing useful about the person who just finished it. Every one of those is a data decision. Most designers making those decisions don't know they're making a data decision.
And the data that goes missing isn't random. Freeform fields fail everyone, but they fail edge cases first. The person whose situation didn't fit the dropdown. The context that got collapsed into a notes field. The user whose needs were always a little outside the pattern and whose data can now never be standardized, queried, or learned from. Every future feature built on that data will carry that absence forward.
That's the gap. And it compounds.
The implication isn't that designers need to become data engineers. It's that we need to think one step further than the screen.
What happens to this input after the user submits it? Where does it live? What does it need to become? Who else needs it, and in what form?
Those are design questions. We just haven't been claiming them.
Good data is the foundation of everything we're trying to build. Designing for capture is designing for every person who will ever interact with that system, including the ones whose situations are hardest to anticipate, and the ones who haven't arrived yet.
That's always been a design responsibility. We just didn't know it.