Episode 2: User Centered by Design

Alex Thirren: [00:00:00] Welcome to user centered by design a podcast where we talk about all things related to user centered design.

Kelly Catale: [00:00:16] In this podcast, we focus on topics in the medical device development realm, but the principles we discussed can absolutely be applied to other industries as well.

Alex Thirren: [00:00:26] I’m Alex Terrian, the director of user centered design at sunrise labs.

I’m Kelly

Kelly Catale: [00:00:32] Kitale, principal, human factors engineer,

Nicole Kelly: [00:00:34] and I’m Nicole Kelly UX UI designer. In today’s episode, we will take a closer look at user center design as a whole, what it is and how the disciplines within UCB work together and how a team can benefit from utilizing one.

Kelly Catale: [00:00:49] In the first episode of this show, we talked a little bit about what is user centered design and how you can best leverage your user centered design consultants and services to serve the needs of your team.

And today we’re actually going to take a step back and really explore the topic of user centered design as a whole, and the value of it from a more holistic perspective.

Alex Thirren: [00:01:14] At sunrise labs, user centered design means really focusing on a systems thinking approach to defining the experience of the entire product.

When we think about what a user centered design team can do, it really means that we’re ensuring the system is safe, effective, but also delightful. And that requires a blend of skill sets. We believe it’s important to have a blend of skillsets to get the right outcome and to get the right experience.

And that means thinking about things from a holistic point of view, where you’re considering the digital, the physical, as well as the human psychology of what’s going on in the product at any moment. So when we talk about the components that are in our team, certainly the approach that we have, it means that we’ve brought in industrial design, user experience and user interface, design, and human factors, engineering.

Kelly, tell us a little bit about what you think it means from a human factors, engineering perspective. What is a human factors engineer? What do they do on the team?

Kelly Catale: [00:02:18] Human factors. Engineering is the discipline. That’s focused on optimizing a user interface to meet the needs, whether that be capabilities or limitations of our users, and also focused around making sure that we’re considering the use environment.

And a lot of that is rooted in risk because we’re working in medical device realm and there’s risk management, there’s understanding requirements and our user needs. And helping to develop a system that’s easy and safe to use from the perspective of the potential end users and the way that the device is intended to be used.

And a lot of what we do is very systems level thinking and keeping a focus on the entire product. So we think about user interface as more of a holistic piece of everything that the user touches and not just maybe one component. And that’s something that human factors engineer has to keep in mind throughout an entire product development process.

Tell me, what does that look like on a day to day basis? Like when you’re on a project, what do, what do people see from you on a regular basis? Like, what are you show up to the morning scrum with, or what are you, what are you doing to, to bring some of that activity to the people you’re working with throughout the process?

I probably pop my head in every day with something new. There’s. A lot that a human factors engineer touches at the beginning. It might be helping to develop user needs and understanding our users. There might be some generative research that goes on maybe going and observing users or potentially doing some interviews and understanding the perspective of our potential and users. And then translating those in a way that our development team can understand.

Nicole Kelly: [00:04:15] I mean, I definitely think it’s a huge benefit to have a human factors engineer on a team, especially for medical product development. Because especially when you’re with the UX UI, there’s a ton of different factors there.

Cause it’s a very broad spectrum of tasks. You do have the user experience side, but you do have the user interface side. So having a human factors engineer to kind of do that very fundamental, you know, re user research user requirements and have that trickle through throughout the process, I think is so beneficial.

Because it helps inform the people who are working on the product, not just within the UC team and helps inform everybody at all levels. And it can help streamline a process so that we’re not, we don’t get stuck in any which way, or, you know, we’re always thinking about the user first, which is what I hope to encompass when I’m doing my part of the job, the UX UI department.

But I do, I think it’s really beneficial.

Kelly Catale: [00:05:09] Alex. How about you talk to us about industrial design? Sure.

Alex Thirren: [00:05:13] Industrial design. There’s a lot of aspects of this. There’s certainly the aesthetic part of it. That’s a common point that we touch on, but so much of it really is about shaping the user experience through form and sculpture and the physical being of the product in a user’s world.

