Transcript

Jared Spool: Welcome to the UX Immersion podcast, I’m Jared Spool.

Being a designer, leading a design project, means putting it out there, making the calls. Everyone expects great things from us. And, it’s scary. Very scary.

That stops us from doing the right thing. From admitting the truth.

Richard Banfield: We are so scared of being wrong, we’re so scared of saying, “I don’t know,” that we’d rather just not have the conversation.

I’m Richard Banfield, the Chief Executive Officer of Fresh Tilled Soil. I’m the guy at the office that everybody wants to avoid having in a conversation, because I’m the highest paid opinion. That’s not very useful.

Jared: Richard’s been studying what happens when people avoid these conversations. He’s found the fear of being exposed as a fraud simply by saying “I don’t know” and allowing for that conversation to occur, is very real.

For example, take how we start a project. The conventional approach is to create a list of requirements. More often than not, these requirements turn out to be assumptions. We’re just assuming our customers need the things that are in that list.

Richard: As my very good friend, Dave Cancel often says, “The worst thing you can do is make these assumptions, because none of us are right any of the time.”

Jared: Even though we’re not right, we continue the practice of listing out requirements and making demands.

A large part of the problem lies in the hierarchical structure of organizations. The higher you are in the organization, the more you’re expected to just know the answer. It’s good to be king, most of the time. Sometimes, when that fear of exposure rears it’s head, you don’t want to seem like the one who’s got shit all over them. Even when someone sits at the top of the hierarchy and is expected to have the answers, they can still be wrong.

Richard: The hierarchy may disincentivize them to talk to each other, but it also might be political. It might be that there are these victims that people are protecting, also protecting their personal space, their jobs, their titles.

In any system that has some kind of complexity or hierarchy, there is an inferred politic. There is a structure that decides who has the last word or who has the most say in any conversation.

In our organizations that we work in, the typical business, there is a hierarchy that is dictated to by somebody’s title, their longevity with the organization, their domain knowledge, their gender, their age. All of those things help people understand where they fit into those conversations.

Even in the most non-political organizations out there, there is still some kind of societal influence or cultural influence over the politics.

Jared: Politics exist anywhere there is more than one person. If you’re the sole inhabitant of your desert island, then your reign is supreme and everything you do pleases everyone, because, everyone is you. But, as soon as there are competing ideas from multiple people, they must discuss them to arrive at a consensus, and to evolve the those ideas. The trick is finding the right tactic to advance these discussions.

This is where design sprints come in. A design sprint is an alternative to the conventional requirements gathering process. The project leader brings a team together to list assumptions and validate them with real users and customers. The nature of the design sprint’s structure turns saying “I don’t know” into a good thing. This is because you just saved the organization the pain of going down the wrong path.

Richard: In some kind of accidental way, design sprints turned out to be this UN of design methodology, where you would just get people in a room together and you’d say, “Why are we fighting about this stuff? Don’t we all really want the same things? Are we not trying to make something good for our users, our customers, our marketplace?”

What the design sprint is structured to do or designed to do, is to avoid letting the people who have those big opinions, or as we call them, the HiPPOs, the highest paid opinions, to allow those people to be quantified at the same level that the junior person’s opinion might be.

If you’re the CEO, and you have a strong opinion about something, it will be leveled against the person who has no political strength or power. By doing so, you’ll start to see these things for the neutral arguments that they are.

What we’ve noticed, having done—I think we’ve lost count now—but let’s say 100 design sprints, we’ve noticed that even the people who have a strong opinion, like this idea, because even they know that their opinions are based on assumptions. They secretly don’t want to be found out either, that’s why they speak so vehemently about their own choices.

They also want to know that there’s a system that will validate the choices that they make and not just base it on assumptions. They’re just as scared as everybody else. This design process gives everybody the opportunity to feel safer. Even the CEO. Even the COO. Even the founder of the organization.

Jared: Organizations, as we know them, were modelled after the structure of a military unit, with a commander at the very top. Orders flowed down and were never to be questioned. The commander could never be wrong. That sows dissent in the ranks.

