We discuss the value of discovery as the first step in complex design projects with DesignMap Partner Gregory Baker and VP of Design Ryan Cornwell.
Greg: Discovery is the process of uncovering the information that’s hidden. To better understand so you can make better decisions. But when it comes to designing a product some clients don’t notice or appreciate the amount of complexity, they approach a project with unchallenged assumptions. As such they might not value or invest in discovery like they probably should, and as such they ultimately don’t get the results they hoped for.
Ryan: When we first approach a business, or a product team, we do so with an appreciation, or expectation, of the projects inherent complexity. From experience we know that there is key information, insights, and perspectives that are hidden. We appreciate that with complex systems no single person understands the whole.
And that’s what we mean by discovery—it’s not about simplifying this complex system, which is impossible—it’s about getting lots of different insight, and building a shared understanding of the system so that has a shared language about it. And can talk about it, and make plans around it, and all be on the same page.
And then, yeah, there’s a process of testing ideas with customers, and iterating, and all that. But that comes later.
How do you approach the process of discovery? Especially as consultants coming in from outside. Where do you start?
Ryan: We start by talking with the contacts that we have, which might be only a few people, or just one person. And we rely on them to give us information and more sources of information.
And then as we start going through the process we'll start to uncover other things and ask, can we add this person to the process? How about this other person? Can we talk to these customers?
Greg: The important thing is to work to get as wide a picture as possible of all the pieces in the system. Who are the people? What are the ideas and concepts? Get all of the puzzle pieces out onto the table. Worry about that first. Then later, figure out how they all fit together.
Because it’s hard to look at one piece or a couple pieces and figure everything out. That’s so freeing—it means you are freed up from the blank page problem. You don't sit down and try to make like the perfect model of the thing with limited information. You first collect the pieces.
Ryan: We want to make sure that we have a good grasp of the big picture before we move forward.
So we gather these pieces, and there’s all sorts of ways to do that. We put sticky notes on a wall or record a conversation, whenever. We capture ideas, and that has to be put down as the puzzle piece on the table. And then you see connections. “Oh, these five are all part of this theme. Clearly, they're all related.” It’s a process.
We talk to people, and what we're doing is we're drawing out ideas, concepts, facts. We want to gather as many bits of information as possible.
Greg: Obviously a big part of what we’re doing is solving a design problem. But there’s an organization problem too.
This is kind of the first taste of that project, typically.
Because at first, you have a bunch of people with different perspectives and assumptions and ways to describe things. And if you don’t create a shared understanding and language, you’re not going to get very far.
You have to find the stakeholders and you have to foster communicate and get input. We talk to the executives that care about the project, get them exposed to the engagement that we're helping with. And there’s a natural progression from that— they’ll tell us where to go for details.
Ryan: What we’re trying to do is identify is the underlying truth of the system. That doesn't just mean technically how the product or the organization is put together. It’s not a technical thing. It’s like we're trying to uncover the foundation, the ideas that everyone understands to be what’s true.
Also it’s important that it’s not just asking about the product, or the user experience. We have to talk about the business, we have to understand the dynamics of all the the team and the organization. The customers. Everything that’s going on there.
Greg: Right. In some ways, it’s like analogous figuring out the information architecture. At first we want to figure out these larger strategic company goals.
If you jump right into the product, if you do that too soon, that’s when things get really messy. People can work on a feature and nobody’s talked about why the feature exists in the first place.
Is it a temptation to just just grab a piece, maybe because you feel like you understand it, and then start to focus on it? To gain a sense of control?
Ryan: For designers just starting out that’s sometimes true. I’m not sure if that’s a temptation for us any longer.
Greg: I think it was when I was started. Because it feels good to feel like you’re executing, like you’re contributing.
Ryan: Early on, it is something you need to to learn. With experience you learn that the first step is has to be the strategic element. Then comes the implementation or more tactical stuff.
That second part, the tactical execution, is all about the “what.” What does this button do, this other thing, whatever. Discovery is all about the “why.”
That’s why discovery has such value for us and our clients. The type of work we do is getting to this consensus. It’s not “do this button because I told you to do this button.” It’s gaining an understanding and an alignment across the entire team of the why we are building something in the first place. That’s really what discovery helps unlock.
You mentioned the temptation for inexperienced designers on to just skip the discovery and get to work on the execution. You work for clients — executives, product leaders — that aren’t experienced designers. Do they get impatient? Do clients think that discovery is a waste of time?
Ryan: Sure. It happens. Clients sometimes say “well, we don’t want to pay you to do discovery! We want to pay you to do work.”
But the ability for us to do any work is founded on discovery. Which is to say, before we can do anything, we have to do this thing we call discovery.
Each the stakeholders have a small piece of the overall puzzle, we need to get all those pieces and put it all together, we need to get everyone around the table to look at that picture and point at it and say, Yes, that’s correct. We need to validate all that, before we do step one of offering up any sort of solution, because we want to start on grounded assumptions.
Greg: Some people have perceptions that designers are just big pencils that you hire to draw. That we aren’t about research, we execute. But executing by itself is not good design. You have to do both.
You mean that some clients tell you what the product is, and they want you to make it sort of prettier. They don’t connect the process of discovery with what they're trying to get out from what you're doing.
Greg: Yeah. And I think they may think that it really is just knowledge transfer, we need to understand what they understand so that we can get to work.
But it’s really bigger than that. We do need to understand their perspective. But more, we also need to understand the perspective of the other five people that they’re not talking to.
We need to understand all of those pictures and how they come together. I think it comes back to the definition of user experience design. We try to educate people about what that is, and how discovery is research. It’s central. But not everybody accepts that.
Ryan: Yeah. If there’s an objection, if a client says “you’re going to spend four weeks just getting up to speed? What’s that all about?”
There’s a pivot where we can say “Okay, if you bring a new employee into your organization, how long does it typically take to onboard them and get them ramped up? I think that’s generally more in the time span of two to three months, if not longer. And we could say, by contrast, we get to understanding in four weeks.”
Does that work? What’s the best way to help people get on board with the discovery process?
Ryan: There’s a shortcut that can help with this. You do a stakeholder interview with them, and play that interview back to show that you understand. It’s amazing how powerful this is. Suddenly, they feel “wow, these guys really get me.” Now they're on board.
And they see that discovery isn’t something that comes before design. It is design. A fundamental part of it.
Ryan: It’s mandatory. We would not engage in any kind of project that didn't involve some amount of discovery.
Greg: Not all agencies feel this way. For years I’ve talked to interviewees considering joining DesignMap. And we describe our process, describe how much time we put towards discovery. They are sometimes surprised. But we believe it’s fundamental to doing the work.
Ryan: Another agency might come into an organization and say, “we’re gonna get screens for you by the end of the week.” You should be suspicious of those pitches.
There are agencies that don’t consider discovery important?
Greg: To be fair, I would say that everybody tries to understand what they’re doing. It’s about how many steps back are you taking.
At DesignMap we always try to take a step further back and take a bigger, wider purview. The really tactical guys may be trying to understand the way the developers need to receive a design. For us they're not going back far enough. We think discovery is about extracting the fundamental business value for a client.
Ryan: It’s hard for us to believe that we’re providing the greatest impact, the best value, the right design, if we skimp on discovery. You can skimp on discovery and make something look good. You can. But it might not be what the business actually needs. We don’t want to do that. We want to give our clients real value.
There must be a point of diminishing returns. Eventually you have to execute. How do you know when you’ve discovered enough to deliver maximum value?
Greg: There’s no algorithm to tell you, no bell that goes off or whatever. You feel like there’s a sweet spot. Usually that happens when you integrated all of the relevant perspectives into discovery.
You have, for example, involved a business person in discovery, and having somebody help us do discovery about the technical aspects, development capabilities that the company has, the state of their product development, that sort of thing. Plugging diverse experts into our process make it even more impactful.
Is that the most important thing? A diverse set of participants?
Greg: Sure. We couldn't do this in a vacuum. We're facilitators, we help clients through this process. A big part of discovery is helping the team make good decisions together.
That’s some of the benefit of having somebody come in from the outside. We can say “This is not ours, guys, this is yours. We’re here to help you all.” So I think that that’s, that’s critical.
Ryan: We get the best results with a strong and broad level of participation. We benefit from that ongoing feedback loop to make sure that we're course correcting, that we're retaining the alignment, and that we're all going towards, towards the right goals.
Greg: Also, the other thing that we bring to the table is we are designers. We can make ideas visible. We can bring form to complicated things in a way that lets our clients understand much better than they could reading a 100 page white paper or some presentation.
We can play things back and get people to look at them differently, and get them to agree on the best decision kind of going forward.
Can you talk about what are the challenges within discovery? When you feel that there’s a roadblock, that somehow the discovery process isn’t being as effective for whatever reason?
Greg: The biggest challenge is the scope of discovery that the client will accept, and our feeling that more could be done. We're on a project right now that’s planned to be about four months long, and 25% of that is discovery. Percentage-wise that’s a lot. But I’m confident that we could get tremendous value out of doing discovery for the entire four months.
The more we learn the you know, the better we're going to do. It’s hard to predict accurately like what the diminishing point of return is on discoveries.
But there’s no sort place where you can say “Ta-da! It’s done!”
Ryan: Ha! No. It’s not like a binary state like that.
Greg: The context is that we want to be really effective. Not just efficient, but effective. But we can’t do discovery indefinitely. This is some of the value of working with a consultant is we are in a time box. We have to to do as much as we can within a strict limitation of time.
It’s almost like a psychotherapeutic process. Like couples therapy. Some couples fight all the time. Have you ever had an experience where you have people to clients, and through the discovery process, sort of strong disagreements? What that truth is?
Greg: Certainly, I have. Usually when that happens we are talking to people who think that they are building a product for themselves. That’s an age-old user experience designer challenge - getting people to understand that they are not the user.
Ryan: I have often seen, just shifting to using personas can be a way to unlock and open up people’s eyes. Even the most diehard stick in the mud who says “I can tell you, that’s not the right feature.”
You develop personas, you run them through a few examples of user testing, where they can hear these real people saying things. Before you know it, you find these people talking using the persona, “You know, Mary wouldn't do it that way.” That’s when you know, you've turned them.
As external consultants what is the benefit you bring to the process?
Ryan: The outside perspective we bring is really important. We’re removed from the day-to-day and we see it as a benefit to be at a remove, because it’s easier to take more into account and view the situation objectively. Having an objective view is not something that is typically easy or even possible for an internal team to do on their own.
Internal teams are typically focus on taking care of the day to day—design teams, product managers and executives are keeping the lights on, keeping the stuff running day to day.
We can come in and work with them to uncovering the big picture, to look beyond the day-to-day.
More than people focused on the day-to-day, I imagine there’s also a certain blindness that comes with deep familiarity with with something you just stopped noticing things as much that you know, sort of fresh eyes would would see pretty readily.
Ryan: Yeah. There’s this metaphor about that; “if you’re inside the jar, you can’t read the label on the outside.”
Greg: There’s another thing about being on the inside is that internal team members might feel like they can't ask certain questions, that it might make them look dumb.
We have that license when we come in and say, “excuse me, this is a dumb question. But how are these things related or different?” And we have the freedom to do that, because we’re coming in fresh. We can ask those kind of naive questions that maybe no one else’s been asking.
And many people are kind of relieved and excited to hear somebody asked it because they've been wondering about themselves.
Greg: Or they realize that they've all assumed an answer. But they might all have different answers, they all have different pictures in their mind. Because they’ve never shared. Right? So now people can't compare options.
So, you’re revealing these hidden truths and ideas. Do you find something unexpected? Does it happen that client will say, “wow, I never thought about it like this before.”
Ryan: I think that happens pretty frequently, actually. Our clients are incredibly intelligent and skilled people, and we give them space to step back and get an objective look at the big picture. Few people have that luxury, but we come in and enable that.
So you know, it’s pretty often that will like illuminate something. Sometimes it’s like a massive thing. Sometimes it’s just a small thing. But I think that’s part of the discovery process is we’re going to discover things that these people have not been able to discover for themselves.
If we are walking through preliminary findings and the stakeholder just nods and says “I expected that” then we’ve probably done something wrong. We haven't gone far enough.
Discovery assumes that there’s something great to discover. But maybe there’s not. Do you ever come to the view that the entire starting brief is a bad idea?
Greg: I don’t know if we’ve ever said “Do you know what, this is not going to work, guys, we’ve discovered that this is a bad idea.” In our experience there is some positive form of intent when we are engaged—discovery won’t dismiss that intent, but it will focus it and make it more relevant to business outcomes.
Ryan: There’s a notion of validation, which means that the client is asking us to say why this is okay. They aren’t asking for us to prove it works, or it doesn’t work. When we’re brought in, we’re given a charter, and we have to make it work.
Greg: We can’t escape the gravity of how we were brought in. There’s an inherent formula about the organization, there’s the company, there’s kind of the revenue or their investors, and there’s some really tight correlation in there. It constrains the space that we can be in. We’re not going to tell them that they should stop doing business or change their business.
Some of the projects you do are specifically about testing an idea. The charter is to find if the business is worth going after.
Greg: It’s kind of inaccurate to think of this as a pass or fail thing. With any idea there’s infinite directions you can go, and discovery is about exploring that space.
Ryan: A friend is working on an app, and these are important questions we can help with. Why are you making this product? Why should it exist? And why does anyone want to use it? Discovery can help build answers to these questions, but there’s also ultimately a market validation that you can’t research yourself around.
Greg: Discovery isn’t about proving there’s a market. It’s about reducing risk as much as you can. And then there’s only one way to prove there’s a market, and that’s by getting into the market.
