Natalie Hanson

Sharing & Communicating User Research

Posted on April 5, 2019     Leave a Comment

This blog post is a transcript of a podcast / interview I did with Zack Naylor, the CEO of Aurelius. From their website, the episode highlights are:

• Differences between in house and external UX teams and the unique challenges of each
• Tips for collaborating with others on your user research work
• How to encourage non-designers and non-researchers to collaborate on user research and insights
• Tips for working with stakeholders who believe they already know what needs to be designed
• Effectively communicating user research insights to inspire action from executives, developers and more

A transcript of our conversation follows, but you can also listen to the full podcast on the Aurelius site, if you prefer.

---

Zack Naylor: Hey, there … Zack Naylor here, co-founder and CEO of Aurelius and your host for the podcast. Our next episode is with Natalie Hanson. Natalie is a UX professional and trained anthropologist. She currently leads two distinct UX teams, one in-house and one client facing at the company, ZS. She has also run anthrodesign since 2002. Natalie has a ton of experience in doing user research and design with both external clients and internal teams at, in-house roles. You can just tell by the way she discusses design and research that she’s seen a lot and has success in our industry.

We continue a long-running theme of our podcast with Natalie, where we discuss the importance of UX and research folks understanding business better to be more effective in their role. Natalie shared some tips specifically on how to learn about how business works, and then how to collaborate with business stakeholders and executives more successfully. Natalie and I had a conversation, pretty focused around user research, and specifically how to collaborate with others in doing that work.

This includes executives, developers, QA and others. We had a chat about the best way to involve other people in user research work and how to best share those findings and communicate the value of research insights to the work they do. Our discussion with Natalie on those topics got me excited, particularly with some new features, we released in our very own user research platform, Aurelius.

You can now share any and all of your user research findings and data right from Aurelius using our new collections feature. And they don’t even need an Aurelius account to view them. We’ve had a few customers already, tell us how huge that’s been to quickly answer the question, from a stakeholder … What do we know about or do we have any research on, fill-in-the-blank.

Aurelius is a user research and insights platform to help you organize, search and share all that customer research and feedback in one place. We’ve had a lot of very cool new features recently launched, and we’ve extended our free trial to 30 days. If you’re interested, head over to our website and check it out for yourself, http://www.aureliuslab.com, that’s A-U-R-E-L-I-U-S-L-A-B.com. Okay, here’s our episode with Natalie Hanson.

Welcome to Aurelius podcast, episode 36, with Natalie Hanson. She’s a UX professional and trained anthropologist who leads two distinct UX teams at ZS. One is an inside team with the company and another which is an outside consultant team. Natalie, welcome to the show.

Natalie Hanson: Thanks so much, Zack. Happy to be here.

ZN: Definitely. So, as we typically do in beginning each episode… For those folks who may not be familiar with you and your work, maybe tell us a little bit about the things that you’re doing recently and some things that you’re sort of thinking about or on your mind?

NH: Sure. So, I have long-running interest in interdisciplinary collaboration and so that’s the thread that runs throughout my career for the past 15 years. And I hope we get to talk a little bit more about that, but that is instantiated in this group that I lead called, “Anthrodesign” which is an online community, both a Listserv and a Slack for people that work with ethnographic methods.

And that’s caused me to think a lot about how do we make interdisciplinary collaboration better, is something I’ve been thinking about. I just recently wrote a paper about that was published last year in the Journal of Business Anthropology. So, that’s sort of a long, sort of an underlying theme in my work over the past years, but I think there’s a lot of super-practical things that many of us have contended with in UX.

In the recent years, how to deliver UX effectively in the Agile environment for example, on the product side of the team that I lead. And then on the consulting side, it’s always the question of value. How do you articulate the value and the impact of the work that you’re doing to your clients? And so, always thinking about how do we help explain what UX is? How do we help explain, why it’s worth investing? So, those kinds of conversations about value impact and measurement are the things that really I focus on, on the consulting side of the business.

ZN: Sure, that makes sense. I’m curious, Natalie though, with you mentioning that… Do you find this is also still true that teams, in-house teams are struggling with that communicating the value and “selling” UX and research?

NH: Absolutely. Prior to ZS, I was at SAP, which is a giant software company, and I went through a similar evolution of having an internal team that grew to be more and more strategic over time. And I think the difference is that you have a similar set of stakeholders over many years. And so, that trust and that respect and that appreciation for what UX does is something that you can build on over time incrementally.

And so, I tell stories for example … Times in the early days of internal work where you’re asked to just help re-skin a website, or help apply brand colors to a website, or help with a little bit of light content editing or some content analysis. And for clients, we would do that, and then they would say, “Hey you know, could you help us maybe do some interviews or validate that … that you’ve put the right stuff on the website, or do some usability testing?”

NH: And then eventually, we built enough trust and respect with that client that we could do ethnographic research. And then, in years three or four of that relationship, they said, “Hey, you know more about our team over time than we do, will you come to our strategic planning meeting and share what you know and help inform our strategic plan for the next year or two?”