Modern day organizations have inherited this structure without questioning it. This is what gets us into trouble. Those people in charge aren’t any more right than anyone else.

Richard: Somebody recently wrote an article that was entitled, “The Hardest Three Words in the English Language to String Together Are, ‘I don’t know.'” Because we’ve got ourselves into this situation where we’re all assumed, because of our title and our domain knowledge, and the roles that we have, to have answers.

People come to us and say, “We’ve got this problem,” and we’re immediately assuming that they’re asking us to come up with a solution. Whereas, the right answer is to say, “That’s an amazing problem. I don’t know the answer. Let’s figure that out together. Let’s work on that together. Let’s figure out what the best solution might be.”

We just don’t have the confidence to do that, because we were told right from the get go when we start school, that there’s only one answer for something. You get given a math test, and the math test says there’s a right answer and a wrong answer. You get given an English test and there’s a right answer and a wrong answer.

We grow up with this belief that there are only answers. Instead of saying, “I don’t know, but here’s something else that we could consider.” Or, “Let’s talk about that and come up with the best answer.” We’re predisposed to think that for every problem out there, there has to be an answer and we’re supposed to carry that in our back pocket.

Jared: Freeing ourselves of the dependency of certainty really opens up the possibilities for solutions to challenges the organization is facing. There’s rarely just one way to accomplish anything. There may be preferred ways, or classic ways, but it doesn’t necessarily mean they are the best, or even most applicable for any given situation. Fostering a culture where it is ok to admit that you don’t know the answer instantly develops strong collaboration.

Richard: The thing that we notice most often is that once you’ve given permission to say, “I don’t know,” or, “This is an assumption,” or, “We should go and test that,” or, “These things that we’ve been basing all of our future roadmap decisions on, need to be made into facts, so that we can be clearer and less ambiguous about our future.”

Once that happens, it’s much more free. The conversation tends to open up. There tends to be less fear in the tone of that design or product conversation. That’s the first thing we notice.

The second thing we notice is that, now that they’ve been given an opportunity to work through a process and that process is familiar to them, they immediately start thinking about how else they can use that process in other parts of their organization.

Jared: Allowing yourself to say “I don’t know” is hard, but it is a skill you can learn. You need an environment that not only supports, but encourages it, so you can develop processes that assist in discovering the answer to what it is you don’t know.

Richard: None of my school, or education, or experience could have possibly prepared me for that. What I need is a system or a process that allows me to face that ambiguity with a whole bunch of confidence and say, “I still don’t know the answer, but I do have a process that’s going to get me to the answer.”

Jared: To create great designs, especially those that are innovative in the marketplace, we need knowledge we don’t have today. Knowledge about our users, about how they work, about what they need to make their lives better. If we don’t get this information, or we guess wrong, we’ll fail.

Admitting that we don’t know everything is what fuels our curiosity. Admitting it to ourselves is much easier than admitting to another person, or an entire team, especially when we’ve been designated the expert.

And for those other people we have to collaborate with, we also have to make it safe for them to admit that they don’t know everything. Structured activities, like design sprints, make that possible. When we create safe, collaborative environments, we open ourselves up to learn the things that make our work great.

That’s why we became designers in the first place.

The UX Immersion podcast is brought to you by the UX Immersion: Interactions conference, which will be April 18th to 20th in San Diego, California.

Richard will teach his full-day workshop, Leading Design Sprints to Jump-Start Team Collaboration. He’ll walk us through what it takes to facilitate a sprint, showing us all the techniques he uses to make the magic happen and kick start projects quickly. We’ve put a detailed description of everything you’ll learn from Richard on the conference web site, uxi16.com.

The UX Immersion podcast is produced by myself and Sean Carmichael. You can find more information about the UX Immersion podcast on iTunes and at the UX Immersion: Interactions conference web site, uxi16.com.

We’d like to thank Richard Banfield for being a part of this episode.

You’ve been listening the UX Immersion Podcast, part of the growing UIE Podcast Network. Thanks for listening and for encouraging our behavior.