On my home office wall hangs a single framed poster. No family photos, no motivational typography, no art prints picked for their colors. Just three words in clean type against white space:
Less but better.
It is Dieter Rams's most famous design principle, and I chose it not as decoration but as a daily reminder. Every time I sit down to work, it reminds me to ask whether what I’m working on is adding any value, or merely adding.
What is easy to miss in the aphorism's brevity, is that less is not a shortcut nor is it a statement of style or preference. It is the result of having considered a variety of potential solutions and discarded all but one—the best one. The resulting minimalism is the outcome of ruthless editing rooted in a deep understanding of what a user actually wants.
Across the Atlantic and a decade earlier, Charles and Ray Eames were working toward the same discipline from a different direction. Their motto was to make “the best for the most for the least,” and it carried a democratic optimism that Rams's philosophical formulation did not. They focused on a post-war middle class for whom well-made things had often been out of reach. And their now legendary products brooked no compromise despite these self-imposed constraints. Neither theirs nor Ram’s work would have benefitted from “more”. They are distilled and inevitable.
Both approaches converge on a single insight: that quality emerges when nothing superfluous remains.
But that ideal becomes harder to uphold when the cost of building anything collapse to near zero.
For most of the history of software, teams obsessed over details partly because they had to. Shipping something new was expensive. A meaningful feature might consume weeks, months, entire quarters. Slop had carrying costs and technical debt.
Now a small team, or increasingly one person with a few good promptsm, can ship half-baked experiments in an afternoon. Which naturally raises the question: if iteration is nearly free, why not throw everything at the wall and let the users decide?
What Rams and the Eameses intuitively understood was that discipline was never really about time, money, or building cost. It was the willingness to understand a problem deeply enough that most solutions could be rejected before they ever reached another human. They respected the user’s attention and hence believed that restraint was part of the product.
Modern product development treats users as participants in an endless live experiment. But segmenting our users into countless cohorts to test ever sloppier features enabled by the falling cost to ship ultimately misses the point:
Each user only experiences one version at a time. To them, the product is not a process. It is simply the thing you shipped.
If it doesn’t meet their expectations they may not give the product a second chance. This matters because your competitors also benefit from those same collapsing costs. Someone is going to win that user’s dollar. Why should it be you if what you ship is careless? Why shouldn’t they just build their own?
We are in a moment where we mistake the abundance of possible solutions and the speed with which we can deploy them with the singular delight that a user experiences when something we built for them just works.
If you’re a designer you know this moment of delight wasn’t an accident. It was the outcome of a “less but better” thinking process. If you’re a business owner, this moment is your insurance that the user will retain. But in a world where anyone can ship anything really fast, what you choose not to ship may matter more.