And so for me, there’s a continuity that comes with internal work that allows you to sort of build that trust and credibility and respect over time, and I think with clients, it can be just harder because you’re working within annual budget constraints and so on. Maybe make it a little bit harder to get in the door for that consistent … for repeated experiences over time that allow you to establish that credibility.

So some feel there are firms that are successful … I think of ReD Associates is a great example. People know that what they do is ethnographic research. And so, people go to ReD for that purpose. That’s great, but a lot of us, that’s not necessarily how our clients come to us. They want something simple, and we build into those more complex, more high investment projects over time.

ZN: Yeah, for sure. I’ve made that argument as well for a while when I spent some time in the services world as a consultant, that those projects are rare because you need to find somebody who’s willing to trust you up front, and by all account there’s no reason why they should to be completely blunt about it, right?

NH: [chuckle] Right.

ZN: They’re hiring you to do a job, you don’t know anything about their company, and that’s… It’s irrespective of the fact that you’re probably very good at learning quickly about their company. It’s a huge barrier to entry for sure. And I think a lot of that really comes back to them trusting you to do research that will inform their decision-making. That’s tough, right, to hand off that trust with somebody you don’t know that well and haven’t built a relationship with.

NH: Absolutely. Yeah, in a lot of cases, this may be a career-defining moment for them and they want to put that in the hands of somebody that they know and they’ve had that experience with … One of the things I would say that’s maybe different about ZS … In our case, one of the things I like about being a UX team sort of embedded in a big professional services firm is that we have very longstanding relationships with clients.

We work in healthcare, we work a lot with pharmaceutical manufacturing companies, for example, and with medical device companies as well. And with those clients… Some of them have been clients for 20 or 30 years. And so, while I might not personally have that long history, we as a firm have established a lot of trust and credibility, and that enables me to get in the door with more trust and a stronger starting point than I would if I was truly starting from scratch with that client relationship.

ZN: For sure. For sure, that makes sense. This tangentially brings up something, I did wanna ask you about which is just this idea of using research as a means for collaboration. And I know that this is something that you’re passionate about right? You’ve written about, and you’ve certainly shared thoughts about… Let me just ask you, I’ll try to be very lawyer-like … do you believe [chuckle] user research helps people collaborate around problem-solving, decision-making, etc?

NH: Yeah. Well, I personally do because I’m an anthropologist and I’m in this field. So, I’m passionate about research as a way to solve complex problems and to create alignment around challenging issues that we might be trying to solve for a client or a product market, an area of the market.

NH: I think where I feel as a discipline, we get into trouble with UX is that not everybody necessarily feels the same way about that. And so, we know that “Hey, if you really got a chance to sit and watch this user flail around with the software that you designed badly, that should evoke some kind of empathetic response that encourages you to make it better.” But I think there’s a lot of assumptions in there, and there’s a lot of our own passion that sort of masks the reality.

NH: The thing that I’m noticing more and more and the things that I’m reading about collaboration is that we as UX professionals actually aren’t particularly empathetic towards our own teammates. People chose the field of engineering. Maybe because they’re passionate about writing code or writing super clean code or those topics are things that they’re really passionate about. They may not really have any interest in people or human behavior and …

NH: And I know that sounds funny, because you think “Okay software is for people” but that’s not what the passion is, in engineering. And so, I think one of the mistakes I think we make is assuming that everyone wants to understand users, and user behavior and that it would naturally evoke empathy and people that participate. And then the last thing, and I think is the final sort of fallacy in all that is that if an engineer watches the same thing that an anthropologist or a psychologist or a design researcher or a designer watches that they’re gonna see the same things in that research session that we see as trained ethnographers or trained researchers.

NH: And, I think that’s just such a huge mistake. And one of the things I’ve talked about elsewhere, is this idea of the ‘Ladder of Inference’ which is, you can look it up, it’s very easy to find, and I can give you a link to some things to read about it, but the idea with the ‘Ladder of Inference’ is that when we observe something, we immediately start to make meaning about it. And if our history is different, if our racial and economic background is different, if our academic training is different, if our lived experience is different (which it always is), we will inevitably come to different conclusions when we see the same thing.

NH: So, one of the things that I talk about is this idea that we have to step up the ladder of inference together as a team if you want bring the engineers along (assuming the engineers are interested). And so, for example, one of the stories I like to tell … one of my mentors, Brigitte Jordan, who has been an anthropologist and worked for many years at the Xerox PARC. One of the things that they did at Xerox in their inter-disciplinary teams is they would watch the video together from some interviews or some kind of session that they had done and that they would actually do the analysis together, as opposed to just saying, “Hey, let’s watch the video.” But they would pause it and say “Here’s what I see, what do you see?” And even just in that one moment of video, they might see something or it might make them think about something related to the code or the staff or something like that, that an anthropologist doesn’t see.

NH: And so… Even just sitting together to watch a video or a usability testing session, I think it’s a mistake to assume that everyone is gonna come to the same conclusion when they watch it. We’re so focused in UX on creating empathy for users. And I know that that whole term has just been so co-opted and overused, but I think we really need to look at the lens within our team and even though we’re exasperated sometimes that an engineer might not understand or might not care about human behavior. We need to recognize that that’s okay, that’s part of what makes the team strong. No one is expecting you to write code, right? And so, if they’re not expecting you to write code, or to see their code, just be realistic about how far into your space you can expect them to come.

