S6E33 Bryant Foster | Design for Human Factors & User Experience

Join us for an in-depth conversation with Bryant Foster, a human factors expert who's worked with industry giants like Google to make complex products simpler and safer. With a background in cognitive psychology, Bryant shares insights on designing user-friendly products, from surgical systems to smart thermostats, all while keeping the end user at the center of the design process.

Main Topics:

• What drew Bryant into human factors and user experience design
• How to define and achieve simplicity in product design
• Advanced usability testing tools: eye tracking, pupilometry, and facial emotion analysis
• Why users don't always give honest feedback and how to work around it
• Providing critical design feedback without demoralizing teams
• Cost-effective approaches to human factors testing
• Safety considerations in medical device design
• Use-related risk analysis and task analysis methodologies
• Lessons learned from working at Google X
• Building successful human factors consulting teams

About the guest: Bryant Foster is the Vice President of Human Factors and User Experience at Research Collective, a user-centered research consultancy serving clients from startups to major companies like GE Healthcare, Microsoft, and Medtronic. With over a decade of experience in applied psychology and usability research, he specializes in ensuring products are safe, intuitive, and user-focused.

He holds a Master’s in Applied Psychology (Human Factors) from Arizona State University and began his career at the Cognitive Engineering Research Institute, later working at Google X as a UX researcher. At Research Collective in Tempe, Arizona, he leads a team that uses methods like ethnography, eye tracking, and biometric analysis.

In addition to his consulting work, Bryant mentors students and supports local entrepreneurs through programs like LEAP, blending scientific rigor with empathy in fields from medical devices to consumer tech.

Links:

Bryant Foster LinkedIn

Research Collective Website

Click here to learn more about simulation solutions from Simutech Group.

🚀 Join Us at PDX 2025! 🚀

PDX 2025 is the  Product Development Expo designed for engineers who want hands-on training from industry experts. PDX focuses on practical skill-building, cutting-edge tools, and real-world solutions.

📅 October 21-22, 2025
 📍 Mesa Convention Center, AZ
 🔗 https://reg.eventmobi.com/product-development-expo-2025

About Being An Engineer

The Being An Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources, and opportunities. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community.

The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us

Chapters

• 0:00 Bryant Foster's Background and Introduction to Human Factors
• 3:07 Challenges in Product Design and Usability
• 7:39 Approaches to Human Factors and Usability Testing
• 14:23 Tools and Techniques in Human Factors Research
• 25:37 Critical Feedback and Collaboration with Engineering Teams
• 28:42 Cost-Effective Practices in Human Factors Research
• 31:29 Safety and User Experience in Medical Devices
• 37:59 Lessons Learned from Working at Google X
• 43:25 Building a Successful Human Factors Team
• 51:18 Engaging with Research Collective and Career Advice

Transcript

Bryant Foster: 0:00

We're the ones that are saying, hey, let's pull this back, where others might be saying, let's add to it. And I think that's a good push and pull right? We can understand the need to put more features in and add complexity to it. I think as long as as we're being heard that adding this feature comes with a cost.

Aaron Moncur: 0:32

Hello and welcome to the being an engineer podcast. Today's guest is Bryant Foster, Vice President of Human Factors and user experience at research collective with a background in cognitive psychology and a passion for simplifying complex systems, Bryant has worked with companies like Google and other behemoths in the healthcare world to design safer, more intuitive products. His work spans everything from surgical systems to smart thermostats, all with the end user in mind, Bryant, thank you so much for joining us today.

Bryant Foster: 1:05

Hey, thanks for having me. Aaron, nice to chat with you again.

Aaron Moncur: 1:08

Yeah, yeah. This is round two for Bryant. He was so great the first time we just had to have him back. And his schedule is so busy, it took this long to get him here. Now we're here. Tell us a little bit about what what drew you into human factors, right? That that is your work, human factors, usability, research, what? What was it that brought you to that field? Um,

Bryant Foster: 1:31

you know, I yeah, this after I got my bachelor's degree, I didn't know exactly what I wanted to do, and I just spent a lot of time kind of looking at different options and and when I found user experience, I was drawn to it. It was this idea of, you know, improving experiences. And, you know, I thought of, I think back then, like going to Chipotle, and I was kind of liked how you go. You kind of know where to go when you walk in, and you some places you walk into, and you kind of, you don't know where to go, you know, like, I won't call any out by name, but I'm thinking of one in Los Angeles I went to, and it's kind of hip and cool, and I felt like a real idiot walking in there, because having never been there before, I didn't know where to go. And the people, it almost kind of weeds you out, you know, creates this exclusive feeling. But I don't think that's what, you know. What I was drawn to is designing things that are kind of usable by all people. And so I got interested in it, and it gave me an opportunity to be involved in design without an engineer, you know, really being an engineer or design or anything, because I don't have those types of chops. So getting to influence design and and really focusing on making design useful and usable without, you know, being the one to actually make it. And so, because I would have liked to have made it, but I just, you know, that wasn't really what I knew how to do. So it gives me a chance to be involved in in making things and which I enjoy, and then especially, kind of focusing on how people use them. That that drew me in.

