Map vs Path

Posted on by in Design, Process

It’s a simple idea that can help your digital product take shape; when a user enters your system, do you hand them a map or a path? What’s the difference? Great question, and in this case, the metaphor is pretty literal.

Maps: 

These products solve problems that are vague and broad. 

Some great examples of maps are:

  • Photoshop
  • Excel
  • Slack

Each of these examples gives a user a blank canvas, with the tools to create whatever outcome they want. Users need to spend lots of time on these products, whether it’s modeling complex financial models, putting your boss’s face on a picture of a dog or creating silly channels with your co-workers. These products don’t force you to do anything. They’re usually very complex and require some time for users to find their true value. The problem that they solve is open-ended and vague. 

Ask yourself — is there one true goal of Photoshop? Sure you could say “editing photos,” but you can do so much more than that. Users of photoshop have highly personal workflows that create very specific relationships to features. They are not just editing photos but doing very personalized tasks. 

It’s also hard to give these products north star metrics. How do you measure the success of Photoshop? There are so many ways to find success in Photoshop.

I am sure the Photoshop team has success metrics but it is much less tangible than with a path. 

Paths: 

These products solve specific problems that have one outcome. 

Some examples are:

  • Lyft 
  • Venmo
  • Hopper

The workflows in theses apps are prescribed by the application and don’t let you deviate from the typical workflow much. Sure there are features like settings or contacting support but there are not many subfeature sets.

This is basically the opposite of a map – you give the user the ability to do one thing and do it as efficiently as possible. Users don’t need to spend lots of time in these products, meaning engagement is not a key goal. When designing an app that is a path you might think “how can I design an experience with as little friction as possible?” Whether it’s getting a ride, transferring money or booking a plane ticket, the product only really gives you one option and you would not go to it for anything else. 

These products also have clear success metrics and it is easier to find north star metrics for them. For Lyft, this might be the number of 5-star rides completed. For Hopper, it might be the number of flights booked. 

Gray Areas:

There are some apps that you could argue are sort of in between these examples. Something like Spotify is a great example. While Spotify’s core service offering feels more like a path (listen to any song anywhere), their product feels a little bit more like a map. Maybe you want to listen to a radio station, maybe you want to make a playlist or find new music based on a genre. To make things more clear, searching for a song is a path and browsing search results is a map. These gray area solutions are hard to construct with tact – typically I see products start off as a path (there is one clear workflow). Then, as more features get built and the service offering expands, the product turns into a map (many different options that all help solve one problem). This is not always the case but it is a great way to start tackling your MVP. 

Figuring out whether your user needs a map or path is a fun and important part of defining your product. Also, it’s a fun exercise to imagine your product as the opposite of what it is now. What if Venmo was a map? What if Photoshop was a path? Overall designing navigation for a site is tricky and there is never one right way. 

Want to learn more about interaction design? Check out Designing for Interaction: Creating Innovative Applications and Devices by Dan Saffer.


Now hiring developers, designers, and product managers.
Apply now: www.carbonfive.com/careers