A social tool to better inform doctors and treat patients
SERMO is a doctor’s social network - a digital form for the disappearing physical doctors’ lounges in hospitals, and a place where doctors can encourage one other, learn from each other, ask questions, and navigate the difficult profession of medicine together.
Before this project, this online space for doctors had focused on offering unstructured and broad ways of interaction. For example, doctors could create posts with subjects, body copy, images, links, tags; they could also private message one another. Around this time, 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. For example, a South African general practitioner shared his recommend treatment for E. Coli patients that he often encountered in his country, and this information was then used by a doctor in Canada to successfully treat a 4-year-old girl. 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?
As we looked at existing products and markets, we identified a gap in the understanding of what doctors thought of particular drugs at scale. Notably, there was no two-way communication between doctors about specific treatments that existed. Given our existing community of 600k physicians, we were in a unique position to leverage our members' cumulative experience to create a clinical tool that would help our doctors' make better prescribing decisions with their patients. I was tasked with designing a prototype and then MVP, utilizing data that was already being collected on drugs, that we could use to confirm demand and refine usability. After a hand off of the initial design concept by our lead designer, I was the sole designer on this project. I gathered feedback often from our lead designer, product manager, engineering team, and management during my design 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:
- 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
For this prototype, these stories were explored and ended up translating to displaying ratings and giving ratings for a drug, a drug ranking table, and a comments section. For the MVP, we focused on the desktop version of the app.
Then, we tested the prototype in depth with 3 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.
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.