ZN: Right. That’s great. So there’s a lot I wanna unpack there, but something that I didn’t expect to comment on that I wanna do so quickly though, is that when you talk about having a team of people who have different socio-economic backgrounds and lived experiences, just as a quick note which I think is important to pull out, that’s why it’s important to have a diverse team.

13:40 NH: Absolutely.

ZN: Period. Right? So I just wanna lay that out because that wasn’t a place I expected us to go. But we have to talk about that, and I think it’s an important and relevant topic recently certainly.

NH: Yeah. Inter-disciplinarity is ultimately about diversity too and when I think sometimes, “Hey, why does UX bring a unique perspective into a particular problem?” And sometimes I wonder if it really doesn’t have to do with the discipline of UX at all, but the fact that we’re in a sea of engineers at least in our case, we are … that’s been true for my whole career. You’re in a sea of engineers, but you’re coming as an anthropologist or you’re coming as someone with a degree in human factors and just your world view is different because of your training, and it might not necessarily have to do with that. Your education itself, but just you’re a different kind of person than someone that went through an engineering program. And that diversity alone brings a different kind of rigor and novelty and problem solving to the opportunity that you’re working on.

ZN: Right. I think that’s absolutely true. So with that, the other thing I wanted to mention based on what you were talking about is it’s also very near and dear to me, in fact, because I’ve been giving a talk pretty centered around this topic actually, of you’re assuming that things that are important to you are important to other people.

NH: Yeah. [chuckle]

ZN: And in your particular case, you’re talking about it very inwardly-focused which is to say you’re assuming other people care about our customers in the way that we do. And I agree with you, it seems weird to suggest that’s not true, but guess what? In fact, the majority of the time is, it’s true that very thing is true.

NH: Absolutely.

ZN: And I think it’s myopic, to assume that everybody else has the same set of values and priorities that we do, because that’s not true in life. So why would it be true in business?

NH: Right yeah, and I think this is one of those places where you may have read Leah Buley wrote a really interesting article when she left Forrester, many people have talked about this before, and since. That article I thought was super compelling. She wrote on Medium about this idea that UX people aren’t going be effective until we understand the business world, and it’s not necessarily about going to get an MBA or understanding finance, or whatever it is, but if you want to evoke some kind of response in an executive, you’re trying to get them to change their product direction or their go-to-market strategy or their experience strategy or whatever, it is, you have to understand what drives them, and that means understanding how they measure the success of their business.

NH: And it doesn’t, like I said, it doesn’t mean you have to have an MBA but that’s also a form of empathy, right, is to say, “Hey, what kind of experience can I give to this executive that’s going to help them think about their business in a radically different way?” And it’s not just pulling on heart strings or getting the kind of insights that you need in order to drive change from a design point of view, it’s really about evoking the kind of experience that’s going help them think about changing their business. That’s something that has to be crafted and thought through and not just sort of assuming that if someone sits in a usability testing session, they’re gonna have a transformative experience about how to change their business model.

ZN: No question, I could not agree any more strongly with everything you just said. In fact, so many of our guests have said something very similar around this topic, it’s almost become a central theme that underlies a lot of the conversations we have here on the show, and I think it’s a good thing because I agree with you, that it’s something that as an industry, all of us need to get better at. So this was a thing for a long time … Why doesn’t design have a seat at the table? And it’s like, that’s like throwing a tantrum. That’s just like saying well…

NH: Totally. [chuckle]

ZN: We should be included because we believe we should be included.

NH: Right exactly.

ZN: That doesn’t speak at all to the benefit to others, of including us. And it’s the same thing with design as an applied practice or research rates, I consider them all in the same when I say that. That’s absolutely true. So we talk a lot about research and you and I have and expect we will, and this is actually a place where I have felt very strongly research helps. And let me clarify what I mean. If you can do a pretty good job at understanding your business, your stakeholders, the people you work with, then you can help them understand what questions they don’t have answers to. Now you see where I’m going with this right is because then we can show directly how our expertise as researchers helps them get answers to questions they want to answer so that they have confidence in making actual business decisions. Now all of sudden what you’ve done is you’ve linked everything up, right? You’ve said, “Well this is exactly how design and research helps you, benefits you.” Not just because it’s great for our customers, which it is, but that’s your job, that’s not their job. Their job is to make it great for the business. And you’ve now helped them directly link that up to how design and research benefits that.

NH: Yeah, absolutely. Yeah, it reminds me, again, coming back to ReD, I did an interview with Christian Madsbjerg, who’s one of the co-founders of ReD Associates; this was a couple of years ago, and he had a book that came out called, The Moment of Clarity, which I just found super compelling and really, really enjoyed it. And one of the things that he said that really struck me is that when they do their research, they are obviously doing ethnographic research of all kinds. They’ve been behind the transformation of Lego and they’ve worked with Adidas, and so many companies, really, really amazing case studies that they have to share.

