How to Sproute your navigation

Intro

Hi there, my name is Julius. I’m a Danish interaction designer. Sproute was the result of my 4 month residency at Move Lab.

Visit the project

In short, Sproute is a navigation app that diversifies how you travel by offering a set of characters that get you to your destination in different ways.

My role in the project was research, concept development and design, while Florian Porada took charge of front and backend development for the project.

images

Overview

This blog post is an in-depth look at the explorative research, technical constraints, and design decisions that factored into our process.

We’ll go on a sightseeing tour of all the points of interest on our design journey. Along the way we’ll stop by:

1. The origins of the project
2. Going from idea to concept
3. Prototyping and development
4. Hypothesising another version of Sproute
5. Visual and functional character design
6. Reflecting on the outcome
7. Speculative futures
8. Further reading and related projects

As you can see we have a packed schedule, and a bit of a long journey ahead of us, so please bear with me.

1 What were we trying to achieve?

On a personal level, my intention for the residency was to continue evaluating my ideas from past projects, namely that user-friendliness doesn’t mean focussing on efficiency and “frictionless” experiences.

This involves questioning assumptions that our interactions with technology are built on, and trying to reimagine them. With the lab’s expertise it would be possible to look at this topic through the lens of mobility.

image

Most navigation apps are built on the assumption that the most useful route for you is always the fastest and most efficient. In the process of using a certain set of criteria to generate a route for you, it also sorts out a bunch of other routes.
Instead of sorting out these routes, I wondered how many different ways could we get from A to B? and what might be achieved by getting rid of the fundamental ASAP criteria of a routing algorithm, and being ok with a trip that was a couple of minutes longer?

These ended up being our guiding questions throughout the project.

(I won’t go into the theories and projects that influenced us here, but if you are interested then I’ve compiled a list at the bottom of this post)

2 From idea to concept

With the intention of testing the ideas with a larger audience we set 3 goals for the final outcome:

• Create a critical project that is still approachable and understandable.
• Make a fully functioning product.
• Get people to actually try it, not just read about it.

imgae

2.1 Experiments

To get into the headspace of navigation behaviours and in order to catalyse discussions among the lab members, we came up with a range of small experiments. Experiments are kind of like experiential research, in that rather than reading about an idea we came up with small experiences to try out. For example navigating the city by smell, drawing a map from memory, or marking down every street you go down.

The experiences we tried out weren’t trying to emulate what the final outcome would be like. Having an external “thing” (like a map or shared experience) to discuss meant that we could much more easily understand each other’s abstract thoughts and specific observations about navigation.

image (more images here, as a slideshow ,Tourist Map, Trying out apps: Derive, Beeline, OffBot)

2.2 Frameworks

These experiments helped create a common framework and language that we could use for the rest of the project:

2.3 Islands and seas

Within the sea of unfamiliar space in a city, we have islands of knowledge. These are the places that we are familiar with and visit often. Our journeys always take us through this unknown sea but is it rare that we venture off the small land bridge of our commute and explore the parallel streets.

2.4 Micro vs macro deviations

Macro deviations take people to completely new areas allowing them to create new islands of knowledge. In contrast, micro deviations cultivate a more mindful exploration of the space between our islands of knowledge.
The focal points of a Macro deviation are often quantifiable and foreseeable, whereas micro deviations are often about unpredictable and subtle experiences.

3 Prototyping

In order to help conceptualise our prototypes I’ve categorised them into Role, Look and Feel, and Implementation, using the framework from the research paper “What do prototypes prototype?”.

Keep in mind in our actual process it wasn’t this clear cut, as the prototypes were happening simultaneously and would melt into each other.

3.1 Role

A month or so into the project we were having a company-wide meeting, and I jumped on the opportunity to try out the design directions that had started to bubble to the top.

We designed, illustrated, and then randomly assigned a range of activity cards that had routing tasks for the participants to carry out during their daily travel. Since the focus was on the experience and not the technical implementation, making cards was much faster than trying to program a digital experience.

Images

