MedicOn

The challenge

As the first UX Design Study Case I decided to build a logical case which helps connecting doctors and patients during Covid-19 pandemic that might be used in a near future in telemedicine as well.

Connecting Doctors and Patients remotely through telemedicine during Covid-19 pandemic.

Scenario

We are experiencing a very complicated time, of sadness and uncertainty, both personally and professionally, where several people are experiencing emotional, physical and financial turbulence without being able to carry out our lives normally, due to the Covid-19 pandemic, which it has already led to the death of hundreds of thousands of lives.

The WHO recommendation is social distance and / or lockdown, to avoid overloading the health system and delaying the proliferation of the virus. However, this measure directly affected all those who depended on face-to-face work, including doctors.

Even with all the measures and precautions, there is still a lot of fear and fear on account of the population to remain in public environments, which has led to a reduction in attendance by doctors in general.

Despite the fact that many doctors are attending with reduced hours and numbers of patients per day, according to the new CFM Resolution 2,227 / 18, recently issued, telemedicine has the potential to become more real and present in people's daily lives, which can change the relationship between doctors and patients in the not too distant future.

Project's goal

The objective of the business is to make communication between doctors and patients safe and comfortable for both sides, through a 100% online platform, without any loss in the quality of the consultation and diagnosis, for any case in which there is no need for a face-to-face examination, and that guarantees the doctor the receipt for his work in a safe way. At first, the idea is to explore virtual assistance during the crisis in the midst of a pandemic, which may extend indefinitely by adapting the target audience to the new style.

CSD Matrix

When we identified that the possible users of our product would be patients and doctors from different areas of care, it was necessary to understand a little more the profile of each one in order to seek to solve their pain. For that, I started creating a matrix of certainties, assumptions and doubts (CSD) of both users.

User profile (Proto Personas)

After defining the assumptions about users, to facilitate the visualization and identification of each side of this story, I created two proto personas, that of the patient and that of the doctor, in order to understand their pains, needs and painkillers.

Pixar Storytelling

‍

‍User 1 - Patient

Once upon a time there was Roberta, a young 30-year-old architect, single, resident of SP, connected, digitally engaged, accustomed to making payments and purchases over the internet. There's a cat called Bruce.
Adept of regular exercises and with an active life, during the pandemic, like many, she had to leave her place of work, people and the regular activities of her daily life. He started working from home office and communicating more over the internet and, due to the fear of contagion, he avoids exposure in public environments as much as possible.
One day, Roberta needed to schedule an appointment to do the routine exams she does every year to monitor her health, but she couldn't find a time because her doctor is not performing face-to-face visits with the same regularity and she also does not feel safe to go to the office. .
Because of this, she decided to look for an alternative that offered virtual assistance and discovered an online platform where she could not only schedule her appointment, but also be seen remotely, virtual and with the same doctor who was used to consulting. And his health plan covered the care.
Roberta then made the appointment, was answered by a video call with her trusted doctor and started her treatment without facing full offices and taking the risks that frightened her.

---

User 2 - Doctor

Once upon a time, Júlia, a 42-year-old nutritionist, married, mother of a 4-year-old boy, resident of SP, connected to the Smartphone, used to making purchases and payments via the internet.
Before the pandemic, he attended in an office in downtown São Paulo, but like most doctors, after the Covid-19 crisis, there was a drastic reduction in the number of patients. Many of them have complained of weight gain and deviations in diets, changes in schedules and habits, but most have avoided going to consultations for fear of being contaminated, if not in the office, during the journey, after all, not all have their own vehicle and many go by bus or metro to the center. With her son at home, due to the school recession, and despite being attending very little in person due to the reduction of patients, Júlia felt that she needed to reinvent herself and start attending remotely. That was when she discovered a 100% online platform, where she could assist her patients through health and / or private insurance and continue to do their job without losing quality, through video calls.
As her patients became aware of the platform, they resumed their consultations and she was able to take the opportunity to be closer to her son.

Interviews

With the personas and assumptions about your problems defined, it is time to check whether those assumptions are valid hypotheses. For this I will use two types of research, quantitative, to understand WHAT is really a problem and a qualitative one, to understand WHY this is going wrong and becoming a problem.

