Stakeholder-Centric Design: How retargeting your design process can make you a more influential part of your organisation

Che Harvey at UXDX Community: Improving your Design Process. Video: https://youtu.be/nF3yaDpwpxE

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 summary

[00:00:00] Che: Thank you, thank you so much. Like Rory mentioned, my name is Che Harvey. I am a UX designer with IBM, in our team called Client Engineering. I've had a whole lot of hats. I've been a mechanical engineer in the past, I've done production assistance, and I've done customer support in a startup in San Francisco. So there are a lot of different things on my path to becoming a designer at a major international corporation in Europe.

[00:00:31] I am based in downtown Berlin, Germany, and I've always had experience working in medium-sized and, in this case, larger enterprise organizations, specifically inside innovation labs, working on MVPs to try to improve, in this case, the efficiency and the efficacy of IBM technology, especially around hybrid cloud and AI. I'm originally from the US, Washington DC to be specific. So there have been a lot of cultural challenges, but also a lot of learnings I've gained over my time as a designer in both regions.

[00:01:19] Today what I would like to speak about is stakeholder-centric design, or in other words, and maybe borrowing this a little bit from a longer title like Stanley Kubrick's Dr. Strangelove: how retargeting your design process can make you a more influential part of your organization.

[00:01:40] In many of these companies, digital innovation is preached from upper management, but it is unfortunately implemented in less than ideal ways. For example, for a new designer coming into an organization as a new hire, I've found that it is vital to establish both yourself and the design community as a champion of good design practice, as well as the shepherd of incremental change, to introduce a culture of experimentation as smoothly as possible.

[00:02:14] While experience has given me insight into the workings of design at smaller corporations, I do believe the lessons learned are applicable across roles. It doesn't really matter what your background is, whether it's design or other disciplines, and it could also be, and has been, implemented in larger teams. Because it really should be our goal as designers and as professionals to build successful businesses while creating positive, inclusive and collaborative environments.

[00:02:44] In summary, I'll go over understanding resistance from stakeholders, approaching stakeholders as users, and learning, educating and reflecting. To wrap it up, I really believe it's important to be open, to never make it difficult to access resources, and to receive information from all directions. And while personal processes might be compromised at times, you'll at least have a better understanding of your teammates and stakeholders when designing anything. There's no one right way; that's important to remember. And you have under no circumstances compromised yourself.

Understanding resistance

[00:03:23] A little bit of background about me. I started in San Francisco at a company called Udemy, for online learning, and I was there actually doing customer support. As I progressed and learned more about the company, I was able to transfer my experience into user experience or customer experience. Especially as UX designers, and not at Udemy but later in my career, I came in with big bright eyes. I thought that with everything I'd learned from online courses, I would be able to immediately take the largest problem a company was facing and tackle it from the beginning.

[00:04:08] I thought I could provide value and completely transform my workplace overnight. I think we all have those big starry eyes as we go in. I thought I'd go in, grab users, talk to them for hours, write down everything that was said and what they were trying to accomplish, and when faced with a particular problem, I could just come up with a camp full of solutions, or go in and write a few tasks for some quick usability testing. If a user got stuck, I'd be able to quickly put a report together of what was high, medium and low priority. And you win awards, your favorite designer talks to you, and you're able to immediately and instantly get a seat at the table.

[00:04:52] But in reality, this was not me. You don't walk in and go after the biggest problem first. While these techniques might not be wrong in principle or in intention, I think it's really critical to remember that our workplaces are still social environments. There are plenty of resources out there for HR departments that state the importance of communicating team values to new hires. Unfortunately, most of these recommendations come from within the organization.

[00:05:23] When trying to get your inherent expertise into the organization, sometimes there is a bit of resistance. This can occur with designers going to other disciplines and sharing the spirit or the lessons from design. But it could also come from just an individual coming into a new place and not necessarily being able to impact or influence as quickly and as instantaneously as we may like.

[00:05:55] Especially when starting out, remember that taking on the most visible aspect or feature of a company is a huge project, and it's more important to first lay down the groundwork that allows the foundations of a relationship with your co-workers, managers and stakeholders to flourish. Like I always say, you're the new kid on the block, and you may be perceived as ignoring the lessons learned. I think that's really important: understanding where things have come from before you dive headfirst going forward.