NH: But one of the things that Christian said that really struck me in that interview was he said they put a lot of energy, almost as much energy into understanding the internal discourse of the corporation that they’re trying to serve as they do looking at the market. Because that internal discourse, how the company understands themselves, what the barriers might be to change, that lens is as critical for the success of the project as the understanding of the market itself. And I think that’s just such a great point. And I don’t think we do that particularly well. We don’t necessarily think of our client’s business as the site of inquiry. We’re enabling them to understand their market, but not necessarily expressing as much curiosity about their business, and how their business operates, and what might prevent change from being successful, and maybe we should.

ZN: Absolutely. Again, I think it’s nearsighted to assume that people want to care about research insights. [chuckle] Just because we know that that’s compelling for the work that we do, that does not translate directly across other parts of your organization, right?

NH: Right.

ZN: So then the next question has to become, Natalie, how do we do that? [chuckle] How do we do that well, how do we collaborate around those things so that we can get other people to care about that?

NH: I don’t wanna say it’s not an appealing answer, but it’s not necessarily what people want to hear is that it’s … honestly, it’s just super hard work. You can’t just say, “Hey, let’s invite our engineers to usability testing and then it will all be better.” [chuckle] It’s what I described, it’s you have to invite them to usability testing, you have to understand maybe what they care about learning, or why they’re even showing up (if they’re showing up at all). And then taking the time to really step through and develop shared meaning from that usability testing instead of assuming that miraculously they’re gonna hear the angels singing and they’re gonna have a UX perspective by sitting in one usability testing session. I think it’s just … it really is just the hard work and the investment of time, and I think there are people, other people that have talked about this, too, at the Design Ops Summit, for example. Holly Cole, for example.

Investing the time in understanding your own internal team and their challenges and what friction that they’re experiencing. Because I do hear, there is designers just frustrated about working with engineers, and how hard it is to work with engineers, and engineers are stubborn or they’re not interested in people. One of the things I really watch in my team is that us against them mentality because it is ultimately just going to create burnout. It’s not an intractable problem, it’s a lens, it’s a problem with the lens that people have. Somebody has to write the code, right? And we love that they do that. And the design is useless if it doesn’t make it to code, so we need that part of the team, so how do we respect that and respect that their experiences and their interests are different? Because I think if we push against that and expect every engineer to care, what just happens is burnout instead.

If I really have to think about my philosophy as a leader and what drives me to think about these things, that’s it. It’s really, really hard to find good UX people, it’s hard to keep them in such a highly competitive market. And so it’s important that they be happy and energized and inspired by what they do. So how do we create the conditions to avoid burnout? Basically. So this is part of what brought me back to this topic.

ZN: That makes sense, for sure. And I’m curious, if we’re talking about using research as a way to collaborate around the problem we’re all trying to solve collectively, so that’s design, engineering, business, marketing, whoever else. What recommendations do you have? Are there any hacks or even just tips you can share on maybe how you do that today even at ZS?

NH: Yeah. I think one thing for sure is we do hire deep experts, we work on very, very complicated business problems, we work with data science, with these really large complex datasets with all kinds of regulatory restrictions, and so the design work we do is intellectually very complicated. And so people do have to be deeply expert if it’s an information architect or a designer or even a visual designer or UX designer. But one of the things I want is always people who are interested in the intersectionality with other fields. So for example, I want researchers that are interested in seeing things through to design, that are interested in being involved in making sure the IA is right for the usability. And I want designers that want to be part of research to some degree; maybe they don’t wanna be researchers per se, but they recognize the importance and the value of research and they want to be a part of those kinds of activities. And that may seem obvious, but I think that is one of the things we interview for. People that just want to do design or just wanna do research, we have to get the collaboration right within our own team because even research and design is … Yes, there are people that do both, but that is interdisciplinary work as well, and people have to be willing to do it and curious about it and have some overlap.

NH: And we have designers that are more interested in understanding a little bit about running code so that they can make our design standards fantastic; that’s great, too. I just want people that are curious, not just about users, but about doing better work together. And so that’s a big part of what we look for, and I think how we get the kind of team spirit that we want as we tackle these problems together. Again, you have to get the right people first. Before you can talk about changing specifically how you work and how you solve those problems, it’s the composition of the team and the attitude of the team that is first.

ZN: Definitely, it’s a mindset, right?

NH: Mm-hmm.

ZN: I’ve often and frequently talked to people… [chuckle] This is my very blunt way of saying it is I like to work with people who give a shit.

NH: [chuckle] Yeah.

ZN: It just comes down to being that simple. If you’re in a field … and it doesn’t matter if you’re an engineer, a designer, it doesn’t matter. But if you’re in the field because you’re just like, “I love research and I want to make this beautiful and intricate research plan that checks all the boxes, is completely bullet-proof, and delivers all this stuff,” but you don’t actually care about the impact that has somewhere else or why it may or may not matter to somebody else, then it doesn’t… How great your work is actually is inconsequential at that point.

