A chat with the Advancing Research community

In addition to being a book publisher and conference organizer, Lou Rosenfeld has started running a series of community calls around Design Ops and Enterprise Experience. I enjoy them when I have time to attend, because it enables us to continue the dialogue from the Rosenfeld conferences. Most recently he has formed a new community called Advancing Research to foster interdisciplinary dialogue about research. In my presentation to this new and growing community, I shared a reprise of my keynote from UX Camp Chicago. The unique content in this post is the Q&A that resulted from sharing an abbreviated version of that presentation.

---

Introduction from Lou Rosenfeld

So there’s some interesting things happening in the research world, and I feel like one reason to have this conversation is that we’re in a post-tribal era. If you’re as old as me, I’m 53, when you learned about people doing research, they were often associated with a different discipline, like it might have been people coming out of marketing, doing their type of research, versus people coming out of HCI, doing their type of research, and so on. And there wasn’t a lot of cross-pollination. And now it seems like we’ve sort of shed the disciplinary boundaries, in many respects. We read each other’s journals, we go to each other’s conferences, we’re actually… The conferences that are very focused on those narrow areas are almost becoming moot, not that important. It’s the sort of synthetic, putting things together perspectives that have become sort of the most vibrant. And so that’s really why we’re here, I think.

Now, you may have some other ideas, and I’d like to make sure we all kind of share those ideas, and that’s why we’re having these calls, and why these are not just presentations, but opportunities for you to share, for you to be part of this conversation, and, ultimately, for you maybe to lead the the next call …

Natalie is such an incredible person. I got to know Natalie, sort of by accident, because at the very first Enterprise UX Conference, back in 2015, she took the most amazing notes on all the sessions, and we decided, and she was kind enough to agree, that we would bring her back the next year as our official trip noter. So we have an official sketch noter, that’s MJ Broadbent, and an official trip noter, and that’s Natalie and she’s done the same for the DesignOps conferences as well. So I got to know her that way. But Natalie is a principal at ZS Associates, I’ll let her tell you more about the work she’s doing. I don’t know if you’re one of the founders or the founder of the Anthrodesign.

Natalie Hanson: The founder, yes.

LR: Founder, and is an amazing combination of both a scientific approach. As someone with a PhD, she has an academic background, but has some really amazing ideas around practice … it’s just great to have you talking about a topic that I know is gonna be really pretty relevant to everyone.

NH: Thank you. Again, great day to be here. Funny story about that first Enterprise UX Conference, I went, I had just finished taking a sketchnoting class with my team, and I was all gung-ho to do sketch noting it. And I tried the opening keynote, and it was just a disaster. I just didn’t have enough whitespace, and I just didn’t know what I was doing. And then I happened to see what MJ was doing and I was like, “What am I thinking? I should just take notes.” [chuckle] So that was my first and only attempt at sketchnoting; after I realized what other people can do, I decided maybe that wasn’t the right technique for me.

NH: So, thanks for the intro, and I appreciate the comments that you made, Lou, because this talk does have a nice combination of a real practical experience from having done this for almost 20 years, but also the academic work that I’m doing in this space. And so I’m gonna sort of switch hats and talk a little bit from both camps, and I think that hopefully will make for a rich discussion. As you mentioned, I did the opening keynote at the UX Camp meeting here in Chicago, right after DesignOps, and this is a subset of those slides. Enough slides to provoke some discussion and get us going here. But the full deck is on my website along with a voice-over if you wanna hear the full thing. I’m going to try to do an abbreviated version today.

Collaboration by Design – Overview

So the topic, for me, is about collaboration, and I think those of you that are connected into the Enterprise UX communications, you know that Lou has been thinking a lot about how do we deepen our collaboration across disciplines. And that is really the topic of this presentation. I care quite a lot about it. The founding of Anthrodesign, almost 16-17 years ago now, the intent was, “How do we make sure that researchers and designers are working together as effectively as possible?” And so this is sort of the deepening of that exploration. And why does that matter? Because, and this is sort of a discouraging statistic that probably many of you know, that more than 50% of technology projects fail. So for those arose us that are doing experience-led work in tech (which I think is many of us), if we have UX in our titles, that a huge percentage of the projects that we do, don’t succeed. And really, why is that the case?

There is a great HBR article about why that happens. And the quote that made its way all over social media is basically that dysfunctional teams make the dysfunctional products.

If we don’t do the work of making our teams work in an integrated way, and we focus all of our empathy and all of our energy on end users and not on the interactions within our own teams, we end up with dysfunctional teams that produce dysfunctional products.