Certainly a lot of that comes back to aesthetics, but it’s also very architectural. We have to think about the placement of these objects in a person’s life and how they are suitable to the environment that they’re working in and how they make sense there. If it’s a product that you’re going to use in a certain way, let’s say you’re building a house.

The appearance and the physicality of it has to appear appropriate to that type of environment. And what you’re trying to do with the object, we’re building tools for people. At the same time when we start talking about med tech, is this a product that communicates robustness and that it can be used in everyday life in an aggressive way.

It’s going to hold up to the wear and tear of what a user might do. Like an infusion pump, a wearable infusion pump. It has to be durable. It has to communicate that to the end user at the same time. The form language, the design of it could communicate that this is a product that needs to live in the home and it’s more delicate and it’s, it’s gotta be treated with care.

And again, you, you would design it differently to respond to that need industrial design is about taking physical objects and make it very clear to an end user. What is appropriate for this object, how it should be used and where it should live. So that. It fits into people’s lives. And that’s an important part of what industrial design is bringing to this user centered design approach.

So, Nicole, why don’t you tell us a little bit more about how UX UI contributes to this conversation?

Nicole Kelly: [00:07:06] Okay, well, first off UX UI design is a bit of an umbrella term UX user experience. And then the UI part user interface. When you start thinking about them together and how they group UX designers consider more of the, the why, what and how to use the product, why the motivations and values the user may have the, what functionality.

And features of the product and then how accessibility and the aesthetics normally within this space, definitely within medical device development too. It’s a little bit different and can be categorized differently depending on what field you’re in UX design is definitely a big umbrella term with multiple things underneath it.

The tasks can vary, you know, you often have. User research, creating personas, designing wireframes interactive, prototypes, and testing the designs, working with the other teams, especially human factors. Getting that information really helps a lot within the medical device realm, but user interface design is the other side of that team, which is also a crucial subset of UX.

They both share the same end goal, which is to provide a positive experience for the user. Right? So making sure that color theory typography is well integrated within the thought process, as well as the fundamental design approaches such as the gestalt principles, which will help gain a deeper insight into how users perceive and interpret what they are going to be interacting with every day and every part of their life that really does tie up all ends of the spectrum within.

The realm of UX UI. So to make a long story short, they really can go over a multitude of segments within it, but it really does differ between company to company and place to place.

Kelly Catale: [00:08:52] Awesome. Great descriptions. Both of you, you might be thinking. Okay. Well now I know about the three disciplines that sunrise uses in their user centered design team.

How does this actually relate to traditional engineering and the disciplines that you might know exists? And what value can we. The UCD team provide to a project. We’ll be covering all those different topics today, but let’s first talk about the relationship to the traditional engineering disciplines.

We as a team, talk about this often and use this terminology. When we’re talking with our cohorts in the sunrise engineering company as a whole. I’ll start first saying that human factors engineering is really closely mapped to systems engineering. We think about requirements and user needs that help inform requirements and our design inputs in general.

And we really are system level thinkers. Really the whole ECD team is system level thinkers. And for us human factors engineering, creating that project plan and thinking about testing is. Closely integrated with a lot of the same type of documentation and work that our systems engineers do.

Alex Thirren: [00:10:06] As we think about some of the peer to peer relationships that industrial design and mechanical engineering generally are understood to go hand in hand.

And when you, when you think about that relationship, industrial design tends to bring a lot of the. The functionality of a device to the forefront and try and celebrate it and feature it in the design of the product. It helps users to understand what, what the function of the device is and how, how they might interact with it in a way that works for them.

There’s other parts it’s a bit too, in the craft of industrial design there, there’s working within the constraints of manufacturing. Done. Well, it really elevates the manufacturing process to something that is beautiful and something that a user desires and wants to have in their life as, as a product.

And it, a lot of times can feel like it serves the Juul of what they carry on them or carry into their lives.

Kelly Catale: [00:11:06] Uh, you know, as someone who’s not a designer, I see UX UI as mapping to software engineering, maybe just for the most obvious part, which is that. The designer is helping inform what’s going to be implemented by software engineers, but I’m sure there are other pieces they’re actually really much more fundamental or more important that help make that mapping even stronger.

