Researching with utensils and cooking with methods

Have you been getting the most out of time with your user? When was the last time you tried a different approach to get the maximum of users’ perceptions?

This post has the intention to clarify why we should think first about our goals and current scenarios before choosing a method. Let’s go!

:: Context and goals: how they influence our plans ::

Pretend you have some gastronomic tasks to be done:

a. Someone has asked you to pell a vegetable

b. Now you need to peel a lot of vegetables

c. Cut 2 onions

d. Now cry and cut 1 kilo of onions

Keep these examples in your mind, and now imagine you need to choose some utensils to execute. Which one would you use in each case, and why? If you got the logic, you likely noticed the use of tools depends on some factors like quantity, time, or other specific characteristics.

Let’s take the example “d”: it’s reasonable to cut all onions with a knife if you have time, but it would be a different situation if you had to cut 1 kilo of onions into plenty of little pieces in 10 minutes. Probably in the last case you could use a vegetable processor, right?

:: Ok, but what about methods? ::

Before we begin to talk about methods I remind you that research is a way to learn something.

Like you have so many tools to cook, the same way we have many methods to use in our study.

We have several ways to absorb subjects, for example, hands-on, listening, writing, and so on; research methods work similarly because they are our “tools” to comprehend users, journeys, and pain points, beyond to get opportunities and insights. Adding to this, time with users is pretty valuable, don’t waste it with no-productive methods; believe me, you will have great results if you use no-traditional resources or more than one method.

:: Keep with me: we are coming to the final (I promise) ::

I’ve seen so many times people using the same methods when, sometimes, the situation demands another approach.

Pretend stakeholders want to “copy and paste” an old platform to a new platform, in other words, there are screens, and they want to “validate” them with users. Would the first option be usability tests?

Let’s put all these elements, and context on paper.

I) What we know until now in this fake case:

• Users are internal people, what would mean a facility to recruit, and talk to them
• There was no moment with these users before the screens conception
• The old platform was not thought for these users
• They want this to the next week (findings)

II) What we would be good to understand:

• If this feature is useable
• What problem we are solving with it
• Who are these users, and what is the use context of the platform

(It is always challenging when the process begins with screens, but no signal of what problem we are talking about, isn’t it?)

Notice that usability it’s not the unique question here, but to analyze if users see value in the feature — yes, we need to pay attention to this because a no-value feature/ product is a straight path to failure, even if this is useable -, and to comprehend contexts when they are using it. Maybe isn’t it worth applying another method like concept validation, a “heatmap” or a little interview, for example?

If there would be a soon moment with users before screen conception to understand their needs, likely a usability test fits better now.

What do you think about this? How have you been applying methods in your routine?