NH: Yeah. There’s a great… I’ll have… I can dig it out for you. I won’t be able to put my fingers on it fast enough here, but I think the second Enterprise UX Conference that Lou Rosenfeld ran, someone talked about “The Sliding Scale of Giving a Fuck,” It’s great. I actually have used that with my team to say, “Look, someone who cares about design standards is freaking out that the devs don’t wanna pay attention to the last micro-pixel or whatever isn’t correct.” And then I just said, “Where are you going put your energy? Is it more important to have a really good long-standing relationship with that developer, or is it more important that the one pixel is right?”

And then really making sure that you’re investing your time and your energy into the right problems, because again, coming back to this idea of burnout. This idea from sociology of emotional labor. We care so much, viscerally care about users and/or patients or the consumers that we’re serving with our solutions, and it does lead to burnout, and you just have to step back and just say, “Which of these things do I really … What’s the hill I want to die on?” And it can’t be every single one, it can’t be every single pixel.

ZN: Right. [chuckle]

NH: We do this elaborate in-context research, and then an executive will go talk to their stakeholders and they call what we did a focus group, and I’m like, “Oh god, please don’t do that!” But that executive is super excited that they’ve sponsored research and that they’ve found interesting things. And is he calling it the wrong thing and is that horrifying to me? Absolutely, [chuckle] but we still have an executive talking about the value of research, so you have to step back and say, “Am I really gonna correct that guy, or am I gonna let him run with it?” And I’m gonna let him run with it.

ZN: Yeah, and I’ve made the same argument in the past it’s like … And actually in that talk that I referenced that I’ve been giving, [chuckle] I use a reference from the one… The most recent Indiana Jones movie, which is… It’s questionable on the quality of that one, but [chuckle] there’s a scene in there… So anybody who knows Indiana Jones knows that he has a phobia of snakes, right?

NH: Right, right.

ZN: And so he’s in this quicksand pit and he’s getting rescued, and they can’t find anything in the jungle so they throw this very long snake for him to grab onto to get out of the quicksand. [laughter] And they keep telling him, “Grab the snake… “

NH: [laughter] That’s funny.

ZN: “Grab the snake, grab the snake,” and he gets mad and he says, “Stop calling it that.” And they say, “Well, what should we call it?” He said, “Say grab the rope.” And so they do, and then he grabs on and they pull him out. [chuckle] It’s funny, but the thing is, is it’s the same thing in the world that we live in is there’s these mental hangups that people have. Now, are you gonna die on the hill of saying, “No, no, no, no, no, those are not focus groups,” or are you just gonna go, “Great job with that focus group. Let’s go and do another collaborative interview session.” Give it a different name. [laughter] If they’re afraid of snakes, don’t call it a snake.

NH: Yeah. And I don’t know if it’s just maybe I’ve been in this field so long now, but I do feel like we are so enamored of our processes, of our artifacts, of how we do the work; we’re a little precious about our own stuff. And I think this is an interesting conversation I was having, we were evaluating changing our prototyping tools, so the set of tools, the combination of tools. We have, again, some interesting challenges because we work on product on one side where we need really sophisticated prototyping with all the behavioral specifications displayed for the dev, and then we have a lot of quick and dirty stuff we do on the consulting side, and we’re learning we need multiple kinds of tools.

I’m experiencing a span of control with 100 people, just the kind of details that you’re in have to change. And I do get impatient for people who get stuck in there, and so I’m starting to empathize more and more with those executives that I go talk to, “Can you get to the point faster? What details really matter?” And I think it would really help … I almost feel like UX people should find a way to shadow executives just as a learning opportunity, and just understand the way that those conversations happen, how snap decisions are made, what kind of data is needed, the advice to focus on the conversation, not on the slides. That kind of executive perspective, I hope more and more UX people will find a way to have that, because I think it could accelerate the kind of impact that we deliver to our target users or patients or customers or whatever by understanding that better.

ZN: Yeah, definitely.

NH: I was looking at one of the questions you asked me, “How do we get people to collaborate and act on it?” And just thinking about how do you do that because there is … even just in the way that you phrased that, there’s just a little bit of forcefulness to it, “How do we get people to collaborate?” [chuckle] And I think … And it’s a fair question, and again, some of it within our team where we have control over the temperament of the people we hire, that’s an expectation. And then you had choosing where not to collaborate. For me, as much as I think engineers do need to have some understanding … and by the way, some people that go into front-end development … I had a full stack developer that I worked with, and he made the switch to be a front-end developer because he actually wanted to be closer to the business logic and the business, and he felt working on the front end would help him do that. He had an MBA also, so an engineering degree and an MBA. And so for him, that was something he really wanted and he was interested in, but not everyone is.

I actually think for me, a much easier thing, once you’ve built the right rapport with clients, is to get clients to work with you. So if we’re doing a big research project, we’ll ask the client to pick a junior person to be part of the project team. We want the insights to be sticky with the client long after we’re not there anymore. And there’s something that happens when you do the analysis, that you internalize the findings in a way you never can if you just get a research report. You have these verbatims in your head, and you understand the patterns in the data.