Aaron Moncur: 3:14

The Chipotle example is a great one. I think that probably makes sense for a lot of people out there, I'm curious. Personally, I'm always looking at products, mostly to look at how they were designed and how they were manufactured, and sometimes from the context of, how would I improve this? But as a usability expert, I imagine you've got to be critiquing products left and right that you had no hand in developing but you know that you're using on a day to day basis?

Bryant Foster: 3:44

Yeah, it's, it's a bit of a curse of people probably, probably same for you in a lot of ways. And for us, I think, you know, the people we work with, we we constantly are saying these types of things, like, how did they not think about this aspect? And I think I drive my family crazy, so I've tried to balance it out over the years and realize like there. And also, too, I think I'm a bit more empathetic to the process of designing products, and I know how difficult it is. It's very easy for me to, you know, look at it through my lens, and as a consultant to where I don't really have the all of the complexity of the things that go into making a product. It's and so, you know, trying to realize, Hey, you can't, you have to make sacrifices. You can't just have every single thing be perfect. And but, yeah, it is. It is a thing we talk about all the time about how, you know, how could they miss that? How could they not? I know there's a specific example from something just recently, but I can't think of it right now. It's pretty consistent.

Aaron Moncur: 4:53

So when you're looking at a product and you're, you're wondering to yourself, how did they miss this thing? Not? This is an unfair question, because there's no way that you can really know, like, why a team did or didn't do something. But do you have any theories, like, General, kind of high level theories about why design teams miss some of these usability features?

Bryant Foster: 5:19

Yeah, I think when they're missed, it's it's often because the the it wasn't put in front of the people who would use it early enough. And that can be for a number of reasons. I mean, it's not easy to get a prototype product, you know, right, something that's in development in front of end users. But, you know, one example that comes to mind is for things that in medical space, like AI is huge, and especially in diagnostics, right, where there's pattern recognition involved. And so a lot of things are being used in imaging. And and you know, software is good at identifying patterns. And if we can train the software to say, Hey, this is what cancer looks like. And you know, it can be really good, but, but there's, there's something involved in that where the clinicians who might be looking at these scans, you know, they're accustomed to looking at them to identify the cancer, or, in this case, you know cancer, but, but now we're asking them to do is not to identify cancer. Was to say, is this identification Correct? Have we identified it? And that's a that's a bit of a shift. And so it seems like a really easy thing, like, Hey, we're making this easier for you, you no longer have to go and identify every instance you know how to set you now, just have to tell us if the system has done it right, if the software has identified it. But if that's not communicated clearly, it's it's confusing to them, and you know what they're used to doing over and over and over again, this new thing that's supposed to be easier now became more difficult, and it would never would have been known, right? We wouldn't seem like it could be more difficult until you put it in front of them, and you watch them, and you're going, what? Okay, they're very trained. You know, it's you've tried to communicate it clearly, but it didn't land somehow. And so I think we've, you know, we're seeing that some with with AI, and shifting how people are what they're expected to do, right? You're changing what you want them to do. And it's hard for people who have years and years of training and experience doing it one way to now say, think of it differently. Yeah,

Aaron Moncur: 7:39

you've worked with very large companies and small companies as well. So the idea of putting a product in front of a user early that makes intuitive sense, right? We're going to want to get user feedback quickly early on our products. Does the approach that you take to human factors usability? Does it change much depending on if you're working with like a giant, you know, fortune 500 company versus a small startup, or is it pretty much the same process across the board?

Bryant Foster: 8:14

I mean, I think if it could be this same process, as far as we're concerned with putting it in front of the user early and often, it would be the same for both. And the the whole idea would be some kind of low cost, low stakes. And my, what I love to do is, if you have a system that has various components, you know, it might have some software, some hardware, and maybe those things are not being developed all the same time. Maybe you get it's easier to prototype on software first, like, Okay, well, let's take that that if that's if we can prototype that quickly, let's get some of those questions answered. You know, I did this the way we're thinking about how the software is designed and laid out, you know, while hardware is working on other things, like, let's, let's evaluate that. So we can check that off and off to think about it again. So you know, whether that's a big company or small company, either that really would be kind of the way that I think it could be the most efficient, effective use of user about you know, like having users involved in in the evaluation of the product. Let's talk about

