This blog post is focused on my chronic health issues, specifically, learning to detox heavy metals using the Andy Cutler Chelation (ACC) protocol. In early July I posted about my first six months of learning about and starting ACC. I was unsure whether I would continue to track my chelation progress, but given that my brain fog comes and goes, it has been helpful for me to write things down. It has been enough of a rollercoaster that I think others would benefit from following my experience, so I am going to continue where I left off with my first Chelation Chronicles blog post.
18 July. I am feeling like crap – the worst I can remember since starting chelation. I posted to the ACC group on Facebook looking for advice, and it’s pretty clear that I’m dealing with redistribution from my dose of ALA being too high. I just have to do everything I can to mitigate the discomfort (manage the headaches, rest as much as possible). One good suggestion was to do just DMSA on my next round, to clean up my system and get back to a good place. Read More
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.
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 …
I am pleased to share that the latest issue of the Journal of Business Anthropology was just released, and I have an article in it. The piece is called “An Uneasy Truce: Navigating Interdisciplinary Collaboration in the Software Industry”.
A download is available here – An Uneasy Truce.
This is a special issue about Anthropology and Design, which is an outcome of a panel I was a part of at the American Anthropology Association meetings in 2016. You can learn more about the original AAA panel here, or peruse the complete table of contents for this issue on the JBA website.
I was invited to deliver the opening keynote at the UX Camp Chicago, which took place last weekend. My presentation was entitled Collaboration by Design: Engaging Deeply for Better Business Outcomes. It was a welcoming audience, and I was glad to have a chance to further articulate my thinking on the challenges and opportunities related to collaboration in interdisciplinary teams.
In this post, you’ll find a voice-over of my slides, and a full transcription below that. Enjoy!
I broke the voice over into three smaller videos so it would be easier to stream:
- Introduction & UX is Emotional Labor
- True collaboration across disciplines is hard
- How will we improve business outcomes?
I’m looking forward to sharing with you a little bit about some of the thinking that I’ve been doing about how to mature the UX function we have at ZS. ZS is a professional services firm, we focus on life sciences, so pharmaceutical medical device companies, and I have two teams there, one on the product side with product designers and another in consulting. Those are two very, very different types of UX work but, in fact, there’s a lot of common ground in the types of challenges that those UX teams face. And I wanna talk a little bit about that today. And what we’ve learned as we go about how to mature, what we’re doing in design and really deliver better outcomes to the business because of how we work together with our teams.
I wanna talk about two questions that have come up over and over again in my team that to me, they’re really intertwined questions. The first one is, how do we more effectively integrate with the teams that we’re working in? And then the other one is, how do we amplify? When I say amplify I’m talking about the voice of the user, so I wanna talk a little bit about both of those things because what I’ve learned, those questions come up over and over and over again, and the questions, and the answer is intertwined. So that’s what I’m gonna talk about today, is what we’ve learned about that and how actually addressing one helps to address the other as well.
So how do we integrate? And I think if you’re following anything about what’s going on in the blogging world or with UX people, writing on Medium or whatever, you do to stay current about UX, you hear people talking about, “Hey how do you get UX embedded into the product teams or into the development teams or into the Agile process? We all have that question about… We know we would be more impactful if we were better integrated in the teams that we work in, and how do we do that, what… How do we actually make that happen? And related to that, this idea of amplification. So I want to talk about this concept, so from the Enterprise UX conference, a couple of years ago, Maria Guidice is the VP of experience design at Autodesk and she leads a team of about 300-400 designers but none of them report to her, sort of a weird situation that she’s in. And her question is, How do I create a sense of team identity and team culture and cohesion, when those people don’t report to me? And so, that word amplify really stuck with me as something that I needed to carry forward and actually have a little sticker at my desk that says, “amplify or amplification.” To just think about how do we do that?
For me, amplification is also… Part of our job is amplifying the voice of the user, of the patient, of the consumer, whoever it is that we’re trying to enable with our design capabilities, and that’s something that we feel a lot of urgency around. We want people to understand, we wanna shake people and say, “Don’t you understand, this is what the users think, this is what the users are experiencing.” And the challenge is there’s so few of us and so many of them, and how do we impart that? So how do we amplify the messages about the people we’re trying to enable with our designs in a way that gets really gets the word out so that we’re not the only ones doing the talking and advocating for those users. Okay, so those are the two inter-twinned questions. How do we integrate? How do we amplify?
I wanna talk about this concept of emotional labor. So Russ didn’t do… You may have read my bio on the website, but my background is as an anthropologist, so I have a social sciences background, I’ve also been trained in design theory, so you’ll see some little spatterings of the academic part of my life in this talk, and emotional labor is a concept, I wanna just talk to you about and you may have heard of before.
Emotional labor, is when you have to control your emotions in some way because of your work. So a nurse for example has to manage their emotions in relation to a patient who might be suffering. If you’re in a customer service, you might have to smile, even if someone is not treating you well on the other end of the phone or at the opposite side of the counter, or whatever that looks like. So having to manage your emotions, that’s Emotional Labor, that’s a term from a sociologist and I think, for us in UX that’s just a reality. If you really care about the users that you’re designing for, you feel what those users need. You viscerally feel it, and it’s very hard sometimes to manage that because if you’re the only one that feels that if your teams don’t come with you for usability testing or they don’t come shadowing you, you’re holding that experience of the user and you feel just this tremendous responsibility and that is a form of emotional labor.
And what happens, at least in my experience, is if you’re the one doing all that emotional work and the people around you aren’t doing it with you, it creates a chasm between the two parts of the team, it creates a rift and because you have all this emotion and this emotional output that you’re sort of bearing on behalf of those users, or those patients, or whatever it is and the engineers, or the other stakeholders that haven’t had those experiences with you, that sort of emotion that you’re putting out there can shut people off, or turn people away. And so the challenge is, how do you do the work of amplifying those emotions and getting them out in a way that doesn’t turn off the teams that you’re working with? And doesn’t make that sense of divide feel even more serious than it might already be.
This is to reflect staffing ratios. So I don’t know how much you… What your working environment is like. I’ve always worked in very, very engineering-heavy cultures. I worked at SAP, which is a giant software company where the staffing ratios of design to engineering are always really tough and even where I work now, even though I’m a partner where I work now, and we really struggle still to get as much design talent, as we need to have properly balanced teams, and what we do in our cases, we just make tough decisions and there’s a lot of stuff that just doesn’t get staffed, so we can put the proper ratios where they’re needed. We have for example, business stakeholder and product managers at the top in green and blue and then you have a sea of engineers, right? And you might have just a few researchers and designers, and so you’re always in the situation where you feel like you’re getting drown out because there’s so many other people that have something to say. And that UX perspective, that brings the voice of the user, is sort of muffled in the noise of all of these other people.
The thing that we need to not forget of and lose sight and this is not to be discouraging about it but to be very practical is, look, the way that we’re graduating engineers and designers today, it’s not gonna get better, it’s just astounding. I think there’s something like 200,000 graduates in engineering across undergrad, Masters and PhD every year just in the US, there’s a million plus in India, but just in the US 200,000. And product and industrial design in the US graduates 2,000 people here. Okay. So the point is not to be super dis… I mean it’s job security, so nothing to be upset about, in that regard, but just important to realize that we’re not gonna be successful in really advocating on behalf of the users, and the patients and the customers we serve. If there aren’t other people telling the story besides us.
And so that’s really what I wanna talk about is this idea, that’s what I mean when I say amplification is, all that sea of teal engineers and those many, many people that you work with that aren’t trained in design. We have to bring them along with us, if we’re gonna do our best work and we’ll make the kind of business impact that we know design can make, really requires that we find ways to build bridges to those other disciplines. However, collaborating across disciplines is really hard and I don’t wanna underestimate this and understate it. It’s… I wanna do two things. I’m gonna talk a little bit about the academic research around collaboration because I think it is important to have some shared language around that, but what I wanna really do in this is, this part of the talk to is get more deeply into what does it mean to deeply collaborate with someone in another discipline, what can we do differently to help build those bridges and make those connections that we need in order to do our best work.
I think an important thing to not forget, and though you may know this from your own experiences, we wanna collaborate because co-creation is fun and participatory design is fun. And most of us were trained that that’s how the best work happens. But the reality is, not everybody that you work with has the desire to operate in that way, and that in and of itself is sort of a hurdle to overcome. People don’t all love to play with post-its and sharpies and do affinity mapping and [09:24] ____ mapping, and all those things that we love so much about our jobs. But the reality is, is that we have to recognize that. Not everyone’s gonna wanna come and participate with us, in the way we wanna participate.
There’s a really wonderful paper about the nature of collaboration from two social scientists, and I can certainly give you the citation if you want it after the talk. Dr. Bernard Choi and Dr. Anita Pak. And they talk about different levels of collaboration and just to walk through these at a high level in a multi-disciplinary teams are they’re sort of all working on the same problem, but they’re not necessarily working on them in an integrated way, they’re all kind of working in their own little bits and pieces. And this is not uncommon, we see it even in the teams that we support today. I’m not pretending our teams are perfect, but you know sometimes people wanna be heads down and just do their own work and not necessarily think about, what would it mean to really work together.
In a better situation is when you have an interdisciplinary … Again this is their language, and I’ll use these words interchangeably. I typically use the word “interdisciplinary”, it’s the easiest one to say, I think, but the interdisciplinary means that there is some desire and interest in overlap, and in working together in a way that gets us to a better outcome. So there’s some realization that, yeah, the BA really, really does need to sit down and spend that time with the UX person or the product manager really does need to be part of the research efforts in order to understand where the product should go.
This ideal state, which is I think, in my mind, when I think about how we talk about participatory design, and co-creation, I think for us, this is what we want, we want this truly integrated team where people care as much about our work and the outcomes that we’re delivering as they care about their own. One of the reasons I do think that we end up sort of unhappy or discouraged in our team work is because we wanna be operating in this transdisciplinary model and most of our colleagues don’t. And so I think recognizing that and acknowledging that and realizing that that’s your own baggage if you will, or your own sort of expectations that you need to manage is a big part of the challenge. And part of the reason I wanted to give you this language is to realize that if you’re feeling that friction, or That unhappiness is because you’re really hoping everyone’s gonna come and participate with you, and not everyone necessarily wants to do that.
And the question is, why does it matter? Not just because it leads to better design outcomes but actually, what we know research now we know is a diversity of all kinds, leads to better business outcomes. So whether you’re a diversity of gender, diversity of race, diversity of sexual orientation, of financial means, of disciplinary differences those differences are actually what make for the best and most innovative outcomes. And we know that instinctively we know that… And now there’s tons and tons of research that supports that. There is… I feel sort of a responsibility on our part to try to make this happen because we will get better outcomes on the work that we do if we do it with a team that’s not just a bunch of designers.
And so the question is, knowing all that, how do we bridge that divide or that gap between what we know to be great, what we know to be the ways that we like to work and the reality of the teams that we’re working in today that might not share those desires.
Before I get into the case studies, I’m gonna give you another sort of tool, some more language around thinking about how you work with other people. This is a piece called the Ladder Of Inference. It’s from a management theorist from Harvard Business School and I was given this in my coaching and I use it a lot with my teams now. What happens a lot of times is you have an experience and you make some assumptions about that experience and you draw conclusions, and the reality is that there’s a lot more steps that are happening there, that are unconscious, and that you need to be aware of in order to actually take those experiences and use them to achieve some kind of alignment.
I’ll give a very specific story. So one of my mentors, Gitti Jordan she passed away a few years ago, from pancreatic cancer, but she was a force in the world of Applied Anthropology, just this unbelievable woman. She for many years, worked at Xerox PARC and at Xerox when they did research, they always did video, and they always analyzed the video afterwards and they did that analysis with the engineers and what they learned in that process was that the engineers literally see different things, so they’re already on this next step of having selected some facts from whatever they’ve observed in that video, and one of the things that Gitti spent a lot of time doing was saying, “What did we observe?” and then working our way up the ladder of inference to what kinds of conclusions we can draw from that, from what we heard.
Because the reality is, if you’re trained in a different field, what you observe is gonna be completely different. So even as you get to that second step of a ladder and you’ve already started to slough off the things that you don’t think is important, right away there’re decisions being made and what happens and that is you have this split and the further up you go, the wider the rift becomes between the conclusions and the assumptions and the actions that people think are required.
And the way to resolve that is to get back to the data and work the way up the ladder of the inference together. And that’s one of the reasons that things like having engineers attend usability testing can be useful. It’s not useful though, if they just attend and you don’t have a really meaningful rich conversation after it, about the conclusions that you’ve drawn from what you’ve observed because they’re gonna come to very different conclusions and it’s normal and natural based on their life experience, based on their training. It’s very, very important to… If you think usability testing is gonna be a miraculous to change an engineer, or a product manager, or a stakeholder you’re truly mistaken. It really comes from working through this conversation together.
If any of you did any poking around or read my bio, before the talk today, you may have noticed that I’m associated with a group called anthrodesign, which I founded more than 15 years ago, and that as a group, now over 3000 people globally. You’re welcome to join us. It’s a group of people that are using ethnographic research methods in the business setting, and it was intended to create interdisciplinary dialogue between anthropologists and designers about how we could work more effectively together, and what we could learn from each other.
And I have a whole separate talk that I’ve done about this, about what we’ve learned over the years but just to give you an example, I mentioned I’m trained as an anthropologist, and one of the first hire I ever made when I built my first UX team, was I hired a designer. Why did I hire a designer? I hired a designer because I had all these ideas I had collected all this research but I didn’t know how to represent those ideas in a way where I could get stakeholder buy-in to make design changes or make a design decision.
What I learned is, in that collaboration, in those early days of collaborating across the social sciences and design was anthropologists are trained to think very broadly, and thematically about ideas and problems and designers in contrast, the way that they’re trained inherently is through a case study approach where you’re given a set of materials, the business problem, the stakeholder, you have to solve a design problem, within constraints and anthropologists are not trained that way at all. And so when we get into the business world, oftentimes we really struggle to take all these great ideas that we have and make them realizable in the business setting, and that partnership with design is part of the ways that social scientists have become more effective in business because designers know how to make it real, because they’ve had that experience in their training. And so over the course of these now, I think anthrodesign is now, I wanna say 17 years old. I wrote a post called, Origins of anthrodesign. I think that was a couple of years ago now, so 16 or 17 years old. And in the meantime, what’s happened is, it spawned a conference which is called EPIC, Ethnographic Praxis in Industry.
There are also six or seven books that have been written on this topic, and countless conference panels and presentations and journal articles about this idea about the collaboration across social sciences and design. My point of all this is that … is that one tiny little partnership that we have in our work. And if you remember the bubbles, I do earlier, like getting the researchers and designers to work together better is obviously a really important part of the equation, but we have all these other stakeholders we work with and we haven’t done that same work that same journey we’ve been on for the past 15 years in this anthrodesign community, we haven’t done the same.
And thinking about how do we work, truly work with product managers, how do we truly work with engineers? A lot of the research that I’ve read, when I look at that collaboration space is, how do we make the engineers more empathetic how do we involve engineers in the design process? It’s all about how do we fix the engineers because they’re broken and on that whole mentality is part of why we have this divide between us and them. And so again these next couple of slides, these next three, I wanna talk about three kinds of collaboration and just think about what we… ‘Cause all we can control is ourselves anyway. We can’t control that there are many, many more engineers coming into the market, than designers and so on. But let’s talk about in the context of our own work, what are the things that we can do differently to start to build bridges to those most important relationships we have, beyond the research and design relationship that I just described. So I wanna talk about three one is relationship with product management, the other is the relationship with engineering. And then finally, for those of you that are in teams that have a QA function, I wanna talk a little bit about the ways that we might collaborate more effectively with our Quality Assurance teams.
Okay, so I’m gonna dig a little bit more into those three. So my slide was supposed to build and it’s not doing that so let’s just see what happened there. Lovely … it’s okay. [laughter]
I wanna start from the bottom and worked my way up. So if you’re in a very engineering-centric environment, one of the things that’s pretty common is different… Tracking different usage metrics. How do I … How many users are using the system, how frequently are they using the system? And those are metrics that really come from an engineering and technology mindset about things, like “Is my server-sized appropriately?” “Are my APIs performing?”, right? It has to … those are really sort of technology-oriented metrics and actually it’s also some of the easiest stuff to track if you have a sloppy Google Analytics implementation, those are the kinds of things you can track.
The reality is that tells you almost nothing. These are called vanity metrics. You guys have probably all heard that term before, but the idea is if what you’re thinking about is how many users are using my system. How many number of daily users do we have? Those are essentially meaningless except truly for sizing servers and networks, and those kinds of things.
And if you get stuck in that way, of thinking about it, you’re gonna find yourself in a really disconnected from the things your product managers care about. Because your product managers care about the stuff in orange at the top. And I’ll get to that in just a minute.
One of the other things, if you’re a little bit more mature and hopefully you are and you have a little research capability or maybe you’re a designer, a team of one, doing your own research, you start to look at other kinds of metrics related to user behavior. Is my… Are my users able to traverse the system and complete transactions? Is the system sticky, are people satisfied with the solution? Those are really good important metrics as well, but they’re also metrics that are kind of… They’re UX metrics. They’re things that we care about, if you think about ISO9241, so the way that we measure usability, a lot of these types of measurements come from the way that we’ve historically measured usability.
And there’s nothing inherently wrong with that. For something like satisfaction for example, we know that employee satisfaction correlates to customer satisfaction, so it’s not a bad thing to understand the satisfaction of a tool and people that are satisfied tend to buy again or tend to be more loyal or tend to refer, so there are benefits to understanding things like satisfaction but in the end, what really matters is, is this thing that I’m doing having a business impact a measurable business outcome, is it driving revenue, is it driving retention, is it driving people buying something a second time, is it driving market share? I don’t know if any of you know the work of Leah Buley. But she wrote the book Team of One. If you haven’t and you’re in a small team, you might really enjoy that.
Some time after writing that book, she went to go work at Forrester, which is an analyst firm. And she worked there for a few years. And she said it was an amazing experience to work across so, so many different customers at a senior level to kinda see what challenges … What kind of challenges the companies face. And what she took away from that, she wrote a fantastic blog post, on Medium, when she left Forrester. And it’s just… it was kind of a wildfire, this blog post. Because what she said is her take away from her time at Forrester was that UX does not understand business and we’re never gonna be relevant until we understand business.
And the challenge with product managers for us in our relationship with product managers, is they’re that bridge to business, to business outcomes, to business stakeholders. Now, every team is organized differently, but in the most mature organizations, the product manager owns the product line, the profit and loss statement, or the P&L for the product. The engineers report to them, UX reports to them. They serve as the general manager of that business of the product, that they’re responsible for. So they’re keenly aware and thinking like a CEO, about the business outcome that they’re expected to deliver with this product that they’re bringing to market. If you come and you talk about these things on the bottom of this KPI framework and not related to the things at the top, your product managers are gonna be incredibly frustrated with you.
Because they are worried about the stuff on the top. They’re on the line for the revenue, or the conversions or the license attainment or whatever those things are. And so one of the things to think about is if you are measuring things either at the bottom or in the middle, is to make a conscious effort to trace what you’re doing to the things that that product manager cares about.
Okay, so find out, what are they accountable for? Even ask them – “What are you compensated for?” “What are your key metrics?” “What does the product need to deliver on?” And if you’re collecting a bunch of data about users, that doesn’t roll up into the orange, you’re not relevant. It’s as simple as that. And so you have to really be thinking about what are you doing, what data are you collecting that is in the interests of the business and those business outcomes. And making sure that you’re doing that in a way, and that’s gonna build tremendous bridges and credibility to your product management team. Okay, any questions about that one before I move on? It’s a pretty dense slide.
Alright. Engineer. So I touched on this earlier. I think there’s this idea that, “Oh we should just bring engineers to usability testing, and that will fix everything.” And I think it’s just such a naive thing that we think that, “Oh, if they just see what we see.” But they’re not gonna be looking at the same things. Again, coming back to that ladder of reference. They’re not even gonna be looking at the same things that you’re looking at. So how can you expect them to come to the same conclusions?
And so it’s really important if you wanna engage your engineers. I think it’s fantastic, by the way, I’m not suggesting you shouldn’t do it, do it and do it, do it again. Do it with stakeholders do it with engineers, product managers. Anyone who will come, absolutely, get them involved in whatever form of research you’re doing. I just used here Usability Testing as an example. As an anthropologist, my favorite is always anything that’s in context and it’s ecologically relevant whether that’s Ethnographic Research or something like that.
I want to just tell a little story. I have a friend who was… She was an anthropologist at the time at Pitney Bowes. And she was in a small triad with an engineer, a designer, and an anthropologist, and that’s how the little innovation teams at Pitney Bowes were organized. I did a panel and I invited her and her engineer to come and talk at this panel at the Society for Applied Anthropology meetings. And one of the things that they shared about how they built trust and understanding with one another is that he took a social sciences class, and she took what she called a coding class, so she learned a little bit about front-end development.
And when she came back from that experience and she spoke at this panel, she said, “Now I know why he needs a yes or no answer.” She had never really understood. Because anthropology it’s always “Oh it depends, human behavior’s so complicated and there’s so many different ways that this could go and people are different. And there’s no one … ” Even we say in anthropology in particular, personas are so redacted and simplified they don’t really express the complexity of human experience. As anthropologists especially, I think we struggle to simplify things to the point that they can actually be consumed by engineers.
And what she learned and what she took away from that, is she really had to change how she was thinking about and packaging what she was doing for that engineer, so he could actually use the information that she had produced.
And so thinking about that here … We take some things away from usability testing, and we expect that those are things that are deeply understood by everybody who’s observing what we’re observing. And that’s just not the case, the engineer in the end has to make some binary decision literally binary decision about how something should look and how it should behave. And if you don’t do the work of helping them move up the ladder of inference from what was observed into what that means for the code, you’re gonna get a crappy outcome. You’re not gonna get the outcome you want because they’re not able to make that leap without you doing it with them.
And so I know this just means that the UX effort is actually much more significant than you’d like to believe. You can’t just come to usability testing or do a read-out and then expect everybody’s gonna know what to do. You actually have to do the work of pulling that up, pulling it through, pulling it up the ladder of inference if you will, so that people really understand the significance of what you found.
One more example that talk a little bit about QA. This is some artifacts that we use in our work, so a summary of what we call user types. We don’t… In the enterprise space, typically we don’t… In our world anyway, we don’t really work with personas because that sort of level of fidelity isn’t necessarily necessary. And so for us user types, typically reflect job roles. So you might have a sales person or a sales manager or a marketing manager for example, and we don’t get to that level of… A little bit we do. So for salespeople, tenure in role is a really important distinction like a very seasoned sales rep versus a more experienced one.
And so, we might, if we do recruiting, or whatever we might make those kinds of distinctions. But we don’t really develop personas, at the level of detail that you might if you were in the consumer space. So we have what we call user types, to make clear that they’re not personas.
So different levels of those. And then we do … when we’re doing some kind of usability testing or even as we’re … as a complement to a requirements document outlining in a very simple way all the user tasks associated with a tool or a set of tools, or a service that we’re building, and outlining for whom those … Who’s supposed to use, which aspects of the tool. And so I wanna just talk … One of the things that happened to me when I started at ZS a little over seven years ago now, was I went to head… Talked to the functional lead of those different departments. So Head of Engineering, Head of QA and just to try to get to know them and think about how we could work together more effectively.
And one of my questions for QA is “How are you testing the front-end today?” “How do you make decisions about what to test?” And what I learned is they were just using their best judgment, no one had ever bothered to ask them. So they took whatever they got from engineering, and they just used their best judgment, to make decisions about what to test. And so it was no surprise that things would go out the door and the things that we thought were important, maybe weren’t adequately tested, and so on.
So one of the things that we started to do. In the teams that are receptive or interested in doing that is thinking about involving QA … QA feels the same sense of disconnect, as we might feel. We feel, “Oh, I’m disconnected from product management.” Or we all sort of feel like maybe we’re not fully included in whatever conversations are going on. QA by the way, feels the exact same thing. They’re like, “Hey someone designed a product, researched a product, decided on a product, research designed a product, engineered a product, and we get the whatever is left over, and we have to deal with it.” QA wants to be involved upstream in the process just as much as we do. And so thinking about how to do that, involving them in, design reviews for example, so that they see that the design intent, and the way the design is supposed to look while it’s still a mock-up, so when it gets to the point where it’s in code that they can see that there’s a gap between what you designed and what was built.
And if you’re doing front-end testing … if you’re an environment doing front-end testing with something like Selenium. Knowing which transactions and which parts of the systems matter most to the users will ensure that those get tested. But if you don’t do that, who’s gonna do it, who’s gonna describe that?
And so I think there’s an opportunity there, I think, to build bridges with QA and that does end up having benefits in the long run because they’ll watch out for you, too. If your design comes looking at all… What comes out of Engineering, looking all wonky, if you have made a good connection with QA, they’re gonna help you address that. Because you’ve made the effort to build those connections. So that’s just another example. Now, I realize not everyone has a mature QA function, ours is pretty sophisticated, we have people that test by hand and then we have what we call PSR (Performance Scalability and Reliability testing), which is like large scale automated testing and so we have a pretty sophisticated QA function, where we are. Not everyone has that. So I recognize it’s not necessarily relevant for everyone here.
So what I wanna talk about now is… So we’ve talked about this idea of how do we more deeply integrate in a way that hopefully helps elevate the voice of the user, in the work that we do. And then the end game as I mentioned in that slide about KPIs, the end game is ultimately business outcomes. For us, it feels like it’s making sure the user’s needs are met, but the reality, it’s about business outcomes. And so the question is, what role do we play in enabling those business outcomes and what does collaboration have to do with that?
So, this is another sort of … it’s not intended to be a really discouraging fact, but it’s a reality. I’ve been doing this now for 20 years before UX was called UX. More than 50% of technology projects fail. Okay, so if you feel like, Oh, maybe I just got the short end of the stick with the portfolio of work I’ve done, it’s just the reality. That many, many technology projects fail for a variety of reasons. And the statistics range as low as 31 and as high as 68. But just to give you a sense of the fact that a lot of projects… A lot of projects don’t succeed and obviously that has a huge business cost. If you’re on a project that’s been going for six months or a year or longer, and then the plug gets pulled on that it’s a huge waste of money, and resources, it’s demoralizing.
It does cause a lot of people to quit. So it also creates a churn in terms of attrition of employees. And so it has a significant cost, and the question is what’s underlying those failures? As it turns out, dysfunctional teams, make dysfunctional products.
So if you have a team … this is from … I can share the citations with you, if you’re interested. This is from a Harvard Business Review article that was written, I think in 2015. If your team is dysfunctional your product’s gonna reflect that dysfunction.
Until we make the effort to fix how our teams work together, we’re not gonna ship better product, Okay. And I think important to talk about this is like, “Why does that dysfunction happen?” ‘Cause you might have a fabulous kick-off, and fabulous sponsorship at the beginning and you might think, “Oh, this one’s gonna be great.” And then things start to kind of slowly unravel. And why do they unravel?
There’s this term that is in this article called “alignment attrition” and this idea that over time people make small small decisions independently that because them to come out of alignment with each other. And what’s the solution to that or what’s one of the best ways to keep that from happening is actually visual artifacts that represent the shared understanding.
And what a powerful place for us as UX professionals that we can help create those visual artifacts that represent the alignment that we’ve achieved as a team and we can bring people back to those artifacts again, and again, to make sure that we don’t experience that alignment attrition in our products over time.
Hopefully, you are all familiar with the Design Management Institute and their survey about design value. This is a fantastic… Hasn’t been done since 2015. This 2015 graph represents data of companies from 2004 to 2014. It’s a phenomenal story. It say that companies that are design led are over 200% more profitable than the rest of the S&P 500. So, we know now we have the data that shows that design-led companies drive huge business impact. This is the Apples of the world, up here in these … and IBMs. These companies that are really truly investing in design and design-led. Now will everyone believe you? Do all the executives that you work with care? Do people that run engineering understand or care about this kind of study? Maybe not. But we know that getting design in a role, integral into the work that we’re doing is gonna lead to much, much better outcome. So again, that personal responsibility we have to make sure that we’re bringing our work into the context where we can have the most business outcome.
I think challenge that we face … and I’ve talked about this a couple of different ways before is … we tend to get enamored with our own processes and our own artifacts. We think, “Oh, Participatory Design is so great, our exercises with post-its that bring everyone along is so great. And isn’t usability testing like the best thing ever.” I love my job, I love all the things that make up my job, but that’s sort of being enamored (and somebody else has called it sort of fetishism) with your own work is actually a barrier. Because if you’re so enamored with how you do things and be… And you’re precious about how you get things done, you push people away instead of bring them in.
As awareness of design thinking grows everyone talks about empathy as being so important. If I hear another management review like business article talking about empathy, it’s just so frustrating, right? It’s everywhere. And it’s for sure it’s commoditized. And we see and we hear, and yet we know because of the emotional labor in our jobs that we’re doing that work, a lot of people are paying lip service to it, but in our job, we know we’re doing that.
The challenge that we have is how to bring that empathy to our own teams. Not just to the end users or the patients or the consumers that we serve which I think we take such a tremendous personal responsibility for. And that’s what leads to that weight of that emotional labor. But why aren’t we doing that within our own teams? And recognizing that our teams are feeling isolated or not connected or not integrated and that we have the tools and the skills and the experience, and the empathy to help make those connections, and make the team feel more connected, which is… I’m not suggesting we should do all the work. I’m just saying there’s a part of this that we can take responsibility for and take action on and that we should.
And I think the point of all this is not just to make … You are not just working in a better team or delivering a better product, or a better outcome, but I think really the next step is actually changing the field and improving the value and the impact of UX much, much more broadly.
And I’ve seen it happen in the work we’ve done with anthrodesign. Where as we develop a shared language, and shared ways of working, that we’re able to make a greater and greater impact in our field because we’ve made some of these and built some of these bridges. And we have a responsibility now in UX and in design to do that, too, to not just make our own team better, our own product but really to deepen and improve what the field can do by improving this collaboration.
So, just in closing, I think what we all hold near and dear to ourselves is this idea of amplifying the voice of the user. And making sure that those people’s needs are heard. If you’re looking at chronically ill patients, or sales reps or whatever it is, whoever it is, that you’re enabling with your design skills or UX skills what you care about is making sure that those voices get heard.
And what I’m telling you is, until you deeply, deeply integrate in the teams that you work in, you’re not gonna get that done. So the goal is integrate so that we can amplify those messages. Okay? That’s it.
Closing Keynote: Design at Scale
Doug Powell, Vice President of Design, IBM Design
From the Design Operations Summit website:
More than 50 years ago, Thomas Watson Jr., the second President of IBM declared, “Good design is good business”. Today, the global company continues to operate on the belief that human experiences drive business. Doug Powell, Distinguished Designer at IBM, will expose what it means to practice design at the global tech company, exploring the inner workings of the largest UX design operation in the world. He will also elaborate on a new Forrester Research study examining the value of design and the design thinking practice at IBM.