Managing client feedback

00:00 Hello and welcome to Perspective. This is a show by founders of small indie creative agencies giving our perspective on starting and running our own companies. The aim is to provide some useful advice and inspiration to others as well as learn from each other and others who may get to come talk on the show.

00:13 This is our eighth episode. My name is John Dark. I'm a director at Every Interaction and with me I have Dan Ghent from Lighthouse London. Hello Dan. Hey John, how's it going? I'm pretty well. How are you?

00:23 Yeah, not bad. Not bad at all. Excellent. I'm keeping busy over at Lighthouse. Yeah, pretty busy. I mean, it's at the point where, you know, I'm basically barely fitting in doing stuff like this, but that's fine.

00:41 Yeah, same here. I think it's that time of year, isn't it? Around sort of end of February, beginning of March, someone flicks the bananas switch and it rains bananas. Yeah, exactly. I expect it's a lot of we should get that brief out first thing next year and then people just come back and sit on it for a while and then go, this is supposed to be going live in June, isn't it? Or April or, you know, oh, all right. Let's ask if someone can do it in four weeks.

01:08 Yeah, I think a lot of people's year ends are also fast approaching. They'll spend that cash. Throwing their money around. Yeah, trying to use it all so they get it at the same amount again next year.

01:19 Yeah. That's how it works, isn't it? Let's get our money nets out and try and cash it. Catch as much as you can. It's like the ticket machine at the end of the crystal maze. I use that exact metaphor in a meeting recently where we were saying what we're going to do towards the end of the year. We've got hold our costs and then see how much new business can come in.

01:42 I just instantly, someone said that and I just instantly thought we've got to get the gold and avoid the silvers. Oh, how can you? You're just so frantically catching, grasping at thinner.

01:56 That's a metaphor for business though, isn't it? If you're frantically flailing around the place, you are going to pick up silvers. It was a really good lesson.

02:07 Brilliant. I love it. Cool. That's not what we're talking about today, though, is it? That's completely unrelated to what we're talking about. That was a terrible segue. Today, we wanted to talk about managing feedback, specifically with clients and how we both go about that in our different ways and some tips and advice we have for people about trying to get that right.

02:30 Sure. So obviously, presenting work back to clients is a big part of what we do. Do you guys structure the way you do your presentations? Is there a pretty set way of doing it or is it, do you do it a bit more ad hoc based on the requirements of the project?

02:48 Do you want me to say what I think we should do or what we actually do? Let's start with what you think you should do. Okay, fine. Yes, we structure it very, very carefully. I think most of the problems around getting client feedback and things like someone pitching in and saying, "Oh, no, I want it to be like this," and everyone gets down about it because the design you've worked on has been knocked.

03:17 I think most of it stems from just a lack of control from the point of view of the agency. I think much like in a sales process where you have to understand that the person doesn't know how to buy design. In this case, it's that feedback process. This person does not know how to critique and feedback on a design. They don't know how to do it. And yet, very few people were prepared to sit there in a meeting and say, "I have no idea what to say about this now." Yeah, that's a really good point. I think a lot of clients just don't know how to feedback.

03:56 A lot of people sitting in those meetings aren't prepared to sit down and say, "I don't have anything meaningful to contribute." Everyone's always going to have some opinion, and because they're the clients and they're paying you money, they feel like they need to contribute to the process, and they should, absolutely. I think structuring your feedback as targeted questions will definitely help in that matter. Not being too open and generic, saying things like, "Here's our design. What do you think?" And then just sitting back.

04:29 You've got to actively engage with them and try and lead the conversation to get the reactions that are going to be beneficial to the process of making amends, developing this design, taking the idea through to fruition. For example, you could start with a targeted question. You could say, "We've used this image because we think that the context of it conveys the brand messaging effectively, and also the negative space that is available in this image allows us the opportunity to overlay this primary call to action in the same space, making better use of available real estate above the fold." Do you think that this particular decision achieves all of those points successfully? Yeah. And I think it's that when you lose control of that, if you have any holes in it, the client will fill those holes. They'll just say, "Oh, okay. So the design agency are doing this, that, and the other, and my job must be this bit that they haven't covered. My job must be now to write a massive email with everything I don't like about this design." If you haven't said, "Here's the format we want it back in." So yeah, I think we're always striving to get a structure on this kind of thing. Now, actually saying that and applying it are two different things. Yes.

