A slight correction from last week. The re-brand of the newsletter is under the newly formed Pipeline Media Lab (not group as I said last week). Sorry for any confusion.
Pipeline Media Lab is still committed to telling the human stories behind the physical products that we know and use everyday. But, we also have some exciting tools, technology and apps in the works to augment our work in delivering impactful stories to you all. Stay tuned for an exciting 2026!
In this week’s newsletter Aaron Moncur has a conversation with Bryant Foster, VP of Human Factors and User Experience at Research Collective.
We know the design's to blame because the thing happened. Any discussion we have should be centered around how do we make the thing better, not whether the design is to blame.
In this episode:
How asking "what can we take away?" creates simpler products than adding features
Why biometric testing reveals cognitive load that self-reports completely miss
How early task analysis prevents expensive failures during FDA submissions
Why observing user behavior matters more than asking users to explain their mistakes
Bonus Content:
Lego’s masterclass on reverse compatibility engineering. How they maintain clutch power across 60 years of production.
S6E33 Bryant Foster | Design for Human Factors & User Experience
Bryant Foster from Research Collective challenges standard product development with a simple question: what can we take away? While engineering teams naturally push to add features, Foster's human factors work reveals that real simplicity comes from strategic reduction. He introduces biometric testing tools that expose cognitive load invisible to traditional methods—pupillometry measures mental effort through pupil dilation, revealing when users struggle even as they report tasks as "easy." The conversation tackles a uncomfortable truth about user research: people don't accurately explain why they make mistakes, and continuing to ask only produces unreliable answers. For medical device teams, Foster outlines how starting with task analysis and use-related risk assessment catches safety-critical design flaws early, before they become expensive problems at FDA submission. The episode offers practical frameworks for teams looking to build simpler, safer products by observing what users actually do rather than relying on what they say.
>If YouTube isn’t your thing, check out this episode and all of our past episodes on Apple, Spotify, and all the rest.
Join us for two days specifically tailored to Engineers that design, build and test product. PDX Expo features 35+ exhibitors, hands-on demos, and 50+ interactive training sessions.
Experience this bootcamp-style expo packed with practical knowledge and real-world solutions that boost your career and your company’s success.
PDX flips the conference model. Vendors don't pitch - they teach. You don't listen - you do.
Master advanced CAD techniques. Compare servo vs. stepper motors hands-on. Learn FDA compliance from engineers who actually file 510(k)s. See cloud-based collaborative design vs. file-based workflows.
We’ve added a fun way to learn, engage and build real skills. 36 learning based challenges with raffle entries on the line.
Prizes include a Bambu Labs 3D printer, free passes to PDX 2026, and a Pipeline Design & Engineering Threaded Insert Installer.
Complete challenges. Build real skills. Win cool prizes.
Reserve your spot now before space runs out (only a few spots remain as of 10/14/2025).
Mesa, AZ | October 21-22, 2025 | $295 (while space remains)
P.S. As subscribers of this newsletter, use code “WBH50” for $50 off registration!
User Self-Reports: Why Observable Behavior Trumps Verbal Explanations
When users struggle with a product during testing, design teams often focus on understanding why the user made the error. But Foster argues this is asking the wrong question. If a design allows a mistake to happen, particularly one with safety implications, the design is at fault regardless of the user's explanation.
We know the design's to blame because the thing happened. And so any discussion we have should be centered around how do we make the thing better, not whether the design is to blame.
People naturally want to explain their mistakes in ways that make sense to them: they reference other products they've used, mention they "didn't understand" something, or point to external factors. These explanations can lead teams to categorize errors as "negative transfer of training" or "incorrect mental models" rather than recognizing them as design failures that need fixing.
A lot of people are relying heavily on what they say about why. If someone says, oh, well, you know, I didn't understand... I think what people are looking for is some way of not taking the blame of that error, that misuse, and saying, 'Oh, well, they had some other mental model.
When users can't immediately explain their mistakes, researchers sometimes keep probing until they get an answer. This creates a problem - users will eventually say something to end the questioning, but that explanation may be fabricated or unreliable.
Sometimes, if you ask them enough, like 'I don't know why I did that,' the trend is to sometimes continue asking them, like, 'Give me something.' And eventually people will say something. They might not be lying, but they might be making something up, or they might be just saying something so that you stop asking them
The valuable part of discussing errors with users is identifying what design changes might prevent the error. If a user says a button didn't look clickable, that's actionable. But trying to psychoanalyze why they made a mistake when the design clearly allowed it wastes time and produces questionable insights.
The why is important more along the lines of, 'Okay, how would we design this out?' So if someone says, 'Oh, well, that button didn't look like a button,' okay, maybe we can change the design. And that's the value of talking to people about why they did what they did.
Lego's Hyper-Focus on Reverse Compatibility Engineering
On January 23, 1958, Godtfred Kirk Christiansen sketched several solutions to a stability problem on a piece of paper. Among them: hollow tubes on the underside of plastic bricks that would interlock with the studs on top. This simple drawing established what may be the most demanding backwards compatibility requirement in manufacturing: every brick produced since 1958 must connect perfectly with every other brick, regardless of when or where it was made. Walk into any LEGO store today and buy a set. Those bricks will connect with bricks your parents played with in 1975. Which will connect with bricks from 1963. Same clutch power. Same connection force. Same reliability. This is an engineering commitment that touches every aspect of how LEGO operates, from the steel mills that make their molds to the software systems that track specifications across six continents.
For more, visit the full article on The Wave.
The topic of manufacturing is always hot, especially with the recent focus on tarrifs. John Boezi, raises an interesting question about the intent behind reshoring of manufacturing and what we can do to be apart of the movement.
Hi all, I've been thinking about this a lot lately. I think the intent around making more products in America is good. However, I feel like the global deck is stacked against it. The headwinds are against businesses. I'd love to hear choices or strategies other engineers have used to make it possible for companies to manufacture their goods in the USA.
Will automation be our savior? Is that feasible for small businesses? What else can we do?
Anything to add to the discussion? Join the conversation on The Wave.