Doc On Demand: Product design
After 6 long weeks of brainstorming, prototyping, design iterations, and evaluation I can finally proudly introduce DocOnDemand, the app that will help you find the best doctors for your needs.
But let’s take a step back and see where this is coming from.
About one year ago I decided to embark in the Interaction Design Specialization by University of California San Diego on Coursera MOOC. In the last 12 months I have been taking courses on Human Computer Interaction, Needfinding, Prototyping, Testing. In this post I will describe the work that went into the final course of this Specialization: the capstone project.
How it all started
Believe or not, when I started the project I had just stabbed my hand by accident and have been visiting several doctors for checking up my hand… and it was while waiting for my turn for one of those visits in the medical center waiting room that I had my inspiration. I will design an app that will help users improve their health.
Needfinding
In my country health insurance is rather expensive and people tend not to go to the doctor unless strictly necessary (as I did when I stabbed my hand) because of the high costs. This could cause health risks since prevention could be often overlooked.
What if there was a way to make sure people visit the doctor when it could be most useful for improving their health rather than only when strictly necessary but in an affordable way?
To answer this question I started by observing and interviewing some friends and colleagues.
As a start, I focused on investigating how people approach booking a medical visit with a doctor. I wanted to know how they book a visit and how they pick the right doctor when they need one.
This quickly gave me some great insight to start work from. Here’s what I learned:
- Before booking a visit you need to find a doctor, and this is already challenging: everyone looks online for doctors information nowadays, but there simply are too many websites giving scattered information and it’s hard to compare your options.
- People want to find a doctor they can trust.
- People expect to do everything online: including booking a medical visit.
- Travellers and expats want to find a doctor that speak their language!
- It’s not always easy to know with what type of doctor book a visit (ie. Do I need an oculist or an ophthalmologist? What’s the difference?)
From these needs, I started brainstorming how my app could help.
Storyboards
At this point I asked myself what this app was supposed to be doing, but I quickly realised that the possibilities were simply too many and that I needed to narrow down possibilities and focus on a more specific goal. Being an expat myself and loving to travel, I decided to design a product that would help you quickly find and compare the right doctor for your needs, especially while being in a foreign country, where language barrier could be a problem if you need to communicate what your symptoms are and where you might not be familiar with the neighbourhoods.
From paper to pixels
I got the needs and the goal, now I just needed the app. When you need a quick way to sketch a product and see if your ideas work out, paper prototype is the best.
Paper is easy to manage: edits and refinements can be done easily quickly re-sketching by hand the screens that don’t work or simply pasting some new modified patches on top of the parts of the screens that need fixing. It’s also pretty funny to test with real people.
After several tests with my guinea pigs to understand what features could work and how to smoothen up interactions with the interface, it was time to move on to pixels.
Prototype, Evaluate, Improve, repeat!
I mocked up my paper prototype with Balsamiq and built the interactions with InVision and then evaluation and test begun.
To collect feedback, I asked to use it to many in person: friends, family, colleagues, fellow students, but also online to random people when performing A/B testing on UserTesting.
At each feedback and iteration, the prototype evolved and changed, hopefully in something more usable, and useful at each stage.
Ta-dah! The result
And finally, after all this brainstorming, prototyping and testing, here I am telling you how it all went down. I have made this video to explain how Doc On Demand could help you find the best doctor for your needs. I hope you like it.
Do you want to see more?
Here’s the link to prototype: https://invis.io/W583POX7V
I’d be happy to hear what you think.
What’s next
I have a couple of ideas for design improvements already. I’d like to introduce a some features that I think would make the app more complete: allow results sorting by different factors, improve online booking, help the user decide which specialty to pick based on their symptoms, and a few more.
Or I might decide to start building it and then improve later.
Which path should I go down to? Product or Engineering? That’s my eternal question!
While I decide, I thank you for reading.
Surprising facts and acknowledgements
After one year of after work courses, I got to the end of it. It’s been an amazing journey that allowed me to learn loads of new things. I’d like to list a few that I think I would have never learned if I didn't embark in this specialization.
- Design takes an awful lot of time and PATIENCE — was hard for me to get there, but I succeeded
- Design is not only about background colours and pretty interfaces — common misconception among developers
- Very few people actually use a product in the same way you do
- Learned how to use some tools that were alien to me 1 year ago: Balsamiq, InVision, R(!), iMovie, …pen+paper
- I struggle a lot with storytelling
- Dr. Nick’s full name is Dr. Nicholas Riviera.
Thanks to everyone who helped through this journey!