05:56 Because that's a lot of effort. And basically, every client needs a different structure often. And as I say, the moment you take your eye off the ball, the client will fill that with a process of their own. Yeah, I completely agree. I think a lot of it is really getting to know your client, I think, helps an enormous amount. If you know their character and the type of person that they are, you can tailor your approach to how you present stuff and also deal with them in meetings in person and on the phone and in email as well. I think you need to tailor your approach to feedback to each client because everybody's different and everybody, like you say, everyone has a different level of experience coming into this. Yeah, it's just figuring out the right way to handle each individual to the benefit of the project. And I think that's something that people, I think often where it goes wrong is that that time to figure out the client and design a process specific to them is something that people rarely imagine they're going to have to do.

07:00 They very rarely cost for, I suppose it's a project management cost, but it's not often an expected one. It's not time I would set aside as being dedicated to that. It's just something you gain from experience of dealing with them, I guess, isn't it? It's like an intuition.

07:18 Yeah, agreed. I think you've got to have authority. That's the main thing. And that authority kind of starts from the first time you meet them. And I often think that where this stuff goes well is where you've managed to convey before you've even won the work how this will run. And if that then can make it over into the project and be in someone actually looks to you as the figure of authority on it. And so it's really hard because until you're able to act like that authority and charge like that authority, to be honest, I mean, I think where we most probably struggled with this was back in the early days when we were fairly cheap. And if people think you're cheap, they're much more likely to say, okay, well, your opinion is worth this amount. And so I feel it's fine. I can take it or leave it where, you know, once you get to the point where your rates go up and people are then saying, well, I've paid for your opinion, I better listen to it. Yeah, a lot of it is coming across as being the expert, right? These people have come to you for your expertise. And if people don't recognize that, and they have no value of your expertise, it's a very difficult point to start from. And it's important to recognize that as soon as possible. Yeah, completely. And I mean, I've done this, or we've done this, I mean, I'm not, as you know, a designer. And so I actually get to take out the kind of personal side of this when talking to clients, because it isn't something that I put my energy into. Yeah, but does it apply to development as well? Or do you think it only applies to creative? It would apply to like how a feature was delivered. But then the person's still looking at the design of that really, the difference is the authority. Like with development, you've pretty much got total authority, because it's all just weird characters and dollar signs and treble equals. And you know what I mean? And no one really wants to contest that, because they just they don't have a frame of reference to, you know, every now and again, you get a client who, you know, it's a sort of a little bit of knowledge is a dangerous thing, sometimes someone that will ask you and quiz you on how you're going to do things. But generally, you get good at making that person feel comfortable with the approach you're going to take. So no, it doesn't really happen with development, I would say. And I think it's just about trying to get to the bottom of what they're saying and why they're saying it. Right, it's really you need to you need to practice this and know that client because there's so much going on in that meeting, you know, there's designers who've worked hard on it, there's there's clients who are worried about the end product who've brought a load of preconceptions to it. I think you've really got to work hard to set a stage where this conversation is had in a constructive way. And it's taken us ages to set that stage. I mean, you know, I've had ones where I've had to ring a client back up afterwards and be like, we completely just bullied you. I'm really sorry. Because, because we basically got our teeth into an argument about why a design should be a certain way had a completely valid point, but just to presented it so badly that the person was just left saying, well, fine, you know, you just go with what you want, you're the designers and you just and you suddenly realized, okay, this isn't the way to do it. You know, you, you can be right about design, but you've actually got to get through this meeting out the other side and everyone feel like the right calls were made. Yeah, yeah. It's important to be able to have that authority around what you talk about. And I think the way you go about that is to really think about why you're making every decision as you're making it. And especially in design, just, it isn't really about intuition design. It's about skill. It's not art. It's design. It has to be used. And so if it needs to be used, especially in a digital realm, there's a reason behind every decision you make. And admittedly, you can be making a lot of those decisions subconsciously as you're making them, but it's important to try and have a mindset as to why you're doing what you're doing and form like a mental log of that, or even write it down as you go. That will really help you understand the process and everything that's going on so that you can communicate when you come to that meeting with a client, exactly the process you went through and why you did what you did. That I think will help reduce feedback, just having, having some justification for the things that you've done. Yeah. And I think that's, I think that's the thing you get good at as a designer, isn't it? Up until that point, you've probably been making these good design decisions, but you've no idea why you just kind of been running on a world instinct really. And then you, and then I suppose you slowly learn why they're good decisions and how you should justify them.

