Category: workplace

Reading Time: 27 minutesI 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!

Presentation

I broke the voice over into three smaller videos so it would be easier to stream:

1. Introduction & UX is Emotional Labor
2. True collaboration across disciplines is hard
3. How will we improve business outcomes?

Transcription

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.

[applause]