Who is ‘the user’?
The long and short of it is that users = people. I imagine that the term ‘users’ came from a more scientific research context, but basically the users of a product are the people who might use this product. I try to use the term ‘people’ wherever possible, because I find ‘users’ sometimes seems isolating. ‘Users’ shouldn’t be so separate from you as researcher, since you’ve probably refined some skills of empathy enough by now that you can put yourself in the position of the user, and see things from their perspective.
Participants should be users, but users aren’t always participants
What’s the difference between participants and users? Well, participants are users in a research context. That is, they are the people you have selected that should be representative of your users, and should probably be potential or active users themselves.
Participants are called so because they participate in user research that helps you improve your product for users. If your participants are too far apart from the real users who are using your product, then your research is inefficient and could be more detrimental to improving the product than not doing the research at all. It’s important to select participants that might use, or already use your product to ensure that you’re testing on the right kind of people. Their comments are therefore probably more in line with those that your users will face, which means you can make improvements based off 6-8 representative participants that will largely improve things for most of your users.
It is important to continue to do user research throughout a product’s life-cycle, so that you don’t end up thinking that your users are like a few participants you tested at the start. You must remember that your participants have taken part in feedback in a research context , which has factors that may influence findings compared to users in ‘real-life’. It’s important to use different participants and research techniques, to get a broad and continuously developing idea of your users and their needs.
Participants’ personalities and preferences can also affect the feedback they give, so don’t think too hard about what they’re saying, but what they’re doing. If you’re designing an app for an Opticians, you shouldn’t change the colour of a button because participant 3 hates red. However, participant 4 can’t see the text in the button because they have a colour vision deficiency and the contrast isn’t there; they are representative of the type of people who might be using the app, so it’s important to consider their real issues over comments that offer preference.
Selecting your users
So, this is kind of a trick one, because while you can design for certain types of users, there will be ones that crop up naturally, and you can’t discredit these just because you didn’t intend for that audience when designing your website.
You should, however, have an idea of your users before you even think about designing a product. Who is this for, and do they really need it? What problem is it going to solve for them? This is really important to consider in your first steps to selecting to users – your development of personas. I’ll speak about this more in a separate post, but personas are basically a fancy word for profiles. Imagine you’re making a Facebook profile for the person using your new fitness app. What is their age/gender/social status? Where do they work? What do they like to do in their free time? What is important to them? If you really think about your users, you will quickly build a picture of who it is you should have in mind to research and base your improvements on.
End users VS end goals
This is something that can often cause trouble for people unfamiliar with UX. Sometimes, thinking continuously about ‘users’, we can misjudge who is our end-user. User experience works on the assumption that there is always an end-user within a project/product, and (this might seem obvious), the end user has to be a functioning human being. Why did I point this out? I once had a conversation with someone who explained that ‘we can’t always please the user, sometimes there just isn’t one’. Well, actually, there is.
For example, take a renovation project for a Doctor’s surgery reception area. Initially, you might think the end goal is to have chairs, a front desk and easy access doors. Do we need to involve users in something like this? The end goal is one that we are familiar with, know is a necessity, and if we start to ask people what colour they want the walls we might end up with llama printed wallpaper leading us to get a bloodtest. Silly, right? Well, not really.
While llama wallpaper is (unfortunately) not on the agenda of UX consultants, you have to try and separate the end goals of a project to the idea that there is an end user on the back of this. The goal for a renovation project isn’t really to update the chairs and tables, but to have a comfortable and efficient place for patients and staff. Your users are the staff working in reception, and the patients waiting to be seen. Do you want 3 chairs next to each other to have some nice plants, or is it better to have 12 chairs spaced out and ditch the plants? Are plants important to calm people while they wait? Does a desk for reception staff need a glass panel to protect staff from potentially infected patients? As you can see, a simple project that seems to have end goals that is probably separate to users would actually benefit from considering users throughout the process.
If you end up with an object as your end-user, take it a step further. Who uses the object? This doesn’t always have to be a customer, but it does have to be a person!
Speaking for our users
To end on something you should never do, no matter how experienced you are in UX. You cannot and should not speak for your users – they should speak for themselves. You can be an advocate for the user, but don’t try and kid yourself that your experience enables you to speak on their behalf. The only way to be a true advocate and speak for the users is to continuously ask them for their feedback, iterate based on your findings, and ask them all over again. Eat, sleep, research, improve, repeat!
Knowing your Users and Developing Personas: https://uxplanet.org/what-really-know-you-user-means-bfaba378c092
Choosing Scope of Personas: https://www.nngroup.com/articles/persona-scope/
Useful article about swapping out detailed personas for persona patterns: https://uxmovement.com/products/persona-patterns-make-personas-people-can-reference/