With this prototype we were trying to understand what would make the experience of taking detours or deviations most compelling, and not just something to try once and then forget about. From the experiments and discussions we landed on play, learning, and personalisation as the 3 types of experience to test out.

3.2 Feedback

After the 2 weeks we gathered the participants back and lead a short workshop.

Amazingly the role-playing aspects of some of the more oddball activities, such as asking people to pretend to be stealthy ninjas, had actually led to the most engagement and reflection among participants.

This power of characters and role play, to get people out of their usual behaviour patterns and into a new mindset, was what we decided to harness in Sproute.

image

3.2 Implementation

Once it started to look like we would be making some kind of routing based digital experience we wanted to understand how to produce these alternate routes in code.

The first thing we did was play around with Graphhopper’s “alternate routing” functions. (Graphhopper is an open-source route planning API that the team had worked with before).

Digging through and testing out the alternate route functions allowed us to quickly understand how the various parameters affected what routes we could generate.

images (OSM)

Using Open Street Map (OSM) we could look through and visualise what kind of landmark and city data that we could use to generate potential characters. For example, if OSM hadn’t had streetlight data then it would have been much harder for us to create the nightlight character.

The open source nature of OSM means that unfortunately the app itself is biased towards communities where there is more available data (usually well-populated western countries), but in the future, the hope is to encourage Sproute users to contribute back to OSM in areas where the data is incorrect (e.g missing streetlights).

image (routing tool)

3.3 Look and Feel

Once the idea of using character based routing was settled on, and we had verified that it would be possible to translate it into code, the next challenge was making this new framework feel approachable.

Coming from a background in industrial design I usually start out with physical prototypes even for digital experiences I am working on. Drawing, cutting, and glueing UI elements together out of paper makes for a much more fun and expressive process, which in turn translates well into the final outcome.

These paper protoypes led us to the idea of re-contextualising the character selection screens from games like Mario Kart and Street Fighter. Using a familiar and simple interaction also helps transmit the concept behind Sproute to any newcomers.

images (app prototyping)

4 Reach Soon

Reach Soon is a side project we worked on to compliment the more experimental aesthetic and experience that Sproute was taking. We wanted to show how the ideas we had looked at might translate into traditional or existing navigation apps.

In short, we thought that notifications would work well as a way of nudging people into a more curious and reflective mindset. For example maybe you could bookmark places to visit and be sent a message if you happen to be close to one of them while out and about.

The lab’s mission is to create and spread ideas, both to our mother company FREE NOW but also to the technology community at large. With this in mind, the most important thing was to outline the landscape of the topic, rather than just focussing on making a "revenue monster" and on the way find ways of how it fit's into FREE NOW's products.

image: mock up sproute meets FREE NOW

5 Characterful Design

Back with Sproute we had to work out how many characters we could make, and which ones they should be. Factoring in time constraints we decided to aim for 4 characters. (at the time of writing we have managed to make 3, and have the 4th one planned out).

This initial ensemble was chosen to exemplify the scope of potential future characters and appeal to different facets of a person’s needs: from precise functionality to open-ended exploration.

image: character design

5.1 Sightseer

From the start it felt obvious that we should exemplify the kind of character that has a bunch of “sub-destinations”, like cafes, parks or shops.

It would be simple to add these categories in the future, but if we could only pick one to exemplify the functionality then we wanted to avoid something that would feel overly commercial (so no shops or cafes).

During our research, we found that for many people use landmarks as a reference when navigating. So by having a character that navigates via landmarks we could simultaneously helps tourists explore a city, while also increasing the locals’ sense of direction and self reliance by adding to their mental library of navigation landmarks.

Image of the backend route generation for Sightseer> (maybe multiple images)

5.2 Nightlight

The Nightlight shows that efficiency and utility in navigation don’t just mean arriving as fast as possible, in this case the personal safety and comfort of the person has to be factored in as well.

For a long time we had planned a character called the Flaneur who would take winding paths through the city. However, in the middle of designing the Flaneur, I stumbled on a discussion online where many women were asking for a “safety mode” in navigation apps, which would avoid creepy and unlit streets at night.