When I

Nicole Kelly: [00:11:28] think of the engineering equivalents for UX UI, I would definitely think of software engineering because definitely we work hand in hand and benefit from each other in the same way, especially the UX part of. UX UI because a lot of the engineers at the beginning need to understand the user requirements and user needs, which kind of goes into human factors.

And again goes back to the systems level, thinking where the user is always the most crucial part of a project or product. That’s the UX part of it. The user interface side of things is more of user-facing. So you still need to do all of that backend research to make sure it supports the UI. At the end, when the user is actually interacting, you know, visually, physically with that product.

But when you’re talking about the user experience and the user interface, there’s also the hardware end of the spectrum and the physical form of the product itself.

Alex Thirren: [00:12:25] It’s interesting because a lot of times industrial design can be treated pretty reductively. So they, okay. Now we’re at the aesthetics of the product.

We’ve done all this, we’ve done all that. And now it’s time to apply the aesthetics and there’s certainly an approach and there’s work like that. That can be done. But design is so much more effective when we’re working from the DNA level upward. That the product is designed and architected to reflect the way the user will interact with it and the way that it will interact with the world around it.

And the context of use, I mean, that’s part of the richness of the way our team works. And one of the reasons why I like the way our team works is because no one can do any one thing. Right. Kelly having you bring the intelligence to the field for us, so that we’re understanding the context of use in a meaningful way and bringing a laser focus to the genitor of research and, and being deep in the problem space.

So we can fall in love with the problem space. Before we start committing to solution ideas. It’s really tough when you’re in the side of. Product development, where you’re conceiving it and creating and generating ideas to not immediately start converting from investigating the problem space into the solution space.

And I find in my own creative process, there, there’s all sorts of different designers out there. I happen to be what I am unapologetically. If I’m in the research mode, I have to commit to being in the research mode. I can’t be doing both at the same time. So I find that if I am trying to cover both research and design, I commit all sorts of sins of starting to get into solutions to problems before really understanding the problems.

And it’s, it’s something that having it a bit more separated in terms of roles and being in a support role when we’re doing the gender of research and really trying to understand things. But. Having somebody like yourself in there to help define it better and make sure that we’re, we’re falling in love with problems before we start falling in love with solutions is, is such a key thing.

And then it helps to then be able to translate that into physical experiences. What is the product and how does it. Reflect that it’s easy to just take a box and try and apply aesthetics to it. It’s so much harder to search, to try and pull through these abstract thoughts into something physical. And that translational exercise is really where I like the interplay between a holistic experience with.

What Nicole is bringing to the table from the UX UI side. And they’re sort of the UX ID side, you know, as it’s sort of, uh, an interesting way of thinking about it, there’s the user experience of the physical device too, but we have to work collaboratively for a, for a holistic picture of what we’re trying to achieve.

I like having a bigger team with deeper focus in each of these areas and that we’re so intermingled and practicing together. That was very well put.

Kelly Catale: [00:15:36] I can appreciate that, obviously in the position that I am working with, both of you in here, your experience and really deep knowledge about how to use your craft to improve the way that someone uses the product.

I think a lot of people who don’t under stand that, and aren’t immersed in that kind of interaction in a day to day basis. Think of design, whether it be industrial design or UX, UI design as make it pretty. And we often have to remind people that there’s a lot more depth into what you guys do. You really did describe it.

Well, so I’m glad because I think a lot of people could learn to appreciate the craft more than just the surface level that it might look like at the end of the day.

Nicole Kelly: [00:16:21] Well, that’s, I think that’s the common thing that people get caught up on, right? Because we do at the end of the day, look at things. We touch things.

If it’s a seamless experience, there’s no problems. That means we’ve done a good job. I think there’s that instance of, if you are not thinking that there’s a problem with something you’re interacting, if you look at it and it’s just a nice community, it’s a pretty screen. It’s, it’s a pretty product or a well designed product.

I mean, you did a good job. What they don’t sometimes always see is it’s definitely work to get there. You definitely need to do all this preliminary research and you have to ask the questions and you have to ask the hard questions. You have to ask why or think about all the problems that could happen within that before you can get to.

