MedicOn — Connecting Doctors and Patients remotely through telemedicine

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.


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 recommendation from WHO 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 Resolution 2.227/18 from Federal Council of Medicine in Brazil , recently issued, telemedicine has the potential to become more present in people’s daily lives, which can change the relationship between doctors and patients in a not so distant future.

Project’s goal

The objective of the business is to make communication between doctors and patients safely and comfortable for both sides, through a 100% online platform, without any loss in quality of the consultation and diagnosis, for any case in which there is no need for a face-to-face examination, and that will guarantee the doctor will receive his wage 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 — Certainties, Suppositions & Doubts

When it was 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 each ones profile in order to seek solving their pain points. For that, I started creating a matrix of certainties, assumptions/suppositions and doubts (CSD) for both users.

User profile (Proto Personas)

After defining the assumptions about users, in order to facilitate the visualization and identification of each side of this story, I created two proto personas, one for the patient and another one for the doctor, in order to understand their pain points, needs and painkillers as well.

Roberta is a 30 year-odl architect who does not feel comfortable going to offices for fear of contagion.
Júlia is a 42 year-old nutritionist who had a reduction in the number of consultations due to pandemics.

Pixar Storytelling

User 1 — Patient

Once upon a time there was Roberta, a young 30-year-old architect, single, currently living in SP, connected, digitally engaged, used to make payments and purchases over the internet. She has a cat called Bruce.
Regular exercise praticant with an active life, during the pandemic, like many others, she had to leave her workplace and the regular activities of her daily life behind. Then she started working from home and communicating with people more often over the internet and due to the fear of contagion, she avoids exposure in public environments as much as possible.
One day Roberta needed to schedule an appointment to do her medical 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 doesn’t feel safe going 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 she was used to consulting with. And she is also covered by her health care plan.
Roberta then made the appointment and was answered by a video call with her trusted doctor and started her treatment without facing full offices and avoiding the risks that once frightened her.

User 2 — Physician

Once upon a time, there was Júlia, a 42-year-old nutritionist, married, mother of a 4-year-old boy, living in São Paulo, connected to her Smartphone, used to making purchases and payments via the internet.
Before the pandemic, she was attending at an office in São Paulo downtown, but like most doctors, after the Covid-19 pandemics, 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 of them have avoided going to consultations for fear of being contaminated, if not in the office itself, during the journey, after all, not every person has their own vehicle and many people go by bus or subway to the center. Having 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 and keep doing her job without losing quality, through video calls.
As her patients were becoming aware of the platform, they were rescheduling their appointments and she was able to take the opportunity to stay close to her son.


With the personas and all the assumptions about their problems well defined, it’s time to check whether those assumptions are valid hypotheses or not. For this It was used two types of research, quantitative, to understand WHAT is a REAL problem and a qualitative one, to understand WHY it’s going wrong and becoming a problem.

Quantitative research

In order to validate (or invalidate) the aforementioned assumptions of each persona, I decided to conduct a quantitative survey, which was sent by e-mail and shared in groups where there were people who fit the profiles of users described on both sides, patients and doctors.
The main hypothesis to be tested were the reasons for the decreasing numbers of frequency in presential medical consultations and to check over possible solutions for this scenario.
However, as they were two personas, the form was created to be conditional, to identify the pain points 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 line for doctors and blue line for patients. In the end, it converged on the research’s final considerations.

Flowchart of the Quantitative Research Form
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 on my spine that needed attention and urgent clinical treatment and I took the opportunity to talk to them about their pain points 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 for their colleagues from other areas of medicine.


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

Validations from the result of the quantitative research

User Journey Map

Based on the information above, which was validated by the surveys and interviews with possible end-users, I decided to set up each user’s journey within the scenario where the use of remote medicine was involved, then I would define alternative solutions for the problem.

Patient Journey Map

User Journey — Patient

Physician Journey Map

User Journey — Doctor

Solution Alternatives

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

Thinking of all the possibilities about 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 with their doctors privately and securely, with their mobile version to perform remote consultations through 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 extremely high to carry out the project.

The second idea was something simpler, making the manual insertion of data and test results in an application to share with the doctor, creating a data base accessed by the doctor and the remote contact would be through another pre-existing applications. However, despite solving part of the problem, the financial question for the doctor still needed to be included, after all, how the doctor is going to get paid for his services?

The third idea, besides having valid points, was discarded because it wasn’t focused on the main problem. Many patients said they were afraid of a presential 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 more flexible and schedules and time available for a face-to-face consultations, however, there are those cases that need a certain urgency and telemedicine would solve this problem but isn’t mentioned in here.

I let two of the ideas that present the best solutions for remote medicine’s problem for the Gran Finale. Both are very similar but one of them suggests 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 the 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 a video call. I’ll 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, checking what difficulties users would encounter and proposing necessary changes in those 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 after for prototyping.

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

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 screens and buttons. I decided to improve and include icons and image representation to facilitate usability, which helped a lot, but some questions were raised by users:

  • a doctor can also be a patient, how to include this in the application? Will two accounts be required or there will be the possibility for transition between profiles?
  • Will the delay be allowed at 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 an underage?

As the main goal is to facilitate communication between patient and doctor and to use telemedicine as an alternative to presential consultation, the application proved to be very effective as the Minimum Viable Product (MVP). However, due to the complexity of the project, the questions above are pertinent and need to be better elaborated, which will 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 a way as easy as a face-to-face consultation. The flow of the patient is represented by the blue line and the doctor’s by the green one.

High Fidelity Prototype V0

After testing the usability of the product, it was time to apply the Style Guides and refine the application, making it ready to be finished by the developers.
The image below refers to the first version of the prototype, which I refined after the Leandro Rezende and Beto Lima mentorship about it.

You can check the first version of the app by clicking here.

Interface Update — UI Updates

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

Naming and Branding

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.


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

Tags and Cards

Photography and Illustration

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

The High Fidelity Prototype is right below.
P.S.: In order to access the prototype, you ought to have a Figma account.
If the prototype isn’t showing up on the screen, please access it by clicking

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‍


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.


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.

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.

About me

My name is Mario Koller UX/UI Designer and I’m currently working at Eldorado Research Institute and you can reach me by pointing the camera of your cellphone to the QR Code right below, or if you prefer, just by clicking on this link:

I’ll be glad to get in touch. Shall we?




UX-UI & Product Designer

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

User-centered design principles, methods & approaches that drive better results

User-centered design principles

A lesson in user retention — Amazon Audible

Primary, secondary and tertiary actions are clear and thoughtful.

Selling K12

How to design a product with a great experience in mind

Level Design by Subdivision of Space

Web Design Basics

What You Need to Know When Building Kiosk Software

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Mario Koller

Mario Koller

UX-UI & Product Designer

More from Medium

summary of the first 3 chapters of Refactoring UI book-Adam Wathan and Steve Schoger

A very peri big influence

Video Game Design Changed How I Design for Data

The Periodic Table Re-Imagined