Navigating environments of complexity and transformation: How designers can become effective agents of change

May 172:35 pm – 3:10 pmStage: Main StageTalk
Slides

Checking session availability…

Hang tight while we load the latest updates.

Large enterprise companies are more than ever embarking on high-paced digital transformations and reinventions to stay relevant and competitive. In-house design teams have become a key part of those endeavours and as a result designers have tremendous opportunity to work on projects of exciting complexity, scope, and impact.

However, the reality of being an in-house designer supporting transformative change can often be a challenging experience. Managing complex stakeholders groups, educating and articulating the value of design, navigating intricate technical restraints; all while canvassing for the end-user. It's a lot to figure out!

In this 25-minute talk, Jeff will share what he's learned over the course of a decade navigating and working on complex projects for enterprise companies as both a designer and more recently as design director leading teams.

Are you a designer or design manager considering moving in-house, or are you currently working in environments of digital transformation and complex problem spaces? Then this talk will teach you how to take the tools, frameworks and concepts you use to design digital experiences in your day-to-day work and how to put those to work to help you navigate and persuade your way to becoming a more effective agent of change

Navigating environments of complexity and transformation: How designers can become effective agents of change

Jeff Simons at UXDX USA. Video: https://youtu.be/qteqVjvgV0w

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and Charles River Laboratories

[00:00:01] Hello everyone. Oh, it's good to see you all. I've been sitting amongst you now for the past while, and I've been like, okay, Wednesday afternoon, Wednesday afternoon, yeah. But now I'm here. Great, thanks, good to be here. My name is Jeff Simons, and I'm talking about navigating environments of complexity and transformation, and how UX designers can become more effective agents of change.

[00:00:33] A little bit about me. You might hear from my accent that I'm a little bit weird-sounding, and that's because I'm from The Hague, the Netherlands, the tiny country in Europe. A few years ago, about a decade ago now actually, I moved to Ireland. I moved from the big city to the countryside, amongst the greenery and the mountains and all that. I live there together with my wife and our two doggies. Over the course of my career I have fallen in love with designing for an enterprise context, for B2B experiences, that kind of thing. Over the past 15 years or so I've worked at a mix of both in-house product teams and consultancies doing just that.

[00:01:18] I currently work as a director of product design at a company called Charles River Laboratories. Charles River Labs is a contract research organization, and essentially what that means is that it's an organization that helps companies develop drugs and medical therapeutics, for all kinds of organizations worldwide. It can be from things like vaccines to cancer medication to even something as simple as Tylenol. So really everything across that spectrum.

[00:01:46] It's quite a large company, consisting of about 20,000 people or so worldwide. I'm part of the, comparatively, very humble 20-person design team, but we're small but mighty. We in turn are part of the Global Technology Group, who are essentially helping the company with the digital transformation that it embarked on a couple of years ago.

Change, exhaustion and losing control

[00:02:13] The thing with the likes of digital transformations is that they're all about change. So I'd like to talk a little bit about change itself, and what we can learn from that as designers. You may be familiar with this quote, "the only constant is change," from a Greek philosopher gentleman whose name I will not dare to butcher live on stage in front of an audience. But it's probably fair to say that for a lot of us, change has been fairly abundant. We've seen quite a lot of change these past two, three years. It's everything from pandemics and wars, civil unrest, food and goods shortages, to, within our own industry, in our hiring markets, incredible ups and the incredible lows, which we've heard some speakers talk about as well.

[00:03:09] Now, you might look at this and say, okay, apart from the hiring market thing, how does that affect me as a designer day to day? Hopefully the majority doesn't, with the exception of the pandemic. But the reality is that a lot of that stuff that's market-related does have an effect on our employers, which in turn has an effect on us. It's things like breaking into new markets, going deeper into existing markets, spin-offs, layoffs, mergers, acquisitions, the whole lot. All of that has an effect on the mandate that we're given as designers, and on the product teams that we're part of, to act on all that change.

[00:03:52] Companies are essentially forced to reinvent themselves constantly. So essentially we're experiencing this cascade of change. The things we're seeing on a larger level make their way all the way down to us, mere cogs in the machine working for companies on a smaller level.

