We simulated a hypertension clinic in our Bangalore office, and our team played the role of nurses, doctors, and patients. Everyone on the team learned how hard it is to juggle the different tasks in a busy clinic and we experienced how our software fits into a healthcare worker’s job.
Why create a simulation?
Our team is working on Simple, an Android app used by healthcare workers at public health facilities in India to manage patients with hypertension. To make our software a success, we must understand our users and the context in which they work.
Making software for clinical environments is really challenging. Workflows at hospitals and clinics are often chaotic. In a single visit, patients must visit many rooms in the hospital, like the outpatient registration desk, nurse’s room, doctor’s room, and the pharmacy. There are queues at each step. Nurses and doctors are under pressure and they’re asked to juggle many tasks at once. The Simple app is just one small part of their workload.
Of course, getting 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 wanted to find a way to give everyone on our team a deeper understanding of a healthcare worker’s job, firsthand.
It’s immensely valuable to play the role of a nurse or doctor yourself, which isn’t possible in a real clinic. So, we created a realistic simulation in our office to give everyone on our team the experience of being in the shoes of a busy healthcare worker treating a queue of “patients.” Engineers, designers, and project managers got to play each role in the clinic and now every one of us has a better understanding of how our software will be used in a real clinical context.
What did we do?
To create a successful simulation clinic:
1. Observe 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. We took notes and took photos to better understand their environment and workflows. These learnings were used to recreate a typical workflow in our simulation clinic.
2. Identify the goals for role-playing
What do you want to learn and observe through the role-playing experience? Keep the goals brief and focused. Our goals were A) to learn what it is 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. Make a plan for the clinic experience
Create roles and scenarios
Identify the roles and the scenarios to be included. Create a list of the tasks that these roles will perform. We created the primary roles of a nurse, a doctor, and a pharmacist. The pharmacist may also run the outpatient registration counter. We also created two secondary roles, a patient’s family member and a doctor’s assistant, to round out the scene.
Make the description of these roles clear and with just enough detail so that they serve as guidance to the team. For instance, we described the nurse’s role with the tasks that she performs when attending to hypertension patients and how she uses the various tools on her table.
Prepare relevant artifacts
We re-created nurses’ and pharmacists’ paper registers using our photos of the real registers used in clinics. We created prescription slips, bought a BP monitor, printed patient ID cards, and acquired medications. We printed the hypertension treatment protocol poster that contains crucial information for treating patients and put it on our simulation clinic’s wall.
Attending to details makes the environment feel realistic and believable. It gives the participant an immersive experience of what it’s like to juggle all of the tools and information required of a real nurse.
4. Set up the simulation clinic
We took several meeting rooms in our office and set up the nurse’s room, doctor’s room, and outpatient registration/pharmacy. Posters on the walls, similar to those seen in the field, were put up. The simulation clinic was large enough to simulate patient flows and patient queues, and small enough that the team was not too spread out so we could observe each others’ experiences.
5. Facilitate role-play
You will play the role of a facilitator — your main job will be to set the context and create an environment where your teammates can engage in a serious play-acting experience, learn about the users and find their own insights.
6. Gather your team together
Brief the team
The facilitator briefs the team about the plan for role-playing. Discuss the goals. Inform them that you will run two rounds of role-play followed by a debriefing session. Indicate the duration of each part of the plan.
Describe the roles
Describe the roles to the team. Have everyone pick roles that they want to play. Succinctly describe the scenarios that will be enacted. Printing out descriptions for easy reference for the team may be helpful. Here is an example of our roles.
Timebox the session
It really helps to set a relatively short timebox for each session. We wanted to give a sense of urgency for treating patients, so we limited the session to 30 minutes, which is about the time a doctor typically manages 5–6 patients (primary care doctors in India can see over 100 patients each day!).
7. Begin the role-playing sessions
The facilitator encourages team members to stay in the character of their roles, and helps ensure that the scenarios are being played out realistically.
Sometimes you may want to briefly step in as one of the actors to help tune up the realism of the scenarios. As a facilitator if you enact the roles realistically, your team members will be encouraged to do the same.
Mimicking observed disruptions to workflow is critical to ensure validity of the scenario. For instance, “patients” interrupting the “nurse” by asking her for some help or counseling is a typical situation that should be included. Interruptions require the “nurse” to switch context, respond to the “patient” in the moment, and then get back to the task that she was attending to.
Run 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. Create a brief quiet time after each session for everyone to individually write down their observations.
Debriefing is a critical part of the process. Once the role-playing session is completed, now is the time for debriefing — to share what lessons were learned and identify the important action items.
Create time for individual reflection
Allow for enough time for individual reflection. We took 15 minutes where each person wrote out their learnings from the experience. We had a list of five questions that they could respond to while reflecting on the experience.
Try not to jump right into a group discussion — the loud voices will drown out others and people won’t have time to personally reflect. Quietly writing down experiences first helps each individual and will foster a more equitable and nuanced discussion afterwards.
Facilitate a rich and equitable discussion
We went around the table one-at-a-time and each person shared a key point they had learned. Go around the table several times.
Encourage people to discuss how they felt during the experience — what was frustrating, what was challenging, what was enjoyable, and what was motivating? This will help build empathy with your users and will lead to meaningful insights beyond usability challenges.
Identify the key takeaways
Identify the top 3–5 takeaways as a team. These are the most important learnings or action items. A key learning could be as simple as, ‘We learned that it’s really frustrating to be a patient and to get treatment at these clinics.’
One action item we came up with: Create a user manual that would guide nurses on how to correctly use the app. 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 participated in the simulation clinic. We learned a few concrete things and gained an appreciation of the complex ballet in a clinic.
By role-playing and observing our colleagues, we learned that our app is one of several tools that a nurse or a doctor uses. It is very challenging to juggle all these tools, while simultaneously attending to a queue of anxious patients. We learned that we can’t assume users will give our software their full attention — everything must be easy to use and cause as little duplication of effort as possible.
We also observed how patient data moves 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. We learnt about the challenges of navigating a public health clinic as a patient, and how that can lead to important patient data not being recorded correctly.
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 is used that will help us to make better product and engineering decisions in the months ahead.
Any team that works on software will benefit from walking a mile in a user’s shoes. A simulation is one great way to bring that experience right into your office.