12:31 Because until you can justify them, you are, you know, you, you're, you have no defense against someone coming and asking for it to be changed into something that you know doesn't work. And I think that's, I mean, it is, it is just experience, but I suppose the quick way to get that experience is to maybe, you know, get that feedback off someone else first. And you know, you can, you can test design. Yeah, people often think that it's completely subjective, but actually, it isn't at all like you can, you can test design on someone, you're just not, it's just the questions you ask is what's important. And the question shouldn't be, does it look nice? Do you like it? The question should be what did you notice? Yeah. Why do you think changing it will make it better? Exactly. What effects do you think that will have? It's really important not to get defensive over this stuff. Because you know, it's also very likely that you could be wrong. It's not that because I'm the designer, and I'm the expert, I know what's best all the time. It's about getting to a solution that everyone in the team is happy with, and making everybody confident that you're making the right decision as a team. How do you deal with them? Because I agree with that. And I think a design discussion often needs like time and space, which a project sometimes doesn't give it.

13:56 So often the you're presented with one of these bits of feedback, like, why is that navigation item over there? Or why have we put this stuff down in the footer? And there is you need time to consider it. Like sometimes it's not a straight off, well, because this list of justification, sometimes it's like, do you know what, that's actually a good point. And now I need to think.

14:26 But often, do you design your feedback process to allow that? Or you just in the moment with the client and anything you don't manage to justify gets changed? No, it's nice to have time to reflect on feedback as well. I think sometimes it's good to just acknowledge that there could be a better solution out there. Try not always to solve everything on the spot. You're going to rush into decisions and suggest things and maybe get by on something that might not be the right solution because you haven't had time to think about it and test it and see what it actually looks like when you get your hands dirty. I guess the important thing is to get them to trust you that you can come up with the right solution. Yeah. To give them the reassurance that I am the expert, give us time. That's a good point. We'll take that away and we'll see if we can come up with a better solution for it. And you can go and try a few things and then you may come back to the client later and go, "We tried a few things. We think the original version is better for this reason." Or you may come back with something different to your original design and come to the conclusion that it's better for some reason or another. Yeah. I mean, I think a good designer can really respond to a lot of this feedback pretty instantaneously in a meeting. And you should have a good reason for everything you've done and you should be able to justify your decisions clearly, objectively, and without getting personal about it. It's nothing personal. You didn't decide it for any personal reason. You decided it for a professional reason. If you can't come up with a defense in that moment in time, you just say, "Oh, that's a great point. We'll make a note of that and we'll work on it and we'll come back to you." And then it gives you the time to go away, reflect, and see if you think there's actually something valid in their comment.

16:17 I think one of the... Yeah, completely. I completely agree with that. I think one of the interesting things about it is also the amount of work we now do before the type of design that receives this comment appear. Because these comments rarely appear until you're looking at something visual with colors and rounded corners or potentially gradients. I don't know what your designers are using these days. You'd be surprised. We give wireframes to people sometimes and we get feedback. We get design feedback saying, "Oh yeah, it's all really good, but do you think we should have a bit of color maybe?" It's a bit gray. We've had the flip reverse of that, which was when we moved on to proper production design from a wireframe, the feedback was, "Oh, the wireframe was so clean and great. It was so minimal. We loved it." It's like, you want it to look like the wireframe. I think your wireframes looked too good, mate.

17:26 Yeah. That's the problem. Completely. Yeah, we still got one. Don't make your wireframes look good. It's a dangerous, dangerous road. Keep them scrappy. That's very true. That is very true.

17:36 But no, so what I was going to say was these days, there's so much work that goes into leading up to that. Researching. Well, I mean, you guys are the... That's your thing, right? The user experience side of it. We have that as part of our process too. It's just not quite as much for our speciality, so we're probably a bit more lightweight there than you are. But it's still a load of stuff that's building up to a justification for design. I think, again, it's become obvious that that's what's required to do good design. And so I suppose this sort of feedback and not having justifications from it is actually, as well as a symptom of not controlling the scenario by which you present design, it's a symptom that the design hasn't maybe been thought through completely anyway.

