How to build the thing that gets you to the thing
A practical guide to making systems that serve people
Last week in Signals, I wrote about Halt and Catch Fire, and the importance of remembering that the best tools aren’t the point; they’re the thing that gets you to the thing. The web wasn’t the thing. Neither was the computer. And AI isn’t the thing, either.
The thing is what people do, make, discover, or become…once the system itself fades away into the background.
This piece is a follow up. A little more of a practical guide. That previous piece was about why we build. This is about how.
1. Start with what it enables
You’re not building something if you don’t know what it enables. You’re just assembling parts in a vacuum and hoping they come together as a product or a system.
Good systems begin with a clear sense of what the desired outcome is, the problem that you’re solving.
What should people be able to do that they couldn’t do before?
What will be easier, faster, and more consistent to do?
Who benefits from this…and how?
When you start designing something, start with a sentence of intent.
When I was at IBM, we used a “who, what, wow” model.
“This system will allow [who] to [do what] in a way that [wows them].”
2. Don’t build a thing to have a thing
Nobody builds a design system for the sake of having a design system. We build design systems to enable people to do better work. That same logic applies to everything from AI integration to internal documentation.
So if your goal is “to implement AI” or “stand up a new system,” then you’ve already missed the point.
And if the system you build doesn’t reflect real behavior, not an idealized way of working, then you’re building something that looks right instead of being actually fit for purpose. Systems should honor desire paths, not try to break them.
3. Make the system vanish
The best systems are invisible. They disappear. Not in a literal sense, but they recede from being the center of attention. If people talk about the system, more than what they built with it, then there’s probably something wrong.
I’m not talking about lack of adoption. In fact, it’s the point at which adoption is so natural, because the system has become infrastructure. Think of it like electricity - we don’t think often about “using electricity”, it’s infrastructure to our lives.
In a system that’s working, you should be able to do things like:
Create something useful without fully knowing how the system works.
Be able to move from expressing your goal in natural language to starting to build.
Take action without needing to translate between your intent and the system interface.
4. Codify your intuition
Really good systems are the ones that encode what works so that other people don’t have to guess. The best ones do that and also support improvisation.
In practice that means:
Safe defaults, but adjustable.
Documented practices that are governed, not enforced.
The kind of guidance that surfaces before someone asks the question.
If a system starts to represent the shared intuition, and scales it, you’re helping people get the best possible start.
5. AI is a translator, not a controller
The promise of AI in all this isn’t just automating it for automation’s sake. We want to use it to translate. To help us turn our raw intent into structured output.
A good AI-supported system doesn’t try to replace creativity. It wants to accelerate it.
Turn sketches into code.
Turn briefs into outlines.
Turn documentation into conversation.
At its best, we should be thinking of AI as a helpful translator between human intent and a digital structure.
6. You’re doing it right if nobody talks about it
You’ve built the right thing when people stop noticing it. When teams just get on with the work; moving faster, asking fewer questions.
The thing that gets you to the thing? It doesn’t need applause, it really just needs to work.
So when you do it right, people spend less time learning, and more time building what matters.
Over the coming weeks, I plan to expand on each of these six ideas in more detail. Breaking down the practical and messy work of building systems that serve people. One of these principles per post, using real examples and honest pitfalls (including cautionary tales from my own mistakes!). Maybe even a checklist or two.
The thing that gets you to the thing? It’s not just a philosophy. It needs a blueprint.