Handling Feedback & Disagreements

[00:00:00]
>> So how do we do that feedback? Right, so if we ask stakeholders for feedback when you present, it's gonna lead to a conversation about how to fix the design and that's gonna lead into design by committee. So we don't want that. Fortunately, there is a better way, right?

[00:00:16]
First of all, let's deal with how do we stop it happening actually in the meeting, because it's very easy for me to say, we're not gonna do feedback. But how do we actually stop it happening? First of all, don't leave enough time [LAUGH], that's always a good way of getting around it.

[00:00:31]
Just make sure that you present up until the deadline, it's naughty but it works. Second, tell people that you want to give them time to digest the design. So make it sound like you're doing it for them, not for you. Third, suggest that people go and consult others, right?

[00:00:48]
Because the only way they can do that is with the video you've given them. So it means all those other people are gonna get the same presentation fundamentally, right? So absolutely fine for them to go and talk to other people and that will make them feel better and more confident.

[00:01:03]
And third, say that you will send them specific questions following the meeting. You'll follow up after the meeting with some specific questions that you wanna get into. And then if you do send those, if you do allow some space for questions in the session. Focus those questions very much on the process that got us to where we are not comments about the design as they stand today.

[00:01:29]
So how do we then follow up and actually gather the feedback? That is gonna be inevitable so we might as well do it. So first of all, we're gonna email the stakeholders post presentation, right? And they're welcome to say, there's somebody else we need to be copied in on this.

[00:01:48]
Or it'll be great if you send it to the CEO as well, just get whatever email addresses you want. And what you gonna do is send him an email and you gonna send a link to the video that you've prepared, all right? And alongside that, you're gonna ask some structured questions, right?

[00:02:04]
And those questions are designed to focus the stakeholders and the clients at providing feedback on what matters. And it's gonna hopefully help them avoid getting sucked into expressing their own personal opinions. I will say it one more time, never ask, what do you think? I cannot overstate that.

[00:02:27]
So what questions should you be asking? Here are a few that are my go to questions, you will obviously have to tailor these to your specific project, but it'll give you an idea. First of all, does the design support the needs of the users it's aimed at? See what I did there, focusing immediately on user needs, right?

[00:02:47]
Second, does the design achieve the organizational objectives? Fair comment, needs to so we need to know. Do you believe users will associate the brand keywords with the design? Don't forget you've literally just shown them some test results that say it does, so that'll help there. Does the design incorporate the stylistic elements designed in the style tiles?

[00:03:09]
And again, you've literally just talked them through how it does that. Does the design reflect the wireframes you've previously created for critical pages? Again, you've just shown them that it does. And does the design communicate the value proposition agreed at the outset of this project? And are there any additional considerations we need to take into account as we move into the build phase?

[00:03:31]
Right, take out that last one just for a minute. Let's look at all the rest. You have literally just shown them how the answer to all of those questions is yes, all right? And if they go through yes, yes, yes, yes, yes, yes, yes, how can they then say I don't like the design, right?

[00:03:50]
You've guided them to the right decision and educated them by focusing them on the right things. As for the last question, that's the only open ended one that you've put in that list really, all of the rest are yes or nos. Hopefully, you asked that one last knowing that they'll have got to the end of the list going yes, yes, yes, yes, yes.

[00:04:10]
The last one, notice the wording of that, that we should take into account as moving into the build phase. I have not said that we need to amend the design or go back in endless circles around iterating the design. I've just said, is there anything additional to take into account?

[00:04:27]
What I'm doing here is controlling the narrative. I'm controlling the conversation that's happening to focus it on what really matters the most. A common mistake I see designers and project managers making is to ask, for example, for a single point of contact with the design, right? That is the worst possible thing you can do, right?

[00:04:47]
Think about it for a minute, a lot of designers get really frustrated that they get all these different conflicting feedback from people. That's the best thing in the world, you definitely want that, right? That's not a bad thing, that's a good thing. The reason it's a good thing is cuz it puts you in control.

[00:05:02]
If everyone's emailing you directly with their feedback, that means that you're the only one that has got all the feedback. You're the one in control, okay? So now I can pick and choose which feedback I listen to and what I quietly ignore. Also I can directly follow up with questions.