18:26 If there's nothing to lean back on and go, "Well, the reason the site maps like that is because of this goal that we all decided the user needed to achieve." Whereas actually, if you just go straight to saying, "Oh, this is what the site maps like," then that's when you get feedback like, "Well, should we have it alphabetical?" Or, "That link go down somewhere else." And so you, again, it's that authority, but it's not a fake authority just for this cause of getting sign off. I think it's basically what you slowly learn over time. You need to actually do a good design. Yeah, yeah, I'd agree. Do you ever take it to the point of saying, "Okay, let's decide this in a user test?" It depends on the project and how it's being run. If it's the type of project where it's ongoing and we're already doing a lot of testing and particularly multivariate or split testing, in those scenarios, you can try a few things in design and you can let the numbers decide.

19:22 But I mean, it only works on longer term ongoing projects where you probably have a retainer and they're a very conversion-centric product where there's a clear funnel and they need to convert people through a funnel to achieve some task. Those sorts of things warrant that sort of testing.

19:40 A lot of other stuff really doesn't. If it isn't conversion-focused, then split testing is hard to justify because it does take a lot of effort. But you can, like you said earlier, you can test design. You can do it on a small scale. In the same way you would use it to something, you get some people in, you would put them in front of it and just ask some reactions basically.

20:04 We often try to get that in if we're ever doing user testing sessions using a design prototype as well. As part of that, we won't only look at user experience and how people go about trying to achieve certain tasks in a product or service. We will try to sneak a few more subjective questions in there to get an opinion back on the design and if it's achieving what it's supposed to achieve, conveying the right sort of brand messaging or convinces them to take the right kind of action.

20:33 It could be even brand level and does this communicate what this thing is supposed to do as a whole. Sure. It's definitely testable. It's just whether you can justify the time to do so. Not every project you can afford to test the design. Completely. I feel that design testing, as you say, is something that you build up on, as most testing is to be honest. We do do testing a lot as part of projects. I always see testing as a way of trying to cause a cultural change in that company because I think you can learn a nice amount of a usability test on something, but really testing becomes effective when you're repeatedly testing and carrying the learning forward to the next test and then trying again. Obviously, in most projects, certainly because we're not a usability testing company, most of our projects, they don't get that much testing. It's more a kind of, "Hey, look at the amazing things that this one round of testing told us. You guys should keep doing that." The way you sell how you're going to decide on design is quite important and actually leads to probably, again, some of these problems being mitigated. You have to really set the stage that this is going to be about, does the design solve the problems? I always hang user testing there. If we really come to a stalemate here, then we're going to ask the users. Actually, that's more to just keep them thinking that that is how they should break those stalemates. What do the users want? Is this a user's opinion? If you keep asking that of them and of yourselves, then the argument is always grounded in that place. No one's going to be right or wrong.

22:25 We're just trying to find out what the user wants. You've got to remove all subjectivity from the conversation. It's not about asking whether you like blue links on your site. I do. I do.

22:37 It's about asking what blue links can do for your business. They're so much more clickable than the other colors. Some of this stuff is really subjective. A simple thing like a color can really change one individual's opinion, but this is where testing can come in quite handy because you can change variables like colors reasonably quickly if it's wanting the code at a CSS level across the board and split test them and see which ones do convert better.

23:12 Yeah, absolutely. It is hard to have those conversations without data to back it up. I think I find myself using that whole "it's about the user thing" as a way to frame the conversation. It's not necessarily that that's how the conversation is going to go because, as you say, it actually takes more effort than that to find out what a user actually thinks.

23:36 But it's just if people have their heads in that place, then you find resolving issues way quicker. You just find you can talk more openly about why people do and don't like things if you frame it as a third-party opinion. It's more a technique like I don't for one minute think that by sitting there, I'm doing proper user testing just by imagining what a user might want, but it does help keep that conversation on track, I think.

24:07 There's one thing I do debate with internally, that is amongst all the other things I debate internally about, is there does come a place where someone's got to own the design, right?

24:18 And at a certain point, if no one really knows what something should be like and it's a mixture of opinion over what someone might want, I always just think, well, the same person should win all of those arguments. So that should be the designer who's trying to hold all this together.

