PRODUCT · plaza / desire path

Desire paths are the product.

an essay on the build trap

A planning officer in Lisbon paused mid-walking-tour last spring in front of a fresh limestone plaza and pointed at the dirt line cutting diagonally across the middle of it. The same failure mode happens in product, where the team confuses the polished surface it shipped with the path the user actually wore. The cleanest products of the last thirty years are the ones that figured out which one was the artefact and which one was the data.

walk the path

Top-down view of the redeveloped square, with the limestone marking what the planner shipped and the dirt strip marking what the commuters wore back.

The trigger for this essay was a walking tour I took last spring around a redeveloped square in Lisbon. The city planner leading the walk stopped in front of a fresh limestone plaza and pointed at a dirt line cutting diagonally across the middle of it. The path had been there before the plaza, worn into the grass over twenty years by commuters taking the shortest route between two metro entrances on opposite corners of the square, and the plaza had simply been laid around it: limestone slabs on either side, a strip of bare earth running through the centre, like a scar across a face the city had spent six million euros putting makeup on. The planner said he sees the same failure in every developing city he has worked in. Somewhere during the cycle where a project gets its funding approved, the plaza starts being graded on how it looks in the dossier, and the desire path quietly stops counting as data anyone is supposed to act on.
That sentence sat in my notes for nine months while I tried to work out why it felt familiar, and what I eventually realised is that I had shipped the limestone slab version of a product roughly five times in the last eight years. Each of those launches produced an actual user behaviour that was a desire path running diagonally across the centre of the surface we had spent two quarters designing. The map of bad development the Lisbon planner was describing turns out to be a map of bad product, too. A team that confuses the polish of the artefact with the value of the product spends its quarter laying limestone on top of a line nobody asked it to lay limestone on.
A company is in the build trap when it measures its success by outputs rather than outcomes, when it focuses on shipping and developing features rather than on the value those things produce.
Melissa Perri, Escaping the Build Trap
Melissa Perri's 2018 book Escaping the Build Trap makes a narrower version of the argument the Lisbon planner was making in the square, but the failure mode behind the metaphor and the failure mode behind her definition share an organ: both end with the team grading itself on the surface of the artefact rather than on the behaviour of the user. The team ships the plaza. The user wears the path anyway, the dossier only ever shows the plaza, and that is what the bonus pool ends up getting funded against next quarter.
limestone slab

What got built

A polished plaza poured to a published plan, graded by the design community on how cleanly the limestone slabs meet at the corners, and signed off by the planner whose career advances on the strength of how the dossier photographs.

worn line

What got used

A dirt line worn diagonally across the same plaza by twenty years of commuters taking the shortest route between two metro entrances, with no signage, no opening ceremony, and no name.

The list of products that won by ignoring the limestone is long and mostly embarrassing for the design community. Craigslist still serves tens of millions of unique monthly users with a flat HTML layout that has not been redesigned since 1996, and Craig Newmark continues to file the company's revenue as a side effect of running what is, by some counts, still the largest job posting board on the open web. Berkshire Hathaway's investor relations page has been the same page, fixed in width and set in plain text, for over twenty years, and the company sitting behind that page is one of the six largest holding entities by market capitalisation. Bloomberg Terminal users pay roughly 24,000 US dollars a seat per year for the privilege of using a keyboard built around function keys, a layout a student in an introductory HCI seminar would reject on sight. The terminal has held the floor of every major capital market for forty years on the strength of being faster to operate, not nicer to look at, and Wikipedia, which gets roughly six billion monthly visits, has managed exactly two visual refreshes over its 23 years and treats the prose itself as the user experience.
The inverse of the pattern is the more interesting half. The products that visibly tried hardest to look beautiful, and were praised on that beauty by the design press at launch, are mostly the ones that lost their categories within five years of shipping. Google+ launched with the cleanest design system any social network had ever shipped, and produced no behavioural pattern that survived contact with Reddit's table layout. Microsoft Bob shipped in 1995 with product illustration more detailed than anything else on a consumer desktop at the time, and was discontinued within a year. The Digg v4 redesign got praised by every product blog for two weeks before it lost most of the user base to a Reddit that still rendered like a 2006 forum. Juicero shipped with industrial design that won awards, wrapped around a product that turned out to be a pouch the customer could squeeze with their own hands.
Juicero's own customers ended up doing the squeezing. No machine required.
Don Norman drew the distinction in 1988, in The Design of Everyday Things, and the design community has spent the 37 years since pretending it does not have to remember: what an affordance tells the user is what the artefact can do for them, and what an ornament tells the user, sent to a different audience entirely, is something about the taste of the team that made it. The product gets paid for on the first of those and graded on the second, which means the team's incentive curve and the user's value curve start diverging somewhere around the third design review. The bigger the team, the further the divergence runs before anyone in the room notices.
The deeper version of the same argument is Christopher Alexander's, in A Pattern Language. Alexander argued that paths and centres in any human settlement are emergent properties of use, not artefacts of plan. The blueprint is a hypothesis the planner offers, and the use is the data the planner gets back. A planner who ignores the data is paving on top of someone else's life, and the life will keep wearing the path back into the ground anyway, regardless of how much limestone is involved. The product equivalent is what Perri makes explicit in her book and what Lisbon's planner was making implicit in the walking tour. The team that confuses the hypothesis it shipped with the data it received is the team that pours the plaza around the desire path and counts the slabs in its quarterly review.
The teams that escape this trap, in my experience watching product organisations from the inside, tend to have one common adaptation: they elevate the worn lines on the plaza into roadmap items with real priority behind them, building dashboards that surface the clicks falling off the intended path, the long press patterns the design system never accounted for, the URL hacks power users invented to skip three screens, and treating the whole mess as a feature request instead of user error. Stack Overflow's product team applied that same instinct to a heuristic about how close the copy button sits to the thing being copied, the way Lisbon's planner should have treated the dirt line: pour the surface around the line that is already there, instead of arguing about whether it ought to exist.

Lifecycle of a desire path UI

  1. prototype
    the deliberately ugly version handles the worn line that the user has been quietly carving for two years
  2. launch
    stakeholders complain that it does not match the design system, the prototype ships anyway because the data is unambiguous
  3. load-bearing
    the ugly affordance becomes the most-used surface in the product inside a single quarter
  4. ugly forever
    the team decides to leave it ugly, because every redesign proposal would have to argue against the usage curve it now produces
  5. rivals lose
    a competitor ships the polished version, fails to match the usage curve, and quietly removes the surface the following year

The worn line ends up being what the team eventually pours stones along.

What Lisbon eventually did with the plaza, after enough complaints reached the mayor's office, was lift the limestone slabs out of the central strip and lay grey paving stones along the desire path itself, with the wider limestone surface kept on either side. The rework cost roughly a third of the original budget, and the resulting plaza looks asymmetric in a way no graduate of an architecture school would have proposed for the dossier, which is exactly why it works. Every launch offers the user a hypothesis about which line they are supposed to walk, and the desire path that shows up afterward in the data is the correction to that hypothesis, the thing the drawing got wrong made visible in dirt. Pouring the next set of stones along that line is cheap. It only feels expensive in the design review, because somebody in the room has to say out loud that the original drawing was wrong.