The best interface is often no interface at all. Every tap, click, confirmation, and decision the user makes is friction — cognitive cost paid by someone who came to get something done, not to operate software. Zero-interaction design asks: what if the product did this without being asked?
In 2012, Google Now launched what became one of the clearest demonstrations of zero-interaction design in consumer software. Before you searched for anything, before you asked any question, it told you your flight was delayed, that your commute would take 40 minutes due to traffic, and that the package you ordered was out for delivery. It had read your email, your calendar, your location, and your history — and it surfaced what you needed before the thought occurred to you to look for it. No query was typed. No button was pressed. The interface produced its output silently, triggered by context rather than command.
This is the zero-interaction principle: the idea that the most valuable thing an interface can do is often act without being asked. The name comes from Golden Krishna's 2015 book The Best Interface Is No Interface, which argued that the design industry's obsession with screens, taps, and flows was producing worse outcomes than systems that simply behaved intelligently in the background.
Zero-interaction design does not mean removing all interface. It means asking, for every interaction the product currently requires, whether that interaction is genuinely necessary or whether the system could make the same decision on the user's behalf — based on context, behaviour, defaults, or explicit prior preferences. When the answer is that the system can decide, the interaction is friction. When the answer is that the user genuinely needs to choose, the interaction is appropriate.
“Every interaction is a failure. Every time a user has to tap, click, or type, the product has failed to anticipate what they needed.”
— Golden Krishna, The Best Interface Is No Interface, 2015
Email clients are one of the highest-density interaction environments in daily computing. Each email in an inbox is a pending decision: read, reply, archive, delete, snooze, flag, forward. Inbox zero methodologies exist specifically because the interaction cost of managing email is so high that entire productivity frameworks have been built to help people cope with it. Zero-interaction email design asks: which of these decisions can the system make?
The two inbox states below show the same 14 emails. One presents them as a flat list requiring sequential triage. The other has already sorted them by context and handled the obvious cases silently.
14 emails, 14 pending decisions. Notifications, newsletters, shipping updates, and an urgent colleague reply all arrive in the same visual space with the same visual weight.
Two emails need the user. Three were handled silently. The green section is the receipt — transparent about what was done, with one-click undo.
The handled-silently section is the zero-interaction principle made visible. The system already knew that a shipping notification does not require a response, that a newsletter can be bundled rather than occupying inbox space, and that a LinkedIn promotional email serves no purpose in a priority view. It acted on all three and reported what it did. The user reviews the report when they want to — or does not, because they trust the system to have made the same decision they would have made if asked.
Zero-interaction design is not binary. Every product decision sits somewhere on a spectrum from “user decides everything” to “system decides everything.” The right position on this spectrum depends on two variables: how well the system can predict what the user would want, and how costly a wrong decision is. When prediction is reliable and the cost of error is low, automation is appropriate. When prediction is unreliable or errors are costly, interaction is appropriate.
The practical application of zero-interaction design starts with an audit of required interactions. For each confirmation, form field, setting, and decision point in your product, ask: does the user need to make this decision, or is there information the system already has that makes asking unnecessary? The answer will be “the system can decide” more often than most designers expect.
The principle is not about removing control. Users who want control should always be able to find it. The principle is about not forcing interaction on users who did not ask for it — about treating every interruption of a user's attention as a cost that requires justification. When the system can act, it should act. When it acts, it should report. When it reports, it should allow undo.
Krishna, G. (2015). The Best Interface Is No Interface: The Simple Path to Brilliant Technology. New Riders. · Norman, D. A. (1988). The Design of Everyday Things. Basic Books. · Weiser, M. (1991). The computer for the 21st century. Scientific American, 265(3), 94–104.