Welcome to part two in our design series, where I get into some of the details surrounding how my team and I approach our design work.
In the previous section of our series, we discussed empathy and its importance to the design process. In this phase of the process, we drive down into the data and create the framework that will drive our design.
When I speak with people about how I approach my work, they are surprised that this step “Defining the Problem” exists – we’ve talked with our end-users and stakeholders, and now we should start thinking and planning our design, right?
Defining the problem seems almost so fundamental that it doesn’t need its own step, but in fact, it’s core to the entire process. Without actively defining the problem you can make all sorts of avoidable mistakes.
How it Works
Defining the problem is a phase that is rooted in data and methodology, which is why it often gets short shrift. It doesn’t seem fun, it seems rigid, and it’s not what you think of when you imagine designing and innovating, but it is so, so important.
Defining the problem means understanding what you are trying to accomplish. It takes all the relevant information and comes up with the ’problem statement’ (a statement that clearly identifies the specific health challenges we are trying to solve). So how do you create a problem statement? You start with participant data. Our participant data is in the form of conversations we have had with our patients, caregivers, and other stakeholders. We need to format the data, so my team can analyze it and create the problem statement.
I use commonly available software to help organize the data and isolate themes and keywords. There is a lot of nuance in this part of the process, but Grounded Theory is the critical principle that guides the process.
Grounded Theory is a research methodology that helps the researcher develop a theory or hypothesis based on the data. It is a useful and objective process that limits any bias the researcher may have, and ultimately through this method, I can arrive at the problem statement.
As we sift through the data, we separate text into different categories, based on the interview topics. This broad identification process is the starting point to eventually examine the data more narrowly.
Once we identify general topic categories, we start to look for five different things:
- What is the current standard of care? How do current accepted medical standards advise and instruct users to treat the challenge they face?
- What are the pain points surrounding that current standard? What do they not like about the device, technique, or technology that they currently use?
- What barriers exist against changing the standard of care? It could be a perception issue from the patient’s perspective. It could be an insurance coverage problem or a prohibitive cost. Sometimes there are no barriers, but often there are several, and I need to know what they are to work through them.
- What are the existing alternative solutions? Without the standard of care, what would a patient be doing to manage their challenges? We need to know what exists on the market and what ad hoc solutions are currently in practice.
- The last thing is feasibility. What are the parameters that we’re designing within?
The answers to these questions help narrow our focus and provide the guide rails a project needs to result in a viable solution.
To illustrate just how important properly defining the problem is, I’d like to share a story:
A very talented student of mine, Gabriella Zarlenga, was interested in a career in medicine. As part of her coursework, she spent time in a local hospital NICU (neonatal intensive care unit) where medical professionals care for newborn babies.
In her courses, she learned the value of “kangaroo care” for newborns. Kangaroo care, or skin-to-skin contact in which the physical contact between a caregiver and baby can provide the baby with important health benefits. From this connection between the infant and caregiver, the baby’s heartbeat will regulate along with their body temperature and breathing.
Gabriella saw all of these babies in the NICU that required extensive time and care in incubators, away from a caregiver, and identified a problem: the babies weren’t able to receive kangaroo care.
She came to me with the idea that we could design a blanket-like garment that the NICU clinicians could use while the baby was still in the incubator. We had many conversations about this device and its design, assuming it needed to be a wearable device.
Having seen this need, we both just blew right past the problem-defining step. Gabriella approached this issue from a position of empathy, so we assumed we knew what was needed and started trying to solve our perception of the problem, without having truly defined it.
We ideated and prototyped and came up with a swaddling garment and ultimately realized that what we designed would not address the needs Gabriella identified in her observations at the NICU. Our “solution” would provide limited benefits in comparison to the actual kangaroo care experience.
We relied on our assumptions instead of taking an unbiased, data-driven approach. Realizing our mistake, we returned to the drawing board and redefined the problem. Having now taken the proper measures in our process, we ultimately were able to arrive at a design that, instead of swaddling and keeping the babies warm, lines the incubator itself and imparts kangaroo care simulation.
This story is a good example to keep in mind because it shows exactly why this step is so critical. Gabriella is smart and talented and came up with a great idea, but it was an idea based on jumping from observation (empathy) straight to ideation without a clear direction. Often one of the hardest parts of a project is remaining objective.
Thanks for reading the second installment of the Design Process series. Stay tuned for the next steps, and if you’d like to be kept in the loop, subscribe to my blog below.