Go and meet your users
I'm currently working in a role (M&S via 101 Ways) in which I'm lucky enough to work with and design for users directly. That involves me designing something going in-store and now testing. The results and speed at which you can progress and iterate are staggering, which is why it's so important.
Conducting user research is an essential step in understanding the needs and behaviours of your target audience.
Over the years of working in and around product teams, it's always expected to find that people haven't ever interacted or tested with their end users. Whether you are a product manager, a designer - even an engineer - should at some point observe their users.
There are multiple clear benefits for doing this and many reasons why you think your product or business doesn't allow you to do so - they are some of the highest priority blockers to clear.
How do I go about it? What methods do I need?
I get asked this question a lot. For me, everything boils down to logic. Firstly, if you're in discovery, it's okay for research objectives to fall outside of your current OKRs. Discovery is just that: it's to help inform what you do next, quash or prove your hypothesis about what your human users want or have problems with.
What's missing from the image above is a line showing product maturity, which I'd run from bottom left to top right. If your product is mature and you have a healthy user base, you can learn a lot (providing you have good data infrastructure) from running quant testing methods.
Example: A friend of mine contacted me recently to ask my views on a company they are affiliated with. They'd received data to suggest that their product had a significant drop-off through a 6/7 stage process. The product essentially connects one user with another. The hypothesis was set that part of the UI was hard to navigate and searching for an individual was more complicated than it should be. So, how should they test that design?
My answer was to ask some questions to establish more about WHO their users are. The assumption is that the individuals this product connects are time-poor, and the benefit and main overall objective of the product are convenience. This significantly affects how I would want to test these new designs.
You wouldn't, for example, get a focus group of these individuals to discuss the design; that would result in low/poor value feedback as the assumption is that these individuals are strong, charismatic and opinionated.
My recommendation was to get the design into some form of clickable prototype, run 1-to-1 sessions with each individual and ask non-leading questions with a loose guide, they should be able to achieve the end goal you desire. An interview with an incentive is the rough prescription for that specific problem.
And therein lies the point. You have to apply the proper methods based on the logical perception of the situation you find yourself in, there are many methods available to you, but the most challenging thing is evaluating what's the most value you'll get from factors like:
- Product maturity - is it an established product or a new feature
- Fidelity of the thing you want to show them
- Space, cost and time of the users you want to ask
- Distance, cost and time to the business
- Product stage, is it discovery, or is it an MVP?
Examples of research that I've done recently
Of course, as I've mentioned, I have been working at M&S recently, which gives me the benefit of gaining access to users very quickly.
I've been working on a prototype in Figma which is designed to be an improvement of an experience for Colleagues in-store who use handheld devices for daily tasks:
The easiest thing I could do was take this on my phone, walk into the store, and test it with people. There have been other examples of research where I've needed to record their usage or feedback, so it's essential to ask for consent. But in this case, I needed input quickly; I didn't have weeks to prove that this concept was right or wrong, I just needed an indication that we were headed in the right direction. What we learned from this specifically was that it compounded habits from Colleagues. All of them tried to click and use individual apps that weren't part of my prototype. It proved that Colleagues only needed/used 4 or 5 apps on the home screen which we'd designed. So, getting that right for each Colleague profile would be valuable.
If you haven't got an established route into your users physically - or have the infrastructure ready to measure behaviour from data, these are the first and most important obstacles that you need to overcome.