newsletter #28 | 19-Sep-2017
“Doesn’t the problem space come first? Shouldn’t it appear on the left in your diagram?” Lots of people ask me this. Research in the problem space isn’t a part of any solution cycle, so no, it does not come first. In an industry filled with process cycles (there are even figure-eight cycles), it’s hard to reconcile this idea with conventional step-wise approaches.
Problem space is not solution space. Well, obviously.
Here are the definitions I use:
solution space – working with your ideas and the incarnation of your ideas … trying to create something, solving all the details, making sure it supports someone and fits in context … trying to map out use cases and edge cases … supporting clearly defined users in different contexts that you have mapped out.
problem space – contexts and inner thinking, reactions, and guiding principles of people, without any reference to solutions they use … derived from research where the scope is the larger purpose or intent a person has.
These contexts, this knowledge of people … they don’t arise from thin air like some mist of knowledge. It takes hard work, knowledge of ethnographic techniques, ability to listen, and a sense of when you’re still at too shallow a level to truly understand the inner thinking of a person … Either that or it takes deep personal experience.
Normally, historically, teams work on solutions based on context and definitions that are already familiar to them. They come up with solutions that support themselves and people that think like them. That is historic convention. This convention is slowly being augmented with awareness and careful research trips into parts of the problem space that will make a difference to the offerings of organizations who have the leeway to focus on innovation and strategy.
Knowledge about the problem space is always there, whether it comes from familiarity or from careful research. It’s like the sun, blasting energy and power to all the spinning planets that orbit–all your solution cycles for various projects that your organization has in play.
Okay, so now for a really geeky analogy: Without the sun the planets would not form. So in this way, knowledge of the problem space does come first, before the ideas. When an organization first gets going, this knowledge is usually native knowledge. The teams responsible for getting something going often need to work insanely fast. Their native knowledge is just enough native hydrogen and helium to start fusion (but not sustain it).
Spend time researching the problem space when you need new fuel for your sun. Usually, this is about once a year. The knowledge (hydrogen and helium) will provide power (fusion) to your projects for decades (eons). Usually the problem space knowledge is aggregated in the framework of artifacts like mental model diagrams or JTBD reports, but it also finds form in ephemeral sticky notes. Any format is fine, as long as you consciously capture the information. For example, if you are starting out with native knowledge, it is also a good idea to formalize that knowledge in an artifact–clarifying the components that are the start of your sun and noting the boundaries where you’ll run out of material. (Just so you’re all cognizant of it.)
Alan Cooper is teaching a course at University of California at Berkeley titled Thinking Like a Good Ancestor: Finding meaning in the technology we build. “In the high-speed disruption culture incubated by Silicon Valley companies and startups, the scope of what we look at is generally the short-term reception of our developments by our users, and not the long-term shifts that will derive from them.” One of the things I teach about problem space research is that it’s about larger purposes and intents–things that your great grandmother might have been thinking about. These larger purposes are still valid today. In Alan’s class, the focus is on the larger social behaviors that result from our technology, where our purpose/intent is sometimes shaped in a different direction. Looks like an interesting course.
Andy Budd gave a talk at UX Week 2017 about becoming an Accidental Leader. He mentioned doing team building during work hours, rather than after hours, like taking a team field trip to a museum. He also mentioned doing listening sessions with direct reports (also in Chapter 7 of Practical Empathy), along with a lot of other inclusive suggestions.
I help teams wrangle the data they’ve collected through listening sessions. Over the decades I’ve had questions about synthesizing data from listening sessions. My answers below has been helping teams turn a mess of thinking into a neat list of concepts.
First a quick review:
combing – going through the transcript (or audio/video) to recognize which parts to pull out (reasoning, reactions, guiding principles), look for all the mentions of each concept, and stick them together
quote – bits of the transcript pasted together as a result of combing (done in your head if you are using sticky notes; collected in a spreadsheet if you are doing this for a traceable, lasting artifact)
summaries – for each concept combed out, write a summary in a clear fashion so that you don’t have to re-understand the concept each time you use the data later
If a quote from the transcript is making you go in circles:
1. Is it a cohesive quote? Is there meat (why-ness) there? Or does it just sound important from a solution point of view? (skip it if the latter)
2. If there’s not enough certainty about the reasoning, can you re-cast it as a reaction instead? Does it have more certainty that way?
3. If it’s a generalization, can you re-cast it as a specific instance, valid for this person?
4. Does the quote represent a single concept, or are there really two (or three) concepts interwoven?
5. Does the quote contain a phrase or part that actually belongs with another quote? If so, move that phrase.
5. If it’s a mess, can the quote be pruned back like a bonsai to reveal its shape? Remove the parts that are unnecessary; see what’s left.
Checklist for writing summaries:
1. Does the summary make sense at first glance, without any background or context? If not, it needs to be re-written.
2. Does the summary follow the rules? (These rule allow you to step into people’s shoes easily and not waste time re-understanding a concept.)
- first person (not third person), helps you step into their shoes
- present tense throughout, also helps you step into their shoes
- clear, with the key information up front
- includes details specific to the participant, using some key vocabulary to personalize it
- concise, not a compound sentence or a run-on
3. Is this summary already represented in another row? Should this summary be combined/moved there?
Representing what people mean. It feels respectful. It’s the struggle to chew over what people really mean–that’s how you get value out of it.
Grouping & finding patterns steps:
1. Start with a summary that you believe is a concept repeated by other participants. (Make things easier on yourself by starting with the common/poplar concepts, so you feel a sense of progress.)
2. Scan the first three or four words of other summaries to find concepts that are similar. Stay focused on the verb–the intent being carried out, or the meaning of the concept. (“Look for” or “search,” “gather,” “find,” or “form” are similar, and if each has an object that is similar, such as “an understanding of,” “the basics,” “an introduction.”)
3. Find other summaries by intent/meaning. Ask yourself, “What does this person intend by saying this?” (In the context of training for a long-distance run, “Stop to remove a rock from my shoe” is about making my running as comfortable as possible, since it is quintessentially an uncomfortable process. “Enjoy the fall colors,” is about getting a spiritual boost from the run, perhaps associated with distracting myself from the pain.)
4. Avoid finding matching summaries by the noun or object or person referred to. (Don’t group all “doctor” summaries together when some of them are about “feel uncomfortable” and others are about “struggle to get attention.” These latter two are different groups.)
5. Start from the bottom and go up. Don’t start with some idea of groups and find summaries to put in these piles (top-down). Instead, continue comparing the meaning/intent of summaries and stay at that level.
6. Write a brief label for the pile you’re creating, using one of the verbs. This label is temporary, just to allow you a way to keep track of what you’ve done.
7. The meaning of a pile you’ve already put together may shift as you add more concepts to it. The meaning might split. Change the label or split the pile and make two labels.
8. If you encounter a summary that isn’t clear, re-understand it and fix it so that it can be compared to other summaries more easily. (Split it, join it with another summary, write a new summary, etc.)
indi can help you
coffee with indi