Rendia's flagship product was a Netflix-like web app that lets doctors (Optometrists, Ophthalmologists, and Otolaryngologists) play medical videos in their waiting room, exam room, or on social media. Doctors were able to use our animations to help explain medical concepts to their patients, but weren't able to this quickly and efficiently while in the exam room.
The Exam Mode is an extension to our web platform and a native iPad app that lets doctors navigate through the human body and visualize conditions and treatments to their patients.
I was the only designer but worked closely with a project manager and a small team of web and iOS developers. I spoke to our sales team, customer support team, and the doctors themselves to understand who was buying the product and who was using the product. I then produced a variety of sketches, mockups, and prototypes, performed remote moderated usability tests, and a few rounds of iteration improving the product.
We observed doctors use our product to explain a prognosis while in the exam room. It was hard to provide context—the videos helped but the screen was usually obstructed by the doctor's hand. It was a lot of effort—a playlist for a certain condition and treatment needed to be created prior to the appointment. There were technical hiccups—doctors are smart but bad at computers.
We defined success as a product that was
1. Quick—Doctors were using this tool in the exam room, so they needed to articulate a patient's condition and move on.
2. Smart—Doctors couldn't waste time finding the right video and needed the right content at the right time
3. Interactive—Doctors told us they wanted to look "cool" (their words). They were moving away from plastic models to screens and iPads
I combined what I learned from talking to sales, support, and with a few actual doctors/current customers and created a persona which covered what type of tool they needed, what they were trying to accomplish, and what obstacles they faced.
We wanted to provide a better experience than what doctors were currently doing, so I looked into just that—the playlists they already created. I understood which videos they put together to see what types of presentations they were trying to make.
It was difficult to find parallels to our product so I explored a lot of ideas in low-fidelity and getting feedback before running in any one direction.
Designs were impacted by constraints which created a few conflicts:
1. Screen size and device—Although we decided not to focus on phone-sized devices and portrait orientation on the iPad, our interface still needed to work on multiple resolutions.
2. Patients have a hard time seeing—Not only did patients had difficulty focusing on a smaller device or screen, they had eye problems so our content needed to be as visible as possible.
3. The touch inputs varied—Whether it was with a mouse cursor or a finger, our navigational system needed to be easy to use and accessible
An idea that didn't make the cut
One of the ideas for navigation that I originally explored was a small modal docked to the bottom-left of the screen.
The menu contains a grid of items that constantly updates based on your recent selection to show you parts of the anatomy that are connected to your current view, likely your decision.
This idea didn't work because it obstructs too much content. This was an issue we knew we would face but it made the viewing area considerably less, especially on an iPad. Although we didn't run with this interface, we incorporated the navigational concept into our final design.
I used Sketch to continue exploring ideas and created detailed designs used in testing for feedback and communicating functionality to the team. These static designs were used to create clickable prototypes that simulated common user flows.
In addition to a bottom-left dialog box, I very briefly proposed a horizontal sliding nav. This type of menu just wasn't suitable for the amount of content we needed to communicate: thumbnails and links to conditions, treatments, and views.
We chose to go with a horizontal menu bar at the top, holding thumbnails of popular views, and a left-hand sidebar containing searchable lists of links to conditions and treatments. This design was an efficient use of space and resembled common interaction patterns like sidebars and dropdowns, so it would likely feel familiar.
I explored how we could improve certain features and micro-interactions through motion studies and animations. This helped convince project managers to pursue worrying about the details.
I used Framer to create realistic prototypes that mirrored end-product functionality. These prototypes gave users dynamic control like scrolling through lists and scrubbing through videos.
These prototypes were also what we tested with. We contacted a few of our power users, users who would gladly pay for the product, even asked for the product
Not only was I able to be a part of conceptualizing, designing, and shipping the web app and iPad app, we were able to iterate on the product. Post-release, we added features like drawing (highly requested from our customers), incorporated other videos (as prototyped above), and focused on micro-interactions.
We knew were were successful because of the feedback we were hearing from customers from all channels (sales and marketing) and the signups in higher priced plans which included the Exam Mode.
The features in the app which fulfilled our goal of being quick, smart, and interactive were:
1. Making the most common views easily accessible and visible at the top of the app
2. Updating the searchable list of results showed the next most likely options, and options available on the current view through a visual distinction
3. Placing contextual hotspots on the viewing area so navigating the interface was intuitive by clicking where you wanted to go
Looking back, there are a few things that I would've done differently:
1. Perform in-person usability tests, similar to the doctor visits we performed in the beginning. During testing, we set up video calls with our users, gauging the feasibility and effectiveness of the product. Seeing the app used first-hand, in the environment in which it would be used, with real patients, would've gave us better insight into the products benefits and drawbacks.
2. Design with the developers. Our design needed to change a bit, during development—the scope of the project changed, more views were needed which meant adjustments to the UI, and settings/options menus were necessary to customize available views. This lead to more back and forth between design and dev due to our waterfall approach. Bringing them on earlier would've helped things go more smoothly down the line.
Being able to work on all aspects of the product design process as the sole designer taught me how to work with what I've got and talk to others often. Customer outreach wasn't always available so I needed to make a concentrated approach while getting feedback. Sharing work with others was important since there were no other designers to get feedback from, so I consulted PMs, devs, and other Rendia employees often to see what flaws they saw in the design.