Category: UX advice / Evidence-based design methods

Client Knowledge

What you can learn

Unless they're self-motivated 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 more about what needs doing. However if they are good at their job, 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 learn from them 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.

How to do it

I find the best time to get a download of client knowledge is right at the start of a project rather than piecemeal throughout. 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 a client starting point to be a request 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 real issues, I make sure my client discussions focus mainly on two areas:

  1. What problems have they learned about from their users/customers (get stats and stories);
  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 diving into solutions. What you take from them 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 of knowledge 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 people another chance to chime in and clarify. 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.

Watch out for

Changes of mind

Halfway through a project it's possible that a client will decide there’s a bigger issue to tackle and will move the goal posts. This is why you need agreement and sign-off on the real problem you're looking to solve at the beginning: get it written down.

Talking to the wrong people

Make sure the key decision-maker for your project is in the room at the beginning, 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.

Early solutions

"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. Try and understand why they think this solution is so necessary and get to the underlying problem.

Too many ideas

Be careful of client meetings that ramble and cover every idea they've ever had. Try and keep the session focused on one primary objective and don't get drawn into solving hypothetical future situations.

Lack of agreement

It's possible that by asking lots of questions you might expose that the client team aren't in agreement about what is wrong with their product and what needs solving. It can be worth stepping back or even pausing the project while they discuss further and perhaps do research of their own. It’s far better to wait than to do work that doesn’t get used.

Example tools (and cost)

To gather client knowledge 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).

How long does it take?

Keep each client meeting focussed and take no more than an hour. Writing up and sharing for input should take about half a day.

How often should you use it?

Often

Sometimes

Rarely

Resources

Last updated on 12 April 2018
14 tools to gather evidence – guide

Here's another method

Guerrilla User Testing

Advice on doing quick user tests to get feedback on your prototypes. Learn more

Last updated July 2018

View all the methods in the guide