Paving digital desire paths
Desire paths are unofficial shortcuts that demonstrate how people tend to take the path of least resistance. As software designers, we can learn from urban planners: desire paths are a form of user feedback, and by taking users’ digital “desire paths” into account, we can create better software.
If you’ve ever seen unofficial shortcuts of dirt and flattened grass cutting through hedges or around corners, you’ve seen what urban planners call “desire paths.” Desire paths are common enough across cultures that they have many different names: desire lines, cow paths, kemonomichi (“beast trails”), chemins de l’âne (“donkey paths”), and Olifantenpad (“elephant trails”).
Importantly, desire paths aren’t just the result of one person deciding where to go: they’re the result of many people making the same choices independently. People often make similar choices when navigating an environment because people are naturally drawn toward the path of least resistance. Scientific studies have shown that our decision-making is heavily influenced by how difficult we think the different options will be. So when the official paved path isn’t the most direct route to where you want to go, you might decide to walk a more direct, unofficial path instead.
Desire paths can also emerge when hikers want to admire scenery just off the official path, or when pedestrians want to avoid car traffic. In any case, desire paths are physical evidence of how people feel about their environment. One desire path might say, “It takes too long to get from this building to the carpark,” and another might say, “I want to get a better look at this beautiful lake.”
The urban planners, architects, and park rangers who are responsible for designing and maintaining physical spaces sometimes think of desire paths as a problem to be stopped. They can try to address this “problem” by blocking off desire paths with fences, large rocks, or strongly worded signs.
But when viewed from a different perspective, desire paths can actually point us toward better solutions. After all, desire paths give us real information about what pedestrians actually want — and knowing what pedestrians want allows designers to craft spaces that better match people’s needs. For example, rather than taking a top-down approach to pathway design, architects for several different college campuses, such as Virginia Tech, Illinois Institute of Technology, Michigan State University, and Reed College, waited to see which routes students would take before deciding where to place paved paths.
The same phenomena that create desire paths in physical spaces apply just as much in digital spaces. If users want to accomplish a particular task using a digital tool, they will find a way — whether the product supports it natively or not. On Tumblr, for example, the lack of a dedicated comments section meant that users started using the tags section of posts — intended to be used for searchable keywords — to express their opinions on shared content. Despite being a tool originally designed for financial calculations, spreadsheets are often used as databases the world over (sometimes to disastrous consequences).
As software designers, what can we learn from the unintended uses of our products? Do we take an authoritarian approach, putting additional restrictions on our products to discourage undesired behavior? Or do we embrace these unauthorized solutions, ”paving” the digital pathways that our users have created for themselves?
Twitter has several of the most famous examples of paved digital desire paths. When users needed a way to create extremely specific search terms, they started appending the octothorpe symbol (#) to the beginning of words and phrases to create what are now formally supported in the product as “hashtags.” When users started manually putting “RT” at the beginning of tweets when sharing text authored by other users, Twitter eventually created an official “retweet” feature to accommodate this practice.
Email has been around for over half a century, and in that time people have used email in surprising and unintended ways. So when designing our own product, Twobird, we looked at common email hacks to craft a better email experience. For example, email was designed to allow people to communicate with each other — but users often email themselves notes and reminders. With this in mind, we built notes and reminders directly into the email experience as a first-class feature, so that you can more easily capture your ideas and store them in the same inbox you already use to manage your day.
Another common trend that we noticed was people using their unread emails as an ad-hoc todo list. They use the unread function — originally designed to indicate an email that hadn’t been read — to indicate an email that requires further action at some point in the future. Why? Well, unread emails stand out visually in the inbox, and marking an email as unread is an easy one-click action. And since we spend so much time in our inboxes anyway, having a to-do list in your inbox means you’re less likely to forget about important tasks.
This digital desire path indicates that people want to see which tasks require their attention, without having to expend unnecessary effort. With this in mind, we designed the Twobird inbox to make it even easier for users to see their to-dos: the top of the inbox contains the to-do section, which includes unread email threads, notes, and triggered reminders. We even added a to-do field that makes adding new tasks to your inbox seamless.
Being a product designer requires understanding users’ desires, and you can learn a lot about users’ desires by analyzing their workarounds and shortcuts. Users are neither inherently correct nor incorrect when they take the path of least resistance. However, if you want users to behave in a certain way, you need to create an environment in which the easiest choice for them to make is the one that you want them to make.