Coursera Interaction Design Capstone: Dash Mechanic
The idea for my project, Dash Mechanic, actually came from an earlier assignment where we storyboarded a few different design ideas. One board showed a user using a key fob with a built in touch screen to monitor your car’s diagnostics, lock and unlock the doors, initiate the panic button, etc. When choosing the Glance brief from the list of capstone design prompts I thought back to that example and decided the idea had some legs.
From the beginning the user need seemed obvious — everyone who owns and drives a car needs to take care of it. They need to fix it. They need to clean it. They need to perform routine maintenance on it. For many of us (those of us who aren’t grease monkeys) we sometimes neglect fixing and maintaining it to the recommended degree and, as a result, pay more on repairs than preventative care to avoid those costly bills. Any way you slice it I think many people would benefit from monitoring what’s going on with their car. And since most of us own a smartphone, putting that technology in your pocket so you can keep track of it seemed obvious.
Interviewing
The process began with interviewing a few different people to get a feel for the practicality and usefulness of the app. I asked a number of questions about their current state of auto care: What do you know about what goes on under the hood? Can you fix things yourself? Do you feel accomplished when you fix something? When alerts and lights pop up on your dashboard, do you know what they mean? Do you need to grab the owner’s manual? Do you have the owner’s manual? All were important in deciding what I should include on a dashboard app for your car.
Sketching, Wireframing, and Paper Prototyping
I started with a few common things that you’d care to see notifications for. Oil. Check engine. Other fluids under the hood. The usual suspects. I also checked out other existing apps with dashboards that monitored various metrics in real-time for inspiration. Fitbit was the most practical. Looking back at what I had sketched from the aforementioned storyboarding exercise, I drew a few parallels and began with a home dashboard.
Although the actions were limited, having a user test walk through my paper prototype was valuable for instinctive things like “I wish I could go back” or “I don’t know what that button would do if I tapped it”. It’s easy for me to get caught up in the details of conveying the dashboard how I envisioned it that I sometimes neglect simple user affordances.
Refining and Digital Prototypes
When it came to scaling up even further and developing functional digital prototypes, I used a few different tools to find what I was looking for. For the initial mock-up prototype I turned to InVision. In fulfilling the initial task of allowing a user to tap and proceed through the app — InVision worked pretty well. When it came time to actually implementing feedback from that exercise and increasing some complexity in the functionality — I needed something more robust. That’s where I turned to Proto.io. That tool helped tremendously for realizing my initial vision and what I could use to interpret that into a prototype much easier. I was able to utilize this higher fidelity prototype for more advanced user testing and could tailor a more complete experience than before. This was crucial in making smarter, user-based decisions as I progressed toward the final weeks of the project. From the in-person user tests to the online testers from usertesting.com, I was able to make necessary refinements that I may have otherwise neglected on my own.
So the essential lesson I took out of this project is that actual users define the decisions you make. You can begin a project with as much research and user-profiling prior to launching your project, but the actual users will define the successes and failures of it.
Links