Aaron Moncur: 9:30

this idea of simplicity. I think intuitively, all of us want to use simple products. But how does research collective define simplicity, and when do you know if a product is simple enough,

Unknown: 10:51

from motors and robotics to controls, automation and precision prototyping. Simutek brings ANSYS. Simulation tools and expert insight directly to your team. We help you accelerate design, reduce risk and eliminate costly rework, validate before you fabricate symutek group helps you simulate thermal stress, vibration, fluid flow, electronics, cooling, electromagnetic performance, you name it, whether you're an automotive, aerospace, energy, industrial automation or the next big thing, simutek partners with innovators to deliver simulation driven results that move products forward, build smarter machines, launch stronger products, scale faster with simute X simulation support by your side, simitech group your engineering partner in motion, visit simutekgroup.com, and let's power up your next design.

Bryant Foster: 11:51

Hmm, well, yeah, I mean, was, I mean, not everything needs to be simple, right? There are things that that are complicated and there's just no way around it, you know, I mean complicated, you know, surgical like, surgical robots, like, there's so much involved in now you're not going to take away so much that that's not ever going to be complicated, but I guess, yeah, it's, you know, the idea of feature creep happens a lot with things and people getting excited, like, Oh, if we can add this additional feature, you know, it will. It could really help. But, you know, from our perspective, it's what can we take away from, from what's there? So there's a balance. And I think if we would say, if, if there's nothing more that we would take away, then, then that's pretty good. That would be kind of an ideal situation that would make it simple. And, yeah, I don't know if I answered that quite, quite right, but no, I think we did. We're kind of we're the ones that are saying, hey, let's pull this back where others might be saying, let's add to it. And I think that's a good a good push and pull right? I think that's necessary, and we can understand the need to put more features in and add complexity to it. And I think as long as as we're being heard that hey, this, adding this feature, comes with a cost, that can we live with that or not? I think that's kind of our role in that process.

Aaron Moncur: 13:36

I think that's a really important role and a smart way to think about the user experience is, what can we take away, in favor of simplicity and user experience. Because engineering teams, I know, generally speaking, we're thinking about, what can we add? And I think most teams out there are similar. So to have a group like research collective that comes in and says, This is great. Everything you guys done, looks looks awesome. There are a couple of opportunities we see here to actually pull some of it back and make the experience even even better for your users, your customers. So your team uses some pretty interesting tools like like eye tracking and facial emotion analysis. I mean, almost sounds like high tech spy gear, or, you know, something of that nature. What What kind of additional insights do you get from these the biometric results of these tools? Sure.

Bryant Foster: 14:37

So you know, in in the type of work we're doing, we're looking at, okay, what is the we're trying to make things simpler, and you can evaluate whether something's easy to use by putting it in front of people, like, what? What I think people used to do might have been, have people use it, then ask them, right? Like, what was that easy to use? You might have a scale, and then they could, you know, give it a ranking on that scale of easy to difficult. And anyone who's done this may have experienced a frustration when you've seen someone use a product and struggle like crazy with it, and then you give them, you know, that question after, like, how easy or difficult was it to use a name mark, easy, very easy. And you're, and then you're, then you're talking to them, like, Okay, what's going on here? Like, it didn't seem like it. And that can happen for any number of reasons, right? Like, by the time they're done using it, they they don't necessarily want to say, Oh, that was difficult to use. They might say, Well, I just didn't understand it. But like, it's easy to use, which is fair, and so everyone has a kind of a different way of thinking of how to answer that question. So by adding biometrics, it gives you another way of looking at things like cognitive load. So through. Pupil ometry, you can see kind of how much cognitive effort, how much effort people are putting into a process, and you can see that in real time and and so that might be another

Aaron Moncur: 16:11

pupil ometry. I've never heard this word before. So you can measure the size of the pupil, and that's a reliable indicator of cognitive load or

Bryant Foster: 16:24

effort, effort? Yes, yes. So, yeah. And so the whole idea is, you know, if you're trying, if you're if you're focused on something, your your pupils will dilate, right? Because you're trying to get as much information as you can. And and you know, those are small changes, but the technology is good enough to sense these small changes, and it's happening very quickly. And another thing might be like returning in this you're reading some text, and if you you know, we don't read linearly like this, right? But if you go back many, many times, that might be another indicator of, like, lack of comprehension, right? You're you're trying to understand it, and so you're having to look at it many times. And so these things can be added to that. You know, that analysis of how easy or difficult something was to use. And so now, if you've you've got the objective, you know, performance of them using it, plus some subjective things. And now you've got a bit more objective evidence through things like the biometric markers along the way.

