My whole career, I’ve tended to approach problems—whether design, engineering, or something else entirely—by not merely taking one step back, but taking 100 steps back.
This means questioning your assumptions and taking nothing for granted. This means getting a wide-enough view of the landscape that you can start to meaningfully answer the question, “What are we actually trying to do here?”
I’ve seen this pattern crop up over and over in different ways and different places. A common approach to novel-writing, for instance, is that your first draft teaches you the story you want to tell, and it’s only then that you can write the actual novel.
This is related to the rhetorical practice of rejecting the premise. When someone asks you whether vanilla or chocolate is better, you don’t actually have to choose one of those responses. You can instead question the question itself.
But asking your client “Wait, why does your app need Feature X?” is rarely a magic wand that causes them to suddenly realize there was a different problem all along. There’s always a reason someone is asking for a feature or capability. This is not about smugly asking why until someone admits there was some other problem all along.
What it does mean is teasing apart the implications of the request, taking seriously their ramifications, and being open to potentially radical new interpretations. If your client says their app needs user accounts, that’s going to involve authentication, profile persistence, password reset flow, and on and on. Can the problem be solved with a private, unguessable link? Does it matter if certain items are publicly accessible?
And to be clear, your client’s app may indeed need user accounts after all. But this approach at the very least ensures the request is justified, and at best, reveals completely different formulations of the problem.
Back when I was designing and prototyping the wireless lighting control system Lightcloud, one of the first decisions I made was to have the Gateway device automatically connect via cellular to our backend.
At the time, most industrial systems like that expected you to hardwire it with ethernet and even manually configure an IP. My goal for Lightcloud was to make the user do as little work as physically possible. Cellular introduced a cost for us, but enabled customers to quite literally plug and play, sidestepping an entire category of problems.
One step back might have been “a well-designed ethernet configuration interface.” 100 steps back is a fundamentally different system.
A famous example is the Sony Walkman. At one time, there was no product category of “personal portable stereo cassette player.” Before the Walkman, you either had portable monaural radios, or “portable tape recorders,” which stemmed in part from the tradition of dictating letters or memos or ideas to a secretary who would do the actual writing or typing. Portable recorders like this were a pretty big market.
But what Sony cofounder Masaru Ibuka realized he actually wanted was to listen to stereo music on a plane, so he had their existing monaural tape recorder converted to stereo. Then, cofounder Akio Morita tried that out and realized* it might “satisfy the wishes of young people who want to enjoy music all day long.” So he fast-tracked this new device even though it had no recording functionality, which many people both inside and outside the company predicted would doom it. Those people were, of course, very wrong.
One step back was a stereo tape recorder. 100 steps back created an entire #(*&ing culture!
Openness to seemingly-strange new ideas is one angle, but deliberately seeking out root causes is another. This is where I’m a fan of Jobs to Be Done, because it requires you to go so far down the user’s thought process that you’re looking at their emotional states and underlying psychology. If you’re going to do root-cause analysis, go all the way! Or at least before it becomes cognitive neuroscience, I guess.
But note that questioning every assumption 1) doesn’t mean the assumption is wrong and 2) doesn’t mean rejecting every convention. Conventions are extremely useful, even if they’re not universally understood. A magnifying glass usually means search, a gear is commonly understood to mean settings, the “three dots” means “more options.” These symbols may not be inherently self-explanatory, but once learned, the knowledge can be carried over to other products.
Bad design sometimes starts by accepting a faulty premise: that your app needs a full-blown AI chat interface, or that ships need to be improved, not the shipping process. Marginal improvements are not wrong, but they sometimes obscure far better solutions.
The point of designing from first principles is not to turn every problem into some unprecedented, novel invention (though hey, I wouldn’t argue with that). The point is to give yourself an opportunity for invention, while potentially dodging much bigger problems. And it doesn’t imply some kind of crazy time expenditure, either—you can have that flash of insight in a single moment as long as you’re priming yourself to look past the ordinary.
* The Sony website doesn’t have an anchor link to the relevant citation, so you have to click on the “More” button under 1979, TPS-L2.