Start With the Experience, Then Work Backwards to the Technology
Design is not how it looks, it's how it works. Part 2 of my product design philosophy: the best interface is no interface, and the parts users can't see should be as beautiful as the parts they can.
Most products are built inside-out. The team starts from the database schema, the vendor's API, or whatever the framework makes easy, then decorates the result with an interface and calls the decoration "design." You can always tell. The product works the way the system is organized, not the way the user thinks.
This is Part 2 of a four-part series on my product design philosophy. The rest: Part 1 — If Your Product Needs a Manual, the Design Already Failed, Part 3 — Nobody Asks for the Future, and Part 4 — Saying No to 1,000 Good Ideas.
The fix is a sentence Jobs said to developers in 1997 and most teams still haven't absorbed: start with the customer experience and work backwards to the technology. Decide what the user should feel at every step, then bend the architecture until it delivers that. The experience is the spec. The technology is the implementation detail.
Design is how it works
"Design is not just what it looks like and feels like. Design is how it works." Everyone quotes this line; almost nobody staffs like they believe it. If design is how it works, then your designers belong in the architecture conversation and your engineers own the user experience. Splitting "what to build" from "how to build it" produces exactly the inside-out products I just described, which is why I argue product and engineering were always one job.
In practice, working backwards looks like this: write the experience first, in plain words. "The operator pastes a tracking number and the order is reconciled before they can switch tabs." That sentence is a design document. It constrains latency, it constrains error handling, it constrains how much of your vendor's clunky API you're allowed to expose. Every technical decision after it either serves that sentence or gets rejected.
The best interface is no interface
The highest form of this philosophy: make the technology invisible. Every screen, button, and confirmation dialog is a cost the user pays to get what they actually wanted. The best interface isn't a cleaner version of that cost. It's the step that disappears entirely.
The file that syncs without a sync button. The payment that happens when you walk out. The report that arrives before anyone asks for it. Users don't describe these as good interfaces; they describe them as the product "just working," which is the entire point. Nobody compliments the doorknob on a door that opens for them.
This is also where AI genuinely changes the design vocabulary. For thirty years, "make it invisible" was aspirational because software couldn't infer intent; it had to ask. Now it can read context, draft answers, and complete whole steps on its own. Which means interfaces that interrogate users with forms aren't just dated, they're a choice. The new design question isn't "how should this screen look," it's "why does this screen exist?"
Magic is engineered, not sprinkled
"Every interaction should feel magical and delightful" sounds like marketing fluff until you reverse-engineer what magic is made of. It's response under a hundred milliseconds. It's defaults so well-chosen the user never opens settings. It's the empty state that teaches without a tutorial, the error message that says what to do next, the form that remembers what it asked you last time.
None of that is delight-as-decoration. All of it is engineering. Perfection in details matters, obsess over every pixel and every transition, not because users consciously notice each one, but because they unconsciously notice all of them at once. The sum has a name: the product feels either crafted or assembled. Users can't tell you which details produced the feeling, but they can tell you the feeling within ten seconds.
The parts you can't see
Jobs got this from his father, who refused to build a fence with an ugly back even though no one would see it. The software translation: the parts users can't see should be as beautiful as the parts they can. The schema, the service boundaries, the naming, the test suite, the deploy pipeline. Quality must go all the way through.
I hold this position for a thoroughly unsentimental reason: in software, the back of the fence doesn't stay hidden. It leaks. The messy schema becomes the slow query becomes the spinner the user stares at. The tangled service boundary becomes the feature that takes a quarter instead of a week. The codebase nobody is proud of becomes the team that stops arguing for the user, because people don't fight for craft in a place that has none.
You cannot bolt a magical experience onto an ugly core. The experience is the part of the iceberg above the water; its shape is determined by everything underneath.
Next in the series: why customers can't ask for the future, and why you have to build it anyway. And if your product was built inside-out and you can feel it, let's talk →