Whether you’re internal or a consultant, we chat about when it’s appropriate to push back on the decision-makers and how to go about doing it.
Matthew: I’m on antibiotics for the next five days and then.
Matt: What do you have against Biotics?
Matthew: They know what they did.
Matt: So yeah what we’re gonna talk about pushing back on clients I think in general, giving clients feedback to their suggestions that might not be in line with what our suggestions or recommendations would be. If I could give a little background on where this topic kind of came from for me.
Matt: During a workshop teaching a class with some folks last week. And it was all internal, they all work for the same company we were talking about well lots of things but, we were talking about UX design specifically and these were not trained experienced designers but they’re kind of transitioning into that role and they’ve had a lot of issues in the past and they’re good, they’ve got good instincts and they’ve had issues in the past pushing back on clients. Clients want the interaction to be a certain way and the design in their web based software and these guys would push back and the clients would basically railroad them and say no it has to be this way and they didn’t have any backup if you will, they didn’t have a leg to stand on in their arguments.
Matthew: The clients you mean.
Matt: Yeah my participants, my students to their clients. And what I’m asked point blank in the training like what are some techniques, how do you do that effectively? It was a really good question and when you’re asking it from a position of inexperience, you’re in for lack of a better word, a weak position to argue I think. And that how they felt like they didn’t have the confidence and the background to have to put up a good argument even though what they were saying they felt was right and from what they told me they were valid arguments. But the client just still feel, the client still kind of bullied them into what they wanted right or wrong. And with those cases it sounds wrong. So I hope that’d be a good topic for us to expound upon. Some techniques, maybe share some stories of when we’ve been in those positions, things like that.
Matthew: Well what about you?
Matt: So and also I had a hard time coming up with some concrete examples like one that I told them I was on a project a few years ago, this Interaction design project and one of the other topics I was teaching this class was about standards and using pattern libraries and those types of things and I was doing this project and I was doing Interaction design and the client or someone on the client’s team was pushing back on some insig, not insignificant but some widget control that I had used and said why don’t you use that one or basically questioning it and it was funny cause it was something from their patent library. Like they actually had an established patent library and like this is something from your style guide, if you don’t like this then let’s, that’s a different conversation. But in general my general feedback was you know these things can be argued or discussed in a way that makes it objective so a lot of the feedback from clients feels like its objective. It’s based on their own experiences with whatever software they happen to use.
Matt: Whatever they have in their head or I use this software at home and I like it so why don’t you do something like that. So I talked to them about things like you know obviously user testing, understanding what the actual target users want to use and what their other tools that they use do and try to match those expectations and those patterns. And if that’s not available and these guys did talk, we have talked extensively about their lack of customer interaction but during a new usability test with customers and if that’s not possible then you look at just basic standards, look at basic heuristics, things that are more objective and try to like frame the conversation about well this is the problem we’re trying to solve, it’s not a preferential thing, this is why this solution we think is better based on x y and z. So it’s less about I think this, you think that and try to remove the subjectivity from the conversation.
Matthew: Yeah I think that’s always a good point, it’s almost as if a really handy decision tree would be helpful.
Matt: It can be helpful.
Matthew: Look hard and say you know okay this situation is this and then. So one of the things that can sometimes come up is you know I want to use this widget or I think we should use this transition or this interaction or whatever the small thing is that sometimes the issue they’re having is not really about that, that’s just what they’ve decided to focus on and pick on because they either can’t articulate or don’t think they should articulate what’s really on their mind. And I think that that is, for me a really good starting point of is this really about what they’re talking about? Alright that’s sort of my first pass of to to what extent does this need to be addressed? And then after that if it really is that’s the issue then I think you’re right it’s going down and try to make it as objective a conversation as possible. My next step would be to not really make any comments but start asking questions in hopes that they talk themselves out of it. The classic interviewing strategy, what led you to choose that? What led you down that path? Or dow did you.
Matt: Tell me more about your thought process.
Matt: If there was one.
Matthew: Because I think a lot of times if you can get people especially verbally not over email but I think these are conversations that you need to have a little more high fidelity with, if you can get them to verbalize it, they hear it sometimes, not always.
Matthew: And then they’re like oh okay no no no like you know and they will either back down a little bit or back down completely but if they are still pushing I think we then have another decision point of okay, can we let this go?
Matthew: Right. What do I think is gonna be the impact if we just let them have their way?
Matt: Right and actually that’s where our conversation led us well like at some point you have to make that decision, as a consultant or just a client, you know is there something, how hard do we wanna fight for this?
Matt: Is this gonna break the app? What is the risk involved.
Matthew: And then communicating what we think that risk is.
Matthew: Because it’s like okay, if we do this here are what the risks are especially if we are not going to go and do any testing afterwards or before to see what the impact is going to be, here is the risk, are you signing off on that risk?
Matt: Right. And it might be something they are like yeah we are willing to sign off on that. Like the example that these folks were telling me about was in this particular case, the actual users, they knew that they were at Microsoft Office all day long. They are using excel at work and so they’ve had an interaction that kind of models the Microsoft pattern and the client didn’t want to for whatever reason I think, can’t remember the details and so their reasoning was well we wanna stick true to what customers are used to and the risk was customers might have more trouble learning their application and following through on the critical tasks. Explaining risks is a great tactic as well and I think some people and I know you’ve run into these folks as well, you have clients and they just, lack of a better word, they’re stubborn or yeah they just think they know, they’ve been around the block, they’ve been working at a product for 20 years.
Matt: Whatever reasons.
Matthew: I was in the field 20 years ago, this how we deal with it.
Matt: A quick anecdote related to this, I was working on a project and this stakeholder was really against user testing during research not even usability testing just going out and doing interviews. They already knew what their journey was like and blah blah blah. We went out and did it anyway even though he was against it we convinced him to let us go out and we came back and we were doing a read out and we had twenty somewhat people in the room including people that actually talked to customers like support people who work for this executive and we were going through it and he was questioning our findings, saying like he knew better or this wasn’t accurate information and then actually some people, one person in particular stood up at the workshop and said no they were right. This is actually what happens and basically shut him up. And this is like a support lead or something to a director somewhat level person and that’s what it took.
Matthew: Well thank goodness for the support lead to do their job.
Matt: Right I mean it took courage.
Matthew: Quietly and so good on them yeah.
Matt: It was very good and yeah we definitely thanked them after the workshop like that took courage cause it was her boss’s boss’s boss’s boss whatever and that’s what it took for that stakeholder, that executive to kind of listen to us and take a different view like none of the things that we said, we could show videos, we could talk about quotes, it was just this wall we kept running up against of acceptance of research. And that was a little bit off topic but it reminded me of that story like sometimes it’s hard to know how to breakthrough and how to make a convincing argument and sometimes it has to be one of your own, sometimes it has to be an outsider, I’ve seen the other way exact the same way, they won’t listen to their employees but they listen to an outside consultant.
Matthew: Yeah and in some cases your role then switches to being in some respects an advocate for the internal people who really know what’s going on.
Matthew: No no no they know like in your scenario the support person was like no no no our consultants know what they are talking about.
Matthew: Other cases it’s like no no no your employees know what they are talking about listen to them.
Matthew: Yeah it’s something that I’ll say that I don’t run into a lot but yeah it continues to surprise me the level to which people will and it shouldn’t but it does the level to which people will hold on to their ideas even in the face of here’s all this data that is not where you’re going.
Matt: Or here is recommendations from people we’ve hired as experts.
Matt: To do whatever and yet there’s still not that trust but to your point I haven’t run into a ton either like when this person asked the question, it took me a minute to really think of some relevant stories or anecdotes that I’d run into.
Matthew: Well I’ve got one that I’m, one person removed from but I think it’s still relevant in that the CEO who has really thought this through and is presented with data that says otherwise, he’s forceful enough that the people who are presenting the data are like well alright we’ll try it your way. So eventually this company gets acquired and the acquiring company starts to integrate the company that they bought the software into their product and that was a year and a half ago maybe two years ago that that process started and I’d heard recently that they’re shutting it all down now because it is a shit show to use the colloquial. It turned out to be a bad buy and it probably wouldn’t have been such a bad buy if the CEO had listened to his employees who he had hired to be experts in these areas. I guess that it surprises me and also it doesn’t surprise me.
Matt: Which is not to say we’re always right.
Matthew: No absolutely.
Matt: And we’ve talked about this maybe they’re part extra topic for a potential future one it’s just having some humility when your are a UX or service designer and like going to the objective research or something. It’s not just about what I think is better.
Matthew: Right. Yeah I mean I know that I did this a little bit when I first started but doing the whole my way or the high way kind of thing probably took me a few years to get fully out of that mode but even within the first couple of years of my career, I could see the people who were really holding, like the UX people who were really holding on to my way way or the high way, were really getting nowhere. To me it isn’t my way or the high way, that’s not even the question. What is best for this context? The context being here are the people we’re impacting, here’s the outcome we want to achieve, what is the best thing? And this goes back to how it depends conversation of you’re constantly having to weigh and reweigh these different components of a project things that are jogging for position to be the most important thing as you go through the project. And it’s a part of our work that I think most people when they come into this kind of stuff are not prepared for unless they’re transitioning into UX from a professional job that they’ve had to deal with the whole politicking and negotiating stuff.
Matt: Yeah I think how I learned earlier on in my career was just being wrong. Like I’d have ideas and again this is ages ago where we didn’t have as much training or available knowledge transfer and I presented ideas and other people, other designers , developers, whoever I was working with that had better ideas and I totally recognized them like wow that’s, that is a better idea, you should be doing this. And.
Matthew: Well I mean yeah.
Matt: You do that enough you kind of realize alright I’m gonna come out with an idea and I’m open to other ideas because other ideas might be better. And what’s the point in holding on to an idea just to be right if it’s not the best idea?
Matthew: Right right yeah. I think I’m very glad that long ago I gave up on the desire to be right about things.
Matt: It’s so much easier to be wrong.
Matthew: Yeah I mean I feel like I am wrong about things a lot.
Matthew: But I’m wrong about them in the playground of our research and design process where I can say I think it’s this and then I can go and validate that or gather more information in general about it and be like hm maybe not so much that. But you know to your point, I remember years ago, we were, you and I were on the call. With a client and we keep picking on Greg.
Matt: I didn’t realize that’s where you’re going oh Greg.
Matthew: Oh yeah yeah. I don’t even remember what it was about but I remember that feeling when Greg said something, what if we just did this? And Greg for the context of the viewers at home, back end developer on the project, Matt and I were the shining UX stars.
Matt: Greg was the rock. Greg is awesome.
Matthew: Yeah. He said what if we do it this way? And I remember thinking oh that’s a really good idea, we should do it that way. He’s right. Now I want the whole team to, I know it’s not aways practical but I want the whole team to be involved in the research and the design stuff because these good ideas come from everywhere and.
Matt: Well and that goes back to one of our.
Matthew: We are the experts but we also don’t have all the answers.
Matt: And that goes back to one of our tenets of design as a team sport.
Matt: And you shouldn’t do it solo, staying just solo. Well you and I partner up on a lot of stuff but it’s not just having the UX mind involved so having developers or stakeholders who have a content folks, marketing whoever.
Matthew: As far as you know, how do you deal with it is the issue even about the issue that’s being talked about, if it is, deal with it. If it’s not, figure out what that issue is. And then is there anyway to get the person who’s being intransigent to talk themselves out of it and if it’s not, as you said, let’s make this objective. Let’s go gather some information. Let’s go gather what best practices are around us. And then if they still won’t budge, I think we all need to have our point where, I don’t want to use words like fight and things like that but we’re going to let it go and just let it happen the way they want. We have to take into account, are we setting that up for future behavior like this? Do we need to meet with this person individually or do we need to have a group session where hopefully a support person stands up and says Matt Wallens knows what he’s talking about. I’m not always a big fun of the do it out in the open thing because I think people can get embarrassed and they hold on to their idea even more but sometimes it works out.
Matt: And I think at the end of the day, the person writing the cheque gets the final call on a lot of cases but as a consultant or anytime you’re on the other side, you’re at least can document things so down the road if it blows up in your face you can say something or have something to say oh yeah we talked about that and we ended up going in this direction not to place blame but more of a cover. And again as you said it, it might not even be an issue, it might be a non issue that no one even notices or cares about and then you just move on and that’s a lesson learned as well. A lot of times like we talk about interaction design and that’s micro interactions have, they are all important and should be intentional which is true I do believe that but at the same time also sometimes you just don’t care.
Matthew: Right. Again it’s about the outcomes.
Matthew: But if you can get them to a positive outcome, maybe a little bit of, I know we’re not supposed to say this but maybe a little stumbling along the way is okay. You have to determine, is this a consumer app? Or is this a business processing app right? Where it’s someone’s job to punch in data. They’re gonna have a higher threshold for things being wrong than the consumer side is going to.
Matt: What if it’s some other critical application where errors can’t happen? You’re launching rockets to Mars or something hopefully we don’t work on this.
Matthew: No no I’m not really interested in projects where there’s zero tolerance for error. I like the projects that are you know if we are in the one to 3% tolerance for error, I’m okay, I’m okay.
Matt: Right I can still sleep at night.
Matthew: Is anyone gonna die by using this? No? Okay I’m in.
Matt: Especially me good.
Matthew: Yeah right. It’s not gonna come back to me is it? No okay. Ship it.
Matt: Do we have a rosy conclusion or was that it?
Matthew: No I don’t think we have a rosy conclusion and I think my inclination is that we’re often never going to have a rosy conclusion because what we apply to all our projects is a process, not deliverables, not outcomes, it’s the process we go through to get to deliverables and outcomes and those are often unknown when we start.
Matt: And similarly there’s no one solution to all the problems.
Matt: So to your point it’s a process and there’s no magic wand.
Matthew: Right. It’s not known whether that works, that works. See our episode on it depends.
Matt: So episode on magic.
Matthew: See our episode on magic wands, how to buy them, how to use them,
Matt: Right. It’s been a long day people.
Matthew: Long day.
Matthew: Alright. Well thanks for watching.
Matt: And subscribe.
Matthew: Are we You tubing correctly?