It was instantly obvious that we should jettison the Flaneur in favour of a function that was obviously much more valuable for a lot of people. This late insight also highlights the blind spots that occur in a project and lab lead by men. As a personal reflection, the first half of the process leant more into experimental exploration than methodical user research. In the future, this could be remedied by more diverse teams, and also by taking the time to do some more interviews, even in more explorativel projects.

Image of the backend route generation for Nightlight> (maybe multiple images)

5.3 Commuter

With the Sightseer already providing macro deviations, we wanted a character that would tap into the gradual exploration afforded by micro deviations.

Whether it is school, or work, or the gym, most of us have a journey that we take multiple times a week. We mostly take the same route back and forth, yet by adding just a few minutes to the trip you can get a much larger and more diverse set of routes.

With the Commuter we generate 100 of these slightly different routes for you, and give you a new one every day. Over time trying out these routes will help you fill in the blanks of your knowledge, and might even help you find your new preferred route.

On a side note: I would highly recommend reading the abstract of this research paper on the lasting effects of train strikes on the commuting routes of Londoners.

Image of the backend route generation for Commuter> (maybe multiple images)

5.4 Co-op

The Co-op character is the next planned addition to the crew, and is the most game-like of the lot.

You play it with one of your friends, and the function is a bit like hide and seek. First, you designate an area that you would like to play within, then your friend will hide four characters somewhere within that space. You aren’t given a route, instead, you have to plan one yourself based on where you think they could be hiding.

Playing a game with someone else requires both creative decision making and empathy, as you have to try to predict what decisions your opponent has made.

The theory is that characters with multiple participants could be used as a way of getting people to reflect and discuss experiences that they might otherwise take for granted.

Image of the backend route generation for Commuter> (maybe multiple images)

6 The app itself

With the first release of Sproute we wanted to focus on and convey the eye of the duck (the core interaction), which is to say the experience of selecting a character and then going on a trip.

This meant that the user flow was boiled down to simply selecting a character and then going on a trip, without including the potential (but non-essential) features such as stat-tracking, settings, or route-saving.

We experimented with 3D character models, but settled on simple 2D aesthetic since it would make it easier to create some sort of visual harmony between the characters and the user interface.

Lastly we introduced the “Journey Overview” button as a way of making a less map-heavy means of understanding the route. It provides some basic universal information like journey time and distance but then also tailors the information to character who is currently in use.

sproute app screens

7 Summary and reflection

After having worked on something for 4 months, and at times grappling with the irony of not knowing how the project itself would get from A to B, it is encouraging to see where we ended up

Sproute is now a fully functioning app that you can go and try out today, and despite the conceptual thinking behind it, my grandma still understands how to use it. So, in the end, Sproute fulfils the 3 objectives that we had set for ourselves:

• Make a fully functioning product.
• Get people to actually try it, not just read about it. (hopefully, this blog has made you want to try it!)
• Create a critical project that is still approachable and understandable.

7.1 Speculative futures

My (Julius’) hope is that, if nurtured correctly, Sproute could start to evolve from a proof of concept to an open-sourced routing platform. Which is to say, rather a place for sharing specific routes, it would be a place to share the algorithms that create those kinds of routes.

A central repository of routing algorithms would give research groups and hobbyists a-like a centralised place to share their creations. Bundling functionalities in the same platform means that certain gate-way characters can help people build trust in the rest of the system and then eventually branch out into the weirder characters.

The last thing to mention is the role that non-linear navigation could play in a future in which we end up with autonomous vehicles, or even in the milder future where we become even more reliant on our mapping apps.

Taking a wrong turn or getting lost can be a blessing rather than a curse. It affords us the opportunity to explore our environments and learn new things about familiar places. Using efficiency and utility to mean “As Soon As Possible” means we’ll lose those moments of discovery. Non-linear routing like what we’ve explored in Sproute could be a way of introducing a little more uncertainty back into the system.

Related things

missing.