Don’t Act Like a Question Monster
Have you ever worked on a team with someone who was acting like a Question Monster?
You might recognize the behavior.
An AI-generated image of a “Question Monster.” It thrives on unanswered questions.
What’s a Question Monster?
A Question Monster is a pattern of behavior typified by riddling colleagues with rapid-fire questions in a meeting or review. “But did you consider this?” “What about this other case?” “Do you have the current usage data on that?”
They’ve also been known to so thoroughly comment bomb your Google doc, covering every character in bright yellow highlights until the whole page is yellow with questions.
Does this sound familiar?
Does it even … gulp … sound like you?
If it does, don’t feel bad. Everyone can be a Question Monster at times. Heck, I often catch myself veering into Question Monster territory! (I feel compelled to point out here that this isn’t about the people, it’s about their behavior.)
Here’s the thing, though, about those who are acting like Question Monsters … their questions might be good, and may indeed encourage you to think about things that you hadn’t considered. And beneath their monstrous exterior, their question-mark-shaped heart is probably in the right place: just like you, they want to figure out all the things, so they can do their part in building a great product.
But how they go about this process of figuring out … with their incessant questioning … that’s less than effective.
Questions create an information deficit
I was recently inspired by a rule in improvisational comedy that discourages players to ask questions, especially early in the scene, as the base reality is being created. Why? Because instead of adding useful information to the scene (Who are the players to each other? Where are they? What is their relationship?) it creates a deficit of information and imposes additional work on one’s scene partner to fill that information deficit. Here’s an example:
Sally: “Wow, it’s sure a nice out here on this beach, bro.”
Jim: “Yea it is. Hey - what’s that out there in the water?”
Because Jim asked this question, it puts a burden on Sally to make something up. Maybe Jim already had something in mind (a boat? a shark? a spaceship?), and Sally’s idea will accord with it, or maybe her idea will differ. Or maybe Jim is just being lazy and decided to ask a question rather than add some useful information to the scene they’re building together.
Either way, this just delays the good part of the scene. Sally now has to suggest something, and Jim has to agree (hopefully, or disagree if he’s being a jerk). If Jim had come right out and said “Yea it is. Hey - is that tsunami coming our way?” then wouldn’t things have gotten interesting a lot quicker?
We’re all making this up together
In an improv scene, it’s a shared responsibility of all the players to first build the base reality (who, what and where) so they can get to the good stuff. In product development, it’s a shared responsibility of the whole team working on the early definition stages to hammer out these basics so we can all start designing and building the thing.
Any team working on any sufficiently complicated problem will face uncomfortable levels of ambiguity, especially at the early stages, when we’re trying to figure out what shape the product or feature will take. And everyone on that team needs to help move things from a state of ambiguity to a state of clarity. So do your part!
What’s UX’s role?
If you’re a UX person on that team, what exactly is your part in this? I’ve often found that UX is in something of a dichotomous predicament.
On the one hand, we can sometimes be downstream of those deciding the product requirements and with the business knowledge. (👆Let’s park the discussion about whether we should be here or further upstream). We’re often dependent on information from those upstream to help us design the right thing.
But at the same time, UX has an uncanny ability to make ideas tangible with mock-ups and flow charts and diagrams. Many of the questions we have end up getting bounced back to us. This process of visualizing and deep thinking, and the artifacts generated in the process, tends to foster discussions that lead to answers to the questions we initially asked.
So while it’s nice to be handed a completely thought-through, unambiguous set of requirements to design against, this is rarely the reality in which we live. In the absence of answers, we need to make assumptions. As long as those assumptions’ influence on the design is clearly documented (so that we can course correct of they turn out to be wrong), I’ve found that we can push ourselves pretty far upstream. This enables us to influence the product in a direction we choose, which hopefully is one that prioritizes the user experience, driven by user needs.
I’ve often thought about UX as a set of superpowers, and this ability to create clarity from ambiguity is an important but often overlooked tool in our belt.
Be an Ambiguity Annihilator
So, instead of thinking about your role in the product definition process as question asker - even if they’re really smart questions! - so that someone upstream can figure it out, strive to be an Ambiguity Annihilator.
Have you ever met one of them?
An AI-generated image of an “Ambiguity Annihilator.” Die question marks, die!
Ambiguity Annihilators seek out pockets of ambiguity and destroy them. With each unanswered question that gets resolved, the Annihilator can notch a victory, and the team is one step closer to figuring out what they’re building and how.
How can Ambiguity Annihilators do what they do? You might be surprised to know that a critical tool in their arsenal is … asking questions. But it’s how, why and what they do with the answers that distinguishes them from the Question Monsters.
Here are some techniques that Ambiguity Annihilators use to remove ambiguity from the early stages of projects. I try to keep these in mind when I’m working on a project with high levels of ambiguity.
Go after the big targets
It’s easy to ask a question - but remember - that information deficit takes some work to fill. Take a beat and think about how the answer to this question will help you do your thing. How important is it to answer now and how will the answer affect your work? If the answer is “not very” and “not much” then try to refocus your annihilation lasers on higher priority targets.
Document obsessively
Another technique to crush ambiguity is to take detailed notes of conversations and decisions. If these aren’t written down somewhere in a notes doc, or in a requirements doc, it’s all too easy to re-open the same question, burning time and resources, and likely frustrating the heck out of everyone (“… but didn’t we already decide we wouldn’t work on that this quarter?”)
Run an interrogation
In cases where you’re just mired in ambiguity, use “The Interrogation.” Write all the open questions down in a document and leave space for answers (it’s always good to have a list of running open questions!). Then get the key stakeholders into a room, throw that document up on the screen and go through it, question-by-question, writing down everyone’s answer and highlighting areas of disagreements. Don’t let them out of the room (or off the call), until all the questions have been answered. But don’t resort to CIA-style enhanced interrogation techniques.
Re-frame your question as an assumption
Like Jim in our example above, do you already have an idea what the answer should be? Do you really think it should be a tidal wave? If so, it’s way more efficient to “add that information to the scene” instead of just asking it as a question. It’ll save a round of feedback and get everyone closer to the goal. Here’s an example
Question Monster:
Will we include a search experience as part of the v1 or not?
Ambiguity Annihilator:
I really think we should include search as part of v1. It makes this feature 10x more usable.
By stating your question as a statement (and providing a rationale), you’ve just saved everyone a round of comments.
Just design both things
There will be times when despite your annihilation attempts, ambiguity persists. Maybe there’s a fork in the road, and choosing a path is hard because of all those darn unanswered questions. The worst thing you can do is to be blocked by it. Remember - it’s your job to help figure this out.
Instead, of being blocked at that fork, just design two things instead of one. Wireframes are cheap if you keep the level of fidelity low. And don’t forget to list out the pros and cons of each approach to help the team with the trade offs. You’ll help the team see how the answer to that question will affect the solution.
Summary
Everyone on the team involved in that foggy front phase of product development (including UX) has a shared responsibility to help bring the team from a place of ambiguity to a place of clarity. Questions are an important part of this, journey but only when wielded the right way. Don’t act like a Question Monster, riddling your colleagues with rapid-fire questions and burdening them alone with coming up with the answers. Instead, be an Ambiguity Annihilator by asking questions wisely, building a solid foundation with the answers you do get, and taking on the responsibility of answering some of those questions yourself (even if it involves making assumptions).
