Human Factors and the Future of HMI, Part One: | The Tech Between Us s4 e5 | Mouser Electronics
If you've been listening to this podcast for a while, you'll know that I'm a huge fan of Star Trek The Original Series. Even now, I can picture the iconic bridge of the Starship Enterprise with panel after panel of blinking lights that signified something was going on, but was more likely to induce epileptic seizure than provide meaningful information to the crew. And as Captain Kirk orders ahead warp factor three. I was captivated by the seamless interaction between human and machine as the group pressed and poked dozens of nearly identical knobs and buttons on the control panels, each with its own sound effect, but nothing being clearly indicated or labeled except the occasional item that was important to the plot for the week. I guess you'd need an identical memory to work in Starfleet, to perfectly remember which color shape in order to push the buttons and knobs. I completely acknowledge that this was low budget 1960s science fiction, but this premise does launches into our topic for the day as we boldly go to explore the strange new worlds of human machine interface.
From the smartphones in our pockets, to our cars, to the coffee makers on the countertops. We are constantly using our devices, but not all interactions are created equal. Some devices seamlessly integrate into our lives, while others leave us scratching our heads in frustration to help us understand why this happens, and more importantly, how manufacturers determine how we interact with our devices. We have with us today, Allison Strochlic, Senior Research Director for Emergo by UL and co-author of the book “Usability Testing of Medical Devices.” Allison, welcome to The Tech Between Us. Can you briefly tell us a little bit about yourself and what you guys do at Emergo? Raymond, thanks so much for having me.
Really excited to be here with you today. So my name is Alison Strochlic. Like I've been in the field of human factors engineering, specifically in the medical and pharmaceutical and healthcare domain now for about 20 years. I'm a senior research director for the Human Factors research and design team at Emergo by UL, which is a consulting team with over 45 folks globally, all focused on the same goal, which is to help make medical and pharmaceutical and health care products easy and safe to use. So I've had an undergraduate and graduate degree in human factors, which some people may just come away from this podcast realizing that's a discipline that you can go into.
So that may be learning number one. And so we'll of course talk about that today in the context of HMI. And then the team I'm a part of, Emergo by UL. It is part of UL solutions, which was previously known as Underwriters Laboratories.
So UL solutions provides testing, inspection and certification services, software products and also advisory support, which is the group I'm in and we focus on a wide range of industries, but do a lot of work in the life sciences and healthcare space. And many people, engineers and lay users alike, are familiar with the UL brand and the UL certification mark. If you look on a light bulb or the bottom of computer chargers, you'll often see a little UL on a circle. So that's the broader group that I'm a part of.
When we first started talking, I saw the UL. I was really curious whether that was truly Underwriters Lab, because every engineer knows UL. I mean, through the certification process, the testing process, the safety processes.
I think every engineer on the planet is familiar with UL. It's great that you are all one big company looking after a larger goal with all kinds of equipment. Yeah, 100%.
So the focus continues to be on safety as well as security and sustainability for a wide number of domains and with an expanded set of services. Certainly. Then we're in place almost 130 years ago now. Absolutely.
And like I said, an incredible pedigree. And maybe I'll just add another word or two about our specific team, because that's what we're here to focus on, is that human factors or HMI piece of it. What our team does is we work with medical device pharmaceutical manufacturers throughout their product development effort to help make sure their products can be used safely and effectively. We're eager to help our customers succeed in the market and also make sure they can comply with a number of regulatory imperatives to apply human factors throughout development. Obviously, the topic of the segment is technically HMI.
However, human factors seems to encompass a lot more of that. Can you help just define for us what you mean by human factors? Absolutely. So Human Factors is a multidisciplinary field that's at the intersection of if you think of like a three part Venn diagram, the way I think about it is that it's psychology, engineering and design. And my undergraduate degree is actually has the name engineering psychology, which was the original term, and now it's human factors, but that's another term for it. But at the broadest level it's working to help ensure there's a great match between people and products or people and systems.
Or you can also think about people and services. And so the goal is to intentionally design that product or system or service around the user instead of design a product which, from an engineering perspective and a biocompatibility perspective and an electrical safety perspective, is wonderful, and then later put it in people's hands and say, I hope people can use it. And so it's really about designing products based on concrete knowledge of the end users, which might include what are their abilities, what are their limitations.
Maybe you have users who are impaired or need to design around. What past experiences do your users bring to your products that are going to impact and should impact how you design that product? And just making sure that there's a user centered design is another term that people say that is relevant in the human factors world. So I can give some kind of specific examples, if you don't mind. Sure. Absolutely. The types of human factors considerations.
So for example, studying how people use current products, interviewing them, collecting their feedback, understanding what their needs are, their preferences, making sure there's a good match between those products and people physically. If you think about the terms like ergonomics and anthropometrics ... does a handle I need to grip is that grippable by a hand of my size? Do I fit in this chair? Can I stand at this desk and also thinking about the physical but also cognitive elements of interacting, you know, in terms of memory constraints and cognitive abilities? And then the last thing I'll throw out there for now is this term of mental model, which basically is the model that you've developed as a user of something, and how you then move about the world with that as your set of expectations or that as your baseline. And what can happen when people have a mental model that's different than the product you've released into the world? As a former design engineer. Yeah.
You have this. “well, of course they're going to use it like this.” And I guess in your world that really it's never an “of course” it's always, “well, you use it like this.” And one of the main activities that we do for our customers is an activity called usability testing. Or some might call it user testing. And the purpose of that is to have people come in and essentially test drive your product, give it to them. And in the medical space we have them simulate using it.
Our team does not do clinical trials, anything like that. But whether it's an inhaler or a pen injector or an infusion pump or a hospital bed or a dialysis machine or a surgical robot - having whoever those users are come in and try to use it and give their feedback. And something that's super fulfilling for me is that when we have customers who come to watch these usability test sessions, some labs, when we have product managers or design engineers or people you know from other parts of the business, come and watch people use this product that they've been designing and just have these “aha” moments is fulfilling and gratifying and obviously very insightful for those developers.
I completely agree. And even doing the podcast, talking to different guests, I love having those “aha” moments. Yeah, so that's a fun part of it as well. I bet now you said it was, you know, kind of a Venn diagram of psychology and engineering and design.
Is there a discipline or one of those that actually is more important in the earlier stages than the other? I would think the psychology would tend to go first before engineering and design, but do you find that true? That's a great question. I've never thought of it in terms of when does one discipline come up. You know, you can almost imagine almost like a graphic of sound wave when one comes up that goes down. And I think if I was to choose among those three, certainly it would start with the psychology piece, because you want to start applying human factors principles when you're starting to think about designing a product. So it's not when you have a prototype or your designs almost finished and you want to check some boxes, that's way too late. You really want to do it early on.
And so it's thinking about what am I designing, what problem am I trying to solve? Who are the users of this product? What are their challenges and what are their expectations. And so that's when it comes to doing early stage research, which can be in the form of interviews, focus groups, observations in certain cases can be extremely valuable. So going into a home environment or for us sometimes a clinical or hospital environment to see how does a surgical team use this product and what are the challenges, or how does a nurse in a NICU work with this kind of incubator? And so you do want to think about the users expectations, abilities up front and then help that go into shaping what you're designing, what it needs to be doing, etc.. Right? Yeah, it seems like a logical progression to understand and then to design and to build.
And so really does kind of have that natural flow to it. And the one thing I'll mention about the flow, there's a flow. But there's also one of the key aspects of human factors is this iterative design. So it's not as though, Okay. you do the research first and then you move on to setting your requirements and designing it and verifying it. Do you want to come back and, Right. usually with a different set of users,
but sometimes the same, say, okay, thanks for all that. We design this. What do you think at a stage where you can still make changes and modify it? Because one of the things we see is that people come along to this human factors and these types of usability evaluation activities too late and the design is frozen and they can't really change it. And at that point, you're really missing out on a lot of the potential benefits of applying these analysis and evaluation activities. Now, I mean, I know this is kind of going looking further down into your process, but that's curious. I mean, you said how many iterations, obviously, if everybody does their job right, and magic happens, there's one iteration.
But how many iterations have you seen or do you find is necessary to really get down into the details? It really varies. And I'll actually say that if you only have one iteration, I would say you actually haven't been doing the job. Well, you could you could say that yes, the product you designed is wonderful and people can use it. And wow, great job. But what we in the field really try to proselytize is this iterative approach and getting feedback early. And then you refine the design and maybe you even have two competing designs at first, and you want to use user feedback to down select. Okay, great.
So then you take concept A and you refine it some more and you put it back in front of people. And the same iterative process occurs with other parts of human factors activities. For example, in the medical and pharma space where I mostly operate, there's this activity called I use related risk analysis, where you take a product as it's being developed and think, what could people do wrong with this product? Where could there be potential harm? Or even more concerning the potential for serious harm? And then how do we mitigate against that? Or how do we design a solution that limits or even inhibits that from happening? And so that also is an iterative process. As you develop the design, as you see if the safeguards you put in place are effective or not, but in terms of the number of rounds, it really depends in part on the complexity of the product. Are you developing? I'll go to an extreme for a moment.
A robot assisted surgical system that has five subsystems, and then each of those is its own mini development effort. And then ultimately, of course, they come together versus if it's a simpler like single or multi use drug delivery device or combination product, as we call them, an injector or an inhaler, there are fewer interaction points, fewer touch points, and therefore ideally fewer opportunities for error and fewer variations. I suppose that you could consider, but I'd say at a minimum, you'd want to have three of these iterations that involve some form of user input or user feedback and human factors. A big joke is that the answer to most questions are. It depends. So I've already said it once, and I'm going to try to max out at maybe, I don't know, 4, 5, 6 at a max, but it does really depend.
Right. That's twice now I got two. There you go. Well, that's funny because a lot of people at Mouser ask me, so, you know, what do you think about this or what do you think? And that is my go to answer. Well, it depends. It depends. So I'm in good company. Yeah, exactly. I completely get that. And it's a great way to have people actually think about, you know, what they're asking.
There is a lot going on these days about user interface design, user experience design and then human factors. Are they all separate entities or are they all just different aspects of the same or different phases of the same thing? Yeah, I'd say they're cousins, maybe siblings in some cases. So certainly I would say that the terms engineering psychology is a much older term we don't really hear anymore. But just follow the path. Human factors is a term that is more recent than that.
Maybe around the 1940s, 50s, I think people started applying human factors specifically to like aviation and cockpit design. And then over the past several years, user experience is a much more popular term. And it's a great question.
And sometimes we feel like we're swimming around in this pool of technical terms and buzzwords. How can they really be distilled down to the same core set of terms? Right? A colleague of mine actually wrote a blog on this very topic once, like user experience versus human factors versus UI design versus HCI, but honing in on the terms that you mentioned. So UI design, user interface design, the way we use the term user interfaces, I think a lot of people, when they think the term user interface, they think of software. Sure, they think of a GUI or a graphical user interface, but a user interface is actually any user touchpoint.
So it can be software or hardware or labeling packaging. It can be training that someone uses on a product. So technically, the way we view it and the way we know that, for example, when it comes to product development, the US Food and Drug Administration, the FDA uses the term user interface is any thing the user interfaces with. And so UI design is specific to the design of all of those touchpoints, but doesn't necessarily imply like a user centered approach or something like that, which is where human factors is really human factors, user centered approaches. And then UX or user experience has seen a rise in popularity. And I view UX as broader, like what is the user experience.
So how are people perceiving things? How do they interact with products? How is their satisfaction? What is the workflow? What are those interactions? And I think that some people use the term UX to refer to the look and feel of the product, but I do think it goes beyond that quite a bit. So I'd say user experience and human factors are kind of getting at the same thing, but with a little bit of a different angle. And then UI design I would say is more focused on the actual design of the thing, right? As opposed to looking at the interaction of the people with the thing.
That's interesting. Yeah. I look at HMI, there are human machine interface and UI as similar as is, like you said, the kind of the the actual interface, whether it be physical or software or whatever. But you know, what does somebody see. What does somebody touch. And clearly human factors there is all these other things that we've been talking about, the intent, the whys, the what's and the whys. On top of all that. I think it is HMI
and UI to me are like again the interface, that thing. And I think when you get into human factors engineering and user experience, you're broadening it a bit. And again, the term that didn't come up that I still think of as one of the siblings is user centered design.
So that I feel like is more akin to human factors engineering in terms of you're putting the user in the center and designing around them for them based on knowledge of them, that type of thing. That makes a lot of sense and it's funny that you, that you mentioned engineering. I've never heard the term engineering psychology. Kind of an older school systems engineering, more of a term. Interesting. Yeah.
Because to me, yeah, engineering and psychology are like diametrically opposed disciplines. I know interestingly. So I went to Tufts University for my undergraduate degree and they have the program was first called Engineering Psychology. And you can take it through the School of Engineering or through the psychology department as a liberal arts degree. No way. Really. And then what? I was on the engineering side.
But basically you take these core classes in human factors engineering. But then on the psychology side, you go deeper into psychology. And I also had psychology classes.
It's part of that core Venn diagram. But then I had more of kind of core engineering and like intro science classes that were required from the engineering disciplines. So I think it's really interesting how that is like truly available on both sides. And it just weighs one discipline more than the other through that educational pathway.
Not necessarily in the real world. Right. Yeah, I guess I would have never put the two together. And and it's funny because I'm an engineer and my boss is his degree is in psychology. Go see if he knows about it. Yeah, exactly. Well, now we can need a put to get together here.
Let's stop here to highlight one of Mouser's articles on HMII. In the article “Human Machine Integration: Bridging the Gap Between Human and Machine,” we dig a little deeper into how human machine interfaces are evolving to enable easier and more intuitive ways to use our many devices. Read the full article and other pieces by visiting mouser.com/empowereing-innovation. Now let's get back to the conversation as we discuss the future of HMI and human factors. All right, so we've talked a little bit already about the different techniques and the processes that you and your team go through to evaluate human factors for client products or products in general. Can you kind of walk us through a little bit more detail what you guys do, whether it be on a daily basis or on a project by project basis? Yeah, sure.
So, our team provides services throughout the product development lifecycle. So in terms of when we engage with the client, the earlier is better. But I should acknowledge that some of our customers and manufacturers do have human factors teams internally.
Okay. And so whether it's through a consultancy like ourselves or through internal resources, the earlier the better in terms of applying human factors. So if people are, you know, highlighting parts of this podcast, take that away as a as a discussion start earlier, not later, but whether it's our team or whether they're internal resources doing it. Human factors should start early. When you're looking to design a product or conceptualize a product, many times customers reach out to us once they already have that concept in play, and they've already taken those earlier stage steps. And so we want to then help them plot out what comes next, basically, on a human factors perspective between whenever they contact us and when they're looking for regulatory clearance.
Because one thing I'll mention is that in a consumer domain, for example, if you're developing a new blender or a connected washing machine or something of that nature, there are many fewer requirements for human factors, or I would say no requirements for human factors. For some, consumer products are, of course, safety requirements. But I think it's important to know that when it comes to medical and pharmaceutical and health care products, there are strict regulations and standards for doing this work. So.
Right. Yes, there are commercial benefits for having products that are easy to use, safe to use, etc. but the U.S., FDA, for example, also international regulators in Europe and China and Japan have standards that are called, applying human factors to medical device development. So there's the commercial piece and there's a regulatory imperative. And we help our customers figure out what they should do to accomplish both those objectives.
So in addition to all the safety and obviously the safety regulations, there is actually a set of regulations that says not only how safe it, but if there are actually regulations that say how it should take the user into consideration. Yeah, absolutely. So I'll just focus in on the FDA, for example. Okay.
And the FDA released what's currently its final guidance was from 2016. So a little while ago now but still relevant. And that guidance document certainly the end point is demonstrated to us as regulators that the product you've designed, medical, pharmaceutical, health care software as a medical device, whatever it may be, can be used safely and effectively by the intended users in the intended use environment. So that's like the thesis statement that you want to make about human factors in your submission. And then the agency goes on to tell you how they think you should accomplish this. And so some of the key aspects of that are this use related risk analysis that I mentioned briefly earlier, where you're kind of dissecting the entire workflow of your product, identifying what could go wrong at each of those steps, and what the potential harm is that comes from those.
And then also doing these user evaluations as the product is being developed. Now, the FDA isn't particularly concerned about, okay, do you do two cycles? Do you do four cycles. Do you do ten of these earlier? Okay. Evaluations are usability tests. But what they want you to do is at the end of your product development effort, they want you to run this. We call it a human factors validation test.
And they actually have pretty specific guidelines. They say, okay, bring in 15 people who represent each of your user groups. Run a study like this. Oh wow. Record what mistakes they make, what difficulties they have while using your product.
Analyze those findings, feed them back into your risk analysis, and then come show me that based on all that, that's how you demonstrate the use safety of your product. The FDA's also concerned about clinical efficacy and clinical trial results and biocompatibility and electrical safety testing and all these other things. Sure. But Human Factors is one of those pieces of the puzzle that needs to be demonstrated from a product safety perspective to be able to access the market. That's really interesting. So, yeah, I mean, I would have never guessed that they would get down to that level of detail in the actual product design, sort of like you said, does it work? Is it safe? Yeah, they really get in there and we see them.
They review protocols, our customers submit and reports, and they ask questions. Hey, I noticed that seven people made this mistake and you said it was because of this, but we're still concerned. Tell us why this is okay or fix it and retest it. And as consumers, we should feel pretty good about that, right? Because there really is a high standard of care put in place, especially for these products where there's a potential for serious harm to occur if the products not used properly, they know the process to get an FDA certification can be, you know, pretty lengthy and really pretty arduous, having worked with some medical equipment designers in the past. But does that contribute to the length of time, or does it actually make it better at the end, or does it do both? That's a great question, and I'll allow me to.
Let's transition to a MythBusters segment for a second. So okay, I think some people who are used to a product design process that doesn't traditionally involve human factors, they learn about it. They're like, oh, I have to add in this other thing, they may be concerned about the time and the budget, right. But you need to get this work done.
Ultimately, we don't want the regulatory imperative to be the driving force all the time, because manufacturers should want to make their products competitive, satisfying to use, usable, right. We want customers to want that. And sometimes it is the FDA needs you to do it, so you got to do it. But if you do it early, when I'm saying talk about it with the users early on or at the concept phase, it should actually shorten your overall development and save you money, because you're not going to be spending all this time on a development effort that once you get to this closer to regulatory submission to this human factors validation test, we're like, oh, wow, oops, that's an oversight.
People cannot use this thing. People can find the emergency stop button. This is terrible or whatever it is. Then you've got to unfreeze or thaw your design.
You have to go back. You have to redo tooling like it's a mess. And so doing this type of work early on can save time and money. Leading up to a regulatory submission, but also when your products on the market, because you will have already seen people use it, you have a lesser chance of adverse events or liability issues.
Hopefully it takes less for people to train on your product. There's a faster learning curve. They're all benefits that come from doing this sooner. That can ultimately lessen the timeline and cost burden to product development.
But it's not viewed as that initially. Right, exactly. I mean, you know, and once again, you're more from the probably from whether from the product design, less the psychology, more product design engineering. Yeah, you get it. Just rolling their eyes. Oh gosh. Okay. We know we got to do this. Oh gosh we got to do that.
It's going to you know but like you said ultimately it makes a better product. It makes a better product. And what I love as I talked about this like “aha” moment when we have a customer or a product manager or an engineer who's watching users for the first time pick up this thing they've designed and try to use it. We've had clients who go so far to basically say, like, okay, on Monday, these five people are observing. On Tuesday, we've got these five people and they use it as an opportunity to connect, albeit through a third party connect their engineers to their users and like really help develop this sense of connection and in some cases, empathy. Right.
Because empathy is actually a really important skill when it comes to these types of disciplines and product research and product design. And here's your user meet them. They have a name. They have a face. They have a family.
They have goals, they have busy lives. And just to see people I think really use a product can contextualize the development effort for those on the other side of it. Yeah, like you said, it's those “aha” moments.
You know, as an engineer, I mean, my empathy score isn't great, but to be able to see it and to, you know, to to see their, like you said, see the reactions and get those “aha” moments, I think is is really important for an engineer, especially an engineer who is looking at doing more and doing higher level things. Yeah, and it's not just about seeing people who might struggle with the things you've designed. Right. That's sometimes some of the “aha” moment is like, wow, that person interpreted that in a completely different way than I expected. I'll throw in a quick example. This was years ago, but it's it's such an easy to recall example that it always jumps into mind, which is that we were working on a dialysis system that's intended for hospital use.
And there were a couple of controls on the screen. It's a touch screen and the user needed to start the treatment back up. And they were looking at the screen is in a usability study. They were looking at the screen and thinking like well I don't want to cancel. But why is resumé on the screen? I don't really get that.
Oh, and it was the word resume, and that person happened to interpret it as resumé and you're like, wow, I wouldn't have thought of that. And so now the button says continue. That's such a minor example, but you would not have known that unless you put that product in front of the user. Right? So those things happen all the time and they're the difficulties, but they're also the examples of people saying, oh my gosh, can I get this product now? I love this so much more than the products I'm currently using or how can I get this? Or when will this be out? And this is why it's so great. So it's not only helping to refine the development effort for the better and find these opportunities for improvement, but it also can be a super confidence booster in terms of, wow, we're on the same page and the things that we're doing are going to make a difference.
And how cool is that? So we've got a few more questions. These are rapid fire. First thing that comes into your mind. Number one jimmies or no jimmies? Oh jimmies but I call them sprinkles. Most interesting client application you've worked on? I find dialysis to be a really interesting space. Or maybe not most interesting, but very impactful and fulfilling.
Because if you have renal disease and you have are in renal failure, you may need to go and do a dialysis treatment for several hours a day, like four days a week at a clinic. And it's super impactful. And people need to leave their jobs and spend time away from family.
So those technologies have been moving into the home steadily over the past many years, and I think that's a space where it feels really impactful to the user to enable them to not have their condition totally take over their lives. You've obviously presented at a gazillion different conferences worldwide. What's been your favorite place? I had the opportunity to travel to Japan in a couple of instances, and really enjoyed a lot of aspects of that. I was in Tokyo for a bit.
I was in some more like rural areas, and I really appreciated the level of like order and thought that goes into the design of most things there. Things are just orderly in a way that we don't experience so much in America. And I was also really lucky because for part of that, I was traveling with a colleague who is Japanese, who lives in Tokyo. And so that was a real treat because otherwise I think without Japanese language, you kind of miss some of the the off the beaten path places. And I did like how karaoke is kind of part of the professional context there, which is kind of fun. If you hadn't gotten into human factors,
what would you be doing in your career? What would I be doing? You know, it's funny because human factors I don't think anyone like is in, you know, growing up now, like, I want to be a human factors engineer, although maybe if some people play this podcast for their kids, I'll be raising future human factors engineers. I really appreciate well-organized, thoughtful things, which I think is why product design is appealing and like making things usable and intuitive. So maybe I'll be doing some organization business.
How far is the nearest Dunkin Donuts from where you are right now? Probably about four minutes, I think. I pass a couple on my eight minute drive between my office and this recording studio. So I would say 3 to 4 minutes, tops. Thanks so much for taking the time to listen to part one of our conversation with Allison Strochlic. Be sure to catch our next episode as we dive deeper into human machine interface and human factors.
If you'd like to expand your knowledge in this technology, The Tech Between Us podcast is just one piece of Mouser's in-depth look at this subject. Explore the entire Empowering Innovation Together technology series at mouser.com/empowering-innovation for technical articles, use cases and more.
2024-07-20 23:54