24:37 I suppose what I'm getting to is when you're showing stuff to get feedback, you're often showing a small part of what is actually quite a large design system.

24:48 So in the designer's head, there are screens upon screens after this screen that's being shown, which use elements from this screen and the whole design patterns will flow through the site.

25:03 And yet you're having a conversation about how many screens, I mean, how many do you show, like one or two at once? Really depends. You may show one half-finished page.

25:14 You may show 10 completely finished ones as part of a system. I guess it depends on the project. Sure. At the moment, working on an interface that's insanely complicated and just a lot of functionality and hierarchy to convey in a single page. And it's taking a very long time just to get the first page at the door because the fundamental design system has to start with this page, which is the most complicated looking view we could conceive of in the system.

25:44 And if we don't nail this correctly first, nothing else will fall into place later. Sure. So we showed it when it was a quarter done, a half done, and it's about 75% done now.

25:59 And we've just shared it again. So they're seeing the sort of evolution of this design language forming, but there's a lot of stuff on the page. It's not like a simple marketing message and a call to action or anything like that.

26:10 Yeah. At the same time, obviously, when you're designing something, especially something that's large and has many elements to it, there's a whole design system that needs to be developed as part of getting to a complete design solution and only addressing a small part of that, even if it is the most complicated part, you're not going to solve the entire design system.

26:34 And you shouldn't consider every single little detail signed off after presenting that back to someone and getting some feedback. You should be expecting that the design details and the design system as a whole to evolve as you continue to look at other templates, other pages, other sections of the same system. It needs to be a continually evolving organism. It's not something that you can just define a definitive, unmoving set of rules about from the very outset and expect that to apply to areas, interfaces, content that you haven't even started looking at yet.

27:13 So you've got to be flexible, but at the same time, some of these rules could permeate throughout the whole thing. And you need to be aware of what's ahead so that you can be laying relevant groundwork for a design system that's going to be flexible enough for the job which you're working on.

27:29 So from that point of view, how do you decide when to show someone something? Because surely you're also up against the kind of, "I don't understand this. I need to see it all finished," versus, "Well, that'll be a complete waste of time if we show you this and you reject it." And it's finished state when you could start rejecting it now so we don't waste all that extra time. Or love it. Obviously, there's sometimes it goes well.

27:59 I think it comes down to projects and the client. It's a judgment call. And it's about, "At what point am I going to get the most useful feedback that's going to benefit us, our process and the project?" If it's a relatively simple sales site for a product and the client doesn't seem overly design opinionated and relatively trustworthy in your expertise, then you could do quite a bit more work, take that to them, and be quite confident that you would only probably be looking at some minor changes. On the other hand, you could be dealing with a very complex and difficult to visualize functional product. And it's a lot of work to get to a finalized version because with anything we do, we always start with the most complex thing we can as the starting point for the design. Yeah, in those scenarios, I feel that the sooner you can show something, whether it's finished or not, the better because there is so much effort involved in getting to that first complete page that you need the incremental feedback as you're going so that if there are any major blunders that the client has an issue with, you can address those sooner and waste less time. I think, yeah, no, that makes sense to me. I think there's always a battle to make the whole sign-off process something that doesn't damage the project because it's such an unnatural thing to do in the middle of a design to prepare it for this thing where it's got to suddenly punch its weight even though it's not finished. If it wasn't obviously completely necessary for someone to actually pay for it, it can't be seen as anything other than wasteful really, as in you wouldn't do it ideally, would you? Or do you do it internally anyway with stuff? Yeah, of course we have lots of internal review. We wouldn't just put one of our designers on it and leave them in isolation for a few days and then blindly take what they've done to the client without doing any sort of internal review of it. We're constantly sitting down together, going over it at every step of the way, working out as a team what we think the right decisions are also starts to build that decision-making story so that when you're presenting you've got a narrative that you can refer back to. And also challenge. I mean, I find as a non-designer, you know, what I'm looking for is to say what here can I challenge is not making as much sense as it should or what in this design is the first thing they're going to call upon. Again, that is one of the problems with showing things that aren't completely polished is if there are real kind of sketchy bits or just stuff that's been just thrown on, you know, don't worry about that.