And so we typically really push to get the clients to assign a junior person from their team to participate in the analysis with us. And it’s amazing how much more sticky the findings are. The client will start talking, “Oh, this is what the research report said,” and that junior person will pipe up in a meeting and say, “Here’s a direct quote,” and they’re able to just really talk in an impassioned way, and they represent, because they’ve done the analysis with us and we’ve all arrived at the same conclusions, they’re just able to carry those insights forward back into the business in a way that we could never do because eventually we step out of the project. And so for me, it’s not to say that that internal team collaboration isn’t important, it is super important to have a high-functioning team, but don’t want to forget that if ultimately what you want is to do research that drives action and change, getting your customers to collaborate, I think, is also incredibly important.

ZN: Right. And even a little bit more tactical in that regard, what do you do there, getting them to collaborate? Because again, that’s making the assumption that they care, and so maybe it starts there.

NH: So I’ll give you a specific example. We’re doing some research with salespeople, which is a user base that we work with a lot at ZS. We do a lot of work within sales; that’s sort of what we’re known for is sales and marketing, whether it’s analytical frameworks or deep domain knowledge about healthcare and how the health care ecosystem is evolving, and what that might mean for a sales or marketing strategy, for example. And then more recently working more and more in the clinical trial space, bringing those same kinds of operational efficiency and technology and domain capabilities into the full life cycle of pharmaceutical products.

So sales is an area where we spend a lot of time. We were doing a multi-phase project where we did concept testing, revised design, usability testing, interviews, some in-context research. It was just a massive amount of data, and it came in phases. And so we did things like creating a hypothetical journey map based on stakeholder feedback, and then we went to talk to the real people whose journey was represented and brought stakeholders with us and said, “What’s wrong with this journey?” or “What’s not in this journey?” And we iterated the journey, and the stakeholders got to observe all the things that they didn’t deeply know or understand about the journey that the real users were able to describe.

In affinity analysis, we collect interview data and organize it into themes, and read the transcripts, cut the transcripts apart. The high-touch, high-effort true analysis effort, and putting things on big poster boards, and looking for themes. Those junior people from the client teams do that with us, and then they’re all energized and jazzed about the deliverables. We’ve had clients take those boards with all the quotes and stuff on them and bring them back to their office and use them and display them in their offices, and say, “This is what the field really needs.” So they’re just… They so deeply advocating for those users after being a part of that process.

I think for me, that whole idea of stakeholder-led design versus true user-informed design, that juxtaposition, doing that, clients believe that that stakeholder design is enough, or they want start with that. We indulge them, we’ll say, “Okay, let’s draw what you know and we’ll start with that.” And then we say, “And then just please give us access to just 3-5 people whose journey this is, and we’ll validate it that way.” And inevitably, it blows the whole conversation wide open about how little they actually knew. And we have just these great visuals that show, “Here’s the process talking to stakeholders, here’s the process after talking to users,” and we’re just able to show now, and once people have been through that, they become believers.

ZN: Yeah. So almost using the reverse psychology like, “Yeah, sure, we’ll do it your way, and then we’ll just make sure that it’s right.” And then, “Oh, well. That’s not right so we should change that, yeah?” And then they just eventually agree because, of course, they want it to be right, and it doesn’t really matter where the idea started from, right?

NH: Yeah, exactly.

ZN: So long as we eventually get to the right idea, the one that’s best for the business and the customer.

NH: Yeah, and I think some of it also is in the language we use. So we might say, “Hey, we should do some kind of usability testing or some kind of… ” Some of the language we can use, it makes clients overwhelmed. If we say, “Look, let’s just validate this with 3-5 users per segment,” or whatever it is, somehow that’s less threatening than, “Let’s do another whole wave of gigantic, complex, expensive workshop,” right?

ZN: Right.

NH: It accomplishes the same thing, it’s eye opening. But it’s the language we use that makes that more accessible and we’re not trying to insist that the stakeholder don’t know. We’re saying, you know, but let’s also talk to the users, too. So not invalidating their own experience or perspective because that’s just gonna create animosity or people are gonna get their backs up, right?

ZN: Yeah, absolutely. If they’re afraid of snakes, call it a rope.

NH: That’s a great one. I can totally… I haven’t seen that movie, but I will visualize that one forever. I’m definitely gonna have to go back and watch it now.

ZN: Yeah. But it’s just one of those things, again, where if usability testing or user research puts the hackles up of somebody you’re talking to, then don’t call it that. Just say, “Yeah, we’re just gonna make sure that you have the confidence that we’re making the right decision. Does that sound good?” If somebody says no to that, then you have a completely different conversation to figure out. But generally speaking …

NH: Yeah, how much do they really care? Why are they investing? Are they just trying to check the box or do they really care?

ZN: Right. Which interestingly enough…

39:23 NH: Go ahead.

ZN: If that’s the case, then guess what? Maybe you actually don’t need research. Maybe you shouldn’t actually waste those time and resources or cycles doing that. It’s rare, but at least you get to an honest place. [chuckle] Right.