Quantitative research

To validate (or invalidate) the aforementioned assumptions of each persona, I decided to conduct a quantitative survey, which was sent by email and shared in groups where there were people who fit the profiles of users described on both sides, both patients , as well as doctors.

The main hypotheses to be tested were the reasons for the decrease in the frequency of face-to-face medical consultations and to check possible solutions for the scenario.

However, as they were two personas, the form was made conditionally, to identify the pain on each side. Below is the flowchart of the form, which directed the interviewee to what I would like to know, without biasing the questions, the first question being responsible for identifying whether the interviewee was a patient or a doctor and, from that point on, the questions were intended for the correct user, green for doctors and blue for patients. In the end, it converged on the research's final considerations.

Flowchart of the Quantitative Research Form

The Flowchart indicates how I managed the research using Google Forms to get information about the user I was trying to reach. The first question was the spliting point, whether the person is a patient or a doctor. The flow coloured in blue is the patient flow and the one in green is the doctors flow, But the last question in Blue is common to both, so at the end of the research both patients and doctors converged to the same point.

Quantitative Research directed at Patients

Quantitative Research directed to Physicians

Qualitative research

The qualitative research was carried out in person with some orthopedic doctors, because during the course of the project, I discovered injuries to my spine that needed attention and urgent clinical treatment and I took the opportunity to talk to them about their pains while they treated mine. Listening to them during the treatment sessions made me understand a little of the positive and negative impacts that the pandemic brought to their area as well as that of colleagues from other areas of medicine.

Outcome

Based on the results of the research, it was possible to validate some assumptions and invalidate others to create possible solutions:

‍

User Journey

Based on the information above, validated by the surveys, I decided to set up each user's journey within the scenario where the use of remote medicine was involved, to then define alternative solutions to the problem.

Patient

Doctor

Alternatives for Viable Solutions

The central idea of ​​the project is focused on telemedicine, so, although there are countless ways to solve the problem, within the context and the current scenario, I gave more attention to the solution that appears more consistent in the short term, but that can unfold to an eventual future scenario.

Thinking about the possibilities of connecting patients and doctors remotely, some insights emerged:

The first was an online platform that concentrated medical information on patients, by storing data and test results, which could be shared privately and securely with their mobile version for remote consultations via video calls. A medical social network, where patients could schedule appointments and doctors could attend remotely, being paid for their work. However, because it concentrates an enormous amount of information, the effort would be very high to carry out the project, being put aside, unless some very powerful stakeholder is interested in the idea.

The second idea was something simpler, making the manual insertion of data and test results in an application to share with the doctor, generating an information bank accessed by the doctor and the remote contact would be on account of other pre-existing applications. However, despite solving part of the problem, it was still necessary to include the financial question for the doctor, after all, how to receive for your services?

The third idea, despite being valid, was discarded because it was out of focus. Many patients said they were afraid of the face-to-face consultation due to factors related to hygiene and the behavior of others, which would be easily solved with restrictions, shortened hours, etc., and this type of application could be an outlet to seek professionals with schedules. more flexible and with available times for face-to-face consultations, however, there are those cases that need a certain urgency and telemedicine, which covers this speed, is not present here.

For the Gran Finale I left the two ideas that present the best solutions to the problem of remote medicine. Both are very similar, however, one of them proposes to connect with native applications focused on health, in order to create a database based on the daily information measured by these applications. However, according to research carried out with doctors, these applications are not so accurate, which could lead to mistaken conclusions and, therefore, to wrong treatments. There is a possibility of an improvement in these applications, or even the development of more accurate metrics within the project itself, but that would generate a lot of effort for construction, so the best idea ended up being the development of an application focused on telemedicine, covered by health plans, where the initial focus is consultation by video call. I leave it open for the insertion of accurate measurements, either through native applications or even an improvement of the project, remembering that the product is never finished.

‍

Effort vs. Vessel Graph Impact

Proposed Solution

Having defined the solution to the problem of the proposed scenario, I decided to start prototyping from sketches to streamline the process, check what difficulties users would encounter and propose necessary changes in the points that were causing problems within the usability of the future application. I made several sketches and low-fidelity prototypes to improve the usability of the application still in the scribbling phase.

