And what’s your most useless skill?

I’m really good at making sure that no Slack channel’s unread indicator survives for long.

Alright, switching gears. Appcues plays in an interesting space where your product is being used by your users and your user’s users. How do you think about both of those groups while designing?

Great question. I’ve run into the same interplay before working on other B2B products, like at Localytics. It’s unique because you’re part of a value chain, and part of your customers’ customer experience, which adds extra complexity and responsibility.

I like to handle this by making various models. The best way to tell you what that means is by passing along this great post from Christina Wodtke. Basically, like an architect might build a model of the building before the real thing, you can make high-level models of how your product will fit into the landscape.

The first step is research. For the B2B link, you have to do double—both your customers, and their users—and then think about what lines up across all your customers’ users to make coherent product decisions out of it. It’s not simple.

In the end, I like to visualize all of that abstract stuff so it’s easier to understand. In the past I’ve make a map on a single page showing bubbles with our product, our customers, and their users, how things connect, and what’s generally true of each group, which helps start the right discussions. It’s a challenge, but I also think it’s one of the reasons B2B design is so much fun.

Getting even more meta — how have you used the Appcues product to help new users learn how to use Appcues? What have been the biggest things you’ve learned from iterating on that over time?

Yeah, this is one of my favorite topics. We dog-food our own product as much as we can, and it’s one of our biggest sources of learning and experience.

We announce and teach all of our new features with Appcues, and by doing that we’ve learned not only how we use our own UI and how our users experience flows, but also in how our company handles the collaborative process of making them. I think it’s hard to get a feel for what happens outside software, and what I’m realizing first-hand is that there’s a lot of interplay between different roles and responsibilities even within our relatively small team, and that definitely makes me reflect on our customer experience.

The other thing we’ve used Appcues to do with great success is recruiting for our user testing and research. We have the highest success rate by far when we ask people in-app if they want to sign up; it just pales in comparison to emailing people, and the folks we get are engaged users who have great insights.

You guys just launched an awesome new resource — Really Good UX — what has been the most useful takeaway for your own growth as a designer through compiling all those examples?

I think it’s this: keep your eyes open. One of the core habits we have — the one that spawned Really Good UX — is posting any examples of UI we like that’s in any way related to what Appcues could do in a slack channel. This channel has been building up for years, it often gets multiple posts per day, and it’s become a huge idea board for solving problems in our wide UI space.

For Really Good UX, we loved that resource so much that we wanted to share it with the world in a really focused way. I love how blunt it is: it’s not about deeply analyzing UX or understanding all the research or the team behind it, it’s just about keeping your eyes open and your visual gears moving, and there’s something to that simple habit.

What is the biggest mistake you consistently see made across products in terms of how they handle onboarding for new users?

Absolutely positively one big thing: onboarding your product, not your user. I think the default take is that the user should know all the ins and outs of your software and how it works, but the first step isn’t knowing how it works — it’s convincing users to stick around to find out, and then guiding them through solving the problem they actually care about.

Users don’t care about your product or its features, they care about getting what they need done.

So, if your onboarding helps them get to their dream destination quickly and clearly, they’ll love it, and it’ll work. If tours are showing them every flashy landmark and turn-off on the side of the road that they don’t care about, then they’ll get annoyed and turn them off. It’s less about whether you use tooltips or pulsating dots, and more about what they’re focused on.

I think that’s the root cause of the annoying onboarding horror stories everyone has experienced, and we’re thinking about how we can educate our own customers better on foundational skills so we nip that problem in the rear for the good of the whole internet. Our blog is a great resource for this honestly — and we want the product to bring more of that content in. That’s the dream.

Back to some user research specific questions — what is your favorite “war story” from a user research session you were involved in?

I was pretty moved one time when I was interviewed myself (on the other side of the table, wink wink). The call was pitched as a user test, but when I got in it was very clear I wasn’t the right audience for the research, and the questions had nothing to do with my work or how I used their product. I could tell the interviewer was getting frustrated with me, we wrapped up quickly, and I felt so embarrassed and demeaned by the whole process.

It really underscored for me how treating your research subjects with empathy and understanding their environment and situation are so important, and not just to treat them like a vessel of information you want to extract — lessons I took into my own research.

There has been a big surge in “design thinking” recently, how would you like to see that trend continue to evolve?

I’m really glad that design itself is becoming more familiar to more people, and less of a black box. That’s what I want to see continue: for people to understand design as a working practical system rather than a set of magical powers.

Instead of a mystery art, I want people to think, how do I take all of what we know, make some good models, use them to get creative, and make something that’s working, valuable, and joyful? It’s hard to get to that point because there are a lot of moving parts and barriers and difficult-to-measure things, but I think more people can break it down and get it, and I want to keep encouraging that optimism that we can make this process work in many contexts.

In what ways do you deviate from the conventional wisdom around user research?

