What is a user need, and when should you start working on them? How can you figure out what the user truly needs – and by the way, do you know who the user is? These are some of the topics you’ll hear about in today’s episode.
Jesseca Lyons joins the podcast today to share more information about user needs. Jesseca is a Mechanical Engineer who’s spent most of her career gathering and defining requirements for new product design and development in the medical device industry.
During today’s conversation, you’ll learn more about how Jessica is thinking about challenges in getting to user needs, using Root Cause Analysis to get to true user needs, and determining who will be interacting with the medical device and which ones are users.
Watch the Video:
Listen now:
Like this episode? Subscribe today on iTunes or Spotify.
Some of the highlights of this episode include:
-
Themes that trip people up regarding user needs and how Jesseca helps them
-
Fears about problems during FDA inspections and 510k submissions
-
What Jesseca thinks of when she thinks of user needs
-
Guiding a customer through figuring out a user need
-
What makes it difficult to get to user needs
-
An example of a standalone design input
-
When to stop divergent thinking
-
More user needs pitfalls
-
Which people are users
Links:
Memorable quotes from Jesseca Lyons:
“Most of the time, our user needs aren’t really doing a good job of telling us what the user is actually looking for; what problem we’re trying to solve.”
“I always found it interesting that we were so willing to solve a problem before we really understood what the requirements were.”
“Anyone who comes in contact with your medical device could be a user.”
“Every fear is a legitimate fear.”
“Your design inputs shouldn’t be so restrictive that there’s only one right answer.”
Transcript:
Etienne Nichols: Hey Jessica, it's so good to have you to on the podcast. I'm, I, I'm always excited to talk to you no matter what we're talking about. But I'm especially excited to talk to you about, you know, the user needs that we want to talk to you about today.
But first I want to ask, well, how are you doing? And, and yeah, just how you doing?
I'm nervous, man.
My goodness. I made myself nervous talking to you before. Okay, go ahead.
Jesseca Lyons: No, you're good, you're good, you're good and I'm always happy to talk to you. I think we always have a lot of fun on our conversations, whether on Zoom or the occasion we get to actually meet in person.
Always fun to get a chance to reconnect, doing well. You know, this is one of those where that man, life gets busy as we go through all of this. And I swear I blink and 2022 is almost over.
Etienne Nichols: Yeah, I can't believe that Thanksgiving's coming up. I'm excited to see. I'm going to have to sneak over to your. The Slack channel and see the, the Thanksgiving questions that come up and then get to know you.
Friday questions.
Jesseca Lyons: Yes. No, those are always fun actually with, with everybody, with the office being closed for Thanksgiving, I'll have to do my get Friday question for Thanksgiving on Monday.
So, we'll have this Friday and then we'll have next Monday, but no one knows that yet, so keep that a secret.
Etienne Nichols: Okay. Okay. Well, we'll publish this after Thanksgiving, so there we go.
Okay. So, the thing that I wanted to talk to you about were user needs. And so, when I first started working in design controls, this is one of the areas that I didn't have a lot of interaction with.
I was, I was mostly design inputs guy design outputs and, and then we worked on verification. Whereas human factors was kind of like the bookend. User needs and design validation.
So, user needs though, I'm curious what your, what your opinion is on them and how to.
Maybe we'll talk about how to get into them first. But just when you think user needs, what pops into your mind?
Jesseca Lyons: I think most people, when we talk user needs have a love hate relationship with them or want to leave them to someone else.
I guess one of the things that I really struggle with, having spent six years plus now at this point, reviewing other people's, I mean it's always easier to review other people's user needs and design inputs is that most of the time our user needs aren't really doing a good job of telling us what the user is actually looking for, what problem we're trying to solve.
Most of the time they come in after the fact and they are where we're going to go in and we're going to say, here's what the engineer wants to do.
So, they're very super technical. If you've seen some of these user needs, or my favorite, they're made up because we feel obligated to have them. So, if you have a user need where it's safe and effective.
Yeah, it's one of the user needs that I hate the most. But one of the things that I found is that everybody just doesn't know what to do with them.
So again, we're either talking engineering and we're super technical in our user need, or they're not really describing the problem that we're solving and they're just kind of super vague there because we feel this, this obligation.
Etienne Nichols: Why do you think.
Well, why do you think that it is one of those love hate relationships? I mean, like you said, they can be kind of difficult to ascertain. But what are some things we could do to make it easier to, to get to those user needs?
Jesseca Lyons: Well, I think one of the things is that sometimes we don't know who owns them.
I mean, like in your past life, like who owned user needs? You said human factors.
Did marketing help with it? Did, did you help with it? Did it?
Etienne Nichols: Well, it was a fight high above. It was product development. Well, I don't, you know, it was, it was a fight between product development and human factors. Honestly.
Jesseca Lyons: Yeah, that's the thing. It's like no one knows who really owns it. Right? Like, so if you're not responsible for it, and I'm not responsible for it now, when you fought, did you fought to take over or did you fight to get out?
Of?
Etienne Nichols: Good question.
It was a little bit of both, mostly kind of.
Well, it's always a looking forward into the future. Okay, if you do that, how are my design inputs are going or will, how will they be affected and so forth.
So, I think it was a little bit of future proofing is, is why we wanted to take ownership or not take ownership in certain cases.
So that said, who, who do you think?
What would be an ideal situation in your mind as far as who owns.
Jesseca Lyons: That well, in an ideal world, it wouldn't be just one group, it would be more than one group. So marketing, they're talking to your customers, right?
Sales, they talk to potential customers, maybe customer success, maybe they talk to your customers.
You get somebody who's a representative who deals with, you know, all of the constant conversations and complaints about what your med device does or doesn't do.
And you get all of these different people who are going to hear different sides of the story.
Maybe you get a sales rep who has a fantastic relationship with an end user and that end user is telling you everything about what they would love to see.
But if engineering owns it or if human factors owns it, you might miss out on some of that information.
Now obviously we have our customer feedback process. Right. Let's not discount that. Maybe that's done really well.
But we don't always get that in certain teams and in certain companies’ kind of shaping the future. Or the device has been never made before. So, it's not like we have customer feedback on.
We'd love it if you improved this.
Etienne Nichols: Yeah, that's a really good point. And I guess when I think of user needs, it is, I don't know, I guess there are those two different paths. You may have a device that's already been built and you're making a version 2, but I guess just my product development mind thinks, okay, well we're doing this from scratch, which is the exciting way to do it.
Yeah, having multiple people own it makes a lot of sense.
And that cross functional teamwork, you know, you can't hardly get away from that really. I don't know how you could, honestly.
Jesseca Lyons: When it comes to user needs.
Unless your product development engineer is going out there and talking to everybody, is, you know, able to connect with all of your customers and maybe they've been afforded that opportunity, you know, maybe you've given that product development, the engineer, whoever is responsible for those activities.
Maybe you've given the ability to sit in with your sales team and kind of listen or you've got, you know, conversations where they can go listen to recordings or they can go to a conference and talk to people.
They're able to read the customer feedback if it's a next generation of a device or they're able to go talk to some of those user groups with your human factors.
Like unless you have one person who can really go out there and get information from all these different sources.
I think this is in part why people struggle with it.
Etienne Nichols: Another thing I would throw out there because you mentioned, you know, if, if a customer has these different features, they're talking to customer success, they have these different desires or things they'd like to see in the product.
The person listening, they might immediately be thinking, okay, yeah, we'll try to put that feature in or put this feature in. And they're not really in the right mindset. Because when I think of user needs, the mindset you need to be thinking of is, and correct me if I'm wrong, I'd love to hear your opinion on this, but you need to be thinking of the problem, not the solution.
Just what is the problem we're trying to solve.
Jesseca Lyons: Now that is probably the hardest thing that any of us face. I don't care whether it is figuring out user needs as we work on developing a new product, or this is going through and solving a kappa or a non-conformance. How many of us jump straight into a solution?
Yeah, like everybody, right? Like it's just that natural, oh, I know how to fix this.
We all, I mean, we're engineers, right? We want to fix the problem. So, we all jump in and we all try to find a solution.
And sometimes it's hard to back up. And when I'm listening to somebody talk, oh, you've got a problem, I know I could fix it this way. And so, we're instantly, even in conversations with, you know, personal conversations, you're, you're trying to fix the problem, you know, trying to go in and solve it for them as opposed to sometimes listening to what is the real problem, you know, what is it that you're struggling with? What is it that you're facing as you go through this?
I think this is something where all of us, as we learn to be better listeners throughout our careers, we can really find that we view user needs differently. I mean, I certainly view them differently from when I first started versus where I am now.
I think that that's part of that challenge. To your point of am I viewing my user needs as I'm finding the solution? And what I really want to do is start to shape that solution.
And I'm going to say I have these user needs because I know the answer, or am I viewing them as an opportunity to solve the problem in a different way and really sitting there and listening to what is it that people are struggling with?
Etienne Nichols: Yeah, and I almost wonder. So, if you're about to tackle user needs, you don't want to forget about the upstream thoughts of intended use, indications for use, because that drives a lot of that.
And that the reason that popped into my Mind was when I was thinking, okay, you want to be kind of divergent thinking. You want to be thinking of all the different problems that.
That this person is coming at me with. So, I can really work through those.
How do you.
How do you know when to stop and to. To say, okay, we're. Now the scope is just creeping like crazy. It's wide open. How do you know when to stop that.
That divergent thinking?
Jesseca Lyons: So, for me, oddly enough, I kind of found my answer through a college course, so had a course in college. And part of it was understanding design controls. And one of the things that we had to understand were user needs, right?
And one of the things that they asked us to do is come up with user needs, come up with these requirements for a theme park and for like, but by asking kids.
So, we actually went to a local elementary school.
We got to talk to the kids. If we could come up with, you know, theme park was one option. They were looking at a museum exhibit. Like, if you could come in and you could come up with an idea for this museum exhibit, for a children's museum, what do you want? What do you want to see? And so, we actually got to talk to elementary school kids about what would make a good children's exhibit in their mind.
So, as we're coming in and we're listening to all of their user needs from the point of view of a child who would engage with it. So, here's our user.
Here's.
If you have ever asked, and you may have asked what it is that a. A kid would want, you know, at this point, they were elementary school, fourth or fifth graders, what they would want from anything.
They come up with more answers than you could possibly imagine on the spot. We had playgrounds and things to play with, topics we wanted to learn about. The following top.
They. They had everything.
And it was overwhelming. It was like, incredibly overwhelming. And we just sat here just as all of this stuff, like, kind of just came in from topics and the way to implement it and ideas on what they'd want to see or things that they hated when they would go into museums, and they didn't want to remotely have in this next one.
It was intense.
And I realized very quickly that as we were going through this, that we could continue to ask questions and learn more for, like, years at this point, like, we could ask this same question and they would talk on this for years, or we could listen.
When we started hearing the same theme more than once, we could decide to tackle that one theme.
And as we spent hours Listening to these fourth and fifth graders talk, everybody kept dancing around like two themes.
Don't ask me to remember what these themes were at this point. It was a long enough time ago. Okay, I know, I know my memory is good, but not that good.
All I remember is that we really just like started to have two themes that, that came out in terms of what these users, what they wanted, what they needed.
And I realized at that point that it was time to stop.
Because if we had these two distinct themes coming out with lots of people, we were Talking at least 30 to 60 people, multiple classes, that we had done a good enough job to get a first pass of something that would be valuable for multiple users. And at that point we could always have a next generation, we could always iterate it, but those two themes would give us enough to start with.
And so that's what I, I took with me. It stuck with me to this day that I listen for themes and I don't listen for, you know, oh, I'm going to solve this problem in this way.
I listen for what kind of a theme do you have?
And am I seeing that same theme repeated?
And you might want to, I mean, as a user you might come in with ways, I want you to solve it, but if you come back to that theme, then I know that I've hit on something.
If those themes aren't getting repeated, I maybe haven't asked the right questions, maybe I haven't figured out the exact issue.
But if I start to see the same theme over and over and over again and everybody, I talk to has the same thing, but maybe slight variations on it, then I know I'm onto something.
Then I know I should stop and I know I should work on that problem first.
Etienne Nichols: That's very cool.
You gave me a lot of different thoughts, so try to figure out which direction to go with that.
One of the things that it made me think of is, well, Steve Jobs pops in my mind. Not that I necessarily hold him up as a person, but his ability to see a user need when it might, or a problem to solve.
And when he held up the iPod and said, this is a thousand songs in your pocket, that's the thing he wanted to solve is the music and so forth. But what it made me think of was how many of those user needs can you really fulfill if you think about those themes?
I guess it's kind of like thinking of an EPIC for a software device.
I think that's a great correlation, at least for me, for me to help me think about things. Because you might think there's lots of different epics for one system, but one in and of itself, that's the problem you really trying to solve.
And a device can be that way. You know, a device can be big enough to be an epic, I guess. I don't know.
Jesseca Lyons: A problem can be solved in many different ways.
And sometimes you can solve the problem with one small thing.
Sometimes solving that problem takes a lot of big things.
And so, I try to limit user needs because one user need has a way of growing exponentially into more design inputs than you can keep count of some days as you try to solve that problem, as you try to get a hold of all of the different facets.
And that's really what I look at from that design input standpoint is like, I'm going to get a hold of the different facets of this user need. And so, I try to keep my user needs a little bit more limited and a little bit more clear.
Etienne Nichols: So, when you work with a lot of customers, or I know you have in the past, and you're doing a lot of different things right now, what are some of the things or themes, I guess, when it comes to user needs that you see people tripping up on and how do you help them overcome those challenges?
Jesseca Lyons: One of the things that I saw earlier on was that many people, they held off on user needs until after they had gotten their prototype figured out because they didn't really know what it was that the user may need.
And I always found it interesting that we were so willing to solve a problem before we really understood what the requirements were.
But many of us are in that same place, right? Like, it's, oh, I want to make this device. And like, we know, I mean, at least for me in my career, similar to customers, their journey, I typically got, hey, this is what you're going to make, right? Like, as an engineer, that's what came to me.
And so, in some cases, the user needs were already taken for granted. We didn't always stop and go back and ask them. And so, then when we're coming and we're retroactively putting in some of these design inputs based off of what we ended up selecting as our prototype or our user needs even further, after the fact of having our prototype, it was hard to go back and put them in place. And so, then we really struggled with what our user needs are because we already had a device because we didn't know what we should put there.
So that's, that's what I saw early on.
Now, what I see more often than not is a lot of people put them in out of a sense of obligation.
They feel obligated to have a user need for every design input.
And that's, that's not the case. And it blows most people's minds when I say the regulations don't say that thou shalt have a user need for every single design input.
Your design input can stand alone.
And that, that makes most people uncomfortable. And I found a lot of people started creating user needs solely because they had a design input and they didn't know what to do with it.
Etienne Nichols: Yeah. And what's an example of a standalone design input?
Jesseca Lyons: Ooh. Okay. So, I love my design inputs. And so, when it comes to a design input, if I have something, a lot of the times my regulatory standards, they can be a standalone design input.
So, in terms of some of this, I.
There's a lot of things from the regulatory standards that I'm not going to put a user need in place. Now there are some where I might.
So, if I know that I'm making like a blood glucose meter, right? Like I'm going to have something, I'm going to have some electronics.
I know that I'm going to have maybe if it's portable and it's in my pocket, and I know that in order to do the reading, I have to have a display.
I know I'm going to have a battery. It's like, I know that some of the electrical safety requirements are going to come because I wanted something that was portable.
I wanted the display to be, you know, easy to read or backlit, to be able to read it in different.
So, like, I want to be able to see the display in different lighting conditions. So, like, there are certain user needs that may feed into electrical safety testing as a design input.
But for other things, just, just start with your design input. You know, if I want to go through and I want to pick on a couple, we talk about sterilization, right? So, I know that I'm going to have a sterility assurance level of 10 to the negative. Like, there are certain requirements here, right.
My user might be asking for something to be, you know, sterile, maybe, maybe not.
I mean, depending on what it is, I may choose to provide it sterile versus sterilizing it with like a steam sterilization method at like a doctor's office, dental.
So, in terms of some of that, I'm creating the requirements not my customer, not. Not my user.
So, there are certain design inputs there, some of those regulatory requirements where you might just Have a standard and you might not have a user need to feed into it.
Etienne Nichols: That makes sense. So, another question, just because of, I think about that supply chain aspect or logistics, can your users be maybe more than just the actual patient? You know, think of. I'm, I'm thinking of like let's say a good example, the scalpel, for lack of a better example, let's say a scalpel.
So, the doctor, maybe the doctor is the user, but like you said, maybe a nurse brings it to him. Oh, takes it out of the tray, maybe someone else puts it through the autoclave through reprocessing.
Are all of those people in your mind, the user or what are, what are your thoughts there?
Jesseca Lyons: Yeah, and sometimes that feels really broad.
Right. Like anyone who comes in contact with your medical device could be a user.
And you want to think about it from different points of view because how you design your packaging matters.
Like, packaging matters.
And packaging matters not just because you don't want your product to get destroyed by the time that it shows up where it's going to get used.
But if the nurse can't actually get that scalpel out for surgery, that's, that's a problem.
If the labeling, like if you can't read any of the information on that package by the time that you get it open again, that's a problem. Because now you're missing critical information.
If every time you go to open it, it drops on the floor and now you've got dirty product and you get again, depending on what it is that you're using it for, you've got to get it clean, you've got to get it sterilized like, or you got to get a new one.
I mean, packaging has a big impact and in some cases the amount of waste that you generate has a big impact because you've got a requirement around having a limited amount of waste for your medical device.
Even so we got to think about our user needs from a lot of different points of view to really do that job effectively.
Etienne Nichols: Yeah, that makes sense.
So, when you go back to the manufacturer standpoint, when they're going through those user needs, what are some things they should be thinking about? And you know, obviously the end use that the actual person in the field, design validation is another thing that they're going to be thinking about as well as design inputs.
What are the, those different threads to design inputs, design validation, what are some of the pitfalls that you see some manufacturers or designers getting into when they're, when they're designing those user needs or coming up with those user needs.
Jesseca Lyons: Hugh, you brought up design validation. I think that's probably the biggest pitfall that all of us, all of us face. We face it in design inputs with our design verifications as well.
Sometimes we forget early on that we're going to have to test it.
And sometimes as we're creating our user needs, we don't take a moment to pause and think about how we're going to be able to test this.
There are certain times where the way that we've worded it or the way that we've phrased it makes it really challenging for us to be able to go in and actually do a good design validation activity around it.
Are we thinking we're going to survey people? Are we thinking we're going to have a clinical trial? Are we thinking we're going to have simulated use in a cadaver lab?
You know, what is it that we're thinking about in terms of how we can go through and validate those user needs? And when we don't stop to take a few minutes to think about just high level, even what we want to do there, we find we pay the price on the back end because now suddenly it's time for our design validation activities.
And now we're in arguments of, well, I can't go do a cadaver lab. Like I've got a there, I can't get on the books, or the cost is more, because at this point, we've overrun the cost of the project, and I don't have the cost to be able to go through and do this.
I can't get doctors to come and participate in this. You know, I, I can't get representative end users to come and actually tell me how this device works, you know, how, what's their experience with it, or from a survey standpoint, people will write it in such a way that they think they're going to get everyone to agree.
And so, then they end up failing because they, they can't get all people to agree in terms of an answer on a survey question. I mean, we've seen commercials, four out of five dentists recommend this.
You know, not everyone agrees when it comes to user needs.
Etienne Nichols: Right.
And one other thing I'll just kind of throw out there is when we think about design validation, we think about that, you know, moment in time or series of actual tests.
But another interesting thing is, you know, as a design designer or manufacturer, when you have those user needs, one of the other things you can be doing is validating that you have the right user needs.
Anytime you interact with a doctor, any, a future user, so forth. So that validation, quote unquote, small V validation should be going all, all the time. I guess in, in my mind, yeah, yeah.
Jesseca Lyons: There is nothing worse than getting to the very end you've got this device done and like you think you're just like eyes dotted, T's cross. I'm getting ready to run and run my validation and I'm going to be done.
And you give it to people and they're like, man, you know what? It'd be really great if it had this instead it there. It just, it never fails. You know, I jokingly say, like I've.
You've read the children's books. If you give a mouse a cookie, it's. If you give a surgeon a tool, they're bound to ask for you. Give an engineer something, whatever it is. If you give someone something, we're bound to ask for more.
And sometimes that's because you've met the needs so well that they're going to ask you for something on top of it.
And that's fantastic. Like you met that user need so well that they're going to ask for one tiny tweak.
And other times you find out that what they were saying was the issue, saying, I want it to do this, I have to have it do this. You solved exactly what they wanted, but you didn't solve their problem.
And I think that that's sometimes where if you go and you're asking those questions all along, to your point, Etienne, like it just, you end up having a better product versus if you wait to the end and then ask.
Etienne Nichols: Yeah.
So, I've, I've seen you work with customers before where you have an exercise to help them figure out a user need. I wonder if you could just do that very quickly just so that we could have it for posterity.
Jesseca Lyons: Oh, man.
Etienne Nichols: Do you, do you have a thought in mind on how you could help someone when you're going through with a customer, how you could guide them? Okay, let's figure out a user need here.
Any thoughts?
Jesseca Lyons: So sometimes this is going to sound really strange. Sometimes it's a lot of just similar things that you use to a root cause analysis.
So, I tend to ask a lot of whys when we're going through like at the end of the day, right, we're solving a problem.
When we're making this med device, we're figuring out these user needs. So, I try to ask why.
So, I, I think you sat in on one where they were making a, a Physical, like instrument box, think like a toolbox.
And they were talking about that it had to lock and they were saying, you know, this, this has to have a lock on it.
We asked the question of why?
Well, because we don't want it to accidentally get opened.
Okay, why?
We just kept asking and at the end of that conversation, as we dug in, more about, okay, what is it that we're really looking for?
It turns out that they didn't want it to be locked to prevent somebody from, you know, breaking in and getting things out.
They wanted to prevent it from opening so that the tools didn't fall out of the instrument case in terms of like shipping, transport, like any, anything. They, they wanted the, the instruments to stay in the spot that they were in, not get moved around and jostled. So, at the end of the day, does it have to have a lock?
Yeah, no, the user, the user need didn't. The problem didn't have to get solved that way.
It was more about, hey, I gotta have a way to keep these instruments in place.
In this case, I need them to be able to not move around during transit.
That's a very different problem that we're trying to solve because instead of putting a lock on something, I guess I'm foam, I can get it cut out. Like, I can put these things in. Like, there's a lot of different ways that I can go in and I can solve it.
So more asking why, figuring out what the problem is, understanding those needs versus just kind of making some of the assumptions as I jump in and solve. So, I like to ask a lot of why’s.
Etienne Nichols: Yeah, I love your root cause analysis illustration.
Just as you were talking, you're thinking about it. My brain was, I'm guilty. I keep going to the solution. I'm like, oh, you could use a clasp, you could use a sliding lid. You know, there's all kinds of things you could do.
But yeah, you're right. Until you know the actual reason why you want to lock it, you know, quote, unquote, lock, you're not actually going to solve that problem.
Jesseca Lyons: So, yeah, I think one of the things that we've been working on and, and it's, it's funny because this, this ties in in so many different ways. We all frequently want to jump in and solve a problem and give you a solution.
And we've actually been working hard to understand more of like a…I'm going to create a hypothesis.
I think the problem is this.
Here's the reasons why I think this is the problem.
Here are the questions that I could ask in order to figure out is this the problem?
So, as you go through this before you propose a solution, do you have the right problem?
Do you actually understand?
So, I've never applied it to user needs, but as I start to think about it and I think about that framework, that's kind of what we've been doing.
Right. When we're asking why, when we're getting into the root, what is it that you're really looking for?
We're creating that hypothesis of I that you want this to do X, Y and Z. I think that because I've seen others who are. I've seen similar devices that have this feature, this feature and this feature in order to prevent this from happening.
Do you feel that if you had something to prevent access that you would be able to solve the problem so like you can look at it kind of in a similar framework, create a hypothesis, have your reasons and ask why?
Etienne Nichols: Yeah, I love that question. Because then once you have that hypothesis and you're supporting evidence, you can go back, like I said, with that mini that lowercase V validation, say, is this it?
And yeah, that's really good.
So, what other things or is there anything else that you would like to just kind of like hit on as far as user needs go, you know, any other pitfalls you see people getting into?
I know we covered quite a bit there.
Jesseca Lyons: Yeah.
I think this is the thing that I've seen a mix of people either do really, really well or people really struggle with is being too technical.
We tend to engineer our user needs.
Like if you read the user need, there's a lot of like engineering speak.
Etienne Nichols: We backed into it, kind of.
Jesseca Lyons: We did, we backed into it. And phrasing our user needs in a way that is more relatable to the end user is I think one of the things that I would encourage people to do.
Because then one to your point, it's easier to mini little V validate than when you're talking to somebody.
And it becomes easier to create those formal validation activities. Because if I understood my user need in such a way that I've stated it where everyone gets it, I can create a survey maybe a little bit easier because now I have the exact questions that I'm, I'm looking for.
Or I could craft the, the way that I'm going to do maybe a cadaver lab, because I know what I'm, I'm looking for as maybe I get in my human factors friends and I have them, you know, watch that procedure and I maybe I even change how I write my user or my IFU, my instructions for my users, based off of what it is that I'm trying to solve, to make sure that I'm guiding them in a certain way.
So, I think if we, if we stop engineering our user needs and focus our engineering and our design inputs, and we allow our user needs to be more relatable to the end user, maybe we'll start to turn the tide there.
Etienne Nichols: So, I'm, while you were talking, I was thinking, why would someone make it that way? And I think there might be a fear of, well, maybe the FDA or whatever agency you're submitting your, your submission to do. It needs to be, it needs to be serious, it needs to be, you know, all this sort of thing. Is that a legitimate fear when you talk about or is, or how do you ride the fence there with this relatable speak?
You know what I'm saying?
Jesseca Lyons: So, every, every fear is a legitimate fear, right? Like most of the time these are fears because we have experienced a problem during an FDA inspection during our 510(k) submission. What?
During our tech file, whatever it is, there's been a problem.
And sometimes because there's been a problem, we swing so far in the opposite direction to prevent there from ever being a problem again.
Because it just caused so much of a bottleneck somewhere that we don't ever want to repeat that. It was awful. We learned our lesson, not going to go through this again.
And I think there's also this degree of we, we want to be right, like, we want to be validated in, in what we're doing that we've, we've done a good job.
So, I get asked, is there a minimum number of user needs that we have to have?
Do I have enough user needs?
Did I put too many?
There is not an exact number that you have to have for your medical devices.
You know, there, you have to have something.
It has to come from, you know, your user needs. But there's no exact science to getting the right number, to getting the right phrasing.
A lot of it is kind of this weird gray area.
You want to be descriptive enough that you're able to understand the problem.
Not so technical that it's a design input versus a user need. You don't want to solve it right up the front and you're afraid of not being taken seriously if you don't phrase it in such a way that others are going to understand and relate to it, whether that's giving it to the FDA, being afraid that they're going to judge you for how you wrote your user needs.
Giving it to somebody from a human factor standpoint to work on a usability study and them not understanding the words you used. Now if we're throwing in thingamajiggies and what's it and whoseits and you know, doohickeys into the phrasing of our user needs, okay, we probably have some problems here.
But if we're talking about, you know, it, portable portability, pocket sized fit into a wallet, you know, there's a million and one ways that we can phrase something that resonates with our end user that isn't so technical as to say it needs to, you know, have certain modules of elasticity in terms of how it's going to stretch and fold and fit.
Etienne Nichols: Yeah, that makes sense. And one of the things that.
Just because we didn't touch too much on design inputs, I wanted to use that, that example of the kit like you were talking about. The.
I don't know what the specific user need might be with that kit, but maybe the, the components within the kit.
I'm going to a little bit of, of engineer speak, but the components of the kit must remain contained within the unit or something like that, whatever that.
Jesseca Lyons: That wise thing, making your user needs all. I mean, come on, we don't want to jostle around during shipment, right?
Etienne Nichols: Yeah, no jostling during shipment.
Jesseca Lyons: This is where we have the.
Was that too fuzzy versus the. I can't have the instrumentation.
What have a deflection of. I mean what you got incredibly technical.
Oh man.
Etienne Nichols: Jessica always calls me out.
Jesseca Lyons: This is the hard part, right? Like this is really hard.
Etienne Nichols: So. But once you get that, I mean, you're right. I'm not negating that at all because you're right. And when you call me out, I, I love it because I always grow.
So that one part. So, if we don't want it to jostle during shipment, you go to your design input. Like I said. When, when we're talking about what that design input could be, some people may question, well, how do I come up with a design input for that? And it could be as simple as, you know, it needs a clasp or the.
Now you're defining how you're going to prevent the jostling during shipping.
Jesseca Lyons: You don't even necessarily have to do that.
Okay, this is the, this is the crazy part. There was a presentation that I sat in a few years ago. I wish I could remember the speaker because he did a fantastic job.
I will have to see if I can dig up this for you to share with the listeners. As part of it gave the absolute fantastic examples around even just a backpack on how to take the user needs and the design inputs and the design outputs.
We don't want to solve the problem yet necessarily from our design inputs. That's what our outputs are.
What is it that it needs?
So instead of talking about it has to have a class, what about how much distance it can move?
Etienne Nichols: Yeah.
Jesseca Lyons: So, if I have that thing and I don't want it to get jostled, how much can it move?
If I define how much it can move, whether I put it in foam or I have it magnetized in place, or I have a clasp or I have whatever it snaps into the plastic containers where, you know you've had to pull out all of these.
Etienne Nichols: Right.
Jesseca Lyons: We had a Magna tiles kit, and all of the Magna tile pieces snap into place in here. Like, whatever it is,
I don't have to solve it yet, but I have to know what my requirements are. Well, it can't move so far. Take those requirements and then let your design team design. Let them explore, let them figure out what it should look like.
Let them come up with different options. Your design inputs shouldn't be so restrictive as there's only one right answer.
Etienne Nichols: Yeah, that's good. That's good. Okay.
Jesseca Lyons: And I'm gonna have to look this speaker up because he gave the most wonderful example of this. It was. It was fantastic.
Etienne Nichols: Definitely. And if. If you're able to find it, we'll put that in the show notes and a link to that so that people can find it. That would be fantastic. Excellent.
Any last parting words or thoughts, advice on design controls in general or anything that you just, you know, might still be on your mind as far as this topic goes, I've already gotten a lot out of this. So, either way, I guess the only.
Jesseca Lyons: Thing is, like, reassurance that one. It's okay to struggle. Like, it's okay to your example earlier. Veer on the side of overly technical or, you know, solving the problem. Like, start to take some baby steps.
Try to not solve the problem in your user needs.
Try to not solve the problem in your design inputs. Necessarily figure out what it is that you really, truly need. Need here.
But it's okay to find it hard. It's okay to struggle. It's okay to worry about if you've phrased it the right way.
At the end of the day, as long as we're solving a problem, as long as we are meeting some kind of a user need. However, we phrased it, we've done good. I mean, this is at the point kind of what we're doing from a med device standpoint. Right? Trying to help people in this world, trying to do good.
Etienne Nichols: And hopefully if we have a cross functional team, they'll help us with that human centered communication as well.
Jesseca Lyons: Yeah, yeah.
Etienne Nichols: Excellent.
Jesseca Lyons: At the very least we can catch it on a design review.
Etienne Nichols: That's right. That's right. Awesome. Well, thank you so much, Jessica. I'll let you get back to the rest of your day. It's been great having you.
Jesseca Lyons: Always a pleasure to catch up.
Etienne Nichols: All right, we'll see you later.
Thanks for tuning in to the Global Medical Device Podcast. If you found value in today's conversation, please take a moment to rate, review and subscribe on your favorite podcast platform.
If you've got thoughts or questions, we'd love to hear from you, email us at podcast@greenlight.guru.
Stay Connected for more insights into the future of MedTech innovation. And if you're ready to take your product development to the next level. Visit us at www.greenlight guru. Until next time, keep innovating and improving the quality of life.
About the Global Medical Device Podcast:
The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.
