Manjeet was counselling a patient with high blood pressure when another patient jostled through the crowd and asked her to hurry up. Each patient was anxious to get back to their own busy lives, and every person at the hospital was rushed, just like any other day at many overworked public hospitals in India and around the world.
At Obvious, one of the projects that we hold very dear to our hearts is a piece of software called Simple — an app designed for nurses like Manjeet, i.e. busy nurses with many patients. They use Simple to manage patients with high blood pressure, with the goal of saving many lives from heart attacks and strokes.
Now typically, clinicians don’t especially want to invest more time than required in an electronic medical record. Nurses and doctors don't come to work only to fill a database. They come to do the critical work of treating the patient sitting in front of them. If we want Nurse Manjeet to use our software, we must understand the working lives of nurses like her, and fit into them as seamlessly as possible.
Naturally, then, our team spends a lot of time in the field observing healthcare workers and asking for their help.
When we talk to healthcare workers about their workflows and how they use Simple, we are looking for patterns. Hearing a concern once is useful; hearing a pattern of concerns makes all the difference. A critical question springs to mind: How can we effectively communicate these patterns to the entire product team, such that we can make better product decisions together?
Our challenge in the initial stages was to bring lessons from the field into our office, so our developers, designers, and product managers can empathize with nurses and prioritize our roadmap.
Inspired by Airbnb’s ‘Snow White’ project, Simple’s Design Director Daniel Burka suggested a visual, data-driven storyboard that illustrated the key parts of the user journey (see the final storyboard here).
This storyboard is now a crucial component in our product process.
How to create a data-driven storyboard
1. Choose your protagonist and their story
The first step is to choose the primary user whose story you are narrating.
In the case of Simple, it is used by many types of users: nurses, doctors, pharmacists, counselors, and other healthcare workers. We chose to tell the story of Manjeet, a fictional staff nurse working at a public health clinic who is new to using software and apps. We chose her because she represents the largest group of our users and the most crucial base for us to satisfy.
The narrative is an end-to-end story of how Manjeet hears about Simple for the first time, her thoughts as she learns to use the app in her workflow, and how she ultimately teaches a colleague how to use Simple as well.
Tip: At this stage, consider keeping in mind that the story you're aiming for isn’t only about how someone uses your software — it also encompasses your user’s overall workflow.
2. Identify the key moments in the user’s experience
The next step is to select the key moments that describe your primary user’s interaction with your product in their context.
Tip: Consider paying special attention to the moments that occur most commonly. Emphasise aspects of the user’s experience that need most of the product team's focus.
In the case of Simple, we created a list of all the different user scenarios, and then grouped, categorized and prioritised them. For scenarios where multiple workflows existed, we focused on what either needed the most support or was most common. For example, there are multiple ways in which a nurse can hear about Simple. It could be through a memo, during a training session, or from another nurse. In our final storyboard, we picked the scenario where a nurse is instructed to use Simple through a memo. This scenario is especially challenging: How can a nurse learn to use the app by herself, without any prior training from her supervisors?
Tip: Avoid focusing only on the digital interactions between a user and your product. Remember to also include offline experiences that glue together your product in the story.
Similarly, we chose scenarios that depicted both online experiences like onboarding, registering a new patient, and making overdue calls, as well as offline experiences like patient treatment, being called out of the room for an emergency, and juggling several tasks at once. Offline and online experiences make up a nurse’s day and if our product falls apart when our users lose focus, our product will not be of much use.
Finally, we arranged the key moments such that each frame independently captured that specific moment; and when stitched together, told a meaningful story.
3. Sketch the key moments
As you sketch each moment, keep the user’s experience, front and centre. We also recommend staying close and truthful to the research data.
Our goal with Simple was to stay close to the user’s actual experience, by asking questions including the following:
- "How many patients will a nurse be attending at a time?"
- "What are the tools a nurse uses for their work?"
- "How old are the patients who visit the clinic?"
- "What do patients carry along with them?"
- "What is the conversation between the nurse and the patient?"
- "What time of the day would it be when a particular moment took place?"
- "What are the character’s thoughts?"
- "What does the nurse’s environment look like?"
- "What perspective must a frame be depicted in?"
For each frame, we pulled out the findings that we developed from user research. We depicted the details of her environment, answering questions such as "What does her table look like?’" and "How does she interact with her tools?". We made rough but realistic pencil sketches of the eleven key moments.
Tip: Ideally, refrain from giving the product more importance than the user. Focus on capturing the essence of the moment, without limiting yourself to what seems possible to solve.
4. Focus on your users’ concerns
Below each scenario that you've successfully sketched out, list down your users’s concerns. This familiarises the reader with the user's context, and enables product teams to set clear goals.
Each frame in our storyboard for Simple had a list of the most common concerns we'd heard from users and stakeholders in the field.
While many concerns can be tackled through the design of the product, others form touchpoints within a service that product teams must strive to design for.
Tip: Remember to only add concerns from research data, and refrain from adding concerns that you anticipate the users might have.
5. Create the final illustrations
After having consensus from the team on the depiction of the frames, you can create the final illustrations.
For Simple's storyboard, we made the colour and style of the protagonist’s clothing bright, so that she stood out in each frame. We also kept the style of the illustrations relatively simple.
Tip: If your illustrations are too fancy, you will have a hard time changing them later when you find out that a detail is wrong or you want to add another frame to your story.
6. Publish the storyboard where everyone can refer to it
It’s crucial to publish the storyboard in a place where your entire team can reference it while they work. Ideally, the storyboard you create should be easy to edit and add to as you learn more from the field, and as your product changes.
We published our storyboard on our documentation site (we use GitBook). We also printed out each frame and hung them prominently on our walls in our workspace so that team members could refresh their perspectives while looking at it time and again.
How storyboards help us during the design process
For starters, each time we make design decisions, we can go back to the pain points and try and address them through the design of our service. With Simple, for example, we need to make sure our product addresses as many of these concerns as possible if we hope to help thousands of clinicians to save millions of lives going forward.
Storyboarding also helps to remind us that software isn’t the only solution required — we additionally also need great training, support, and marketing.
For engineers and others who aren’t frequently in the field, having a storyboard helps to build more empathy with our users. It gives them context when they’re making decisions. It also helps to bring new members of the team up to speed, especially if they're joining at a later stage.
The eleven frames of our Simple storyboard, and those of our other projects, are a constant reminder of what we’re really building and how it affects our core users at the end of the day.
Moving forward, we aim for the storyboard to be a tool that fosters the participation of all stakeholders in the product design process, helping us make well thought out decisions.
- This article is co-written with Tanushree Jindal, without whose valuable input, the storyboard would not have been possible.
- Thanks to Daniel Burka for his help in writing and editing, which helped us strengthen the article.
- Special thanks to Dr. Terry Cullen and Dr. Greg Schmidt for reviewing and editing the article, and to Anand Ramakrishnan for the photography.