On UX research at start-ups and asking "why"

Rick Bond is a research leader who has conducted, scaled and evangelized research at Bay Area organizations including Quest Software, Dell and Uber. He recently spoke with us about how he builds the story for research within organizations and what it takes to be an effective design research leader, and how dscout plays a role in making research happen. 

dscout: You’ve done a lot of what you’ve called “research start ups.” What’s it like going into a company that does not already have a research team? You've been brought in, so somebody there thinks that research will add value, but do they leave it to you to convince the rest of the organization? How does that work?

Rick Bond: Going into a company where the research isn't done, but there's an appetite, it really comes down to influence or impact through utility—focusing on research that answers top of mind questions. If you go out and do an ethnographic study, you could come back with insights, but that might not actually resonate because they don't address specific or current business problems. It's a question of timing.

You have to initially come in and take a fairly pragmatic approach. You ask product teams and designers, "What questions do you have?" Then you dig in and maybe reframe those questions, but that’s your entry point, where somebody has a defined need and you meet it with useful insights. Then, once they've experienced that, you can get involved in foundational research and roadmap development.

Some designers believe that inspiration and ideas come from within them—the inspired genius. Others want to go to the user and get answers there. How does a research leader handle this divide?

I see a continuum. There are definitely the inspired designers who, through that creative spark and their own force of will, want to have their design built exactly as they’ve envisioned, and they’re not looking for evaluative research.  The people you want to start with are the designers who want feedback from users. They may say things like, "I just want you to put this in front of users." That's not exactly what you do, but the spirit is right, and you can build on it.

Putting things in front of users isn’t what you do?

You don't just put static images in front of users and ask them if they like them. It’s more effective to construct a prototype that simulates interactions, because that's what people experience, is doing things. Not just looking at things.

People talk about fidelity with prototypes. Visual fidelity can actually work against you, because things look too done and people are hesitant to criticize something that looks finished. If it's lower fidelity, for example, if you have a wireframe, that's a much better way to evaluate a concept. For people to understand the designer’s intent, they have to relate to the content; no lorem ipsum.

Evaluative research is just one method. With dscout I've conducted all kinds of studies, from exploratory through evaluative, depending on what we’re trying to accomplish. I've used it to create opportunities for serendipitous discovery, and—at the other end—to evaluate process funnels and touchpoints in secret shopper studies.

As you’ve moved into a leadership role, you probably don’t get into the field much. Do you miss it?

Yes, I do miss the hands-on work. When you grow a research organization, you hire managers to manage the projects and teams. As a result of that, my day to day changed. I haven’t been able to collaborate with researchers on projects, and I miss that.

But, I have to say that I do love building teams and helping those teams make an impact in the organization.

When you go into an organization to build a research team, is it pretty formulaic—are you doing it essentially the same way every time?

There are two models. You can have a service model, where you have a group of researchers taking on projects from different teams as needed. That works pretty well when you've got a small team; in fact, it is really the only way. The other way is the embedded model, in which researchers join product teams, sit with them, gain a deep understanding of the area, and become experts about their users, technology, the team, and the product.  

I hire a researcher and have them work within a specific team. They sit with that team and their job is that they're a farmer. They're an entrepreneur. Their job is really, again, to prove the value of research and grow that into a more strategic role. I support them in that, but they have to be entrepreneurs. They are farmers. As they can prove value, though, they become victims of their success and get crushed by demand. Then you need to find a way to work with the teams to help the researchers to focus on areas where they're really going to be able to make an impact, where their time will be best spent.

How do you help them to make, or coach them to learn how to make, those prioritization decisions?

By helping them look for research opportunities that are both important as well as urgent. Also by distinguishing research efforts that focus on building the right thing vs. building the thing right. But that can still leave out the foundational work, such as personas and experience mapping, so you have to find a way to fit that in, otherwise the focus is too tactical.

Objectives are important, since everything else goes off of that. But it's about the quality of the objectives, how they're stated. Like the term 'validate' is often used. Validate is a very biased word. What it means is we have a good solution, and we just want to prove it's good. That's not an open-minded stance. If you just do a word replacement and you substitute 'evaluate' for 'validate', everything changes. But I've learned not to be so picky about it.

That’s a great observation. Do you think your background as a writer is coming into play there?

I was a writer and editor before I got into UX. It’s a useful background for a lot of reasons. Surveys, for example, are deceptively simple, but it's actually one of the hardest kinds of research you can do. Unless you structure and word it correctly, it's really, really hard to know that the respondent is answering the question as you intended them to answer. You have to write your questions and the response set really well. But you may not know the range of possible responses. You have to inform that through qualitative research, but a lot of it comes down to just good writing.

Speaking of surveys, there was a lot of talk recently about how the election polls were off, and even researchers didn't know what was really happening outside of their own bubbles. Do you, as a researcher, see any need to make more of an effort to go outside your bubble?

As researchers we’re the ones who are outside the bubble, we're putting the pins in the bubbles. The morning after the election, I told my team, "This is an example of why we need people like you, researchers who actually go out into the field and really get to understand people and get the qualitative understanding needed to inform good predictions."

Is that what motivates you to do research every day: getting a sense of what’s happening with people? Or is it about informing the design? Something else?

I've been driven by the question, "Why?" in my career. In technology that’s about the interaction, the human and computer interaction, as well as the human-human interactions that the technology facilitates. Why are people responding or how might we get them to respond to a product in a way that's deeply satisfying to them?