[00:04:09] But the thing is, I don't know about you, but I've gotten to a stage where I'm actually exhausted. I'm exhausted from the change. Does anyone else feel this way? Yeah, right. Well, you're not alone. It's us together that have become exhausted from all this change. Burnout is probably more prevalent than ever before, and so it's not uncommon that you feel this way.

[00:04:37] People have spent the past few years honing their crafts, only to decide to upend their lives and essentially abandon being a designer and become flower farmers, or open coffee shops, or pick up trades like carpentry or plumbing. Things that have nothing to do with making software. And actually it sounds kind of nice, to a certain degree.

[00:05:00] I have a theory. While I'm sure there are many reasons why people choose to make a decision like that, I have a theory that it has to do with people feeling like they have less and less control over the outcome of the work that they do on a daily basis. It's things like decisions on our work that are seemingly coming from some random person in the company somewhere. Or your stakeholders that are more enamored with their own ideas as opposed to the research that you're presenting to them. Or it's system dependencies upon system dependencies, legacy software, and I feel quite passionate about this, that are ultimately determining the user experience that you design. No matter how lovely it is in Figma, ultimately it might feel disjointed and unrefined because of all of those layers of complexity.

[00:05:55] In other words, these are the kinds of things that make you feel like you have no control over the output of the work you're doing. It doesn't matter how hard you work, because with all this complexity it essentially makes you feel like you have no control. And that just happens to be one of the primary drivers of burnout.

[00:06:13] Now, if you've felt like that recently, and you're a designer in a mid to large enterprise company, which I think a lot of you are, from speaking to a few of you this week, then part of the outcome of today's talk is to give you some tools and ideas on how to approach change and give you back a bit of control. To basically make some of those uncontrollables that we spoke about earlier into more controllables. While it certainly might not be the silver bullet to cure your feelings of overwhelm or burnout, I'm not doing that with my humble presentation, I hope that it gives you some ideas on how to make some of those things more controllable.

Three ways to become an agent of change

[00:06:53] To start with the end, here is what you can expect to learn from the talk today. The main theme of this talk is that I feel that you have all the tools you need to bring about the change that you're hoping to make as a designer, but you've just got to use them a little bit differently. There are three ways you're going to do that, and that's what I'm going to talk about. The first is map and explore: use what you know to better understand your organization. The second is speak the language: translate what you know into the right language that better resonates with people. And the third is don't go at it alone: bring people together in these communities of change.

[00:07:31] But before we dive a little bit deeper into that, let's take a look at some examples of the types of change, because change, as I've just mentioned, can be on whole different layers of abstraction. What are we talking about? In essence, the change I'm referencing is as simple as going from a current state to a future state, and I've listed a few different examples here. When you take the time to read through these, you'll notice that each and every one of these changes, whether big or small, has a component that requires collaboration with other people. It's not as simple as diving into Figma and making a small change that ultimately you're fairly well positioned to make. It's things that require you to collaborate, to negotiate. That's the hard change to do, because it requires working with other people. So let's dive into how you can do that a little bit more effectively.

[00:08:22] I'd like to introduce you to this guy called John Kotter, who about 25 to 30 years ago wrote this book called Leading Change. As a matter of fact, it was 1996 when he first published this book, and it laid out a set of four principles and an eight-step approach to help leaders looking to make a change in their organization. This has essentially been a foundational approach to a practice called change management, which is a really interesting profession that you may have heard about. You may be lucky enough to have change management professionals within your organization. But without going into too much detail on the theories behind it, I'd like to talk to you about the four principles that Mr. Kotter lays out in this book. They are: select few versus diverse many, have to versus want to, head and heart, and management and leadership. I'll start with the last one.

