Cloud based web application for patients to review and share medical consultations

My role: UX Designer & Project manager. Working with another UX designer and two developers

The Hackathon
This was the world’s first dual-nation live broadcast hackathon event; MiSK’s ‘Medical Internet of Things’.
There were hackers in London and Riyadh, Saudi Arabia. The talent of teams and the mentors (who supported hackers with their expertise) was really inspirational.

The Brief
The hackers were given 48 hours (Friday midday to Sunday midday) to produce a product/ concept that fitted into the category 'Medical Internet of Things'.
At the end of the 48 hours, each team pitched for two and a half minutes for a prize fund investment.

The Outcome
Given a $10,000 investment to further develop 'My Med'. A cloud based web application for patients to review and share medical consultations at a future time. Review data includes: appointment summary voice recording, symptoms, diagnostics, medication prescribed and next steps.

Skills I used in this project

Competitor Analysis

Interviews

Feature prioritisation

Wireframing

User Testing

Presentation

Contact me about this project, click here

Outlining the problem and goals

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.

User research

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.

Feature Prioritisation

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.

Key Insights:

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.

Creating Personas

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.

Wireframing

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.

Business 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.

Presentation

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.

Outlining the problem and goals

User research

Creating Personas

Wireframing

Business Case

Presentation

ArtRunners

Craft.co

SOCIAL