Below is the most refined version of the sketches which was used for prototyping.

Low fidelity prototype

To create the low-fidelity prototype, I used the Marvel tool, in order to assess the fluidity and ease of screen transitions.

Click here to view the low-fidelity prototype.

First usability test

From the development of the scribbles, I asked some people to make use of the first version, which contained some problems of clarity regarding the objectives of the screens and buttons. I decided to improve and include icons and image representation to facilitate usability, which helped a lot, but there were some questions raised by users:

- A doctor can also be patient, how to include this section in the application? Will two accounts be required or will there be a possibility of transition between profiles?

- Will the delay be allowed at the time of the consultation? How will the notification be? How to guarantee the doctor's payment for the schedule even if the patient is forgotten?

- How will the clinical exams be done? Laboratories, equipment purchased or rented with wi-fi / bluetooth connection, applications integrated to the cell phone?

- What if I want to schedule an appointment for a minor?

As the proposal is to facilitate communication between patient and doctor and use telemedicine as an alternative to face-to-face consultation, the application proved to be very effective as the Smallest Viable Product (MVP). However, due to the complexity of the project, the above questions are pertinent and need to be further elaborated and depend on more extensive research.

Wireframes and User Flow

The medium fidelity wireframe was developed to test the ease of use of the product, because although the pain of both patients and doctors is different, the main idea of ​​the project is to be something simple so that both parties can achieve their goals in such a way easy as a face-to-face consultation. The flow of the patient is represented in blue and the doctor's in green.

‍

High Fidelity Prototype - v0

After testing the usability of the product, it is time to apply the Style Guides and refine the application, leaving it ready to be finalized by the developers.

First Version

Right below there is the showcase of the first version of the Product which faced an update after some reviews made by Beto Lima, a UX Designer from LuizaLabs.

If you want to check this first version of the app, click here.

‍

‍

Interface Update

After some adjustments in the product interface, I decided to create a new section only addressing the UI part of the product. ‍

‍

The creative proccess of app's product naming came from a contraction of these two words: Medic and Online due to the product main goal, which is a telemedicine app. With the name already defined, some alternatives for the logotype came to mind and lots of sketches were made until the final result. Imagotype, which is the image + the logotype, is a combination with a computer/tablet/cellphone screen and a stetoscopic, giving the idea of a virtual/online meeting. The logotype was created based on Ubuntu's typeface, which is also part of the institutional typography and has been chosen because of its name. According to Dirk Louw, PhD in African Phylosophy by Stellenbosch University (South Africa):

"A society guided by the foundations of respect and solidarity is part of ubuntu's essence, african phylosophy that talks about the importance of alliances and relationship amongst people, each one to another. In the free translation from africaner, ubuntu would be "humanity from one to another". A person with ubuntu is aware that he or she is also affected once their equals are opressed." Font: Inside Africa.

Because of this phylosophy to do good to one another, the typography was used as the foundation on this telemedicine app logotype's creation, and to reassing that it's online, a wi-fi symbol was added as well.

‍

The colours choice wasn't randomly made. It was used a research way through Color's Psychology and what each color represent or transmit to those who observe them. It was used an online tool called Picular for chosing the colours through key words as: medicine, doctors, health, calm, tranquillity and everything that reminds of health and well being. After I have defined the two main colours (the blue as primary and the green as secondary), I used another tool called Coolors to create a colour pallette with a tertiary colour, which was defined based on the chromatic circle using the half-complementary pallete, leading to a purple colour as tertiary one. However it was removed after some adjustments on the app.

Having the base colours already defined, I used the HSB matrix to generate the auxiliar colours. To the lighter ones I reduced saturation in 50/60 % and incresead the britghness to 90/100 %. The same proccess was used to neutral colours, or gray tones.

‍

Since the very beginning of Product Naming and Logotype development process Ubuntu's typeface has been present and because of the phylosophy behind its name was determinating she kept present in the whole product typography. On previous version of the product there was a third typeface, called Poppins, for headers on desktop and mobile Landing Page, however along the tertiary colour, it was removed from product's final version. In order to properly match the both typefaces I used Google Fonts and the other typeface, for paragraphs and small texts, I chose Roboto's typeface.

