The final concept went through a couple of iterations and prototypes to become what it is now. In total, four prototypes were made. Here's how I worked and what I learned from it.
Early on in the process I was figuring out how tot prototype and test design ideas for the car. Since the Tesla has a browser I was able to create a couple of simple web prototypes that were click-through and useful in the very first stages of the process. Because the linux-based operating system and browser in the Tesla are very limiting, I had to code my own simple html page and make them manually link to each other.
Paper prototyping is always an option but is really labour-intensive and won't allow you to design and find usability problems early on. Since the nature of the project, I wanted both concept and design insights while testing.
To test a car interface, some form of car cockpit is definitely a requirement.
After prototyping using the Tesla browser with a simple clickthrough prototype I quickly stumbled upon the limitations. Not being able to design for the Instrument Cluster is a big problem. So I researched what would be a good investment for my project without constructing a very expensive car simulator. With help from my father we drew a sketch and I started putting it together with Niels Mulder at UNITiD. Using iPads would allow me to control the prototype on one iPad from a Macbook using Duet. The other iPad would be operating on it's own. I ended up using Principle to prototype the Main Computer Unit, using the mirror app on iPad.
The process of building the setup.
Our setup consisted of a custom made dashboard where users could interact with an iPad that resembled the Main Computer Unit in the car. The steering wheel had three buttons that controlled the Instrument Cluster. The user would sit in front of the wheel and watch the driving footage. Meanwhile the user would be given tasks to complete throughout the test. While testing we’ve learned quite a few things that we would like to share:
Get the context right
Driving is a complex task and users will often forget what they’re actually doing in the car. Therefore it’s important to talk and test in an environment that is as close to the real deal as possible. Interviewing a user on their driving habits is best done in the car, for instance.
Use a realistic script
Users will calculate routes in their head and if it’s not realistic, it will hurt their ability to empathise with your scenario. So make sure your prototype resembles real driving distances and travel times.
Give your test subject a task while driving
Not every user is focused on driving the car while testing. In our setup a user couldn’t crash, so we had trouble making sure users would actually pay attention to the road. In order to do so, we gave users tasks to complete while driving: tell me when we’re changing lanes or let me know when we enter a roundabout. Not every user will take this seriously, so either stress the importance or make it a game and write down the score for them to see.
Record the test
It’s difficult to manage a setup with multiple screens and possibly a phone prototype too. Filming everything will make sure you won’t miss a thing. You’ll get useful footage and be able to judge your own testing practices.
The process of user testing.
During the project I've documented every single day on Instagram. There you'll see some more detailed shots of what I did. •