Executing UX Research at a Startup. Part Two.
This is concluding part of the series.
If you came on this page directly, I humbly recommend going through Part One of it first —
And one more pre-read —
A quick recap, in Part One I talked (or rather wrote) about what kind and how to do UX Research when all you have is an idea for a product.
In this part, I will talk about what kind and how to do UX Research when a product exists — it can be in form of MVP or a product that is shipped (may or may not be getting traction and/or making money) and how everyone can benefit from having a UX Researcher in the team.
To reiterate what I concluded in Part One —
As a researcher, your job is to drive clarity, to increase the confidence level of product teams and help them take better and informed decisions of not only making the current better experience better but also be on the look-out of new opportunities.
While the above is the overarching outcome and interestingly one which is never-ending (ideally Research should be ongoing and a way of life for any product company to not only survive but also thrive), there are several steps/processes you can do to contribute and add value.
I will break it down into 2 sub-categories —
- When an MVP of a product exists
- When the product is shipped/live in the market
Reason for the above sub-categories is so that you can plan your Research accordingly as both will need a slightly different approach.
When an MVP exists
- Understand the domain of the product and use it as much as you can.
Many researchers make the mistake of directly speaking to potential users without first understanding the product themselves. This always leads to not knowing what you are looking for in the first place. It’s not required to be an expert but a good knowledge is definitely useful.
This also helps during Analysis and Synthesis phase when you are better equipped to make inferences and recommendations.
2. Speak to the key decision-makers/stakeholders whose voice contributed and influenced the MVP as it exists.
Ask them questions like —
What problem are they setting out to solve?
What assumptions/hypothesis did they start with?
What’s currently keeping them stuck?
What’s giving them confidence?
Who are the target users?
Whether any research was done which led to MVP? If yes how often.
What are their blind spots?
What are they feeling less confident about?
What is their “story” for the users?
Document all the above and you will find patterns within various people. Go through as many existing documents (if available) as you can to understand how decisions were made, what kind of research was done and what was the insights from this research.
Now go out and talk to your potential users. It can be ethnographic studies/interviews/prototypes (either coded or even on paper or simulation is fine). It is strongly recommended to involve as many members who influenced/worked on MVP as its easier to change their decisions (if required) when they are seeing how their MVP is faring among the users. It’s natural to ignore a problem if you don’t see it happening yourself.
Based on the data and insights you infer it can either validate the assumptions and/or open new use-cases which may not have been considered earlier on.
The purpose of any research is not to find data to discard existing solutions, its to first find out whether the right problem is being solved and then figuring out if it is being solved in the right way which will delight users.
Everyone who has worked or is working on the product gets naturally attached to the product as they have invested X amount of time and money to it. It’s the researchers who must bring in an unbiased and neutral view in the benefit of the user’s life and therefore to the organisation who is building the product.
One very important thing is to share the research findings with as many people/stakeholders as you can as it is not realistically possible for everyone to take part in research regularly. Which doesn’t mean they should not be aware of what is happening in the real world.
When the product is shipped/live in the market
This is both tricky and exciting at the same time.
When the product is shipped and is doing well, there will be a natural resistance to any Research as to why do Research when everything is going well.
When the product is not doing well or not as well as expected, at that time there is generally more accepting of Research to find out what is the cause and what can be done.
Regardless…you should be able to hit the ground running and get traction by doing the following —
- Support Centre
It’s not funny as to how many ignore or don’t even think of this fantastic resource to know how your product is faring in the market and among the users.
Support tickets (email, calls, chat) is a goldmine of insights right from your customer’s mouth (as a figure of speech).
Past 3–4 months, 3–4 times a week I start my day by opening the CRM at my workplace and going through the issues which customers have reported. It’s amazing and eye-opening the kind of issues they reach out for. Things you would never expect or things which you assumed and gets proven otherwise…happens on a regular basis.
Everyone should open their CRM daily without fail, especially Product Managers, Designers and Researchers.
Where else can you get served Insights literally on a platter?
One caveat is necessary when you are going through CRM, what Customer says, what they mean, how the Support person interprets and records, all these can be different. So don’t go blindly, always follow-up with more data points and dig deeper. Never take the first problem statement and solution at face value.
One very important benefit of going through CRM is, say for example when you meet your existing User who has reported an issue, you are more likely to build a rapport with them immediately and they will be happy that you are aware of their issues instead of going in blind. You may not have a solution, but at least you are aware and that itself is a huge thing.
Yet another benefit is that when you call your User (who has reached out to Support) for Research, he/she is more likely to welcome you as they already have an existing problem and chances of them agreeing increases manifold. Which doesn’t mean that your Research is limited to the topic he/she is struggling with, but it does get you a foot-in-the-door.
Support people are dealing with on-ground realities by the minute and they get calls from various diversities which your product caters to. I find it surprising or rather shocking why they are not reached out to more often.
2. Social Media channels — Twitter, Facebook, LinkedIn
Nowadays users, especially in B2C product segments are very vocal about sharing both their good and especially bad experiences of their product on various social media channels. And it's usually unfiltered and authentic.
Always keep a tab on what Users are saying about your product and also your competitor's product for that matter. If users are consistently praising something in your competitor’s product, perhaps you should go deeper and see why users are liking it and how can cater to the same use-case but even in a more delightful manner.
Social media channels can also be a powerful tool for recruiting users for your research.
3. App store reviews — App Store, Play Store
Similar lines as on Social Media Channels, app stores is another avenue which anyone from Product Team shouldn’t ignore. If your product is also an App and considering App ratings matter a lot for discovery, one has to be in touch with what the users are saying about it.
Even when I am trying new apps, it's natural for me to read through the reviews and ratings before downloading/paying for it.
Product people must optimize and stay updated with all touch-points which the user is likely to have with your product; it can be pre-sales, post-sales or even support. For user its singular experience even though multiple teams are working and accountable for each part of the experience.
I have intentionally not delved into more tactical stuff like what methods to use, what tools to use, how to analyse and synthesise data. Perhaps in another post will cover these and more.
Hope this helps and gives you some direction to start.