[00:09:13] Management and leadership basically says that change does not just come about by effectively project managing a new initiative, but that it's about inspiring people, bringing them together with a vision and a show of leadership. Head and heart says that logic alone doesn't help inspire a group of people; you have to appeal to the human desire to contribute to something that's greater than them. Answer questions like: what's in it for me? What is this in service of? Have to versus want to is about giving employees a stake, ownership of the change that you're making. It's creating an environment where people feel like they get to partake, as opposed to have to partake. And select few versus diverse many talks about the fact that change that affects many will be carried out much better if it's carried by many minds, hearts, hands and feet, over relying on a select few, or a new team for that matter, to bring in that change.

[00:10:05] Kind of get it out of the way a little bit: it kind of sounds like it was written in 1996. You can imagine some manager or CEO picking this up in 1996 and going, oh my God, if I treat people like human beings, they're going to respond much better to change? This is radical. But in fairness to Mr. Kotter, it was probably very much relevant for its time. And what he's really saying is that to successfully bring about change, you should really find ways to understand the people that you're working with, and to make them a part of the change that you're introducing.

[00:10:43] Based on that, I've extracted these three summaries from the four principles. The first is: understand your people and your organization. Know the language that connects with your people or your organization. And approach change in collaboration with those very people. From that I've derived three different roles that you can take as a designer: the navigator, the translator and the advocate, who very handily correspond with the three different things that I just mentioned.

The navigator: organizational attitude

[00:11:18] Let's talk a bit about the navigator first. As you may have gathered, I'm a bit of a nerd, and part of that is a fascination with space flight and space and science fiction and all those kinds of things. So I figured, what better way to talk about a navigator than to talk about someone that's gone off into space? There's this gentleman here called Chris Hadfield. Chris is a retired astronaut, and the first Canadian astronaut to do extravehicular activity in space. He's written a book, when he came back from space, not in space, that would have been difficult I imagine, on what he's learned about life on Earth after being in space.

[00:12:02] In that he talks about this concept called attitude. Not necessarily attitude in the sense of, oh, you've got to check your attitude, or you've got to have a good attitude. The attitude that he talks about in space flight refers to orientation: which direction your vehicle is pointing in relative to the sun or to another spacecraft. Because if you imagine space, it's a vast thing, and so to know where you are, you've got to have attitude. You've got to know where you are in relation to other objects.

[00:12:28] He talks about that in relation to what he's learned about his trajectory in life and all the rest of it. But it stuck with me, because I feel like in order to effect change, which we've seen can be as small or as big as you'd like really, I'm convinced that you have to know a little bit about the environment that you operate in. It can't just be that you're working in isolation. You have to have that attitude of your organization: organizational attitude, if you will. Which can also be organizational attitude in the other sense, but that's a different thing.

[00:13:02] So that's what the navigator is all about: understanding your people and your organization, and using the methods that you use as a designer for understanding people to understand your colleagues and your company. Essentially becoming an organizational ethnographer, which is by the way a real thing. It's a much bigger practice, and I won't go into that, but it's also very interesting.

[00:13:25] For instance, all those fancy maps that we make to capture all the different market forces at play with our customers, and maybe their purchasing decisions: you can use those on your own colleagues. Crazy. Okay, I might be an idiot, but when I first thought about these kinds of things, I had never considered using the tools that we use to develop empathy with our customers, or with our end users, and applying those to our colleagues to better understand my working environment.

[00:13:59] It doesn't have to be these ecosystem maps. In this case, this is an example that I developed for a project that I was working on which was quite complex. It had a lot of different stakeholders from different parts of the organization, and I was trying to figure out: okay, who relates to what? Why are certain decisions being favored over others? Mapping something like this helps in capturing all those different pieces in play.

[00:14:23] But it can be on a more detailed level. We heard a lot of conversations around personas and empathy today. Something as simple as that: have conversations with your colleagues about the things that motivate them, their pains and their gains, their objectives, the things that they say on the likes of Teams or Zoom calls. You can capture all of those things, and by doing so you can better start understanding the people that you're working with. It might feel a little bit unethical at first. You're like, oh, should I be capturing what my colleague Bob just said and make it part of his persona? But the thing is, these are tools for understanding. They are tools for giving you, again, that sense of control over the things that otherwise feel uncontrollable.

The translator: shared understanding and the good partner map

