Unless they're self-motivated side projects, all design work has either an external client or an internal stakeholder commissioning or owning it (for the purposes of this guide I'll use the term client for both). As a designer it can be easy to be dismissive of them and think you know what needs doing. However if they are in any way successful the chances are they know more about their product and users than you do.
A good client is a valuable source of information who can save you time and energy on a design project. You should utilise their knowledge early in a project to understand the problems and issues they hear about most from their users. You can also use them to tell you the demographics of their users and their common behaviours, which you can double-check with audience data. On top of this they'll be able to tell you who their competitors are, so you can carry out competitor analysis.
Whilst their knowledge is a great resource you should be cautious of clients who are too ready with solutions. You don't want them just telling you exactly what to implement or they might as well have done it themselves.
I find the best time to get a download of client knowledge is right at the start of a project. It's important to make sure you and the client are on the same page and it's also important to dig into what the problem is that they really want solving. It's common for clients to come asking designers for a certain solution when after a bit of exploration it turns out they actually need something else. Just like interviewing users it's worth questioning until you get to the real problem.
To find this out I make sure my client discussions focus mainly on two areas: 1, what problems have they learned about from their users/customers and 2, who their users are and what are they trying to do with the site or app. The discussion should be problem and user focused at this stage, not about discussing solutions. The output should be statements about current behaviour and issues (e.g. 'Users mostly complain about feature x') or questions that need further research (e.g. 'What is the conversion rate of page y?').
During the meeting I make quick notes (often on post-its) of every relevant nugget and after the meeting I type this up into a Google Doc to share around with the client and their team. This states the main problems we're looking to solve with the new design and gives everyone another chance to chime in with any tweaks. At this point we should then be agreed on what the problems are, what needs more investigation, and what we're looking to design.
The above outlines the main time I use client knowledge as a piece of research evidence. Of course they are also there throughout the design process to input into designs but it is important to keep everyone focused on the originally agreed issues that need solving.
The client who changes their mind. Halfway through a project it's possible that a client will decide they want to do something different and will move the goal posts. This is why you need agreement and sign-off on the real problem you're looking to solve: get it written down.
Talk to the right people. Make sure the key decision-maker is in the room, otherwise everything you discuss could be scrapped if they haven't had their say. If it's tough to organise a group, you might need to run a separate meeting to get their input.
"We just want you to design one of these"—be wary of clients who come fully armed with a solution. They might be right but some clients see everything as a chance to design a brand new shiny thing, when in fact their users might just require a small fix to the existing product.
Be careful of client meetings that ramble and cover every idea they've ever had. Try and keep the session focused on one key problem and don't get drawn into solving hypothetical future situations.
Clients who can't agree amongst themselves. It's possible that by asking lots of questions you might expose that the client team aren't in agreement about what is wrong. It might be worth stepping back while they discuss further and perhaps do research of their own.
You'll need something to take notes with (notebook, post-it notes, laptop, or tablet) and it's worth recording on your computer or phone too. Then you'll need something for sharing these notes around, I like Google Docs (free).
Each meeting should stay focused and take no more than an hour. The follow-up should take about half a day.
Sign up to get the latest Evidence-Based UX Design Guide methods via email. AND pick up a free download to my favourite 10 tools to help you design with evidence.
Note: the examples in this guide are for website design, but most of the content is also applicable for native apps and software.