Beyond UX Design
- Épisodes
- 218
- Parution
- hebdomadaire
- Dernier épisode
- 6 Nov 2026
À propos du podcast
Beyond UX Design’s mission is to give you the tools you need to be a truly effective UX designer by diving into the soft skills they won’t be teaching you in school or a boot camp. These soft skills are critical for your success as a UX professional.
Épisodes 218
Where's this week's episode?
Quick update: Beyond UX Design is moving to early access. New episodes go to paid members first, then come out free for everyone a week later. The next public episode lands Thursday, November 12. For $5 a month …
Notes de l’épisode
Quick update: Beyond UX Design is moving to early access. New episodes go to paid members first, then come out free for everyone a week later. The next public episode lands Thursday, November 12. For $5 a month on Spotify or Patreon, members get audio and video early, plus the full video archive.
Wondering where this week's episode went?
If you're looking for a new episode today, you didn't miss it. Starting now, new episodes of Beyond UX Design go to paid members first. A week later, they come out for everyone, for free, right here in this feed. The next public episode lands Thursday, November 12.
The show is still free. The only thing changing is when you can hear it. If you want to support the show and get something back, $5 a month gets you finished episodes a week early in audio and video, plus the full archive of video episodes. You can join on Spotify or Patreon, and you'll find both links at beyonduxdesign.com/support.
If you're already a patron, thank you. You'll get a members RSS feed for your podcast app, and if you have any trouble setting it up, give me a holler at [email protected]. Give this quick update a listen, and I'll see you next Thursday.
What you need to know
- The show is still free. Every episode still comes out for everyone, one week after members get it.
- The next public episode is Thursday, November 12. After that, public episodes keep coming out on Thursdays.
- Early access is $5 a month on Spotify or Patreon. You get audio and video a week early, plus the full video archive.
- Patrons get a members RSS feed. Email [email protected] if you need help setting it up.
What's Actually Still Mine? // What Survives E05
Cursor handed me a good idea and I killed it anyway. In episode five, I take inventory of what’s actually still mine: judgment, taste, time, and the space to ask if it’s good for people. Then I get to the part …
Notes de l’épisode
Cursor handed me a good idea and I killed it anyway. In episode five, I take inventory of what’s actually still mine: judgment, taste, time, and the space to ask if it’s good for people. Then I get to the part I didn’t want to say out loud.
If judgment is what’s left of the design job, how much of the work is actually still yours?
Last episode, I landed on a line that sounded pretty good: the identity was never in the pixel pushing, it was in the deciding. But that’s easy to say when you’re standing in the wreckage of everything else. So in this episode, I actually check. I start with a story about a mobile action bar, a clever idea from Cursor, and why I said no when it tried to bring that idea to desktop. It wasn’t a bad idea. It just needed to live somewhere else.
From there, I walk through what’s still on my list and test whether it holds up. That includes judgment, taste (with a less precious definition than the one you usually hear), and the hours I’ve gained now that work can run while I’m in meetings. I also take on Michelle’s question from LinkedIn, because my original answer was a bit of a dodge. If shipping keeps getting cheaper, who’s still willing to slow down and ask whether the thing is good for the people using it?
Then there’s the part that’s harder to say. The inventory holds up better for some designers than others, and it leads to a much colder question that sets up the back half of the season. So if you’ve been wondering what’s still yours, give this one a listen and then go take your own inventory.
Topics:
• 00:00 - The good idea I killed
• 01:00 - Welcome and this episode’s sponsor
• 02:25 - Season recap
• 03:00 - Cursor’s mobile action bar
• 03:35 - Why it didn’t work on desktop
• 04:20 - Moving the idea to the design system
• 05:35 - Taste and social capital
• 08:05 - Work that runs during meetings
• 08:55 - Where the recovered hours go
• 11:05 - Michelle’s question: outputs vs. outcomes
• 12:15 - The pressure to ship faster
• 14:10 - Keeping the space to ask
• 14:25 - The full inventory
• 15:05 - Why losing the tool felt like losing my identity
• 16:00 - The uncomfortable truth about production work
• 17:50 - Will the market keep paying for judgment?
• 18:30 - Wrap-up
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
DesignByte: Persona Non Grata
This is the story of a senior UX researcher who builds the perfect persona to win over a stubborn steering committee. He’s warm. He’s helpful. He remembers your kid’s name. And a few weeks later, he starts …
Notes de l’épisode
This is the story of a senior UX researcher who builds the perfect persona to win over a stubborn steering committee. He’s warm. He’s helpful. He remembers your kid’s name. And a few weeks later, he starts leaving feedback in Slack.
What happens when your persona starts getting more buy-in than you do?
It’s that time of year again. Today, we’re stepping away from our usual interviews to bring you our annual Halloween audio drama.
This is the story of Dana Cole. A senior UX researcher with fifteen years of airtight, beautifully sourced research that nobody reads. So when her VP of Product asks for a persona that will finally make the steering committee feel something, Dana gives them Doug Whitaker.
Doug is a sales ops director from Naperville. He has a golden retriever named Biscuit. He gets your coffee order right without being asked. He’s the nicest guy in the room.
And Dana made up almost every word of him.
👻
Whether you’ve run a hundred research studies or you’ve just inherited a wall of personas from whoever had your job before you, this one should feel a little too familiar. It’s a story about personas, persuasion, and what happens when the most convincing voice in the building was never real to begin with.
So turn the lights down, grab your headphones, and give it a listen... If you dare!
Special thanks to our cast of characters:
- Voice Actor Extraordinaire, Amie Breedlove: amiebreedlove.com
- Actress and UX Designer, Stephanie Terrero: stephanieterrero.com
- Co-founder inflight.co, Tommy Geoco: designertom.io
- All-around swell guy, Hang Xu: thegistof.me/design
- Sound engineer, Derek Seibert: pillowfortpodcast.com
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
Did I Lose My Identity? // What Survives E04
Somebody tells me the thing we shipped is amazing, and a voice in my head says I didn’t make it. In episode four, I take on Chris’s question: did I lose my identity as a designer? I dig into the craft I lost …
Notes de l’épisode
Somebody tells me the thing we shipped is amazing, and a voice in my head says I didn’t make it. In episode four, I take on Chris’s question: did I lose my identity as a designer? I dig into the craft I lost, the career unease it exposed, and where I’ve landed for now.
If AI builds what you describe and everybody calls it amazing, who actually designed it?
A while back, Chris sent me a DM that kicked off this entire season: did I lose my identity as a designer? I’ve been putting off a real answer for three episodes, and this one is where I finally stop dodging. I start with what I was most proud of, which for me was prototypes. I’m talking Axure-level, way-more-than-the-project-needed prototypes, and later, Figma files pushed so far past their limits that I’d burn days on them. That skill didn’t fade. The place it lived just doesn’t exist anymore. And with it goes the design file itself, the one artifact that held our uncompromised vision, which raises a question I don’t have a clean answer to yet: what does a portfolio even look like now?
The question also hit harder than I expected, and in this episode I get honest about why. Losing Figma pulled the covers off something that was already sore: years of low-grade career unease, two layoffs, a cross-country move, and a household where both incomes ride the same tech cycles. That’s how my buddy Kevin the plumber, a little New Orleans-style beignet window, and Peter Gibbons from Office Space all end up in this conversation.
Then I go back to that hollow compliment and put the bigger question on the table. Is a designer the hand that makes the thing, or the person who directs it? If the robot draws now and I direct, I might be sitting in the art director’s chair that designers spent whole careers complaining about. I’ll tell you where I’ve landed for now, and why it sets up a harder question for the rest of the season. If Chris’s question has been rattling around in your head too, give this one a listen.
Topics:
- 00:00 - When a compliment on your work feels hollow
- 03:00 - Why Axure prototypes felt like a superpower
- 04:15 - The skill didn’t fade, its home disappeared
- 05:15 - Why the design file felt more like ours
- 06:25 - What does a portfolio look like now?
- 07:15 - Layoffs and the mark they leave
- 08:50 - What Kevin the plumber has that designers don’t
- 10:05 - The beignet window fantasy
- 10:40 - Why Peter Gibbons had it figured out
- 12:55 - Same tool, different outcomes
- 13:15 - Is a designer the hand or the direction?
- 13:45 - Designers in the art director’s seat
- 15:05 - Did I lose my identity? My truest answer
- 16:10 - The market doesn’t care about identity
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
Illusion of Transparency: Why Your Design Rationale Isn’t as Obvious as You Think
If your disagreement feels obvious to you, why does everyone keep walking out of the meeting thinking you’re on board?A Stanford researcher once had people tap out familiar songs on a desk and predict how often …
Notes de l’épisode
If your disagreement feels obvious to you, why does everyone keep walking out of the meeting thinking you’re on board?
A Stanford researcher once had people tap out familiar songs on a desk and predict how often listeners would name the tune. Tappers guessed about half the time. Listeners got three out of 120. That gap has a name: the illusion of transparency. It’s our tendency to overestimate how much other people can see what’s going on inside us, like our nerves, our disagreement, our intentions, and our tone.
Thomas Gilovich, Kenneth Savitsky, and Victoria Husted Medvec put this bias on the map in 1998, building on earlier work by Dale Miller and Cathy McFarland. Across lying, hiding disgust, and reacting to someone breaking the rules, the result was the same. People believed their insides were showing, and they mostly weren’t. We confuse how strongly we feel something with how clearly we’re showing it.
On product teams, this one hides well because it feels like everyone else’s fault. I share a roadmap review where I was sure my crossed arms and pointed questions made my concerns obvious, and my PM walked away thinking I was totally fine with it.
This week, we look at how the same bias shows up in Slack tone, design critiques, performance feedback, stakeholder negotiations, and async work, and why the fix is almost insultingly simple: say the quiet part out loud. So if you’ve ever been blindsided by “but you didn’t say anything,” give this one a listen.
Topics:
• 00:00 - Tap out Happy Birthday on your desk
• 01:00 - What is the illusion of transparency?
• 03:00 - The roadmap review where nobody knew I disagreed
• 04:25 - Why we think our feelings are visible
• 04:55 - The research behind the bias
• 05:55 - Egocentric anchoring: why this happens
• 06:30 - The spotlight effect and the curse of knowledge
• 07:00 - Can knowing about the bias fix it?
• 07:45 - Why your Slack tone gets misread
• 08:10 - The thumbs up emoji problem
• 08:55 - Design critiques and "obvious" rationale
• 09:15 - Why your feedback isn't landing
• 9:40 - Stakeholder negotiations
• 10:00 - Remote and async work turns it up to 11
• 10:45 - The insultingly simple fix
• 11:05 - Assume you're harder to read than you feel
• 11:45 - Say the obvious thing out loud
• 12:15 - Make feedback impossible to misread
• 12:50 - Read their words, not their face
• 13:20 - Build check-backs into async work
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
Was It Worth It? // What Survives E03
When my team moved from Figma to Cursor, we gave things up on purpose. In this episode, I walk through the real ledger: lost visual history, the comment threads that held our why, a rejected pull request, and …
Notes de l’épisode
When my team moved from Figma to Cursor, we gave things up on purpose. In this episode, I walk through the real ledger: lost visual history, the comment threads that held our why, a rejected pull request, and what we gained by designing with the real product instead of a picture of it.
When your design team trades the canvas for code, what actually disappears, and is what you get back worth more than what you lost?
A few months ago, I designed a full-page drag and drop interaction, cut it for a technical constraint, and then went looking for it a month later when that constraint disappeared. It took me 15 minutes and an AI assistant to dig it out of an old pull request. In Figma, it would've taken under a minute. And if a year had gone by, or I'd left for Costa Rica to take up surfing, nobody would've known it existed. That little treasure hunt is where this episode starts.This is episode three of "What Survives: When AI Comes for Your Design Work," and it's all about the trade-offs. I get into what my team lost when we left a canvas design tool behind: the visual iteration history that came for free, the comment threads that quietly held the why behind our decisions, the blank canvas (which, as it turns out, may have been gone long before AI showed up), and a command line skill set I can feel getting weaker every day. I also take on a fair pushback from a listener named Elena, who argues teams rarely look back at old versions anyway.But it's not a horror story. I talk through the other side of the ledger too: turning six months of Figma work into working, production-ready pages in days, the rejected PR that made me wonder if we were just cosplaying as engineers, and how we found our lane with engineering afterward. If your team has made the switch, or is about to, give this one a listen and then tell me what you traded away.
Topics:
- 03:10 - The foundation nobody sees
- 04:10 - Not a picture of the design, the design itself
- 04:50 - Losing the visual history
- 06:15 - Recovering a decision, not browsing
- 07:40 - Where the why actually lived
- 09:05 - How we kept collaboration alive
- 09:45 - When tooling costs more than a human
- 10:20 - Was the blank canvas ever blank?
- 11:15 - Auto layout was already doing the work
- 12:15 - The skills I'm renting
- 14:10 - The other side of the ledger
- 14:45 - Months of Figma work rebuilt in days
- 15:35 - The PR that got rejected
- 16:30 - Finding our lane with engineering
- 17:25 - Saved time is contested territory
- 18:15 - Engineers weren't territorial
- 19:25 - Designer or UI engineer?
- 20:05 - Back to pen and paper
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
Belief Bias: Why Good Ideas Get Grilled and Bad Ones Sail Through
This week we dig into belief bias, the reason your team grills the research it doesn’t like and waves through the stuff it already agrees with. Same evidence, two completely different levels of scrutiny.If …
Notes de l’épisode
This week we dig into belief bias, the reason your team grills the research it doesn’t like and waves through the stuff it already agrees with. Same evidence, two completely different levels of scrutiny.
If you’ve ever won an argument at work, how sure are you that you made the better case and not just the more popular one?
Belief bias is what happens when we judge an argument by whether we agree with where it lands instead of whether the logic actually holds up. If the conclusion sounds right, weak reasoning gets a pass. If it sounds wrong, suddenly everyone turns into a fact-checker. It’s one of the oldest reasoning errors on record, first noted back in 1928, but the study that set the template came in 1983 when Evans, Barston, and Pollard separated two things that usually travel together: whether an argument is valid and whether its conclusion is believable. People accepted believable conclusions about nine times out of ten, no matter whether the logic held.
On a product team this shows up everywhere scrutiny is supposed to live. The design direction everyone already likes gets a thin rationale waved through, while the unexpected one gets picked apart. A sloppy study that confirms the roadmap is “directionally useful,” and a solid one that threatens it is suddenly “not statistically significant.” The same point lands when a senior person makes it and stalls when a junior person says the exact same thing. The fix isn’t to distrust your gut. It’s to grade the reasoning before you look at the conclusion, notice when the hard questions only come out for answers you don’t like, and slow things down when the stakes are real.
Give it a listen and catch yourself before belief bias makes the call for you.
Topics:
• 00:00 - Same idea, two meetings
• 03:45 - Two research studies, same afternoon
• 05:05 - What belief bias actually is (and where it came from)
• 06:00 - The 1983 study that proved it
• 07:00 - Why it happens: fast belief vs slow logic
• 08:10 - Belief bias is not confirmation bias
• 08:40 - Where it shows up on product teams
• 10:00 - Does group discussion fix it?
• 11:20 - 5 ways to catch belief bias
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
We Cut Figma. Here's Why. // What Survives E02
It’s a regular Thursday sync until my manager cuts our Figma license and hands the whole product team one month to go fully AI. In this one I walk through who made that call, the surprisingly solid case for it …
Notes de l’épisode
It’s a regular Thursday sync until my manager cuts our Figma license and hands the whole product team one month to go fully AI. In this one I walk through who made that call, the surprisingly solid case for it, and the very selfish panic running through my head while I said nothing.
When the tool you spent a decade mastering loses its market value in a single meeting, what exactly are you afraid of losing: your job, or your identity?
This is the episode about the day the call actually came down. I’m at my kitchen counter with a fresh coffee, hopping on a normal weekly UX sync, when my manager announces the entire product team is moving to a 100% AI workflow by the end of the month. And by the way, the Figma license is getting cut. No debate, no “what does everyone think.” The decision was made in a room I wasn’t in, then delivered to a room full of designers who had about a month to deal with it.
I do two things in this one. First, I try to be fair to the decision, because it deserves it. I get into the cost math leadership was staring at in early 2026, the pricing question Bob Baxley raised after I posted about the switch, and why ripping the band-aid off with a brutally short deadline was probably the right move and not the reckless one it felt like. Then I tell you the less flattering half: what was actually going through my head in that meeting. Spoiler, not one of those thoughts was about our users or the work. Every single one was about me, my title, and whether being “the person who knows Figma best” was ever a real skill to begin with.
I also get into the part nobody sat us down to talk about, which is that these tools blur the lines between design, engineering, and product in every direction at once, and introduce the “in the loop, on the loop, out of the loop” question that runs through the rest of the season. If your company hasn’t had this meeting yet, I’d gently suggest not assuming it isn’t coming. Give this one a listen, then let me know about your own version of the kitchen counter moment.
Topics:
• 0:00 The day they cut our Figma license
• 3:00 The cost play: why pay for two tools?
• 4:05 Not my call: where I sit in the org
• 4:50 Nobody said "adapt or quit" (the soft mandate)
• 5:30 The fair case, and Bob Baxley's pricing question
• 7:15 Ripping the Band-Aid: off the dock, into the boat
• 8:40 What was really in my head: "just UI engineers now?"
• 9:45 Kevin the plumber
• 10:50 Watching a decade of skill depreciate
• 11:50 How remote teams process shock
• 13:10 Does engineering even want us in the code?
• 14:00 Every role blurs at once
• 15:10 The walk
• 15:55 In the loop, on the loop, out of the loop
• 17:10 Next time: what we traded away
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
Not Invented Here: When “We’re Different” Is Just an Excuse to Ignore Outside Work
Ever notice an idea gets a cold reception the moment it comes from another team? That’s Not Invented Here. This week I dig into why our brains treat “not ours” as “not good,” what it cost teams I worked on at …
Notes de l’épisode
Ever notice an idea gets a cold reception the moment it comes from another team? That’s Not Invented Here. This week I dig into why our brains treat “not ours” as “not good,” what it cost teams I worked on at GE, and how to catch it early.
When your team says an outside idea “won’t work for us,” are you evaluating the idea, or just the team it came from?
Not Invented Here is the tendency to reject or undervalue ideas, tools, and research that come from outside your own team, while overvaluing the stuff you built yourselves. The catch is that it never announces itself. It feels like you have standards, or you know your users, when really the source of the idea is doing the evaluating for you in the background. The term goes back to a 1982 study by Ralph Katz and Thomas Allen at MIT, who tracked fifty R&D groups and found that the longer a team stayed together, the less it talked to the outside sources it most needed to hear from. Performance slid as a result. Later work from David Antons and Frank Piller reframed it as an attitude rather than a behavior, a standing negative feeling toward anything labeled “external,” whether that label comes from a different company, department, discipline, or just a different job title.
On product teams, this shows up everywhere once you start looking. Engineers’ UX suggestions get waved off because usability is “our lane.” Agency research gets its methodology questioned the second it contradicts the team’s assumptions, while a single hallway conversation gets treated as solid evidence. Ten squads rebuild nearly the same component ten different ways because the shared version doesn’t quite work for us, and then nobody trusts the design system anymore.
If your team has ever quietly shelved a good finding because it came from the wrong people, this one’s for you. Give it a listen.
Topics:
• 00:00 - The reflex that rejects an idea before you've even looked at it
• 03:00 - The GE story: a mandate to adopt one design system called Cirrus
• 04:00 - Every team pushes back with the same "that won't work for us"
• 05:00 - Defining not invented here and the 1982 Katz and Allen study
• 06:00 - Why long-tenured teams stop talking outward, and the shift from behavior to attitude
• 07:00 - Why your brain does it: ownership, effort, identity, and the IKEA effect connection
• 08:00 - The measurable cost, and Spolsky's defense of building in-house
• 09:00 - How the bias hides behind "our context is different"
• 10:00 - How it hits research and design systems, and where the IKEA effect sneaks in
• 11:00 - Engineering rewrites, competitor patterns, and acquired teams
• 12:00 - Turning the bias around with "proudly found elsewhere"
• 13:00 - Separate the source from the substance, and watch your team's own boundaries
• 14:00 - Give ownership before adoption, and treat build versus adopt as a real decision
• 15:00 - Audit your outside input, and back to the Cirrus lesson
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
• Subscribe on Stitcher
When Figma Was Just How We Worked // What Survives E01
A late-night DM from a listener named Chris asked me something I couldn’t answer: did I lose my identity as a designer? My team just went one hundred percent Cursor, no more Figma. This season, I figure out …
Notes de l’épisode
A late-night DM from a listener named Chris asked me something I couldn’t answer: did I lose my identity as a designer? My team just went one hundred percent Cursor, no more Figma. This season, I figure out what AI actually changes about the work, and what it never touched.
When the tool that defined your job for a decade disappears overnight, what part of “designer” actually leaves with it?
This is the first solo season in the history of Beyond UX Design. No guests, no interviews, just me working through one question that landed in my DMs late one night from Chris, a listener I’ve known for years. He asked whether I felt like I’d lost my identity as a designer after my team dropped Figma and went fully into Cursor. My gut said no. Thirty seconds later, I realized I didn’t actually know. That question became this whole season.
Episode one is about the world right before the change, back when Figma was just how we worked. I walk through what a normal design process looked like on my team, and then I get honest about something we don’t talk about enough: how much of “being a good designer” got quietly measured by tool fluency. Named layers, auto layout, clean files. None of that is capital-D design, but it stood in for it because it was the thing we could see, screenshot, and post about on LinkedIn
I also take on a good question from the original LinkedIn thread that inspired this. If you could always design and build in code, why is this suddenly a big deal now? My answer comes down to opportunity cost, and it reframes what AI actually changed. Spoiler: it wasn’t the ability to code. It was the time. If any of this sounds familiar, whether your team already made the switch or you can feel it coming, hit play and come along for the season.
Topics:
• 00:00 – The DM from Chris: “Do you feel as if you lost your identity as a designer?”
• 02:40 – The late-night LinkedIn message
• 03:20 – Why the identity question never crossed my mind
• 04:10 – 127 comments, and why they were almost all tactical
• 05:30 – This isn’t just a designer problem: PMs and engineers too
• 06:00 – What “normal” looked like: the old design-to-handoff process
• 07:30 – How designers quietly ranked each other on tool fluency
• 09:20 – Why tool skills got mistaken for design skills for a decade
• 10:40 – Derek’s challenge: “We could always design in code, so why now?”
• 11:20 – My front-end dev origin story and why it doesn’t settle the debate
• 12:50 – The real answer: opportunity cost, not ability
• 13:50 – What AI actually changed: collapsing the time to do both
• 14:40 – Were there warning signs? The pilots I read as experiments
• 16:00 – The real danger isn’t replacement, it’s belief
• 16:30 – What survives so far: research, flows, judgment, taste
• 17:10 – What still gets me, and a look ahead to episode two
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
Source Confusion: Why Your Ideas Get Remembered Under Someone Else’s Name
We remember what we learned but lose track of where it came from. I dig into source confusion, the memory quirk that quietly decides who gets credit on your team, whose research gets remembered, and why the …
Notes de l’épisode
We remember what we learned but lose track of where it came from. I dig into source confusion, the memory quirk that quietly decides who gets credit on your team, whose research gets remembered, and why the person who repeats an idea usually beats the person who had it.
Have you ever watched your idea come out of someone else’s mouth twenty minutes later and get all the applause you didn’t?
Source confusion is the reason your team’s history gets rewritten without anyone meaning to do it. We hold onto what we learn and quietly lose the note about where it came from. Back in 1993, researchers Marcia Johnson, Shahin Hashtroudi, and Steven Lindsay laid this out as the source monitoring framework: memories don’t come with a tag saying where they originated. Every time you recall something, your brain rebuilds the source on the spot using clues like how vivid it feels or whether you remember thinking it through. And because the source gets rebuilt instead of retrieved, it can get rebuilt wrong. An idea you worked hard on feels like yours whether it was or not, and an idea that arrived easily in conversation leaves fewer clues behind, which makes it easy to lose track of who actually said it first.
On a design team, this quietly reshapes who gets credit, and credit is the whole game. It decides who gets trusted with the next big project, who gets promoted, and whose voice carries weight in the next planning meeting. The person who develops ideas out loud and in writing piles up credit, while the person who seeds an idea quietly and moves on gets absorbed into someone else’s story. The good news is that this is predictable, and predictable things you can plan around. In this episode, I get into how to work with it: attribute out loud and in writing, capture ideas before the room talks, keep decision logs with names on them, and build your own paper trail because your org isn’t going to do it for you. Give it a listen and see where source confusion might be quietly rewriting your team’s history.Topics:
• 00:37 - Why it isn’t stealing
• 02:27 - Flipping the scene around: how you fall for this too
• 03:24 - What source confusion actually is
• 04:04 - The memory-as-filing-cabinet myth and the source monitoring framework
• 04:40 - How your brain rebuilds a source from clues instead of retrieving it
• 05:45 - The Brown and Murphy round-robin experiment and cryptomnesia
• 06:55 - Schacter’s seven sins of memory: these are side effects, not bugs
• 07:15 - How credit gets absorbed in critiques and research
• 08:12 - How this quietly shapes who gets promoted
• 08:45 - Using it to your advantage: be the last confident voice in the room
• 09:15 - The defensive move: stop relying on anyone’s memory
• 09:38 - Why your boss won’t track credit for you
• 09:55 - What to actually do about it
• 10:20 - Write ideas down before the room talks
• 10:50 - Attribute out loud and in writing
• 11:20 - Make your own contributions and leave a paper trail
• 11:50 - Check the origin story before performance reviews
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
What Survives: When AI Comes for Your Design Work (Season 1 Trailer)
At the end of April, my design team dropped Figma. As of May first, we've been one hundred percent in Cursor. Then a friend asked me if I'd lost my identity as a designer, and I couldn't answer him. This …
Notes de l’épisode
At the end of April, my design team dropped Figma. As of May first, we've been one hundred percent in Cursor. Then a friend asked me if I'd lost my identity as a designer, and I couldn't answer him. This season, eight solo episodes, is my answer. Starts September 08.
If the tool that defined your career disappeared tomorrow, what part of being a designer would actually be left?
This season is different. No guests, no interviews. Just me, telling you exactly what happened when my team lost the tool that, for a decade, basically defined what it meant to be a designer. At the end of April, our Figma license got cut. It wasn't our decision. By May first, we were doing everything in Cursor, and I've been sorting through what that means ever since.
The whole thing kicked off with a DM from Chris, a longtime listener and a friend, who asked me a question I couldn't answer: do you feel as if you lost your identity as a designer? My first reaction was no, obviously not. My second reaction was that I didn't actually know. Across eight episodes, I'm going to work through it out loud. The day the call came down. What we traded away and what came back. Whether I lost something or just lost the story where the answer was easy. What's still mine when the robot does the pixel pushing. The economics nobody wants to say out loud. And the question that worries me most: if judgment is what survives, and judgment gets built by the exact work that's disappearing, who comes after us?
I'm not selling a tool, and I'm not selling a course. I'm a design lead who's actually living this, and I've got a lot to say. If your team has made this switch, or you can feel it coming, this season is for you. Follow the show so the first episode lands in your feed on September 08.
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
• Subscribe on Stitcher
Anchoring Effect: Stop Letting the First Draft Define the Whole Project
Whoever puts the first number, the first draft, or the first design in front of the team quietly decides where everyone else ends up. This week I dig into why anchoring bias steers our estimates, redesigns, and …
Notes de l’épisode
Whoever puts the first number, the first draft, or the first design in front of the team quietly decides where everyone else ends up. This week I dig into why anchoring bias steers our estimates, redesigns, and negotiations more than we realize, and what we can do about it.
Ever set out to redesign a feature and ended up with the same product wearing a fresh coat of paint?
There’s a good chance you got anchored before the work even started.Anchoring bias is the tendency to lean too heavily on the first piece of information we encounter when making a decision. Amos Tversky and Daniel Kahneman named it back in 1974, and the effect is stubborn. Their famous Wheel of Fortune study showed that even a totally random number could pull people’s estimates toward it. Later research on experienced judges and real estate agents found the same pattern, even when the professionals swore the anchor hadn’t influenced them at all. That denial is a big part of what makes this one so tricky.
On product teams, this shows up constantly. The first draft of a PRD sets the frame every reviewer edits around. The old design becomes the gravity for the new one, and a supposed redesign quietly turns into a reskin. The first estimate in a planning meeting drags everybody else’s numbers toward it.
This week, on the Cognition Catalog, I walk through where anchoring comes from, why willpower and expertise barely help, and a handful of specific moves you can make to keep the first thing seen from automatically becoming the thing that wins. Give it a listen and let me know if you’ve caught yourself getting anchored lately.
Topics:
• 3:00 The Two-Week Estimate Trap
• 4:45 What Is the Anchoring Effect?
• 5:20 The Wheel of Fortune Experiment
• 6:20 Why We Stop Adjusting Too Soon• 7:15 Even Experienced Judges Get Anchored
• 8:10 The Real Estate Study• 9:00 How First Drafts Frame Everything
• 9:35 Why Redesigns Turn Into Reskins
• 9:55 The Status Quo Is an Anchor Nobody Chose
• 10:30 Using Anchoring on Purpose
• 11:25 Why Willpower Doesn’t Fix It
• 12:00 Five Things to Try With Your Team
• 14:30 The Bottom Line
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
• Subscribe on Stitcher
What Reinventing Your Career (Twice) Actually Looks Like with Chris Nguyen
Jeremy catches up with friend of the show, Chris Nguyen, who’s rebuilt his business twice since his last appearance. They talk about why designers can’t count on job security the way they used to, what it …
Notes de l’épisode
Jeremy catches up with friend of the show, Chris Nguyen, who’s rebuilt his business twice since his last appearance. They talk about why designers can’t count on job security the way they used to, what it actually takes to build something of your own, and why the perfect plan is a myth worth abandoning early.
If you can’t count on your job to protect you, what are you doing to protect yourself?
Chris Nguyen has already rebuilt his business once since he last joined the show, and by the time this episode airs, he’ll be in the middle of doing it again. He built UX Playbook into a recognized education brand, tried a community project called Backlog that fizzled out, took several months off to recover, and landed on Rectangles: a live-stream and newsletter brand built around the design conversations he wishes he’d had years ago. None of it happened on a straight line, and that’s kind of the point.
Jeremy and Chris talk candidly about why designers can’t afford to treat a single employer as their whole safety net anymore. Jeremy’s own team recently made a drastic tooling change that upended how designers on his team work day to day, and he connects that disruption directly to a bigger argument: if the ground can shift under you that fast, having something outside your job, whether it’s a side project, a creative outlet, or a small business, isn’t optional anymore. It’s how you stay steady.
The conversation keeps circling back to a simple, unglamorous truth: nobody has the plan figured out in advance. Chris talks about sitting on the Rectangles idea for the better part of a year before finally committing to a two-week sprint to get it out the door, and admits he still doesn’t fully know what it’ll become. Jeremy pushes on that idea with his own reflections on burnout, reinvention, and why doing something just for yourself, outside of work entirely, might be the most stabilizing thing a designer can do right now. Give this one a listen if you’ve been sitting on an idea and waiting for the right moment.
Topics:
• 03:16 – Catching up on 100 episodes and the never-ending edit grind
• 05:33 – What Chris has been building since his last appearance
• 06:20 – The funk, the time off, and the shift from product to media
• 09:37 – Why running a media company means the content is the product
• 11:36 – Chris breaks down what Rectangles actually is
• 14:04 – Going beyond UX and UI into big D design
• 15:26 – The early 90s aesthetic behind the Rectangles brand
• 20:10 – Why Jeremy’s team just walked away from their Figma license
• 22:42 – Designing straight into Cursor with a component library
• 29:20 – The case for building income outside a single job
• 32:36 – How UX education content has changed as the industry shifts
• 34:22 – The unglamorous side of building something online
• 52:56 – Why a latte art post outperformed a bias breakdown on LinkedIn
• 57:03 – Chris’s closing advice on ideas versus execution
• 58:23 – Consumption versus creation and why the balance matters
• 58:43 – Where to find Chris and the Rectangles launch detailsHelpful Links:
• Connect with Chris on LinkedIn
• Subscribe to Rectangles
• Get your UX Playbook—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
Ambiguity Effect: The Hidden Reason Your Roadmap Keeps Playing It Safe
Your team isn’t just avoiding risk, they’re avoiding the unknown. In this episode of the Cognition Catalog, I break down the ambiguity effect: the cognitive bias that makes unfamiliar ideas, tools, and people …
Notes de l’épisode
Your team isn’t just avoiding risk, they’re avoiding the unknown. In this episode of the Cognition Catalog, I break down the ambiguity effect: the cognitive bias that makes unfamiliar ideas, tools, and people feel like threats before anyone’s even evaluated them on their merits.
Have you ever watched a genuinely strong idea get quietly buried in a planning meeting?
Not because anyone argued against it, but because nobody could fully picture how it would play out?
The ambiguity effect is what happens when our brains treat “I don’t know” as “probably bad.” It’s not the same as avoiding risk. Risk is when you know the odds, and they might not be in your favor. Ambiguity is when you don’t even know the odds, and that uncertainty is what our brains treat as a genuine threat. The research goes back to economist Daniel Ellsberg in 1961, who ran a simple thought experiment with two jars of colored balls and predicted that people would almost always choose the jar they could see clearly, even when the hidden jar was, on average, an equally good bet. Decades of follow-up research confirmed he was right.
In a UX or product context, this shows up constantly and quietly. It’s the familiar roadmap feature that beats out the bolder, fuzzier idea. It’s the proven engineering framework that wins over the newer tool that might actually be a better fit. It’s the new hire or new leader whose ideas get extra scrutiny, not because they’re weaker, but because you haven’t had enough time to read them yet. The bias doesn’t announce itself. It disguises itself as discipline and caution. In this episode, I walk through where the ambiguity effect comes from, how to spot it in your team’s decision-making, and a handful of practical ways to make sure your best ideas get a fair shot before the fog scares everyone off. Give it a listen.fds
Topics:
• 02:28 – How the ambiguity effect plays out in a planning meeting
• 03:59 – What the ambiguity effect actually is
• 05:00 – The Ellsberg experiment
• 07:05 – Risk vs. ambiguity, what’s the difference?
• 08:22 – How it shows up on your roadmap
• 09:49 – When the unknown is a person
• 12:10 – What to do about it
• 14:42 – Closing thought—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
Build a Career That Outlasts Your Next Layoff with Frank Bach
Your nine-to-five pays the bills, but it doesn’t define your career, and if you think it does, that might be the thing holding you back. This week, I sit down with a lead product designer, community builder …
Notes de l’épisode
Your nine-to-five pays the bills, but it doesn’t define your career, and if you think it does, that might be the thing holding you back. This week, I sit down with a lead product designer, community builder, and all-around multi-hyphenate to talk about owning your career before someone else does.
What happens to your sense of identity when the job goes away? Have you built anything outside of it that would survive?
My guest this week is Frank Bach, a lead product designer who’s worked at places like Instagram, DoorDash, and Headspace. But honestly, the resume might be the least interesting thing about Frank. He also runs the LA Design and Dev community, teaches courses, fronts a hardcore band called Monk, and runs his own e-commerce shop, Sunshine Shop. Frank is someone who has clearly figured out that a career worth having doesn’t fit neatly inside one little box.
We get into a lot in this conversation, like the danger of tying your self-worth to a company name, why “personal brand” feels so gross to so many designers, and what it actually looks like to cultivate what you’re known for without becoming a full-time content creator. Frank has a really practical way of thinking about all of this: treat your full-time job more like a freelance engagement, stay in “maintenance mode” when life demands it, and remember that your manager is thinking about their own promotion, not yours.
We also talk about the other side of having a lot going on: how to decide when something’s run its course versus when you just need a breather, how to balance side projects without letting them eat your life, and why starting something messy is always better than waiting for the perfect moment. If you’ve ever felt like your career is just happening to you, this one’s worth a listen.
Topics:
• 03:20 - How Frank got into design and the multi-hyphenate mindset
• 04:20 - The danger of tying your self-worth to a company name
• 05:05 - Treating your full-time job like a freelance contract
• 06:25 - The upside of big brand names on your resume
• 07:05 - What happens to colleagues who lean too hard on “ex-Google, ex-Meta”
• 08:17 - Why personal brand feels gross to so many designers
• 09:35 - Personal brand isn’t just posting on LinkedIn
• 11:10 - Being memorable: your look, your setup, your presence
• 13:40 - The Instagram hiring story: 15 years of showing up paid off
• 14:45 - Internal brand: the designers who are legends without being online
• 15:37 - Maintenance mode: you don’t have to be 100% all the time
• 19:38 - Does your day job have to fill your creative cup?
• 21:05 - How side projects made Frank more valuable at work
• 24:45 - How to have the side project conversation with your manager
• 28:40 - How Frank stays consistent with so many things going on
• 29:15 - The minimum viable version: where to start if you have nothing
• 30:19 - Knowing when to cut something loose
• 33:57 - Hiatus vs. done: how to tell the difference
• 42:31 - Closing advice: you’re in the driver’s seatHelpful Links:
• Connect with Frank on LinkedIn
• Listen to Monk
• Sunshine Shop—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
Illusory Correlation: The Bias That Turns Coincidence Into Conviction
Your brain is wired to find patterns. That's mostly a good thing... until it's not. This episode breaks down illusory correlation: why your team sees connections that aren't there, and what you can do to stop …
Notes de l’épisode
Your brain is wired to find patterns. That's mostly a good thing... until it's not. This episode breaks down illusory correlation: why your team sees connections that aren't there, and what you can do to stop making decisions based on a handful of vivid moments dressed up as a trend.
Have you ever watched your team make a confident product decision based on a pattern that, when you actually look at the data, barely exists?
Illusory correlation is the bias that turns coincidence into conviction. When two things happen close together -- even just once or twice -- our brains quietly file them as connected. The concept was first identified by psychologist Loren J. Chapman in 1967, who noticed that trained clinical professionals were reporting patient behavior patterns that statistically didn't exist. The problem isn't laziness or bad intent. It's just how human memory works. Rare or distinctive events get stored differently, and when two unusual things co-occur, the brain treats that pairing as meaningful -- even when it's pure chance.
In product and design work, this plays out constantly and in ways that feel completely legitimate. A feature ships and traffic ticks up the next day, so the launch gets the credit -- even though a competitor was down and marketing ran a campaign. Six user interviews produce two mentions of a feature, and suddenly that feature defines the whole persona. A few support tickets from one customer segment, and that segment becomes "a tough audience." The misses get forgotten. The hits stack up. And the team ends up navigating by a pattern that was never really there. This episode breaks down how illusory correlation sneaks into your metrics, your research, and your team dynamics -- and gives you a few concrete habits to start catching it before it shapes your roadmap. Give it a listen.
Topics:
• 02:20 – Personal story: the engineering lead I had all wrong
• 04:29 – What is illusory correlation?
• 04:46 – The origin: Chapman’s 1967 research
• 06:19 – Hamilton & Gifford: how the bias distorts how we see groups
• 07:10 – Kahneman & Tversky: why illusory correlations stick
• 07:50 – How it shows up in your product metrics
• 08:23 – The A/B testing problem
• 09:00 – How it distorts how teams think about people and segments
• 09:26 – How it corrupts user research
• 09:50 – Engineering superstitions and team dynamics
• 10:27 – Why more data isn’t always the fix
• 11:00 – Five habits to fight illusory correlation—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
You're Not the Center of the Corporate Universe with Andy Vitale
There's a gap between how designers see themselves and how everyone else sees them, and that gap has consequences. In this episode, a seasoned design executive shares what it really means to be a good corporate …
Notes de l’épisode
There's a gap between how designers see themselves and how everyone else sees them, and that gap has consequences. In this episode, a seasoned design executive shares what it really means to be a good corporate citizen, why design isn't the center of the universe, and how to show up differently.
What if the biggest thing holding your career back isn't your design skills? What if it's the way you think about your role inside the organization?
My guest today has spent years leading design within large, complex organizations—places like Truist, 3M, and Rocket—where designers are easily outnumbered by scientists, engineers, marketers, and businesspeople. He's navigated financial realities most ICs never consider, managed situations that don't appear in any design curriculum, and had to advocate for design without assuming it's automatically the most important thing in the room. The conversation we had is one I've been wanting to have for a long time.
We got into what it actually means to be a "good corporate citizen," not in a corporate buzzword kind of way, but in a real, practical sense. We talked about the perception gap between how designers see themselves and how the rest of the team experiences working with them, why designers are sometimes seen as a speed bump instead of an accelerant, and what it looks like when someone on your team finally gets it. We also got into design systems as a business asset, the realities of design leadership that ICs rarely see, and a concept I've been thinking about for years: followership.
If you've ever walked out of a meeting frustrated, dissented in the Slack channel instead of raising your hand in the room, or wondered why your work isn't getting the traction it deserves, this episode is for you. Hit play.
Topics:
• 03:58 - Andy's origin story: raising his hand at 3M
• 05:30 - "Design wasn't the center of the corporate universe, it was a contributor to success."
• 09:32 - Defining corporate citizenship
• 11:15 - Why design education sets us up on the wrong foot
• 13:25 - The two disconnects: hallway dissent and the speed bump perception
• 17:22 - What it actually feels like to work with a designer who doesn't get it
• 19:00 - Stop playing defense on ROI: start pointing to the metrics the org is already tracking
• 21:10 - What a mature designer looks like: signals Andy watches for
• 24:10 - Pair prompting with PMs and building relationships through AI tools
• 26:00 - "You can't build great software without great relationships"
• 29:19 - Design systems as a moat for the organization
• 37:05 - Treating your design system like a portfolio piece vs. a business asset
• 40:52 - What ICs fundamentally misunderstand about leadership
• 44:00 - Context switching and the emotional weight of being a design exec
• 47:55 - The case for async feedback: never wait for the one-on-one
• 51:05 - Followership: having a point of view and showing up with swagger
• 53:45 - The Sully Sullenberger story: "my cockpit"
• 55:00 - "Own your shit."Helpful Links:
• Connect with Andy on LinkedIn—Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
Social Desirability: Everyone Knew. Nobody Said It.
We've all been in that meeting: the one where everyone nods along and nobody says the thing they're actually thinking. That's not a personality flaw. It's a bias. This episode of the Cognition Catalog breaks …
Notes de l’épisode
We've all been in that meeting: the one where everyone nods along and nobody says the thing they're actually thinking. That's not a personality flaw. It's a bias. This episode of the Cognition Catalog breaks down social desirability and what it's quietly costing your team.
Have you ever walked out of a meeting knowing you should have said something, and then watched the project stumble over the exact problem nobody brought up?
This week on the Cognition Catalog, we're talking about social desirability bias, and no, this one isn't just about user research. It shows up in every standup, every retro, every meeting where somebody asks "any concerns?" and the room goes quiet. Most teams deal with this constantly. They just don't have a name for it.Social desirability bias operates through two mechanisms: impression management, the conscious effort to present yourself favorably when you feel like you're being evaluated, and self-deceptive enhancement, a subtler, largely unconscious tendency to give positively biased responses without even realizing it. The tricky part is that it doesn't feel like a bias when you're in it, it feels like reading the room. It feels like being a team player. The cost shows up later, usually in a missed dependency or a launch that underperforms for reasons everyone saw coming.This episode gets into why honest cultures aren't built through value statements, why the HiPPO effect makes all of this worse, and what you can actually do to start closing the gap between what your team thinks and what they're willing to say out loud. If you've ever left a meeting with more to say than you actually said, this one's for you. Give it a listen.
Topics:
• 03:36 - What social desirability looks like at the team level.
• 04:32 - Why it doesn't feel like a bias when you're in it.
• 05:19 - The two mechanisms: impression management and self-deceptive enhancement.
• 05:50 - The research behind the bias (Edwards, Crown & Marlowe).
• 06:24 - When self-presentation slides into self-deception.
• 06:49 - How team norms shape what people say — and remember.
• 07:57 - The HiPPO effect and why it makes everything worse.
• 08:27 - How toxic environments turn up the pressure.
• 09:02 - Why honest cultures aren't built through value statements.
• 09:29 - Notice when your team is performing instead of communicating.
• 10:01 - Build structures that reward honesty.
• 10:29 - Notice when you're performing agreement yourself.
• 10:55 - Push past the summary and into the specifics.
• 11:20 - Lower the social cost of being wrong.
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Subscribe on Apple Podcasts
Yes, And... Now What? Improv Lessons for Navigating the Actual Job with Nikki Anderson
Your tools are solid. Your process is tight. But when a stakeholder pushes back, a workshop goes sideways, or a PM challenges your work, none of that matters. What matters is how you respond. Nikki Anderson …
Notes de l’épisode
Your tools are solid. Your process is tight. But when a stakeholder pushes back, a workshop goes sideways, or a PM challenges your work, none of that matters. What matters is how you respond. Nikki Anderson joins me to talk about improv, structured play, and how to stay sharp when the messy stuff hits.
What if the most important skill in your UX career has nothing to do with design?
Nikki Anderson is a UX research consultant, founder of Drop-In Research, and one of those rare people who can draw a straight line between improv comedy and stakeholder management, and actually make it land. She started doing improv around the same time she got into UX research, originally to overcome a lifelong fear of speaking on the spot. What she found was that the principles she was learning on stage translated almost perfectly into the conference room.
In this conversation, we get into the specific places where UX professionals tend to flail, and it's not where most people think. It's not the research plan or the prototype. It's the high-stakes meeting where everything's riding on one presentation. It's the design critique that spirals into defensiveness. It's the moment a stakeholder blames you for something and your fight-or-flight kicks in before your brain does. Nikki breaks down how improv—and specifically the "yes, and" mindset—isn't about blind agreement. It's about accepting reality, staying curious, and choosing to investigate rather than argue.
We also get into structured play, the idea that creativity doesn't just need freedom, it needs a container. Nikki makes the case that the most productive meetings, critiques, and workshops aren't the loose, open-ended ones. They're the ones with clear intention, playground rules, and maybe a little "draw a duck" warm-up before anyone starts giving feedback. If you've ever felt like the soft skills side of this job was something you were just supposed to figure out on your own, this one's for you. Listen in.
Topics:
• 04:00 - Nikki's improv origin story.
• 07:12 - Where UX professionals flail: the high-stakes meeting trap.
• 10:30 - The skepticism around "yes, and" — and what it actually means.
• 13:50 - Structured play and why it matters at work.
• 16:20 - Ambiguity and mismatched expectations: improv as a tool for dealing with them on the fly.
• 17:21 - Live stakeholder blame scenario: the "yes, and + investigate" approach in action.
• 22:45 - Applying improv to design critiques.
• 23:31 - Renaming critiques, setting playground rules, and warm-up exercises.
• 30:45 - Using improv to handle unexpected process changes.
• 31:30 - Accepting reality: the "yes" before the question.
• 35:55 - The control/no-control exercise for individual contributors.
• 38:10 - Creativity needs structure, not just freedom.
• 44:05 - Closing thoughts: take an improv class; nothing is an emergency.
Helpful Links:
• Connect with Nikki on LinkedIn
• Subscribe to the User Research Strategist—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Subscribe on Apple Podcasts
The Frequency Illusion: You Just Noticed It, but it Was Always There
Your brain doesn't show you everything around you — it shows you what it's been told to look for. In this episode of the Cognition Catalog, we break down the frequency illusion and how this quirk of attention …
Notes de l’épisode
Your brain doesn't show you everything around you — it shows you what it's been told to look for. In this episode of the Cognition Catalog, we break down the frequency illusion and how this quirk of attention can quietly warp how product teams spot trends, prioritize problems, and build roadmaps.
What if the trend your team keeps talking about isn't actually a trend — and your brain has been quietly manufacturing evidence for it this whole time?
The frequency illusion is one of those cognitive biases that feels like insight right up until it isn't. You learn a new term, you spot a new pattern, and suddenly it seems like it's everywhere: in your product, in your competitors' apps, in research you've been staring at for weeks. The information was always there. Your attention just finally got the memo.
In this episode of the Cognition Catalog, I break down how the frequency illusion works, where it came from (including the surprisingly colorful backstory behind the Baader-Meinhof phenomenon), and why it doesn't stop at UI patterns. The same mechanism that makes you see skeleton loaders everywhere after one design review is the same one that inflates a single customer complaint into what feels like a five-alarm fire on your roadmap.
The tricky part? It feels exactly like professional growth. And when an entire team gets primed on the same idea at the same time, that individual bias can scale into something much harder to catch. If you want to get better at separating what you're noticing from what's actually happening, this episode is for you.
Topics:
• 03:00 - The Inter story: how a LinkedIn post changed everything I saw.
• 04:00 - What the frequency illusion actually is.
• 04:30 - The Baader-Meinhof phenomenon and how it got its name.
• 05:00 - Arnold Zwicky coins "the frequency illusion" in 2005.
• 05:30 - Selective attention and confirmation bias: the two engines behind it.
• 06:30 - The recency illusion and how it compounds the problem.
• 07:00 - How the frequency illusion shows up in design critiques.• 08:30 - What to actually do about it: attention is not neutral.
• 08:50 - Watch for shared attention bias on your team.
• 09:20 - Don't let air time substitute for evidence.
• 09:45 - Create deliberate distance between discovery and decision.
• 10:15 - Surface what you're not seeing.
• 11:00 - Closing thoughts and listener question.
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
The Execution Trap Nobody Warns You About with Cat Lo
Cat Lo spent 20 years learning that execution excellence can actually hold you back. After burning out at Amazon doing beautiful work that nobody noticed, she distilled her hard-won lessons into five tenets, a …
Notes de l’épisode
Cat Lo spent 20 years learning that execution excellence can actually hold you back. After burning out at Amazon doing beautiful work that nobody noticed, she distilled her hard-won lessons into five tenets, a framework that helped her shape billion-dollar opportunities and drive $218 million in impact.
What if the very thing that made you a great designer is the reason you’re being left out of the decisions that matter most?
Cat Lo’s career has taken a path most designers don’t follow, starting with a bus ticket to New York City and no job waiting, through agency work, entrepreneurship, and eventually to Amazon, where she designs how millions of new products find their first customers. She didn’t take the traditional route from corporate to “I need freedom.” She went the other direction, deliberately. And that choice gave her a perspective on craft, scale, and influence that’s pretty hard to find in most design conversations.
In this episode, Cat breaks down why execution excellence, the thing that gets you hired and earns you trust, can quietly become a trap. The better you get at delivering, the more delivery lands on your plate. And the more delivery on your plate, the less you’re involved in deciding what gets built in the first place. The result is a framework of five tenets she uses every day: find the smallest testable truth, let customer data be the tiebreaker, ship to learn rather than waiting for perfection, align on the problem, not the solution, and look for the invisible problems nobody else is paying attention to.
Cat also walks us through a real example from her work at Amazon — a $7.8 billion market opportunity hiding in plain sight that most people had written off as not important enough to solve. It’s a masterclass in how individual contributors without direct authority can still shape strategy, build conviction, and make work impossible to ignore. If you’ve ever felt like you’re doing great work that just isn’t landing, this one is for you. Go give it a listen.
Topics:
• 03:27 - Cat’s Origin story: a bus ticket, $20, and no job waiting in New York City.
• 05:08 - Career arc: fine arts → art director → entrepreneurship → Amazon.
• 07:41 - Your skills are knobs, not switches. Learn when to turn each one up or down.
• 10:07 - Every company speaks a different design language; you have to learn to speak theirs.
• 14:17 - How to handle vague direction: match your response to the altitude of the ask.
• 18:00 - Tenet 1: find the smallest testable truth before going wide.
• 25:52 - Tenet 2: customer truth is the only real tiebreaker when opinions are flying.
• 30:36 -Tenet 3: achievable now beats perfect later. Ship to learn, not to finish.
• 37:33 - Tenet 4: alignment means agreeing on the problem, not the solution.
• 41:00 - The brand name generator story and the $7.8B opportunity nobody was solving.
• 48:00 - Tenet 5: look around the corner for the invisible problems no one’s been assigned.
• 53:15 - How to build influence without authority: state your opinion clearly and stay flexible.
• 01:04:05 - Where to find Cat: faangforcorporate.com.
Helpful Links:
• Connect with Cat on LinkedIn
• Subscribe to FAANG Boss—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
Survivorship Bias: Success Theater and the Data You Never See
We've built our careers on case studies, portfolios, and success stories, but what if we're only ever seeing a fraction of the full picture? This week, we dig into survivorship bias and how it quietly shapes …
Notes de l’épisode
We've built our careers on case studies, portfolios, and success stories, but what if we're only ever seeing a fraction of the full picture? This week, we dig into survivorship bias and how it quietly shapes the decisions your product team makes every day.
What if every case study and "here's how we did it" success story you've ever learned from was missing the most important part of the story?
Every startup founder story sounds the same. Crazy idea. Doubters everywhere. Bet on themselves. Changed everything. It's a great narrative, but it's a narrative written entirely by the people who made it through. For every founder who ignored the critics and won, thousands did the exact same thing and quietly disappeared. It may sound like pessimism, but that's the math we've been ignoring.
This week's Cognition Catalog episode breaks down survivorship bias: why we instinctively focus on the outcomes we can see while the failures stay invisible. It shows up everywhere; in the startup mythology we've absorbed, in the portfolios we scroll through on LinkedIn, and in the way product teams anchor their planning on the projects that shipped rather than the ones that got quietly shelved.
The good news is that this isn't a bias you're stuck with. There are practical ways to build better habits into how your team makes decisions, and it starts by asking a different question. Give this one a listen if you've ever wondered why your career feels like it doesn't quite measure up to everyone else's highlight reel.
Topics:
• 00:00 - The startup founder myth and why we only hear from the survivors.
• 01:23 - Welcome to the Cognition Catalog.
• 02:45 - The small business failure numbers that most people never talk about.
• 04:23 - What survivorship bias actually is and why it matters.
• 04:35 - Why portfolio case studies only show the work that succeeded.
• 05:35 - Why your career probably looks worse than everyone else's, and why that's an illusion.• 08:16 - How the college dropout mythology turns exceptions into templates.
• 08:40 - How survivorship bias quietly shapes product team decisions.
• 09:02 - Why your active user research is a filtered sample.
• 09:28 - How survivorship bias shows up in team culture.
• 10:09 - Five practical ways to fight survivorship bias on your team.
• 12:11 - The one question you should always be asking about success stories.
—
Thanks for listening!
We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
Democratize Without Destroying: The Case for Research Charters with Ned Dwyer
AI is making it easier than ever to run research, but faster doesn't always mean better. In this episode, we dig into what it really means to democratize research responsibly, and why your team probably needs a …
Notes de l’épisode
AI is making it easier than ever to run research, but faster doesn't always mean better. In this episode, we dig into what it really means to democratize research responsibly, and why your team probably needs a charter before someone does something they can't take back.
Your team is already running research without you. So the real question is: are you going to help them do it well, or just hope for the best?
Ned Dwyer is the co-founder and CEO of Great Question, an all-in-one UX research platform built to bring research to everyone in an organization. Not just the people with "researcher" in their title. He's spent years thinking about how teams can democratize access to customer insights without turning research into a free-for-all, and his talk at UX Con is what first put him on my radar.
In this conversation, we dig into one of the more divisive topics in our industry right now: research democratization. Ned makes a pretty compelling case that it's not the all-or-nothing argument a lot of people make it out to be. It's a spectrum, and where your organization should land on that spectrum depends on who you're researching, what decisions are being made, and how much risk is on the table. We also get into AI's role in all of this, from AI-moderated interviews to synthesized insights, and where teams tend to get themselves into trouble when they hand over too much to the machine without any real governance in place.
The thing I found most useful in this conversation is Ned's concept of a democratization charter, a practical framework for defining who should be doing what kind of research, with which populations, and under what guardrails. It's something I honestly hadn't thought much about before meeting Ned, and I think it's one of the most actionable ideas we've talked about on the show. If your team is already using AI research tools (and let's be honest, they probably are), this conversation is worth your time.
Topics:
• 01:45 - Ned's origin story and why he built Great Question
• 04:10 - The pressure to move fast, and what gets lost when speed wins
• 06:11 - The 80/20 rule: how to use AI without publishing slop
• 09:45 - Democratization is a spectrum, not a binary
• 12:35 - Where guardrails matter most: vulnerable populations and one-way-door decisions
• 13:12 - The case for a democratization charter
• 19:00 - AI moderation demystified: closer to a talking survey than a human interviewer
• 23:00 - Ned's GoDaddy confession: how rogue research goes wrong
• 27:00 - Participant fatigue and insight overload: the new risks AI introduces
• 31:45 - Rogue research will happen regardless... your job is to make it safer
• 43:28 - The Will Smith spaghetti analogy and where AI tools are headed
—
Thanks for listening! We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
Expectation Bias: Your Prediction Is Showing
Have you ever walked out of a usability session completely confident in your findings, only to ship something that quietly missed the mark? What if the signal was there the whole time, and your brain just …
Notes de l’épisode
Have you ever walked out of a usability session completely confident in your findings, only to ship something that quietly missed the mark?
What if the signal was there the whole time, and your brain just decided it wasn't worth logging?
This week on the Cognition Catalog, we tackle The Expectation Bias. This bias shapes what you notice before you've even decided what to think about it. Your brain has already generated a prediction before the first participant clicks a button or a teammate presents their work, and that prediction quietly shapes what registers as a signal and what gets explained away before you've made a single conscious decision about what any of it actually means.
We get into the science behind why this happens, and trace the research back to psychologist Robert Rosenthal's work in the early 1960s. His experiments, including the landmark Pygmalion in the Classroom study with Lenore Jacobson, showed that expectations don't just color our perceptions; they can actually change outcomes. That's a sobering thought when you consider how many design decisions are built on research we assumed was neutral.
We also dig into where this plays out on real teams: in usability sessions where hesitations get logged as "minor," in design reviews where leadership-championed features get a generous read while quietly doubted projects get interrogated at every turn, and in how we evaluate colleagues whose reputations have already done the evaluating for us. If any of that sounds familiar, this episode offers five concrete habits to help you catch the filter before it's already done its job. Give it a listen.
Topics:
• 00:00 - Perception is prediction
• 02:04 - A UX research cautionary tale
• 03:23 - Defining expectation bias
• 03:42 - Prediction errors explained
• 04:31 - Pygmalion effect origins
• 06:03 - Expectation vs confirmation
• 06:30 - How it warps team decisions
• 08:31 - Habits to reduce bias
• 10:47 - Wrap up and next steps
—
Thanks for listening! We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
• Subscribe on StitcherParty of One: Building a Practice When You're Alone in the Room with Julian Della Mattia
What does it actually take to be the first, or only, designer or researcher on a team? Spoiler: it’s not just about doing great work. This week, we get into the unglamorous, under-discussed side of the solo …
Notes de l’épisode
What does it actually take to be the first, or only, designer or researcher on a team? Spoiler: it’s not just about doing great work. This week, we get into the unglamorous, under-discussed side of the solo role: building systems, managing up, and earning trust before you’ve even shipped anything.
What happens when you’re really good at the craft, but nobody around you understands what you do, why it matters, or how to support you?
Julian Della Mattia has spent his career doing one of the hardest things in UX: showing up first. As a researcher who has repeatedly been the founding or solo practitioner inside organizations, Julian has learned, mostly the hard way, that being great at research is only a fraction of the actual job. He’s also the host of Finders to Builders, a podcast built specifically for researchers navigating this exact challenge.
In this conversation, we dig into what Julian calls the “finder to builder” mindset shift: moving from someone who just surfaces insights to someone who builds the infrastructure, earns the trust, and creates the conditions for research (and design) to actually matter inside an organization. We talk about how to manage up when your manager doesn’t fully understand your work, how to know when your efforts are starting to gain traction, and what the invisible job description of a solo or founding designer really looks like.
If you’ve ever landed a solo design or research role and felt the gap between what you prepared for and what the job actually demanded, this one’s for you. Julian brings a grounded, practical perspective that goes well beyond frameworks, because, as he puts it, in this context, frameworks rarely fly out of the box. Hit play.
Helpful Links:
• Connect with Julian on LinkedIn
• Follow Julian’s Substack
• Finders to Builders PodcastTopics:
• 02:25 – Meet Julian Della Mattia
• 03:48 – From PM to first researcher
• 06:06 – Agency advice for juniors
• 10:54 – Accidental in-house research role
• 14:28 – Finder to builder mindset
• 18:51 – Time triage and playmaker mode
• 24:53 – Invisible work and org dynamics
• 27:49 – Managing up and selling research
• 32:23 – Signals and metrics that it’s working
• 36:48 – Measuring research impact
• 38:35 – Skip the framework trap
• 39:02 – Managing up tactics
• 40:16 – Aligning with business goals
• 43:37 – Just ask your boss
• 44:43 – When to start hiring
• 46:32 – Recap and teamwork
• 48:37 – Parting advice for firsts
• 60:39 – Where to find Julian
—
Thanks for listening! We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
• Subscribe on Stitcher
Anecdotal Fallacy: A Data Point of One Is Not Evidence
Why does one vivid customer story outweigh months of research? This week on the Cognition Catalog, we break down the anecdotal fallacy — our tendency to let a single experience override real evidence. Learn why …
Notes de l’épisode
Why does one vivid customer story outweigh months of research? This week on the Cognition Catalog, we break down the anecdotal fallacy — our tendency to let a single experience override real evidence. Learn why stories hijack decisions, how this shows up on product teams, and what you can do about it.
Have you ever watched weeks of solid research get sidelined by one person saying, "Yeah, but I talked to a customer who hated it"?
We've all been in that meeting. The team has done the work—research is solid, the data points in a clear direction—and then someone shares a single story that shifts the entire conversation. A stakeholder mentions one piece of feedback from a sales call, or an engineer pushes back on a technology choice because of a bad experience three jobs ago. Suddenly, the energy in the room changes, and the data fades into the background. That's the anecdotal fallacy at work, and it's one of the quietest ways teams get pulled off course.
In this episode of the Cognition Catalog, I'm breaking down why our brains are wired to favor stories over statistics, and how this bias shows up constantly on product teams, from design critiques to sprint planning to roadmap discussions. We'll look at the research behind why personal narratives outperform aggregate data in persuasion (hint: it's not because people reject evidence, it's because stories are just easier to process and remember). And we'll talk about the HiPPO effect — when the highest paid person's opinion carries disproportionate weight simply because of who's telling the story.
But here's the thing... the goal isn't to eliminate anecdotes. Stories surface edge cases, highlight blind spots, and humanize insights. The key is learning to treat them as hypotheses, not proof. I'm sharing five practical takeaways your team can start using right away to keep one person's experience from becoming the whole team's strategy. Give it a listen.
Topics:
• 01:50 - When one story derails the team
• 03:49 - What the Anecdotal Fallacy is
• 04:21 - Why stories feel true
• 06:03 - How it hurts our team
• 07:36 - Fixes and team habits
—
Thanks for listening! We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
• Subscribe on Stitcher
From Iran to China to the US: A real-life VUCA Story with Mahnaz Hajesmaeili
Mahnaz has lived with volatility, uncertainty, complexity, and ambiguity in ways most product teams never will. In this episode, we talk about what happens when VUCA isn’t theoretical, how to avoid becoming an …
Notes de l’épisode
Mahnaz has lived with volatility, uncertainty, complexity, and ambiguity in ways most product teams never will. In this episode, we talk about what happens when VUCA isn’t theoretical, how to avoid becoming an order taker, and how courage, empathy, and initiative can reshape your role as a designer.
What if the volatility, uncertainty, complexity, and ambiguity you’re facing at work feel overwhelming only because you’ve never had to live through it in your everyday life?
I throw the word VUCA around like it’s a trendy framework. Volatility. Uncertainty. Complexity. Ambiguity. But for Mahnaz Hajesmaeili, those aren’t abstract concepts; they’re lived experience.
Originally from Iran, before becoming a product designer, she built a life in China, knowing she could never fully belong there. When COVID hit, borders closed, savings ran out, and the life she had carefully constructed disappeared almost overnight. She returned to Iran, started over, taught herself UX, and eventually rebuilt her career in the United States.
That’s not “roadmap volatility.” That’s real volatility.
This week, I chat with Mahnaz to explore how living through that level of instability reshaped her approach to work. Why rejected designs don’t shake her. Why unclear strategy doesn’t rattle her and why she doesn’t default to being an order taker.
If you’ve ever felt overwhelmed by shifting priorities or frustrated by leaders who “don’t know what they want,” this episode offers perspective—and practical lessons.
Give it a listen. It might change how you define uncertainty.
Helpful Links:
• Connect with Mahnaz on LinkedIn—
Thanks for listening! We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
The Testing Effect: Why nodding along doesn’t mean alignment
You can have clear meetings, clean decks, and unanimous nods and still walk away misaligned. In this episode of the Cognition Catalog, we break down the testing effect and why teams confuse exposure with …
Notes de l’épisode
You can have clear meetings, clean decks, and unanimous nods and still walk away misaligned. In this episode of the Cognition Catalog, we break down the testing effect and why teams confuse exposure with learning. We’ll look at how recall, not agreement, is what actually creates alignment.
If everyone was in the same meeting… why does everyone remember it differently?
You’ve probably experienced this before: a meeting ends with clear action items, apparent alignment, and a general sense that things are settled, only for confusion to resurface weeks later. Different assumptions. Different memories. Same meeting. This episode unpacks why that gap happens and why alignment without recall is basically an illusion.
This week, we walk through the testing effect and how it explains a common team failure mode: mistaking discussion, documentation, and agreement for learning. From onboarding to retrospectives to roadmap reviews, teams overload people with information and assume that exposure equals understanding. It doesn’t. Without retrieval, memory fades, rationales drift, and alignment quietly decays.
We’ll also look at what it actually takes to apply the testing effect at work, without quizzes or formal tests. Simple changes to how meetings end, how onboarding is structured, and how teams normalize recall can reduce rework, friction, and those “wait, when did that change?” moments. If you want decisions to stick, this episode is for you.
Topics:
• 00:00 - Introduction: The Meeting Dilemma
• 01:35 - The Illusion of Learning in Teams
• 03:48 - Understanding the Testing Effect
• 07:43 - Applying the Testing Effect in Teams
To explore more about the Testing Effect, don’t miss the full article @ cognitioncatalog.com
—
Thanks for listening! We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
• Subscribe on YouTube
• Subscribe on Stitcher
How Healthy Conflict Creates Better Design Decisions With Yaprak Gültay Davison
Most teams treat conflict as something to avoid. In this episode, I sit down with Yaprak Gültay Davison to talk about why that instinct backfires. We explore how healthy disagreement builds trust, improves …
Notes de l’épisode
Most teams treat conflict as something to avoid. In this episode, I sit down with Yaprak Gültay Davison to talk about why that instinct backfires. We explore how healthy disagreement builds trust, improves decision-making, and helps teams move faster... without blowing things up.
What if the tension you’re trying to avoid at work is actually the thing your team needs most?
Most design teams say they value collaboration, empathy, and alignment, but rarely talk about disagreement. In this conversation, I sat down with Yaprak Davison, Head of Design at Goodnotes and former design leader at Spotify, to unpack why conflict isn’t a threat to good teams. It’s often the foundation of trust.
Yaprak shares how designers are trained to optimize for harmony, and how that instinct can quietly erode clarity, slow teams down, and lead to decisions being made without the right people in the room. We talk about the real signals of unaddressed conflict—delayed replies, passive agreement, quiet misalignment—and why silence often causes more damage than open disagreement ever could.
We also dig into what it actually looks like to lead through conflict: naming tension early, separating facts from the stories we tell ourselves, and turning disagreement into a co-design moment rather than a power struggle. If you’ve ever felt stuck “keeping the peace” while things quietly fall apart, this episode will change how you think about conflict and your role in it.
Helpful Links:
• Connect with Yaprak on LinkedIn
• Subscribe to “Leadership as Craft”Topics:
• 02:49 – Diving into Conflict in Teams
• 03:18 – Guest Introduction: YRA Davidson
• 04:25 – The Role of Conflict in Design
• 05:45 – Managing Conflict in Design Teams
• 11:31 – Coaching and Cultural Differences
• 22:21 – Building Trust Through Conflict
• 25:21 – Scaling Teams and Systems
• 30:53 – Exploring the Concept of Followership
• 32:31 – Leadership as a Team Sport
• 33:40 – Balancing Leadership and Craft
• 35:43 – Building High-Performing Remote Teams
• 39:40 – Handling Remote Conflict
• 41:46 – Personal Insights and Advice
• 52:51 – Final Thoughts and Resources—
Thanks for listening! We hope you dug today’s episode. If you liked what you heard, be sure to like and subscribe wherever you listen to podcasts! And if you really enjoyed today’s episode, why don’t you leave a five-star review? Or tell some friends! It will help us out a ton.
If you haven’t already, sign up for our email list. We won’t spam you. Pinky swear.
• Get a FREE audiobook AND support the show
• Support the show on Patreon
• Check out show transcripts
• Check out our website
• Subscribe on Apple Podcasts
• Subscribe on Spotify
Voici les 40 derniers épisodes sur 218. Les épisodes plus anciens se trouvent dans le flux du podcast.
Podcasts similaires
Plus de podcasts : Arts
C’est votre podcast ?
Confirmez-le avec une entrée dans votre flux : vous recevez ici un code, vous l’ajoutez comme podcast:txt dans le canal de votre flux, et nous le vérifions. Votre podcast apparaît ensuite comme « vérifié » sur SoundNode.