A new take on Google Maps Navigation — Design sprint day4&5
A new way to Navigate
Quite simply, a prototype is anything a person can look at and respond to. A prototype doesn’t usually have to be very complex in order to learn what you need to know.
Prototype
It all comes down to this day where all my observations and assumptions finally end up in a quick and dirty prototype. There are different activities suggested for prototyping. That includes,
- HTML/CSS
- Invision or similar tools
- Keynote — heavily used by Google Ventures
- Paper Prototype
There is no restriction on the tool or the level of details (preferably low-fi) you bring to your prototype. It’s all about –
Quite simply, a prototype is anything a person can look at and respond to. A prototype doesn’t usually have to be very complex to learn what you need to know.
Keep in mind the bare minimum before building a prototype
- Keep it Minimal and real
Even if things are not pixel perfect, a user can tell you what they understand about your product and what they don’t. With this, you will learn much faster, iterate faster before investing time in the final design. - Write real text
Try not to use dummy text such as “lorem ipsum” because the intent behind studying the users while interacting with the prototype is to see how they explain things and test their understanding. “dummy text” limits your learning.
Prefer a prototyping tool over coding. When you have one day to come up with a prototype, coding often delays the progress. Stick on to a tool that helps validate the idea faster. Google ventures suggest Keynote.
Prototype walkthrough
It’s important to build a click-through prototype or load up on an actual device, however, I end up making still images using the Sketch app.
With still images, you lose the transitions from changing roads but you can still learn a lot. You can see if all the critical informations are covered, if the movement and current location of the vehicle is understood, if the text size is right, if the color scheme looks okay, how clear it your information retrieval etc.
Day 5: Validate
I am finally happy that the prototype is out, and this day is all about showing the prototype to users and perform a user study. Since I will be the one who will be providing feedback, I want to make it real as possible by doing a self-critique and try to raise some questions about the solution. I also have to keep in mind that today is not about usability testing — but test if other users of this product will understand the feature, etc.
Would you be able to forgo the digital map and go with no map interface for driving?
Yes, I think so. I probably need a more interactive prototype to really answer this question.
Will this solution fits all geographical conditions?
Since all navigation road signs are geometrical in shape and since the app clearly follows the directional landscape of the route, this solution should fir all geographical conditions.
What do you think about the usability of this feature on a city street with no nearby street reference?
For a driver who is seeing the road and the street in question, only he needs to see is how far he has to go to take the correct turn. And since the map gives you just that and does no confuse with nearby turns, this shouldn’t be a problem. However, a live prototype will definitely test this case..
Do you think this feature to be optional and not triggered when the minimum speed goes above 20km/hr?
I strongly recommend this feature to be experimental and optional. However, I am not sure if a minimum speed trigger is a good idea.
Why did you go with the dark theme?
A couple of thought on this, one, it will reduce distractions and strain with too many colors on the digital map. Another reason is it will promote longer on time of the app as the dark theme consumes less power.
The prototype only talks a little about the current state of the vehicle and how changing traffic conditions is updated. This is mostly because I couldn’t come up with a dynamic and interactive prototype due to the nature of the product that I have taken for this sprint. I will try to address this issue in the future sprint.
Success metrics
I understand that this article is very biased to my own satisfaction. I strongly believe that a new experience such as this can bring new user behavior and bring change the way people navigate with their digital maps. I am happy to see how the sprint finally evolved.
Closing thoughts
This was a long sprint and I deliberately wanted to try Google sprint processes as its a great way to work with constraints. At work, it will be difficult to follow all the processes and experiment with different activities. Also, in the future, I will try to do more personal sprints that involve personal use cases than creating new experience over any existing product features. I must explore more on prototyping that includes real data, micro-interactions, animation, and other obvious feedbacks.
Next, I try different design sprint frameworks or mix processes to come up with my own unique style of addressing a problem statement. I thoroughly enjoyed the process and I hope you find this interesting too.
Thanks for reading and please connect with me on Twitter or feel free to reach out to me.
Useful Links
Google Venture(GV) resources:
The Design Sprint
Day 1: Understand
Day 2: Diverge
Day 3: Decide
Day 4: Prototype
Day 5: Validate
Others:
Thoughtbot product design sprint repository
Sprint day activities
Create . Pitch . Critique design sprint series
Previous: Day 3— Choose the right path
Originally posted at arunantony.co
