I first heard about desire paths from Daniel Burka during his presentation at the Web Directions South 2008 conference in Sydney.
The term “desire path” refers to a path made through desire by users of an area instead of by the intent of the designers. For example, on the right is a photo I took in Dickson, Canberra of a carpark where people regularly climb over/under the fence because to go around the fence would add an extra 20 metres to their trip. The fence is nothing but a slight annoyance for pedestrians.
Desire paths show a failure by designers to accommodate the goals of pedestrians who simply want to get from A-B as quickly as possible. Designers sometimes like to take pedestrians on some scenic tour of a place, which can work for gardens where people have come to explore and browse but for things like shopping malls, university grounds etc it should be about optimising the movement of people along the shortest route.
Back when I used to go to church they would have end of year camps where 500 people would descend on a campground and set up tents for 2 weeks. There would be instructions to follow designated paths and not walk between tents. Of course, many people ignored that instruction because walking between tents and taking the most direct route was much faster even though it resulted in people frequently tripping over tent ropes.
Whilst designers need to take into account the aesthetic aspect of path design the primary function is to support the goals of the users. Failure to do so will result in your beautifully-designed landscaping being criss-crossed with bare-earth foot-worn routes.
In user experience design for software and the web we can also take this concept of desire paths to explain why users can ignore the process or method that the interface designers dictate should be followed to complete a particular task. There’s often more than one way to do something and while there are some people who’ll be a stickler for following the letter of the law as laid down by the designers, many people will figure out their own way – and it will surprise you what some people do.
A basic example is form validation and excessive mandatory field entry requirements. If the user doesn’t understand why you require 20 bits of information from them and if they don’t have the time to fill out all that data or don’t want to supply it to you then they might do things like put “00000″ in the postcode field, or “someone@example.com” in the email address field. Just like how desire paths will ruin a landscape, rubbish data like this injected into your system because your interface does not consider users will ruin the integrity of your database.
This is why it is so important to understand the people who will be using a system and though user stories and personas to document user goals, constraints, environments and other influencing factors.
Boundary fences like the one in the photo above serve no one. They don’t stop people going where they want and they simply annoy people who have to clamber over them. I’m surprised someone hasn’t taken a hacksaw to it yet.
George Redgrave curates the Desire Paths group on Flickr.
// purecaffeine.com, UX, design, social media and Gov 2.0 blog by designer Nathanael Boehm, Canberra, Australia. Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Australia License.
{ 4 comments… read them below or add one }
Thanks for the article! It reminds of a related idea, turned into a positive concept: “pave the cowpaths.” Christian Crumlish was talking about this at Web Directions, and it’s covered in more details in the book he wrote with Erin Malone, “Designing Social Interfaces”.
Basically the idea is to observe the users of your software, and see where they go (regardless of, and often against, your wishes) and then build them pathways that match their desires.
Great post Nathan, loved it and the path at Dickson is such an obvious example that you can pretty much see anywhere.
Matt touches on a building block of marketing in that you build something in response to a target market/users needs or problems. Then it truly fits and will probably sell itself.
The old saying “Build it and they will come” no longer applies.
Should we ammend the saying: “If they come, they will build it”?
Great post. As a user, I often get frustrated by the lack of search (or a bad implementation of search) and the absence of site maps on large websites. It’s very frustrating when you know what you want, and you know it’s on the website somewhere — but you have to jump through hoops to get there.
Still, I can see the rationale behind putting up fences (literally and figuratively). You don’t want people to jump across your park fence without paying an entrance fee. Sometimes, making it a little more difficult for users to get somewhere has a reason behind it. Take terms of use, for example. Websites don’t display the document directly anymore; they just link to it from the signup page with a checkbox saying “I understand the terms and conditions.” It’s all well and good for the user when he signs up — it speeds things along. But it also makes it seem okay for the user not to read the terms, which might lead to unwanted consequences in the long run.