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.

how do you feel about using # (pound) for groups. As in #barcamp [msg]?

— ˗ˏˋ Chris Messina ´ˎ˗ (@chrismessina) August 23, 2007

The habit spread fast among the community, without any kind of central direction, and after a while Twitter integrated support for [hashtags][2] 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.

[][3]The 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][3] 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.

[2]: https://support.twitter.com/articles/49309-what-are-hashtags-symbols “What Are Hashtags ("#” Symbols)?" [3]: /img/wp-uploads/2012/07/githubplusone.png