Workrise: Problem Framing Process

Designing an ongoing discovery framework for complicated product areas

“While doing product discovery, certain tools and techniques serve both to facilitate collaboration, as well as to provide an artifact as an output of that collaboration. Two very popular examples of that are prototypes and story maps. The very act of creating and discussing prototypes and story maps facilitates true collaboration. And if you are diligent about keeping your prototype or story map up to date, then they can also serve as an artifact capturing the learning and decisions from the discovery work. The real benefit and purpose of the tools in this case is in fostering the collaboration; however, it is a nice side-benefit to be able to have an artifact at the end.”
—Marty Cagan on collaboration

The Need for Problem Mapping

After conversations with many designers and product managers, we started to hear and feel some themes: product teams had limited understanding of the problems we were trying to solve for and often were not thinking at a system level to address symptoms instead of causes. Additional solution concepts were rarely considered, and teams were usually building the first idea they came up with.

Designers found themselves operating in a very reactive way to product requests, and we wanted to create a framework that would allow design—and other non-product functions—to be brought into projects early on, bringing a proactive, design-thinking approach to the problems we set out to solve.

We also set out to help eliminate the phrase, “We don’t have time for research.”

“Problem-framing workshops” is a bit of a mouthful, but we wanted to be very specific about what we called this new exercise. Problem, because we wanted teams to start with a deep understanding of the problem they’re trying to solve. Framing, because the problems we attempt to solve are complicated and multilayered and take time to understand correctly. Workshop, because we wanted this to be a collaborative session where all parties participate, engage, and generate ideas.

Inspiration: Monday of the GV Design Sprint

While working at ASICS Digital, I facilitated multiple design sprints. Participants really enjoyed the collaborative approach to understanding and solving for problems, but the sprints were very time-intensive and not always followed up on. So we asked ourselves: How might we break the beginning of a design sprint into a smaller piece our teams could quickly leverage?

We used the first day of a design sprint (Monday) as our inspiration for the problem-framing workshops. We knew that there was a huge need for teams to stop and understand the problem before diving into solutions. The Monday sprint exercises—where teams mapped out a problem and then decided on a specific section of the flow to focus on, bringing in experts to examine and correct the map, and, finally, generating “How Might We” cards—were always eye-opening and beneficial for teams, so we decided to pull those elements into our problem-framing workshops.

Designing the Framework

How many times have you seen a team create a beautiful, thorough user journey map only to watch it gather dust in a Google Drive folder? We knew that each of the three phases of this process (planning, facilitating, action) needed to be thought through, with extra emphasis on the post-workshop action phase, because what good is research if it doesn’t ultimately benefit your users?

Setting Up a Problem-Framing Workshop

We created guidelines and outcomes for the workshop planning session, a small meeting that should only take 30-45 minutes to complete, in which product and design align on the workshop’s focus and participants.

The product manager for the project explains the problem space and identifies the personas who are involved. Together with design, they map out the high-level flow of the problem and decide which specific part of the flow to focus on improving.

The group discusses which different factors they could solve for, and product decides on the factor to focus on. The last thing to do is generate the meeting invite list, and probe to make sure the right people are invited.

Facilitating a Problem-Framing Workshop

The goal of the workshop is to give the team the context they need to develop a shared understanding of the problem they’re tasked with solving, driving creative solutions through collective insights.

The workshop is split into a few sections, which I’ll explain below.

Intro

During the quick intro, we cover the goal of the workshop, introduce participants, cover the ground rules (no devices, no solutions, equal participation, tight timeline = parking lot for ideas), discuss roles (facilitator, decider, expert, ideator), explain desired outcomes, and preview next steps. Since this can eat up a little time during a workshop, we occasionally do this intro over Slack before everyone meets.

Persona Definition

During this phase, we crowdsource insights on the persona we are targeting. We ask the group to define the persona’s role, responsibilities, and goal in this task or flow and to highlight any useful information about their location, environment, or tools.

Map

Here, we walk through the high-level flow of the problem space and explain why we’ve chosen to zoom in on a specific step.

We have the stakeholders build the map with us, explaining the touchpoint where each step happens (app, SMS, email, in-person?). Once the group agrees that the map looks accurate, we introduce the aspect of the problem we’re trying to improve (the Y-axis of our map). For example, one workshop was about increasing a persona’s trust in our product and company, so we chose “Trust: Low to High” as our Y-axis of the map.

From there, we ask the group to help us rank each step of the user’s journey on that Y-axis (1-5). After we’ve ranked each step according to the aspect we want to improve, we explain that any low-ranking steps are things we want to improve over time. Low trust at step one? What can we do to move that up?

Insights

The next phase of the workshop is where we dive into each step of the journey and generate different categories of insights: what needs to be true for this step to be successful, wins, worries, and questions.

Outro

Once we’ve finished annotating the map with insights, the workshop is complete. The outro is a great chance to once again thank all the participants for their help in the session and highlight what will happen next. The discovery done in the workshop will lead to product improvements and user value, all because we took the time to thoroughly understand a problem space.

Generating “How Might We” Cards

When we initially designed the problem-framing workshops, we had the groups generate “How Might We” cards along with the other insights below the map. We found that there wasn’t quite enough time in a workshop to generate the quality and quantity of “How Might We” cards that we wanted, so we decided to split this out into a follow-up session.

Soon after a problem-framing workshop, a smaller group of product, design, and engineering will review the map and generate “How Might We” cards based on captured worries.

From here, we’ll draw boxes around what we call “slices of work”—areas that the team can prioritize and focus on. At this point, the team understands the problem, has defined what to improve, and will now generate multiple ways to solve for the problem, working together to determine which direction they believe will best solve their user’s problems.

Summary

So how did we do? Are we helping to solve the problem of teams understanding problems (so meta!). We are! We created, rolled out, and are training teams on how to use this framework. The response to this framework has been very positive, and we’ve used it on many projects to better understand who and what we’re designing for.

The workshops are cross-functional and collaborative and are doing a great job at demonstrating how design needs to be an inclusive team sport to be successful.

When we introduced the idea of this framework, we heard sentiment from the product managers that this could slow projects down. We kept that in mind while we designed the solution, and we made sure that workshops we planned with minimal overhead, were facilitated in under two hours, and that actionable insights could appear within hours of the workshop completion. Our proposed framework helped debunk the idea that there “wasn’t time for research.”

You might be thinking, isn’t this just a journey map? In a way, yes—but it’s a template that is customized to our business’s needs, and anyone who is familiar with one of our journey maps will be able to hop into another map and understand it and add additional insights.

A great side effect of these workshops is seeing the relationship between the product team and our stakeholders deepen and improve.

Many new projects are kicking off with problem-framing workshops, and every map that comes out of a session yields dozens of those wonderful purple “How Might We” cards, which drive teams to consider multiple, creative ways to solve problems. I’d call that a success.