30:38 That's just to balance the page until we look at that. Every one of those bits erodes confidence and take a bit of focus away from what you're trying to get out of the feedback. So it's super complicated. And I mean, especially since they invented bloody mobile phones, I mean, you know, once upon a time it was like, this is what your website's going to look like.

30:58 Sign it off and then we'll build it. And now I feel like that is hard to measure when you should be getting that feedback. And I suppose what I find we do is challenge our process so often that we never get good at the process. You know, you're like, you're sort of like, well, that process is fine, but we should really do this and the other. And I think what we've fallen back on now is what you highlighted is that actually each of these is going to be different.

31:26 Each client's different and each design is different. So whilst it would be lovely as an agency to just have, oh, well, we're starting the project then. So we're going to book in a design feedback meeting in four weeks or whatever, because we're always at the same point there.

31:42 And we'll get the feedback and do it. And, you know, and that's what people used to do. I used to be like, you know, how you still get asked the question, like, how many rounds of feedback will we get for that price? And you just sort of think, well, at what stage, you know, and just that question just makes so little sense to me. I suppose it needs, you're the one that needs to make it make sense, right? You're the one who needs to say, well, here are the parameters by which we'll be collaborating on this design. And even though up until the point of working with us, we've been saying that this is going to go perfectly, you know, these parameters and this feedback is going to cause some waste and some imperfection in the design because things get lost as they're going back and forth. I mean, that's obviously natural in any project. But as you can tell, I struggle with the whole concept. I don't think it only applies to design either.

32:35 We get a lot of feedback at the earlier stages of the project, just in sketching and wire framing. One thing that we've struggled with on a few projects is when we've been hired to help a client develop a solution for what's been pitched to us as an MVP. And the whole time we are concentrating on making it as simple a user experience as possible, making the product minimal to make it an MVP and ship something to market. But the client, this is a bigger question perhaps about what an MVP is, but the client has a vision around what they want it to be that perhaps wasn't completely clear at the beginning until you got into the detail. They want to make it a lot more detailed and a lot more complex than perhaps it started out as being. And they're constantly giving you this feedback that they want to add this functionality, add this feature, there's always a reason for it because they know their market and they've got a lot of knowledge to back it up. Have you ever encountered that kind of scenario?

33:30 Oh yeah. How have you dealt with that and trying to steer the project's experience and just the project as a whole in terms of delivering what you envisioned the roof to be at the beginning?

33:42 Yeah, well that's MVP as a euphemism, which is the same as the euphemism of phase two being that's never going to happen. But it's still feedback, isn't it? They're giving you feedback as to how they would like to see your output be steered as you're going.

34:05 Yeah, and MVP is so often just used as a, "Can we do this cheaper than you said you could do it?" And it's a bit of a fashionable term. I think it's probably easy to get signed off if you're saying we're doing an MVP. Like if you're a person in a company and you want to build a product, someone says, "Well, that sounds elaborate and how are you going to justify the money?" You say, "Oh, it's fine. It's an MVP. It's a learning thing." So we also don't even have to be successful. We just got to learn something. And agreed.

34:35 We do a lot of product stuff and obviously we're developing that stuff as well. Yeah. Yeah. Again, it's about trying to impose an authority on how to choose features, on basically product ownership.

34:48 The process. Yeah, completely. And if you don't... Again, it's exactly the same situation. If you don't impose that framework, then the person you're working with will fill all the things that you didn't say. Like if you don't impose how to be strict about keeping features simple, and if you don't keep pounding away, if you don't drive for simplicity, you'll get complexity.

35:11 If you don't keep pounding away on that, then the moment you look away, your backlog of features will be full of completely wild features that you can't possibly say is MVP. But how much do you push back? That's the thing. Because you...

35:26 I mean, there's a limit, right? There's a line of how far you should push back. Absolutely. Because ultimately they're hiring you to do a job and if they absolutely assist, you've given them all fair warning around what you think is the right decision to do, and they still insist on making their decision. What can you do? You can walk away from the project, basically, or do what they ask. It does come to that point at some level.