Approaching stakeholders as users

[00:06:29] We've also been hit over the head with this, and sorry, I should have said there's a kind of flash warning if this is a little bit too fast. We understand the process as designers. We already have all the tools to be successful, no matter the experience level. But I think it's important to return to the basics. User-centric design might look like this, and I know everyone knows this, so I don't want to beat anyone over the head with it. But it's important to always come back to what we've learned.

[00:07:03] There are certain steps we sometimes take for granted when building something physical or digital, but we can also take a step back and apply the same process to situations, to relationships, and most importantly to people as well. I think UX really extends beyond our work and our work location, and can be useful in everything we do.

[00:07:24] And here I come to the point that as designers we can actually see ourselves as the product. So properly complete your user discovery, if you are the product. Why were you hired? Why are you in this organization in the first place? What problems were those making the decisions trying to solve? What did they think they could solve by bringing someone like a designer in? What issues was the company experiencing, and what was being used before? Exploring some of these, and how we can alleviate some of these issues, is a path forward to being more influential inside an organization.

[00:08:06] In many cases it could be that design was done by external agencies, and the decision to bring in a team member was to get more control over the process. I think knowledge and insight like this can be used to our advantage. Breaking down successes and being able to replicate them for decision makers can always be a powerful way to integrate ourselves into organizations.

[00:08:36] Where I always start, whether it's a new team, a new selling team, a new product team, anything like that, is to look back and ask what the biggest wins were over the past couple of weeks or months for each of those team members, to understand what each individual cares most about. Discovering this history and uncovering similarities between big company wins is one place to look. But also focus on wins that were experienced not only by one member but by the entire team as a group. Pulling out those characteristics will allow you to create stronger and better connections.

[00:09:22] At IBM, for example, we are 300,000 people, and it is incredibly important to take those relationships personally and put a lot of importance and weight on them. So figure out what's going well, what's not going well and the general state of things, and see where frictions exist between departments. One example I'm working on now inside IBM: we of course have a design system, but the way my team uses that design system sometimes needed us to start from scratch, and that was an interaction between our technology engineers, what we call our full-stack developers, and the design team.

[00:10:08] What we did to try to alleviate some of that pain was build out template pages, not only from a design perspective but hand in hand with the developers, so that other teams could come and use reusable resources, build faster and hopefully delight our clients. So the big takeaway I want to share is that design, at the end of the day, really comes down to communication. In an ideal world, solutions are developed cross-functionally, but if that is absolutely not possible, make sure to bring other departments into the conversation as soon as possible, to alleviate that feeling of isolation and of solving multiple problems at the same time.

Don't outshine the master

[00:10:55] I want to go into an example. This is more of a story of why to compromise, so away from design, but I thought it was an interesting little anecdote. In 17th-century France, the finance minister, Nicolas Fouquet, had spent a ton of money building a magnificent chateau on his estate. He threw a lavish party to show off his connections, cultivated manner and charm, thinking he would be able to make himself an indispensable asset to the king.

[00:11:30] In 1661, Louis XIV, at age 23, goes to the finance minister's country estate, and he was absolutely outraged by its magnificence. He left feeling insecure, outraged by the fact that people were more impressed with the finance minister than with the king himself. In short, he found a convenient excuse to get rid of Fouquet, who spent the next 20 years of his life in prison. And after that, what happened next?

[00:12:08] King Louis XIV went ahead and built Versailles, which of course is known today and is much grander and more lavish than the chateau, which I had never heard of before, to display his charms and his connections. I think the lesson from this is probably a little extreme, but it comes down to: don't outshine. Again, remember that we're part of teams. At least I've had it in the past where I thought I knew absolutely everything going in, and that has always, always backfired for me.

[00:12:41] A positive example of this would be Galileo, who was clever in observing this law by giving glory to his patrons. In order to solve his problem of funding, he dedicated his discovery of the moons of Jupiter to the Medici family, since the royal symbol of the Medici family was the planet Jupiter. He then commissioned an emblem for them, with each moon representing one of the sons who revolved around the patriarch. The Medici family became his biggest patrons, appointing him their official court mathematician and philosopher and giving him a more comfortable life and a steady salary.