Aaron Moncur: 17:36

You know, as you're talking about this, it reminds me of that TV show, house, actually, I recently started re watching it, so it's on my mind. Have you seen this show?

Bryant Foster: 17:47

I've never seen it. No, I heard good things about it, though it's

Aaron Moncur: 17:50

a great show. Dr Gregory House, and he's this world renowned pathologist, and patients come in with unique undiagnosable pathologies, and he and his team solve them, figure out what's going on. But anyway, one of the things that he always says about his patients is patients always lie. And I remember, I was thinking about that as you were talking, how big of a problem is that for you? I mean, you're not dealing with patients, per se, but users. How big of a problem is that users just don't give you honest feedback. I'm actually

Bryant Foster: 18:23

really glad you bring this up, because this is kind of one of the things I love talking about so and this is, I guess, pretty much, pretty deep in the weeds for human factors, people. But, you know, I think what we're seeing in our industry is, is a desire, well, in a lot of what, what we deal with is products that are seeking some sort of regulatory approval, right? A lot of people that are doing usability testing for like, a 510, K submission, and they're submitting that to FDA, and then the FDA will, you know, review their human factors or usability testing results and determine if the device can use safely. And what we're seeing a lot is people really relying on the self the report, the self report that people are giving. So do you know, not necessarily, was this easy to use, but in the case where, let's imagine someone needs to perform a task that has critical safety implications. You know, if they don't do it correctly, you know, they could hurt themselves or someone else, and if they don't do it as as expected or intended, the process is to ask them, you know, okay, can you tell me what happened here and what we all the only thing we know is that they didn't do what we wanted them to do, right, like what would have been the the safe way of doing it. We know that because we observed that. But when we talk to them about it, they can say any number of things, and I think a lot of people are relying heavily on what they say about why, you know, if someone says, oh, well, you know, I, I didn't understand. Well, let's see, let me, let me think of a good one. You know, I have used this other product, and, you know, it goes this way. And so I thought this one would be the same, but it wasn't, you know that to me, you know, I think what people are looking for is some way of, kind of not taking the blame of, like, that error, that, that misuse, and saying, Oh, well, you know, they, they had some other mental model, or they, you Know, applying knowledge from one device or one thing to another would be like negative transfer of training. So they have experience from one and they, you know, do it the same way with this other one. But that's not the correct way of doing it. And I would argue that we need to the device that we're that we're evaluating needs to overcome. Them you know, the person having a different mental model or having some other experience that you know influences their use of the product and and so, yeah, people you know. And sometimes, if you ask them enough like, let's say someone doesn't know. Like, I don't know why I did that, the trend is to sometimes continue asking them, like, Give me something like, Give me something to say. You know why this happened? Like, Why you You made this mistake. And eventually people will say something, you know. And they might not be lying, but they might be, and they might be making something up, or they might be just saying something so that you stop asking them. You know why it's

Aaron Moncur: 21:41

like torture, right? You keep torturing. Eventually they're going to tell you something

Bryant Foster: 21:46

exactly. And so you know, how reliable are those responses and and my, I guess my argument is, how valuable are they? Because what we know is the design allowed this mistake to happen. First and foremost, we need to, you know, understand if we can live with that and and the why it's it's important, more in the, in my opinion, more along the lines of, like, Okay, how would we design this out. So if someone says, oh, well, that button didn't look like a button. I don't know it looked like I was supposed to push it instead of pull it right, like, okay, maybe we can change the design. And that's the value of talking to people about why they did what they did, not necessarily to say, hey, you know, is the design to blame for this? We know the designs to blame because the thing happened. And so any discussion we have should be centered around, you know, how do we make thing better? If there's a way to make it better? Sometimes there's not right. Sometimes people make a mistake, and, you know, they don't know why. And you look at the design, you go, I don't know what else we could do with it. And that that's that's okay. You know that that can happen. But, yeah, there's, there's anyway. You got me on my soapbox about kind of people talking about why, why they make mistakes, and we just a lot of times, don't know and and I think that the only thing we know is kind of what we're able to

Aaron Moncur: 23:16

observe. I love it. I can hear the passion in your voice. Are there any products out there that most of us know and you think are particularly well designed from a human factors, user experience

Bryant Foster: 23:31