[00:15:04] Okay, so next, the translator. This is a holiday photo of me. We would be waiting for someone else, but it's me. This is me in front of the temple in Petra, in Jordan, which is this ancient city. Very beautiful. This was after a fairly grueling hike of, I want to say, about six hours or something like that.

[00:15:33] If you were to look at this picture, and I told you, oh, this is in Petra, this is in Jordan, just like I did just now, you'd be like, oh yeah, it's nice, good-looking temple, sounds interesting. It reminds me of the beach; it's not very far from the beach. But as a matter of fact, my wife, who was with me on that very same trip, one of the things that she remembers most about it is not so much the temple that we were standing in front of. Just to the right of this there was this incredible ravine, this path that we just hiked up. You can see, I think, a gentleman just over here. And she remembers that. She's like, forget about the temple, that's the view that was incredible. Because she enjoyed the landscape so much, that's the thing that stuck with her.

[00:16:13] This holiday photo phenomenon is described by Jeff Patton in his work User Story Mapping, and he uses it as an example to convey that when we're looking at the same artifacts, we often say a picture tells more than a thousand words or something like that, but the reality is that the same picture can have different meanings to different people. So when we talk about developing shared understanding about what people care about and the language that they use, the same artifacts that we choose to present to them might actually have different meanings to different people. To achieve proper alignment, is what Jeff is saying, not me, the other guy, when referencing something you've got to build towards shared understanding, and you've got to go past the artifacts.

[00:16:59] That's what the translator is all about: developing shared understanding and finding ways to speak in the language that will resonate more with others. The idea is that, by virtue of us all approaching things from our own perspectives, we'll have different understandings of different concepts. So you've got to build on the understanding that you develop in your capacity as navigator, and start figuring out: okay, what's the language that resonates with people, in order for me to actually convince them of the thing that I'm trying to convince them of? You've got to find ways to speak their language, become an organizational interpreter of sorts.

[00:17:38] One of the tools I've found really handy is something called the good partner map. This was developed by Ryan Rumsey of Second Wave Dive, a designer gone educator, and he offers courses on this. There's a bit of content from those courses that I've taken as well. The good partner map in particular I think is a really interesting canvas, because it basically allows you to dissect what you're offering in a way that is all about value. You can see it here, numbers one, two, three and four. Who is it that you're providing value for? Who are the different people that you're working with? What are you providing value on? How are you providing that value? Why is this even valuable? What, objectively speaking, are the ways that this is valuable?

[00:18:23] And then the second half of the canvas essentially allows you to tweak the offering on the left in such a way that it resonates better with the person that you're trying to sell to. It's a way to experiment with language, with the definition of your offering, in a way that you can experiment with: how can I make this more interesting for the person that I'm hoping to work with? I used that on the project that I mentioned earlier, as a way to capture, for the director of product, for instance, that I was working with: what are their pains and gains, and how can I think of my offerings, and present them, in such a way that they are more aligned with what I've learned by mapping their considerations? How can I tweak my language in such a way that I can speak to them in a way that resonates more?

[00:19:18] If the first part, understanding, tells you more about them, helps you understand what the forces at play are, who the people are, what their pains, gains, objectives and so on are, and the good partner map allows you to experiment with the language, then the third part, if you will, is about finding ways to then tell that story to the other person, using the language that you've just learned, or defined, or refined, if you will.

[00:19:52] As designers, we have a tendency to present our work in a classical storytelling fashion, in the top right-hand corner over there. There is a problem, I went and researched this, I came up with a solution, and the solution maybe wasn't great initially, and then I refined it and then it was great, and here's the solution. But our partners in business, as a matter of fact, think of this kind of decision-making more as a collection of trade-offs. There are frameworks for that, more analytical ones, that are less about, I came up with something great, the problems and all the rest of it. That's called analytical storytelling. Ryan also talks about that, both in his book and his blog, which I would recommend you check out.