NH: And we’re just really careful when we do that kind of work that we label it; we make really, really clear, this is a journey map, but it’s not informed. We will go that extra mile to just make it really clear that it’s not user-informed. Because what happens is people see a journey, they assume it’s grounded in some user insights, and if it’s not, we don’t want it misrepresented. So there are some ethical things there, too. And ultimately you’re protecting your client. You don’t want them representing something as a journey if it’s a stakeholder-designed journey.

ZN: Right, absolutely.

NH: I was looking at the other questions you had asked and made sure we covered them all, Zack, and one of the things you said is, “How do we collaborate around research to make it more actionable?” And I think this is where this idea of thinking about who needs to take action. An executive needs to take one kind of action, and an engineer needs to take a different kind of action, a product manager a different one. And so just thinking that you can have a one-size-fits-all deliverable, for example, I think is a mistake. And so we’ll have the executive version of the deck, we’ll have the one that we created with the product manager that determines next steps from a roadmap perspective of working on a product. And with the engineer, making sure that we’re pulling it through to say, okay, for example, just because you present a usability testing report and say this is what worked and what didn’t work for the users, an engineer doesn’t automatically know what it means they need to do differently.

And so we created separate deliverables, “Here’s what the usability testings findings specifically mean for engineering next steps.” And not assuming that is understood, because then there’s this huge interpretive gap there if we’re not specific. And so, like I said, it is extra effort to do that kind of collaboration, but then you’re more likely to get the outcomes you want.

ZN: Yeah, that’s awesome. And I wonder, can you speak to any more detail on the differences between some of those deliverables? You mentioned the one for development, for instance. Okay, here’s a finding, here’s what this means to you. I love that idea, could you talk to that any more?

NH: Sure. So when you do a research report typically, it’s organized around themes; that’s what makes a good a research report. The themes or the ideas behind the research are sticky. But the developers are thinking about components of code and screens and so we actually, literally, go screen by screen. We’ll actually go screen by screen and document, here’s what needs to change, here’s what needs to change, here’s what needs to change, instead of assuming that because for example, maybe you’re using one element on a screen doesn’t mean they know to change it everywhere. There is software that does this now, I think about something like Zeplin that we’re starting to use internally, and it just takes whatever specifications you’ve documented and it just flips it on its axis so it’s organized around the things that the devs care about instead of what you care about.

NH: The devs don’t care about the business themes or the user themes, they care, “Okay, how many times does that search box appear? Where does it appear? So we make sure we change it everywhere.” Or, “Where was that color used? If that color doesn’t work, please tell me all the places where that color was used so that we catch everything.” And just going that extra mile to make sure you pull it all the way through is important. I think another area where we’ve had some really good success is all the way through to QA, and so I think we often feel, “Oh, we’re sandwiched between engineering and product management,” or “There’s the business and product management on one side, engineering, and we’re stuck in the middle,” and we feel like we don’t know enough about the business, and we’re not involved enough in engineering, and we feel like we’re the ugly stepchild or whatever, the monkey in the middle.

And what I’ve learned in having those conversations with QA is they feel the same way. And product decisions, roadmap decisions are made, designs are made, research and sites are developed, codes gets engineered, and then QA is the last mile, but they haven’t been included in any of the stuff upfront. And the amount of good will that’s established by just including them earlier. We’ve done some things like first of all inviting QA people to hear our findings, because otherwise they don’t even know what use cases they should be testing for. So they go to usability testing, and we have a list of tasks, now it becomes evident what should be tested from a QA perspective in terms of the core capability of the solution.

And then the other thing is, is even with design system. Maybe this is obvious, but say, “Hey, here’s all the things that are covered with the design system. You don’t need the QA these anymore because the search box is a piece of code that’s been QA’ed once and never needs to be QA’ed again. Here’s the parts of the design that aren’t in the design standards yet that you should be focusing on when you do your annual testing.” And it’s just… You say it and that seems so obvious, but each one of those teams start to feel like they’re left out somehow. Engineering left out of the business conversations. QA feels like they’re left out of some conversations too. So, I think just looking around at what does it take to get the product out the door, and who are all the people that touch it, and are people really included, because then all of them can evangelize on behalf of what’s best for the user, or what the pixel-perfect outcome would look like. Are they gonna advocate for your pixel-perfect design if they’ve never seen it before? Probably not.

ZN: Right. Yeah, and I think… Yeah, something you said there, I’m reading between the lines and pulling this out, but we got onto this because we were talking about how research enables teams to collaborate. And the reality of it is when you bring them together, and you bring them together around a central idea that is supported by something you learn from customers of this shared agreement of the problem we’re solving, that’s backed up by what you actually learned from research, then all of a sudden the conversations you have are not, “Well, this is what we want or need from QA, and this is what we want or need from Development,” it’s all, “What are we doing in the best interest of this thing we’re all rallied around, which just so happens to have been informed by the very work we did in research.”

NH: Yep. Yeah, I read a great article, you’ve probably heard that expression, dysfunctional teams create dysfunctional products. And I went and did some digging around about where that came from, because it was so compelling to me. And it turns out it’s a Harvard Business Review article, and one of the things that I found really, really interesting in that article is they said that people do align at the beginning of projects, but then they gradually drift apart as micro-decisions get made. And that one of the things that prevents that from happening is visual artifact. Whether it’s your Kanban board, or a wireframe, or a site map or whatever it is, and I just think that’s the business we’re in.

