When Walt Disney created Disneyland, he left the grassy areas unpaved and unfenced. Having opened the park to the public, Disney watched where visitors walked most as they navigated the theme park. When clear pathways emerged from all the walking, Disney had the paths paved.

Disney knew that centrally planned park walkways would be inferior to those created organically by Disneyland visitors—Disney understood that desire paths are opportunities.

Desire paths—a.k.a. desire lines or cowpaths—are the unofficial dirt trails cut through grassy open spaces marking the shortest distance from A to B. They are crowdsourced solutions to constraints and inefficiency.

College campuses often have similar stories describing how their sidewalks were created. For example, take a look at the Michigan State University campus:

An aerial photo of Michigan State University. Source: Google Maps.

As useful as desire paths can be for landscape architects who design physical spaces, when it comes to digital spaces like the Internet, desire paths are considerably harder to see. Users can't blaze a trail through the JavaScript and HTML. No desire line is cut into the DOM or across in-app workflows from the plodding mouse movements and clicks of users.

So how can designers, developers, and product managers see the desire paths if they never get made?

You need a way to see the negative space.

The hidden intent behind the rage.

For those unfamiliar, Rage Clicks occur when someone clicks repeatedly on some part of your site. Rage Clicks have many causes, from confusing UI to slow-loading videos. They can even be the result of clicky links that are actually working as they were intended to be used (E.g. "Next page" links that get repeatedly clicked and register as "Rage Clicks").

Rage Clicks are born from missed expectations. They hint at unfulfilled desires. Users click click click on a button, link, badge, or icon, thinking it will take them to Point B only to find they're stuck.

We've seen this first-hand at FullStory. Replaying sessions of FullStory users we noticed Rage Clicks on a specific part of the UI—the little user avatar that displays next to a user's email address. Check it out:

Why ... won't ... clicking ... this ... avatar ... do something!

In addition to the avatar (or a Gravatar, in some cases), in the sidebar of FullStory you can see a user's name and email address and how long they've been using the product.

Our intent in incorporating this avatar in the design of FullStory was to remind users they were watching a specific, real person's experience. So what intent were users signaling by Rage Clicking the avatar?

We replayed user sessions in FullStory to find out. Paying close attention to what it was these Rage Clicking users were doing before their rapid-fire clicks, we were able to tease out the hidden intent.

Avatars are common UI elements across web applications and websites, which means that they come loaded with expectations. Users expect a click on an avatar will result in additional information.

See, for example, how a click on the avatar in Facebook explodes the user profile. This is almost default behavior for this type of element.

By not meeting the expectations of our users—expectations we had never even considered—we created friction in the user experience, as captured by Rage Clicking behaviors. Thankfully, the solution was simple: we made clicks on the avatar bring up more information about that user.

We learned from this experience how Rage Clicks act as a proxy for user desire. There's a desire path that almost wants to be made—but no amount of clicking will create it. By using Rage Clicks as a proxy for desire, we can uncover that path, pave it, and improve our product.

While our users can't always tell us what they hope to accomplish with their clicks, by examining the context around their interactions using session replay, we gain the user's perspective.

From Rage Clicks to Jobs-to-Be-Done.

Using Rage Clicks as a proxy to surface desire paths requires we infer the intent of the user. What is it they want to do? To answer this question, we use Clayton Christensen's Jobs-to-Be-Done framework. Jobs-to-Be-Done teases out user intent because it shifts the perspective away from the product and towards the desired outcome—where user desire leads:

In order to understand what motivates people to act, we first must understand what it is they need done—the why behind the what.

Jobs-to-Be-Done or "JTBD" helps articulate the high-level reasons behind decisions. It's an "outcome-driven" approach to building products.

For Rage Clicks, you can use the JTBD framework by asking the question: what job is it that people are trying to do when they Rage Click on [the element in question]?

To apply JTBD to Rage Click observations, ask:

  • Does the element being Rage Clicked have context beyond your site? In our FullStory user profile example, avatars are common elements on the web. What expectations do other sites impart to the element? Imagine how the Rage Clicked element my be used outside of your site or app. Then consider what users might have tried to do the last time they clicked that type of element.

  • Where do users go before and after the Rage Click? If you see a user Rage Clicking all over a button, then suddenly navigate a series of menus at speed, it's possible that that's them taking the long way around. Compare their overall journey with that of other users to see if there's a correlation.

  • Do they use search? In some cases, you can use search functionality on your site to provide clues about what users really want—they might even spell it out for you.

    (In fact, examining sessions in FullStory that include interactions with your search bar can be a highly useful approach to surfacing desire paths entirely separate from using Rage Clicks.)

  • or Just ask them. If you really can't tell what a user is trying to do when they're Rage Clicking an element and you see that it's more than an isolated problem with one user, consider reaching out and asking directly: “What were you doing when you last did this—where were you trying to go?”

Triangulating around user intent using the above questions can help tease out whatever it is that users hoped to accomplish through their Rage Clicking.

Hypothesize and test. Pave the path.

Once you have an idea about whatever unmet desire exists, test it out. Use FullStory search to find sessions of users who interact with your proposed "paved path" (Your test).

See if users appear satisfied by the new experience. If they look frantic or exit out of the experience only to Rage Click (or show other signs of distress), do more research, ask more questions, challenge your assertions, and try again.

If user engagement is improved by your test, pave that desire path for everyone. It's that simple.


Using Rage Clicks as a proxy user desire and teasing out intent using Jobs-to-Be-Done makes for a powerful strategy to drive incremental product improvements.

Search for Rage Click sessions in FullStory to get started. Go see if you can blaze a trail or two.