[00:13:18] These two lessons actually came from a book I kind of call the dark side of How to Win Friends and Influence People, called The 48 Laws of Power, by Robert Greene. It discusses how to amass influence and work with others to accomplish goals. I call it the dark side because the other 47 rules, in my mind, are sometimes ethically inept, to say the least. For example, there are a couple that are funny and terrifying. One was, "Use selective honesty and generosity to disarm your victim." And, "Keep others in suspended terror: cultivate an air of unpredictability." I 100 percent do not recommend any of these laws being applied inside a workspace. But the underlying rule from these two stories has been invaluable during my time, and I do think it contributes to a positive company culture.

How to compromise

[00:14:22] Next, how to compromise. This is thinking before you act. Being patient is an incredibly strong life lesson. It changes someone who may be against you into a support system. Take the time to first understand yourself and your stakeholders' emotional and psychological state, being alert both to what separates them from everyone else and to what they share with everyone else. So be calm, empathetic and soft with people, but also sure in your way.

[00:14:54] There was a quote, and I wish I remembered exactly who said it, that a good designer should be strong in their opinions but hold on to them loosely. So understand each other's basic fears, hate and jealousy, and also primary emotions like love, freedom, family, etc. Once you understand that, you will have not only a lifelong friend at work but someone to collaborate with as you move forward. Remember that self-interest can be the strongest motive of all, but this of course takes time to progress.

[00:15:34] In my free time I'm actually a street photographer and portrait photographer, and there's a technique I've learned from photography that has allowed me to understand some of the lessons I've mentioned. In the first contact with a subject, I noticed it's always important to first find something they inherently like about themselves. For example, it's said that if a person covers half of their face with their hair, you watch where the hair is parted and highlight the other side.

[00:16:10] How this translates to the workplace is by figuring out what they promote, either internally at work or publicly through blogs, LinkedIn professional profiles, or XING, depending on where you are. Or simply by asking what their biggest success at work has been and why they think they accomplished it. So let's find ways to make everyone win, them and of course you yourself and your design practice along with it.

Objection handling

[00:16:38] The next is a technique from sales called objection handling, and at this point I can also describe a little more about my role in Client Engineering at IBM. We obviously have technology we would like our customers and clients to use to become even more successful, but a lot of my job has to do with speaking with both internal and external stakeholders. It's my goal to build MVPs that prove the value of IBM, and this means I get a lot of pushback from people who either haven't worked with IBM before or haven't worked with my particular team within IBM before. This tool is a way to really listen to other people and, ultimately, prepare a response.

[00:17:35] The first step is to clarify. If an objection comes up, it's important to get the real objection and try not to create new problems or answer too quickly without first understanding. An example would be "design always takes too long," and a step would be to first almost repeat that statement back to the stakeholder or whoever you're speaking with. Once you get the buy-in, "Yes, that's exactly what I said," you can move into acknowledging.

[00:18:08] Acknowledging another person's objection is basically saying, yes, what you're saying has absolute validity. Allow the other person to feel heard, and allow yourself to make sure you heard them correctly. Then move on to responding after that clarification. If the objection is valid, it will be helpful to offer a solution. For example, the one I mentioned about time: we have clarified and acknowledged that the client is concerned about the time it takes to design things. The response would be to establish, one, how much time exactly is too much time, and then surface the potential dangers of rushing design, as well as offering a hypothetical solution that addresses the concern directly.

[00:19:07] When I say hypothetical, I also want to make sure it's legitimate. So of course, if you need to talk to someone outside your team, or to developers, to make sure something is technically feasible, definitely do that. Make sure the offer you come back with holds up. If the client says, "Oh, it can't take more than four weeks," then you could say something like, "Okay, so if we can finish this in four weeks, are there any objections to moving forward?" Because I don't recommend lying by any stretch of the imagination.

[00:19:40] Finally, ask if the offer addresses the concern. Hopefully this should resolve the objection. But of course, if another objection is offered, you can begin from the start and try again, until you clarify, acknowledge, respond and confirm every objection as you move forward.

