Designing Pharmacie: Allowing You Into My Thought Process
I conducted user interviews to understand how, Pharmacie, a feature in a medical application that enables patients to be able to request for drug prescription and renew prescription. While there are other extreme users, my research and solution focused on these two primary users:
- One who uses the app to request prescription for himself/herself
- One who uses the app to request prescription for someone else.
As a result, I created these two personas to represent my users.
Olanrewaju Akin, a Software Developer, and Mrs. Obianuju Elizabeth, a Project Manager and a mother of two, use the e-Hospital Mobile Application for their medical services. However, whenever they want to request or buy their prescriptions, they still have to walk manually to pharmacy stores to purchase them. Olanrewaju Akin and Obianuju Elizabeth do not, at all times, have the liberty to walk into pharmacy stores because of the nature of their jobs. Other times, Olanrewaju’s prescription are not always available at stores, thus the need for him to always get it ahead.
To solve this problem for Olanrewaju Akin and Obianuju Elizabeth, e-Hospital introduces a feature, Pharmacie, to the medical application. Pharmacie is a feature of the application that allows users to request and renew prescription, just like how they would in a physical store, but with a better experience that will help them track their dosage use, and in the case of Olanrewaju Akin, he can schedule auto-renewal for his prescription easily without having to worry from which Pharmacy he will get it from.
As the Product Designer that designed this solution, my Thought Process is focused on the followings:
1. Requesting for new prescription
2. Renewing Prescription
3. Payment Method
4. Fast delivery of prescription
Requesting for a new prescription
When requesting for a prescription, in the case of both users, Olanrewaju Akin and Obianuju Elizabeth, either of these two cases occurs:
Case one: they have a prescription note handed to them by a doctor and make request for the prescription using the mobile application. In the UX design for Pharmacie, this is considered as an existing illness because there’s a known prescription already.
Case two: they request prescription as a result of the symptoms of a new illness. In this case, they get to chat with a pharmacist, describe their symptoms, and the pharmacist will prescribe drugs for them.
In the case two, why I considered the patient describing their symptoms to a Pharmacist instead of a Doctor is the fact that Pharmacist are also licensed in Nigeria to manage minor health issues like Malaria, Typhoid, Hypertension, etc. And of course, while having the conversation, and the description of the symptoms seems complex, the Pharmacist can then refer the patient to any available e-Hospital Doctor for proper diagnosis.
Thus, considering both cases one and two, for Akin and Elizabeth to request for prescription, either for Existing Illness or New Illness, the userflow below shows how both users are expected to navigate their ways in requesting prescription:
However, various questions were raised while requesting prescription for Existing Illness. These questions focused on preventing the users from self-diagnosis and self-medicating. I registered during my research that other users beyond Akin and Elizabeth (referred to as extreme users) may self-diagnose, for example, Eczema for Scabies because of similar symptoms — rash and intense itching — both infections have.
Thus, these extreme users may want to get drugs to treat Eczema without consulting a medical professional. To prevent this, the userflow for the Existing Illness was modified.
Also, in the modification of the userflow of the Existing Illness, there’s need to consider three possible scenarios that may occur when Akin and Elizabeth input their prescription and corresponding symptoms on the Pharmacie prescription form page in other to be able to buy the prescription.
And these scenarios also form the basis of the modification (preventing self-diagnosis and self-medication) for the Existing Illness userflow, and are thus described below:
Scenario one: This is when the prescription can still be sold to patient whether the drug is prescribed by a registered hospital, doctor, or pharmacist. This scenario considers the instance where the symptoms don’t match the prescription. When this happens, the patients are provided with two alternatives:
- To speak with a pharmacist before making purchase
- To proceed to make purchase
This alternatives are provided with the inference drawn from researches made on the patients.
Scenario Two: This is when prescription/drugs are the ones found in Poison book, and can only be sold to a patient with the consent and signature of a registered doctor and hospital. When this happens, the patients are requested to upload the prescription note from the hospital, and input the name of the hospital and doctor. This is needed for the verification of that prescription. Also, the prescription verification process is manual, and a pharmacist attending to that prescription in real time does the verification.
The verification process provides the patients with either of the two responses:
- If the verification is successful, the patient can proceed to purchase the prescription.
- If the verification is not successful, the patient is suggested to book an appointment with a doctor.
The second alternative is important and thus considered because of the severity of the usage of such drugs.
Scenario Three: This is when the prescription/drugs match the symptoms for its usage. This is a similar case with scenario one, but here, the patient are not provided with the alternatives to speak with a pharmacist.
This scenario here, as with scenario one, happens with drugs referred to as “Over The Counter Drugs”.
The userflow detailing the modification to the first and detailing how Akin and Elizabeth are expected to navigate their ways for the three scenarios is shown below
Renewing a prescription
While designing the renew prescription section, my thought process of designing a better experience is more prominent on the information architecture of the renewal page which is shown in the low fidelity design below, and the features on the renew prescription page which will be shown in the high fidelity prototype.
The image above shows the first and second draft. The first draft only focused on allowing the users to renew their prescription. Thus the need for the Next Renewal Date text and a Renew Prescription Button.
While understanding the pain points of the users, Olanrewaju Akin and Obianuju Elizabeth sometimes miss the time for using their prescription because of how busy their schedules get. Thus, the need to not only help them in renewing their prescription, but to also help them manage their dosage and let them know when they need to take the next dose of their prescription. And this is illustrated in the image below:
In order to further help the users to have a better experience using the application to renew their prescription, the following things are later considered:
1. The information on the page should be relevant ones
2. (If they want to) They should be able to setup auto renewal.
3. They should be able to set notification for the next time to use their dose.
While considering making the information the users see on the page a relevant one, there is the need to remove the date and time of each dosage as it feeds the users with too much of information. This is now replaced with the Next Dosage Period. The notification is then activated for the next dosage period. Thus, Olanrewaju Akin can be prompt about the time to use his dosage.
In other to setup auto renewal, the application must know when the dosage of the prescription of the patient is getting low, and automate the renewal. This can only be achieved through the dosage calculation. The dosage calculator relies on frequencies:
- The predefined dosage which is based on age and weight of the patient, and which comes from the manufacturer.
- The custom dosage which is prescribed by a pharmacist.
Beyond that, the custom dosage frequency is what helps Obianuju Elizabeth to be able to set the dosage periods for her children when she buys them prescription using the application.
With these frequencies, the application can help the patients track when next to have their next dosage and when they are running low on their prescription, so they can renew manually or automatically.
Having established that when renewing their prescription, patients like Olanrewaju Akin will prefer to automate their renewal so they can get their prescription before the current one ends. While Elizabeth, as a mother of two, may have bought the prescription for her children. The userflow below illustrates how they go about it.
Fast Delivery of Prescriptions
While gathering the UX Information from the customers, the need for fast delivery of prescriptions came up. The solution provided to this problem is by making the Pharmacie storefront shows the prescription a patient requests for only from pharmacy stores which are within 25 kilometers from the patient.
What this means is partnership with pharmacy so they can setup their stores on the platform. In other for these setup to be smooth, the mode of uploading their product is via a Public Repository. This Public Repository means when a pharmacy uploads a particular drug, say paracetamol, the information about that drug is saved in Public Repository, such that when another pharmacy wants to upload that drug on their store, the pharmacy only have to search for it and put in the stock and price details.
This solution will enhance pharmacies partnership, and thus enhance fast delivery of prescriptions.
Payment Method
There are two mode of payments:
1. Pay with e-wallet
2. Pay with card
The pay with e-wallet is made an alternative to paying with card, because it is a medical app, and users can fund their wallet anytime in other to have premium access to basic medical services.
Some high fidelity designs
Important: Pharmacie and e-Hospital are names I adopted to put the solution I designed for the users in context.