What we call the surface phase of what could look like that pretty quick here. So it is nice to, you know, have a team that focuses on all aspects of that as we understand each other, and we know how to get into that.

Kelly Catale: [00:17:20] That’s a really good point. I actually have heard that the simplest designs are the ones that take the most time.

That are the most challenging ones. So you can have a really, really simple design and on the surface, one might think, Oh, they just made that look nice. That’s pretty. But to get it to be a seamless, to your point, Nicole seamless, simple design takes a lot of thought and a lot of knowledge in the front end of development, to be able to make it, what if it comes out to be.

Alex Thirren: [00:17:51] Each of the elements that are left behind that still exist and survive sort of the editing process and the design. They’ve each got to handle multiple tasks at that point. And it’s funny because so much of great design is it is a filtering process. What makes it into the product? Oftentimes if, if it’s not thoughtful, if it’s not curated, if it’s not intentional, And what you’re eliminating as much as what you’re including.

It can become noisy and tough to follow. I think Nicole part of what I’ve loved about the work that you’ve been doing with me lately is the focus on white space. The, the attention to detail in what we’re, including from anything from instructions to use, to the, the amount of visual detail in the design of our products, because it brings focus to each area.

And it supports a lot of the usability goals that we have, but from a highly marketable sense of execution, you know, the execution is very tight. It’s very well followed through to, to the branding area, which I know is a particular interest in focus of yours, all these things interplay with each other.

They tend to support each other much more than we give it credit for. You know, there’s a lot of talk about. And almost low grade adversarial relationship between marketing and usability or marketing and human factors once we get into the regulated space. But I don’t think we’ve ever seen it that way. I know that that’s been a conversation I’ve had with each of you individually, but I think that’s an area where we certainly strive to achieve both.

And it’s a lot of that’s from stripping out detail and making sure that we’re reaching the right, the right balance of the amount of ingredients we’re including into whatever we’re baking.

Kelly Catale: [00:19:45] There’s also a really important piece. We’ve been talking about design and whether it’s the physical design or the graphical design, more screen design user experience, doesn’t end it just the product.

And that’s where a team that’s integrated that has all of their design focused user centered disciplines working in tandem can benefit a lot because we’re thinking about the full experience, which includes using the product, but it might also include any sort of instructions that come with the product or.

Packaging that comes with a product. And how does the branding align with all of those elements? And on top of that, how does training affect the way that someone uses it? And. A team that’s functioning well and is working in a way that considers all the disciplines simultaneously and is communicating well, should be able to tell, tackle that experience as a whole and think holistically of how the person at the end of the day is going to feel when immersed in whatever the full embodiment of the experiences.

Nicole Kelly: [00:20:55] I think there’s a huge importance for cross functionality within a company, or even within a product that you’re helping design as an art place. Sometimes, you know, when we take on products, but I think that’s a huge play into, you know, having that cross-functionality can help with like transfer fast transfer of information.

It really helps quick in our testing, you know, if we need to do something on the UX UI side, if we find. If there are findings from a usability study that Kelly has been doing, I can quickly take that feedback within the team because we’re so cross-functional and be able to rapidly produce a alteration to my design, to then quickly test it for another thing.

And there’s a lot of benefits from having the three of us in a team because we really do benefit from mostly all of our team. Some in other companies may not, but in our team, we definitely do have that whole systems level thinking where we’re, we’re always thinking about the user. We’re always thinking, how will this affect them and how will they interact with it?

And I think that’s very important within med tech, especially.

Alex Thirren: [00:22:03] It’s tough to separate out the ingredients to a successful product. It’s certainly an integrated team approach within a user centered design group. And that’s part of why I like the design of our team. It’s really difficult to be successful.

If human factors engineering doesn’t understand the intention of why something was designed a certain way, it could be. Misaligned in the testing, it could be misaligned in the intention. It could be misaligned in the understanding of what human capabilities are. There’s so many different permutations of how that could lead to a systemic failure of what the product might be come from either side.

And the integration means that there’s less over the wall, over the wall is kind of the death of a great product in, in my experience. And. Having an industrial design team that operates separately and in a silo from UX UI and the digital experience of a product, or is the focus on the controls and user interface also from either design speciality within our team, how those integrate with human factors engineering.

