Unintentional Metaphors
So I had this ah-ha moment yesterday while sitting on my couch with my fiancé. He was reading to me what I think was a ridiculous thread of Reddit Dad Jokes, and we just couldn’t stop laughing. I was trying to work on a lightning talk for our SEP Product Guild and he kept refocusing me to hilariousness. That punk. But they were funny, so I don’t blame him.
After many, many, many stupid jokes, he wanted to send his favorite joke on GroupMe to our family. He typed up the lead into the joke and waited for someone to respond asking for the punch line. Nada. No response.
So then my experience design trained brain kicks in and starts a line of questioning asking him what he expects to happen from the message he’s delivered thus far. He tells me that he’s waiting for someone to ask for the punchline. So, he’s made an assumption that just because he gave the lead into a joke that someone will ASK for the punchline.
After he thinks it through, he decides to send the punchline and suddenly we’re filled with all the LOLs, hahaha’s, etc. that he had been waiting for from our family.
Then I started thinking… well, isn’t this just an awesome metaphor to use in my lightning talk about asking for feedback? The message you frame when asking for feedback is indicative to the response you’ll get from your recipient. If you don’t give someone all the information they need to respond with empathy to the product, then you won’t receive the feedback you’re asking for.
It starts with framing the ask.
When we ask someone to review our work, it’s important to build empathy for the Critique’r. The biggest mistake we can make is expecting someone to have the same mental models we’ve formed overtime on our projects, and then not give the proper background to give a valuable critique.
In Adam Conner’s book on Discussing Design where he says that you must set the stage to get proper feedback. You have to tell the Critique’r whose eyes you need to be looking through.
To do this, we need to do the work upfront. You, as the Asker for a critique, need to set the stage with personas and scenarios to help the Critique’r understand user behavior, goals and expectations. You also need to share with your Critique’r the details of your design with expected behaviors, the expectations your users have about your product, and the contexts in which it will be used. Build the empathy.
Without these things you’ll get your Critique’r drawing from their own mental models of past experiences for the product and ultimately providing self-design feedback. UXers are always repeating like a broken record…. “YOU ARE NOT THE USER.” But ultimately that’s the feedback you’ll get if you don’t put the work in upfront and communicate your design to your Critique’r.
Asking for feedback that’s actually valuable.
So you as an awesome builder of empathy now have your Critique’r on the same page as you. Good job, congrats you! Now what?
Now we have to work together to discuss the goals of the product that’s being critiqued. Some good questions to start the conversation might be…
- Does this help Persona A reach their goal in Scenario A?
- How might Persona B feel about ____?
But we also need to ensure we’re following design principles. This might be the reason you’re asking for a critique in the first place. So some questions to start the conversation might be…
- Does this UI control work within the context of this screen?
- How will someone understand how to recover within this screen if they encounter an error?
Ask open-ended questions that will lead to a conversation between you and the Critique’r.
Giving the valuable feedback.
So as the person providing a critique, I’m talking to you now. This is where we ask questions about the product experience from the empathy built by the Asker. It’s your job to step into the shoes of the personas defined. But when you make that step, don’t forget to bring along your product and design knowledge of best practices!
Ask questions retaining to validation of user goals and needs. Ask design validation questions, product experience questions, IxD questions, etc. You’re a fresh set of eyes so you might see something that was missed. That the whole point of the critique, right?
The point is to have a conversation, not pick out everything you see wrong. Ask thoughtful questions that evoke conversation and collaboration.
The right conversation.
Ultimately, the feedback we all need comes from a group of people who are on the same page talking about how to make products better. The wrong conversation comes from assumptions and unarticulated needs that makes a critique a horrible, painful experience that you never want to do again.
Let’s follow these guidelines so we’re more efficient in our critiques to support validated learning loops to build better products. Lets encourage each other to take the time to craft the lead up to the joke, so when you deliver the punchline you receive the laugh you were expecting.