Now, one of the things I really love about the recommendations from this particular piece of research is that they characterized why the dysfunction happens, and what they said is that it’s a series of small decisions that result in sort of a dissolving of an alignment that existed at the beginning of a project. So you start with some shared understanding and some shared goals and then over time, micro-decisions get made independently that cause the team to drift apart in terms of their shared understanding or their shared goals. And the most powerful vehicle to prevent that from happening is visual artifacts and visual representation.

So not your 200 or 500-page business requirements document from the old waterfall days. But UX artifacts are brilliant in an important way that you keep a team coherent and engaged on a set of shared objectives. So I think we, as UX professionals, have a critical role to play in using our ability to create abstract representations of what we’re trying to achieve or what users need, or whatever, as a way to keep the team all aligned and moving in the same direction.

Here’s another little bit of academic work, and the citations are in the comments here. I can share them for anyone who’s interested. This is a paper by Bernard Choi and Anita Pak, it’s an industry scan of research about collaboration, and they describe these three different models of collaboration. The lingo is a little academic and impractical. I still say interdisciplinary, though that’s probably not really what I mean, but I think just to give us some common language to talk about this for a moment, this idea that, in most cases, we’re working in a team, a multidisciplinary team, and we’re just working next to each other, but we’re not really working and sort of dissolving those interdisciplinary boundaries in any way, we just happen to be sitting next to each other.

It’s like with kids, at a certain age, they’re engaged in parallel play and not really in play with each other. This is multidisciplinary, sort of the equivalent of parallel play. In interdisciplinary collaboration, we get a little bit more connected to one another, and we start to do knowledge exchange, and maybe soften the boundaries between disciplines in some way, and that obviously makes the coherent whole a lot stronger. The end game, the ideal state, is this transdisciplinary, and is the term that I saw over and over again, was this idea that teams are recombinant and that their disciplines are subordinated to solving the problems in different ways. And I would say, in my experience, I think when we talk about participatory design as this sort of Holy Grail of how we wanna work in project team, I think we have this transdisciplinary model in mind, and we imagine this thing where engineers do the research, and we all do the affinity analysis together, and everybody is reading transcripts, like this idea that we’re all kind of working together, right? We’re expecting other people to engage in the UX work. We don’t necessarily wanna be writing code, but we want them to be deeply engaged in the work that we’re doing as well.

I think the reality is that that’s not really necessarily of mutual interest. So I think – just a little bit of a reality check – that we have this thing that we want, that we believe and we actually know from scientific research leads to better outcomes. More diverse teams with more varying viewpoints are scientifically proven to lead to better, more innovative outcomes. So we want this, but the reality is on most of the teams that we’re working with don’t necessarily want the same thing. So part of what I talked about in the longer version of this talk is the emotional self-management that’s required of us as UX professionals to manage our own expectations about how far along this maturity model we can expect to get with people from other teams.

One more little piece of academic research I wanna share, I actually use this quite a lot in coaching my team. I see there are a few members of my team on the phone, so they’re gonna maybe feel like they’re listening to a broken record here! But this ladder of inference is a really, I think, very powerful vehicle to make sure that we’re really talking about the same thing as we move forward into action plans. So some of you, if you come from the field of anthropology or applied research, you may know Gitti Jordan, she was a mentor of mine. She passed away a couple of years ago from pancreatic cancer, but she was just an absolute force in the world of applied anthropology, and she spent many, many years working at Xerox PARC. And one of the things that they were committed to at Xerox was these integrated teams where designers and researchers and engineers worked together. They recorded their research and they sat together and did the analysis of the video together. And what she realized is that, of course, because we’re trained as researchers or designers, we, at the very beginning, the things that we observe, the facts that we select to observe at the bottom of this ladder of inference, are very, very different than what an engineer might observe in the first place.

If you don’t get everybody aligned on the observed data first, the assumptions and the beliefs and decisions about what to do just bifurcate from there.

And so she spent a lot of time doing the analysis of the video with the engineers, so that there was an alignment about, not only what the video meant, but what should be done about it. Okay? And so I think this is valid in many, many other cases, this idea of thinking about the ladder of inference and saying, “Okay, I’m experiencing some conflict or friction with another team, and why is that?” And we’re already at assumptions and conclusions or disagreeing about actions, which is at the top of the ladder of inference. Based on what data and what meaning are those decisions being grounded, and to work your way back down the ladder to get to the point where there is alignment, and then work your way back up again. And I think especially when people are operating from very different disciplinary training and experiences, that that becomes incredibly important.