35:49 It completely does. I think with the product features, it's much more damaging to give on those things. Often it'll cause overruns in time. If you haven't carefully structured the project, agreeing to a feature being done a different way or a feature that you hadn't thought would be in there, obviously you should be trying to protect yourself to make sure that that's a change in scope and you can build for it. I suppose it's slightly different to design feedback, but yeah, completely. The thing remains the same. Picking the client and just making sure you've got some working hard to build up that authority and not messing up your authority by leaving a stupid mistake in. As soon as someone sees that and you just see them change and be like, "Oh, right. Oh, that's the typo in our company name at the top there. I really need to check this whole thing over and these guys are clearly needing quite a lot of feedback from me." That's the sort of thing that happens. We're on a slightly different topic now, but I think it's definitely, yeah, it all comes back to you've just got to work hard to build authority because that's what's going to get you feedback you want when someone actually just, like you say, someone trusts you. Yeah. Sometimes people just aren't experienced as we touched on earlier, they just don't know how to communicate what it is. They're trying to get across and their feedback can often be misinterpreted, which is a danger. I often find if they say something that doesn't seem to make sense, actually try and help them make their point, try and help them articulate what they're trying to say, reframe their question and reframe their feedback, put it back to them as another question for them to sort of extrapolate on them. It makes them step back and think about it more and it gives you more time to think about a considered response, especially if you're in a face-to-face scenario. Yeah, completely. Because often they will have insight that you don't have over the user. Yeah. I mean, the classic example is, "Oh, can you make that button red?" And you're like, "Well, that's just an awful design decision." But essentially what you're saying is that button is really important. People need to see it. At the moment, I feel people can't see it. Most of the design in our place, someone will grab me and say, "Look at this." And yeah, I think that's my one contribution to the design process, is to look at something and go, "It looks fantastic, but that part of it's lost." And I'm very careful to not say, "Why don't you make it blink?" or any of the other great ideas that I've got in my locker. I'm very careful just to state what my problem is with it. It's just stating the problem and that's the kind of feedback you want. And I try and coach clients with that.

38:41 We're always trying to like, "Just give us the problem and we'll try and find a solution." But you've got to earn the right to do that because when they do just give you the problem, you then got to go and find the solution. We've had that before where we've done that. And I think I've ended up with a slightly frustrated client going, "Dan, I know you just keep telling me to give you just the problem, but it's not getting solved," kind of thing. So solve it by making the button red.

39:05 And you realize you've got to earn it. You've got to manage that process. And you're right. When a client does give feedback, you've got to help them with it. And certainly the way to get overridden is to just go, "No, no, no. You don't want it red. It's this color because that's a nice color with these other things." You'll get overridden. You'll lose it.

39:30 Yeah. If you don't have a good argument, if you can't defend why you made your decision, give a valid reason for what you're doing if it's just opinion. Or even if you deliver the valid reason that you deliver it in the wrong way.

39:42 Yeah, yeah, yeah. If you make them feel, "Oh, I know what I'm doing. You don't," or, "You're not of value to this design process," you're going to get what you deserve. Yeah. You just say, "I like it," or, "I think that's better," then you've lost.

39:54 Yes. Basically, you've got to remove those words from your vocabulary entirely and just focus on what decisions you made to get to that point in the first place. And if you don't have any valid reasons for the decisions you made, perhaps they weren't the right decisions.

40:08 I mean, absolutely. We're just experimenting with... I heard the guys chatting about it the other day, a way of showing design but showing it in the context of the previous work that has gone on. So...

40:20 I mean, the previous versions of the same design. Yes. And maybe even the wireframes and the research. And if they're doing moveboards, they get back and forth on moveboards. Moveboards are hard to get feedback on as well.

40:37 Oh, don't bother to do that. No. I think basically there's something about them we like for certain things, but the feedback you keep getting is like, "Well, they were so colorful and amazing." Yeah, there were lots of different sites altogether. Okay, fine.

40:54 There were lots of moods on there. The moods were amazing. Where are the moods? Where have they gone? But no, more. Even if it's just as a... I'm going to say the word "garnish," which is ridiculous.

41:07 But even if they're just there when you're looking at a thing, even if they're not a foreground thing that you're meant to be looking at, if they're just saying, "This design has come from somewhere," this is not the first time anyone's done anything here. And I think that can be important if someone's seeing it new, who's just like, they don't know what's the feedback on.

41:26 They don't know, "Oh, this is near the end," or, "This is the first stab," or, "What are we to think about here?" I mean, I've heard people use video effects for that kind of thing. Have you ever done a video showing people who are designed to kind of get to stakeholders that aren't...