Removing reasons to say no

[00:20:02] Easy to remember: everyone is still at a job and everyone has bosses. In corporate sales, which I guess is the part of IBM I'm working in now, when selling a product or service to someone, it's better to think that you're removing reasons why someone can say no. Ultimately, the person you're on the phone with or sending emails to will need to defend that purchase or decision higher up the chain. So take away reasons someone can say no.

[00:20:34] In many cases, cost is a factor. For example, if ethnographic research costs too much, try bringing users into the office, or conduct remote testing, or guerrilla testing in the street. And if your company won't go for that, think of testing ideas within your organization. I know it's not ideal, and I know we always tell ourselves that we are not the user, but always try to break it down into more digestible chunks, so that your process is first understood, and then you can take the next step in the direction you would prefer.

[00:21:08] The point being that you can treat your design approach like an MVP. You don't have to have the lab to show value. So step down the list to a more reasonable alternative that eliminates stakeholder concerns, and when the results come back and show value in the design process, it'll be possible, like I said before, to move back towards the ideal situation.

Sharing learnings and building trust

[00:21:33] This is from when I used to use Evernote, but bring all of your learnings together in your own repository, and then collect each of the departments' learnings in whatever tool you use. Whether it's Box or Notion or Evernote, wherever it's stored, make sure that learning and that information lives there. Write out what you've learned in your own articles, and know which metrics are important to the business so that you can fall back on them when the time comes. This saved a lot of time.

[00:22:04] It's like the way we build case studies for ourselves for portfolios: almost do that internally for the company or organization you're working with, and then share those out. It's a way to increase trust, to increase the amount of knowledge you're perceived to have, and the number of projects you're able to work on going forward.

[00:22:30] Like I said, building that trust is one of the most important aspects of implementing a concept of design, and your stakeholders and the rest of the team must be aligned on it and on what you can offer. There are a million ways to do things. So remember that there's a difference between consensus and alignment. Alignment is not consensus. Consensus is when you take the overlapping parts of individual opinions and highlight what is common. This is usually the lowest-hanging fruit, and everyone is left with something missing.

[00:23:01] Alignment is agreeing on what the desired outcome could be. You do not have to have the same opinion or solution to be aligned on intent and outcome. This can mean committing to a decision or direction that is not universally agreed upon. Alignment is the goal. That way you'll be able to objectively say, "We wanted to accomplish this and we didn't." If not, it's no problem, and the conversation will open up to what went wrong and how to address it moving forward.

[00:23:35] Next is building trust by starting small. This came from a podcast by Abigail Hart Gray [?], a design podcast, or Design Better, from a few years ago that I really liked. It was: pick something that currently has little or no value to the company, and choose that for a rapid workshop or sprint process to rebuild it. This way you can introduce your way of doing things in a completely non-threatening manner, connect with different parts of the organization, and convince a team of your way of working. And if not, no one minds if it didn't work, because it was a section of the product that was overlooked to begin with.

[00:24:18] There's another way to think about this, and I'm not saying this is exactly how Client Engineering does it, but what we do is try to reduce the risk our clients are facing. We do that by working with clients for six weeks at really no cost to them. We work to prove that by continuing with IBM we can really prove value and help move the needle on whatever business goal we unearth during our workshop and our process.

Passive education and changing the environment

[00:24:54] Make those learnings available. Passive education is about making information accessible to stakeholders and the company as a whole. Understand the users you're building for. Maintain the need for user-centric design, but understand that these users are users of your users as well. I'm talking about stakeholders: understanding them, whoever happens to be above. As the holder of knowledge, it's the job of the designer to bring new insights into their line of vision.

[00:25:29] This one is more on the personal level: holding conversations outside the normal environment to break up the monotony of the daily routine. I know it's hard coming out of remote work, but there's an idea that if you wear your watch on the other hand for the day, the day can feel more memorable. So this is basically building alignment outside your normal working locations, whether it's going to a coffee shop, changing backgrounds, or just doing something that isn't the same.