Anthrodesign is a community that I formed more than 15 years ago. It focuses on ethnographic methods, the use of ethnographic methods in business. And two years after that Ken Anderson and Tracy Lovejoy formed the EPIC Conference, which many of you may be aware of, an ethnographic research conference, so that continues. And they have double-blind peer-reviewed proceedings so they’ve now created a body of literature around these types of collaborations that didn’t exist 15 years ago.

When I look at what’s happened in those 15 or so years, we’ve spent a lot of energy and thought and time in dialogue about the benefits of the anthropology or sociology working together with design. What I came to realize as I was completing my PhD and founding anthrodesign was that

anthropologists are really not well-equipped to deal with business problems because we ask far-ranging, open-ended questions, and we’re seeking themes and patterns in a way that are very compelling and meaningful in terms of human behavior but may be incredibly impractical from a business point of view. And we don’t have issues with that complexity, we’re paying attention to what people are doing, but we don’t necessarily know how to bring that to business.

And what I felt was so powerful, the first hiring decision I made when I built my first UX team, was I hired a designer. Why did I hire a designer? Because I had all these ideas, but I couldn’t express them in a way that the business could understand.

Designers are inherently, the outcome of their training is a portfolio that describes their ability to solve a problem within constraints. And that’s precisely the enormous gap that exists in anthropology in terms of most training. Especially at the PhD level, you don’t get a lot of that really practical methodological experience that you do if you do, say, in a applied Master’s degree. And so I just started to realize that there was this really amazing an important synergy between the nature of the way that anthropologists think and work and produce outcomes, and the way that designers work and think and produce outcomes. And so I started Anthrodesign as a way to foster dialogue about that, and using the idea of ethnographic methods as that shared place that we wanted to work from together.

So, in principle, the community is organized around the method, but really, the intent was around interdisciplinary collaboration. Now, what’s happened in these 15 intervening years is six books have been written, countless, countless journal articles, entire conference tracks, of course, at EPIC, and so on. And so now there is 15 years worth of dialogue about this kind of collaboration between anthropology and design. It’s really exciting to see that conversation deepening and people now, on LinkedIn, they call themselves design anthropologists and all this sort of stuff, which not of that language existed before Anthrodesign.

I wrote a post called The Origins of Anthrodesign reflecting on why I had built the list and what I think is the work ahead of us in the future. The work ahead (and what I want to talk about briefly here) is that we have to do the same work with all of the disciplines we collaborate with, not just with anthropology and design. I think, in fact, this might be the easiest of our partnerships, because many of us now work in teams with a shared umbrella of UX.

How do we deepen our understanding and our appreciation for working with engineers, or working with product managers, working with our QA function, in the same way that we’ve invested in understanding these other fields within UX.

Question & Answer

Q: I work in a large corporation, and, yes, we all wanna collaborate, but the organizational structure keeps putting brakes on things because of different leaders and different objectives, etc. And I’m loving what you’re saying, I’m just wondering what you found, if there’s any ways to overcome those constraints, I guess, it is a big design problem.

A: So, to give you some perspective, I work at a company that’s now 6000 people. The tech business is about 2000, so about a third of that. And it’s a democracy, it’s privately held partnership, employee-owned and operated, and all that good stuff. But before that, I spent 15 years at SAP, which could not be more different. And SAP is enormous and highly structured and siloed and very command and control. It could not be more opposite, culturally, from where I am now. And I did the same things I’m doing now, when I was at SAP because to some extent, if you’re committed to solving the same business problems, those boundaries don’t matter if you’ve established the right individual human connections.

At least for SAP, it’s an incredibly well-run company in many ways, and there are four KPIs that govern the entire company. All 80,000 employees share the same four KPIs. So if you understand that that’s how the business run, you can find common ground with people in other silos. But I think it is a question of persistence and tenacity, and business acumen, candidly, to find that common ground. And for me, what that meant was learning a hell of a lot more about how business executives talk, how they run their businesses, how they measure success, and to talk about UX in terms that makes sense for those business executives.

I’ll give you a very specific example. I’ve been away from SAP for eight years now, but at the time SAP had a Chief Process Officer, and he was tasked with moving the entire software development organization to Lean Agile model. Twelve thousand developers, so imagine the size of that change and that transformation.

He was using not just Agile, obviously, but these ideas about Lean, and I started to do a bunch of reading and learning about Lean, and what I learned about Lean is that it has a ton of synergies with UX. Lean starts with the customer and works backwards. The primary methodology is that you walk the shop floor to understand what’s going on before you propose interventions, and that it’s inherently iterative, that Lean is inherently a process of removing waste in an iterative way. Once I understood the basics of Lean, I realized there were huge synergies with UX. I got my whole team certified on Lean, and then I went to talk to the Chief Process Officer and I said, “I can help you, and here’s how I can help you.” But I did that because I took the time to understand the language of business and what was driving and motivating him, and I presented what I had to offer in the language that made sense for him as a business executive.

