DESIGNING A PHARMACY MANAGEMENT APP
DESIGNING AN INTEGRATED POINT OF SALE AND STOCK MANAGEMENT SOFTWARE SOLUTION
The German pharmaceutical giant, Merck
User & Stakeholder Interviewing, Wireframing, Detailing Information Architecture, Specifying & Ranking User Requirements, Liasing with Developers
Darmstadt (Germany) | Nairobi (Kenya)
Patients in developing countries like Kenya face many challenges obtaining quality and affordable healthcare. To address this, Merck launched the CURAFA™ initiative.
The CURAFA™ initiative consists of:
• small points-of-care healthcare facilities offering medicines and basic clinical services
• a set of digital health initiatives aimed at increased patient engagement
A CURAFA™ point-of-care facility
CURAFA™ points-of-care facilities are owned or co-owned and operated by entrepreneurs, usually qualified pharmacists, nurses, or clinicians.
Each facility has:
A pharmacy/dispensary where customers can buy drugs/medication from a pharmacist
A small screening room for basic primary healthcare services done by a clinician/nurse
For these two activities, two types of software are required:
Point-of-sales software (POS)
Patient management software (Electronic Medical Records, or EMR)
When I started on the project, entrepreneurs used two separate, fragmented Android Apps to conduct this. Since each facility was equipped with an Android tablet, the goal was thus to design an integrated app offering (optimized for tablet usage) where entrepreneurs have end-to-end functionalities to conduct and record their work in their small healthcare facilities.
How can I design an integrated digital pharmacy operations solution for small pharmacies/clinics to address all needs of healthcare workers and facility owners?
I decided to start my UX Research with studying the apps already in use by the entrepreneurs, and to interview them about the (lacking) functionalities (I also coupled this with further stakeholder interviews such as internal Merck management).
This allowed me to map user journeys, construct detailed information architecture of the design concept, and design wireframes in Adobe XD to visually show the proposed design concept.
Lastly, I detailed the final information architecture and learnings in user requirement specification documentation which was ranked and sent to the app developers.
The first step was to research the current apps used by the entrepreneurs in the points-of-care facilities, as well as other apps in available in the market. I focused specifically on apps and software available in the East African Market which offered patient management functionalities or point-of-sale and stock management solutions.
The creation of competitive profiles (target market, core functionalities, general user feedback, etc.) assisted me to map and compare offerings.
Out of all the solutions, the status quo offering seemed to be Maisha Meds, a free app aimed at clinics and pharmacies in East Africa, which lets facility owners manage sales and inventory. Some screenshots of the app can be seen below.
Screenshots of Maisha Meds
USER & STAKEHOLDER INTERVIEWS
After I benchmarked and analyzed other offerings in the market, I interviewed CURAFA™ entrepreneurs (pharmacists and clinicians) to establish:
what tasks and activities they do most frequently every day, and which tools do they use to do so
frustrations they have with the current apps they were using
functionalities and features they would like to see included in their 'ideal” pharmacy operations software
Additionally, I also interviewed other internal stakeholders within Merck which also could benefit from the newly designed app (for example a financial controller seeing aggregated sales data from the app).
FINDINGS & LEARNINGS FROM INTERVIEWS
Entrepreneurs detailed all their daily activities and tasks, and it became apparent that tasks and accompanying features can be broadly categorized into 5 categories (plus some general requirements), which eventually made up the 5 modules of the proposed app.
Entrepreneurs sell over-the-counter and prescription drugs every day
Suppliers payment terms, outstanding payments, etc. must be recorded
Incoming and sold inventory has to be documented automatically
Ability to view aggregated sales data, profit & loss statements, etc.
Screened patients' data and pre-scriptions must be recorded
General features like multi-level account management was desired
USER JOURNEY MAPPING
For each of the 5 main modules I identified through for the competitor analysis and user/stakeholders, I constructed user journey maps for entrepreneurs.
Entrepreneurs noted that multi-level access control is an important requirement for them – e.g. restricting cashiers from not accessing supplier or inventory management data. To incorporate this in my user journey mapping, I took a top-down approach: mapping the user journey for entrepreneurs (full access), and then limiting features for lower-privilege users.
An example of a user journey map I constructed is shown here below - the journey for an entrepreneur (pharmacist) when selling medication to a customer.
A typical user journey for a pharmacist wishing to sell medication
Based on the competitor analysis, initial content audits, user journey mapping, and user interviews, I defined the information architecture (mobile app map) for the proposed pharmacy operations app, which I coined the CURAFA™ Pharmacy Operations Solution (CPOS).
An extract of the information architecture (point-of-sale module) can be seen below.
An extract of the defined information architecture
With the information architecture and preliminary workflow defined – especially with the help of the user journey mapping – I created low-fidelity paper wireframes to quickly visually structure user workflows, which served as a basis for clickable wireflows.
A few paper mock-ups of the wireframes
For a higher-fidelity prototype, I created clickable wireflows in Adobe XD for each CPOS module, and iterated the designs after consultation with CURAFA™ entrepreneurs and internal Merck management.
An extract (point-of-sale module) of the wireflows can be seen below.
A few wireframes from the point-of-sale module
USER REQUIREMENT SPECIFICATIONS
After constructing and testing the wireflows, and reviewing the information architecture, I proceeded to define detailed User Requirement Specification (URS) documentation based on business requirements and learnings from the prototypes.
The aim of defining such URS documentation was threefold:
Consult with internal Merck management on ranking of features to be included in the first version of CPOS (considering development time & cost trade-offs)
SEND TO DEVELOPERS
Have documentation in place to send to app developers for cost and develop-ment timeline estimations
The URS documentation detailed the following:
An overview and introduction of CPOS
The CPOS value proposition – i.e. how it aims to assist CURAFA™ entrepreneurs and other small point-of-care facility owners
Specification of user types and typical user profiles
For each of the 5 modules: the main overview of the module, features of the modules, and detailed attributes and fields to be collected within each feature
I completed two iterations of the URS documentation:
a first initial draft detailing my first findings
a second and final draft where all features and functions to be included were ranked based on importance, urgency, and cost and implementation timeline estimations
HANDOVER, CONCLUSION & LEARNINGS
With the completed URS documentation, my final responsibility was to hand over the documentation to Android developers and obtain cost and development timeline estimations from them, which I did.
During this same time, the greater CURAFA™ project was acquired by a local Kenyan healthcare provided, Access Afya – a social business that operates primary healthcare clinics, retail pharmacies, and mobile health and data analytics solutions in developing countries.
When the CURAFA™ project was handed over, I also communicated my learnings and deliverables to the Access Afya team in detail, in order to help us both understand where my learnings could possibly fit within their healthcare software ecosystem.
This project was very insightful and rewarding in the sense that I since I was the only person in the CURAFA™ team with Design Thinking and UX Research experience, I had the opportunity to take the lead in applying these methods, as well as to get other members in the greater Merck team involved on how such methods work.
For this, I also conducted workshops with Merck management on the essence of human-centered design and how a user-centric approach can be adopted and cultivated. I’m grateful that my managers were prepared to give me such scope and freedom in seeing a project through like this on my own, despite me being the youngest on the team.
While the project naturally delivered many insights and learnings, I highlight 3 below.
#1 Design for the context
Due to the size (small) and location (rural) of the facilities, the pharmacists and clinicians at the clinics do not serve thousands of patients a day as a larger hospital would serve, for example. Thus, while it is tempting to include many features and functionalities you would find in healthcare information systems for larger facilities, it is important to keep it simple and place the user first in the design process.
#2 Interesting information architecture considerations
Again, due to the target customer of the CURAFA™ entrepreneurs (low-income patients) and unique cultural behavior in Kenya, patients often purchase medication per tablet and not per box, as would be standard in developed countries. Thus, designing inventory management and point-of-sale software modules has to include such considerations, which complicates designing sound information architecture (but also makes it more interesting!)
#3 "Seeing is believing"
One thing I have learned, especially when working with colleagues or other people not familiar with design methods, is that once you present mock-ups and wireframes and gather feedback on this, users/testers instinctively provide more concrete feedback than just hypothetical or descriptive scenarios. Visual and tangible resources for users also significantly simplify usability testing.