You are not your user

The greatest benefit I find in doing user research is this: You have a unique opportunity to take a look into somebody else’s life and see what you can do to make it better.

The trick to this is empathy. Or in other words, putting yourself in someone else’s shoes to try to understand how they experience the world around them. To hear what they hear, see what they see, and feel what they feel. The rule of thumb in learning empathic design is to consider who your users are and what they want.

Stop and think for a minute: if you were your user, who are you actually? How old are you? What do you do for fun in your spare time? What do you do for work? Are you confident using the internet? What gets on your nerves and annoys you? What would make your life easier?

Once you know what your users want, you are ready to start building something! But don’t forget to bring them along on the journey with you.

“But why?", you may ask. "I already know what they want”.

Repeat after me:

‍You are not your user

Even if you think you are basically the same as your users, chances are you know a lot more about the backend goings on of your product /service than a user ever would. Time and time again, I have found when conducting user research that something that may be obvious to you may not be so obvious to a first-time user. I have worked with interaction designers who are almost certain that users will click the big blue call-to-action button they have put on a page, but then the user surprises everyone by totally missing it. In some cases, users even say that they would give up at this point and shut down the website. This is why we need user research: to constantly test our assumptions and improve until we get it right.

Consider that you have been tasked with creating an experience for somebody with a physical disability in a wheelchair. Designing an experience for them without their input makes little sense to me. Why not involve them in the design process to ensure we are designing something that meets their needs and that they will actually want to use? Otherwise, you may launch something that none of the intended users can actually use and it ends up being a flop.

On the flipside, I have witnessed many “aha!” moments when user feedback has helped steer project teams down a better path - for instance, tweaking the design to include more accessibility features, leading to a better, more successful outcome.

There are many more examples that illustrate why testing your prototype with users often uncovers insights that are critical to the success or failure of the project.

For instance, you may be wanting to launch a website for seniors that requires them to enter their birth certificate, driver's licence and passport details as part of the process to access the service. However, when you actually speak with seniors you may discover that many never got a copy of their birth certificate or they lost it, they gave up their driver's licence years ago as they are no longer confident driving, and their passport expired as they last went overseas 15 years ago. In this case, the user would not even be able to complete the online process you created specifically for them, which is clearly not ideal.

What can we learn from this?

If we are getting this essential feedback from users along the way, project teams can tell if they are hitting the mark or not, and can pivot to ensure they are heading in the right direction based on user needs. For instance, the project team may then brainstorm: What can we do to make it easier for the user to get through? Can we make the fields non-mandatory? Can we offer other options to choose from? Can we provide an assisted digital channel?

Obviously, there are many considerations that need to be taken into account, such as whether making these changes will compromise security. But the role of the User Researcher is to bring to light fundamental user issues along the way, and then work with the rest of the team to see where compromises can be made to provide a better user experience. This will also save time and money later on, by ensuring that whatever you deliver is something that is usable by its intended audience, thereby minimising any rework that may be required.

Understanding “you are not your user”, and trying instead to engage as much as possible with real users along the way, ultimately leads to more successful project delivery, proud project teams, and happy customers!

Nexxt has worked with numerous organisations to help with successful project delivery, for an initial discussion, contact us at info@nexxt.com.au or call 1300 031 931.