For me, those silos have never stopped me because we’re still all people. There’s still human connections and human interests, and combined with a deep understanding of what’s driving people’s business. You think about Maslow’s hierarchy of needs, they’re not gonna do something that’s gonna get them fired, but you can find that common ground. And in a business, even if you’re in silos, there’s common ground because otherwise the business wouldn’t run. And, again, whether it’s the ladder of inference or the Maslow’s hierarchy of needs or whatever, work down to that common denominator and then build up together from there.

Q: What about the six books that you mentioned?

A: My Origins of Anthrodesign blog post lists the six books.

Q: “Wow, I didn’t know that Anthrodesign was really a place for this type of discussion. Is it a place that we can join?”

A: If you go to http://www.anthrodesign.com/join-us there are instructions. There are two channels, one is a listserv, which is the long-standing sort of 15-year listserv. I have to add you (which minimizes spam), but it’s unmoderated once you’ve been added. It gets about 200 posts a month right now, so just keep that in mind from a volume perspective, you may wanna sign up for the digest. And then there’s a Slack, and the Slack is a couple of years old, and that’s a collaboration with the Ethnography Matters blog, which is Tricia Wang’s blog about applied anthropology, and also with EPIC, which is this Ethnographic Praxis in Industry Conference. So the three of us agreed to do one Slack together and we moderate and admin that together. And instructions for both of those are at the link above.

Collaboration by Design – Examples

So three quick examples, I think, and then we can just move into the open discussion. And I think the point I wanna make here is that this way of collaborating is much more subtle and requires way more work than I think we’re used to. What I’ve read in academic journals doesn’t accurately represent the complexities of the business world. And in the business world the complexity of human behavior is not well understood. So, I think we tend to gloss over how complicated it is to do this kind of collaboration. I would say even within my own team, and I have a pretty high-functioning, successful team, we have great employee feedback, very good customer satisfaction scores, and still we struggle with how to effectively collaborate between researcher and design. So I think it’s an ongoing piece of work that requires attention, and it’s easy to do that within the boundaries of UX because now we’re generally part of the same umbrella and harder maybe, to do in other cases.

I want to talk about the collaboration with product management (PM), the challenges we face in collaborating with PM colleagues. So those of you who follow what’s going on in the field and the literature, you may remember Leah Buley’s book Team of One. I think that book made a huge impact on many, many people. And after that, she went to Forrester, which is an analyst firm, and she spent a number of years working across many, many clients, helping them mature their thinking about UX. And when she left Forrester, she wrote a blog post that just, I think, exploded the Internet. Now, that was just me, maybe the community that I was in, but she basically said UX people need to get it together and understand how the business world works. If I had to kinda encapsulate my takeaway from her post, I thought it was a fantastic piece. I don’t agree with everything she has to say, but I thought it was really powerful.

So this is in keeping with that message. So what’s the role of product management? Product management’s job is to be the bridge, depending on how you’re structured, but in a sophisticated product organization, they would own the P&L, or own the profit and loss statements for a product. They have a tremendous sense of responsibility and ownership for the financial success in the market success of a product. They are a business person, or they might be a product owner if they’re not a true product manager, they’re owning the product on behalf of a business stakeholder who’s trying to achieve a business outcome. And I think where we get into trouble in UX, and why I see it still over and over again, is we’re just engaged in bringing the wrong kind of insights and perspective to the conversation with product managers. So in the most immature organization, we start at the bottom of the visual and work up.

So the most immature organizations that we see, for example, using really basic Google Analytics, tracking traffic hits per page, browsers, any meaningful traffic patterns, spikes on certain days of the week or a campaign system might spike after an campaign email is sent, or something like that. We know you may have heard the term vanity metrics, really not useful for business decision-making. I think we get mired in these, especially if we’re coming from a highly technically-driven organization, we tend to focus on them. These things help with sizing of servers, okay, and performance APIs and… These are metrics that really don’t have a lot of business value. And so I think many of us know not to get stuck here.

