A social tool to better inform doctors and treat patients
SERMO is a doctor’s social network - a place where doctors can talk with each other and navigate the difficult profession of medicine together.
We started to notice that doctors would increasingly share diagnosis and treatment-related information with one another - and this type of content ranked among the most popular types of content on the network. We thought to ourselves - how could we structure this helpful advice in a way such that the content could be more easily accessible and found, and thus more useful in solving the problems our doctors encountered every day?
Thus, I was tasked with designing a prototype and then MVP of a drug ratings product, utilizing data that was already being collected on drugs, that we could use to confirm demand and refine usability. I gathered feedback often from our lead designer, product manager, engineering team, and management during my process.
Insights through user testing
We conducted several interviews with doctors to better understand how the diagnosis and treatment process works. Based on these conversations and personas I created for our community, we established the objectives of the initial experience, which I used to design a prototype:
- They want to see, at a glance, the overall value of a drug for a certain condition
- They want to be able to see how valuable a drug is, compared to other similar drugs
- They want to be able to talk to one another about specific treatments
Then, we tested the prototype in depth with doctors on SERMO. We noted aspects of the product that were clear and unclear, especially the call to actions related to our 3 objectives. While the ratings and comments were well understood and intuitive, we found a number usability problems.
One example of a usability problem was in recognizing and changing the desired indication (condition) associated with a drug. We found that using an expandable list of pill-like buttons to select indication was ineffective and not easily noticed by our doctors. As a result, I explored different options on how best to display and choose a condition. I chose to go with a sticky scrolling navigation bar that would allow the user to filter by condition (as well as data points like age group, country, and specialty of doctor) no matter where on the page they were.
The drug ratings app is now launched in active use by the entire social network, and refinements are made continuously based on much more data and feedback.
As I reflect now on my team and I's process, it is clear that developing 3 significant features before testing with actual users resulted in a delayed timeline and overuse of team time in the development of the initial prototype. If I were to work on a similar project in the future, I would advocate for more user testing done sooner on initial concept and features. If possible, I would recommend shadowing doctors and observing their diagnosis process and mental model, as opposed to asking about it after creating features. More initial user research would have contributed to earlier insights, a better use of product/engineering teams' time, and better tools completed earlier for doctors to use.