[00:20:37] Essentially, they are based on the pyramid principle by Barbara Minto. Barbara Minto is ex-McKinsey, so a management consultant, and she would have worked with a lot of different companies. As a management consultant, she helped them whittle down their decision fatigue, all the different options presented before them. What management consultants are really good at is helping make decisions out of all the different options out there. Based on all the work that she did, and the formats that were successful with customers, she came up with the pyramid principle, which essentially distills storytelling into a really straightforward, formulaic structure. I don't have enough time to go into that in detail, but I would recommend you check these two things out.

[00:21:21] What you can take away from this is that once you've established who you're making change with, and figured out the language, or experimented with ways to present your proposed change in a way that resonates with other people, then the next important thing is to experiment with how to actually tell the story of the change you're hoping to make.

The advocate: building communities of change

[00:21:47] Last but not least, we'll talk about the advocate. To talk about that, I'd like to introduce you to this social startup called Common Knowledge. Common Knowledge is an Irish startup based in the west of Ireland. I can't remember what it's like in the US, but I know for a fact that in Ireland we have a bit of a housing crisis. We have a lot of demand for houses, and we don't have a lot of actual houses for people to buy or to rent. So there are a lot of people that are essentially unable to make that change in their lives.

[00:22:20] What Common Knowledge does is they've started this educational center. They say that over the years we've lost our common knowledge of building and repairing things. So what they do is offer courses in basic construction, basic DIY and stuff like that, in ways that allow you to take on the challenge of building and renovating a property yourself, or with more resources than you would have had otherwise. It's a really interesting thing. What they've done in particular with that initiative is they've lowered the barrier for people to purchase a property, to get a home, to move on with their lives from being renters, or living with their parents, or otherwise.

[00:23:14] It's that notion of breaking down barriers, making things more inclusive, lowering the threshold for people. That's essentially what the advocate is all about. Because what we've seen is that for a change to be successfully integrated, it needs to be approached together. You've got to make inclusive environments for people to actually be able to step into it. If you're asking people to do more research, you can't just say, go do research. You've got to actually empower them with the tools to allow them to do that. So you essentially have to become a community builder.

[00:23:48] Examples of that are, for instance, some of the things that are done by the likes of IBM. IBM Design Thinking is a very, very famous example. They essentially hired an army of designers and steered a 300,000-person organization towards becoming more design-centered through this educational program. But then also GE, who were less successful with a similar output, but rather than using a design thinking educational program, they used a design system called Predix as a way to bring about change and user-centered design across the organization.

[00:24:26] But your version of this doesn't have to be quite as big. We've just heard Duo [?] talk about playbooks and templates and all those things, to empower people in the organization to do the same. We're approaching something similar, from a more humble place of getting started with this. First of all, it's very well written by my colleague Colleen, very compact, but it's also just written in Word. It's a Word document on the SharePoint where most of our colleagues live and breathe and do their daily things.

[00:25:01] Another great example of accessible tooling is this on the right-hand side here, where Hannah from GOV.UK, a service designer in the UK government, talks about how your tooling, if you're making a journey map, should be made in such a way that it is accessible. In this case Google Docs. It doesn't have to be in Figma. Because if we think about the change that you're trying to make, you're this person pushing this boulder up the hill, if you will, and you don't want to be the single person pushing the boulder up the hill. You want to have other people around you. Something as simple as introducing a journey map in a tool that people are already familiar with, that they can contribute to themselves, will make it a living and breathing document, much better than if you or your team are the only people actually updating that document.

Why this work is worth it

[00:25:58] I see I'm at time, so I'll hurry up. Now, you'll hear all of this and go: well, Jeff, we've just established that burnout is a common thing, and I'm exhausted, and you've just given me loads more work to do. So what's the story? What do we do here? Well, this is something that my manager used to say at a previous company: 80 percent of building software is dealing with people, and only 20 percent is actually creating. If we acknowledge that as a fact, that so much of our work has to do with dealing with people, other parts of our organization, our customers, all those kinds of things, then this is an unfortunate reality. But that just means that we've got to reorient the way that we do our jobs, so that rather than seeing this as extra work that we shouldn't be doing, we see it as work that will ultimately make you more successful.

[00:26:51] The better you are at reading your organization, the higher your acceleration rate, if you will, of making change in your organization. Because if people understand you and trust you, and you understand them and trust them, then you achieve great things together.