Where we do get stuck is in this middle band. For us, these measurements about user behavior are so important. Can the user sign-up? For those of you that are kinda old school, ISO 9241, the measurements for usability, efficiency, effectiveness, satisfaction. Is the shopping cart completed in an e-Commerce offering? Is it sticky? Are people coming back? All these things that are UX things that we care about and that we track and that we measure. A sophisticated product manager, they’re gonna shut you out or shut you down if you stay focused there, because they’re focused on a much broader range of problems: Market share, revenue, competitive landscape … maybe business costs like reducing support costs, or patient adherence, these major, major business outcomes. And if you aren’t talking about what you’re doing in your UX work, in relation to the things that they care about, they’re going to tune you out.

So I think our challenge and our responsibility in the call to action from Leah, in my own words, is to say, “You’ve got to figure out how to move yourself up to the point where your metrics and the things that you’re thinking about are in this business impact category, or roll up into that business impact category in a way that the product manager cares about.

And if you get stuck in this middle band, your product manager is not gonna think that you have anything relevant or compelling to bring to the table.”

Now, this is just one example. There’s lots of other ways we engage with product managers, making product roadmap decisions, all kinds of things. So this is just one very narrow example of thinking about how are you measuring your success in UX. You should be understanding, what are the success metrics at a business level for the product that I’m enabling with my UX services? And are the things that I’m measuring or researching or seeking to improve connected to that in a way that the product manager is going care about? And if not, you better change what you’re doing if you want to be relevant. That’s just one example. And again, that’s not to characterize the whole product management relationship, okay, it’s just one piece of it.

We talk about the importance of inviting engineers to usability testing, and I don’t argue with that, but I think what we do is we somehow think if we’re gonna invite users, invite engineers to usability testing, that miraculously that they’ll have empathy and they’ll know what to do with the product that they’re working on with us. And it’s just so much more complicated than that. And this is why I shared the ladder of inference earlier. You are going see very different things in the usability testing than the engineer is gonna see in the usability testing. And if you don’t sit… If you just say, “Ta-da, we all did usability testing, let’s go change stuff,” and you don’t work your way up the ladder of inference with that engineer to say, “Here’s the behaviors we saw, here’s what the implications are for the experience, here’s what I think it means for engineering changes.” If you don’t work your way up that together, people are could potentially come away with vastly different ideas about what needs to be done.

So one of the things that we’ve made an explicit part of our testing and our read-out now what we do is, yes, we do usability testing, we write up the report that might be a report for a business executive or whatever it is, but we have another report that we write for the engineers that’s specifically about the implications for their work as an engineer. That ensure that there are no questions about how we’re expecting the findings to get pulled through from a technology perspective.

Don’t assume that people understand what to do with usability testing just because they were there with you, or even because you presented a read-out because you haven’t made it explicit in terms of their own work. And if you don’t do that, then there’s no way for knowing for sure that they understand and are aligned on where they’re headed.

Okay, last example. IWe have a pretty robust QA function here because we’re building productive compliance-related systems, so we have people that test by hand front-end and back-end and everything in between, and we have what we call performance scalability and reliability testing, which is all the automated testing, so a very robust QA function. This may not be relevant for everyone, however.

One of the things that I learned when I first started at ZS, I made the rounds to talk to the heads of all the other departments: head of engineering, head of QA, head of product management, to say, “Hey, how do we work together, what are you seeing?” And one of the things I learned from QA is, boy, they feel just as disconnected from product roadmap decisions and design decisions as we feel about other parts of the process, and that everybody wants to feel more included and more a part of how decisions are being made. And one of the things that we realized is that QA could be a tremendous ally for us. This was before we had design standards, so now we have a body of design standards, and those standards are in code.

In terms of looking at the interface for inconsistencies, at that level of QA, we don’t need a lot of help anymore because all the standards are in code. But at the time, nothing was standardized, and we really, really needed QA to look at the thing we drew in a mock-up, and look at what was built, and help us make sure that the designs actually went to market looking the way they were supposed to. We didn’t have enough people to be all the way downstream in the QA process. And so what we learned is, hey, just a little bit of involvement of QA, who are the users … So we don’t do personas here in the enterprise space, we do use what I call user types, which is basically by job function. For example, with a sales rep, a very seasoned sales rep is gonna behave differently than a new sales rep, but on the whole we don’t get down to the level of personas the way you might in the consumer space. But nonetheless, we’re describing job functions, and the the driving behaviors, the driving things for those job functions.

Having a QA person understand who the tool is being designed for and what task it is intended to enable. Because when I asked our QA team, “What are you testing?” They were just using their best judgment about what to test. They actually had no idea what transactions or workflows the system was designed to support, because no one had ever bothered to tell them what business problem or what task the tool was going solve. They just had to use their best judgment. And so just a little bit of connection between us and them to say, “Here’s the users, here’s the tasks we’re enabling.” We invited them to be part of the design reviews and see the mock-ups so they knew how this thing was supposed to look in the end. That tiny little bit of connection just goes a long, long way to make sure the right product goes out the door. Okay?

