Landscape architects have a name for the path people wear into the grass instead of using the paved walkway: a desire path.
Software has them too.
Users export a report and rebuild it in a spreadsheet. They paste information into a notes field because the proper field is too restrictive. They keep a second system open because the official workflow does not answer one question they need during the day.
Product teams tend to react to these behaviours in one of two ways. They dismiss them as user error, or they immediately turn them into feature requests.
Both reactions are too quick.
A workaround is evidence. It tells you that the user is trying to cross a gap between the product you designed and the job they are actually doing. It does not tell you, by itself, how that gap should be closed.
The workaround is part of the research
I have seen this pattern in inventory systems, safety workflows, and sales software. The intended path makes sense when the process is described in a meeting. Then the software reaches daily operations and people begin bending it.
That does not necessarily mean the product is bad. Real work contains exceptions, timing pressures, and local knowledge that no first version captures completely.
The mistake is treating the workaround as noise.
When somebody repeatedly exports data, I want to know what happens next. Are they changing the presentation, combining it with information we do not have, or making a decision the product never supported? The export is not the requirement. It is the entrance to the requirement.
The same applies to a notes field full of structured-looking text. Adding ten new fields might be correct. It might also turn one team’s local practice into complexity every customer has to carry.
The visible behaviour is only the first clue.
Some paths should be paved
A desire path is worth making official when it reveals a common job the product should support and can support safely.
The best examples reduce repeated translation. If many users export the same report, rearrange the same columns, and send it to the same kind of person, the product may be stopping one step before the useful outcome. Building that view or handoff into the system can remove work without expanding the product in a random direction.
Frequency matters, but it is not enough. I also look at whether the workaround is stable. A repeated behaviour that has survived different users and situations is stronger evidence than one loud request. It suggests the need belongs to the work, not only to one person’s preference.
There is still a cost. Every path we pave becomes part of the product we have to explain, test, secure, and maintain. A shortcut that saves five clicks can create a second version of the workflow that the team owns for years.
The right feature is not always the one that most faithfully copies the workaround. Sometimes the user found an awkward route because the product never exposed a simpler one.
Some paths should remain informal
Not every useful behaviour needs a button.
Flexible tools are valuable partly because people can adapt them without waiting for the roadmap. Exports, APIs, and notes can provide safe escape routes for work that is legitimate but too rare or too specific to deserve a permanent interface.
This is uncomfortable for product teams because it means accepting that some work will happen outside the product. I think that is healthier than pretending one system should contain every edge of a customer’s operation.
The boundary I care about is whether the informal path damages trust. If it creates multiple sources of truth, bypasses important validation, or depends on copying sensitive data into an uncontrolled tool, “leave it alone” is no longer neutral. The workaround has become risk.
But if the path is visible, reversible, and genuinely peripheral, forcing it into the core product can make the main experience worse for everyone else.
Some paths have to be blocked
Users optimize for completing the job in front of them. They are not always in a position to see the system-wide consequence.
A workaround that bypasses permissions, audit history, safety controls, or billing rules cannot be accepted simply because it is popular. In those cases the product team has two responsibilities: close the unsafe route and understand why people needed it.
Blocking without understanding usually starts an arms race. The user finds another route because the underlying job did not disappear. Understanding without blocking leaves a known risk in place.
This is where the desire-path metaphor has a limit. A shortcut across grass is mostly a maintenance question. A shortcut around an authorization check is a security decision. User behaviour is evidence, not authority.
The decision I use now
When a workaround appears, I try to separate four questions:
- What job is the user completing after they leave the intended path?
- How often does that job occur, and for how many kinds of user?
- What risk or inconsistency does the workaround create?
- If we make it official, what permanent complexity are we accepting?
From there, the choices become clearer: pave the path, provide a safe escape route, or block it and repair the missing workflow.
What I no longer do is assume that users are wrong because they ignored the design. A clean interface can still encode a false idea about how the work happens. Repeated workarounds are one of the few ways the product tells us that directly.
Users will always find a route to the outcome they need.
The product judgment is deciding which of those routes deserves pavement—and which one is a warning not to follow.