2013 Main Conference Talk
It’s easy to solve the wrong problems. Good design relentlessly questions assumptions and reframes the problem to be solved. We know this, and yet, HOW to actually reframe a problem is missing from our conversations.
In this session, Stephen P. Anderson will share tips that have helped him cut through the noise of requests and requirements, to focus on the real problem(s) to be solved. Specifically, you’ll pick up ways to see a problem from different perspectives, ways to ask why, how to draw upon seemingly unrelated experiences, how to separate real from perceived constraints, and most importantly, ways to keep yourself in check, so as not to solve the wrong problem (or if you do, you do so intentionally, for a strategic purpose!).
Whether you’re designing strategies or screens, you’re sure to pick up a few new mental hacks that you’ll no doubt use on a daily basis.
About the speaker(s)
Stephen P. Anderson is a design leader focused on workforce learning and organizational development. And he’s on a mission: To make learning the hard stuff fun, by creating ‘things to think with’ and ‘spaces’ for generative play. Through custom toolkits, on-site training, and The Mighty Minds Club, Stephen helps product teams work through their most difficult situations. As a keynote speaker, Stephen continues to challenge and inspire audiences as he exposes the quirky connections between games, play, learning, interactive visualizations, and other exciting topics.
Stephen is most recognized as the man behind the Mental Notes card deck—a tool that’s widely used by product teams to apply psychology to interaction design. He also authored Seductive Interaction Design, which answers the question: “How do we get people to fall in love with our applications?” Stephen’s next book, Figure It Out: Getting From Information to Understanding will be out Spring 2020.
Stephen Anderson: Thank you for being here after lunch. I have a real issue with time management, so we’ll go ahead and get started right now, on time. My name’s Stephen Anderson. I am coming from Dallas, Texas. I’m an independent consultant.
I help lots of companies with product and strategy needs, lots of companies being startups, primarily. A few years ago I created or self-published a deck of cards called the “Mental Notes Card Deck,” which looked at ways to apply psychology to design.
A year later, I published a book with New Riders called “Seductive Interaction Design,” which is all about the same topic, psychology applied to design. That is not what I’m going to be talking about today. It has nothing to do with today’s topic.
What I want to talk about today is something that I see as a recurring problem since I’ve been consulting, since I’ve been in this career professionally for the last decade, something I’ll comment more on as we get into it.
Let’s start off with a quick exercise. For this exercise, I need everyone to get out a sheet of paper and something to draw with. You can’t do this on your mobile device. It’s going to be sketching. Those of you, if you’re short on paper, your lanyard actually have blank sheets to take notes. You can use that as well.
Here’s the assignment. I’m going to give you two minutes. I’ll set the timer, play some music. I’m going to give you two minutes. I want you to design a vase, sketch a vase. Practice those sketching skills. Are you ready? Three, two, one. Go.
Stephen: Those of you who just came in, grab a sketch pad, and start drawing a vase. You have a minute and a half left.
Stephen: I see some beautiful vases.
Stephen: 34 seconds left.
Stephen: Two minutes are up. Very quickly, take about 10 seconds each. I want you to share your vase sketch with your neighbor, give you a chance to show off what you just drew.
[background noises only]
Stephen: You got beautiful vases. I saw some of them. Now, go and flip your sheet of paper over or draw a line. You’re going to draw below. We’re going to do a second drawing exercise.
This time, I’m going to change the question a little bit. Instead of designing the vase, this time, you have two minutes, just like before. This time, I want you to design a better way for people to enjoy flowers in their home. Two minutes. Go for it.
Stephen: Be polite to our neighbors. A minute left.
Stephen: Show of hands. I don’t think we have to show this time, but show of hands. How many of you felt like you did something much more original, much more interesting? How many of you had a better time with that second problem statement? Just raise your hands. I think most of you, like me, the first time I saw this example, this comes from a guy named Mark Rettig, instantly I got it.
We reframed the problem. We changed it from designing the vase, which is to find the solution already, to actually designing the reason we have a vase in the first place. That’s why when I talk about…It’s this theme that I found in this very elegant quote from e.e. cummings, “Always the beautiful answer who asks a more beautiful question.”
Where a lot of people stop, design is creative problem solving. Of course, if you have seen this model before, you know the highest level of the design maturity model is design as actually problem framing as well. You can be creatively solving the right problems. That’s really where I want to focus on today. How do we actually frame the right problem so we don’t get suckered into solving the wrong things?
Stephen: I’m not going to talk about frames, metaphors, language, Lakoff-style stuff, linguistic relativity, I’m not going to talk about adjacent problems, and I’m not going to talk about unicorns.
Stephen: Instead, I just want to talk about this thing that happens all the time. You get a request from a business stakeholder, a product owner, whatever it might be, and they said, “We’re going to build a tricycle with wings.” By the way, that’s a silly request. Immediately people say, “Great! What colors do you want it?” or, “Awesome, I can trial some HTML5-coded titanium on this project.”
Then there’s the one person, hopefully, who says, “Wait. Wait. Stop. Why is this valuable and for whom?” That’s what I want to talk about. That’s what I want you to be and that’s what I want all of us to be, that when we get these requests, it’s a challenging thing to do this, because sometimes they’re obvious problems. It’s easy to say, “Wait a second, let’s pull the brakes.”
Then there are more deceptive problems, ones that are harder to spot, like the vase example I kicked off with. What I’ve decided to do, what I thought would be the most effective to help us to be on guard against bad problem statements, is to actually go through a name base. I’ve cataloged and named about 20 bad problem statements.
But just write down a problem, recently, that you were asked to solve, and then, as I go through the ones that I’ve identified, see if you find a match, or a couple of matches. As I go through, you’re like, “Aha! Solutioneering. Yes, that’s the problem I wrote down.” Take about 30 seconds. Just write down a recent problem you were asked to solve.
Stephen: I’m going to go through and I’ll share examples of the problem statements and we’ll name them. Some of these I have more examples of how to respond. Some of these, we’ll just skip through very quickly. Here are some requests that I’ve heard.
A lot of these may be clients I’ve had in the past. They may just be things I’ve heard. Here’s one, “Write some case studies to show how our customers love us. We need a help game to health employees meet wellness goals.” Not quite obvious, but this is exactly the same type of problem the base problem was.
The solution is defined in the problem statements. I would call this anchoring. I would say, if I was in a room, “Is this a real problem or are we anchoring? Are we framing the problem in the context of a specific solution which immediately discounts all other solutions?”
Here are some more examples. A way to spot this, “The design a vase or design a better way for people to enjoy flowers,” is the difference between describing a product or a task. Focus problem versus designing experience focus problem.
I worked at a startup in 2007 where what the problem most people have tackled is design a better search engine results page. We tackled a different problem. Design a better way to learn about and we had all sorts of topics. That led to totally different solutions.
We were focused on the experience of what happens when people type certain words. What can we do to sense intent? Here’s an example. Someone says, “Design a better compass.” You get something like this, maybe a nicer looking one.
If you go back to the reason we use compasses in the first place and what they help us do, then you might end up with something more creative. It’s using a camera and the accelerometer and you hold it up and you actually get a sense of direction in a completely different way. I’ve seen this happen with calculator apps.
I don’t know if you’ve experienced this, but you’re typing some calculations and you need to go back and change one of the numbers you did before. If you don’t or you can’t, you end up starting it all over from the beginning. I see heads nodding. “Calcbot” solves this to some degree.
I want to play a quick clip before I go on. This is a common problem. This is an interview with Jony Ive and he was revealing some responses to a design challenge that elementary students had done in the UK. I want you to listen to this clip.
Jony Ive: If we’re thinking of lunch boxes, we would be really careful about not having the word box. Already gives you a bunch of ideas that could be quite narrow. You think of a box as being square and like a cube.
We’re quite careful with the words we use. Those can sort of determine the path that you go down. I’ve got some video.
Stephen: “Quite careful with the words we use because they can determine the path we go down.” Let’s go do another one. This problem has already been named and you will probably recognize it. “We need a new Drupal CMS to make it easier for our team to add pages or our company needs a SharePoint installation.”
Anyone heard problems like this? This has a name already. This is called solutioneering. How many of you have heard that before? Solutioneering? I love the phrase. It’s framing the problem in terms of a technology purchase when the issues may not be technical.
I worked at a company where they made a lot of money selling SharePoint installations. I didn’t last there very long because it bugged me. I was, “What’s the problem? How are we helping people share knowledge? What are we really trying to do?” From a business perspective, they were trying to sell SharePoint installations.
Here’s another one. “We need our new site to be able to do this and this and this.” This one happens very often. It happens in the selection of tools to use.
I would call this wish listing. Are we solving the real problem or are we wish listing? It’s framing the problem as a set of desired features. I will admit because I’m not perfect at solving these problems.
We are going through this at the company I’m with right now where the engineering team is selecting a new project management tool. They’ve been using “Acunote” and they’re looking at things like “JIRA,” “Pivotal Tracker” or “Sprint.ly.” “Sprint.ly” was my recommendation, but they’re lining up a list of all the features they need like integration with “Zendesk” and all these other things.
They’re checking it off and they’re finding one that matches the most features. I haven’t been there long enough to really push an opinion. It’s largely for the engineering team. What I would try to do is direct them to say, “What’s the problem we’re trying to solve?”
When you move those lists of requirements to conditions of satisfaction, but not the real problem, then they become a little more flexible. You can say, “The real problem we’re trying to fix is this and we had this list of conditions. We could probably move around a few of these or dismiss these because the bigger problem is communication or collaboration or timely tracking or whatever it might be.”
Anyone relate to that problem? The features trap? Here’s another one. “We’re going to be the iTunes of health insurance.” I don’t even know what that is. “This will be the Angry Birds of online shopping.” This was easy to come up with a name, buzz wording. That’s what I’m going to call this.
It’s likening the solution to some other popular product or service. When you’re pitching the idea or trying to get investment, this is fine. This happens in Hollywood all the time where people will pitch, “It’s going to be the ‘Star Wars’ of whatever.”
When it comes to framing the problem you’re trying to solve, it can actually be dangerous. Most of the time, I’m like, “What do you even mean by that?” When you say iTunes, what are you thinking about? Is it their success or their management because I don’t see it? Buzz wording.
Here’s one. I’ll actually read it from right to left on these. “YouTube meets Craigslist.” This is actually a project I worked on back in 2003. “Friendster plus Tribe plus Craigslist.” That’s what we’re building or, “A tool for logging students into the computer lab, but also a way for teachers to sift through student data.”
What do you see in all these scenarios? What’s happening? It’s a mash up of some different things. I would call that frankensteining. That’s actually a term used in graphic design when you mash together some different design solutions. I’m going to use it here for our conceptual problem.
We’re framing the problem as a blend of things that may or may not mix. This is a good time for me to say that, to some of these, the context may dictate that these are OK that these aren’t so bad. It’s important to have that conversation and realize, “Are these good or bad?”
For example, you could describe…I was trying to make up something. I thought about, “What about YouTube meets Instagram?” I realized, “Oh, that’s Vine.” There are cases where this could work. It’s a different approach. We want to be on guard against what we’re doing.
This is a classic example. This has been around. This goes back to Alan Cooper‘s book “The Inmates are Running the Asylum.” He talks about personas and clarifying, “Are we building a car or a truck or a van? What is it?” Otherwise, you end up with something like this.
This same analogy was carried forward into “The Simpsons,” with Homer. Do you remember that? Homer finds that he has a cousin who owns a car manufacturing facility and he’s able to design the perfect car that has all the features he wants.
Of course, it bankrupts his cousin’s business because no one wants that combination of things. This next one I was going to go with noun names. I would have called it the epic, but the naming convention I opted for is a little bit different. I’m curious if anyone else can relate to this project.
I’m not kidding here when I tell you, I worked, years ago with a client who said, “We want iTunes plus iPhoto plus YouTube plus Facebook plus cloud storage all rolled into one. It’s going to be your media center in everything. It’s going to have all that stuff.”
You could kind of see, “OK, media kind of relates.” The only reason we put any stock in it is because of the brand of this company and we thought, “Maybe they can pull it off.” They weren’t a startup. Really big epic problem. I thought we would call this boiling the ocean. Actually the term is out there, we’ve all used.
We were really taking on something too big. We worked hard with this client to find that epicenter, that place to start, to grow into this. It was a really hard challenge.
Again, boiling the ocean. I think a lot of us think of as a negative thing. What are we trying to do? We’re trying to boil the ocean here, but actually getting a man on the moon was a boiling the ocean problem. There’s a time and place for those but if you’re solving a boiling the ocean problem, it also means that you have a team in one way to do that.
We need more customer support folks to answer all these incoming calls. Anyone want to guess what’s happening here? What trap you might be falling into? Is what? How about solving the problems.
I’m calling this, “Treating a symptom.” It’s a phrase we’ve heard reacting to urgent problems rather than seeking the reason for that problem. I have to say, I’m rather proud of my little brother. He works at a company where they actually make more money when they get more customer support calls.
They have this exact request. This came from him. They have this exact request a few weeks ago. His response to them was, “Why are you getting so many calls? How can we improve the product or reduce the number of incoming calls?”
His rationale was, “Wait a second.” He even said, “We lose money by chasing this away. We’ve become a partner. We help them fix the bigger problems and that shifts the money for more innovative things, more interesting things.” I’m like, “Wow,” I wish more business people have that enlightened view.
Here are some other examples. Very common, I encounter this all the time. “Our customers don’t know how to use X.” Insert whatever you want in there. The response is, “Let’s give them more training. Or add more instructional text. Or, maybe a tool tip to explain what to do.”
How many of you have been in this situation? Have this response? It’s universal. This has been exemplified in the “Norman Doors,” from Donald Norman’s book, where you have a problem where, it looks like a pull handle.
That’s what it looks like it should be able to do. It’s actually a push door so people fix it by adding a label, by adding noise. This is an example. A friend of mine pointed out. I thought that was just great. This restaurant or this place where we eat, they had problems of people throwing away the baskets.
The solution, add a sign that says, “Don’t throw away the baskets.” There’s a simpler more elegant solution, make a smaller hole so the basket won’t go into.
This is that contrast between are we adding on junk to solve the problem. Or are we getting back and solving the real problem, which often results in more elegant, simpler solution?
I wrote to a few friends, before this conference, looking for ideas and things and Dorian Taylor sent me this really fantastic example. He says, “If you take the problem of a kid learning to write a bike and the kid’s falling down. There’s a very engineering approach, which is to add training wheels, to add stuff, to solve the problem.”
He’s falling down, let’s fix it. Let’s add training wheels. That might help, but when the training wheels come off, it’s still a very painful process. Timmy still falls down, scrapes his knees.
The design mind set comes up with something like the push bike, where there are no pedals. It says, “The real problem isn’t that Timmy’s falling over. The real problem is helping Timmy how to ride a bike.” We know there are several things you have to learn.
Balance, being one of the most difficult. Let’s start off with a bike that’s just a push bike where you can learn to master balance. Once they’ve done that, then they can move up to a bike with pedals. It’s a much easier way for young children to learn how to ride a bike.
Speaking as a father of several boys, I can advocate, just personally that yes, the push bike works much better than the training wheels approach. What I like about this is it gets back to the human need. What’s the human need that we’re trying to accomplish? It’s not about the thing. It’s about the person we’re trying to help. I like that you end up with a more elegant, simpler solution.
We must fix this now. I’ve got several customers complaining about our new changes. I’m going to call this one, “Amplifying of the feedback.” Maybe several customers are three and you’ve got thousands of customers but, for some reason, it gets put under the microscope.
Any of you that come from a sound engineering or a music background, what happens when you put the mic in front of the amplifier? It creates that feedback loop. It gets louder and louder and louder. That’s what we’re talking about here. Allowing the complaints or the praise, of a few people, to drive decisions even when it’s statistically invalid.
This is one that I encounter all the time. It’s very deceptive because it comes in 100 different ways. It’s phrases like, “The technology doesn’t allow us to do that.” Or, “We’ve tried that before.” Or, “The Senior VP will never go for that.”
In fact, I could probably break these all into probably different problem statements. For now, I’m going to call them all, “Hamstringing.” Actually constraining the problem with assumptions, usually tech, user, or political. In the case of “We’ve tried it before.” It’s an example of learned helplessness, where you’ve tried stuff and you’ve failed so you’ve given up.
This one bugs the heck out of me. I usually won’t enter into situations where I’m removed from the decision stakeholder. Oftentimes when this happens, I’m like, “Great, let me go talk to him. Let me show him these ideas. Let’s find out.” The intermediaries are often a lot more cautious than the person they’re representing is what I’ve found.
This one sometimes is true. More often, I’ve found it’s not true and I start poking at the technology saying, “Wait, I know a little bit about how things work.” We’ll go through and I usually find out that it can be solved just no one’s ever pushed on the IT team that way.
Here’s another one, or maybe you have legacy technology or legacy product that has brought you a lot of value. Maybe it’s an outdoor map. You are thinking the problem is John selects a nearby fishing spot on the map.
You’re already constraining the solution by requiring the map, your intellectual property, to be a part of that. A better problem statement, an experiential problem statement would be John needs a way to discover a great new fishing spot. See the difference there? Subtle reframing.
This one happens all the time. We need a Facebook page. We need a blog. Your simple response is? What is it? Why? Yeah. This is band wagoning it. It happens often because everyone else is doing it. Framing the problem is something important to do because everyone else is doing that thing. Our response there should be, “Why?”
This one’s more deceptive. Once upon a time, this wouldn’t have been a problem but the hotel, if you’re a hotel company and you’re saying this is the problem statement, what are you ignoring? That just came about over the last two or three years?
AirBnB and other forms of lodging. What’s the real problem? It’s not booking a hotel. It’s more like finding a place to stay for the night, finding lodging. Hotel is just one of your options. I would call this, “Narrowing the problem.” Framing the problem of a specific solution which immediately discounts other solutions.
Here’s another before and after. User needs to compare pricing. There was a project that I worked on recently. As I got deeper into the problem, I realized it wasn’t just pricing, it was which sellers give me the best products and went with the best contract offer, was a broader problem. We had narrowed the problem, initially.
We need a new home page to promote our feature deals. Users of a complete brief conversation surveys will help us measure program impact. I’ll just jump to this one. Pacifying whoever it is, usually internal business stakeholders. You end up writing these very fictional things that you know that no user wants.
No one wants, but someone’s asking for it internally so we have to write it and solve this problem. The problem is framed entirely in terms of one group’s priorities, typically the business priorities.
Let’s go back to the hotel example. User will book hotel with Expedia. You work with Expedia. This is the problem statement we start off with. People will educate their families, friends about our life saving product. We’ll call this “Being presumptuous.”
Stephen: Presuming users will do some implausible activity. A couple more of these and then we’ll check and see if you found the match. I’m not going to start with an example here. I’m just going to share some I’ve collected.
This is overlooking the obvious. The problem, as it’s presented, is missing a vital piece of information or based on a flawed assumption. Let me give you a story. This one has made the rounds in different books. You may have even encountered before.
During World War II, Abraham Wald was brought in to answer the question. They were looking at all these planes they were bringing back from the battlefield and looking at all the bullet holes in the armor.
In fact, they did some statistical analysis and mapped out where all the bullet holes were going. The question was, “Where to best add armor to the plane’s structure?” If you just look at it, what would your hunch be? This is the hunch of the room. Where would you add the armor?
A lot of people said, “Those were where the bullet holes are. We need more armor there.” He said, “What we’re missing is. These are all the planes that actually made it back. What we should really be looking at is all the planes that didn’t make it back.”
He said, “I’m willing to invest. We need more armor where you don’t see bullet holes because those are the ones that probably crashed and that are where they were shot.” He said, “We’re missing something obvious here.”
Let me take this down to a very granular atomic level with a Web UI I was asked to do a few years ago, when I worked at travel company. It was one of these one or two hour type projects. They said, “Hey, can you do a makeover on this screen? Can you fix this up? Can you prettify it whatever it may be?”
When you look at something like this, your initial impression, your initial assumption is here, you’re comparing A and B. Let’s make a better comparison and choose between the two.
If you’ve gone down that path, you’d be solving the wrong problem because the context of this, was actually during the check out process, and you’ve actually already brought this one on the left, that’s the one you have. They’re trying to up sell you to the second one. It’s not a real compare contrast.
When I stepped back for a moment, just to think about that. I said, “Oh, this doesn’t even need to be in the grid or columns. It should be more something like this. Let’s just add some bullets. You can upgrade for 2.50 and get these additional features than what you currently have.” Stepping back and saying, “Let’s solve the real problem.”
Let’s see, go through a few more of these. This one I’ll just jump through because it’s fun. [laughs] I’ll call it “ego stroking.” Insert whatever you like here. It doesn’t matter what question the HIPPO asks for. You guys, are you familiar with the term “HIPPO?” Highest paid person’s opinion.
A person comes in and says, “This is my opinion.” The only reason a problem exists because it’s important to the HIPPO. Those are hard to deal with sometimes. I usually try to drive things back to the business goals and the outcomes and what we hope for. Then, try to resolve the discrepancies there.
This one came from Matthew Milan. I’ll tell you what he calls this is in a moment. His example was he works with clients who will say, “It’s like AirBnB but with this missing feature.” Or, “It’s like this site that’s really popular, but they’re missing this features. They just haven’t built it. I know there’s enough of a user base that would like that service better, if it had these additional features.”
Have you ever encountered that problem before? People trying to copy something plus. He calls this, “Flavoring.” Framing a problem as an existing product plus missing features.
We’ve seen people try this over the years with we’re going to do a better Twitter and have these things. 37 Signals products were so simple. We’re going to build one with the features everyone wants. Then you lose the elegance of what they have designed.
This one, I might get in trouble for saying, but don’t spend too much time on this. You may have heard or MVP. I’ll put a big asterisk there. It’s MVP as it’s practiced. I’ve encountered a lot of companies that use the language of MVP but not for what it’s originally intended.
When they say MVP, it’s the least amount of effort is what they mean or something crappy but functioning. This is actually a term satisficing. Aims for a good enough solution — which is fine, in some context, particular for startups — that avoids the risk and the costs associated with identifying or responding to the root problem. That’s the danger. That’s what you’re doing when you satisfice.
This one we’ve all seen just copy Amazon, or just copy whoever. I’m going to call it following the leader. This one a little bit hard if you don’t know a lot about the domain. Maybe you get a request from a health company. It says, “We’re building the community for parents of Type I diabetics.” I will point out that this already exists in multiple ways.
The client of the business who’s asking for this is suspending reality or they’re putting their head in the sand or they’re not recognizing that this is a problem that’s already been solved to some degree. Believe the problem has not been solved already. How many of you have had clients like that?
This one again, good or bad, the view eye looks great, well we only have a few options, like four or five options, but we’ll have hundreds in a few years. We need to design for both scenarios.
Scalability is obviously important. I usually come back and say, “We only have four or five right now. If I design for 200, it’s going to look like crap. I can make it look great for four or five and we can revisit it in six months when you’re at 12 to 20. We can revisit it at 50 and we can make the content look great at whatever scale you’re at.
Let’s not solve the problem that doesn’t exist yet.” I’m going to call this, “Future proofing.” Solving for a problem that doesn’t exist yet. This is dangerous for a lot of start ups, that’s concerned with the scalability thing too early or scaling the UI. You definitely what to do that at some point. You want to avoid code debt, IA debt, UI debt.
But there’s a danger and I’ve seen it happen over and over again where people build for a future that doesn’t exist and they never even make it out of the starting gate. So future proofing.
Here’s a checklist of the 20 I went through. Like I said, this is just a start. I would love for you to add to the conversation or critique the 20 I identified, add more examples, whatever you may want. I put this at bit.ly/badproblems and that will link to a Google Doc. I invite you to collaborate on this. Let’s continue adding this and getting a language for spotting bad problems.
How many of you found a match or more than one match for the problem you wrote down? Raise your hand. Most of you. That means those of you that didn’t raise your hand, you’ve got to go to the site now and add your problem and figure out what to call it so you just worked yourself into a homework assignment.
I was sharing this with some friends last night and the response was after you go through all of that how can one write a good problem statement? What’s a good problem statement? There’s one simple tip I’ll share, which I think you already know. The simple anecdote to all of these is the word “why” asked multiple times, asking why.
Let me close, for the next 10 minutes, with a little bit more about a process or an approach that I’ve used for the last probably 10 years to get to the real problem.
Some of you may relate to this. This may be how you work. For some of you, it may be a different way of doing things. I’ll start off with one thing I’ve never done and I’ve never gotten in trouble for it because the results have always paid off. I always ignore requirements and user stories and use cases and all these documents I get handed. I’ve never actually read through those or used those to start my work.
If anything, I come back to them as a gap check later on. Even then, I don’t like doing that, I’ll just ask the person who wrote it, “Did I get everything?” It’s just a waste of time, I find. Here’s why it’s a waste. You have the business stakeholder or the product owner. You have someone who has this idea and there’s the product manager, owner, or the requirements person like here’s what they think the person’s saying and they translate that into a document that’s usually text where a lot’s lost in translation.
That document gets handed off to a design team or a product team where you’re left to make your own sense of it and then you design what you think was being asked for in the documents and you can predict what happens next.
Stephen: I don’t like those situations. I’ve always avoided them and whenever I hear stuff I’m like yeah, that’s nice. This is the left. I go back to the first person and I say, “Tell me what you want. Let’s take 30 minutes. Let’s just draw it out.” When you do that and you draw it out, maybe you get all three of you in the room and you sketch it or actually create a high fidelity prototype on the fly, everyone’s happier.
Often I’ve found there might be something with 10 requirements and in the end, there’s actually seven requirements so it’s actually less effort and we actually get where the guy who had the idea in their mind originally wanted to go. Much better way. That’s ignoring requirements.
Second, keep questioning for clarity. Why, why, why. You may have heard of laddering or the five whys where you very tactfully, or delicately, ask why in different ways. Here’s a crude example because it starts with why. My wallpaper is peeling off so you might jump to conclusions and say the problem is how do I get the wallpaper to stay on the wall?
If you stop to ask, “Why is the wallpaper peeling off?” You might get an answer like the wall is wet. Why is the wall wet? The wall is wet because there’s a leak in the attic. Oh, OK. Now we’re peeling back things and getting to the root of the problem. The problem wasn’t replacing the wallpaper because you’d be coming back next week to solve that again.
You could go on. Maybe there’s a reason there’s a leak in the attic. There are leaks all the time, a bigger problem to fix.
Define the desired outcome. This is where you get to defining the problem. I actually is shifting away from using the language problem statement. I feel like even opportunity statement is too vague but problem statement is focused on the problem, a very near term. There’s a phrase I picked up that I started using recently. I say let’s define the desired outcomes.
What I love just about those two words, desired outcomes, is it shifts the focus to the intended effect of what you want to do. I have this document I won’t share with you, a prescriptive document, because it’s not about the document. The intent of this desired outcomes document or worksheet is to do several things. Obviously to focus on the outcomes, but then to shift the conversation to experiences, going back to our base example.
I find when you do this, you suddenly create a generative thinking space for the product team where you can explore many more options, many more interesting options. Obviously, I want to focus on value in this document, what’s the value, why are we doing this. Then when you actually get to a solution or solutions, you have an objective way to offer feedback.
You can say here was the outcome we wanted, is this accomplishing that outcome? Are the measures holding up? What goes into the document? Again, it varies per product team and per context, but generally I have these basic things. Who needs what by when? Even the when is optional but definitely the who and the what is important.
Why do they need it or why do they want it. Then I love this one, what are their conditions of satisfaction. That’s where we get specific details and things. Some of those things that were the problem are now conditions of satisfaction and we can talk about those and their importance in the context of the outcome. How will we measure success is attached to this.
If the who is a user — this is an important distinction — so you’re filling this out based on someone else’s need. I require that there be needs and insights in this document that drive the request or support it. This is to help avoid the fictional oh user wants to do this preposterous thing that we know they’ll never want to do. If you just use a typical who, what, and why format you can fill that in with all sorts of junk that doesn’t make sense so I like to make sure this is truth or there’s some verity to this.
It’s not the framework but it’s actually the content you put in the framework. Let me give you two examples that answer who, what, and why and you tell me which one you would prefer to design from. This example, by the way, comes from the Stanford D school.
A teenage girl needs more nutritious food because vitamins are vital to health. That was one statement. That answers who, what, and why. Here’s the better version. A teenage girl with a bleak outlook needs to feel more socially accepted when eating healthy food because in her hood, a social risk is more dangerous than the health risk.
Wow. That’s a much more interesting and in-depth problem to solve. So define the desired outcomes. Occasionally, you’ll end up with scenarios where the desired outcome of the business, like as a business stakeholder I want this and this is how we’ll measure it, and the desired outcomes of the user, we’ve observed the user wants this in our research or maybe there’s other people, I’m simplifying, that they’re at odds.
I’ll actually put these different problem statements or desired outcome statements on the wall and say let’s figure out how we can reconcile these, how we can bring them together to find that overlap or that sweet spot where there’s value for both people. That’s sparked some interesting conversations.
Now, you can actually start to get a little bit farther along into starting the transition into the problem solving. One of the things that good design teams really enjoy is constraints. I love constraints. Constraints give focus to the problem. What I hate more than anything are bad constraints or perceived constraints.
There’s a difference. Real constraints help you focus the problem. Perceived ones just drive you nuts and frustrate you.
Things like we can’t do that because of the technology or the VP would never approve that, that’s not a constraint. If you do find the technology can’t do it for some reason then yes, it is and you should factor it in. Let me give you an example of a perceived constraint, actually a myth, at a company I worked at long ago.
How many of you recognize what this is? How many of you work with clients who use a terminal green screen like that is your user? Several of you. Bloomberg, travel. This is from the travel industry. What I heard at this company I worked at, and this was common language that everyone knew, they had done research over the years and they actually heard from a travel agent, “You can pry the green screen out of my cold, dead hands” is what they heard. We love the green screen.
Whenever we talked about this, they’re like you can’t touch the green screen. It’s sacred. It’s off limits. We went out and did our own design research, our own ethnographic research and watched and listened and talked to users. What we learned was actually very different. What we learned was these travel agents can do amazing things with the green screen that no mouse or GUI will ever do.
They could book a multi-city international flight in 30 seconds. Amazing stuff. They loved the input of the terminal green screen.
What they don’t like is the output. They would love to have something on the output that has pictures and photos, has some information design, is more like Travelocity or Expedia, but don’t mess with the input. That was a completely different problem from don’t touch the green screen. We separated this myth of this half truth out.
There are other half truths. Again, our technology stack won’t let us do that, the CEO would never go for it. We tried something like that before. I hate that phrase. We tried something like that. Tell me. Let’s try it again. Maybe we’ll do it differently this time.
This next one’s subtle but oftentimes we design the problem very narrowly. I’ve found that if you can pull back and actually look at other problems or other complimentary projects, you can often find more interesting solutions. I call this the sandwich problem where you might see that multiple teams are all working at the same sandwich and you’re kind of at the center of it and you’re like we’re all working on the same thing. There’s easier ways to solve this if we work together.
If I’m remembering the case study correctly, this is the hippo used in Africa. Actually, it solved two problems. The initial problem that one team was working on was how to get more water back to a village. In these cases, you can see some of the photos here, villagers would have to go very far to the nearest water source and carry it back in these jugs and they had to do it on a daily basis, sometimes multiple trips.
Carrying it on their heads can be very unhealthy over time. They said how can we help this? That was one design problem.
There was another design problem also for villages in Africa which was roads and how can we get better roads and smoother roads. When these design teams pulled back and said wait a second, I think there’s a bigger design problem here, they came up with this idea for the hippo, which is actually a barrel that you can push and when it’s full it holds 200 pounds worth of water so when you’re rolling it back you can actually start to roll and do a little bit of bulldozing and create paths back to your village so you can start to create these roads.
It was two different problems that when brought together yielded a much better solution.
Step back and look for complimentary projects and, a theme I’ve heard over and over in conversations and talks this week, and people. A lot of things aren’t process or project problems, they’re people problems. Just having conversations, building those relationships.
Finally, rinse and repeat, learn along the way. You don’t define the problem statement up in the front and write it in concrete, it changes. You learn more and you refine it along the way.
My challenge to you is to be this person, the person that stands up and says stop, why are we doing this? What is the desired outcome? There have been some nice quotes that people have been ending on. There was a nice Aristotle quote I saw someone end on last session. I’m going to end on a quote from Sherlock Holmes. “Good. You’re finally asking the right questions.”
With that, thank you very much.
Stephen: There are some talks where I end it here and I don’t take questions because I framed a very careful argument. This is one that I love talking about and so I would love to welcome or entertain any questions you have and I do have books to give away to anyone who asks questions. Yes? Just come on to the mic.
Audience Member: I was thrown into a project and this is the problem right now is nobody knows what the problem is. I was thrown into the project. Bad blood, nobody likes each other, and here I am. Good team. The stakeholder doesn’t like the team, the team doesn’t like the stakeholder, so I’m the one who has to mediate this.
If that was you, how would you even start to look at this, reframe the problem, and try to keep the peace?
Stephen: There’s definitely a human problem going on.
Audience Member: Yes. The last point you made was not the project.
Stephen: Yes, and I glossed over that very quickly. Getting out of the office doing things together, if that’s possible. Maybe there’s some rank or seniority where that’s not. Definitely address the people problem and a lot of things will follow or work themselves out. Setting that aside for a second, that being very important, you’re working on a project and the project has goals, right?
Audience Member: Mm-hmm. The project has goals and nobody wants to address the goals. The answers to most of the things are just do it. Can we talk to users? We don’t have any, just do it.
Stephen: What are you doing would be my question. What are we building? What are we solving? You don’t have to answer, those would be my questions. There’s something you’re trying to accomplish. The business stakeholder wants to accomplish something, at the end of the day. The team wants the right thing to work on.
I would start with that problem statement or that outcome statement and figure out what it is.
Audience Member: I’ll tell you about the project later. You’ll like it.
Stephen: Yeah, let’s continue afterwards. Free book. Seductive Interaction Design.
Audience Member: I was just going to comment that the HIPPOs and CEOs are usually really type A, egotistical people and sometimes asking these questions yield really negative results. At certain companies, the chain goes so far up that you only get to talk to your boss’s boss at the best and they’re still saying the CEO would never go for that and you don’t get to talk to the CEO.
When you hit that wall, do you have any ideas or suggestions?
Stephen: That’s a really hard one when you have those chains of hierarchy. There’s a certain advantage to coming in as an outside consultant where it’s like we paid the guy to come in.
Audience Member: They’re paying you.
Stephen: They’re paying me. Being in the situation, you’re right, it’s very hard to work your way up. That person’s very busy, has as different set of priorities. If you’re going to get their time, if you’re going to earn their time, it’s very important to understand the language they speak, what’s important to them.
Audience Member: Learning how to speak in numbers sort of thing?
Stephen: Yeah, to some degree, or value. I always go back to value. What’s the value, what are we trying to provide. I’ve told people I’m not going to do this because it’s costing you money that you don’t need to spend.
Audience Member: At some point, walk away? It might be easier for you than someone…
Stephen: Yeah. The company I was at, it was dysfunctional with so much arguing you were just spinning your wheels. You can start off with documenting it and talking about the facts and hoping it trickles up, but, if after a while, it doesn’t, there are plenty of companies looking for good UX people. [laughs]
Audience Member: Hey, Stephen.
Audience Member: Have you found that there are some types of organizations or companies that are more or less receptive to this, say, private versus government or those sorts of classifications?
Stephen: I’ll be up front. I have not worked with government organizations. My experience is mainly big corporate companies or startups. That’s the level of experience. Like I said before, I think you do have a luxury coming as an outsider, whether it’s agency or consultant.
Audience Member: Maybe, then, I would change that to certain circumstances where they’re more or less receptive?
Stephen: It’s not always circumstances or culture. It’s usually the people and the personalities. That’s usually the biggest thing I’ve found.
Audience Member: Myself, as well.
Stephen: It would be the individual personalities. I think that’s it. Feel free to come afterwards.
Stephen: Thank you.