If you get separated there, you’re going to be set up for structural and systemic failure. I think that and extends beyond just the design of the product and the intention of the product into the execution of the product industrial design isn’t collaborating well with it’s peer to peer relationships in mechanical engineering.

We won’t see the pull through, into tooling, into manufacturer. What we had spent so many hours trying to refine and get just right in the material selection, the, the fabrication method, the true craft of, of industrial design. It, it becomes really difficult. I’m sure the same is true. I know the same is true across each of the peer groups within UCD with Nicole’s experience in UX UI, and.

Some of her experience that are with her peers and same with systems engineering and human factors. I don’t know if, either you want to want to share some of your thoughts there.

Kelly Catale: [00:24:25] Well, I know one thing that I’ve worked on that always seems to get tied up is risk management and being a medical device product that we might be working on just med tech in general, we are risk driven.

That’s the nature of the work that we do. And there is a special type of risk management process that is done to identify users and characterize, use related risks for a product and the mitigations that have to be put in place in the design of a product. Go beyond just. Design just surface design that you might think of.

It could be physical mitigations that are built into embedded hardware or into the design that a mechanical engineer might be working on. And the systems engineers really take that information as input to designing or defining the requirements. So I find that a lot of overlap that I’ve seen with our systems engineers is in defining requirements, understanding the architecture of systems.

So we can really characterize how we’re going to mitigate risk and then understanding how the risk falls in the whole profile of. Risk for an entire system. Cause there’s more than just use related risk. Of course there’s all the mechanical risks and electrical risks and maybe bio hazard risks, whatever the system is.

But there’s definitely a tie to systems engineering, a lot of different ways, even just, if you think about from the end goal, being that we have to run, assuming the risk. Demands that we have to run a validation study at the end. And that is part of the envy, right? Verification and validation, human factors.

Validation has to fit in there as well. And systems engineers really have to coordinate all of those details. And we work with them closely to make sure that we are aligning with their goals for

Alex Thirren: [00:26:12] the system. It’s interesting. How, if not well managed at that level, you can end up really separated on it at the architectural expectation.

Right? So even something as simple as Bluetooth technology, if we’re using Bluetooth low energy, for example, it’s, it’s optimized for burst transmissions, right? So if suddenly we’re expecting for a steady stream and a steady indication of, uh, status within the device. That technology may not support it.

And we may be in conflict with the fundamental architecture that we committed to long ago and can’t change anymore if we’re not progressing at the same pace and understanding each other well, so a

Kelly Catale: [00:26:51] good communication between the UCD team members and all of our peers in all the other departments means that we’re not going to be asking the design to break physics in any way.

It’s going to align with the way that the world works, but also the way that the system was intended and. If we have a finding from usability tests, like Nicole mentioned that does feed back into our design and it feeds back to all the other disciplines too. It doesn’t just stay within the UCD team. It goes to our electrical engineers and our systems, engineers and software mechanical.

And if we have recommendations, we’re not going to recommend something that makes absolutely no sense because we talk with them regularly. We interact with them regularly and we know what the limitations are. And we know where we can grow, where we can modify without asking them to move mountains, to be able to do it, or in a more realistic case, without asking them to rewrite lines and lines and line hundreds of lines of code, for example, but maybe there’s an easier way to fix something or an easier recommendation that meets everyone’s needs.

But I know that from a software perspective, there’s a lot, there could be a lot of potential. One might think there could be a lot of potential for flexibility, but their software can be. Kind of finicky when we’re suggesting different changes. And it’s why it’s really important for us to get in early and help with defining the architecture for our system.

Nicole Kelly: [00:28:17] It’s a huge benefit to be able to communicate sufficiently with software engineers, especially from the UX UI side of things, but you definitely need to have that open communication flow to make sure that. You spent all this time and the client wants to see these prototypes, these fast prototypes, these architectures of the navigational flow that they are expecting.

When you get to handing that off to your developers, your software engineers, you know, there’s a lot of backend work that has been done. So it’s really good to have that open flow of communication to make sure that things are getting implemented the way that they were intended to the way that. The MI the designer had designed them and shown the client and shown how the user was supposed to interact.

