A practical tool for prioritising research questions – and ensuring that they don’t all end up in a usability test

As a UX researcher, you often have to answer questions like: ‘how much are participants willing to pay for our product?’ Or, ‘can you ask them to tell us more about what they want from us?’

But these questions don’t belong in a usability test. The stakeholder asking the questions is aware that further research is needed, but planning is tight and ‘as we’re inviting all these customers for a test anyway, why not ask them while they’re here?’

How can you help your colleague understand that these questions don’t belong in a usability test? Or better still, how can you avoid having this conversation at all?

Meena Kothandaraman & Zarla Ludin of twig+fish research practice created a tool to help you do just this: The NCredible Framework.

The NCredible Framework 3.0 by twig+fish research practice. Presenting a square with four quadrants. Left side below it shows: discovery, topics and descriptions. Left side above is shows: exploratory, realities and aspirations. Right side below it shows: definition, ideas and solutions. Right side above it shows: validation, answers and decisions.

Although the framework appeared very useful in my projects, it is sometimes difficult to distinguish between discovery and exploratory research. Let’s try to clarify the situation.

A square with four quadrants. The left side present the problem space, the right side the solution space. Left side below it shows: discover, what are the focus areas of interest? Left side above is shows: elaborate, how do people address topics of interest? Right side below it shows: define, what realities can we generate solutions for. Right side above it shows: validate, which ideas work? And which don't?
We use the term Elaborate instead of Exploratory. The term Exploratory is often used to describe Discovery research in other models, which can be confusing.

How to use NCredible

Create a large poster containing the four quadrants – discover, elaborate, define and validate – and hang this somewhere where everyone can see it. The next time a stakeholder asks you about a usability test, just point at the poster and ask: ‘What do you want to learn?’ Together you then translate their objective into research questions and assign these to the appropriate quadrant.

Let the stakeholders formulate the questions themselves as much as possible. This will:

  • Give them ownership of the question
  • Create an understanding that there are different types of studies for different questions
  • Create a need for finding an answer and understanding what they want to learn (the deeper meaning behind the question)

An example

Imagine your colleagues want to develop an app that will facilitate neighbours to borrow and lend tools or equipment that they only need occasionally: for example, a chainsaw.

The two left quadrants deal with a deep understanding of the user and their problems. The bottom left quadrant starts with discovery questions: how do neighbours interact with another? Do they borrow things from each other? Why? Why not? What do people experience as being the biggest frustrations?

In the left upper corner, you start with the elaboration questions: some people find it difficult to talk to neighbours, why? Others connect all the time. What’s the difference?

The two right quadrants are about the solution. The bottom right quadrant deals with the definition questions: if we want to create an online solution, what requirements do we need to take into account? Are neighbours already connecting online? When do they prefer to ring the doorbell instead?

The upper right corner contains the validation questions: does using our app make borrowing a chainsaw easier? What can we improve?

You can assign a method to the appropriate quadrant

While you’re filling in the framework with your stakeholder, you can explain that some research methods are more suitable for creating input for new ideas while others are ideally suited for validation purposes. Although you can assign most methods to multiple quadrants, the more generative methods, like observation, diary studies or in-depth interviews, generally belong in the left quadrants. And the more product-related methods, like co-creation, usability testing or A/B testing, belong in the right quadrants.

A square with four quadrants. The left side present the problem space, the right side the solution space. Left side below it shows: discover, obervation, interview, diary, desktop. Left side above is shows: elaborate, observation, interview, diary, desktop, questionnaire. Right side below it shows: define, concept test, co-creation, cardsort, treetest, competitor analysis. Right side above it shows: validate, usability test, questionnaire, A/B testing, analytics.
Each quadrant is linked to its own research methods

It’s tempting to combine various questions in a single study. As we’re inviting users for a test anyway, isn’t it efficient to ask them about their problems at the same time? But this only makes sense if the research method allows for it. If not, you have a solid argument for conducting a separate study.

This is where the quadrants can help you set priorities, with a roadmap as a result.

Once all the quadrants are filled with questions, it’s time for research. A usability test is ideal for validation research. But only if the discovery, elaboration and definition questions have already been answered. The NCredible Framework helps you and your team members clarify the questions that need to be answered first.

Karin den Bouwmeester (she/her)

Karin is the founder of UXinsight. With over 20 years of hands-on research experience, she’s determined to help the research community grow to a mature level. She loves to connect UX researchers from all over the world.

The full article was published on uxpamagazine

Read full article
3 min. read
4.3K reads

Subscribe to our newsletter!

Get latest articles and templates from UXinsight in our monthly updates. Stay on top of upcoming UX research conferences, events & trainings.

  • This field is for validation purposes and should be left unchanged.