[00:27:06] So the theme is that, first of all, you have all the tools you need to bring about the change that you're charged with. We heard about essentially using that empathy that you use with customers on a daily basis. That's your superpower. We've heard about those three change roles, the navigator, translator and the advocate: understanding your organization, speaking their language, and finding ways of essentially evangelizing what you do in such a way that you include them in your process. I hope this gives you some of the tools that give you some of that control that we were talking about earlier. Either way, I'll be rooting for you. So thanks very much.

Q&A

[00:28:00] Host: Thank you, that was a great talk. I really like the aspect of change, because when I opened it, it was all about how you actually implement some of these things that we're doing. Do we have any online questions? No. Any questions from the audience? Okay, we have one back there, so here's my best shot. Sorry, not a good shot.

[00:28:36] Audience: Am I the only one that thinks this should be a ball and not a box? Jeff, thanks for your talk. This is kind of a specific question, but you highlighted a voice of customer playbook, and that was interesting to me. Can you talk about the content of that and what that entails specifically?

[00:29:00] Jeff: Yeah. The voice of customer playbook is essentially written to help others in the organization do research, knowing that we can't be everywhere. I acknowledge that we are a 20-person team in a 20,000-person organization. Even if you make the subset of the people that are relevant to what we're doing a little bit smaller, that's still a lot of people for us to service on a daily basis. So the idea of the voice of customer playbook is that it's designed in such a way that, let's say, a colleague in the likes of marketing can look at this, and if they want to do research on a particular project, they can say: okay, what am I trying to learn? There's a flowchart for that, essentially. What's the nature of the question? What is the nature of what I'm hoping to learn? What is my objective?

[00:29:56] Basically this playbook helps recommend a number of different methods and processes that are not necessarily specific to our industry, but have some twist so that they're relevant to our organization. But ultimately they're just a collection of methods and stuff that people can find online, from the likes of Nielsen Norman or whatever. So it's essentially an accelerator document that will help people figure out where to start. We're hoping to build on that by also providing a repository of all the different projects. So if someone's interested in doing a certain type of research, then we can say: we've done these types of projects already, so here are some examples of how we've approached that ourselves, as inspiration for how you might do it. So I hope that answers your question.

[00:30:50] Host: Thank you. Any other questions? We have one right at the front here, so the box is coming its way. Where am I throwing this? Okay, right to the front. Good.

[00:31:12] Audience: Thank you so much for the great talk. It was very inspirational, knowing that I'm also coming from an enterprise design organization. My question might sound a bit too broad, but I'll try. In your organization, how do you ritualize changes done well, as well as define and celebrate when things are done well, and also the lessons learned if things didn't go as well as you wanted?

[00:31:42] Jeff: Yeah. We are kind of fortunate in a way that we're coming at this... Charles River is a 75-year-old company, and part of the challenge that we have is that we also operate in an industry that's heavily paper-based, heavily traditional. So we're very lucky in the sense that we're coming at this with a refreshed perspective. Every project that we start, we're not necessarily just stumbling into it, like, oh, we need to do this; we're setting it up for success. At the start of every project there are metrics that need to be defined: what are we hoping to achieve? Specifically on the project level, we have that well documented, if you will. So at the end of a major milestone, if it's a particular project release or whatever, we're able to assess: did we do our jobs, yes or no? There have been projects that have been successful in the past, and some that have been less successful, and that's the nature of transformations. Some go well, and some you just learn and move on.

[00:32:37] When they do go well, obviously some of the ways that we celebrate those wins is by broadcasting them to the larger company, to say: hey, we did this, we made this change, here's what we learned from it. Basically to make it known to other parts of the organization, especially in such a large company, that hey, we have the capacity to do this in-house. We don't have to go to external vendors to do that anymore, and you might get something cool out of it, so come do it as well. So I hope that answers your question.

[00:33:10] Host: Cool. I think that brings us to time, so thank you very much, Jeff.

[00:33:13] Jeff: Thank you very much.

Speaker

Jeff Simons

Jeff Simons

Director of Product Design

Charles River Laboratories