In design thinking everybody’s talking about empathy, it’s all over the business journals, and management journals, and executives are talking about it, and you’re probably sick of hearing about it, I certainly am! But I think the point is that there’s just a level of empathy and attention that we need to bring to the dialogue within our own team, and that it’s not just a question of looking at end users and making the lives better of that patient, that customer, that end user, but I think this resonates a lot. We have to bring that empathy to our own teams as well. Ultimately that’s gonna enable us to ship better products and deliver better business outcomes, But we have to start with our own teams, and especially those most challenging interdisciplinary collaboration moments with our own team.

Question & Answer, cont’d

Q: Hmm, sounds like we need to be empathetic to our co-workers as well as for our users. My empathy’s been [chuckle] spread very thin already, and I don’t know if you have any thoughts on how to scale empathy.

A: Scaling empathy. In the longer version of the talk I opened with another academic piece, I talked about emotional labor, so if any of you are trained in the social sciences, you may have heard that term emotional labor. The concept of emotional labor is that your job requires you to either suppress or amplify an emotion that you maybe aren’t feeling. So if you’re in customer service, you have to be nice, even when someone’s a jerk. If someone makes you really angry, I’m thinking about … I don’t know if you guys were paying attention to the media when the whole Kaepernick ad rolled out, and the staff in the Nike call center were receiving all of these hate calls. How do you manage your own emotional stress under those conditions? There were young African-American people taking these horrible calls from people responding to that Kaepernick ad. That’s emotional labor. Even if your aunt Betty gives you a really horrible Christmas present and you have to pretend you like it, that’s emotional labor. So we’re all doing it.

But of course the pressure with emotional labor, in the workplace especially, is your job depends on it. And so I think what happens with us is we commit all that emotional labor for those end users or customers or patients. You come crying out of usability testing or ethnographic research, you’ve just internalized all of that pain that you’ve experienced. Enterprise software is one thing, we’ve done a lot of that, but now we’re doing more and more in the patient space, and I’m telling you, that’s a whole different thing in terms of emotional labor. And so we’re a little emotionally drained by the time it comes time to deal with pig-headed engineers, for example, just as an example. [chuckle]

Not to generalize or anything! So I think that’s the challenge is to make sure you’re holding enough of yourself back that you can do that work as well, because you’re never gonna get the right product to market if you exhaust all that energy on your patients or your consumers, and you have nothing left for the team, the team that you have that you have to cocreate this product with.

And I’ll tell you the other big thing, and this is another thing I coach my team on, and it’s also a question of work-life balance. If you’re exhausted both from the emotional labor of your job, but because you’re working too many hours, you cannot self-manage your emotional state. And so that’s another thing, especially as UX leaders, we have to really work hard to make sure that we’re setting that model in terms of work-life balance and managing our own stress and our own emotions, because if we can’t manage those difficult conversations, how can we expect our teams to do that?

Q: When you were talking about consensus, how to do it when profit is not the main driver, in the context of government work?

A: There are still a shared values, whether it’s citizen engagement, whether it’s democratic ideals of some kind, whether it’s distribution of wealth, who knows, there are different set of values. But the thing that really scares me in a question or a comment like that is, if you don’t know what the things are that are driving the business you’re in, whether it’s nonprofit, or healthcare, or education … I’ve worked in all those sectors. You have to know what makes that business go round. You have to know. In a research university it’s publication, in a privately held university it’s enrollments. Whatever those things are, you need to know what those are. In your head you should have a picture of what’s the Balanced Scorecard that the CEO is using to run the business or that executive is using to run the business. And if you don’t know, you’re in trouble. You can’t possibly do good work if you can’t align with that.

And so the first question is, you gotta go figure that out. [chuckle] And then there’s always a way to tell that story. If I can make a connection between Lean and UX, Agile and UX. Right now I’m engaged in CIO-level discussions, if I can connect UX to CIO problems it can be done. But you gotta roll up your sleeves, it’s a research problem. You have to roll up your sleeves and figure out what’s the common ground? And you have to find a coach, if you don’t know, you have to find a coach that can help you navigate that.

Comment: “Heard a great statement the other day about how the researchers are not the advocate for the user or against the wishes of the business demands. Your researcher is the advocate for the connection between business and their user.” [Lou adds] “I think the researcher should be the advocate for reality. “

