The patient medication app
Pen(check), sketch pens(check), sticky notes(check), flip chart(sh*t!), I panicked and rushed to the stationary shop in the hostel. “I have only A4 sheets”, the guy at the shop said. A sudden rush of intense fear crept through my spine and my heart skipped a beat. Although I didn’t need them necessarily but being a guy who likes to put all the thoughts on paper, having all the necessary arrangements gives a sense of comfort to me. I rushed to the design studio(department of design at IIT Delhi) and got myself a few sheets. The panic wasn’t out of ‘nowhere’, I had received a task from our placement coordinator which I had to finish in exact 24 hours, to be eligible for the on-campus interview by Optum’s panel.
Seeing the task with various intricacies, I thought to myself, will I be able to finish everything on time. More than a test of my design skills it was a test of my time management skills. The challenge was formidable, I took a few deep breaths and like ‘Barney Stinson’ embraced the “challenge accepted!” attitude.
The scenario
The scenario presented to me was, “A hospital nurse has just visited a patient and needs to give him medication. The patient has not taken the medication before but needs to take the medication 4 more times in the next 48 hours. The patient is currently taking 3 other medications. One medication is for a chronic condition, and the other two medications were first given when the patient arrived at the facility.”
The problem statement
“Keeping in mind the above scenario, we want you to design a digital way for inpatient nursing staff to track the medication given to a patient.”
After reading the details given with the task. I noticed a few things
- The scenario doesn’t talk about the location or nationality of the user. Since every country has different laws on patient medical record maintenance and way to chart details may change a bit from culture(diary, folders, clipboards, tablets, mobile phones etc), it becomes essential to define the location to address regulation and organisational culture specific to that location.
- The solution will have multiple users(Patient, nurse, probably doctors and other medical staff) hence one will have to identify the primary user and primary use cases.
- The solution will be a medium to exchange and consume information, hence proper communication becomes crucial to avoid misinterpretations.
The next step seemed clearer. The problem had layers and it was absolutely necessary to define the problem in such a way that it gives a clear picture of the whole system. For this I decided to employ the ‘Boundary examination method’.
The boundary examination
The Understanding of the problem, and its relevance, often grows with the understanding of the scenario. Since someone else had defined the problem statement, it was not very unusual for it to be influenced by their understanding as well as by my own. By defining the boundary it would have been easier for me to blur the details which do not have a considerable impact on the problem.
The steps included were:
- Writing down the given problem statement.
- Highlighting the keywords.
- Examination of each keyword to identify the connotations and direct meanings by replacing them with their synonyms and observing the difference in the meaning.
- After the exploration with words, redefining the problem with appropriate diction.
- The goal is not to change our understanding of the situation but to find where the boundary lies and how the choice of word affecting our assumption of the scenario.
The boundary examination refined the problem statement to:
“Design a digital way for medical staff to record the treatment administered on the inpatient”
The boundary examination demolished three preconceived notions
- The solution is only for nurses.
- Medicines are the only prescribed treatment.
- All the medications handed out will be administered.
As we know
- Doctors will also monitor the situation.
- Food items and exercises etc. are also prescribed alongside medicine.
- Some medications are handed out only to take when a certain situation triggers.
As I was clear about the problem and its scope, I moved on to do a deeper analysis of the problem to find out its root causes. For this, I used the 5 whys technique.
5 whys:
Five whys is an interrogative and iterative technique to find the root causes of a problem.
1st why
Why do we need to design a digital way for medical staff to record the treatment administered on the inpatient?
Answer: Because paperwork is clumsy and time-consuming.
2nd why
Why is paperwork clumsy and time-consuming?
Answer: Details are scattered over pages.
3rd why
Why details are scattered over pages?
Answer: Because a lot of documentation is involved.
4th why
Why a lot of documentation is involved?
Answer: Because there are multiple entries by the visiting doctor(s) and report attached to records.
5th why
Why there are multiple entries by visiting doctors?
Answer: Because the condition of patient fluctuates and accordingly the medication changes.
Since there is a lot of fluctuation in medication given to the patients and administration of some medications depends on the other medicines previously administered, it becomes very important to crunch the information in such a way that one can observe patient medicine routine and behavior.
Now I had a deeper understanding of the problem that the goal is not to record medicine intake but to correct patient behavior(medicine) and avoid medical blunders.
To give a visual context to the problem I used the AEIOU framework.
AEIOU:
AEIOU is a heuristic framework which provides a technique used to document contextual inquiries from field(Here, from memory) observations.
After identifying the activities, environment, interactions, objects and users(Stakeholders). I moved forward with an intention to explore who are our stakeholders. So I found there are mainly 4 stakeholders.
- Patient
- Doctor
- Nurse
- Assisting family member
- Nursing assistants
With a strong resolve to understand the stakeholders in the problem I decided to do stakeholders study. But it was 6 in the morning and I was way too drowsy to take up such a huge task. I decide to sleep for a while(otherwise I would have ended up testing my own solution :P ).
I snoozed until 9:30 am and woke up late for breakfast. I put on my slippers and ran to the mess but the food was already over(What!). After asking around a little someone offered a banana to which I was grateful. While eating ‘my banana’ I realized that I was in a love hate relationship with this assignment. On one hand I was enjoying the work and the challenge, to complete it in time, so much that it kept me awake all night while on the other hand I had to skip my breakfast, I barely slept for two hours and my brain was lagging like ‘Call of Duty’ on ‘windows xp’.
I came back to my room promising myself that I will take a short nap in the afternoon but little did I know that I will get no time for such luxuries(;D) not until the task is over. With that promise in mind I started doing the stakeholders study.
Stakeholder Analysis:
- Players: These are the high-Influence, high-interest individuals who have the highest stakes and impact on the projects.
- Subjects: These are the low-Influence, high-interest stakeholders who are impacted by the solution but have little to no influence on solution.
- Context-setters: These high-Influence, low-interest stakeholders. They have huge influence on the solution but little interest in the outcome.
- Crowd: Finally, the low-power, low-interest stakeholders those individuals who do not have any direct influence or interest in the project.
Players = Nurses since the maintain all the records and do all the charting, Patients as their actions will have the most impact on the success of solution.
Subjects = Nursing assistants since they are affected by solution but their actions have little to no impact of the success of solution.
Context setter = Doctors, as they have a very high impact on success of solution but the success has lesser impact on them since they do not maintain the records.
Crowd = Family members, they are the outsiders in this situation but have huge influence on actions of the patient.
After setting my hierarchy straight, I decided to look into the life of our primary Stakeholders. I decided to chart up a day in the life of a nurse/patient.
DILO(Day In the Life Of):
Creating DILOs made sense as our solution will have multiple engagements with both the stakeholders throughout the day hence understanding the daily routine sheds light on latent needs of the user.
DILO gave some very useful insights into the life of the user. It made the picture clearer for two of my most important personas ‘Nurse’ and the ‘Patient’.
Now I had the overview of the condition and people in it I did role play to empathize with the two personas and tried to put myself into their shoes. And from this vantage point, I started listing pain points and opportunities.
Pain Points and opportunities:
It is a process to identify the pain points of the personas and the opportunities which can be turned into fruitful experiences. I listed down all the pain points and opportunities to form need statements.
Affinity Mapping:
Since I had a chunk of user needs I decided to cluster them into larger groups to identify the types and domains of the needs, to find which type of needs are more important(Based on problem statement and number of unique problems in the category) and rate them accordingly.
Rating of the needs:
Based on the above-stated criteria I rated the needs as follows
- Patient history
- Schedule
- Information
- Emotional issues
- Patient’s Vitals
- Emergency
- Help
- Medicine management
C-Box analysis:
Now with a clear hierarchy of needs, I started developing a lot of ideas. I numbered them and did a C-Box analysis by plotting them on a graph of creativity vs ease. To filter out Ideas which are creative enough and easy to implement, to proceed to the next phase of the task prototyping.
It was already 7:30 pm and my race was against time and in the back of my head somewhere the Saxons’ song ‘Ride like the wind’ was playing on full volume. I hurried without panicking as even though only a little time was left to finish the task, I knew I was on the right path.
Initial Prototyping:
The Initial Idea of the prototype is to have 2 separate modalities a patient watch based solution and nurse’s tablet-based solution. I though all the alerts on patient watch should be haptic and vibration-based since sound base alerts and notification doesn’t make much sense in a hospital environment. Both of these systems will be interdependent and one will update the other. I started working on wireframes but the clock was running against me, I decided to end it at the brink of success. I was at peace as I knew the design was thorough and relevant.
Ideation sketches:
Since I like to sketch my ideas out on paper I visualised the ideas on paper. Surprisingly, I was enjoying it, even though I lost the race! I did it properly, I had my freedom to create as per the insights I had and the ideas I generated. Since the solution was on three platforms I wanted to have continuity through out the design, across all platforms.
Wireframes:
The Ideas were clear, the layouts were done and I was all set for the wireframes.
Final screens:
After sketching and creating the wireframes, I had pretty good Idea how the final screens would look, even though I ended up making minor changes in the final screens.
It was a ‘1 day challenge’ for me to convert my ideas into visuals and then to UI, I tried my best to complete the challenge within the time frame. I wanted to focus and detail the mobile application a little bit more but since it was a time based challenge, I stoped my self from indulging any further in the project. This was it the 2 day effort and its outcome!