Since October, 18F has been bringing in noted individuals from the software development world to discuss their work, and we’re excited to kick off a new, design-focused series this Friday, February 20 (10:30 a.m. ET). We’re inviting a number of influential designers to share their unique perspective with the 18F team, and with you.

First up in our series is the noted Steve Portigal. Steve helps companies strategically plan for user research and unlock their teams’ research superpowers. He’s the principal of Portigal Consulting, author of Interviewing Users: How To Uncover Compelling Insights, and host of the Dollars to Donuts podcast. He makes his home in the San Francisco Bay Area, where there's always a new ramen restaurant to check out. We’re thrilled that he’ll be joining us.

18F designer Nick Brethauer had the chance to chat with Steve about key aspects of user-centered design, including how to win over clients who are unfamiliar with the process and the importance of knowing your gatekeeper. Read on for the full conversation.

This interview has been edited and condensed.

Nick Brethauer: The main themes I’d like to talk to you about today are around client engagement and education, which are big topics here at 18F. To kick things off, how do you most effectively communicate to potential clients the value of user research?

Steve Portigal: If my clients are sold on the value of research before they come to me, then I know they’re at least curious about user research, and so I’m not typically overcoming skepticism. Admittedly, I've been in this business long enough that I've seen the idea of involving users go from ridiculous to a nice-to-have to a we-really-should.

That doesn't mean people know what the results of this research will be, and sometimes this is part of the conversation. Really, it's more interesting to me (not to mention more effective) to talk to clients about what they’re hoping to accomplish. I tend to talk about the business question (e.g., what are you going to do?) versus the research question (e.g., what do you need to learn?). Clients may have one or the other (or both) defined, and at various levels of refinement.

The third thing to consider, of course, is your research method. Ideally, you want all three pieces to align, although there's always a bit of discovery during the whole experience that will help clarify the elusive aspects (e.g., goals). Of course, you have to consider how these will evolve based on what you learn.

NB: Thanks — that makes a lot of sense. As a follow-up, how do you handle client education when your potential clients haven't had much exposure to these concepts, and might have varying degrees of openness to them?

SP: I work a lot with gatekeepers — people who are working as change agents inside their organizations. They may be people who believe in this approach but maybe can't articulate it or advocate for it as much as they’d like to. They give me the lay of the land, the traditional objections or enthusiasms, the players, and their history, and together we work on how to make the case — not just our approach, mind you, but also taking action on the approach. There is no one way to handle this, as the sources of resistance (and I'm reluctant to use that phrase because it frames things in an adversarial manner) vary and need to be assessed individually.

NB: On that note, is there a tried-and-true way to measure or test a potential client’s commitment to completing projects in a user-centered way?

SP: I'm intrigued by the user-centered theater — that is to say, people who have a design goal or a strategic need or a hunger for some insights, but who aren't open to collaborating on how to accomplish that.

You often see this with projects where a client wants to understand something enormously complex and nuanced, and they don't have any budget or time to do so. This is a big red flag. Sometimes, it’s worthwhile having a conversation to see if they [potential client] are open to feedback on their situation and on alternative ways to work.

In some cases, I’m pleasantly surprised; in many cases, though, I’m usually happy to pass on these projects. The kicker is that many of these folks have often already defined the method they want to use to reach their stated goal. It's foolhardy to try to help people who have set you up to fail.

NB: Do you have any recommendations for setting up client engagements so you and the client can have a truly shared understanding of how you’ll do your work?

SP: One piece of advice I was given (and that I try to use) is that you and the client should collaborate around the approach. We usually start by having a conversation, and then I'll riff about a possible approach; I'll put something down in an email but I’ll emphasize that it’s just a sketch at this point.

The goal is to basically paper-prototype your project approach. If you present an approach as a fully-baked proposal, you position your client to say yes or no. What I strive for is to have the client respond to my ideas and let me know if I’ve heard them correctly — if I’ve addressed their needs.

Of course, you can't control what they do with that sketch. Sometimes they pass it off to their boss, who I've not spoken with and who is perhaps comparing the sketch to something more fully-baked (that has either been iterated upon or is just put into a more sales-y format). In some ways, this project planning process is a longer and more rigorous form of figuring out if this is going to be a good collaboration. That isn't to say that going with my plan is the only way to be user-centered; there are lots of factors that go into choosing an approach. While I always think mine is best, I can't always persuade the world of that fact!

NB: Any final thoughts or advice on this topic?

SP: Even when there's agreement on an approach, it's easy to find yourself in a position where you are working with others who haven't signed off on the approach or only found out later the work is happening, etc.

It's great to kick off with stakeholders and talk to them about their expectations and the planned approach, but I still meet new stakeholders as the project moves forward. I go out into the field with people who weren't part of the process, and weeks into a project, I lead workshops with folks I haven't met before. This is where a good gatekeeper can at least help you succeed (if not manage those things on your behalf). Never overlook the importance of a good gatekeeper.

NB: Excellent advice — thank you again for chatting with 18F.

Remember to check back next week for a recap of Steve’s talk and a link to a recording of the presentation. If you’re not able to attend the event in person, you can watch our livestream from the comfort of your home or office. We’ll tweet a link to the livestream shortly before the event — follow @18F on Twitter so you don’t miss out. In the meantime, visit Steve’s blog for more great insights.