Making software for clinical environments is really challenging.
Workflows at hospitals and clinics are often chaotic. In a single visit, patients usually visit many rooms in the hospital, including but not limited to the outpatient registration desk, nurse’s room, doctor’s room, and then, the pharmacy. There are queues at each step. Nurses and doctors are under pressure and need to juggle many tasks at once.
Simple, an Android app used by healthcare workers at public health facilities in India to manage patients with hypertension, aims to help simplify this process. But to make the software that we were working on a success, we needed to understand our users and the context in which they operate.
Of course, jumping into the field and witnessing real patients being treated is a great method to understand our users. And we do go into the field frequently to observe patient care. However, we needed to find a way to give everyone on our team a deeper understanding of a healthcare worker’s job, first-hand. It had to be a method that could take its time without disrupting the flow of nurses and healthcare workers actually on the job.
To that end, during the nascent stages of Simple, we decided to simulate a hypertension clinic in Obvious' Bengaluru office. The entire team enacted healthcare workers treating a queue of “patients”, who were also role-played. In a matter of a few hours, everyone on the team learned how hard it was to juggle different tasks in a busy clinic, experienced how our software fit into a healthcare worker’s job, and understood how the Simple app was just a small part of their workload.
Why create a simulation?
It’s immensely valuable to play the role of a nurse or doctor yourself — something that isn’t possible in a real clinic without causing major disruptions. Through a realistic simulation of a clinic in our office, everyone on the team experienced being in the shoes of a healthcare worker for a day. Engineers, designers, and project managers got to play each role in the simulated clinic to form a better understanding of how our software would be used in a real clinical context.
What did we do to create a successful simulation clinic?
1. Observed real users in the field
First, we observed clinical care at about 10 facilities in Punjab, India. Typical patient flows were mapped out. Nurses, doctors, pharmacists, and other healthcare workers were observed and interviewed, with as minimum interference as possible. We took notes and clicked photos to better understand their environment. These learnings were then used to recreate a typical workflow in our simulation clinic.
2. Identified the goals for role-playing
The key question we asked ourselves was: What did we want to learn and observe through the role-playing experience? Accordingly, our goals were kept brief and focused. They were A) to learn what it would be like to use our app as a nurse and as a doctor, and B) to understand the challenges in typical workflows at a public health facility.
3. Made a plan for the clinic experience
Created roles and scenarios
We then identified the roles and the scenarios to be included. A list was created of the tasks that these roles would perform. We created the primary roles of a nurse, a doctor, and a pharmacist, where a pharmacist also ran the outpatient registration counter. Two secondary roles were also created to round out the scene — that of a patient’s family member and a doctor’s assistant.
We ensured that the description of these roles was made clear, with just enough details to serve as guidance for the team. For instance, we described the nurse’s role with the tasks that they would perform when attending to hypertension patients, and how they would use the various tools on her table.
Prepared relevant artifacts
We re-created nurses’ and pharmacists’ paper registers using our photos of the real registers from the clinics. We created prescription slips, bought a BP monitor, printed patient ID cards, and acquired medications. We also printed the hypertension treatment protocol poster that contained crucial information for treating patients and put it on our simulation clinic’s wall.
Attending to such details made the environment feel realistic and believable. It gave the participant an immersive experience of what it would be like to juggle all of the tools and information while also fulfilling responsibilities required of a real nurse.
4. Set up the simulation clinic
We took over several meeting rooms in our office and set up the nurse’s room, doctor’s room, and outpatient registration / pharmacy. The simulation clinic was large enough to replicate patient flows and patient queues, but small enough so that the team was not too spread out and could observe each others’ experiences.
5. Facilitated role-play
For a seamless process, one person played the role of a facilitator. This person's main job was to set the context and create an environment where teammates could engage in a serious play-acting experience, learn about the users, and find their own insights.
6. Gathered the team
The facilitator briefed the team about the plan for role-playing, discussed the goals, indicated the duration of each part of the plan, and also informed them of the format — two rounds of role-play followed by a debriefing session.
Described the roles
The facilitator described the roles to the team, the scenarios that were going to be enacted, and had everyone pick roles that they wanted to play. Written descriptions were also printed out for easy reference for the team.
Timeboxed the session
It really helped to set a relatively short timebox for each session. We wanted to create a sense of urgency for treating patients, so we limited the session to 30 minutes, roughly equivalent to the time in which a doctor typically manages 5–6 patients (Amazingly, primary care doctors in India can see over 100 patients each day! Who would've thought?!).
7. Began the role-playing sessions
All team members were encouraged to stay in the character of their roles by the facilitator, to ensure realistic scenarios. The facilitator also briefly stepped in if needed as one of the actors to help tune up the realism of the scenarios. After all, if a facilitator enacts the roles seriously and as realistically as possible, the team members would definitely follow suit, don't you think?
Mimicking observed disruptions to workflow was also critical for actual validity of the scenario. For instance, “patients” interrupting the “nurse” by asking her for some help or counseling is a typical situation that needed be included. This is so because such interruptions generally require the “nurse” to switch context, respond to the “patient” in the moment, and then get back to the task that they were attending to.
We usually consider and suggest running at least two rounds of role-play. This ensures that the team members have the opportunity to play different roles, and allows enough time to make their observations. A brief quiet time after each session for everyone to individually write down their observations, is also a good next step.
Debriefing is a critical part of the process. Once the role-playing session was completed, it was time for debriefing — to share what lessons were learnt and identify the important action items.
Created time for individual reflection
We took 15 minutes where each person wrote out their learnings from the experience individually. We had a list of five questions that they could respond to while reflecting on the same as well. We deliberately stayed away from jumping right into a group discussion, because sometimes loud voices drown out others in a group context, but quietly writing down experiences helps individuals foster a more equitable and nuanced discussion afterwards.
Facilitated a rich and equitable discussion
We went around the table one-at-a-time and each person shared a key point they had learned, and repeated this several times, till we knew there were no stones left to be unturned.
Encouraged people to discuss how they felt during the experience
We tried to answer the following questions: what was frustrating, what was challenging, what was enjoyable, and what was motivating? This helped build empathy with our users, and also led to meaningful insights beyond usability challenges.
As a team, we identified the top 3–5 takeaways. These were the most important learnings or action items, possibly as simple as, ‘We learned that it’s really frustrating to be a patient and to get treatment at these clinics.’
Tip: One action item we came up with is to create a user manual that would guide nurses on how to correctly use the app. This is because we observed that it was difficult to get started if you weren’t really familiar with the software.
What did we learn?
In just two hours, our entire team simulated a clinic from start to finish. We learned a few concrete things, and also gained an appreciation of the complex ballet that healthcare workers undertake everyday.
By role-playing and observing our colleagues, we understood that our app was just one of several tools that a nurse or a doctor used. It was very challenging to juggle them, while simultaneously attending to a queue of anxious patients. It also helped us comprehend that we couldn't assume that our users would give the software their full attention — one of the main reasons why the app needed to be easy to use and cause as little duplication of effort as possible.
We observed how patient data moved between the nurse, the doctor and the pharmacist through the combination of prescription slips, patient ID cards, and the app. Points of potential breakdown were identified. This activity also gave us an insight into the challenges of navigating a public health clinic as a patient, and how that could potentially lead to important patient data not being recorded correctly.
Walking a mile in the user's shoes
The simulated clinic afforded the safety to experience the difficult job of a healthcare worker. The experience gave us deepened empathy for clinicians and their patients. We all walked away with an impactful and long-lasting understanding of the context where our software was being used — something that will help us make better product and engineering decisions going forward.
Now more than ever, we believe that any team that works on software will benefit from walking a mile in a user’s shoes, and a simulation is one of the many great ways to bring that experience right into your office.
- Thanks to everyone from Nilenso and Obvious who participated.
- Thanks to Tanushree Jindal for contributing to this article, to Akshay Verma for his help implementing the simulation clinic, and to Anand Rama Krishna for the photography.
- Special thanks to Dr Terry Cullen, Dr Greg Schmidt, and Erin Sykes for their help editing and to Daniel Burka for his help writing and editing.