If there’s a disconnect between that in any way, it can cause a lot of scope problems with making sure that it’s like you said, if they need to keep adding lines of code, or if I design something that’s completely unfeasible for them, we need to be able to understand that too. I think there’s. A common misconception that it can just be a pretty picture because I’m definitely not thinking that it’s only that as of the UX side of things, the user experience side, you, you can’t just think linearly.

You need to be able to think and make sure that what you’re doing is going to be beneficial for the team while still keeping the user in mind. But you definitely need to be able to make sure that. It’s not going to break the product that you’re working on and it’s not going to break any software architectures that have already been created.

You need to fit, find a happy medium and fit between that spot while still not sacrificing the aesthetics for the user and the ease of use for them as well. So I think that, and that open communication flow with your software developers definitely keep that up, but I think that’s such a good benefit and such a good thing we have at sunrise is definitely.

Having that good communication and good teamwork with our engineers, because I think that allows us to be able to really think at the end that it is for the user and that we definitely are trying to make a product for them and work for them

Alex Thirren: [00:30:24] as well. I really like what you’re describing there because no pressure on you, Nicole.

But a lot of times when we’re doing a product, most of the assumptions that are. Misaligned most of the, the incorrect beliefs about the system 70 to 80% of those are showing up in the user interface. If we can get a good cut at the user interface, even as just wire frame flows, it pulls out so much of the differences between what.

The client marketing side, the client product owner, the client tech lead our own software, internal engineers, the system engineer revision of the architecture. Well, it’s the best. The ideas are great until you have the first prototype where everything just gets punched in the jaw. And, uh, there, there’s a certain amount of, if we can build a prototype of it quickly.

We’re going to fail faster. And so much of that comes out of the prototyping that you do in a system. And I love that about how we can operate at speed and how much that the healthy dynamic that we have with our software engineering team is this coming to the front in those situations, because they’re looking to you and they’re looking to our department for help to kind of bring to reality.

Bring to, to a full experience, everything that we’ve been talking about at a level that we can figure out how your version of it and the product owner’s version of it and the software version of it, where the gaps are. So we can rationalize between them and come to the right answer.

Nicole Kelly: [00:32:05] Yeah. You know, definitely connecting the broader development team with user experience is such a benefit.

You’re creating an environment where you’re building empathy for the clinician and the patient. And I think that’s so huge because then it helps set the tone for the engineering design decisions that maybe made prior to kickoff, even in some instances, but there’s literally the product we’re working on.

Right. And I feel like. What we’re doing right now on this project we’re working on, it’s really helping set the stage for the electrical engineers and the software engineers, because we need to think about. Where this person is going to be using this device and how they’re going to be carrying it around or holding it or using it.

And I think making empathy with the patient on that side, the user who’s going to be using the device every day, making sure the whole team is aware of that is so beneficial because then it helps make sure that everything works. As we’ve said before at a systems level approach, and we’re not forgetting any part of it, you know, we’re really making sure that the experience of the user is having is pleasant.

You know, we’re making sure that we’re not missing anything so that we’re making just the best product that we can for that users need

Alex Thirren: [00:33:17] there a certain amount of transactions between. The medical device and the patient, right? So they’ve the patient obviously wants to get, well, the device is there to help them achieve that goal, but there’s a transaction there how much you’re able to help their health outcome is a direct.

Correlation to how much you can ask of them to feed and care for your device and referencing the, the project that we’re on right now. So much of this, we just kicked this off is about focusing on how much we’re asking versus how much we’re giving and really making it clear. To the technical side about what that transaction balance is netting out right now and where that means we have less flexibility in some of the requirements that we’re forecasting, so size, weight portability of things.

Okay. Some of these goals are pretty challenging for getting the technology to fit a certain size and scale and appropriateness for the, for the individual wearing and carrying it. Some of that is pretty set in stone. If not, it needs to be more aggressive based on what we know of the transaction that we’re forecasting.

I see a, a ton in there about how we’re helping the engineers to understand what are the most pressing problems upfront and how far to go after them. And I appreciate that about what we’re getting to do here. It’s a fun part of the process. That’s very healthy. I