standpoint? I mean, I'm I'm happy that now that a lot of them are like a lot of products. I'm I like to ride bikes, and, you know, I like any sort of I got some lights recently from a company called nog, K, N, O, G, and they're definitely like an industrial design driven group and but everything from their packaging to, you know how you interact, they need to make a bell that I put on my mountain bike, and it's just, it's, it's usable, like any you know how to use it, but it doesn't look like any Bell you've ever seen. It just, it's just like this little ring, and that could be confusing, but just the way it was packaged, the simple instructions they had made it, made it really easy. So, yeah, I think definitely user experience has gotten much better, you know, with Yeah, while I think Apple, you know, you put, made a big push on your user experience and and simplifying things, taking away from design. But, yeah, those are some things that come to mind.

Aaron Moncur: 24:50

Yeah, I think it was Mitt Romney that I heard this from. It wasn't directly from him. It was, it was from someone who had been part of his company. What's his company? Bain, I think the consulting company. And as the story goes, I heard third hand Mitt Romney was speaking to his company of consultants, and said, Hey, we are not. What was the word he used, not pigeon, Siegel. We are not Siegel consultants, where you fly in crap, all over everything, and then fly away. That's not how we operate. I thought of that because tangentially, I'm sure that's not what, of course, that's not what what your team does either. Nevertheless, you are going to have to provide some critical feedback at times to your customers. And you know, these, these teams of engineers and industrial designers, project managers, this is their baby, right? This product that they've designed and developed and birthed, it's their baby. How do you handle situations where, like you need to provide some critical feedback that maybe not all of your baby, but. This part of your baby is ugly,

Bryant Foster: 26:00

yeah, yeah. That's a huge part, I think, of of what we do. And I like that, that story, and, yeah, I think the, the way we try to think about it is we don't want to provide a critique without a recommendation, right? Like, so not just it's, it's easy to critique things, right? It's like, especially, I feel like, for people like us who chose to do this for a career, but yeah, we really try to say, Okay, what? What's good about it? And that's, that's maybe something we could even do better. Because I think a lot of our like a usability study of a product is designed to determine if the device is is usable and and if you know it's really designed to find problems. It's not designed to tell you everything that's great. And so then a lot of times our reports just kind of focus on problems. And really, you know, I think we've done this better sometimes than others, but we there are so many good things about the design, right? The majority of it is good. And so I think it's important to start with that. And some teams are more sensitive than others. You know, some teams are like, tell us everything that's that's bad. Like, that's why you're coming in. Like, you don't need to sugarcoat it. But others, yeah, it is their baby. I mean, there are people who their their jobs are, are on the line for, you know, a lot of times with some of the smaller companies, like, it's all riding on this thing, you know, being successful, making it to the market. So I think just having remembering that, and, you know, it can be easy for us to in our own little world, just look at problems, but But remembering there's so much more to it, and the majority of of the product is good if we find issues, you know, pointing those out as the minority of things that could be improved and and not just that they need to be improved, but saying, Hey, here's some here's some ways they can be improved. Because I think that helps us become part of the solution rather than just pointing out the problem.

Aaron Moncur: 28:23

How can engineering teams be most cost effective when working with a human factors group like research collective? Or are there some best practices that they can follow so they give your team an opportunity to identify problems early and in a way that's less expensive to fix.

Bryant Foster: 28:44

Sure, yeah, there, there's an analysis called a heuristic evaluation that that we do, and it's, it's really kind of like an expert review, right? We we see a lot of different types of products, and we, there's, there's certain things that you just kind of know are good design. And these are, these were developed originally by jakka Nielsen, the 10 heuristics and and so we we would evaluate a product to these principles. And so without any sort of user involvement, right? No, no evaluation, where you bring people in and have them use the product, we can kind of just get some of that low hanging fruit that we say. I'm trying to think of a good example of this from something recent even, like some simple things, like some home use products that are designed to be really simple, that sometimes they're too simple, right? Like, sometimes the instructions are too minimal, that you go, I don't think people are going to get, you know, one important thing about instructions is, if you're going to give people instructions, like make sure you tell them each step, because if they are relying on those which you know, sometimes the battle is just getting them to look at the instructions. And if you, if you, if you win that battle, and you get them the instructions, well, you definitely want the instructions to walk them through the process and and sometimes instructions get can be a little too designy, if you will. They might be beautiful, but they but they are not kind of task by task. And so it might skip a thing, or take for granted that it didn't communicate this one piece. And and people, if they are kind of reading those literally. Then they, they go from one thing to the next, and they, they've skipped this thing. So those are the types of things that we might catch in a curious evaluation, because we would look at and say, Okay, what are the tasks? And if I'm doing this, as someone who doesn't know, you know, if I follow those instructions, would I get? It to the the end result. And anyone can really do that, but it's just often not thought of, right? It's just, it's, it's easy to overlook in all the things that have to be done and created. So that's one way of, kind of saving some some money. Because without bringing in participants, you're saving, you know, lots, lots of money not having to pay them. I'm, you know, have a space to do it. All those things would be cost savings. Yeah, that's great.