Q: How do you tailor your research outputs to engineering function? I think you spoke about the fact that you now create two outputs that are tailored to the specific audience, right? How do you connect with engineering function at the level that shows them what the implications are for their work?

A: So as an anthropologist, for me the joy is always in the human behavior and then the ripple effect of what we’ve found, and the engineers, honestly, they’re just not interested. And it’s not a mean thing, it’s just not what they’re passionate about. So we lay out all the screens and annotate what the screens need to change, and if there’s a quote from the user or a percentage of five users out of six failed on this dropdown versus radio button or whatever, we may provide some data from the testing, but we really focus on the practical, what needs to change. We stop expecting them to be interested in human behavior. It’s not a fair ask, they’re not asking us to review their code.

And yes, there has to be a certain amount of caring to get to transdisciplinary. One of the great stories from my time, I had a friend who led an innovation function at Pitney Bowes. Before becoming the team lead, she was an anthropologist paired with an engineer. He took a social sciences class and she took an engineering class, just a front-end course to learn to write web pages. But she came back from that and she spoke on a panel with me at the Society for Applied Anthropology meetings, and what she said was, “Now I know why he needs a yes or no answer. He doesn’t want the ‘it depends’. There’s human behavior, there’s this context, give him a yes or no answer.” And now, because she took a class on writing code, she understood that the decisions need to be binary; you have to meet them where they are in terms of their decision-making process, and be realistic about how much you can really expect them to meet you in understanding human behavior.

Now there are engineers that are going to be fascinated by human behavior. Some of the guys in my team that made the switch from full-stack development to front-end development, they did that because they were interested in human behavior, but that’s not the norm for most engineers. Just be empathetic and aware of that, and then give them what they need to know so they can focus on doing the part of their job that they love.

Q: Jonathan Grove’s brief comment: “I describe research as a method of surfacing risk.”

A: I think that’s great because what that means is you’ve become attuned to the culture you’re operating in. Managing risk is the way that decisions get made, and so you have to align how you tell your story with what the business culture and the business discourse is, and that’s what you’ve done, makes great sense. And every business is different, even if we’re both in software companies, different software companies have different underlying drivers.

Q: I’m curious about how to provide more rounded education for designers, knowing that a lot of folks are learning business knowledge and ‘product-focused bootstrap’ or applied areas. This could be dangerous because designers then don’t truly know what they’re contributing towards, but more narrowly focused on whatever they’re trying to optimize for.

A: Yeah, yeah, I agree. And that’s actually one of the critiques, if you know the know the work of Christian Madsbjerg, he’s a founding principal at ReD Associates, and he’s written a couple books, one called The Moment of Clarity, and another called Sensemaking about the importance of liberal arts in the digital era. And he very, very critical of IDEO, and it’s exactly for this reason, because he says IDEO provides context, but context with a lower case C instead of context like cultural context, the way they do in the ethnographic work that’s done at ReD. And so, yeah, you feel like you’re solving the problem, but you don’t actually have enough context to know the true complexity of the problem. And I agree, that’s a risk, but that’s also a risk in any business that doesn’t wanna invest the time in doing research the right way. I think my answer to that, if you’re lucky enough to be in a product team, not in a consulting function.

So I have two teams, one in products and one in consulting, but we work with the same customers and on the same kind of business problems. The solution to that is longitudinal research and foundational research. And Don Norman wrote a great article about that, I can dig it up, it’s referenced on my blog somewhere. It was an inflammatory piece that basically said just go start designing. He said, “You want to sit at the table? Get yourself in there.” But his point was, if you’re in a product organization, you should have enough domain knowledge to get started right away, and you shouldn’t have to go do eight weeks of research to be part of the conversation. Now, of course, if you’re in a consulting role and it’s a new space, new domain, that’s obviously a lot harder, but the point is, is one of the things we’re working on right now is we’re building a program of foundational research so that we’re always learning new things, and so when new product ideas come we don’t have to commit to an eight or 12-week research effort to have something to contribute in the early stages of the conversation.

Q: How might we reward the balanced team, like product, UX, and design, and dev for delivering on both the business and user outcome?

A: So first of all, a nod to Balanced Team. I don’t know if anybody else is familiar with them, it’s a great concept. They do have a Slack channel, and they do some in-person meet-ups. It’s exactly this idea, I think, of what I called earlier transdisciplinary team. So Google it, look for Balanced Team, there’s a Slack. I can find the link to it and share it with you, but they are exactly talking about this, how do we work in a truly deeply integrated way, and of course then that leads to questions like how the impacts of those unique functions should then be acknowledged. But in my mind the reward is the same for everyone – buy your product, people download your product, people rate your product highly, people recommend your product. To me, because that is a user outcome and a business outcome at the same time. It’s that moment where those things overlap by 80% or 90% that you want the team to get focused on.