Kelly Catale: [00:34:50] think one thing that falls in alignment with what you both are talking about, but maybe even a little more fundamental.

Is when you build empathy with your team members. So you’re going through this exercise that you guys are talking about and all the technical team members, not just UCD, but now you have European and your mechanical electrical software engineers and their systems engineers, and they all are starting to understand the user’s perspective.

Which often doesn’t happen in a big team, in a big company, especially you’re going to have silos working independently. They come together for integration, but at the end of the day, they’re kind of stuck in their, their lane. When you have every team member really appreciating the user experience and their journey, it gives people purpose.

And I know right now we’ve been talking about the technical benefits, but. When someone from the team can say, okay, I know that this product is helping this population. You start to build a little bit more connection with that population. And you realize that the work that you’re doing on a day-to-day basis could feel mundane after months of work, because we know that medical device development is not a fast process and it can take some time and sometimes it’s tedious, but if you can help build that empathy.

Which the UCD team really can do and has done successfully for a lot of our projects. You then create the sense of purpose for the team and you can go back and call on them to say, Hey, it’s no longer designing your mechanical design or your electrical, whatever. It’s. It’s not personal. When I tell you that it’s not going to work, we’re talking about this.

Isn’t going to work for the user or your work right now is really meaningful. And you’re doing something really great for the end user. There’s a lot of value and a lot of unspoken value about that, that doesn’t necessarily pan out when you think of all the technical benefits, but it does have something that really draws the team, pulls the team together in a bonding almost way.

Alex Thirren: [00:37:02] And I, I liked the fact that it’s short circuiting, a potential conflict early through what is essentially a critique process. So with anything that we do, there’s, there’s sort of a critique process that exists. Other engineering, technical groups, generally call those design reviews. And if we can get in before that, And sort of share these empathetic elements of the project and help them to understand that the patient journey and the user journey, which can be different throughout the device that we’re developing or the system that we’re developing.

It. It does a couple of things. Number one, It democratizes creativity. If they’re aware of certain things and have empathy for the patient and the end user, they may make different decisions up front about the way that they’re envisioning a technical solution to a problem. Because they understand the problem space better back to our earlier part of the conversation and understanding and falling in love with the problem space before you get into solutions, asking the hard question.

Yeah, exactly. The, the inner six year old. Why? Why, why? But yes. But additionally, when we, when we get into the critique space where we’re criticizing our work and trying to find the best answer, it becomes less personal. It becomes more collaborative because we’re identifying opportunities to improve, as opposed to saying you just didn’t get it.

And here’s the thing that you didn’t know beforehand. And part of that is the other thing that we’ve been kind of pointing at within human factors engineering and about its integration. Into both the technical team, as well as the user centered design entity that, that we advocate for as a, as a structural element of an organization, not just at sunrise, but in most places it’s being integrated with the team means understanding the intent and understanding the intent is part of being able to.

Effectively critique what needs to change, because if you don’t understand and you don’t empathize with why decisions were made and it was just like, well, that’s wrong, you should do it differently. It’s tough to do that work and be effective at critique without falling in some level of love and trying to understand.

The sense of where the design was heading in the first place or the solution to the problem was heading in the first place. Cause this isn’t limited to a user centered design team. It’s the overall product reduced to the role of just being testing or just filling a consulting role into a team. Human factors.

Engineering often is constrained from what it’s able to be most effective at us, which is to understand and communicate with empathy, the needs of the user. So that we all can operate better. I think with, with the proper application of critique, we can really achieve that goal. Great.

Kelly Catale: [00:39:55] Actually, I was working on a project recently where I helped develop a journey map at the start of a project and it wasn’t the start start of the project.

So the project was still, uh, was already underway. There were teams of people already working toward a solution. And I had helped develop this journey map with the client, shared it with our team and had a lot of feedback from the technical team members saying, Oh gosh, I had to write new software requirements.

Or I had to write new requirements, system requirements because of things I learned through this process. And it was relatively simple and it helped build that empathy and helped build that trust with the team that. They were able to understand those details in a better way and understand the why behind some of the design requirements that the client had come to the table with.