Aaron Moncur: 31:30

So your company's focus is, is healthcare, and especially in healthcare, safety is a huge, huge issue, right for good reason. What are some of the most critical factors? Because a lot of our audience, not all of them, by any means, but a good chunk, are in the medical device space. What are some of the most critical factors in ensuring medical devices are both safe and user friendly. Let's focus more on the safety aspect here. Are there kind of general rules of thumb?

Bryant Foster: 32:06

Yeah, I feel like something that people are doing much better these days, or companies are is establishing. And part of this is, I think FDA, for example, has been better about communicating the need for something like a use related risk analysis and having that early rather than waiting, you know, too late in the process. And so essentially, a use related risk analysis is it starts with a task analysis. So task everything from, you know, maybe even purchasing a product, unpackaging it, setting it up through use of it, disposal, every task that any user will have to perform, you know, really being granular in listing out what those tasks are and and that might change, right? So sometimes what's hard for people is to think about doing that when the design isn't complete, and the you know, the tasks might change. And I think that's okay, right? The The idea would be for this to be a living document, and so as early as possible, create this task analysis and let it evolve, let it grow with the product and the design and and so the the use related risk analysis takes that task analysis and then assigns potential harm to any of those tasks that are not performed correctly or skipped, let's say, and. And that would you know, I think companies are very familiar with risk analysis, and, you know, in things like manufacturing and all different reasons how risk could get into, you know, to the patient or the user, and the use related risk analysis would take from the big risk analysis and say, Okay, if someone doesn't clean the skin before they, you know, put this thing on. What is the what could go wrong, and then what is the severity of that harm if that happens, and that could be anything from negligible to serious harm, death and that so, having, having that, that use related risk analysis and understanding it very clearly shows you where the serious harm is. You know, that's what you really want to focus on, because, you know, if something leads to negligible harm, then you know, no harm really, then that's that's more of a nice to have in terms of safety for your FDA submission. But if something could really hurt someone or worse, then those are the types of tasks that that the FDA is going to be really, you know, keen on making sure that you have evaluated and that your design, the design of your product, kind of mitigates those issues. And, of course, the company themselves want to make sure that that, you know is is, is not those harms are being realized and and so having that early, you might be able to focus earlier in the prototyping phase on some of those critical tasks. So you know, if cleaning the skin isn't a really important thing. But let's say that holding an injection at a correct angle, let's say, is super important. Then maybe you would design those instructions and evaluate those more critical task instructions earlier in the process to again, we're trying to kind of put things to bed, like get things behind this. Hey, we know this design is good. We don't have to think about it again. We can keep moving forward that design and focus on new things. And so if you have that list of what's really important, what's safety critical, kind of focusing on those tasks, making sure that you're communicating them correctly. And. And people are understanding kind of how to do those tasks as early as you can. The last thing you want to do is get to the end and then realize, oh, people don't know the angle this thing's supposed to be held. We have to change the instructions, or we have to change the device, because it can't be held at that angle, but based on the way it's shaped, right like things like that can happen. So having that use related risk analysis early and letting it grow with the product, I think can really help

Aaron Moncur: 36:26

in engineering. There's something called an FMEA. You heard of an FMEA? Okay? Oh, yeah. It sounds like that's your analog to the FMEA.

Bryant Foster: 36:34

Yeah. And sometimes it's people will talk about a use FMEA. And you know, I think what's cleared up more in in the recent guidance documents for FDA, is is, rather than starting with the the hazards, starting with the tasks, and then assigning hazards to misuse on tasks. And I think it's just kind of a slightly different way of thinking about it, like from a use Related perspective, I like thinking of, here's all our tasks, regardless of any harm. Then we can look at, okay, if they're not done right? Let's, let's think about where harm can happen. And I think they kind of like sometimes a use related risk analysis might identify a potential harm that wasn't in an FMEA, right, right? Maybe like this. So all these things kind of need to work together. Something represented here might identify a hole in something else, and then, similarly, right, like some harm in a FMEA might make us go way, way. We didn't even know that was possible. And maybe it's not from misuse but, but needs to at least be considered.

Aaron Moncur: 37:41

Yeah, I hear people calling FMEAs femas. It's just another way that people refer to the same thing. FEMA and it all is a stupid tangent. Doesn't matter at all, but it's always bugged me that people call her the female. Like, how does FMEA spell female? Right? The letters aren't arranged that way people, yeah, but anyway, my engineering brain just can't let it go. FMEA, so you spent some time working at Google X, which is a prestigious place to be. Can you think of something you learned there that you have taken throughout your career?

