Desire Path Product Design

Have you ever found yourself so frustrated with social media websites that your workflow includes 3 other apps just to get basic work done? Is your Photoshop workflow so custom, complicated and so full of shortcuts and third party plugins that few other mortals can decipher it? If you said yes; you probably discovered (or created) a Desire Path.

In landscaping design, Desire Paths arise from unforeseen inefficiencies in the way the designers attempted to guide people through their paths. Something like this:

Desire paths can cause a rift between the people who design the landscapes and the people actually using them.

I saw a battle between landscapers play out while I was in my undergrad; the administration stubbornly tried to stop people from cutting across a lawn. Hedges and fences did nothing to stop us; in fact, it motivated us.

While I didn’t see the end of that fight while I was still in school, I checked in on that spot on Google Earth, and we won:

You can tell they really didn’t want to make that path on the right because otherwise they would’ve aligned the mortar properly. Photo Credit: Google Earth.

How do Desire Paths translate to product design?

In product design, Desire Paths are all the tools, tips, and shortcuts people use to get work done faster with your product, or to use your product in ways you never intended.

A couple of examples, one big and one small of Desire Path design:

YouTube was originally intended as a video dating site. The idea was, people would upload videos of themselves as their dating profile. Users quickly started uploading all sorts of videos to the site and YouTube pivoted to what their users wanted.

2. The Facebook Branded Content Tool

The “with Adobe Spark” copy is how Facebook complies with advertising guidelines and regulations about sponsored posts. Mari Smith.

Itwas created because people with big Facebook pages discovered an unintended way to use Facebook’s pages product: getting paid to promote stuff. Facebook didn’t want to thwart that desire path, but Influencers keep getting in trouble with the FTC. So they created a tool to disclose the fact that these were paid posts + some additional tracking features and shared insights.

Product managers should also look towards third party apps and plugins built for their products. These kinds of products are usually desire paths, particularly for users who use your platform daily, at high volume, or to make a living (aka power users). For example, It’s not a big leap to see Facebook’s post scheduling tool partly as a response to how popular tools like Hootsuite are with their power users.

How to prioritize Desire Path features.

Features inspired by your users’ desire paths should not automatically be treated as top priority; as any product manager knows, just because users want something doesn’t mean it is a good feature to build into your product.

Instead, Desire Path features should be prioritized in the same way you prioritize your other features, with a couple additional factors to consider:

How many people use the desire path?

Going back to my University example, the Desire Path that was ultimately paved over wasn’t the only desire path on campus. There were other, more manageable ones where people didn’t completely kill the grass or made a muddy mess when it rained. If your feature will pave over a muddy mess, you should prioritize it higher.

2. Avoid the Power User pitfall.

Desire Path features, almost by nature, will tend to skew more toward power users. They are the ones using your product the most, getting frustrated and finding those tips and shortcuts that make up product desire paths.

When considering power user features, make sure you don’t build features targeted to such a niche group of Power Users that it does not further your overall product goals, nor justify the time and resource investment. That’s the Power User pitfall.

When my company, dose., ran a big network of user-generated content sites (like smartphowned.com and givesmehope.com), we ran into this issue all the time; even though we didn’t realize it at the time.

The websites were successful because we allowed power users to submit a lot of content, other power users would vote that content up or down, and we’d publish the best, based on our results.

In building features for the site, we constantly looked toward building features that encouraged power users to submit and vote more because that was the lifeline of our network of sites.

Along the way, there were multiple instances when we both avoided, and fell into the power user pitfall. I’ll give one example of each.

We fell into the pitfall when we tried to build a robust User Account system for our network of sites. We heard from a small number of power users that they wanted a system that allowed them to track their submissions and comments across our sites. We got excited with this idea (as we also were power users of the sites ourselves) and after a long development time we had a User Account system with a ton of bells and whistles that made no impact on our bottom line or our traffic. We had misjudged how many of our users actually wanted the feature; and to make matters worse, we built more than what they asked us to do.

We navigated successfully with the “builders” we developed for each site. They allowed power users to quickly and easily create the content in our site format. Take this one from Smartphowned, as an example:

Yes, if you’ve seen a Smartphowned post, it’s probably fake and someone made it in this builder. Dose.

The builders took a lot of time and resources to build. However, they worked great at encouraging our power users to submit content; the Smartphowned builder in particular was a massive success for us and catapulted the site to 60m+ monthly pageviews for a period of time, on the back of a strong number of submissions.

The best way to avoid this pitfall is to have a great ROI analysis (Return On Investment) and to never forget: You should be your own product’s #1 power user; but this can make certain features look more useful than they actually are.

A good way to improve a feature’s ROI is to scale back its scope and build something that a higher percentage of your power users will use.

A great example of this is Facebook’s scheduling tool:

The Facebook scheduler only lets you schedule one post at a time. However, it’s still the best way to schedule a video post.

Facebook created this feature as a response to third party scheduling tools like Hootsuite or Buffer. These two third party services let social media managers (the “0.01%” of Facebook power users) schedule hundreds of posts to multiple accounts using just an Excel spreadsheet.

Facebook’s scheduler, on the other hand, only lets you schedule one post in one account at a time.

Naturally, Facebook’s feature didn’t replace Hootsuite for social media managers. It did, however, help the thousands of small business owners and influencers who want to schedule 3–4 posts a day and have no need for something more complex.

Once I started looking for Desire Path features, I started finding ideas everywhere. This is hopefully the first in a series of desire path product feature ideas; first up: Tweetstorms.