Alex Thirren: [00:40:47] I like the good listing as part of that, because so much of that is facilitating what’s in the client’s head and getting it out onto paper in a meaningful way to help explain to the broader part of the team. And make sure that we were effectively listening to the client. I really love that part of the story.

Kelly Catale: [00:41:09] You sounded nerdy when you’re I love that part.

Nicole Kelly: [00:41:16] We get excited.

Kelly Catale: [00:41:18] Oh, I’m super nerd. I I’m the I’m not critiquing from a non nerd standpoint.

Alex Thirren: [00:41:26] I’m more. Oh,

Kelly Catale: [00:41:28] don’t test me,

Alex Thirren: [00:41:32] bro. Come at me. We talked about a lot of things we did.

Kelly Catale: [00:41:39] In the last episode that we had episode one, we talked about how to leverage your UCD team in a way that will most benefit your project.

And then today we’re talking about the benefits of UCD and perhaps at the start of this, you were, you might’ve been as a listener. Might’ve been thinking, well, okay, we have a designer or we have a human factors. Engineering department is UCD really that, that important. And hopefully the message you can take away is that the close integration between design and human factors, and then even closer integration with all of the development team really does bring a lot of value.

Every project can definitely benefit from a UCD mindset, even if it’s not a UCD team, but a mindset of staying user focused and really user forward in all of your design discussions. And as the design progresses throughout its life cycle.

Alex Thirren: [00:42:34] I really liked that the scalability of this idea is integration early integration at the start.

If you have one designer, great. Bring them in at the start and have them work with the team all the way through it and start conversationally. When, when you have a single designer within a larger organization, sometimes there’s some scaling issues about how to consume and how to, how to mature your ability to leverage design as a skillset.

Same with human factors engineering. When I talk about design broadly, because this is about user centered design work. Integrating them early means that we’re thinking from a systematic and architectural standpoint about the integration of the user and their influence on the system at, at the get-go at the DNA level.

If we’re dealing with it. At the we’ve got something let’s skin it, or we’ve got something let’s put some corner radiuses on it or we’ve got something, make it, make it.

Kelly Catale: [00:43:32] Yes. I was going to say make it pretty, like we said, at the beginning,

Alex Thirren: [00:43:37] put the pretty on top of the thing and it just, it never works. Too late.

I think the takeaway there is, I don’t think you’re going to get what you want out of it. Well, have these aspirations and these visions in their heads of what design can bring to the table. And even if it is putting pretty into the picture, not addressing that at the fundamental level means that you’re not going to get the outcome that you want it.

It really does come down to, maybe we can put some really nice corner ADI on here and it’s going to be an Apple product. That’s not, it there’s so much like we talked about at the start of the program. It’s. It’s about the restraint and the editing process that goes into what goes in and what comes out and what makes it through the filtering.

It’s tough to achieve that. If you’re not integrating with your design resources early enough, via a human factors engineer, who’s going to set you up with an architecture and a mental model of how this product will work for your end user. So you can execute that throughout whatever technical team you’re applying to the problem, or a hardware industrial designer who is focused on how the form.

Gets developed to reflect what the user’s environment is and how the physical product and the material choices and the interface the human comes about, or the software. Where we’re thinking through the workflows, we’re thinking through what is inappropriate aesthetic. We’re thinking through how we take interactions off the table.

So user doesn’t even have to worry about it and eliminate elements of Karen support that the user may have to do for a software system. All of that comes into play. When you start thinking at the DNA level,

Kelly Catale: [00:45:16] I’m super excited about all the stuff we talked about today, and I feel like anyone listening could hear.

The passion in our voice, which comes from understanding and appreciating our users and designing with them in mind, which is being user centered, user centered design, or user centered by design. That wraps us up.

Alex Thirren: [00:45:36] I think it does wrap us up. I think we’ve got another episode that we’ll start working on soon.

This is number two in the can, so that’s exciting. And we have Marcus,

Kelly Catale: [00:45:44] we enjoyed this conversation. I hope you all did too. And we’ll catch you next time.

Alex Thirren: [00:45:50] Thank you everyone.