Including more people and more roles in the interview process. I’ve been in situations at past companies where the owner was fairly protective of the sacred research process (I’ve even been that person). At Appcues, there was already a pretty solid user testing and research process when I arrived that our CEO, Jonathan Kim, had set up, with a monthly “User Testing Day,” where the whole product and engineering team was interviewing users. It broke down my assumptions about what it means to be a user researcher.

It took some getting used to, but I’ve gotten to the point where it’s more about helping other people do better interviews and learn, than doing all the research myself, and that’s been a sea change. It’s no longer just about gaining knowledge, but also drives motivation and transparency and helps more people get a direct connection to users and problems. It’s a bit magic.

When I started trusting the developers more, trusting users to handle unorthodox situations (like an interview with 4 people on the call), things worked out even when I didn’t expect them to. People are flexible. I’m impressed at how well our team runs interviews, how smart and resilient our users are, and how much fun it is. It’s not perfect, but it’s easy to see that the upsides greatly outweigh the downsides.

What do you think is the biggest mistake people make when approaching user research?

Not forming a good connection or building enough empathy from the start. That part of an interview where you talk about the user’s background and experience and job or whatever profile fields you want to capture — it’s a huge opportunity. You can gain empathy and context, guide what you ask in the future and how you ask it, and build a rapport so the rest of the interview is multiplied. I think a relaxed, happy person who knows you have their back and aren’t judging them will get so much deeper on any topic.

My goal is to make an honest human connection with the person on the other end, and set it up so it’s all but guaranteed that you get truth and honesty just oozing out of the conversation. In my experience, that happens more often when I achieve a good connection early on. I fail to do that as many times as I succeed, so it’s not easy, but it’s worth shooting for.

After years of doing user research, what is biggest lesson you’ve learned? The type of thing you wish someone had told you about when you were getting started.

So many things, but I think the biggest one I wish I had been told when getting started would be, just to talk to as many users as you can.

Just do it.™

You can learn all the little tips along the way, but nothing takes the place of experience and practice. Drop all your fears and schedule 5 calls this week and just do your best, get feedback, mess up a lot, and try it all again next week.

Let’s wrap up with some quick hits. How do you like to prep right before sitting down with a user for a research session? Any habits that you find effective?

I love having everything all prepared (mise en place) and printed out or written on plain sheets of paper. I take notes and scribble all over everything. It’s like driving a car made in 2005 vs one made today — I want the 2005 one with all the physical dials and switches in the same place so I’m never fumbling and can focus on the road without looking at the screen.

What tools do you use during sessions? For interview guides, notes, recording, prototypes, etc.

Our interviews run the gamut from exploratory research, to specific usability tests, so we use a variety of tools based on what we’re trying to do. Paper is my thing for guides and taking notes, and for any printouts I try to stick to one page Google Docs so they print nicely and I’m not turning pages. For prototypes, often InVision, and sometimes for more interactive needs, raw HTML and Javascript. We use Zoom for remote calls, recording, and screen/mouse sharing.

How do you and your team document and share the insights you collect from user research?

The first is just our process: we get more people to participate. All engineers are listening to the calls and getting the insights first hand. Beyond that, we record all the calls using Zoom and have them all in one Google Drive folder to go back to, and I try to summarize conclusions and send out an email after our monthly user testing day. We also have Slack channels where I’ll post random things I heard on calls, or interesting notes.

One of the coolest things I did recently was to go back to a round of research I did three months prior, and listen to everything over again. I was doing it for a round-up presentation on the topic, but I learned so much I didn’t expect. I had a whole different perspective on what users were saying, and all my biases at the time seemed less important. Highly recommended.

Are there any tricks you use to make participants feel relaxed or more expressive during sessions?

I love this question, because I think it’s so important. I’ll double-down on what I said earlier about using the initial intro to build a rapport. I like to ask them questions around the basic questions to get them to open up a little, then make sure to empathize and relate. For example, I might ask someone, “what’s your role?” and they might respond, “I’m the VP of Product.” A good follow-up could be, “How did you get to the role you’re in?” or, “How do you like that role?”—any number of things just a little deeper. Eventually, you might land on something you can relate to and get passionate about — at that point you don’t want to hide it, but open up and genuinely relate.

I think the most recent time this happened was when I was interviewing a product manager and found out she was really interested in learning how we did user research (relevant) and that’s why she signed up, and we geeked out together for a couple minutes on that. It was easy to relate and made the rest of the interview more light-hearted and effective.

One other thought — you won’t get through to everyone, so if it doesn’t work out, don’t sweat it too much. It’s just part of life: there’s a ton of variation among people, and you can’t build a connection with everyone. This is one of many reasons to build a diverse team that can relate to and understand more of your users in a deeper way.

That’s everything. Thanks again for taking the time and I’m looking forward to seeing how you continue to improve Appcues (which, full disclosure, I use and love)!

Thanks so much! This was fun.

Need more? Follow Tristan Harward on Medium (or on Twitter).

If you'd like to be interviewed for Other Side of the Table, reach out to erin@userinterviews.com.

Want to contribute to User Interviews content? Here’s how.

Ready to launch a research project and easily recruit quality participants? Get started here.

‍