Bryant Foster: 38:21

Probably, um, probably the biggest thing that I learned there. So that was the first place I worked after grad school, and I I still had visions of being a designer at that point. I think it never really occurred to me that I would be a researcher fully, even though that's kind of what I went to school for, I always picture myself more involved in coming up with ideas and for for design and Google, Google X had some incredible designers like and I just realized really quickly, okay, my role here is to be a researcher. And if I can be a good if I can provide good insights, those those folks can make it look really cool, and can actually make it happen and so much faster than I can. So yeah, I think for kind of a younger, more inexperienced. Me, it was, it was seeing how good people really are at their roles there and and then me realizing I got to be really good at this role, right? So where I design is research, like I'm designing a study because, you know, you can do a study that doesn't answer questions that you might have had, right? So I think starting with good questions saying, Okay, we need to know, you know, does this message clearly communicate this thing? And so how do we evaluate that in, you know, that's in a realistic context? Because it's, it'd be possible to, you know, do a study and come out with results, but because the the study was, you know, not realistic enough, those results might not be reliable. And now, when you put it into a more realistic study, or in the real world, it, it doesn't, you don't get the same results. So that's kind of where I've found joy in being involved in design processes, designing good studies that help answer questions that people can take and then build cool stuff

Aaron Moncur: 40:27

with that story really resonates with me, finding these designers that were so good and made you realize that maybe that's not my calling. What I'm really good at is the research, and that's where I should focus. I've felt kind of my whole career, like I'm never going to be the superstar engineer. I know superstar engineers, and that's not me. I'm I'm good at certain areas, for sure, I think I pretty darn good with mechanical design, but there are other areas. Is basically anything that is associated with electrical not me, no, no programming, no software. Not me at all. I'm not the guy who knows all the physics and the thermo and the the you know, statics and dynamics equations I can get around Excel well enough, but, but I'm, I'm not a master Excel artist and and so over my career, I've, I've come to accept the fact that I'm, I'm never going to be that superstar engineer. But you know what, I am very good at communication and organization and building culture and building community. I'm, in fact, I didn't realize how good I was at those things because they just came natural to me, yeah, and at a certain point I realized, oh, that's actually a skill that not everyone else has, and I'm pretty good at this. And so combining that, of course, I have a background, a long background, in engineering as well, and combining those two things has worked out well for me. But I think that's, I mean, your point is a really good one. Identifying what you're not best at is maybe as important as identifying what you are best at.

Bryant Foster: 42:52

Yeah, certainly for me, yeah. I think, I mean, you probably don't give yourself enough credit, right? We do that a lot. Yeah, enough credit, and it is hard to recognize what comes easy to us, because you didn't think that. You thought everyone could do that. It would like the things that you're good at. So, you know, that's, that's, that's pretty cool.

Aaron Moncur: 43:13

Well, tell me, tell us a little bit about the the process with working with a group like research collective, probably some listeners are listening to this and thinking of themselves, man, we could really use some help from a team like Bryant's what like, what's the process for Working with you and your team? The Product Development expo or PDX, is your chance to learn from subject matter experts, providing practical hands on training for dozens of different engineering topics, Gd and T advanced surface modeling, DFM, plating and finishing techniques, programming robots, adhesive, dispensing, prototyping tips and tricks and lots more. PDX happens October 21 and 22nd in Phoenix, Arizona. Learn more at PD Expo. Dot engineer, that's p, d, e, x, p, O. Dot engineer,

Bryant Foster: 44:17

yeah. I mean it, it can really vary quite a lot, just kind of an introduction call to say, to kind of identify where, where people are at. You know, sometimes, usually people are coming to us when they know they either want to design something new and they want to understand, okay, how should this thing be designed? And we can help do certain types of research to kind of look at maybe what people are doing currently, and where there's opportunities to design something to fill a void. And then, of course, if they have some sort of prototype or some sort of product that they're developing, and they want to know, you know, is this, is this usable? And then, you know, they they can contact us and talk, and we can, you know, start with this heuristic evaluation or put it in front of some users in a small study. And, you know, every once in a while, we get people contacting us who got pushback from FDA, and they the FDA setting where we need to see the results from your usability testing and and then, you know, they now they're looking for someone to help them do that, and we can certainly help in those situations as well. How about

Aaron Moncur: 45:42

for teams who, for whatever reason, aren't quite ready to engage with a team like yours, but they know that they need some kind of usability, some kind of UX research. Is there anything that, you know, small things that non experts can do to at least get the ball rolling in that direction. Yeah,

Bryant Foster: 46:03

