When & Why to Explore the Problem Space
When do you really need problem space knowledge? (Read more in the book Time to Listen, released June 2022.
In the design and creation of products, services, or software, most organizations follow a cyclical approach. The idea is that past work informs future work. The cycle goes by many names, with three or more steps involved. There is the Think-Make-Check cycle, Agile, Lean Product or Lean Startup or Lean UX, Jobs to Be Done, Continuous Dual Track, etc.
Laura Klein’s diagram in her book UX for Lean Startups depicts the cycle this way:
The Lean movement, of which Eric Ries is an early leader with his book The Lean Startup, introduced the idea of minimizing time spent developing the wrong ideas by checking those ideas before they go any further. Prior to Lean, organizations would commonly check designs after they had formed.
Common: as design is forming, after design has taken form
“How well does our gym coach app work for people?”
“Does the written copy A work better for people than written copy B?”
Less Common: after an idea/hypothesis has surfaced
“Is our idea of a gym coach app going to be helpful?”
Here is the a simplified cycle diagram with these areas marked up. In addition to evaluation studies, user research groups also involve users in generating ideas. I added these generative opportunities to the diagram as well. These are the processes that practitioners and leaders have helped refine over the past decade.
At this point I want to point out that the cycle is spinning around some software, product, or service that your organization offers. The ideas, design, and delivery effort is aimed at this software, product, or service. The evaluation and generation is about the software, product, or service. The customers or users all have a relationship to your organization. It has been too easy to look at the process through these lenses only, and to miss assumptions you have made. It’s too easy to mistake the system you have created as the way a customer thinks.
So you need a parallel way to look at things, to identify and erase your assumptions and to support the way a person thinks (or how different people think differently) rather than making them bend to the approach your system represents.
This parallel perspective explores how people reason as they achieve an intent or purpose. The intent or purpose is not a task, like “book a flight,” nor a goal like “take a trip to the Grand Canyon,” but a purpose like “take Mom to the Grand Canyon while we still can, since she always talked about going, but she worked too hard, each opportunity escaped her, and now she is 80. It would be a good way to celebrate her life and all that she has done for others in the family.” These larger intents, and the reasoning, reactions, and guiding principles behind them are what form a deeper understanding of people. The cycle for creating a deep understanding of people is necessarily separate from the cycles spinning around your software, products, and services.
The cycle for deeply understanding people involves listening to them describe their intents and purposes, untangling all the concepts they bring up,* and then walking in their shoes.
The separation between the cycles is traditionally represented as “solution space” and “problem space.” Dan Olsen, author of The Lean Product Playbook, is developing a four-step cycle that he depicts in the diagram below. Note how he represents problem space as separate from solution space.
Problem space is the realm of a person who is trying to achieve a larger intent or purpose, like taking Mom to the Grand Canyon. Solution space is how your organization supports her in this intent: are there options available to support elders and their companions physically, respecting intelligence and experience, relating to biological time constraints, using tones that recognize the person’s situation and background? Are there reasons to support different people in different ways?
I believe that forging a deep understanding of people has to be separated from the definition, design, and delivery cycle. Here’s why: it takes time. It is difficult to fit deep understanding into the speedy time frame of development. To give yourself time to forge deep understanding, separate the effort from the development cycle. So I show the difference between problem space and solution space in a slightly different way than Dan Olsen, below.
This form of solution space exploration is a way of checking assumptions, building better, more nuanced support for people’s different philosophies, or honing your focus on one particular segment. It is still very uncommon, yet teams in architecture, banking, data & technology, higher education, manufacturing, software, and transportation are delving into it. Their hope is to learn to support people in more nuanced, fulfilling ways. Startups are using the approach to hone their initial focus and reduce risks of going off in the wrong direction.
Common: as design is forming, after design has taken form
“How well does our gym coach app work for people?”
“How well does this written copy work for people?”
Less Common: after an idea/hypothesis has surfaced
“Is our idea of a gym coach app going to be helpful?”
Uncommon: before the ideas come up
“What goes through people’s minds with regard to what our organization is in a position to support, such as staying generally fit, losing weight, injury recovery, building muscle, training for an event as a newbie or a repeater or a champ?”
Developing deep understanding of all the different reasoning, reactions, and guiding principles people can have as they achieve a purpose gives your organization clarity of vision. I describe how to do it in my book Practical Empathy, where I define deep understanding as a form of cognitive empathy. Since this deep understanding is based on larger intents, it does not hinge on a particular state of technology, product, or service. The knowledge does not go stale. You can keep working with it and adding to it for decades.
* How to forge deep understanding:
- The first step is to identify and untangle the concepts a person mentions, then re-state these concepts in a clear way that ensures you won’t have to re-understand them later on. (Since this data does not go stale, you will be re-encountering these concepts for years as you use and add to the data set.)
- The second step is to see affinities between the summaries you created in step one for different participants, and let them form into groups. These affinities are not based on the thing (noun) mentioned, but are based on the intent of the participant.
- The third step is to consider the data in relationship to your organization’s current needs and use the resulting insights to a) support the philosophies of the user, b) create different experiences for uses whose philosophies differ enough, and c) employ the language and purposes of the user instead of exposing the language and features of the system.
