Spoiler alert: User research is like a movie

Ale Machado
Ale Machado
Blog Main Image

I have two types of friends, the ones who don’t care for or even enjoy spoilers, and the ones (like me) who hate them.

I usually have this conversation with them as I would often go in ‘blind’ to the movies, not even watching the trailers that come ahead of them, and going as far as covering my eyes before The Batman plays. I can’t help but be as excited about Doctor Strange in the Multiverse of Madness, so I would hate it if a trailer ruined a big reveal. Thankfully, as the movie just premiered, those fears have now dissipated until Thor: Love and Thunder approaches.

In many regards, anticipation could be one heck of a motivator. However, we must be mindful that it has its fair share of danger.

The problem with spoilers.

Just like when Scarlet Witch and Doctor Strange were about to— Eh, you didn’t think I was going to give away Multiverse of Madness, did you?

That single sentence may have had you sweating for a brief moment, should you have any level of investment into the Marvel Cinematic Universe. And, even if you didn’t, it surely made you think something’s not right. That “aw, snap!” kind of feeling.

What if you end up regretting knowing something about that movie? Or worse, what if it ends up not making sense in the way you thought it would? This also happens when trailers give away too much detail, which is increasingly becoming the norm to move up box office numbers and pre-orders (especially in the case of videogames).

Hype, spoilers, and spoiler-generated anticipation might be effective to attract people, but could also actually be a double-edged sword. This valuable lesson doesn’t just apply to entertainment, it applies to product research and development, too.

Grab a cup of coffee and join me for a brief look into why anticipation can be our ally, or our greatest enemy, depending on how you handle it.

Setting expectations (accurately) is key.

> Driven by hunger, a fox tried to reach some grapes hanging high on the vine but was unable to, although it leaped with all its strength. As it went away, the fox remarked “Oh, you aren’t even ripe yet! I don’t need any sour grapes.”

Driven by hunger, a fox tried to reach some grapes hanging high on the vine but was unable to, although it leaped with all its strength. As it went away, the fox remarked “Oh, you aren’t even ripe yet! I don’t need any sour grapes.”

When the fox wasn’t able to reach the grapes, it ended up hating them out of spite, out of those conflicting thoughts of desire and frustration: a so-called cognitive dissonance.

In essence, cognitive dissonance is the psychological phenomenon in which differing thoughts or emotions collide, resulting in mixed or negative emotions and reactions as means to relieve the stress. We may, erroneously, think that hype is only a matter of marketing. Truth is, bells and whistles can come from anywhere, and users will remember this.

If we were to learn something from that, is that we must be cautious of how much we promise or which features we reveal before the product ships. In the end, we are in control of how ripe we make our grapes look, and that gives us a tremendous advantage.

 ”Not everyone needs to know everything, Newt.”

”Not everyone needs to know everything, Newt.”

Building... a bridge?

As designers, we may feel the urge to ask users what they think of adding certain features to the experience and, if we are not timely, we may taint their entire thought process of how a product works and, with that, their expectations. Undeniably, even stakeholders may feel this eagerness and ‘spoil’ a long-term roadmap if they were to participate in co-creation sessions, focus groups, or interviews. Remember, people in business do not have the same sensibilities as people in design, and that’s the whole point.

Laguna Garzón Bridge

Laguna Garzón Bridge

As you may know, it’d be ideal to approach this carefully and in a rather abstract way. Instead of asking users directly if they would like a bridge to cross to the other side of the lake, we might ask about their ideal way of doing so. You’d be surprised to learn that, depending on the context, their least concern might be crossing. One such example is the rather known Laguna Garzón Bridge. If crossing was its foremost objective, would it be circular?

While having a diverse ensemble for our ideation process is, in my opinion, a must, it may be troublesome if some of these people know ‘a little bit too much’ about the project. So, naturally, we must have this awkward conversation with our clients, and properly prepare them if they are participating in our activities.

Remember, mental models are our guide. We must learn about them before setting expectations on our users, and we should be mindful of our own so that we don’t bias them.

The features the team likes the most might end up being the less relevant ones.

What if development costs set back a feature you teased and users end up being disappointed? Sure, you learned that said feature is important to them, but by the time you add it back in a future release it might already be too late, since people probably already moved on, most likely leaving a negative review in the App Store (remember the grapes?)

Like users, we also have our own expectations of how a product might turn out to be once it ships. This is where user research comes into play. Not to shove these ideas into the users’ minds, but to align ours to theirs.

So, how do we ensure we don’t taint the process with our own excitement?

Image of Dr. Strange with multiple hands

Our key plot devices.

Stakeholders and people in business are usually eager to learn how you work and to understand what’s the buzz with user research (and why it may be so expensive and require multiple designers to make, apparently, the same task). So, naturally, they might want to join your co-creation activities or interviews.

While nowhere near a recipe or a rule of thumb, these are some approaches that have helped me perform research with stakeholders, and not die trying.

Do your homework

It kind of takes guts to stand up to your client and ask for some space while you conduct your research. However, we have the greatest wild card: research and its methods are backed by facts and studies. There’s a lot of material that can help you defend your decisions as a designer or researcher for various scopes, budgets, and industries. Make sure to do your homework, call your stakeholders to do your pre-work, and take the chance (and the lead!) on how you are going to approach users. Be firm, but also be inclusive. Remember, it’s their time and resources and you need to instill trust and respect.

Assert your position as the facilitator/interviewer.

In discovery activities, time and focus are key, that’s why some of the more successful facilitators and interviewers are the ones who are capable of calling people to order and respectfully redirect the conversation to important discussions about the ideation process, which have to be evaluated as such on the fly, usually against what you need to discover. Again, as it’s important not to let users get carried away, it’s also important not to let stakeholders justify their product in any way, unless it’s valuable to the discussion like, say, in a prioritization activity.

Do not bias your users.

If we were to learn one thing about a skilled interviewer, like Kara Swisher, is how she treats heated topics. She always refers back, quotes, and mentions topics with little to no paraphrasing. She’s also clever enough to ask the interviewee to “talk a little bit more about” a topic. Learn to ask without any connotation of previous research, giving away details, or even your opinion. Keep your cool and remember that you are not the user™.

In a nutshell...

Honesty, only with a bit of secrecy

”If I tell you what happens, it won’t happen”

Like with spoilers, giving away too much detail on your discovery activities might harm the actual thought process of your users, as we mentioned.

In my experience, you can mitigate this in pre-work meetings as we have the chance to prepare our stakeholders, unlike with the user. If we have the chance to prepare the user, it’s always best to set up expectations as to what the discovery activities are going to entail and what we want to learn from them.

Never force the user into thinking what you or your stakeholders want them to think. Pick the most relevant information and let it be disclosed at suitable times in such a way that brings value to our discovery process. And remember...

“The secret of being a bore is to tell everything.” - Voltaire