[00:05:24]
So let's say we were getting feedback from person B but all of that feedback had to go through person A. What if I've got follow up questions with person B? I don't have access to that person to ask them additional questions. So if I'm getting feedback directly then I can go to those people and I can ask them questions and control the conversation a little bit more.

[00:05:46]
We want all feedback to come to us directly because it allows us to question the feedback rather than just blindly have it forced upon us. We can judge how important and how strongly that person feels about the feedback cuz this happens all the time, right? The CEO makes a vague comment.

[00:06:03]
The next person along the chain makes a strong recommendation based on it. And the third person that communicates it to you, it's an absolute must. The CEO says so, right? You don't want that scenario, you wanna be at the source. And if you control it, you can decide what's acted upon and what's not.

[00:06:25]
Be the single person with the whole picture and take control of that discussion and that narrative. Again, this doesn't just apply to design, this applies in project management in general. So let's talk about the disagreements that will inevitably come up, right? So there are going to be some objections.

[00:06:47]
There are going to be things. You can control it as much as you want. You can be as clever as you want, but there are always gonna be feedback that you get that you don't like, that you don't feel is correct. So how do you handle that? Well, first thing is, I would suggest, ask why, right?

[00:07:06]
There is a tactic called the five whys to drill down to an underlying problem where you ask why, you ask why, you ask why. I call it the annoying toddler approach to project management, where essentially, and when you've got a small kid, you know they endlessly ask you why?

[00:07:23]
Why is the sky blue? And you give an answer and they go, well, why is that? And it just goes on and on and it drives you nuts, but it's actually a really useful tactic. Say somebody comes back and says, I think that I want the logo to be bigger.

[00:07:36]
Well, why? Because I feel that users might miss seeing it. Well, why do you think they'll miss that? Because I didn't see it. Okay, and why do you think them missing it will be a problem? And you keep asking why? And oftentimes, A, you get to the root of the underlying problem which is not always the problem that they've expressed.

[00:08:01]
But B, oftentimes they'll lose steam [LAUGH]. And they'll basically realize there is kinda no underlying thing. Now you mustn't do it aggressively or confrontationally cuz the minute you do that it puts people's backs up and you get nowhere. I need to understand this better to fix it, can you help me kind of thing, works really well.

[00:08:22]
If you've got objections to their argument, whatever it is that they said, don't word it directly. So a classic example would be, I wanna change the color of that text, right? And immediately through your head goes, well, that's gonna be inaccessible for a start, right? If you come back and say, that's gonna be inaccessible, all right?

[00:08:48]
You're basically saying, you thicky, what's wrong with you? Why didn't you realize it's gonna be inaccessible, are you an idiot? Why would you even suggest such a thing, all right? That's the underlying implication. If however you say, yeah, yeah, we could definitely do that. What's your thoughts about the accessibility issue?

[00:09:07]
How do you think we ought to get around that? A totally different feel to it, a totally different conversation that then ensues. Because you're talking about we and us and how are we going to deal with it. And you're making the presumption they must have thought of that already, all right?

[00:09:23]
They're not thickies. So that works really well. Another thing I do is, this is a great one. So someone says they wanna change the navigation or whatever, it doesn't really matter. Yeah, yeah, you could be right. I might have got that wrong, all right? That always throws them for an instant straightaway because people are used to confrontation.

[00:09:46]
So yeah, yeah you might be right, we really ought to test that and find out, all right? It'll kill it dead. Cuz they won't have time, they won't wanna commit time, they just wanted you to change it. But nobody can really disagree with the idea of testing it.

[00:10:03]
Especially, as you've been so conciliatory over it and said, yeah, I might be wrong, we need to find that out. You've got a really good point, let's test it. Well, they don't have the time or the money because they wanna move on. So they go, I'm sure it'd be all right for now.

[00:10:17]
That's the answer you'll get back. Great, we move forward, we launch that cuz the truth is once it's live you will get data back that will prove one way or another. It's about keeping project momentum going. And that is exactly the last point, my last argument for dealing with disagreement is, you might be right.

[00:10:35]
Let's just get it live and see what happens, right? Or let's deal with that later. Great, which brings us nicely on to handling scope creep cuz we haven't really fully resolved that as an issue yet.