Stairways to Nowhere: Why the Blueprint Comes First
Blueprints matter more in the age of AI, not less.
It’s called a mystery house. The mystery isn’t ghosts—it’s why anyone would build it this way.
The house wasn’t built for you to live in. It was built for one person—and it worked for her. But walk through it now, and you feel the difference between a space designed for its owner and one designed for anyone else.
It feels like a carnival fun house. It’s actually a mansion in San Jose, in the heart of Silicon Valley. The Winchester Mystery House was constructed continuously for thirty-eight years by its owner, Sarah Winchester, with no master plan. Room after room added without anyone asking how people would move through them. Today it’s a tourist attraction. People pay to experience the disorientation.
She taught herself architecture from journals: an amateur with extraordinary resources, accountable to no one but herself. When a hallway came out wrong, she tore it out. When she wanted a room, she added it, whether or not it connected to anything. Staircases climb into ceilings. Doors open onto walls. The dysfunction didn’t matter because she was the only user.
Software teams build houses like this every day.
It happens when teams build in silos — each optimizing for its own roadmap, its own definition of done, its own launch. Each room works. The journey between them breaks.
The Missing Role
Over thirty years ago, Mitch Kapor named this problem. Kapor had founded Lotus and created Lotus 1-2-3, the spreadsheet that turned the PC into a business tool. He wasn't an outsider critiquing the industry; he was someone who'd built massively successful software saying we're doing this wrong.
His “Software Design Manifesto” argued that software needed a role like the architect, someone who asks how people will move through what you're building before construction begins.
I discovered the manifesto in Terry Winograd’s Bringing Design to Software, a title that made the argument before you opened the cover. It gave voice to a journey I was already on. I'd trained as an architect and shifted to software before the web went mainstream. The need was the same, the scale was global. Kapor was naming the role from inside the industry.
His reasoning was simple: when you design a house, you talk to an architect before you talk to an engineer. Not because engineers aren't essential, they are, but because the first questions aren't structural. They're about how people will live. Where should the kitchen be relative to the dining room? That emerges from understanding human purposes, not technical constraints. Software, Kapor argued, had skipped this step entirely.
“One of the main reasons most computer software is so abysmal is that it’s not designed at all, but merely engineered.” — Mitch Kapor
Two thousand years ago, the Roman architect Vitruvius argued that good buildings exhibit three qualities: firmitas, utilitas, venustas. They're built to last, they fit the need, and they reward the experience of being in them. Kapor saw the same test for software.
Three decades later, Kapor’s argument feels less like a manifesto and more like a timeless principle, one that becomes even more critical in an agentic world.
That’s why “how people move through what we’re building” isn’t a design preference. It’s the foundation.
A blueprint isn’t a spec. It’s a shared view of how people will move through what you’re building: how this feature connects to the next one, what happens after someone completes a task, where they go when something goes wrong. It keeps the team oriented to the person on the other end, not just the product taking shape.
And like any blueprint, it has to go deeper than the rooms: the permissions architecture, the data boundaries, the failure modes, the trust infrastructure that holds everything up.
The people inside the building are depending on that infrastructure whether they know it’s there or not. They don’t see the footings. They just trust the floor won’t give way.
We’ve seen too many times what happens when that layer is assumed rather than designed. Data breaches aren’t surface failures. They’re architectural ones — something that should have been in the blueprint wasn’t.
In an agentic world, where systems act on people’s behalf and have access to their accounts, files, and finances, the cost of getting it wrong isn’t inconvenience. It’s exposure.
What’s Changed
Design leadership has become essential to technology innovation. What Kapor described as a missing role is now embedded across the industry — in product teams, in engineering orgs, in how companies hire and build.
In 1996, when his manifesto reached print, roughly 36 million people were online. Today it's 5.5 billion, across 18 billion connected devices. The discipline didn't just evolve. The scale grew exponentially.
But the organizational challenge Kapor identified persists.
Teams still build in silos, and the rigor to connect learning across user journeys rarely survives the pressure to ship. Kapor noticed something I've seen throughout my career: when software fails people, they blame themselves. “People are embarrassed to say they find these devices hard to use,” he wrote. “They think the fault is their own."
If anything, the pressure has intensified. Jenny Wen, Head of Design for Claude at Anthropic, described the shift on Lenny's Podcast: planning and prototyping work that once consumed 60 to 70% of a designer's time has dropped to 30 to 40%. Vision horizons that once stretched years now compress to months. The blueprint work isn't being eliminated. It's being squeezed until it may not function as a blueprint at all.
But principles don’t self-implement. Sarah Winchester could afford to tear out a hallway when it came out wrong and try again. She had the budget to iterate forever. That’s a rare luxury.
There’s a brutal asymmetry here. A tiny handful of companies can afford to fix the house after it’s already built. Google is one of them. They’ve published this as explicit principle: “prioritize landings over launches”, because they’ve seen what happens when incentives reward shipping and the experience fractures. And they can bankroll the unsexy work: refactors, consistency, performance, accessibility, the connective tissue that makes the whole thing feel inevitable instead of accidental. Alphabet generated $73.3 billion in free cash flow in 2025 alone.
Most companies don’t have that luxury. Not the cash cushion, not the talent density, not the time. So if you skip blueprint work up front, you’re not being bold. You’re deferring the bill. You pay later in engineering thrash, support load, and the more dangerous cost: customers who hit friction in the journey and leave because it’s easier than fighting your organization’s seams.
The cost is measurable. Gartner found that 96% of customers who experience high-effort interactions become more disloyal, compared to just 9% for low-effort experiences. U.S. companies lose an estimated $168 billion annually to avoidable churn. Customers who rate their experience highest spend 140% more.
The Winchester problem isn’t just bad design. It’s the exit sign for customers.
Sometimes a napkin sketch is enough to align on how to serve people. The blueprint should match the stage. When you're testing a hypothesis, when learning requires something to be live, precision would be premature. And when you're building something that needs to hold together across teams and time, that shared understanding becomes your foundation.
I’ve seen what becomes possible when teams invest in that foundation. At Google, I led user research and design for unifying fragmented payments experiences into a single platform, what became Google Pay. At Meta, we brought fragmented business tools together into Meta Business Suite, unlocking product-market fit for millions of small businesses.
Different companies, same opportunity: the blueprint work turns inherited complexity into impact.
The pressure to copy makes this harder. When a competitor ships something and leadership asks “why don’t we have that?”, the blueprint work feels like a luxury.
Copying is a version of the same mistake. You import someone else’s room without understanding how it connects to your house, or whether their house had the same floor plan to begin with.
Amazon had a phrase that shaped how I think about this: “We don’t obsess over competitors. We obsess over customers.” Customer obsession forces the blueprint work. Competitor obsession lets you skip it.
The Agentic Shift
When building was slow, unclear intentions got corrected along the way. Friction created space for reflection. The blueprint could be fuzzy because construction would sharpen it.
That’s less true now. AI can generate entire products in hours. If your blueprint is unclear, you’ll get a well-constructed house where the rooms don’t connect, and you’ll get it fast.
There's a reasonable objection here: AI-powered products are non-deterministic. You can't mock every state. But that misidentifies what the blueprint is for. You're not predicting every output. You're deciding how agents relate to each other, what context they share, what happens when one fails. The less predictable the rooms, the more the hallways matter.
The promise of AI is speed. Ship faster, build faster, iterate faster. But speed is only valuable if you’re moving in the right direction. A blueprint doesn’t slow that down. It’s what makes the speed mean something. Without it, you’re not moving faster. You’re just getting to the wrong place sooner.
The data bears this out. An MIT study of 300 enterprise AI deployments found a consistent pattern: failure wasn't driven by model quality. It was driven by approach.
Teams layering AI onto existing workflows without redesigning the journey first. The technology worked. The house didn't. That's the blueprint problem, at billion-dollar scale.
Imagine agents acting on your behalf. One books your flight, another reserves a hotel, a third checks your calendar, each completing its task. But no one mapped how they'd work together. The flight lands at midnight, the hotel check-in closed at ten, and your calendar shows a breakfast meeting you'll never make.
The agents weren’t broken. They were just never introduced. Each did exactly what it was designed to do, in isolation.
But when orchestration works, it’s invisible in the best way. Think about what happens when you request an Uber. One system predicts demand across the city, another sets pricing based on supply, a third matches you with a driver weighing distance, traffic, direction, and driver preferences, and a fourth optimizes the route in real time. Each component feeds data to the others, creating feedback loops that improve with every ride. Fifteen million trips a day, matched in milliseconds. You don’t see any of this. You just see a car arrive. Google Photos works the same way — you don’t ask it to remember your best moments; it just does. That’s what happens when the rooms line up.
That’s what good orchestration looks like: agents working in the background while you get where you’re going. The blueprint came first. And at the center of that blueprint is a question that turns out to be surprisingly hard to engineer: what does this person actually want? Amazon calls it intent detection, the orchestration layer’s ability to correctly read a user’s goal before routing to the right agent. When it works, the experience feels seamless. When it fails, the cascade is immediate: wrong agent, wrong response, compounding frustration. Getting that question right is now a core engineering challenge, not a design afterthought.
Agentic customer support is the counterexample. You start hopeful, but quickly you’re shuttled between agents: “order details,” “returns,” “tech help.” None remember you. Each door leads to a new room, and you’re not sure there’s an exit. You end up in a closet, no context, no way out, and drop the chat. Next time, you’ll shop somewhere else.
Most production failures in agentic systems aren't model failures. They're architecture failures, the connections between agents, not the agents themselves. Rooms again.
Well-designed agent systems have an orchestration layer, something that holds the user’s goal and coordinates the sub-tasks. But that layer doesn’t design itself. Someone has to map the dependencies, define the handoffs, decide what context each agent needs from the others. Service designers call this the backstage. In an agentic world, most of the experience is backstage. As one 2026 design analysis put it: we’re no longer designing screens for users, we’re designing intelligence that acts for them. The interface has moved backstage. So has the blueprint work.
Kapor understood this when the medium was screens. The principle holds as the medium shifts to agents. Teams who bring that rigor to orchestration, who design the backstage as intentionally as they once designed the interface, will build experiences people actually want to live in.
The craft isn’t disappearing. It’s shifting from construction to intention.
The tools will keep getting faster, and some interfaces may fade. What won’t compress is the human work of understanding: observing behavior, mapping journeys, asking how people actually move through their lives. There’s no shortcut to the conversation where someone shows you what they really need, as opposed to what you assumed they wanted.
That’s the blueprint work. As building accelerates, the cost of skipping it doesn’t disappear. It compounds.
The Cascade
Kapor’s question, do we have shared understanding of how people will move through what we’re building, was written for a conference in 1990. It’s still the right question.
Enforcing it is the real work. When teams are rewarded for shipping features, asking how people move through the whole experience feels like friction. It’s not. It’s the blueprint. Without it, you’re not designing like an architect. You’re just adding rooms.
Brilliant work is being done across the industry by people asking that same question. And there are still broken experiences, teams adding room after room without stepping back to see the whole.
The Winchester House still stands. Stairs to nowhere, doors to walls. It worked for the woman who built it. Today it’s a tourist attraction. People pay to experience the disorientation, to wander through something that was never designed with them in mind.
Most of us are building for people we’ll never meet. That’s the opportunity: to build somewhere they want to live.
Mitch Kapor’s “A Software Design Manifesto” was delivered at Esther Dyson’s PC Forum in 1990. It appeared as the opening chapter of Terry Winograd’s Bringing Design to Software (Addison-Wesley, 1996).
Designing Impact is a series by Scott Hines about work that lasts — why some ideas and innovations continue to shape the world long after the people who created them have moved on, and what it takes to build that way.