Designers: To deal with micromanaging clients, just say this
I recently saw a post on LinkedIn claiming that only 20% of the requirements for a design position are hard skills such as ability to build in Figma or design in a game engine. The other 80? Soft skills, like communication, organization, and client management.
This article will focus on managing your pushy clients, something every designer deals with at some point.
I’m a game and gamification designer, which sometimes imbues me with a sense of mystery and awe to other designers, or to clients. But the truth is, game design is like any other kind. And like any kind of designer, I’ve delt with my share of micromanaging clients.
You know the type. They have a great idea. They just saw something on another app. Their kids LOVE this game called blah and can we do this? Or maybe they just fancy themselves creative, and have some helpful “suggestions.”
These types can be hard to deal with, especially because they’re the ones paying your salary. On a good day, you might find a way to politely tell them “no.”
On a bad day, you might tell them “I’m the designer, let me design. You hired an expert, trust my expertise,” etc. This can come off as confrontational or at least it’s hard to phrase in a way that doesn’t sound dismissive.
On a really bad day, you might just let them tell you how to do your job after all to get them to shut up, and add in a feature or make a change to please them, not your user. This is something you should never be doing.
Next time, instead, try one of these strategies. They’re not magic words, but they will allow you to have a professional conversation based on mutual respect, grounded in the user’s needs, and no one’s ego.
“We decided together…”
This is my go-to. It works because it reminds the client they had a say already, and that they are an important stakeholder with a voice that matters.
This only works if you’ve involved them early in the process in what we call co-design. A great way of doing this is holding a workshop with client representation present, so they can offer their thoughts along with other stakeholders. It makes them feel like part of the team, and like they have some ownership over the final product.
Later, when they get a “stroke of genius” and ask for things to change, you can remind them of this process, and the specific findings from the workshop that led you to design it the way it is. Laying out all the facts and reasoning this way is almost always enough to justify these decisions, and the client will end up shutting down the new request themselves without you ever having to say “no.”
“We design iteratively, based on data.”
Another strategy is to anchor your reasoning in process, in this case the iterative process that any good designer should be using.
The client has an idea. Maybe it’s a good idea! Everyone has ideas, many of them good. They probably also have a good reason for thinking the idea should be implemented, otherwise why are they talking to you? But a good idea not based on data is simply an assumption.
I never trust assumptions, no matter how strong, not even my own. To spend the time, money, and effort required to change or add a feature, I need data.
There are many kinds of data and many ways to get it. Qualitative data can be generated from user testing and UX research. Quantitative data can be gathered through pushing features and A/B testing. There’s market research, brand research, academic research, and plain old user feedback. Any of these might suggest strong reasons to add or remove features, or change the design of a product. But none of them are “I saw something / I came up with something / my grandson likes this.”
This reasoning works because it does not say “no” or flatly refuse to change. In fact, it reinforces the idea that the app WILL change, must change if it is to be successful. And those changes may include things the client is suggesting (or close to them).
It just will happen iteratively, based on data. Which means later.
Most of the time, the client forgets the suggestion they made shortly after this. But sometimes, if the idea is strong, some version of it does find its way into the app!
Note that this is different than saying “Good idea, we will add it to the roadmap” with no intention of doing so. This is a lie and sows distrust. Always be upfront with a client. They’re not stupid and can tell when they’re being jerked around, and this harms your relationship.
We tried it, and it doesn’t work.
I use this one the least, but when I say this it always works.
The reason that I don’t say it often is because it has to be true to work. The suggestion must be something you legitimately tried already and failed with your users.
Note that it doesn’t have to be the exact suggestion, just something close to it. For instance, they might suggest a social feature where you can share with a friend via text, when you’ve tried a social feature that shares to Facebook, and found no one touched the feature.
“We tried social sharing before, and this isn’t something our users wanted,” is a good response. You can then explain the details and the reasons for this.
Honesty, still the best policy
I’ve seen a lot of product managers and designers dismiss clients by baffling them with bullshit, passing the blame to another department, or outright lying to deal with a pushy client. People do what they need to do. But if you take anything away from the above strategies, I hope it is to always conduct yourself responsibly, respectfully, and as honestly as you can. Your relationships are everything in any line of work.
Oh, and these strategies can also work on micromanaging bosses, but that’s another article.
Sam Liberty is a gamification designer and consultant. He is the former lead game designer at Sidekick Health. He teaches game design at Northeastern University.
