Fifteen footsteps wear a trail. Twitter’s hashtag was one. So is shadow IT. The signal vanishes the moment you pave it.
Walk south from 110th Street in Manhattan and Broadway curves. Not by much, but enough that any planner with a ruler would have made it straight. Broadway runs at a slight diagonal across Manhattan’s grid for thirteen miles, and the reason is that the Lenape walked it long before the Dutch laid out their streets. The Wickquasgeck Trail — a single-track footpath connecting Native American settlements across the island — was already there. The city built around it. The most famous street in American theater began as a desire path, and three centuries of pavement, subway tunnels, and skyscrapers have never quite straightened the curve.
That is the pattern this essay is about: the routes people wear into a system, against the wishes of the people who designed it. They show up in lawns, in software, in spreadsheets, in shadow IT departments, in the informal economies of two billion workers. They are, almost always, the most honest piece of feedback a system will ever get — and the hardest to act on, because the act of formalizing them tends to destroy the signal that created them.
A desire path (also: desire line, cow path, elephant path, social trail) is the worn track that appears in grass, snow, or mud when enough people walk a route the designer didn’t build. The term traces to French philosopher Gaston Bachelard, who in The Poetics of Space (1958) described chemins du désir — paths of longing worn into landscapes. It has since migrated into urban planning, UX research, and the academic literature on “digital desire paths” (Hardaker & Singh, European Journal of Information Systems, 2024).
The numbers are smaller than you would guess. According to Carmanah Technologies’ 2025 review of pedestrian infrastructure research, as few as fifteen traversals of an unpaved route are enough to create a visible track. Once it exists, the next pedestrian recognizes it as a shortcut and follows. A space that opened on Monday can carry permanent informal trails by Friday — faster than any procurement cycle or review board. The infrastructure is obsolete before the ribbon is cut.
Michigan State University famously decided to stop fighting this. The university’s design team left several new campus areas as grass, watched where students walked for a year, and then paved the paths students had created. The result was a network of curves and diagonals that “do more justice to users’ needs than the average rectilinear pavement,” in the words of Pop-Up City’s report on the program. The pre-paving observation period is the design.
There is a faster method. Finnish city planners visit parks immediately after the first snowfall and photograph the prints. Snow is a one-day natural experiment: with no visible paths to constrain them, pedestrians take their preferred route, and the trace lasts long enough to map. The results then feed into trail planning. The Finns get in a day what Michigan State takes a year to learn.
A subtler version of the same trick appears in Philadelphia, where a local advocacy movement coined the word sneckdown (snow + neckdown) for the bulges of untouched snow at intersections — the road space that cars never actually drive over. A sneckdown is a desire path in negative: it reveals where the city built infrastructure that nobody uses. The snow is doing the same job in both cases, just measuring different things. One shows where users do go; the other shows where they don’t. Both are revealed preferences. Both are unfakeable in a way that a survey is not.
El Cerrito, California has gone further still — written desire-path observation directly into city code. Before a new crosswalk is approved, the municipal process requires “engineering studies, walk audits, staff observation, or public feedback.” That last clause is doing real work. It means the city’s design process formally admits that users get a vote, and that the vote is cast with feet, not ballots.
Most software organizations do not have anything that crisp. They have a roadmap, and a backlog, and a research team, and somewhere far down the org chart a customer-support queue full of the same complaints repeating in different words. Those tickets are sneckdowns. So are the integrations users build, the spreadsheets they email around, the export-to-CSV button they hit instead of using the app’s “real” workflow.
The cleanest demonstration is the platform that is most a desire path: Twitter. Three of its iconic features were invented by users, against the founders’ protests.
On November 2, 2006, a user named Robert S. Anderson sent the first message prefixed with another user’s name and an @ symbol. Twitter did not yet have a reply mechanism. Anderson improvised one, the convention spread, and eventually Twitter built the feature he had already designed for them.
On August 23, 2007, Chris Messina proposed using the pound sign to group tweets by topic, borrowing the convention from IRC channel names. Twitter’s cofounders Biz Stone and Ev Williams reportedly thought it was, as Messina later recounted to CNBC, “too nerdy” and predicted it “would never catch on.” Two months later, the San Diego wildfires hit, and users coordinated emergency information under the tag #SanDiegoFire. Twitter watched a grassroots disaster-coordination network self-assemble on a feature it had refused to build. The company officially adopted hashtags in July 2009 — almost two years after Messina’s proposal and the wildfire moment that proved it. The retweet followed the same trajectory: users typed “RT @username” by hand, then Twitter eventually paved it.
Whatever you think of what Twitter became, the early product was a master class in observing the lawn. The features that defined the platform were not invented by product managers. They were invented by an ad hoc community improvising around a system that had not anticipated them, and the company’s job — sometimes against its will — was to notice, then pave. Most of the platform’s worst missteps came when it stopped paving and started fencing.
The corporate version of this story is “shadow IT” — the personal Dropbox accounts, unauthorized SaaS subscriptions, and freelance ChatGPT use that runs alongside the official tech stack. Gartner reports that the share of employees acquiring or modifying technology without IT’s knowledge rose from 30–40% pre-pandemic to 41% in 2022, with projections reaching 75% by 2027. A 2025 paper in IJACSA on post-pandemic shadow IT identifies a useful three-phase evolution: shadow IT began as convenience (the official tool is annoying and Dropbox is faster), became necessity during COVID lockdowns (the official tool doesn’t exist for this and the work has to happen), and is now hardening into strategic optimization (the official tool exists, but the unofficial one is better).
The pattern is the same as Twitter’s. Users routed around a designed system. They did it first as individuals, then in pandemic-era emergencies, and finally with the tacit blessing of organizations whose entire operations had survived on the workarounds.
The counterintuitive finding is what happens to the users who do this. A widely cited 2016 AMCIS paper on shadow IT and individual performance found that workaround behavior and unauthorized tool use are positively correlated with performance — the people routing around the designed system are typically the higher performers, not the lower ones. This inverts the standard security framing. The shadow IT user isn’t your weakest link; they are often your best engineer, who has noticed that the procurement-approved tool costs them an hour a day. The 2024 UNSW pedestrian study found a parallel: pedestrians who are “young, fit, and graduate” are the first to leave the designed paths. The most capable users defect first.
This does not mean shadow IT is harmless. Gartner reports that 69% of employees intentionally bypass cybersecurity controls in a given year, knowing they are breaking rules; 50% using unauthorized AI tools would keep doing it even if explicitly banned. The diagnostic question isn’t “are users disobeying?” — they are — but “are they routing around a feature or around friction?” A feature adds value the user can’t see. Friction adds cost the designer can’t see. The desire path tells you which is which, but only if you investigate before you fence it off.
There is a Hindi word, jugaad, that translates roughly as “a way to fix a difficulty not through conventional measures, but through the cheapest possible means.” A jugaad solution is a tractor stitched together from a motorcycle engine and a water pump; a credit ledger run out of a tea-shop owner’s notebook; a parallel ride-hailing market that exists because the formal one is unaffordable. The Asia Society’s Jugaad Innovation program characterizes it as a six-principle approach: seek opportunities in adversity, do more with less, think flexibly, keep solutions simple, include marginal participants, be passionate.
The scale matters. According to a 2024 Cambridge University Press volume on innovation in the informal economy, close to 70% of workers in developing and low-income countries — nearly two billion people globally — are in informal employment. Their working lives are routed around formal economies that do not serve them. The shop on the corner that runs on cash because the bank charges 4% on card transactions; the loan from a neighbor instead of the bank; the bus route that exists because the city’s planned transit ends three kilometers away from where people actually need it.
This reframes the desire-path concept. In the Michigan State story, the trail is an exception to the designed system. In jugaad, the trail is the system, and the designed infrastructure is the exception — the late-arriving formal scaffold that the informal economy may or may not absorb. Western design literature treats desire paths as evidence of failure. Two billion people treat them as evidence of life.
The deepest finding in the research is the one that complicates every clean lesson above. Paving a desire path destroys the signal that created it.
Ant-colony optimization makes the mechanism legible. Ants returning from a food source lay pheromone trails. Other ants follow the strong trails, reinforcing them, until the colony converges on an efficient route. The crucial detail in Marco Dorigo’s foundational work (Dorigo & Stützle, Ant Colony Optimization, MIT Press, 2004) is evaporation. Without it, the first path discovered becomes permanently dominant, even when better paths exist later. The system locks in. Pheromone evaporation is what lets the colony un-learn.
Paving is the opposite of evaporation. It locks in.
Twitter’s hashtag, once a feature, became a spam vector and an algorithmic gaming target. The Michigan State paths, once paved, calcified — they were now the designed paths, with the same blindness to next year’s foot traffic that the original layout had. El Cerrito’s formal walk-audit process is excellent, but it institutionalizes the people who run walk audits, which means the next round of desire paths will form against them. The hashtag had to be invented because Twitter’s product team couldn’t see the need. Once they could, they shipped the feature — and then they shipped twenty other features that the next generation of users routed around.
This is the paradox at the heart of the concept. The desire path is information because it is unsanctioned. The moment it becomes the sanctioned route, it stops carrying that information, and the new informal routes form somewhere else, often against the path you just paved. A well-run organization doesn’t pave its desire paths once. It learns to keep watching the lawn, because the lawn is always renewing.
Not every workaround is wisdom. Users route around safety features for convenience as readily as they route around bad design. The 69% cybersecurity bypass rate includes some genuinely dangerous behavior. Pheromone trails can converge on local optima rather than global ones — and so can desire paths, especially when reinforced by network effects. The UNSW Sydney study (Irannezhad et al., 2020) found that 40% of pedestrians strongly preferred a desire line even when it was officially closed, but that doesn’t tell you whether the path was a good idea or just a stubbornly preferred one. The diagnostic discipline is the same as for any feedback signal: don’t pave the path the first time you see it; wait until the pattern has survived diverse conditions and many users.
Stewart Brand’s How Buildings Learn (1994) offers the operating principle. Brand observed that buildings adapt best when different layers change at different rates: site (permanent), structure (decades), skin (about twenty years), services (seven to fifteen years), space plan (three to thirty years), and stuff (daily). Rigid buildings are ones that lock all the layers together. “Low Road” buildings — Brand’s term for warehouses, lofts, and garages — adapt fastest because the inner layers are cheap to modify without disturbing the outer ones.
This is the discipline for paving desire paths. Not everything should be emergent, and not everything should be planned. The question is which layer.
You want the foundations rigid: authentication, billing, the data model, the security boundary, the regulatory contract. You want the surface layers emergent: which integrations users build, which workflows they string together, which fields they leave blank, where they enter the product, which features they ignore. Rigid surface layers (a fixed UI that punishes deviation) drive every shadow IT story in this essay. Emergent foundations (anyone can change the schema) drive every data-corruption story you’ll see this year. The art is putting the line in the right place, then maintaining it.
So the practical instrument is a desire-path audit. For your product, codebase, or knowledge base, ask five questions:
Answer the five questions and you have a map of where the designed system and the lived system diverge. Then comes the harder discipline: don’t pave everything. Pave only the paths worn by many users under varied conditions, and pave them in a way that leaves room for the next round of trails.
Broadway is still slightly diagonal. The Wickquasgeck Trail is still in the curve of the avenue. The most durable infrastructure started as the most informal — fifteen traversals, then twenty, then a thousand years of feet. The path was already there. The skill is noticing.
Your agents are already wearing desire paths. Are you reading them?
An agent that quietly stops calling one of your tools, picks up a workaround, retries through a different endpoint, or routes around a permissions check is laying pheromone. If your audit trail only records the sanctioned path, the signal evaporates. Chain of Consciousness is a hash-linked record of what the agent actually did — sanctioned and unsanctioned both — so the worn track shows up where you can see it before you decide whether to pave or fence.
pip install chain-of-consciousness · npm install chain-of-consciousness · Hosted CoC