41:42 Because one thing people can mess things up is if a design gets out into the wild, which again, you lose control. If a design's like, "Oh, I'll just share this with the board." Oh, dear. Yeah, that's a warning sign.

41:59 Yeah, but one way of doing that potentially, we haven't done it. I've heard it can work quite well, is to actually say, "Well, the board gets to see a video of me showing the design and talking about the design." Oh, so you record the presentation.

42:11 I think that's what you do. That's interesting. Yeah, that is interesting. We've never done that, but I can definitely see a lot of arguments for keeping the design in the context of its journey to that point. Because the moment it comes out of that context, it's vulnerable to someone misunderstanding what it's meant to be, where we're meant to be with it.

42:32 And that's where the feedback can be like, "Oh, well, this would be great when they've changed all the colors and put that big background thing I'm thinking of on it." But if someone sees like, "Oh, right. Yeah, the big background idea got rejected in the wireframe stage." That's it again. It's like just keeping control of that process. And sometimes you just can't be there, I suppose. Yeah. Well, I would always advise anyone to always try and do face-to-face meeting, at least for the early stages of these big steps in the presentation. Never just send stuff with an email with a whim and a prayer and hope that everything's going to be fine. You can do that later on when everything's mostly resolved and you're just rolling out a design language that's been agreed upon and signed off. Even if you can't actually be there in person, just do it with Skype and screen share and talk through the whole thing. And maybe recording that would be a good idea if you want to share it with more people afterwards. Yeah. That's a nice idea, having that sort of supporting argument or at least the decision-making behind how it got to where it is.

43:33 If you just show people stuff out of context, opinion just creeps in and there is no quote context. Yeah. One trick I always use is to always start the meeting with how you finished the last meeting. Okay. So even the last meeting, you look at some wireframes, you spend the first few minutes just doing a very quick run-through of what you covered off then or what's happened since on that part before you step into the new stuff. So it's exactly that. It's that context of where you're at, especially because you've probably been looking at this constantly for a week, two weeks every single day and it's been on your mind and you're completely aware of where the project status is at. Your client may not have looked at this since you last saw them a fortnight ago. Yeah. May not have thought about it since and couldn't remember every detail at that meeting. So it's important to bring some of that history back to give some context in order to control the kind of reactions and the feedback that you're probably going to be getting from them. Yeah. Because to own the process, you've got to take responsibility for that. You've got to be responsible for the client understanding and giving good feedback. You can't just turn around and be like, "Oh, well, it's not my problem that the feedback wasn't very good." It's like, "Well, this was your process." And if it wasn't your process, then that's your first mistake. Yeah, absolutely. Awesome. Nice. Any parting thoughts? No, I look forward to lots of feedback on this episode from the wider community of pod listeners. Yes. Yeah. Hardly say that everyone working on the project, you're on the same team. You're all trying to achieve the same goals. It's not a fight. It's about trying to make the right decisions for the right reasons. And there's always a path to getting there. It's just finding the right one. Completely. Yeah. I'd just be creative with it as well. I think your process is almost a way of marketing. If you've got a creative process and the way that you go about getting feedback and you explain it nicely, design that process in the way that you design everything else. And if you can make it enjoyable, people will say, "Those guys had it. That agency was great." Something you can actually be creative with. Good. Well, I hope that helps some people. As Dan says, if you've got any feedback, the place to get us is at www.perspective.fm. On our website there, you should find lots of links to give us any questions, comments, or feedback. We'd love to hear them. Also, if there are any topics you'd like us to cover, please get in touch there. We'd love to hear from you all. We're on iTunes, so please go there and give us a rating. That helps us out a lot. If you haven't done it yet, please go there right now. There should be a link on the post for this episode and every other episode on our website, www.perspective.fm. We're on Twitter, @_perspectivefm. On the Facebook and everything else, links are on the websites. I've been John Dark at @darkjohn on Twitter from Every Interaction, @everyinteract. And Dan, where can people find you? We are @WeAreLighthouse on the Twitter, WeAreLighthouse.com on the webs, and @GentisMaximus on Twitter as well. Good stuff. All those links will be in our show notes. Thanks very much, everybody. See you next time. See you soon.