Traffik

Problem statement

Stavanger is the fourth largest city in Norway. It is home to many oil companies and as a result traffic congestion is significant. The traffic is particularly bad during rush hours. Existing tools like Google Maps mainly focus on major roads, leaving smaller streets — often used as detours — unaccounted for.

Possible solution

Our client wanted to build an app that would allow people to beat the traffic. The app would show traffic on small roads and allow users to report traffic jams, accidents, road works and other situations.

Competitive Analysis

Our closest competitors were Google Maps and Waze.

Neither platform effectively reported conditions on smaller roads.

During brainstorming session we discovered that people were trying to avoid traffic by taking detours and becoming stuck even in worse traffic on small streets.

I came to the conclusion that what can make our app different was crowdsourced reporting.

Users

I created an empathy map using a new persona - which I called Stian. Stian helped us understand users goals, needs, and frustrations.

With Stian in mind, we were ready to brainstorm the app’s key features.

Features

I carried out a brainstorming session to gather all ideas and thoughts. Here's the summary:

• Display a map and pins on it
• Show train delays
• Showing the best route
• Roadworks with their expected end date
• Display accidents via pins
• Traffic
• Simple, blocky interface for ease of use while driving
• Present relevant news
• Integration with traffic webcams
• Support night mode

Not every feature could be easily developed - it took several weeks to estimate the cost of potential features. The product manager then needed to consult the client regarding the budget. During the first stage of the project the client decided to focus on the core features:

• Displaying a map and pins on it
• Display accidents and roadworks via pins
• Allowing users to report situations on roads
• Displaying city webcams and news

Designing the flow & wireframing

I designed the flow on paper. Once it was established, I used Balsamiq to create basic wireframes. In the end, high-fidelity version was created in InVision.

Designing the menu

The menu design went through several iterations. First attempts...

and some testing led me to:

Following best practices I wanted the menu to be at the bottom of the screen. That way users can reach it more easily with their thumbs.

In the end I tested a few versions, including a version without icons.

83% of participants (6 users) at the A|B test picked the menu that had both text and icons.

Testing

I was constantly testing the ideas, flows and designs throughout the project. I tested parts of interactions with clickable prototypes (like adding cameras to favourites or adding a road accident on the map) throughout the designing process by giving users small tasks.

Final conclusions

After launch I discovered there was a significant sign-In wall. A logical solution was to allow users to get to know the app before they committed to sign up.

Not only did we allow users to check the app before registration but we also significantly shortened the form. This reduced the drop-off rate by 30%.

Before & After:

I also decided to get rid of traditional, multi-step onboarding screens - and replace them with some informal tips. Those would be shown to the user after a while and only when they hadn’t discovered something by then:

Another bigger issue that appeared during user surveys after launching was that users expected route optimization — a feature we hadn’t initially prioritised. This feature was out of scope due to technical and budget constraints.

After launch we added additional functionalities such as: finding parking spots (with available parking spots left) or train delays.

Final designs