[00:26:09] For example, we use WebEx internally, and then we try to use things like digital whiteboarding tools, whether it's Mural or Miro or Figma and FigJam. Try to do things in a slightly different way with the tools you have, so those ideas are a little more unique, and again bring it all back to a shared repository.

The power of legacy and the endowment effect

[00:26:36] Don't underestimate the power of legacy. Everyone understands the need for change in the abstract, but day to day, people are creatures of habit. Too much innovation can be traumatic and can lead to pushback. If you're new to a position, or in a new organization, or working with a new client, try to build that base first and make a show of respecting the old way of doing things, and if change is necessary, make it feel like a gentle improvement on the past.

[00:27:07] There's an experiment that demonstrated the endowment effect, by Daniel Kahneman, Jack Knetsch and Richard Thaler. They brought three groups of participants in to complete a mock psychological study. Basically they asked them to fill out a survey, some kind of paper quiz; it doesn't really matter. The most important thing was actually the gift they gave. The first group came in and was given a choice between a mug and a chocolate bar as a reward for doing this mock study. They set both gifts on the table and found that 55 percent ended up picking the mug and 45 percent ended up with the candy. So it's about even; the gifts had about the same value to begin with.

[00:28:00] The second group came in and was given the mug before completing the task, and only after finishing did they ask the participants if they wanted to switch the mug they got at the beginning for the candy. 90 percent stuck with their first reward. And they flipped it exactly: gave the candy bar first, and the same result happened. People stuck with the first thing they had, the first gift or reward for completing this mock study, and did not want to switch to the other.

[00:28:32] I think this is a really good lesson: there is a lot of value in what is effectively part of the legacy. Someone who comes in proposing very strong changes is most likely going to be met with a level of rejection and a bit of resistance to those changes. You cannot make people see the world or value your way without paying homage or respect to what already exists.

Wrap-up

[00:29:05] In summary: include stakeholders and empathize with them. Think of yourself as the product and take the discovery phase seriously; that's your discovery phase, analyzing yourself as the product. As a simple gesture, this could be using old titles for processes, or keeping the same name for a group even when its functions slightly change. That will tie you to the past and support you with the authority of history. Make a loud and public display of support for the values of the past, and widely share your learnings with them, them being the stakeholders, in a non-confrontational manner.

[00:29:48] What has been established before seems greater. Habit and history add weight; use this to your advantage. Highlight wins in the past, and avoid stirring up too many fears by outshining what has been in place. Remember objection handling. Know why things were done and why they were the way they were before moving forward and making incremental changes under old names.

[00:30:11] And finally, be open, and never make it difficult to access resources or receive information from all directions. When designing anything, there's no one right way forward, but when you educate and learn, you have under no circumstances compromised yourself. Thank you very much. If you want to reach out, I'm Ch by Design [?] on Twitter, and you can also send me an email at my email address here. I'd love to talk to anyone who has open questions, so I'll open the floor and give it back to you.

Q&A

[00:30:45] Rory: Thank you very much. I thought that was a great presentation, because one of the things I always found early in my career was that I disliked sales. Sales just seemed a bit icky or something to me. But as I've gone through my career, everything is sales. So I wish I had done more of that learning earlier on.

[00:31:09] Che: Yeah, I think the same thing. This role I'm in now really does distill what design is trying to do down to individual people. We're trying to solve problems, but we're also trying to do it in a way that people feel comforted and like they've been heard all the time. Again, I think the biggest lesson is objection handling, which allows you to very clearly step through: empathize, acknowledge what's happened before or where people are at, and then try to come to decisions or potential hypothetical solutions that feel like you're building collaboratively with the person you're selling to. So it doesn't become "Hey, buy this." It ends up becoming "Hey, how can we work together to solve that problem?" It changes the angle, the approach.

[00:32:06] Rory: Excellent. Just to reiterate, people out there can ask any questions. You can put them into uxdx.com or whichever platform; we're monitoring them all at the moment. But I'm going to start with a question, because something you started with really connected with how I felt when I started my career. It was this drive to just move quickly. Thinking about it, in college and school you learn something, move on to the next, learn something, move on to the next. And then you suddenly hit a workplace where they're like, "No, no, no, slow down. You have to take things slowly, work things out and build up." I was of the opinion: just tell me what to do and I'll do it.

