The Real Problem is the Problem: Using Presumptive Design to Validate the Problem Space
The challenge for most of us, much of the time, is to create outcomes that matter to the people that matter in our lives. Whether that is a professional focus, such as creating “the next big thing,” or a personal endeavor, such as making a holiday event fun, inclusive and familial. The first step is always to identify the problem we’re trying to solve–without defining the problem, how can we know when we’ve solved it, right?
That seems like a stupid thing to have to say. We’ve all heard the expression, “once you’ve figured out the problem, you’ve got it half-solved…”–a gesture to John Dewey.
All too often we jump in, developing an approach (or touted design approach) to a solution without spending enough time really understanding the problem. Lately, some of these approaches have new and provocative names like Lean UX and Google Design Sprints. Yet, merely crafting a solution more quickly is one of the most expensive ways of figuring out you’re solving the wrong problem!
All too often we jump in, developing an approach (or touted design approach) to a solution without spending enough time really understanding the problem.
Instead, we have been exploring a radically different way of approaching the problem space — a light-weight mechanism to quickly figure out if you’re even focused on the right problem — before you spend tons of money on building out a solution. I’ve named the technique Presumptive Design.
Let’s draw on a well-known, design-thinking framework from the UK Design Council — the renowned “Double-Diamond Diagram”.
The left diamond is all about understanding the problem: you, or the organization you serve, have identified an opportunity (an “intention”) and you are now trying to figure out how to address it. We refer to this area as the “problem space.” Before we can say we understand the problem space, we have to agree that both sides of the left-hand diamond have been completely explored. In our experience, this isn’t often the case.
For many organizations, the problem space is defined by the intention itself. “Let’s have a party!” But merely shouting an expectation isn’t sufficient by a long shot. In the left-hand side of the left-hand diamond we are obliged to look at the intention and question it, poke at it, give some thought to it. Do we need a party? What kind of party? Who is it for? Why are we having a party?
Okay, I grant you all of that may be a buzz-kill for something that is supposed to be fun, but the real question should be: how do you know it will be fun for the people you are inviting if you don’t know what they consider to be fun?
Well, that’s easy, you may respond, “I would have fun at such-and-such a party, so I know my friends would too! Or, We had a great party last year and everyone had a great time, so let’s do that again, it will be fun!”
Those responses illustrate a key set of flawed assumptions:
- What I consider to be fun, I know my guests will consider to be fun as well (or restated: My guests are like me so I can predict what will be fun for them)
- I know the party we had before was fun, so it will be fun again
Simply re-phrasing the intention (“Let’s have a party!”) so it becomes a problem statement (“We need to throw a party!”) is not exploring the problem space itself.
By now you’re saying, “Really? I need to ‘explore a problem space’ just to throw a party?” And I’d agree with you: exploring a problem space for a party is overkill, or it may be something you do so quickly in your head you don’t need to sketch it out. But for other endeavors, involving risks to property, capital, or lives — exploration is absolutely necessary. Yet, in many such high-risk endeavors (like new product development) teams only traverse the right-hand side, the convergent part, of the left-hand diamond. That is, they accept at face-value the assumptions behind the initial problem statement without questioning it deeply.
And what about those assumptions? What if you are throwing a high-stakes party for people with whom you aren’t very familiar? What if these prospective guests have a very different definition of “fun” than you?
The artifact isn’t a solution, like Lean UX or Google Design Sprints promote — instead it’s an embodiment of the team’s assumptions.
Presumptive Design is all about bringing those assumptions out into the open by crafting an artifact your team can test. The artifact isn’t a solution, like Lean UX or Google Design Sprints promote — instead it’s an embodiment of the team’s assumptions. It might appear to be a solution (in the form of a paper prototype, for example), but no one believes it’s really a solution.
In the case of a high-stakes party, you might sketch out an invitation, including things like a celebrity appearance, or a magician, or a pony ride – whatever the team has assumed would be fun.
But merely creating an artifact isn’t sufficient; PrD has the team test the artifact with stakeholders – the folks you are expecting to pay for, or use the solution. Here again, in the case of a party, you’d likely show your sketch to a few of the people you’d want to attend and see if a) they’re even interested in a party, b) if the sorts of activities you’re planning interest them and c) what else they might suggest instead of a party that would be fun.
In the real world, testing the problem space (that is, truly ideating and looking at the possible problems your team faces) is pretty difficult. But Presumptive Design makes it easier and more fun, no matter if you’re planning for a troupe of clowns or creating the next big thing.
– – –
Leo Frishberg is a UX strategist based in Portland, Oregon. He will be exploring his presumptive design model during the Webvisions Portland workshop: Create First, Research Later! Presumptive Design: An ‘Action First’ Research Technique.