The Tech Between Us - Subscriber Only Bonus Content
The Tech Between Us
Human Machine Interface - Subscriber Edition
Raymond Yin
Welcome! You're listening to a subscriber-exclusive, mini-episode of The Tech Between Us. We've been chatting with Allison Strochlic, Senior Research Director for Emergo by UL, on Human Machine Interface and human factors. Today, we're focusing on the engineer and what human factor requirements should be considered in the design phase.
When you work with clients, or probably more so if they're coming to you later in the design cycle rather than upfront, what sorts of things are you seeing that they're missing over and over and over again? Is something that's consistently overlooked in the human factors design area?
Allison Strochlic
So, you kind of teed up the question in a nice way that gets to the point while asking a question, which is, yeah, it's usually that earlier stage work that's not being done. So, they're starting too late. Again, thinking about our clients in particular in medical and pharma, they're starting too late in thinking about their users and thinking about what products are currently on the market, what are the challenges people have with those products? There's really a lot of opportunity to move that earlier. And so, there are many companies that are like, well, we're going to design the next of this product. We're just going to base it on the previous one. We know what we're doing. But they're missing opportunities to innovate, potentially, by not first checking in with their users who use their product or a competitor's product and looking to say, hey, how's it going? What's challenging for you? What features would you like to see in your next product? Well, how could we make this easier for you? And so, it's this discovery phase where you're trying to identify where are the opportunities not only for design refinement for this next product, but also for innovation. And then one thing is, I've talked about it now earlier, is this usability testing activity, which involves bringing people in, having them basically test drive a product. That is something that I think companies are doing too late. So, what features do you maintain and what do you change or what do you add? But this test drive of products as they're being developed is a really valuable activity. And one thing is that you can really get a lot of insight with only a few people. So, it doesn't need to be this pause development, we're taking three months off, we've got to run this study. Just last week a client said, “I want to get some more information on this.” They're designing a diabetes management desktop application for healthcare professionals to track their patients and people with diabetes and their metrics, blood glucose, insulin doses, et cetera. And they're like, you know what? We're trying to prioritize features for the next release of this software. We want some more data points. We want to get it from people in different parts of the country and just see what they prioritize from a feature perspective. And within a week we had conducted 20 additional remote interviews sharing a screen and got them really clear indications on where to prioritize. And in some cases, it confirmed their assumptions, and in other cases, it actually brought to the surface areas that our client didn't realize were as important as that they actually were.
You can get valuable insight in a week. You can get a valuable insight from five people, and it doesn't take that long. And so, we see many clients waiting until it's too late to make changes to the design, in which case you're really missing those opportunities.
Raymond Yin
Yeah, I mean that's interesting. Use it as a learning experience to better your own product. We all do analysis. I think every company does that, but to do it to that level of depth and that level of research is, I bet that provides some really interesting results.
Allison Strochlic
I think it does because if you, of course, you have your typical matrix where you're looking at the products and what features do they have and where are gaps and where are differentiators, all of that desktop analysis is of course valuable. But if you put it in front of people, you can see if it's easy to use or not, what goes well or not, and then ask the users, what do you want in this thing? What's missing that you like or don't like? Which you can't tell based on specs available on the internet.
Raymond Yin
Yeah, if they use resume or continue.
Allison Strochlic
Yeah, exactly. You wouldn't know that.
Raymond Yin
That to me is brilliant. Once again, I've been part of product design teams. What we do is bring them in and tear them apart rather than bring them in and actually use them.
Allison Strochlic
Yeah. But I've never read that word as résumé because of the context I had and the involvement in the design. And there are a bunch of stories like that that I won't take up all of our time together telling them, but I'll give one other example if you don't mind.
Raymond Yin
Okay, sure. Absolutely!
Allison Strochlic
We had a client who was developing an on-body injection device. So there's an adhesive liner you pull off and it's prefilled with medication. You put it on your body, there's a little needle that drops in a cannula, and so you're getting medication through this thing that's sitting on your body. You wear it for three days at a time, and then it needs to tell you either when the reservoir of medication is low or when the battery's dying and you need to replace it, or just in general when that 72 hours has elapsed.
Raymond Yin
Sure. Right.
Allison Strochlic
And there was a sound, we were doing a usability study, evaluating if users could detect and interpret the different sounds this thing put out. It didn't have a digital user interface, wasn't connected with an app, so needed to rely on these audible tones to be able to communicate what's needed. And we ran a study with maybe 12 or 15 people. It wasn't huge, and there were multiple participants who could not hear the tone. So we had people put this on their body, no needle, no medication, but we had a device that was designed to sound within a few minutes to simulate this and it was under their shirt. And I, as a moderator, would start a discussion. We would be chatting, and I would be waiting for you, Raymond, to say, “oh, something's beeping, should I do something about that?” And I was just chatting, weather, movies, whatever with this person. And I was hearing it. He was not. So, I let it go for a couple minutes just to see, because we wouldn't want to test it out in a room as quiet as the one I'm in, because that's not real life. If you're at a cafe or at the supermarket or in a meeting, are you going to hear this thing? And it turns out that the frequency level of this sound was too high for some individuals to hear. And in particular, older males, may have presbycusis or high frequency hearing loss, and it was too high pitched. And so, this one gentleman and others didn't hear it. And so, the client then knew to redesign that and lower the frequency and make that a more audible tone. But that was something that if it meets the standards and that frequency was okay, they may not have known that could be an issue in the field.
Raymond Yin
That's interesting. Yeah. Once again, I would've thought it would've been all about the loudness. Like, is this loud enough?
Allison Strochlic
Yeah, it's also the frequency.
Raymond Yin
Yeah, that’s interesting.
Allison Strochlic
But one thing about human factors that I love is that our team sometimes teaches human factors workshops. So, we go into companies, and we talk for one or two or three days about human factors and how to apply it to their development effort and the regulatory piece and the commercial piece. And we try to bring in all these real-life examples because what we want to do is not turn everyone into a critic. I go places, I use products and I'm like, oh, I don't like this or, wow, I really appreciate this good design, right? It's two sided, I'm not just a critic, but I also value and recognize good design. But there are things that we interact with every day, some of which provide a delightful user experience and we can use them safely and effectively. And others that are abominable, but we use them anyway because we have to or because we think we have to because we're used to it, and we've accommodated the idiosyncrasies of having to reset our coffee pot time where every time there's a power outage.
Raymond Yin
Like you said, we've gotten used to it.
Allison Strochlic
We've gotten used to it, right! But I'm renting a car right now; my car is in the shop. So, I'm used to a shifter in the center column or up here that it's like a stick or a something, but this is a dial and it's right underneath the stereo. And on the first day driving this rental car, which I've had it for about a week, unfortunately. I touched that knob and before turning it, I glanced over and realized I was about to downshift instead of change the volume on the stereo. They were both knobs. One was bigger, one had a slightly different texture, but they were right next to each other. And, because I'm such a nerd, I took a picture and posted it to my team who then all validated my frustration and how I thought this was a really poor design that I could shift from D to L when I'm trying to increase the stereo volume.
And there's actually a lot of cases around shifter design. Turns out when I was sharing this with my former automotive focus colleague about shifter design and where do you put them and how do you avoid that? And I think a rental car is actually a really interesting kind stress case for product design because you're in a car for a day, three days, a week, and you’ve got to learn how to use it. And I remember years ago when I first got a rental car I'd never used before. It was a hybrid. At the time, and there was reverse and neutral and drive all in one place, but I couldn't find the parking control. And I was pulling up to exit the garage and park the car and show them my agreement and my license and I couldn't park the thing. And the parking button was separate, and it was a different kind of control. And I was like, well, that's weird. These controls all go together. It's about what gear I'm in, why is that separate? But that's really a worst-case scenario where you have someone step in, there's no orientation, you've potentially never seen this car before, and now you have to use this key piece of equipment, safely.
Raymond Yin
Right. And if you misuse it, bad things can happen.
Allison Strochlic
Correct. So that's my recent real-life example of poor user interface design, not leading to an issue because I checked it, but multiple times my hand went to the wrong dial. And that's not great.
Raymond Yin
Oh my gosh, yeah. And for me, for a while, I was traveling quite a bit and getting rental cars literally every other week. And I would always try to get the same one or at least the same brand over and over and over again just because I got tired of trying to figure out how to turn on the lights at night.
Allison Strochlic
And then you can apply the learnings and you can improve over time, and you can get used to it and what have you. But if every week you're in some new vehicle - and where's the USB and how do I put on CarPlay and whatever, it can be tiring and lead to mistakes that could be problematic.
Raymond Yin
We've talked a lot about how OEMs...what they should be doing. Can you offer some best practices for companies who are looking to truly improve their human factors design? In other words, how should their marketing teams, their engineering teams, their design teams. How should they work together?
Allison Strochlic
There's certainly a lot of collaboration that comes into play when developing a product. And so, it's everyone working together and there's design, there's clinical, there's quality, there's human factors, engineering. And so, product development has to be a team sport. What can be tricky about a human factors function is especially as a consultant, but even internally, you don't necessarily own any part of the design. You're not necessarily the end decision maker. And so, there are times, even when companies do have human factors folks internally, that those human factors folks are not on the core list for a design review, for example, or they're not necessarily in mind at all the stages where we can add value. And so, there's a lot of influence that comes along with being a human factors engineer, especially internally, to make sure that you're invited to the party and to make sure that you're listening, you're at these stakeholder meetings and you're saying, hey, I'd like to come to that. I can give input to that. And making sure that your voice is heard.
Because as a human factors engineer, you want to make sure that you're having that impact and that you're working with others in marketing and clinical to understand who the users are, what the product should be doing, but not trying to serve in all the functions. So, for example, clinical is so important when it comes to product development and human factors because you need to understand what the relative risk is of people doing something incorrectly or a mistake someone might make. And so, I don't know how bad it is if someone under doses once under doses twice, what about this amount or what about that amount? Or what if, I don't know that, which is why I need to have a clinical counterpart to help with this - in particular, this use-related risk analysis we spoke about earlier to make sure that they're aware of that, I'm aware and they're aware of what those risks are.
And so, the other thing is related to, just as an example, running these usability tests. Our team may run a test collect, capture a lot of feedback. They want something to be lighter weight, but oh, what does that do about the battery level? What are the constraints? And so, you need R&D individuals to be able to comment on what's technically feasible and not, and then have an informed trade-off discussion between all these stakeholders on how do we take these learnings, what's feasible versus not from a design refinement perspective, and how do you manage priorities? Cost, timelines, technical feasibility, that type of thing. So, it certainly is super collaborative, and you need really multiple teams to work together. The structure of those teams might vary - is clinical separate from quality or together? Is designed maybe with human factors or separate? But then you've got regulatory, you need these people to be working together to lead to a successful development effort.
Raymond Yin
Okay. Yeah. And once again, from a medical perspective, all these groups are in place and whether they talk to each other, I'm sure you've seen all, the whole spectrum of everything. Now, would you say, going back to some of these other industries, would you say more the consumer companies just tend to make a bunch of assumptions and they just kind of go through? Or do you think that there really is a best practice they can really adopt as well?
Allison Strochlic
I'm not 100% sure to be honest, because I've never worked internally in a consumer company or on that many consumer development efforts. I do think that, again, because of that competitiveness in the market, that there is more done, more consistently when it comes to human factors or user-centered design. But I can't really speak to the extent to which there is the most effective collaboration versus not.
Raymond Yin
So, Allison, Mouser's core customer is that electrical design engineer and a lot of the content that we create is for them. What advice would you give a design engineer on how to take human factors into consideration even without a human factors team within their company?
Allison Strochlic
Yeah, thank you for asking that because I do want people to walk away from this nice discussion we've had - hopefully with being entertained slightly, but also with some key takeaways. So, I'll share a few things. One is that something is always better than nothing. So, what we sometimes hear is like, “oh, we don't have time,” “we don't have budget.” You asked that question earlier, does human factors slow down or ultimately accelerate the process? And we say overall, the latter - opportunity to accelerate. But something is better than nothing. So, if you don't have time to do a big fancy study, bring in five people, bring in three. Worst case, if they have to be your family or your friends do that too. But ideally, they're representative users of whatever product you're developing and bring them in, ask them some questions, have them try using the thing, do the things they want to accomplish, and see how it goes. So, we still see a tendency by some organizations to shy away because they can't do something more formally or more officially. But don't let the perfect be the enemy of the good, right? Don't miss out on any user feedback just because you fear you don't have enough to do a big event.
Raymond Yin
So, every little bit helps?
Allison Strochlic
Every little bit helps. Every little bit helps. And if a client comes to us and says, well, this is my budget, I could either do one 30-person study or I could do three 10-person studies, just as an example. I'm not sure everyone's ever asked me that specific of a question, but I would always say do the more iterative approach, right? So, we talked about human factors being iterative. Don't have a single point in time where you're getting info from 30 people. You're going to start to see an asymptote in terms of what your return on investment is. You're going to want to do fewer, smaller rounds to iterate. So, you do a round of 10 or five, make some changes and then bring it back up to some different people and do that iteratively.
A couple other quick tidbits, make sure you step back and take a system level view. So, you might be working on a component of something that fits into a broader system, but make sure you understand what that system is and then make sure you're working with others collaboratively like we just covered, to make sure that your part of it is going to work with the other parts. And then related to that system level thinking, try to think about or think your customer or end user. So, we talked about empathy as that skill - and think about, try to take a step back and think about how does this person use this thing? Maybe even go watch some YouTube videos on someone trying to program an insulin pump. Just see what that's like for them. Try and make sure that you're connecting what you're doing to the user because, of course, what you're designing is going to impact the user and enable them to hopefully use what's a great product that is safe and usable and all these wonderful things. But make sure you don't forget about those people. Because think about how they'll use it, where they'll use it, what tasks they're trying to accomplish, what are their goals because you're part of making that successful. And so, just make sure you keep them in mind so you have the context of how this thing you're designing will be used.
Raymond Yin
That's great advice. Thank you.
We hope you've enjoyed this episode of The Tech Between Us. Continue to follow Mouser for more exclusive content made just for you. Be sure to explore all of our Human Machine Interface offering, including articles, videos, podcasts, and more by visiting mouser.com/empowering-innovation.