I seek out the root of the problem…
…but look to what’s already working well to inspire and frame my next steps. In the three sections below, I give the story of one time I sought the root of the problem while doing a walk-through of a site with our clients, one situation at work that required me to develop the skill of seeking the root of the problem without explicitly asking the users about it, and what I would do given one product development scenario demanding I find the root of the problem. Enjoy!
Design research at the CCDOC
My team and I had the opportunity to visit the Cook County Department of Corrections for the Segal summer design internship last year. This was our first on-site meeting with our project partners to see the space where our puppet theater would be set up a few months later.
Our job was to give the hundreds of kids who come there every month a chance to connect with their loved ones in a way they rarely get to—to give them a creative outlet and the tools to play on their own or with siblings in a place where play and creativity feel starkly out of place. Given the context the design would be used in, we had specific constraints on what materials the set could contain and which features were allowed in compliance with the facility’s rules, for the safety of the families, staff and incarcerated folks alike. As we were walked through the visitation room by a few representatives of the sheriff’s office, we looked around and asked questions… “What if the theater were placed there instead of where the current play area is? Where could the parents sit to watch their kids’ productions? How tall could we make it?”
I don’t remember who asked if we could build stairs and have a second tier for the kids to climb on to do their plays, but they responded by letting us know that wasn’t possible, and we kept going with the tour. I couldn’t stop thinking about that though, and later on asked them a few more questions. I found out that it was actually to allow for maximum visibility in the room for the officers, and the way they could see that happening is by making sure the set didn’t rise past eye level.
This quick follow-up revealed a requirement we hadn’t known was important to them before, and was ultimately relevant to other parts of the design—it meant no hiding places or features like tunnels could be included in the set—and later on, my team and I also briefly discussed meeting this requirement by making the top part out of clear acrylic.
This isn’t something that ended up in our final design, but it was helpful to learn what questions to ask to get to the root of what users and stakeholders need, while ensuring we can think beyond what’s been done in the past.
User testing at Keurig
When I was working at Keurig, I had the amazing opportunity to head my own project developing requirements and design recommendations for a component on their coffee makers. I was given a lot of freedom to achieve this end goal as I saw fit, and I immediately knew I wanted to talk to people and see them interact with the machine in person to see what was working well, what could be improved and which features and functionalities mattered most to them.
Over the coming weeks I organized and facilitated fourteen 1-on-1 user testing sessions. These were about an hour long each, and consisted of my observing folks with a range of different coffee-making experiences go through the process of interacting with the brewers, and chatting with them about their experience afterward.
I didn’t reveal up front what the specific goals of my research were, but with the help of my coworker—an expert in user research—I crafted a short list of questions that were designed to start a conversation about a specific step… and sought out the root of the problem via observation and dialogue.
Indeed, some of the best insights I gleaned from those sessions were from moments where we were talking about something else as they quickly finished a task or demonstrated something—not when they were performing it for the first time as I observed. This is the closest I’d get to seeing how they’d typically interact with it at home—early in the morning, in a rush to get to work, distracted by something else perhaps—and that turned out to be really useful data.
I also made a point to ask them about the parts of the process they enjoyed, and to ask them about the products they had at home—I wanted to learn from what was working well for them, and to see how I could translate those learnings to the trickier features and steps.
I learned a lot from that experience, made plenty of mistakes and asked for feedback throughout from my coworkers and supervisor, but ultimately grew a lot in my skills as a facilitator. Those ended up being some of my favorite weeks working at the company!
I’m given a product your company has received several complaints about and asked to figure out how to mitigate these issues in its upcoming version. Where do I start?
Now, if I were asked to identify potential failure modes before this product were broken, I would conduct an FMEA analysis. But assuming we already have a wealth of data about what’s going wrong, and I can visually inspect it for broken or worn areas myself, this is where I’d start…
-
If there are clear problem areas with probable causes for why they failed the way they did, I’d start here. If this is the only thing users are reporting issues with and the turnaround on the project is tight, I’d use my knowledge of the user journey and any reviews or customer feedback to map out the 3 main scenarios that would result in the issue occurring. For example, if a specific corner was experiencing stress concentrations and starting to come apart, or a nozzle kept getting clogged.
-
I’d do my best to recreate the user journey in context, taking note of each small action and step required to complete the product’s intended job. Enlisting a friend or coworker (who isn’t familiar with the process or issue) to run through the process too and observing them would be even more ideal here!
-
Often, the issue lies in the small sub-steps, often overlooked or deemed “not key” to the user journey. With a few sticky notes and a pen, what this process allows me to do is identify what key “jobs” the product must do—not cause someone discomfort as they hold a water tank under the faucet as it fills, deliver molten liquid from point A to point B, or zip up a coat with one hand—and using a “5 Whys” analysis to uncover the root of the problem causing inefficiency, frustration or damage.
This approach is central to how my capstone professor (Dan Brown) generated innovative designs during his career time and again, and it stood out to me as something that would be really useful down the line. This kind of systematic analysis of an issue can be really helpful in identifying root causes, brainstorming around the key “job” of a problem component, and uncovering new ways of getting those jobs done.