Super interesting. This is equally true that we see so many products that are a poor experience although they have huge research teams. The question is not the research itself—the question is about the *right application of research*—as you often mention—the findings, insights, synthesis, and making sense and meaning of research so that the product teams can apply those findings.
There’s been this bashing of research. Folks say that Research doesn’t yield ROI and that the recent downsizing of research is justified. This is because Research has mostly been reactive. The moment we have the first concept, we have some hypothesis. So the design process should be about clarifying that research question. You don’t have to test everything but you have to know how you define success.
Also, I guess the *research* here means the actual research that we carry formally, and building the common and peripheral awareness in the teams for the whys and conversations around why research is important, how to apply those learnings, and how it helps all of us collectively.
Pretty much yes. My POV is that all activities before launch is get to a testable viability hypothesis. Any time you release something, you will get signals at scale. Every design exploration has an inherent hypothesis about behavior. The first step is to see the behavioral triggers in your design and trade offs between them. I will post another article about measuring and qual to quant. When you practice design this way, there's reasoning about causation --> outcome and trade offs. The engineering review before implementation meeting is always to really vet what we're trying to measure/learn quantitatively.
And, just as we need research to make sure that our own judgment, hypothesis, assumptions, and experience do not go wrong, likewise, we need to use our judgment and experience to make sure that research does not misguide us—so we need both—research and research-independent-judgment to guide us throughout.
My position is that the act of design itself is grounded in formulating research questions. It’s critically seeing the hypothesis to outcomes in the concept. My boss says I’m a researcher who knows how to design. When you’ve had to design/run research studies and experiments, you have this mindset.
The way I read the Product Quality stage, it sounded terminal. I spend the bulk of my time in that activity, but I advocate for it to feed back into identifying new/more promising solutions or better/novel opportunities or framing. In other words, treat it like the A in OODA loops or the Build in Build-Measure-Learn (which Pawel Samsonov pointed out the flaws absent design, but is a familiar reference to many).
Completely agree. These can be cyclical and porous. It's not terminal. But for the purpose of categorizing design maturity, I intentionally just paint that broad stroke or the article will go on forever. I can dive in to this more later.
This essay is packed with so many subjects that could each have their own essay. Love it, thanks for sharing.
Found myself nodding along as someone who started in a testing/research role, then switched to PdM and is now a designer.
I find myself straddling all these worlds, and advocating for people in these roles to learn more from each other. If you're planning to write about how you do that, I'd love to read.
For context, I was referring to this bit from your essay:
"I coached my designers to think like Product Managers and my Product Managers to think like Designers. My focus was on encouraging the team to adopt a research mindset."
Super interesting. This is equally true that we see so many products that are a poor experience although they have huge research teams. The question is not the research itself—the question is about the *right application of research*—as you often mention—the findings, insights, synthesis, and making sense and meaning of research so that the product teams can apply those findings.
So, design is the application of research.
PS: I remember this LinkedIn discussion a few moons ago: https://www.linkedin.com/posts/jmspool_ux-uxstrategy-uxresearch-activity-7176321604681904128-O4dJ/
There’s been this bashing of research. Folks say that Research doesn’t yield ROI and that the recent downsizing of research is justified. This is because Research has mostly been reactive. The moment we have the first concept, we have some hypothesis. So the design process should be about clarifying that research question. You don’t have to test everything but you have to know how you define success.
Also, I guess the *research* here means the actual research that we carry formally, and building the common and peripheral awareness in the teams for the whys and conversations around why research is important, how to apply those learnings, and how it helps all of us collectively.
Pretty much yes. My POV is that all activities before launch is get to a testable viability hypothesis. Any time you release something, you will get signals at scale. Every design exploration has an inherent hypothesis about behavior. The first step is to see the behavioral triggers in your design and trade offs between them. I will post another article about measuring and qual to quant. When you practice design this way, there's reasoning about causation --> outcome and trade offs. The engineering review before implementation meeting is always to really vet what we're trying to measure/learn quantitatively.
And, just as we need research to make sure that our own judgment, hypothesis, assumptions, and experience do not go wrong, likewise, we need to use our judgment and experience to make sure that research does not misguide us—so we need both—research and research-independent-judgment to guide us throughout.
My position is that the act of design itself is grounded in formulating research questions. It’s critically seeing the hypothesis to outcomes in the concept. My boss says I’m a researcher who knows how to design. When you’ve had to design/run research studies and experiments, you have this mindset.
The way I read the Product Quality stage, it sounded terminal. I spend the bulk of my time in that activity, but I advocate for it to feed back into identifying new/more promising solutions or better/novel opportunities or framing. In other words, treat it like the A in OODA loops or the Build in Build-Measure-Learn (which Pawel Samsonov pointed out the flaws absent design, but is a familiar reference to many).
Completely agree. These can be cyclical and porous. It's not terminal. But for the purpose of categorizing design maturity, I intentionally just paint that broad stroke or the article will go on forever. I can dive in to this more later.
This essay is packed with so many subjects that could each have their own essay. Love it, thanks for sharing.
Found myself nodding along as someone who started in a testing/research role, then switched to PdM and is now a designer.
I find myself straddling all these worlds, and advocating for people in these roles to learn more from each other. If you're planning to write about how you do that, I'd love to read.
Can you tell me more? Are you asking how to bring folks together to articulate meaningful positions and create testable artifacts?
Yes, precisely that.
For context, I was referring to this bit from your essay:
"I coached my designers to think like Product Managers and my Product Managers to think like Designers. My focus was on encouraging the team to adopt a research mindset."
Got it. Thanks.
This is exactly what’s missing in my org. Great read!