Hey Reader,

Ever feel like you’re designing in the dark — with product decisions made on hunches instead of user insights? When user research is missing, you're left balancing intuition, stakeholder opinions, and guesswork — all while trying to build something that actually works.

In today's email:

• How to navigate assumption-driven product culture
• Why trusting “the process” might hold you back
• How Canva builds AI design tools — from fast prototyping to product decisions.

Design gems of the week

• ​Don’t Trust the Design Process – by Jenny Wen A sharp, honest look at how we became obsessed with “the process” — and lost sight of what really matters: designing great things that work and feel right. Jenny argues for bending the rules, skipping steps, and trusting intuition over templates. If you’ve ever felt trapped in design theater, this one will hit home.
  ​
• ​The Future of Branding: A Special Evening With Chris Do Join branding expert Chris Do for a high-energy night of strategy, stand-up, and real talk — all in a nightclub. In a world where AI has made content faster, cheaper, and everywhere, clarity of identity is your edge. Expect bold takes, live interaction, and sharp insights on personal branding in a noisy, automated world.
  ​
• ​Inside Canva’s AI Playbook – Go behind the scenes of the world’s most-used design tool. Cameron Adams shares how Canva approaches AI (hint: prototypes > PRDs), why coaching beats managing, and how a rubber ducky became part of their culture. Packed with insights for anyone building design tools in 2025.
  ​
• ​Level Up Your PM & AI Skills with Uxcel This July, Uxcel launches new Product Management and AI skill tracks to help product and design teams level up fast. Join the waitlist to get a 62.5% discount, plus enter their massive giveaway with over $17,000 in prizes, including a MacBook Pro, 50 Uxcel Pro memberships, and a secret offer for everyone who joins. Don’t miss your chance to grow your skills and win big this summer.

​

A MESSAGE FROM FRAMER Just publish it with Framer. Beautiful sites without code — easily. Join thousands of designers and teams using Framer to turn ideas into high-performing websites, fast. The internet is your canvas. ​Get 25% off for 3 months with code FEMKE​

Navigating assumption-driven product development

This week we're taking on this designer's question about how to navigate a company culture where PM's aren't open to validating assumptions.

The scenario you've described is painfully familiar to many product designers: you're staffed to a project but your designer instincts immediately question whether this is actually the right problem to solve.

This disconnect between research-informed design and assumption-driven development is one of the most common—and frustrating—challenges in product work.

​

The assumption trap

Before diving into solutions, it's worth understanding why this happens so frequently. The issue isn't that managers are incompetent or malicious. In fact, there are several psychological and organizational factors at play:

The curse of knowledge: When you're deeply embedded in your product, you lose the ability to see it through fresh eyes. What feels obvious to someone who lives in the product daily might be completely confusing to a new user.

Confirmation bias: Once someone forms an opinion about what users need, they tend to interpret every piece of information as confirmation of that belief. That one customer complaint from six months ago becomes "widespread user frustration."

The telephone game effect: User insights get diluted and distorted as they pass through multiple conversations. A specific issue from one user segment becomes "all users want this feature."

Time pressure: Research takes time, and when leadership is under pressure to ship, assumptions feel faster than validation.

​

Building your research advocacy toolkit

Start small and strategic

Rather than fighting for a complete research investment, identify one high-impact area where you can demonstrate the value of user input. Pick a project where:

• The stakes are meaningful but not company-critical
• You have reason to believe assumptions might be wrong
• The timeline allows for at least lightweight research

This becomes your proof of concept for research-informed design.

Reframe assumptions as hypotheses

Instead of telling stakeholders they're "making assumptions" (which can feel accusatory), try reframing their ideas as hypotheses to test:

• "That's an interesting theory about user behavior. How might we validate that?"
• "It sounds like you have a strong hypothesis about this pain point. What would we expect to see if that's true?"
• "Let's treat this as our starting hypothesis and see what users tell us."

This approach acknowledges their expertise while creating space for validation.

Use the "What If We're Wrong?" framework

When proposing research, focus on risk mitigation rather than proving stakeholders wrong:

• "What if we build this and it doesn't solve the core problem?"
• "What's the cost of being wrong about user priorities here?"
• "How confident are we that this is the highest-impact change we could make?"

This shifts the conversation from "should we do research?" to "can we afford not to?"

Practical research integration strategies

The 5-Minute user check

For quick validation, establish a practice of spending just 5 minutes with users before starting any design work:

• Send a quick survey to existing users
• Review recent support tickets
• Check analytics for related user behavior
• Have a brief conversation with customer-facing team members

This isn't comprehensive research, but it often surfaces immediate red flags.

The documentation play

Start documenting the assumptions behind every design decision. Create a simple template:

• The request: What we've been asked to build
• The assumption: What we believe about user needs
• The evidence: What we know for certain
• The unknowns: What we're assuming without validation

This makes implicit assumptions explicit and often reveals gaps in understanding.

Partner with customer-facing teams

Sales, customer success, and support teams talk to users daily. They're often goldmines of user insights that never make it to the design team. Build relationships with these teams and establish regular check-ins to gather user feedback.

​
When research isn't possible: Designing with constraints

Sometimes, despite your best efforts, you'll need to work without comprehensive research. In these cases:

Design for learning

Build learning opportunities into your designs:

• Include simple feedback mechanisms
• Use feature flags to test variations
• Design analytics to track user behavior
• Plan for iteration based on usage data

Advocate through design

Use your design work to highlight the risks of assumption-driven development:

• Create prototypes that illustrate different user scenarios
• Include user journey maps that show potential pain points
• Present multiple design directions based on different user needs

Build allies gradually

Look for stakeholders who are naturally curious about users. These become your research advocates who can help shift the culture over time.

The long game: shifting organizational culture

Changing how an organization thinks about user research is a marathon, not a sprint. Focus on:

• Celebrating wins: When research leads to better outcomes, make sure everyone knows
• Building empathy: Invite stakeholders to observe user interviews when possible
• Creating rituals: Establish regular touch points with users, even if informal
• Measuring impact: Track how research-informed decisions perform compared to assumption-based ones

Moving forward

The tension between research and assumptions will always exist in product development. Your role isn't to eliminate all assumptions, but to help your team make better-informed decisions about which assumptions are worth testing.

Start small, build credibility, and remember that every conversation about user needs is a step toward a more user-centered culture. The fact that you're questioning these assumptions already puts you ahead of many designers who simply execute without thinking critically about the problem.

The path forward isn't about winning arguments—it's about building a practice of curiosity about users that becomes as natural as opening your design tool.
​

Have a topic you'd like me to write about? Reply to this email and let me know! I read every reply.