- Literature Review
- User Research
- Lab Research
- Interaction Design
The goal of the project was to provide ANWB members with an interface to consume the real time traffic information that was relevant for these members, while also keeping them safe. The ANWB also wanted to create a vision for their traffic communication that would be sustainable for a 5 to 10 year period in new and old cars.
We started off with desk research.
As a team, we identified multiple research topics related to the problem space and decided to investigate them in our desk research. These topics included distractions and cognitive load, voice interactions, competitor analysis, human factor guidelines for automobiles and analysis of the existing ANWB app. My area of focus was distractions and the impact of voice interactions on cognitive load in the automobile. The key findings from these are described below.
I looked at distractions.
I wanted to understand what were the different types of distractions, what caused these distractions and what could be done to reduce distractions to increase safety.
Next, I challenged my assumptions and looked at the impact of voice interactions in the context of mobility.
I wanted to understand if voice interfaces could be beneficial in the context of mobility and to tackle my own assumptions that voice interfaces would have lower distraction.
Then we moved on to user research.
We looked into the problems and needs that users had in our interviews and surveys. The key findings from our interviews and surveys are explained below.
Next, we elaborated and defined our user groups.
Commuters are people who travel along the same route every single day.
They have most information about the route and don't need that repeated.
They only need information that reduces unpredictability.
They briefly turn into explorers when they are stuck in traffic and then decide to take an alternative route that they have never taken before.
Explorers are people who use turn by turn navigation to go to a new place that they have never been to before. This could be people whose jobs require them to travel to new places constantly.
They have no information about the route and need all the information related to the route that they are taking.
Explorers can turn into commuters when they have taken a certain stretch of road repeatedly in the past.
But how could we compete
against an established product
like Google Maps?
The market was saturated with established products like Google Maps that were primarily aimed at explorers who needed directions and turn by turn navigation. The ANWB didn’t have the capability to compete with these established products which is why we needed a strong differentiator for our product.
GAP IN THE MARKET
Commuters didn’t have any product that was specifically targetted at them. They had most information about the route and didn’t want that repeated. Since commuters didn’t have any specialised solutions and were forced to use navigation products, we realised there was a gap in the market.
Which is why we made the strategic decision to target commuters.
Armed with research insights, a deeper understanding of the problem and a clear strategy, we started concepting.
We laid out a few key insights that the concept would be based on and a few guidelines that we thought were important for our concept to follow.
Commuters don’t want to be bothered again and again because they are familiar with the route.
Commuters only needed information that reduced unpredictability on road (like delays and traffic).
The technology should improve safety without being overbearing or intrusive.
COMMUTER TO EXPLORER
Be aware that commuters turn into explorers sometimes and provide support when that happens.
If the commuter turns into an explorer like when taking an alternative route, the system will then switch to explorer mode to provide turn by turn navigation.
A typical bike ride with no traffic or a drive through a non busy road will not have any updates from the watch. The watch will remain ‘off’ for the entire journey - putting the technology in the background and allowing the commuter to travel in peace.
Our aim was to reduce visual, manual and cognitive distractions to improve safety. And in order to do so, we used gestures to ensure that the users' eyes are on the road, hands are on the steering wheel or the handlebars and mental distraction is minimal.
Asking information from the system (input)
Users would use the 'glance' gesture as an input to tell the device that they need information. This ensures that the drivers' hands are always on the steering wheel or handlebars and manual distraction is limited.
Confirming or cancelling an operation (input)
Users would use the 'flick' gesture to confirm or cancel a certain action. Flicking up would cancel an action and flicking down would confirm it. This ensures that both hands are always on the steering wheel or handlebars and manual distraction is limited.
Receiving information from the system (output)
HAPTICS + VISUALS
The watch would provide feedback through a combination of haptics and visuals. The haptics would ensure users don't miss the information and the visuals would be minimal to ensure that information can be consumed in a glance.
But how did we get here? And why did we choose a smartwatch?
We imagined our concept would work the same regardless of what form or device it took. We experimented with multiple forms/devices and tested them with users to understand which ones were the safest and which ones they preferred.
Because it is ubiquitous and has a very small learning curve and because people are used to it.
Because it has the potential to reduce manual distraction and make driving and biking safer and sales of smartwatches are increasing.
Button set + Phone
Four buttons shaped like a game controller which can be attached on the steering or handlebars and can be used to ask for information without any visual or manual or cognitive distraction.
Button set + Screen
Another idea that we had which we thought was worth exploring despite some clear flaws.
We then set out to prototype and test each of these forms.
I was responsible for prototyping the Button set + Phone. This included low fi foam prototypes to high fi 3D printed models. I tested the form with users with small, medium and large hands to ensure that it was easy to interact with.
Once we had all of the prototypes, we tested them with users.
The smartwatch and the button set + phone was found to be the safest of all the devices. But the smartwatch was considered to be far more practical on a day to day basis and just easier to carry when switching from a bike to a car. The ANWB also had business concerns with the button set + phone because of their limited experience in producing custom hardware.
Based on this, we chose to work on the smartwatch and iterate and refine the created prototype to a final product.
The final product
Before driving or biking
SMARTPHONE OR SMARTWATCH
The information needed before the journey can be accessed either on the smartwatch or through the mobile app. The functionality would remain exactly the same. Through the mobile app, the information can be accessed through widgets or through the app or through notifications in the morning. Based on user preferences, the app would also recommend a vehicle for that particular day based on traffic and weather.
During driving or biking
TRAFFIC DELAY (Haptic + visual feedback)
The smartwatch would provide notifications like shown in this image during the journey. The minimal design ensures that information can be taken in, in a quick glance.
During driving or biking
ETA SCREEN (Glance gesture)
Through a glance gesture, users can ask the watch for information which will show the duration of the delay and the estimated time of arrival.
During driving or biking
ALTERNATIVE ROUTE (Flick gesture)
In the event of a traffic delay, the watch would ask the driver or the biker if he/would like to take an alternative route. If the user flicks yes, the system would then enter explorer mode and would provide turn by turn navigation till the user is back on a familiar 'commuter' route.