Q: What has the impact of these many education programs and boot camps been on the ability of specialists like designers, PMs, and researchers, to appreciate and address the needs of others in organizations?

A: The thing that comes to mind for me on this one, when Sam Yen was at SAP, and IBM have a lot in common. It’s this idea that everybody should have some common language around design and design thinking, and that creates fertile soil for design practitioners who might actually be trained in design or research to go in and do the work and guide the work of other people while still being the expert practitioner. So this idea that everyone’s a designer with a lower case D, but only certain people are designers with a capital D. At IBM they’ve trained 140,000 people in design thinking just through virtual training.

It will deepen the appreciation for the field. And just like if you want to go get the Jobs-To-Be-Done training to understand a little bit more about how product managers think about things, or if you wanna go take a class and learn how to code web pages by hand, though I don’t think anyone does that anymore. But yes, any of that kind of learning is going create mutual appreciation and understanding for how hard the work is. What we’re asking of people when we ask them to truly blur those disciplinary boundaries with us. It’s much harder, I think, than we really acknowledge when we ask for that.

Q: I really appreciate this talk, by the way, this has been really helpful to be able to listen to all of this. So as someone who came from a pretty distinctly academic background, part of my struggle has been making that shift and being able to bridge that gap between what I understand to be these design thinking methods and research methods that are connected specifically to UX and the design or the research background that I’m used to. And so I’m wondering if you can speak a little bit more to how to bridge that gap and make that leap because it seems to be pretty significant.

A: Where are you struggling to bridge?

Quite a bit of the research that I’m used to looking at is, at least now working in UX, is qualitative, and so trying to find ways to bridge from being able to quantify things and to being able to quantify qualitative things.

Oh, I have a funny story about that, actually, and we’re not gonna have time to get into the details, but I wrote a paper about it for the Ethnographic Practice and Industry Conference in, I wanna way, 2005. If you ping me … I just put my email in the chat, you can send me a note about it. But basically I did this ethnographic research, and I had to get it in front of a bunch of executives to get funding for a project, and I turned it into … I quantified it as a pie chart to get the executives’ attention. It’s one of those things, looking back on it, it was one of those really super embarrassing moments, to take ethnographic research and put it in a pie chart. And that pie chart followed me through the last 10 years of my SAP career like, “Oh, you’re the one that did the pie chart!” I’m like, “Oh god.” But you know what, it was the thing that opened the door to all these executive conversations, so I did it.

I would say in most of those cases, there’s been a great series of discussions in the ethnographic practice and industry community about the importance of qualitative and quantitative methods. So Martha Cotton, if you know her, she was at Gravity Tank, which is an innovation consultancy in Chicago, and she’s now at Fjord. And she did this talk with Neal Patel, who was at Google, about the importance of both qualitative and quantitative methods, and not being afraid. And he’s a statistician, and she’s a qualitative researcher. But all I can say is dive in, ask for help. I’ve actually thought myself about going back and taking a stats class just so that I would be a little bit more conversant.

Market researchers are actually very fluid in working across qual and quant, and they’ll be very happy to do your qual for you [chuckle] if you work with them. And they don’t realize, I think in a lot of cases, what they consider to be good research is very different than what we consider to be good research for purposes of design. And so we’re actually engaged in dialogue now with our market research team, where there’s some research work that they’re giving to us because they know we can do it better, and in turn we’re getting access to some qualitative chops that we didn’t necessarily have before. But it’s an important… It’s a thing not to be afraid of. It shouldn’t be an either/or it needs to be a both.

You know who has a brilliant talk on this is Tricia Wang. Search her on TED, and I know she did a talk at a recent Enterprise UX. But if you search Tricia Wang on TED, she has an amazing talk, she talks about Netflix redesigning the experience around binge-watching. How did they know to do that? They got that insight from ethnographic research. And once they got that insight about how people consume in binges they were able to change their whole experience and leverage and get all the machine learning and AI to support that way of consuming content. But it was the ethnographic research that triggered that whole way that Netflix provides that consumption model now. But she has a great talk, definitely would encourage you to go to watch it, and there’s other… Like I said, in the EPIC community, a number of other papers and presentations you could watch on that topic to get you started.

In closing

I hope you enjoyed this post. You can join the community and participate in future session by signing up here – https://rosenfeldmedia.com/advancing-research-community. We’re working on a new conference! It’s planned for the end of March 2020. Stay tuned for more on that shortly …