Designing for the Person You Are, Not the Person You Think You Should Be

There is a chair in almost every bedroom in the world that serves no purpose it was designed for. It doesn't hold cushions. It doesn't get sat in. It holds the pile: the clothes that aren't quite dirty enough for the wash but aren't quite clean enough to go back in the wardrobe. The laundry basket sits nearby, empty or near-empty, a monument to the person you intend to be. You know this chair. You almost certainly have one.

Most people treat the pile as a small personal failure. Designers who are paying attention treat it as the most honest piece of data in the room.

Desire paths and the wisdom of disobedience

Before landscape architects understood how people actually move through spaces, they designed paths where they thought people should walk: tidy, logical, geometrically correct. Then they watched as pedestrians cut across the grass and wore their own trails into the ground anyway. These informal routes are called desire paths: the lines that form wherever people find it easier to go their own way than to follow the intended one.

The instinctive response from designers was frustration. The more instructive response, now adopted at universities including UC Berkeley and Virginia Tech, is to treat those trails as free user research. Some campuses deliberately leave areas unpaved for an academic year, then lay the permanent paths where the footprints tell them to. They build for where people actually go, not where the plan assumed they would.

The chair in your bedroom is a desire path. So are the keys that always end up on the hallway table even though you bought a hook for them. So is the mug that migrates permanently to your desk. So is every junk drawer that exists in defiance of the organised drawer beside it. These aren't failures of discipline. They are behaviour in its most honest form: automatic, low-effort and repeatable.

The question for anyone building products or physical spaces is not "how do we stop this?" It is "what is this behaviour telling us, and how do we design around it?"

The science underneath the pile

The reason the clothes land in the corner has a clean explanation. BJ Fogg, whose Behaviour Model emerged from research at Stanford's Behaviour Design Lab, shows that any behaviour requires three things to converge at the same moment: motivation, ability and a prompt. When ability is low, even strong motivation isn't enough. The pile forms in the corner because that's where the ability exists. The clothes are already in your hands, you're tired and the corner is right there. The laundry basket, two metres away and requiring you to lift a lid, is one step too many.

James Clear puts the applied version of this precisely: "Before you try to increase your willpower, try to decrease the friction in your environment". This isn't a concession to laziness. It is an acknowledgement that human beings are energy-conserving systems. We default to the lowest-effort option available because we always have, because that is how we are wired. A designer who fights that tendency will lose every time. A designer who works with it will build things people actually use.

Don Norman's work adds a further layer. In The Design of Everyday Things, Norman draws a distinction between affordances — what actions an object makes possible — and signifiers, the cues that tell people how to discover those possibilities. A flat plate on a door signals "push". A handle signals "pull". When the signifier contradicts the affordance, people make the "wrong" choice and feel foolish. Good design removes that moment of doubt by making the right action the obvious one.

This points towards a concept worth building into every design decision: point of performance. Put the thing where the behaviour actually happens, not where you think it should happen. A hook by the front door will be used. A hook inside the wardrobe room two hallways away will not. This is not because people are careless. It is because the wardrobe hook asks for more than the moment allows. Kaizen, the continuous improvement method that emerged from Toyota's manufacturing system, applies the same logic to processes: audit every step and ask whether it genuinely serves the outcome, or whether it simply exists because nobody removed it.

Friction is a design lever, not a symptom

Once you understand friction as a mechanism, you can use it intentionally in either direction.

Deliberate friction protects users from consequences they didn't intend. An unsubscribe flow with a confirmation screen is reasonable design: it introduces a pause before an action that's difficult to reverse, at a moment of low commitment. A "type DELETE to confirm" pattern on account deletion is friction by design, and it serves a genuine purpose: forcing a user to engage cognitively with a permanent action. Nielsen Norman Group's research on confirmation dialogs is clear on when this works: friction earns its place for irreversible, high-cost actions. Applied to routine ones, users habituate and click through without reading, and the friction achieves nothing except delay.

Intentional friction can also create value rather than simply prevent harm. Research published in Management Science in 2011 by Ryan Buell and Michael Norton at Harvard Business School found that users rated results as significantly more valuable and trustworthy when they could see effort happening on their behalf, even when the underlying process was instantaneous. Buell and Norton called it the 'labor illusion'. Kayak applies it in flight search, surfacing partial results progressively with a running count of sites checked. TurboTax shows an animated 'triple-checking your return' bar before revealing the final figure. Neither is a technical constraint. Both are deliberate choices grounded in the same logic as the Fogg model's ability component: when a result appears instantly, there is no visible signal that the system worked hard. Adding the signal, even artificially, restores it. Fast Company's analysis of Apple's unboxing experience captures the physical version of this: the slow-open resistance of an iPhone box is engineered to create ritual and build anticipation before the product is even visible. The friction is the product experience.

The failure mode is importing that same logic into moments where you need behaviour to happen easily. An onboarding flow that demands job title, team size, use case and billing information before a new user has seen anything of value is not protecting the user. It is protecting the product team's data model. The user who completes it is the exception. The majority leave at step two and are never heard from again.

The demo below makes the contrast concrete. Step through the friction-heavy flow and notice exactly where the impulse to quit arrives, then switch modes and feel how different the same moment is when the design has been stripped to its minimum.

Every unnecessary step in a flow is a desire path waiting to form. The Kaizen audit question is worth asking here: which steps in this journey serve the person going through it, and which steps are there because the team added them and nobody thought to take them away?

If you have to explain where it is, the implementation has already failed

There is a test I've found consistently clarifying for any new feature or workflow: can a user find it without being told where it is?

If the answer is no, it's worth sitting with that before you ship. Not because it means the feature is bad. But because it means the implementation has failed on its most basic requirement: discoverability. I've noticed this pattern in practice: when I find myself explaining where a new feature lives, something in that moment flags a problem. The explanation should not be necessary. If it is, the right question isn't "how do I explain this better?" It's: why does it require explanation at all? That is a product question, and it connects directly back to the science. In Fogg's model, behaviour requires motivation, ability and a prompt converging at the same moment. A feature with no visible signifier (Norman's term for the cue that communicates a possibility exists) never fires the prompt. The behaviour cannot happen regardless of how well-built or genuinely useful the feature is. Product teams routinely invest months in functionality and days in the surface layer that signals it exists. The ratio is the problem.

Nielsen Norman Group's research on findability consistently shows that obscuring navigation doesn't just make a feature harder to reach, it compounds through every interaction that follows. Customer success teams are often the earliest signal here: if CS is regularly explaining where a feature lives or how a workflow functions, that is not a training problem. That is a product team receiving user research in real time and not recognising it for what it is. The same applies in engineering: a technically correct implementation that users cannot find is not a shipped feature. It is a tree that fell in the forest.

Clutter, confusion and workarounds in a product are not failure states. They are signals. The messy navigation, the feature buried three levels deep, the label that made sense in the internal spec but means nothing to the person using it: these are desire paths. They are telling you something. The question is whether you are listening.

The homes we design in our heads are tidier, more organised and more intentional than the ones we actually live in. The products we design in our heads are used exactly as intended, by exactly the right persona, in exactly the right sequence. Neither version is real. The chair in the corner is real. The user who quits your onboarding on step three is real. The feature that nobody uses until someone explains it at a conference is real. What you do with that information is probably the most consequential decision a product team makes: whether to treat it as inconvenient noise, or as the most useful feedback you will ever receive.