So the rallying cry for me is we can play a critical role in keeping teams moving in the right direction and building the right thing because we’re the team that can create those artifacts that ensure that we remain aligned as a project goes forward. Whether it’s some kind of abstract conceptual piece. We’ve done things like visualize information architecture as a way to help teams get aligned, not just to say UX artifacts, but project team artifacts that are visual are sticky and help drive and make that alignment. It becomes a reference point over time: Let’s pull that out again, is this decision in line with what we agreed when we draw the solution architecture diagram? And so for me, that just seems like such a great opportunity for us to be the glue in making that vision that we establish as a team become reality.

ZN: Yeah. That’s great. Say, Natalie, I’m looking at the time, and I realize we’re coming up towards the end of our conversation, of which I’m quite sure we could spend several more hours discussing this with you.

NH: Yeah, it’s been fun, absolutely fun.

ZN: Definitely, but I wanna be respectful of your time. So to that end, I would ask you, is there anything else that you’d like to share with the audience today that we haven’t already covered in our conversation?

NH: I don’t think so, we’ve talked around a lot of different topics. I think a lot of these things I’ve been writing about on my blog. I mentioned I wrote an article for the Journal of Business Anthropology about interdisciplinary collaboration. On my blog, there’s a post called “Origins of Anthrodesign”. So I’d mentioned anthrodesign at the beginning of our discussion, and I wrote it about a year ago, but that post marked the 15-year anniversary. So it was around the time I was finishing my PhD and thinking about what my next career steps would look like, I wrote that post to reflect on the fact that it’s 15 years strong, it’s still vibrant, still generates a lot of really great discussion; I still learn something new there all the time. And so I think if you wanna know more about my thinking on those topics, that more recent JBA article, and then that Origins of Anthrodesign article would be great places to start.

And then I think the main thing that I’m trying to impart to UX professionals is that empathy with the disciplines that you work with every day, that that’s really gonna get those outcomes, ultimately get the outcomes we want. Not just the empathy for the users, patients, or consumers that we’re designing for, but empathy within the team actually is gonna drive better outcomes, too. And if you really find you’re banging your head against the wall in dealing with an engineer, or a product manager, or whatever it is, to just really step back and say, “How is their world view different than mine, why is it different than mine?” And rather than risk burning yourself out or banging your head against the wall is to just say, “How do I step back?” And as a fantastic research opportunity, how do I reframe the problem, right?

ZN: Yeah.

NH: And really go after this in a different way, and manage people, really encourage people to do that, and to say that maybe what’s in that unhappiness is a learning opportunity. And I think in the end, we’ll do better work, and we’ll probably be happier at work, too, if you’re feeling frustrated.

ZN: Yes, that’s great.

NH: There’s also the Ethnographic Practice in Industry Conference (EPIC), which is a conference that’s focused on ethnographic methods and interdisciplinary teams, which I think is a great event. And it’s nice because it’s not huge, it’s single track, and so there’s just really an opportunity to get to know other people. So that would be another place if you’re really interested in those types of methods and interdisciplinary teams doing that kind of work, that’s a great place to start. The next one’s in the fall in Rhode Island.

ZN: Awesome, we’ll make sure we include links to those things in the show notes.

NH: Great.

ZN: Part of what you just said, too, is… Reminded me that I need to ask you the question I typically do of all of our guests, which is if I came down with temporary amnesia and I forgot everything that we talked about, [chuckle] and there was one point that you wanted to make sure that everybody got from the conversation that we had today, what do you think that would be?

NH: I would say for me it’s that we deliver the best possible outcomes when we treat the relationship within our teams as seriously as we treat the relationships with the clients, patients, consumers we’re attempting to serve.

ZN: Excellent, I love it. And I strongly agree with that.

NH: Alright, well, Zack, it’s been a pleasure speaking with you, thank you so much.

ZN: Definitely. Natalie Hanson, thank you so much for taking the time and joining us on the show. And I hope everybody got something out of this, I know I certainly did, and we’ll have links to all the things that she referenced in our show notes, you can check those out. And Natalie, again, thank you.

NH: My pleasure.

ZN: Alright everybody, we will see you next time.

If you enjoyed this episode, consider leaving us a rating on iTunes, or wherever it is that you listen to our podcast, and also you can fill out our podcast survey where you can let us know of someone awesome that we should have on the show, and even tell us about the things you would wanna hear about, topics that are interesting for you. You can check that out in the show notes or on our website.

Thanks for listening to the Aurelius Podcast, the show where we talk with brilliant minds about user research, UX design, and building great products that meet the needs of real people and what you learned about them. Aurelius is a user research and insights tool for design and product teams. Aurelius helps you add, tag, organize, search, and share all of your user research notes and customer feedback insights to figure out what you learn faster and easier than ever before, so you can make awesome designs, products, and features. Check us out for a free trial at aureliuslab.com that is A-U-R-E-L-I-U-S-L-A-B.com or find us on Twitter @aureliuslab. We’ll see you next time.