Here are the typefaces with primary and secondary colours over different backgrounds.

‍

The buttons were divided by size and besides not every button had been used on the prototype they were created for both plataforms, desktop and mobile. I also included social media buttons, fintech and operatrional system buttons, toggle switch and rating buttons.

‍

Icons were chosen mainly through Material Design but there were some I created from svg vectors, like social media and some branding. For benefits section on Landing Page, vector illustrations were used for each benefit offered by the product.

‍

Forms have the purpose to gather and repass valuable information from one part to another, on this case, both primary users of the product: doctors and patients. It is through the forms patients have a conversation with the doctor, who analyse the data offered by those patients which are converted into charts and sheets, where the doctors can evaluate and organize their schedule in a easy way.

Sheets

- Types of appointment - I used a Pie chart to separate two types of appointments - private or healthcare ensurance.

- Types of Patient - Also a pie chart to determine the number of new patients and those who return.

- Number of appointments - Evaluate the quantity of montlhy appointments on the app (only)

- Gender - identify if the patient is male, female or other.

‍

‍

High Fidelity Prototype

After getting the wireframe done, I then start building the app, following the same design structure of the wireframe using the Style Guide (which included Poppins Typeface and the purple tertiary colour). However, after some guidance from Beto Lima, currently working as Product Designer at Luiza Labs, and Leandro Rezende, my mentor on UX Unicórnio course, about the visual elements on product's interface, I started a review all over the product and got this final result. Lots of things have been changed on visuals and also on user flow, where I added:

- Permission messages delivered on each step, as follows the good practice on User Centered Design;

- Emtpy States screens for new users;

- System Message on the first screen, informing every important message to user;

- Floating Menu for user's info.

- Footer on every section, making it easier to navigate through screens;

- and a main button for schedule an appointment, making it easy to access the user's journey defining the Golden Path (which I'm gonna show next).

To access the High Fidelity Prototype of MedicOn App click on the link - Here

‍

Golden Path

The Golden Path is the path user does since the very beginning of the usability, when he starts using the app until he fully completes the task he wanted to. This is the way that requires the most attention, it's not that the others don't have to have the same quality but the main function, the golden path, has to be, indeed, made of gold! THis way the Golden Path is represented on the image below. Certainly the doctors are also users, but the end-user of the product is the patient, who needs an alternative for his/her medical appointments.

‍

Usability Test for Golden Path definition

Learnings

From the beginning of the journey, from research to the development of the project, I learned that in the face of a scenario like medicine, as well as any project that involves people, no solution is definitive, because change happens all the time. However, despite knowing that the pandemic will one day cease to exist, the idea of ​​the project is to be part of a new era of care that can facilitate, for both patients and doctors, the treatment of diseases without needing to go to the office. And with that came some considerations:

1 - A project is never finished;

2 - It is not possible to develop an application of such a complex nature alone, teamwork would have made the development much easier;

3 - The researches that guided me to product development, certainly if they were repeated nowadays, with more knowledge and after months of pandemic, would lead me to another project conclusion;

4 - As the first UX case developed from scratch, I am fully aware that I need to further mature my methodology and the development of solutions, but I also believe that, due to all the knowledge passed by Leandro Rezende and the exchange of experiences with everyone at Slack, especially the mentoring of Rafael Frota, during the UX Unicorn course, is a matter of practice and dedication until this happens.

When I wrote this article I was still studying the UX Unicorn Program, and I still lacked some Research and Strategy modules to complete but I left this first case that was placed as a challenge within the course, as my MVP (Minimum Viable Product) which I intended to revisit in near future with a more mature look after having completed all the course modules.

Well, all the updates in this case were made after the conclusion of the UX Unicorn Program, in order to improve all areas of the case making it more complete.

Conclusions

After Leandro and Beto's considerations about the first version of the project, I learnt, by redoing it that the project can always be improved, whether in the visuals or functionalities. On this case, the product I developed in UX Unicórnio Program, should be improved in both areas: the interface and the usability itself. I also concluded that, despite knowing that UX Design isn't about beautiful screen products, a good and pleasant interface is also part of a good experience when it comes to the usage of the product, therefore, redoing the app with these principles of good aesthetics in mind was important to get a better outcome.