From initial research and discussions, my team and I decided to focus on a problem that affects many people having medical treatment; when going to a doctor’s appointment patients can feel overwhelmed (by information or emotions), which can lead to missing or forgotten information. This can cause difficulties in later health related decisions or communications. After interviewing Doctors we also discovered they all wished they had more time to communicate the diagnosis and treatments with patients.
After defining the problem we hoped to solve, we laid out our mission for the product we were to develop. Our mission was to empower patients to record, manage and share consultations with medical professionals and loved ones. Reducing the risk of misinterpretation, forgetfulness and maximising the efficiency of a GP’s time with a patient.
Once the problem, goals and our mission was outlined, I began speaking to patients and doctors about how information and diagnosis is given during a medical consultation. Inevitably experiences and outcomes were varied, but patients tended to be told information verbally and either given leaflets for further information or advised to make a follow up appointment to discuss further.
Although these strategies are useful and help individuals, both doctors and patients admitted that not all information is absorbed at the time. Often there are tight time restrictions for appointments and not all information can be given.
Below is a summary of a call I had with a Junior doctor about interactions with patients and how news is given.
Above: Summary of a call with a junior doctor about how news is generally given to patients. 1. Prepare the patient for news ('this is a difficult conversation'). 2. Tell them the diagnosis or information. 3. Leave the information to settle for a few minutes to begin to understand. 4. Either ask the patient to come back for another appointment or give them leaflets. Generally if the information is complicated a patient will be too overwhelmed to take in everything, so a recording could be easier. Information could be given via trusted source website links. A way to remind patients about future treatment appointments would also be very helpful.
Key insights from user research:
Patients can struggle to remember all information that is given during a consultation (especially if it is bad news). They may leave with a distorted understanding and further convey that to loved ones.
Doctors have limited time with patients, often it takes doctors a long time to learn all symptoms as patients often find it difficult or embarrassed to explain some problems - this uses up a lot of time in appointments.
Patients often brought in with them either: a pen and paper, a loved one or their phone to record an appointment - these are our main competitors.
There are many untrustworthy and inaccurate sources on the internet, patients often read all information about diagnosis and treatments which can scare-monger. Doctors would prefer providing a list of information outlets that patients should focus on.
From the information we gathered from interviews and working with mentors who were doctors at the hackathon, the team wrote down all possible features that they would want to see in the product (however unrealistic). The post-its were then grouped into categories that summarised the topic that the post-its discussed (seen below).
After recording the category titles (seen above) we repurposed the post-its to perform a MoSCoW feature prioritisation exercise. The MoSCoW looks at features that Must, Should, Could, and Won't be included in the design and development for the weekend MVP product. Must features would be included in this MVP. Should features would be included if it was fast to implement and improved the design significantly for users. Could and Won't would be implemented in future iterations.
The feature analysis exercise allowed us to minimise the amount of features to a realistic level within the allotted time. By doing this as a team and reviewing with potential users we made sure that we are all on the same page for future steps. The category title groupings would be useful for us when naming and placing features in the design.
Features that were included in the Must list were: Audio recording, Medication, links & references/ research & further reading, password protection, shared with loved ones & other consultants, overview of topic discussions, symptoms and results.
For this project it was very important to know users and understand what their needs were. We created empathy maps and personas (representations of a user audience) based on groups of people we interviewed.
Above: empathy maps of a doctor (left) and a newly pregnant woman (right). Empathy maps help to build a persona profile. Before creating a persona it is helpful to understand what they would think, see, hear and say - an empathy map adds that perspective.
Following the empathy map, we created the four personas that represented some of the user types that could interact with the product. The personas were:
Bosan - Newly pregnant with her first child
Jim - 65 year old retired plumber being tested for a cancerous cells
Zein - Happy-go-lucky traveller that needs vaccinations for travel
Dr Harrison - Experienced GP
To see the full personas document (including profile, behaviours, needs and how we can help), click here. [Disclaimer: this was a lean project (due to the rapidity of development), the document is very basic with no image or structured layout]
Understanding and empathising with the personas helped to develop task and page flows for each of the personas.
Having page and task flows sketched out for each of the personas, we began wireframing.
For this MVP we focused designs on two personas flow: Dr Harrison's and Bosan's. There are many people who could interact with Bosan during her pregnancy (midwives, GP's, ultra sound technicians etc). Bosan would also be likely to share appointments with her husband and mother. Her case was perfect to display the flexibility of the product.
We sketched wireframes in a rapid design session to begin prototyping. Once the concept was on paper the developers began working to maximise time, as we (UX designers) began working in Sketch to produce low to high fidelity wireframes.
Above: Initial digital wireframes. Left to right: Text message saying consultation notes have been added by the doctor and link to web app; My Med login page; consultation page (will automatically be taken to this page if click through text link and logged in); (right) consultation pages of past consultations.
Above: User testing with potential patient.
The journey changed slightly after testing and feedback from more doctors and legal professionals.
The recording would be pitched as summary tool or as an aspect of the appointment rather than used for the whole appointment. This adjustment was because it could change the dynamic and relationship between doctor and patient -doctors may be unwilling to give advice (they would have otherwise given) if they were recorded and could have legal ramifications later on. The patient would therefore record having discussed it with the doctor, empowering them to further understand their treatment. There would be an agreement when signing up that information and recordings could not be used in a medico-legal case.
Some hackathon mentors were health tech business experts - advising on business plans and how to get funding. Whilst the developers were working, I worked with a mentor on how we would take the product to market and which companies we should target first.
Above: Value and risk grid to understand which industry sector to approach
Talking through a basic business plan, considering costs and who to approach, really changed our design into a product that had a strong market potential. From that point decided that working on the presentation was vital in order to get funding. The pitch was so short that there would be no time to present a prototype in action.
Our team efforts shifted to focus on getting content ready to clearly and confidently pitch our idea.
Above: Presenting to judges and fellow hackers our My Med application
The pitch discussed problems many patients and doctors experience when receiving or providing medical care. We covered features of the product and how we would take it to market.
My Med gained $10,000 funding for further development of the project.
Please contact me if you would like to discuss My Med further or view the presentation.