Desire Path

On desire paths… and software

Desire paths are a common pattern in landscape design: born as simple footpaths when someone takes a more direct, shorter way to their destination, they often evolve to proper paths and roads after a while.

While architects and garden planners often regard those paths as unesthetic and try to prevent them by using fences and the well known keep off the grass signs, desire paths tell a lot about the needs of people traversing a space. Some urban planners even use those paths to guide them when revising the original design by adding new roads or altering the original project.

Desire paths are important because they give insights about points where the original design is lacking from a functional point of view. Sure, they may not be as pleasant to the eye as a perfect, regular lawn, but they often show a more effective way to solve a problem: getting from one point in physical space to another.

I am posting about landscape design here because the same phenomenon can occur when observing the way users interact with software products. Users often compensate for missing features by and taking shortcuts and by adopting workarounds which, eventually, leave a persistent mark on the system they are using.

Here a couple of examples.

The first is a historical example. In 2007, allegedly following a convention proposed by Chris Messina, a group of Twitter users started using the # symbol to specify tags associated to their tweets.

The habit spread fast among the community, without any kind of central direction, and after a while Twitter integrated support for hashtags as we know them today. This is one of the most significant examples of desire paths at work: users figured out a smart way to use a system that was eventually promoted to a full-fledged feature.

A streak of +1 comments on GitHubThe second example is way more recent, and you may have noticed it if you spent some time navigating the open issues of some popular open source project hosted on GitHub.

The more popular the project, the more easy it is to find issues with never-ending threads of comments like the like the one on the right side of this page (click here to see it in full scale). At a first glance, those issues seem to be extremely severe or controversial to cause such discussions, but the truth is quite different.

On a closer look, all those comments do not carry much meaning: they often are just a long list of comments consisting in (verbatim) “+1” (and occasionally some variations on the same theme). Those types of comments have become a standard way for users to communicate to the development team that some issue is important to them.

While the intention is understandable, this is often perceived by some a “bad” way to use comments on issues. Regardless of what opinions we may have on that point, it is certain that this behavior is another clear example of desire paths at work. Users want a quick way to let developers know they care for issues: comments were not designed for this purpose, but people figured out that they can be used for that too.

And then who knows, GitHub may end up adding a “like” button equivalent on their issues.

Paying attention to patterns like these in software can give us important insights about features that would benefit our users if we were to implement them. They are like validated user needs, highlighting an area in which our product may be lacking.


Published by

Alessandro Bahgat

Master geek, developer, avid reader and one of the minds behind and

7 thoughts on “On desire paths… and software”

  1. Thank you, the questions at the end of the article are definitely interesting, especially this:

    why isn’t there any other elephant path starting on the other side (where there is no sign)?

    I guess it’s because sight of the destination is an essential driver for people to walk off the proper path, but that is just my guess. I wonder if there a proper explanation for this kind of behavior, though.

  2. “When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.” HTML Design Principles, W3C Working Draft

  3. Alessandro, thank you for this interesting post. I agree with your last comment too. You are right with the point that the case of desire path can be related to both the idea of shortcut and to that of workaround, although your next point, that “[these] eventually, leave a persistent mark on the system they are using.” is a little bit excessive. These deviating behaviors can be adopted and made “mainstream” behavior in the next releases of the system, _if designers have got some way to get access to the (often almost stymergic) traces of these behaviors_ . But when does such a thing really happen (I mean, we would need some process mining from the use logs, or something like that). Would not it be nice if all backends adopted something like this little app ( so that the actual interaction “trails” and usual pointer paths could be observed emerge in real practice and let them provide designers with a visual “feedback” for the continuous improvement of the ergo(eco)nomics of their graphical user interfaces?

  4. Thank you Federico for your comment: I agree when you say that tools like iographica would help significantly when designing evolutions of an existing project or prototype.
    Analytical approaches to product design and product management rely heavily on log analysis, split testing and other metrics to drive the evolution of software. As you noted, though, not all teams are willing to pay the price needed to collect and process the relevant data.

    The analogy with desire paths, however, comes from persistence: desire paths are visible, persistent traces left by users taking unplanned shortcuts. As such, they are easier to observe than the other signals we mentioned and, if properly interpreted, still give insightful suggestions.

    When I say visible, I mean something like the two examples in the article:

    • Twitter hashtags: a manifestations of the desire to tag updates by topic
    • GitHub +1s: a manifestation of the desire to express interest, signal priority and subscribe to an issue (interestingly this approach to issue management seem to address the same problem)

    Another example: people used to prefix classifieds titles with AAA to have them listed first when ads were sorted alphabetically.
    Publishers initially charged more for each A in the title but now, in the age of Internet, many sites offer you a (usually paid) option to highlight your ads.
    Would you consider this another desire path in software?

  5. Have you ever considered creating an e-book or
    guest authoring on other sites? I have a blog based upon on the same information you discuss
    and would really like to have you share some stories/information. I know my subscribers would enjoy your work.
    If you’re even remotely interested, feel free to shoot me an email.

What do you think? Leave a Reply:

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s