Published: 20 November 2020
The fine art of getting good stakeholder feedback
Gerry Gaffney
This is Gerry Gaffney with the User Experience podcast.
My guest today is an independent design consultant. With 20 years of experience in user-centred design. She has a particular expertise in Information Architecture. She's very well known in the UX community, including for setting up the UX Australia conference and running it for many years.
Her latest book is Presenting Design Work and refreshingly it doesn't have any subtitle.
Donna Spencer, welcome to the User Experience podcast.
Donna Spencer
Thank you, Gerry. It's so good to talk to you
Gerry
I don't know if you realize it, Donna, but it's been 14 years since you were last on the…
Donna
Fourteen! Really?
Gerry
Yeah, I went and checked. I double checked in fact, so yeah, 14 years. And that was when you'd written the book or actually you hadn't written, you were writing the book on card sorting.
Donna
Oh I must have been writing it, okay.
Gerry
Yeah, I think it took you another couple of years to actually finish it. [Laughter.]
Donna
Fourteen. Well at least I occasionally have seen you in between.
Gerry
That's true.
You write in the book that effectively presenting work is one of the most important skills a designer can have. Why is that so?
Donna
Because we have to do it so often for one and because decisions like project decisions get made from it. And in a lot of cases you have a project decisions, decisions of going ahead with one direction or another are made primarily off seeing a presentation. So you mess that up and all your good work has gone to waste.
Gerry
I find it surprising sometimes that people who are excellent designers can be absolutely awful at presenting. Have you found that and if so, what can those people do to improve their presentation?
Donna
I think that happens because they're like genuinely different skill sets, the ability to, you know, work your way through a problem and come up with something that, you know, really solves it is is an entirely different skillset to getting up in front of people and presenting. People should be able to explain their designs well. But I can understand why they may not be good natural presenters. And I don't know that it's possible to make everybody amazing presenters. Yeah. Cause look, some people just are never going to be super confident talking in front of groups, but there are definitely steps and ways of presenting better, even if you're not naturally a good presenter. And that's the kind of stuff, like that's, that's what I've written in the book is a bunch of tips on, even if you're not going to be super comfortable as a presenter, an amazing presenter, things that you can still do that you can plan and be really deliberate about that means that you will get your work across better.
Gerry
I guess one could outsource the presentation to another person on the team
Donna
That probably isn't a bad idea. Yeah. You'd still have to… the main designer would still have to be around because there are always kind of detailed questions about why did you do it in that way? But yeah, if you are not, if you know that you're not going to ever be great in front of people or you're kind of new to it, or it's a really key presentation and there's a lot hanging off it, yeah, getting, getting a team member a colleague, somebody who's more confident is probably an exceptionally good idea.
Gerry
When you talk about people being new to it. I think sometimes designers get their egos very much tied up in the design.
Donna
[Laughs.] I think so too. And I think that that's actually what trips up lots of people. It's not that they don't want a present it's they don't want to listen. Not universally. But I have certainly seen plenty of it. And I've certainly spoken to plenty of design managers for whom that's their main issue is how can I get my designers not to present, but how do I get them to listen to feedback? Because look, it makes sense. We put a lot of work into into, you know, creating a design, doing a piece of the work. And it is a, like, it's a real skill to listen. And I had to do with this with the book, I wrote a nasty old rough draft, and I sent it out to people and I asked them for feedback and I was really clear what I wanted out of it. And it came in and I had to read it. And there's always that moment where you're like – "I don't… but… but…" and then you go, well, if you're, if you're a good listener, you go – "Yeah. Okay. That makes sense."
The thing that I don't understand about why designers aren't good at this at taking on feedback is that they… if you're like also kind of a designer who likes research, I mean, you like hearing feedback from users just a lot don't like hearing it back from their clients.
Gerry
Yeah. That's a good point, isn't it? I often find the really good designers really love getting feedback, don't they?
Donna
Really good ones love it. Yeah. And are open to it and will be – "Oh, cool. Yeah. I didn't realize that. Thank you." And then, they probably won't pick up much from my book. God, I think I, I just feel like I've gotten into a hole where I've called just not people who aren't good designers, not good presenters.
Gerry
Well, look, I think you know, I think there's something in the book for good presenters as well. It certainly helps people to focus on what's important and what they need to do. One of the things in the book, that's a kind of a real obvious one probably, but I know people won't do it is you know, rehearsing and recording oneself.
Donna
Yeah. a lot of people find it hard to listen to themselves and, you know, I just got over it because I'm fine about listening to myself. But also once I'd listened to myself doing user research for years I didn't, I didn't cringe at myself anymore. And I always notice important things that are really good that I'm like, I'm glad I picked that up. I will know not to say that. And the other thing about rehearsing, once you've said something out loud to yourself, it's in your brain and your brain knows that you've said it and knows that you've thought it. So when you're in front of other people and you're a bit stressed your brain already knows this thing because it's already heard you do it. So it's much easier to do it the second time. I recorded a talk last week that I recorded twice. And the second time was easy because my brain is like, oh yeah, you already know all that stuff.
Gerry
Yeah. You talk about being you know, sort of the cognitive load when you're doing presenting. And it can be a real issue from the point of view of gathering feedback as well, because somebody will say something during a presentation, you think yeah, yeah, and you kind of make a mental note of it, but unless you're actually noting it down, it's very hard, can be very hard to recall it afterwards. How do you address that problem?
Donna
Well, you shouldn't be making mental notes of feedback, feedback is too important. I mean, it's the point of presenting is to get feedback so that collectively you can make a product or service or whatever you're designing better. If you're not capturing the feedback, if somebody is not writing that down it's lost. It is literally what was the point of doing it in the first, of presenting in the first place, if you haven't caught it. So you either need to have somebody helping to take notes. And if you don't have a colleague who can do it you need to ask somebody in the client side to take it. You cannot manage the managing the group and going through your design rationale and explaining you know, the user doing a thing in the story and listening to people. And remembering later on that, you've got to do something about it. You can't do all that at once. You can record, like, if we're doing online stuff, you can record it for later on. But yeah. Mental notes are not ever useful. It's like doing user research and going, yeah, yeah, I'll remember what they say. [Laughs.]
Gerry
It's like going into the kitchen and thinking, I'll remember what I wanted when I got there.
Donna
And the kitchen is only two steps away from me, but I bet I could get up from here to there and wonder what I needed.
Gerry
Now you talk about the dreaded word, the one that makes me shudder, whenever clients mention it, or particularly when vendors mention it and that's walkthrough,
Donna
Did I actually say walkthrough?
Gerry
[Laughter.] Did you say walkthrough? I'll have to… I can't search the entire book.
Donna
I probably did. Yeah.
Gerry
Yes. Yeah. You said the thing you absolutely positively. Now, here you go. I'm quoting it back to you, Donna. "The thing that you absolutely positively must not do is a real estate tour…"
Donna
A real estate, yeah.
Gerry
"…that is a screen by screen walkthrough of a page while pointing out its features." What's wrong with that?
Donna
Well, so, lots of things. One, it's not a story of a person using the thing you've designed. Two, it's really quite dull to be going – "Okay, so there's the logo and there's the top navigation bar and in the top navigation bar are these things. And over there, there's a carousel with products in it. And you can see that there's a filter with a dropdown."
That's really not interesting. But also what it does is it draws attention to the pieces of the screen. And I would prefer to get feedback on a whole flow of a person doing a thing than feedback on a dropdown or a carousel. It also means that you're more likely to use jargon like dropdown and carousel. And often the folks in the room don't know that jargon. So I suggest people instead of doing a real estate tour of pointing out all the features, instead of that go through the screens, the design, the prototype, the wireframes, whatever it is as, as if a person was using that thing.
So you start before, you know, a bit of intro to what the person's doing and show your way through the screens until they finish. And then I always suggest you go right back to the beginning and you do it again because the first time people are like – "Oh my God, what's going on. She's showing me all of these things and it's really fast." And you do it again and they're like – "OK, right. I can see that bit. And I can see that bit and I can see that bit. And I understand. But yeah, pointing out things like real estate doesn't help the audience get the flow in their head. It doesn't help them understand what the user's experience might be. And literally does draw attention to the things you might not want any comment on like, you know, colours and buttons and drop downs.
Gerry
So literally you would do to the same story twice or the same scenario twice?
Donna
Yes. I might change the words in it a bit, or I might, let's say we were doing a product example I might show them going through and, you know, finding our product and then I'll go back and they might find a different product this time, but I do show things twice. And I do it because the first time people see a thing it's just too fast. You know, the first time you see a movie and you're like, "Oh my God, that felt like it was really long." The second time you're like – "Oh, that was really short. What happened there?"
Gerry
Depends on the movie Donna.
Donna
I know. Yeah, no, it was bad. It was a bad metaphor. But you know, the idea or any kind of experience the first time, there's so much to notice and the second time, you know what you're focusing on. Yeah. I don't know that that was a good metaphor, but anyway, you know what I mean.
Gerry
I know what you mean. So presumably the story that you walked through would be one of the key scenarios that the product or service is supposed to support.
Donna
Yes, absolutely. Yeah.
Gerry
So what's the structure then of an ideal design presentation?
Donna
The structure is pre-planning to make sure that you know who is going to be in the room and why they're going to be there. Then the presentation itself, the structure I recommend that, you know, works for me and that I've taught other people and seen work is to give people context, tell them what, you know, has been decided before what you're talking about today. So kind of what, what the scope of the presentation is going to be.
Ask them specifically to do something. So give them a job. So not just say, I'm going to show you a thing and I'm going to ask for feedback, but can you please look out for, does this work for all the customers that you know are likely to use it? Is this technically possible? Is there anything that… are there weird cases that I've missed? You know, find specific jobs for people to do and ask them to do something specific and to look out for something specific. Then go through as if a person's using a thing twice, possibly another time, like you've also got the opportunity to show people using it in an alternate way, like maybe on a mobile or maybe somebody with a screen reader showing, you know, there are different ways to experience a path.
And then if you need to dive into detail, go into the detail after you've already shown it as a flow. And then never ever say to people, do you like it? Or what do you think? But then go back to, so the things that we're looking for, let's now talk about, you know, those, do you have feedback on? Is this technically possible? Does it work for a particular kind of customer? So being really specific about things and not just, not just kind of showing a thing and then going, what do you think?
Gerry
It sounds like you don't allow interruptions or discussion during the presentation in that approach.
Donna
No, not usually. I mean, this is fast, this isn't a 30 minute presentation. We don't usually design things that take people that long, so it should be able to be done. So you could do, like, if you've got a lot to show, you can of course break it into pieces. But there should be like, if you're doing it quickly as a person doing a thing, there should be not really a place where people are like, hang on.
But otherwise I also say up front, I'm going to do this straight through. We will come back to anything you need to discuss so that people know that they're going to be heard. If you, if you tell people that they're going to be heard and that, and that where they have a chance to be heard, they will wait for that point. People often interrupt because they're afraid they're not going to get a chance to be heard. So, yeah, I don't let people interrupt and if they, if they do, I say, we'll come back to that. Just let me finish, just let me finish this bit and we'll come back to it.
Gerry
How polished should you, if you're, if we're talking about a digital product, how polished should the UI be when you're doing presentations?
Donna
It depends what stage you're at and what kind of feedback you're really after. So if you're early on in in a process and you're still working on fairly conceptual designs and you want to understand, you want to get feedback on – "Does this broadly makes sense? Do we have the data to support it? Are there red flags in this overall, you know, flow? – all you need is something scratchy. You don't need any kind of detail. If you're later on and you've refined a lot of concepts and you're actually after feedback on the polish, then you should show the polish, but really like most of the feedback should be up on the kind of scratchy conceptual end and less on the polished coloured-in interactions kind of end. Like you probably shouldn't really need to show off you know the interaction of a dropdown for feedback ever.
Gerry
Yeah. I find with the great selection of really powerful tools that are available, that it's sometimes a trap that a designers fall into of you know over-engineering the thing too early.
Donna
Yeah. And then the difficulty with that as a designer is you fall in love with the beautiful thing. And it's hard. It is hard to shake that, and it's hard to, it's hard to get feedback on something that feels so good. But it's easier to get feedback when you've scratched out some concepts. And that's why I like tools that let you easily scratch out some concepts and not worry about the detail. And then, I mean, there's a layer of also explaining to stakeholders who haven't been involved in a kind of scratchy process before. There's some level of explaining to them what they're looking at, but explaining a scratchy concept to your stakeholders is easier than dealing with nitty gritty, detailed feedback on colour and button corners and fonts and type when, what you wanted was feedback on concepts.
Gerry
Now you also write, and I can't find the quote, but I know that you will agree that you wrote it somewhere. You say don't write about how you got here. You know, don't write about the process, or don't present about the process rather.
Donna
Yeah. And I wrote that because I've seen, I've been in presentations with many designers where they get up and they say, okay, so we did this and then we did this, and then we did this one as well, and the're zipping around the screen. And then they're like, but none of that worked. And then blah, blah, blah, blah, blah. And I'm like, hang on, what are you showing me? I don't need to see everybody's thoughts as a stakeholder or as a manager. I need to see what the results they came up with to solve the design problem was. I don't need to see everything in between, and I completely understand why it happens. It's because as a designer you've gone, okay. I need to just, I need to do this thing. And I worked through that and it was kind of hard. And then I realized it wouldn't work. And so I changed my mind and I did it a different way. And then that was hard as well. And then I figured it out and now I've come up with this thing.
So presenting your thought process linearly kind of seems normal. But it's not useful. It's not useful for anybody to see those in-between states because they're just sitting there wondering why aren't you showing them? What are, what is this… it's horrible. So yeah, you only need to show the end result. And when I've talked to people about that, they've gone – "Yeah, yeah, yeah. But I've got to show my process. So they value my work." An d I'm like, no, no, they just need to see the end results so they value your work, If they have questions on it, if they wonder if you thought about a particular thing or if there was a different way to do it, they can ask. And then the answer makes more sense when it's answered as a question rather than here's 20 things I thought about in the last week.
Gerry
Yeah. But as I was reading that I was thinking of Erin Meyer's book The Culture Map, and she talks about, you know, for certain audiences it's get to the point, like US audiences, for example show me the thing, but for others, I think she specifically mentions German. I can't remember, but some audiences do want the step by step to get to, you know, so that you've validated where you've reached.
Donna
Yeah. And that actually does make sense. I would still, I mean, people know their own or should know their own cultures. I would still show the result. And then if you're working in a very collaborative work culture or you know, living culture and you know, that just showing the outcome is going to leave people feeling dissatisfied, then go through some things and talk to them and work on it together, but still show the result first. Otherwise it just is very confusing as to what you're looking at. But yeah, that's a, that's a good point. And I wish I had a thought about that and included it.
Gerry
You talk about when you're getting feedback, the way you classify feedback on what you're going to do about it, you say, you know, I'll agree and do it later, I'll agree and do it now, needs further research, I need to clarify, or No I'm not going to do it.
How do you tell your stakeholders and particularly your clients, I guess that no, you're not going to take their input.Donna
Look… You do it by building a good relationship with them over some amount of time. So if you have set up a good presentation and feedback process and your client knows that you are listening to them and that you are taking things on board and you're taking, that you are collecting and caring about the feedback.
When you need to say thank you, we've heard what you've said. And we as a team, maybe, however that works out with your team, we have decided not to do this. And you have a rationale as well. So it might be we heard what you said, we talked about it and after digging into it, we realized it was really complex. Or it just isn't technically possible. Or you asked us to already do this amount of work and it would make extra work. All of the reasons that you might… I mean, you have to first, you have to know the reason you're saying no. You don't get to just say no, because you don't like it. You have to have some rigour around that decision making process. And I don't think all teams have that, but if you've built up that good relationship with the client so that they know that they're being listened to, and they know that you are being you're being rational it's actually pretty easy.
Gerry
One of the things, you've talked about the people in the room and getting to know the room and who your audience is and so on. There's been a trend towards remote working for some time. It's been accelerated recently by COVID. What's the difference in running these sorts of sessions remotely when perhaps everybody is remote?
Donna
There's still a lot of similarities. You still want to know who is in the presentation. Why are they there? You can still give them all individual jobs to do. It is a little easier to hold the floor and have interruptions or, you know, a discussion at the end. So that's, that's actually easier online because you've got, you've got the floor for a moment. You might not be able to see their faces and their, you know, the kind of physical reactions and people twitching and writing down notes and those kinds of things. But you still need to know who's there and why, and you still need to ask them, give them instruction on what feedback you need and ask them to give you good concrete feedback. So it doesn't change a lot, except that it's harder to read the room.
Gerry
I find sometimes people presenting can lose quite a bit of credibility by faffing around with the technology for several minutes at the start of a session or during a session.
Donna
Yep. And particularly if your stakeholders aren't very tech savvy themselves. They don't realize that actually every time you plug your headphones in every platform goes, hang on, which headphones are we talking to? Your headphones or your microphone? How do we talk to that screen? It is super important to understand your technology and to understand how things plug in. And if it's an important presentation to rehearse that ahead of time. It makes it makes you look a lot more professional and you will also be a lot less flustered when you start if you know how to manage the technology. And if you are just not good at that, if you just can't ever kind of remember how to plug things in, get somebody else to do it with you, like, get a colleague to, to, to do that piece so that you can focus on communicating with your audience.
Gerry
Sometimes you won't be able to get feedback in the time that you've got for the presentation. This may be particularly a problem online, I guess, but I think that the mistake sometimes people make is they say you can send me feedback afterwards, but they don't either have a forum for that or a mechanism for that or indeed an end date or a deadline for it.
Donna
Yeah. Look, my preference is actually always to get feedback afterwards. I don't like getting feedback at the time. My experience is that feedback at the time during the presentation is kind of shallow. It relies on people actually having seen you and seeing what you've done on the screen. It doesn't give them a chance to look at it properly and poke around on it. So I find that if you try to get feedback at the time in the meeting, things will still come up next week when, or in between when people are like, hang on, I just thought of a thing. So I prefer to get feedback afterwards anyway, but I also don't just say, hey, send me feedback. I will always tell people how to get feedback in what format usually in a format that suits them. So they want to email me or write a Jira ticket or give me a phone call or whatever any of that is fine.
Here are the things that we need to know. We need it by this date. And I would always follow up with you know, if we've got a prototype or something, here is a link to the prototype, here are a handful of person-doing-your-things, scenarios for you to go through, do these things and then get this, and then, and then send back these things by then, and then send a reminder. You can't just leave it open and hope that people remember to tell you, If you do that, you're setting yourself up for later on for people to, you know, in two weeks go – "Oh yeah. That thing you already showed us." Yeah. That's a problem. And you're kind of way past that you need to be able to get it fairly quickly,
Gerry
How often should one be presenting?
Donna
There's probably no real answer to how often. So let's think of some factors. You don't want to be presenting so much that it's overwhelming and people can't follow it. So you want to be presenting frequently enough that people can get their head around what you're showing them. You don't want to be presenting, you know, super long meetings, again because by the time you've presented 20 minutes of screens, you've forgotten the thing that happened in minute one. But it is hard to schedule meetings with people. And especially with like, if you're working offsite and not onsite with a client you often just get like a handful of times to present back.
So default to frequent short sessions when you can and get people into the process of giving feedback, of giving them a bit of time, but getting feedback to you fairly quickly. If you can't, like, if your project is structured so that you can only check in infrequently you're going to need a lot more rigour around the presentation. You're going to need a lot more rigour around collecting feedback and you're going to need a lot more rigour around your project because you've got longer timeframes between being able to take the feedback, and do something with it. So it's no answer to how often, but as often as you can in shorter sessions, than longer.
Gerry
Now, given that people might be presenting to a remote audience is there an argument to be made for just videotaping yourself doing a presentation so that you can finesse it and then sending that out and asking for feedback?
Donna
I think that's not a bad idea. As long as your audience still feel that you're listening to them. It certainly could get around the scheduling issue. You need to add a bit more kind of written structure around the edges of it to say again… I mean, I guess you could record this into the video. The, the context of, we've done this before we're doing this now here's the boundaries, what I'm presenting… You probably still need some kind of written structure around, please, can you focus on these things?
I've never done this, but I think it could work. You have to also, I mean, people could easily ignore it and go, I don't have 15 minutes where sometimes getting into their calendars means it's going to happen, but you certainly can control that presentation better.
Gerry
And then people can run it at one-and-a-half speed if they want.
Donna
Yeah.Gerry
I was amused. When you talk about you know, preparing a presentation, you talked about being here about the user needs and the business needs, and you say, if you're not clear what business and user problems you're trying to solve, do get clarification before you present.
And then you have the rather forlorn statement: "After all, somebody must have had at least an idea of what the project was set up to do." [Laughter.]
Donna
Come on, you've been in these as well. We're both consultants. We both end up in projects where we're like, why, why did you ask me to do that thing? I don't understand…
And I know that there's certainly a lot of junior designers get caught in these situations where they've been asked to design something, but they don't understand the purpose of it. So I included that because not everything is ideal. You know, I acknowledge that sometimes we get asked to do things without a reason. But if you don't know what you're doing and why you can't actually be solving the right problem, sometimes you have to, like, sometimes you have to go, okay, you told me to do this so I did it. And then show that it kind of doesn't make any sense for some clients to go – "Oh, that kind of doesn't make any sense." Yeah. I had to put that forlorn sentence in.
Gerry
I'll remind listeners that Donna's excellent book is called Presenting Design Work and it's published on A Book Apart and it's full of really good practical information.
It's nice and short. I'd certainly recommend it.
As usual, this is a transcript of this episode at uxpod.com.
Donna Spencer. Thanks so much for joining me today on the user experience podcast.
Donna
Thank you very much, Gerry, and really nice to talk to you again.