you know, working with a group right now that that we're just helping them do a task analysis for their product, and maybe something they they could do, but it's, I don't think it's going to cost them. I know it's not going to cost them all that much money to have us do it. And I think by you know, they're learning along the way, and maybe it's something that they in the future do themselves. But you know, anything, nothing's too small, really. And, and I've talked to groups before where. They, you know, they want to get involved, get us involved in doing stuff. And then I might say, I don't think now's the right time, right like, let's get, let's get you down the road on having some prototypes, and then at that point we'll we can evaluate them. And so, yeah, it's, it kind of just depends, but it's probably never too early to at least have a conversation and and kind of setting plans for when might be a good time to have something formal,

Aaron Moncur: 47:05

cool, nice. Okay, one more question, and then we'll wrap things up here on this episode, thinking back over your your career. What is the project or the accomplishment that you're most proud of?

Bryant Foster: 47:24

This doesn't necessarily have to do with any sort of product project or anything, but I'm I feel very fortunate to work with the people I work and so the president of research Collective is Russ branigan, Dr Russ branigan, and he was my grad school advisor. And when I, you know, mentioned finding user experience with no background in it, he was kind enough to take a meeting with me and and then, you know, not tell me in that moment, like you don't really have any background in this, he kind of said, well, here's some things you can do to get involved. Here's some classes I would take. And then, you know, to work towards applying to the grad program. And you know that that got now I'm here, right? And so, because he was willing to take that meeting, and then we worked together through grad school, and now over 10 years later, we're still working together and and so that probably is the, like, coolest thing about it all. And then we have this great team. And you know, you know, it's it, we never knew kind of what this would be. And it's, it's grown, we say organically, and you know, it's it, we've, we've pushed it, but at the same time, you know, just kind of added people as as as we needed, and tried to always, a lot of times, when we had people that'd be like, Well, we really can't see this person not being with us. So, you know, I don't know if we have the work, but let's for sure have them, and we'll figure that out. And that, you know, has, has, I think, worked well for us. And, yeah, so yeah, just working with the group that I work with is it's nothing I've done, or it's not an accomplishment. So maybe it's not really an answer your question, but I think it's, uh kind of the biggest joy of of what I'm able to do day to day.

Aaron Moncur: 49:34

Yeah, you're evaluating the products from all of your customers, and at the same time, you've been building your own product, so to speak,

Bryant Foster: 49:44

yeah, yeah, no, it's true. We and you know, I'm very proud of the reputation we have in our field. That has just kind of grown, grown with us. And I think we get a lot of good feedback from people about just being flexible and easy to work with. I think a lot of times it is easy. It would be easier for us to be critics of products, right? It'd be very easy for us to design studies, find problems, tell people what the problems are, and and just kind of cut and dry, no emotion. But I feel like we it's not something we necessarily would try to do. We just were more naturally interested in being kind of partnering with with people. And so, you know, that requires us to be a little bit more flexible. You know, timelines change all the time. Goals change. People ask to throw things into studies at the last minute, and it it would be much easier just to say, No, we've got this thing designed this how we're going to do it. But kind of accommodating those things is has led to getting a lot of feedback, of being easy to work with and and being flexible, and I don't think we want to have it any other way.

Aaron Moncur: 51:02

How can people get a hold of you, whether it's to talk about engaging professionally on a project or, you know, maybe there's someone out there listening right now, who is the Brian Foster in in waiting, right? Doesn't necessarily have that human factors background, but, man, that sounds so cool. I'd love to get into that, and maybe Brian can give me some some advice. How should people get in touch with you?

Bryant Foster: 51:29

Um, I mean, so our website is research, hyphen, collect. Collective.com and and my email and LinkedIn are on there. My email, Bryant at research, hyphen, collective, Bryant, B, R, Y, a n t, those are probably the best ways. And yeah, I do. I certainly love talking to people about various projects, but but also people interested in the field. You know, I think that's I'll be very open to having those types of conversations.

Aaron Moncur: 52:06

Fantastic. All right. Well, Bryant, thank you again for appearing on the being an engineer podcast and sharing all about human factors and user experience and all the fun insights and stories that you've collected over over your time at research collective and before. So really appreciate you having you here, and thank you again.

Bryant Foster: 52:28

Yeah, thanks for having me here.

Aaron Moncur: 52:30

I'm Aaron Moncur, founder of pipeline design and engineering. If you liked what you heard today, please share the episode to learn how your team can leverage our team's expertise developing advanced manufacturing processes, automated machines and custom fixtures, complemented with product design and R and D services. Visit us at Team pipeline.us. To join a vibrant community of engineers online visit the wave dot engineer, thank you for listening. You.