[00:32:51] Che: Yeah.

[00:32:51] Rory: Whereas in the workplace it's a bit more vague. You have to figure out what needs to be done and then do it. So what advice do you have for people who are either going through that, or trying to manage somebody who's going through that?

[00:33:05] Che: So the question is how to help someone who's really gung-ho, trying to get into it...

[00:33:13] Rory: Yeah, to step back and think about all those steps you just described.

[00:33:19] Che: For someone in that position, it really is starting small but going really, really deep. We talk about T-shapes all the time: having very broad knowledge is exactly what design education is meant for. Across our whole background we learn absolutely everything, and then we want to apply absolutely everything across the board. But if there is a particular team or a particular project, pet projects could be a great candidate for someone like that. Work with someone, or identify someone in the organization who might be a potential mentor, understand what they would like to see or the vision they want to bring, and then go deep on that topic. That gives you a bit of time to understand how the organization works and what some of the roadblocks might be, to really move forward.

[00:34:15] For someone working with or managing that person: in my past, when I've been managed in those positions, I was always told, "Understand the history, really know why we're doing things." There are some positives and some negatives to that. The positives are that once you learn the legacy systems or legacy processes, you can find the small problems in them and propose incremental changes. The bad thing is that sometimes you can also be blinded. If you've been in an organization for 15 years, you don't necessarily know the new techniques or new processes. So if you're managing that, also be open.

[00:35:03] There's a saying, and I'm probably going to butcher it completely, but it's something like: ask an old scientist about what is possible, and whatever they say is most likely right. But ask an old scientist about what is impossible, and whatever they say is most likely wrong. I think that rings true for design in organizations as well.

[00:35:26] Rory: That's a great example. We're getting a question in from Paulini [?]. She's asked: in a process that demands more agility every day, what do you think is the most practical way to share learnings?

[00:35:40] Che: Honestly, as quickly as possible. Again, I always try to make this analogy between a product and the product designer. As we build MVPs, we do quick paper sketches, we do wireframes, and we're always encouraged to get that out and show our work as fast as possible. I think most of us are probably using some type of messenger like Slack. There's a great feature I use all the time on Slack, which is the video, showing your screen and then sending it directly. That way we don't get slowed down writing the perfect message to someone or crafting the perfect email. Just opening up your design tool, sharing your screen, putting your face in the bottom corner, explaining the thought process you're going through, and sending it over to people who can make a quick decision is a very, very fast way to remain agile.

[00:36:38] Rory: I love that. It's an example of thinking out loud, which I think is really powerful, because if people just see the output, they don't realize how you got there. That thinking out loud is really valuable.

[00:36:51] Che: Yeah.

[00:36:52] Rory: I hope that answered your question, Paulini [?]. One final question I have, and if anybody else wants to send them in, please do. You mentioned alignment versus consensus, and that's one of the challenges I've found. Some people have quite strong opinions, and getting that alignment, you can go almost in circles.

[00:37:15] Che: Yeah.

[00:37:15] Rory: So what do you do when you're trying to get alignment and somebody is being, maybe not stubborn, but quite adamant on a particular position?

[00:37:26] Che: I think that comes back to the fact that, at the end of the day, it's an objection. You have to understand why they don't think the idea being proposed is the right one, because when you ask those questions, you force them to identify the problem themselves. Hopefully you can then take that direct objection and solve it, or incorporate it into whatever the rest of the team has aligned on. Again, it's bringing everyone together; we shouldn't be working in silos. One person is not the gatekeeper of all the information. Coming at this from diverse backgrounds and diverse disciplines is the way we build strong products, and keeping that team as tight as possible is, I think, the only way forward, really.

[00:38:17] Rory: Brilliant, thank you very much. I haven't seen any more questions come in. Tai [?] says, "This is great, thanks, Che." Paulini [?] has also said thank you twice in the chat. So I think some people really enjoyed that. Thank you very much for sharing.

[00:38:34] Che: It's been my pleasure, Rory. Thank you.

[00:38:37] Rory: Thanks.