A Cautious Approach to User Input

In an age where user experience is vital it can be tempting to enable projects to become user-led. After all, if we want to please our users, why not let them specify the products that they want? Then we can create those products and be certain that they’ll sell right?

Wrong. In many cases users are not product designers and they have no idea whether their needs/wants are practical or not. Even if we use a decent sample size for our research there exists a possibility that the users we researched were atypical users and that their feedback does not translate to the needs/wants of all users too.

So how do we get the best from our users?

Tell Them What You Are Researching

There is a theory that a “blind interview” (one where the participant has no idea, prior to the interview commencing, of what the interview will be about) can generate really useful data because it doesn’t allow the user to introduce their current biases to the interview. In reality, this tends not to be the case.

Preparing your interviewees and enabling them to understand what you need from them; helps them focus on the task in hand. It reduces the number of people who come to interviews to vent about issues and increases the number of participants who are informed and offer viable feedback.

Get Feedback and Not Requests

There’s a reason we conduct research before designing new products. If all we needed was a list of requests to determine new functionality; we could probably just raid the helpdesk’s database. Customer services are often inundated with requests for “could you do this… or that..?”

In reality these requests can be a great starting point for idea generation but before we run without ideas; we need to test them. It’s the feedback that matters on these ideas. You do not have an unlimited budget for new features. You need to ensure that the features you do implement enhance rather than impede most users’ experiences. You can only do that by soliciting feedback.

You should also be testing ideas generated by the business or other project stakeholders alongside the customer’s wish list.

Look for Facts and Distinguish Opinion

Is something hard to use or do people just say it’s hard to use? For example; I might hate the login function on Facebook and argue that it could be simplified. But there are a billion people logging into Facebook daily; if the process really was hard to use – wouldn’t there be less people logging in?

Opinion is useful. Facts are useful too. Learning to separate the two lets your users inform your process rather than derailing it.

Stay Neutral

One problematic area of user research is our own input into it. If we’re looking to find a specific answer that backs up our own theories; we tend to load questions and act particularly enthusiastic when someone gives the answers we want. This doesn’t lead to informative responses but rather the ones we wanted. You have to stay neutral and let you subjects give honest rather than directed feedback.

Header Image: Author/Copyright holder: Christine Saetre. Copyright terms and licence: CC BY-NC-ND 2.0