Before we started working on NaviExpert for Android Auto, we wanted to find out what works in existing sat-nav apps and what frustrates drivers. We began by looking at other products, and then tested our own interface before rolling it out.
My role
I recruited drivers, organised meetings, prepared questionnaires and conducted interviews. I worked alongside the product owner, who took notes during the sessions and was responsible for the interface design. Together, we analysed the results.
On the road
We travelled with drivers to see how they used Android Auto in practice. In the apps being tested at the time, maps would sometimes load slowly or freeze, voice search didn’t always work, and some basic functions were difficult to find.
One problem stood out in particular: using the car’s screen didn’t always mean you could put your phone away. Searching for a petrol station or accessing your favourite places sometimes required you to pick it up again.
There were also issues with the interface itself. Bright colours were distracting, large panels obscured the map, and drivers couldn’t always pan or zoom as they’d expect.
These findings helped set the direction for our solution: sound controls directly on the main screen, a clear mute status, muted colours and a non-glare night mode. Voice search was also a priority for the product owner.
Testing our interface
Once the product owner had prepared the design, we travelled to Warsaw to test it with six users. We used a prototype on a tablet, observing how participants found features and carried out typical tasks.
We also asked them which features were most important to them. A survey, completed in November and December 2021, supplemented the information gathered during the tests. All six participants highlighted easy access to search history, the ability to manually browse the map, and the lane assistant. Five highlighted quick audio controls, and four mentioned voice search.
As these were the preferences of a small group, we considered them alongside the observations from the sessions.
What needed refining
Adding a petrol station to the route turned out to be one step too many. Participants expected that simply selecting it would be enough to add a stop. It was also not always clear whether the petrol station had already been added to the route.
Audio controls also required attention. Some labels were ambiguous, and participants wanted the interface to automatically return to the map after changing a setting.
Another issue was the map being obscured. The search and alert panels took up too much space, and some of the hidden buttons were difficult to find.
Not everyone wanted to use the app in the same way, either. For several participants, voice search was essential, whilst one person preferred to type in queries and stated that they did not use voice commands. We had to cater for both methods of use.
What the research revealed
The first stage enabled us to identify the problems drivers were already facing. Testing our own prototype then revealed where similar difficulties might arise in our design.
On this basis, specific recommendations were drawn up: simplifying the process of adding stops, providing clearer confirmations, refining the audio control labels, and keeping a larger portion of the map visible. The research also provided further arguments for prioritising voice search.
For me, the most important thing was linking what drivers said with what they actually did — first in their cars, and later whilst using our prototype.
