Published: 30 December 2015
Communicating your ideas, eliciting feedback, and fighting your corner
Gerry Gaffney:
This is Gerry Gaffney with the User Experience podcast. My guest today is the UX Director at Bitovi, a front end design and development consulting company. He's worked with a range of clients, from big ones like Walmart to small start-ups and everything in between.
He recently published a book through O'Reilly called Articulating Design Decisions: Communicate with Stakeholders, Keep your Sanity and Deliver the Best User Experience. And I must say I thoroughly enjoyed it, and it's the topic of today's conversation.
Tom Greever, welcome to the User Experience podcast.
Tom Greever
Thanks for having me, Gerry.
Gerry:
So Tom let's jump straight in, why do we need this book? Surely UX people almost by definition are brilliant at communicating design decisions?
Tom:
[Laughs.] You know, UX people are brilliant at solving problems and keeping the user in mind when they do solve those problems. But it doesn't always follow that they're good at helping other people, and sometimes those people don't know anything about UX and we need to help them understand why we did what we did, and I think that that takes an extra step, like an extra level of, of awareness and intentionality. It's something everyone, all of us can improve upon, whether you've been doing this just for a few years or your whole career, I think it's something everybody needs to be better at.
Gerry:
Yeah, and in fact I was being tongue-in-cheek there, and you do write there in one point in the book that you were amazed and offended at the number of designers who when applying for a job lack basic communication skills. It's really surprising isn't it?
Tom:
It is. I don't know why it happens so frequently. Maybe if I knew I would be less offended at the prospect. [Laughs.]
It does happen that sometimes these artistically talented designers just fail to follow simple instructions. Or they send me an email with maybe a resume and, like, nothing else! I don't know, there's probably a few things going on there. A lot of designers are, maybe, more right-brained, they're less cognisant of details like that, it takes a certain kind of task-oriented person to do stuff like that in a way that would impress you over email.
But really I think there's a certain amount of pride that goes into making these design decisions, right? It's an art-form for sure, and a lot of us come from an art-type background so there's this mentality that maybe our designs should or do speak for themselves, that if it's not obvious then it's not good design. And I think that's a point where probably I would diverge from a lot of people in the design field. Great design doesn't speak for itself, right? We have to help people, especially stakeholders, know why what we did is the right thing.
Gerry:
You yourself come from a background in marketing, is that right?
Tom:
I do, yeah, I started out in the marketing department, building websites at a time when we didn't know where to put web people. They either were in IT or they belonged to Marketing and I just happened to start in an environment where Marketing was who owned the website.
Gerry:
And I guess a lot of the time in the book you're talking about people who've come to UX through a Marketing or a Visual Design type of background although I think it's relevant to anyone who's in UX.
One of the things that I occasionally get from clients is they say "Oh, y'know, we used to work with so-and-so but they were just arrogant." Or "they were patronising." Do you think that's a common failing among UX people?
Tom:
Um, well I wouldn't want to paint a picture that a lot of UX'ers believe they're better than everyone else when it comes to making these decisions, although that can and does happen.
But it's probably true that we, because we're professionals in our field, we believe that what we've created is absolutely the right thing to do - and it probably is - but it's not automatic that everyone on our team or the people in charge of our projects are going to see it that way. We still have to work hard to help them understand those choices, without being patronising.
And what we need to do is be more thoughtful about how we express ourselves, make sure that the way we present our ideas is actually going to be effective in dealing with them.
So the arrogance happens when we think that we don't need those things, that people should just accept our work, no questions asked.
Gerry:
Yeah, I guess it's interesting, you talked about being thoughtful. I was thinking earlier on this morning about self-reflection and one of the quotes in the book is "We don't always understand how our intuition connects to the problem at hand. And you do see it a lot, where you talk to designers, they have a proposed solution and they can't articulate it.
How can they, if you like, get in touch with their own thinking about they did come up with particular design propositions, do you think?
Tom:
Yeah, exactly. That's the hard part, and I think that's why the content in this book is so important. When a person is really good at their job, they don't think about it much, They just do, it, right? They have these reflexes that work, muscle memory, in the same way that maybe a dancer could make a performance look effortless but that same dancer would have a hard time telling you why they did what they did.
And so we have these same reflexes, and this same sort of mental muscle memory, when it comes to making good design decisions. So we know how to solve these problems, we have a much harder time explaining the whys and hows to other people.
So the way to address that is to make sure that we're consciously aware of those decisions. We can't throw that part out, we have to make sure that we're intentional about it. We have to ask ourselves questions about what we did, get to the bottom of own thinking, whether that's writing it down practicing a presentation, whatever. And really, that's the topic of the whole book is to learn how to connect that intuition to the problem.
Gerry:
It's such an overhead, though, isn't it, to document design decisions as you make them? Is that something that comes naturally to you, or is it something you need to work on?
Tom:
I wouldn't want that to be a barrier to anyone. The phrase "document design decisions" sounds overbearing and difficult and time-consuming. It can be far simpler than that and the more practice you have at it the better you'll get. It can be as simple as just making a list. "OK, here's the problem that I'm solving and here's the solution." It can be just a few bullets about why I did what I did. It can be five minutes before the meeting. But I think we have to be in that regular habit. Otherwise you kind of become disconnected from your designs. Or at least from the intuition that drove you to make those decisions.
It definitely requires practice, but it doesn't have to be this big undertaking that is going to require a lot of time. Not always.
Gerry:
You've mentioned the word "meeting" several times, and I guess its' fair to say that the book is very largely structured around preparing for and attending and presenting and debriefing after meetings. What is it about the meeting that's so crucial?
Tom:
Right. In fact the book is linear in the sense that you start at the beginning of the book preparing for the meeting and thinking about your stakeholders, and we go all the way through in a linear fashion through the course of the meeting, in listening and responding and the following up afterwards, so it all kind of centres around the idea of meeting with a stakeholder.
And while probably a lot of the examples in the book have more formal meetings in mind, with executives or manager types, we need to be in the habit of doing a lot of these things even for hallway conversations, right? Even impromptu stuff where you end up in a meeting with someone to talk about designs. We kind of always have to be prepared to talk about our stuff in a way that's effective.
I think that meeting is important because that's where decisions get made, right? That's where we have the greatest potential, I think, for stakeholders to overrule us on decisions that we know better, and we have to be able to... we have to be prepared to deal with that.
Gerry:
From my own personal point of view, I think I have to adjust my mindset, too, because I always think of meetings as being a waste of time, you know, because it's time that you could be working during! But I know I have to see them as a necessary part of the design process. Does that come naturally to you or do you have any tips to get the right mindset, if you like?
Tom:
It probably does come more naturally to me than some people, but I think that when we see those meetings as a necessary part of our success, when you realise how important that is, to your success as a designer or maybe to the success of your project, then I think it kind of takes on new meaning.
I think too often we think that we can just create something beautiful and it will just go out into the world and kind of grow up on its own. But unless we get the support from our stakeholders and from everyone on our team, then there's almost no point. It's no good having a design that we think is really effective, that works really well, if we can't get the approval from the people in that meeting.
So in that sense, that meeting is more important than the design itself. At least, getting approval in that meeting is more important than the design, because without that approval, our design will never see the light of day.
Gerry:
Indeed. We're in kind of a funny situation, aren't we? You talk about it in the book, you talk about the dangers of getting what we wish for. You know, in the old days, I think it's true to say that most, well, many organisations did not value design and now, to quote, you say "entire organisations arrange themselves to value design and make it part of their core culture."
Which I guess means that the UX person is right at the heart of what's going on within an organisation and it is what we always wanted. But now that we're there, it's quite... I guess it's onerous and in some ways threatening, perhaps.
Tom:
Oh, absolutely. It's actually been really fascinating to watch the industry and the shift in design thinking that's taken place in nearly every company, large and small. You know, when I was first starting out, there were few people outside our own team that cared much about design. As long as it looked professional, that was all that mattered.
And now CEOs who previously had no interest in design at all are intimately involved in that process. And I think as designers we've been begging for this for a long time. "Oh, if only people valued our work enough they would understand and see how good it could be for the company. We knew we could solve those hard problems and that design was the answer. Well, guess what, we're finally getting that recognition, but it doesn't come easy. What comes with that territory is the need to convince executives and everyone else in the company to get on board with this vision of a designed future.
And I think that's part of why we're struggling with this most right now, it's not in our talent at creating design, but in our skill in talking about it.
Gerry:
You talk about there being four benefits that accrue from being articulate about our designs. What are those benefits?
Tom:
The first one is that it imparts intelligence. When you're articulate about the designs that you've created, then you're showing people that you're smart and you know what you're talking about, which is really important, to communicate that we know what we're doing.
The second is that it demonstrates intentionality. So you designed it this way for a logical reason. Not because you like it that way or you think it looks good. And surprisingly, a lot of non-designer stakeholders still think that design is just about making something look nice. So we have to do this even more.
The third benefit is that being articulate expresses confidence in your work. Sometimes just having confidence in your decisions is going to build trust with those stakeholders, whereas if you're unsure about it, or if you're wishy-washy that can kind of erode away that trust and it'll cause your stakeholders to question you even more.
The last one is that it shows respect for the other people, for the stakeholders and the people on your team. You're not wasting their time by just throwing around a bunch of crazy ideas and hoping one sticks. [Laughs.]
Instead, you're demonstrating you value their time enough by having a well thought-out explanation that really gets to the core point that they need to know or the problem that you know they want to solve.
And if you can do all of these things for your stakeholders then you're much more likely to earn their trust and get your way on those vital design decisions.
Gerry:
One of the things I see, particularly in newcomers to UX, or perhaps newcomers to the politics of managing meetings, is if a question comes up that they don't know the answer to, they tend to fudge and pretend an answer. It's really important for people to be able to acknowledge areas of ignorance, isn't it?
Tom:
Oh sure, yeah. Stakeholders can see through that, right? If you're just making stuff up and BS'ing your way through. You have to be genuine, and I think it's OK to admit, you know; "We don't know the answer to that question, we don't know for sure if this is going to solve the problem, we think it is... but to the best of our ability, and our experience tells us this is the right thing to do."
You have to be upfront and straight-forward, for sure.
Gerry:
In preparing to communicate designs or design rationales, you talk about three key questions. Can you tell us a little bit about each question?
Tom:
The questions stem from my attempt to kind of boil UX down to three basic ingredients so that we can wrap our own minds around it but quite simply so that our stakeholders can have a simple way of thinking about what we do. And so I have these three questions that we can ask ourselves about our design decisions, and if we can answer them, then we'll be prepared to talk about our designs with those people.
The first question is: What problem does it solve? Our designs have to solve a problem for the user or for the business, preferably both, right? Otherwise there's no point. And I think UX'ers are pretty good at understanding that we're solving problems.
The next question is: How does it affect the user? We know we're practicing user-centred design and we always need to make that connection between our decisions and that end users. And UX'ers are also pretty good at thinking about this question and being able to come up with an answer to this. We just need to be more diligent about doing it, honestly.
The last one, the third question, which I think is important for bridging the gap between our stakeholders and our decisions is answering the last question: Why is this better than the alternative? It's not enough, in other words, to have a design that just solves a problem and is easy for users, because if we can't explain why those choices are better than any of the alternate ways of approaching it, then we're going to be sure to fail at convincing someone that it's the best way forward.
Of course, implicit in that last question (why is it better than the alternative) is that we know what those alternatives are. Maybe we even tried them; for whatever reason they didn't work so well, we threw them out, but now we have to go back and talk about them with other people. Because what happens is there'll be someone else in the room that will suggest that alternative, and if we didn't try it or we're not prepared to talk about it, then we're going to have a difficult time convincing them.
Gerry:
One of the things that Bill Buxton recommends is, I can't remember the number, but he says to sketch to 10 variants of any particular element that you're working on. I personally find that very very useful, to come up with several alternatives to every element of design, every piece of navigation and so on. Do you do that yourself?
Tom:
I do. I don't know about the number 10 although that would definitely be a challenge and probably result in much better alternatives. I think the risk, and where we fall short on this one, is that we throw those... we throw nine of them away and we just take the one that we think is best. Because... We think we shouldn't show our stakeholders the other nine that we don't recommend because they might pick that one. Instead we have to be prepared to talk about why all nine of those don't work as well as the one that we suggest. And I think that's where we need to connect the dots. Not only do you have to do those 10, but now you have to take all of them and be prepared to talk about them in your meetings.
Gerry:
That reminds me of, I can't remember exactly where in the book, but at some point you had this rather underhanded suggestion, I thought, of presenting a design proposition that you didn't want to get accepted in order that you could subsequently present another one. Tell us about that strategy.
Tom:
Yeah, that is a reference to painting a duck. So, the story actually comes out of Interplay Entertainment which is a gaming software company out in the San Francisco area. But the story goes that one of their designers was working on the animations for a 3D chess game, and it seemed like no matter what he did, every time he would take his work to the product owner, they always had one more change. And he kind of got tired of all the changes, it seemed like it just never stopped. So he decided to approach the problem a little more creatively.
When it came time to do the animations for the Queen, he went and made all the changes to the animations and the design just as they'd agreed but he made one addition. And that was he gave the Queen a pet duck. And he was careful to make sure the duck didn't overlap on the Queen's animation, but he did want to be sure that it was very distracting and kind of obnoxious, like flapping down at the Queen's feet and quacking and things.
And what he found was that the product owner came in and looked at the designs and said: "It's all very very good. Just one thing. Remove the duck." And he removed the duck and could move on with the project. That story always gets a lot of laughs and, you know, people will ask me, "Do you paint the duck with your clients?" and "How does it actually work in real life?" and "What do you do if they like the duck?" [Laughs.] That's always the question that people ask, but I do find that its appropriate sometimes to allow purposeful distractions, because we want to be sure that we're keeping meetings on track.
And it may not be something as overt as a duck, but it might mean being careful about showing and curating the way you present your designs, the order in which you present. So I'm going to start with the one that I don't recommend so I can tell a story and end with the one that I do and that by presenting it in that way I'll be more likely to get their agreement, right?
I think that sort of thing, no matter how underhanded it might seem, can actually be effective.
Gerry:
I guess it's user-centred design, isn't it? Which brings me to another question, and that's: Why do so many UX people really fail to see their stakeholders as users whose needs they must meet? And I guess we see it in things like poorly prepared presentations, inability to articulate design decisions, unwillingness to put in the effort needed to, I guess to talk to and convince others of the direction that we're moving in. Why are we unable to see those people as users?
Tom:
Yeah, that's a good question, right? We talk so much about having empathy for users as if those users are the only ones that matter. And then we fail to treat our stakeholders with that same degree of care and attention.
You know, that's a good question because it's true, we talk so much about having empathy for our users, as if they're the only ones that matter, and then we fail to treat our stakeholders with that same degree of care and attention. But we have to have our stakeholders' support to be successful, right? What good is a well-designed app that's been tested with users if it can never see the light of day due to stakeholder disagreement?
And I've seen it happen. Designers who desperately wanted their product to change the world but were unable to convince the people who held the keys to their success.
And it's that arrogance that you alluded to earlier, Gerry, right? We see ourselves as the experts. And we are the experts. But sometimes that clouds our judgment. Or it makes us defensive. And so instead of validating our stakeholders' concerns, we jump right to the explanation of why we did what we did. And it just comes across as excuses, rather than building a logical case.
Gerry:
You do quote Dale Carnegie from the book, from "How to Make Friends and Influence People" and you talk about, I guess basic principles of human interaction. I was on the one hand surprised to see a quotation and on the other hand not surprised because a lot of it was the sort of stuff that Dale Carnegie used to talk about, especially when you talk about establishing rapport with our stakeholders. Do you want to tell us about some of those techniques?
Tom:
Yeah. The principle that you're referring to is Dale Carnegie's: Appeal to a nobler motive, which is one of the steps in communication from the book "How to Win Friends and Influence People." I think in UX and design that that principle is especially relevant, because we almost always have these nobler motives that we're going after. That could be some sort of metric or objective, usually there's a business goal involved, right? We establish some measure to know if our designs are effective or not, some goal that we're chasing after.
And any time that you can point to those goals and you can say: "Hey, if we can do this, that's going to get us one step closer to that goal." Or: "If I move this button here or if I change the colour of it or if we update the copy of that button, that's going to improve conversion" which is your goal, right, you stand a much much better chance of making your case to your stakeholders, when you connect those dots for them.
So we have to remember those nobler motives at all times and we have to hold that up as the thing we're all trying to achieve and point to it and say: "This is where we're going, this is where we're headed and if we make these decisions then that will help get us there." Not only does that make an effective case for your designs, but I think it reinforces that you and your stakeholder are on the same team, right? We're headed in the same direction, we're chasing after the same goals. And I think sometimes when we butt heads on decisions we forget that, and we need to be reminded of that and we need to remind our stakeholders of that as much as we can.
Gerry:
So how should one prepare for a stakeholder meeting? What do you do in advance of such meetings to make sure you go in feeling comfortable?
Tom:
Preparation is a big part of this. It can be as simple as just taking five minutes before a daily stand-up to go through your designs from the previous day and make a few notes of what you did and why. I do that regularly.
For bigger presentations like to a CEO or something where you're going to have a bunch of slides, you're going to be more meticulous about going through your designs. You're going to need to try to figure out what's going to be distracting to your stakeholder or your client and try to remove those distractions. One of the examples I give in the book is the use of placeholder content like "Lorem Ipsum" copy. "Lorem Ipsum" copy can be a huge distraction to some people, and you don't want the conversation to be derailed by something that doesn't matter. So figure out what's going to be distracting to your clients and remove those from the process.
Another one is to just take some notes, write things down. A lot of designers think visually and we express ourselves visually so it's important that we take the time to put into actual words what we're going to say, because that is going to help us connect our design decisions to the logic and the reason behind it.
And then another one is just to practice, right? I say in the book that practicing for the meeting is the usability test of being articulate. Because when you have the chance to stand up in front of a mirror or just talking to a friend or practicing anywhere you'll say things and you'll stop yourself and you'll rephrase it and you'll find better ways to express yourself, right? That's the test, and you use that as an opportunity to make your case and your argument more effective. You find better ways of talking about your design decisions. And those are all really important to being prepared.
Gerry:
You emphasise in the book the importance of note-taking during stakeholder meetings. Do you have any key tips for how to do that effectively and what sort of information to capture?
Tom:
Yeah, you know note-taking is absolutely critical when you're meeting about design because... There's a number of reasons but one of the things I think is common is you'll see... you'll make a design decision in one meeting and get agreement from everyone, and then a week later you'll come back together again and people will say: "Wait, why did we do that again?" And unless you're able to go back and reference your notes than you're just having the same conversation over and over again, right? And it becomes difficult to restart that, and we don't want to lose that traction, we want to build momentum towards the final design.
To that end, note-taking is really really important. There are several tips that I recommend in the book. One of them is that you should have someone else to take notes for you, if that's at all possible. Just ask someone else to be focused on writing stuff down so that your brain is available to focus on being articulate. If you're trying to talk and listen at the same time you're trying to write down and take notes, you're not going to be as effective at responding to your stakeholders. You want to be sure that your brain is available to listen to them and process what they're saying so you can respond effectively. So having someone else do that for you is really helpful.
Another one is you want to be sure that your notes are shareable or accessible. It's easiest when you have a Google Docs type situation where you can have a shared document and everyone can see what you're working on as you type it, other people can contribute, because you want to be able to show everyone what decisions were made, who made them, and a track record and a history of everything that was decided and discussed in that meeting.
And then you also want to be sure that your notes are referenced and that they're specific. By referenced I mean that you want to be sure that you're adding either screen shots or links or other words that'll kind of help you describe the decision. If you're talking about a specific interaction, then you have a link to your prototype so you know exactly what interaction you're talking about. If it's about a specific part of a web page or app you include a screen shot so that it's very clear to everyone - not just you, but to everyone else - this was the part of the application we were talking about.
And then your notes need to be specific, meaning you need to write down people's names and the decisions that were made. Sometimes especially when there's a lot of people in the meeting I will write down multiple names. "John agrees, Tammy was unsure, but this is the decision that we landed on." It's really sometimes useful, and I've done this months later when a new manager comes on a project and says, "Hey, why decide to do this this way?" I'm able to go look at my notes from three or four months earlier and even tell him the specific person. "Oh, yeah, John and Tammy in this meeting on this date decided that this is what we should do." That doesn't mean that the new manager isn't still going to want to change it. We'll still have to have that conversation but at least we're not just rehashing the same thing over and over again, right? We're starting with the information we need to move forward.
Gerry:
And I guess it comes back to showing that intentionality in your design as well.
Tom:
Absolutely. If it's important enough that we can write it down and document what those things are and have a recorded history then it shows that we're not just being haphazard about it. We're doing all this stuff on purpose. And I think that having that record and those notes makes it feel more permanent to people, when they can actually see it written down.
Gerry:
You talk too about how to deal with input, commentary, feedback, whatever you want to call it and I guess there's a couple of factors that are of interest. One is, I guess, the extent to which our egos get wrapped up in our design, and the other was your advice to start with "Yes" in your responses. Can you tell us a bit about that?
Tom:
Yeah, well ego is definitely a big problem. We've already talked about arrogance. A couple of different times it comes up, right? I think that as designers we become very attached to our decisions and to our designs and our work, because it is such an art form that it can be really hard to just take two steps back. And one of the things that I recommend is actually... [Laughs.] The first step of the 12-step programs which help people overcome substance abuse and alcohol addiction is, the first step to recover is admitting that you're not in control. And I think sometimes we see ourselves as the owners of our work and it's hard to let go of that. And it's really just, there's just a mental switch there. We just have to flip that switch and remind ourselves, OK, this is not my baby, there are other people involved in it, and need to have influence over it. So we have to learn to not take their feedback directly and personally. Because they might even use words that sound like they're attacking us, right? But we can't view it that way no matter what they say. We have to believe the best about their intentions and we have to believe that their comment is on the effectiveness of our designs, and we're working together to come up with the best solution. I think just flipping that switch, just having that attitude is really important.
The next point you mentioned, Gerry, was "Lead with a 'yes'" and I get more positive reactions from people about this one than maybe anything else that I talk about. This is the concept of the "yes, and..." where you quite literally need to start every response to stakeholder feedback with the word "Yes." And it does several things. One, it's a positive word first of all. No-one wants to hear "No" as the firs thing out of your mouth. But more than that, you're validating what that other person says is an OK thing. Even if you disagree with it. You're saying "Yes, I see your perspective." "Yes, that's a really good point." You can say these things without agreeing that their solution is the best. And yet that word "Yes" is such a magical word because it turns their brain on to listening to you. They make a suggestion and you say "Yes." They're far more like to hear then the rest of what you have to say. If you start off just saying "No, the reason we did it this was is because the research showed that..." they're tuned out at that point. They just turn it off. This concept has roots in improvisational comedy too. What one actor brings to another in improv, they have to, one of the rules of improv is they have to say "Yes" to each other. Because if they don't, it totally shuts down the sketch. One of them walks up and says, you know, "Hey, let's go to the grocery store," and the other actor says "No, I don't want to." Well that's the end of the sketch, right? Curtain closed, they have nowhere to go. And our meetings with stakeholders are also improvisations and we have to say "Yes" if we really want it to go somewhere, if we want to take that story somewhere else, we have to lead with a "Yes" and stay positive, reinforce that we're all on the same team headed in the same direction and you'll be amazed at how much easier it is to get what you want when you stay positive and lead with a "Yes."
Gerry:
And what are the words that we should never start any sentence with?
Tom:
[Laughs.] Well there's a few phrases and words I recommend you avoiding. One is the word "like." You know, we've got to strike the word "like" from our vocabulary. It's too easy to like or not like something, it's too subjective, and the truth is we don't really care what you like or don't like, we care about what works, what doesn't work. So anytime a stakeholder says to you, "Well, I don't really like that," I recommend repeating that back to them in a way that will force them to not use the word like. So they say, "I don't like that" and you can say "I understand that you prefer that this be moved over here, but why doesn't it work to have it over there?" You convert the word "like" into the word "work." And when you do that, people will sometimes catch themselves, and they'll be "Oh, it works just fine over there, I just thought it would look better over here," and at least then we're getting somewhere, we're getting to the bottom of their thinking.
So one of them is to remove the word "like." Another one, which I think is what you're alluding to, is "From a design perspective."
Gerry:
[Laughs.] Yeah, that's the one that annoys me.
Tom:
Yeah, we say this a lot and we start a lot of design sentences as well. Someone will say, you know, "We need to make changes to your design," and our first response is, "Well, from a design perspective..." And, you know, first of all I think this is just a bullshit way of saying "from my perspective." And we don't really care about your perspective. First and foremost we care about the user's perspective, but ultimately we have to value the stakeholders too. And this just sounds like we're trying to one-up them with our expertise in design. They couldn't possibly understand why we did this, because they're not designers.
And that phrase in particular has a certain air of arrogance about it that we need to remove.
Gerry:
Tom, for people working in UX who, you know, maybe they've been a little bit inspired listening to you or they aware that they need to improve their stakeholder communications skills, what steps should they take, besides reading your book, of course?
Tom:
Practice is really the biggest thing, and I think this is a skill that can only be learned by practice. You can read the book, there's a video series that goes along with the book, too. But at the end of the day you've got to get out there and talk to people and talk to stakeholders. And the more meetings that you're in and the more opportunities you have to explain your design decisions to people, the better you'll get.
I actually have recommended to several people that they join Toastmasters. If there's a local speaking club in your area, that's a great low-risk opportunity for you to go and get feedback from other people about your presentation skills in general. But even, set the stage for them and tell them, you know, "You're the skeptical stakeholder here, I'm presenting my design to you and I need you to push back on me so that I can learn better to defend my design decisions." You know, any way that you can practice.
If that's not a good first step for you, then just practice in the shower. Practice in your bedroom at home at night when no-one's looking, right? Just find a place where you can go and shut a door and listen to yourself talk. Record yourself talking, and listen back to it afterwards. I've actually done this myself, where I'll stand at my desk and turn on my web cam and go through the slides and practice my presentation and then when I'm done I'll stop it and I'll go back and re-watch the whole thing over and over again. And that really helps uncover a lot of areas where I go, "Oh, the way I described that isn't actually the best way of explaining it." And so I'll go back and I'll practice it again.
You know, different meetings will require more or less preparation, but any opportunity you can find to practice, I think, is valuable.
Gerry:
Tom's book is called Articulating Design Decisions: Communicate with Stakeholders, Keep your Sanity and Deliver the Best User Experience. And I found it a thoroughly enjoyable and interesting book I think both for entry level people and for people who've got a bit more experience, because there's stuff in it that you might not have thought about or just, I guess, a bit of a reminder of the sort of things that we should be doing.
Tom Greever, thanks for joining me today on the User Experience podcast.
Tom:
Great! Thank you, Gerry, I enjoyed it.