Welcome to the UX Myth blog series, where I debunk common design misunderstandings you keep hearing about in product meetings (and attempting to fix them).
It’s Not For Every Project, Right?
Any product, be it an application, web platform, or grocery store, aims to be used by more than one person.
In finding the sweet spot between all users of the product, UX research is born. The process is made to synthesise valuable data into useful insight that can be used as a reference point for stakeholders. They can then make informed decisions based on those data, thus creating a good “User Experience”.
In other words, UX Research is one of the essential tools to keep you and your product from the echo chambers. It is perhaps the best measurement you could ever need in the product designs process.
The perception of people when hearing the word "User Research" or "Prototype Testing" is perhaps the same when we mentioned "User Experience". We're using an extensive term to discuss such a specific field of data synthesis.
There are so many research and testing methods for gaining insights from your users. Here are a few things we may be referring to when we say “research”:
Competitor’s analysis -> A study to understand and compare specific areas of products within the same industry/market.
Focus groups -> A session for a curated group of people performing an interview to gain insights into your target users.
Usability testing -> A closed group observation where subjects perform actions to reveal insights on a product’s usability and features.
Brainstorming -> A whiteboard-reliant meeting where participants visualise ideas into post-its™ and arrange them in a way that could kickstart the discussion or find solutions to problems.
Unfortunately, not all designers can optimise or 'choose' the appropriate research and testing method to fit the project's timeline -- which make sense, considering time management isn't most UX designers' strong suit.
This often results in those noticeable and excessive results on some data. Most brainstorming sessions ended up with insights too shallow to act upon, or grow out of proportion into even more questions.
Spending 45 minutes brainstorming on a Forgot Password flow is not a good use of anyone's time.
Said perception notoriously affects the world of UX research; it now has a generally negative image containing people presenting tons of interview transcripts, detailed heat maps, an Excel spreadsheet comparing each competitor's feature set, a massive pile of post-its on A2 papers, and so on.
What to Do?
Assess the following parameter the next time your design project comes up:
Should've, Could've, Would've (aka a MoSCoW Method)
When a project manager performs an agile grooming ceremony consisting of filtering requirements and discussing work scope, priority is the first thing that should be agreed upon after the initial gathering of requirements.
Why? Because it shows everyone how much is needed to be done and sets up the expectation of how urgent said task is.
So when you're about to start working on those design tasks. Ask the following questions:
Are there any data from other stakeholders that we could start with, E.g. marketing departments, PO, decision-maker, etc.?
If data is insufficient (or not available), what could be the fastest research/testing methods to get insights?
How might we acquire that data with our current resources, e.g. time, confidentiality, effort vs value, etc.?
You'll be amazed at how much time you save by not fiddling around with redundant brainstorming workshops and guerrilla interviewing people around your office.
What If I Still Can't Afford Any Research?
Of course, those mentioned above are the tried-and-true ways of UX research. Most of us would use that to gain insights on solving problems and ideate together as a team. However, we are overlooking the simple fact that it doesn't have to be that comprehensive.
Take our typical design process, for example. In providing designs and User journey, we subconsciously created UX research in our minds. Where to put a CTA?, How to phrase the error message? Should we show popups or redirect?: These conventions were embedded into our design pattern and form a reliable source of information.
Remember that you can also be subject to your own design’s usability testing -- providing you can remain in character and empathise with the personas you created as a target audience of the product. Here is an example of bite-size usability testing should you need to do it yourself.
