UX, Agile, and Healthcare Innovation Projects

Luke Preston: The topic of the episode is all about Agile, and I know a lot of my viewers are working on their own projects or trying to build up their portfolios or experience, and whatnot. What’s the connection that they could use with Agile in their projects? Maybe we could start off by explaining what Agile is, and then we could kind of ease into how they could apply that framework to better implement the phases of their project.

Nate Bauer: Yeah, okay, cool. There are a plethora of different directions we could take this conversation, but I love the opportunity to define what Agile is first because a lot of what I experienced throughout my mentorship is that a lot of different folks who work at companies have different perceptions and mental models of what Agile means. And what I typically find is they have some flavor of Agile at their work, at their business, and that flavor doesn’t align with other people’s flavors, and most of the times, it’s also not usually true Agile. So, yeah, let’s talk about some fundamentals real fast and define some terms. And as strangely as it sounds, one of the best ways I find to talk and describe what Agile is is to actually talk about Waterfall and then compare the differences between those two. And like all classic UX analogies, there’s the whole building the house analogy, and I think it works really well in this instance.

So, Waterfall, in general, has a motivation of getting things right on the first try. And let me depict what that means. So, if you are building a house, you might go about building a house by starting with research, designing, or figuring out what kind of house you want to build, how many rooms it should have, your needs, all that sort. And then you enter the design phase, and then you might say, okay, well, what does this house need to look like? How should I design the blueprints to this house? And then you might enter the build phase where you actually start building, developing the house. And then every so often, you see in Waterfall frameworks, there is potentially a testing or validation phase at the end to make sure you built the thing. But what’s important to remember about Waterfall is that it’s usually longer timelines. Waterfall projects usually have many months to many years underneath them. So if there is a testing and validation phase, it’s usually way too late to get actually any value out of it. So, in a nutshell, that’s what a Waterfall framework looks like: a few different phases, you’ve got the research phase, the design phase, the build phase, sometimes a testing validation phase, but the moral of the story here being that Waterfall has a motivation of getting things right on the first try.

So, Waterfall, Agile has a similar core structure but with an entirely different motivation, and I think that nuance is really interesting. If you were building that same house in an Agile framework, you would start with the research phase and then you’d research, hey, what’s the objectives of this particular project, and what’s like the most important thing we need to do? And in that research phase, Agile might learn that, hey, this house that we’re building, the office is actually the most important part of that room. The person who’s buying the house wants the office the most. So rather than building the entire house, we’re going to enter the design phase, and we’re only going to design the office. And then we’re going to enter the build phase, and we’re only going to build the office. And then we’re going to introduce the testing validation phase, and because we’ve only built the office, it happened way faster. So we can genuinely validate, hey, is the momentum that we’re moving forward, is that the correct momentum? Are we solving the problem in the right way? Does it address the business objectives that the team agreed on earlier? So what’s awesome about this is it provides value real fast. You can test that value real fast. And then the overall moral here being that if Waterfall tries to get things right on the first try, Agile tries to get things right eventually, and chooses to fail in a lot of ways first but focus on one thing, and then after each iteration, eventually get to the right product.

Luke, be my sounding board on this. Is all that making sense?

Luke Preston: Makes perfect sense. I love the house analogy because I’m more of a visual person, and I could just circulate that in my head. But what I want to ask is, let’s say I’m breaking into the healthcare industry, okay, yeah. And I’m working on, let’s say, a web app for keeping clients’ records or whatever, let’s just say that. What is the thought process when I should be using Agile, or let’s say I should be using Waterfall, like what is the environment in which I should apply this to that or that to this?

Nate Bauer: Yeah, that’s a super interesting question. So, you gave me an example of, I think you said something about contracts. Let me throw a different analogy at you. So, I currently work in healthcare, and the portion of healthcare that I work on is, there’s a fancy world called uh, fancy word called adjudication. It’s really just a fancy word for processing claims. And what it turns out is that the world of claim processing is exceptionally complicated, and there’s nobody on the planet, there’s no single person who understands the entire process front to back. So what we have is a conundrum in the feasibility and capability of our amount of understanding in attempting to solve this problem. So what we end up learning is if we were to attempt to do a Waterfall process to this and try to get things right on the first try, we’re almost guaranteed failure because there’s no portion, there’s no entirety of knowledge that we could possibly have at one time to solve this problem. So instead, if we could apply an Agile approach where we’d say, hey, I can’t understand the entire thing, I can understand, you know, 3% of it, let’s solve that 3% and then let’s move on to the next 3% and iterate from there. Agile, in this context, ends up being really the only possible solution to get to that greater final product. So you would say Agile is more of like more of an experimental kind of framework for when the path is unclear, and the problem is not really set in stone known. It’s kind of like, let’s say we use Waterfall when we know this is the objective, and this is what we got to build. You would use that kind of framework first, and then Agile is more, okay, well, this is what we think is the problem, um, these are kind of the features or whatnot that we’re going to build for it, and this is kind of our theory on how we’re going to get there. Am I on the right path?

Luke Preston: Yeah, no, that’s totally making sense. There are a plethora of other nuances, pros, and cons to Agile and how it differs from Waterfall, but at a high level, you’ve got it, man. That’s exactly the conundrum that Agile is attempting to solve. Sweet, cool. Well, how can I connect this, let’s say I’m working on this record app, okay. We’re going to go back to the healthcare situation here, and I’m in a team now, so it’s not just me now. I’m dealing with other people. What are the best practices of leading an Agile framework or being a part of one? And you could even go over the Waterfall as well, kind of what’s the workflow system like with working together using this framework? Is there more kind of communication errors that can happen, or what is there to watch out for, pretty much when it comes to this?

Nate Bauer: Yeah, so there’s a lot of, man, there’s so much to talk about there. So, in terms of starting an Agile team and building an Agile team and creating a healthy, mature Agile team, there’s a lot of different factors that take place in building that sort of team formation. The motivation of building something right eventually keeps coming back, and as you start building this formation, as you start making business decisions, you have to, as the UX designer, really enforce that that motivation takes place at all decision points throughout the process. So, what’s interesting about leading an Agile team, particularly in what’s referred to as a decentralized product environment, what’s interesting about leading teams in those sorts of environments is that the UX designer ends up being a team leader in a lot of senses. They end up being the facilitator toward Agile protocols, and they end up leading the sort of team through this Agile experience. It’s a process that is new enough that a lot of folks don’t have intrinsic knowledge of how it should function just yet. So, you end up being the host of that experience and sort of the leader for that entire flow.

I missed what was the other question you had, a bunch of stuff in there.

Luke Preston: Oh, um, so one was what to look out for when you’re working on Agile within a team, and then the second one was you could also explain the Waterfall methodology too, um, with kind of the same framework or whatnot when working with teams like what’s the what’s kind of the different scenarios that you would deal with when working with others?

Nate Bauer: Yeah, yeah, yeah, totally. So a second ago, you mentioned communication. This is another big factor in how Agile teams function, and it’s one of the friction points of Agile. So I’m glad you’re talking about Waterfall and comparing those two. So in a Waterfall team, there are pros and cons to Waterfall. One of the pros is that communication in Waterfall is exceptionally… I shouldn’t say exceptionally but it’s significantly easier. So, for example, you’re building a Waterfall project of some kind, and that project typically starts with some sort of plan. Somebody writes down in a document, this is how the project is going to function, these are all the folks associated with this project, this is how much it’s going to cost, and that plan is then distributed toward all the stakeholders. And the stakeholders can approve or reject some of it, all of it, none of it, and they can provide their say on what that process looks like. So, in a Waterfall framework, that plan ends up being really easy to communicate across lots of different stakeholders.

Well, in an Agile team, most Agile frameworks work in Sprints, and usually, they’re two-week Sprints, but you know, it depends on the business. What you end up finding is that because we’re not planning the entire project, we’re only planning one Sprint at a time. Communication ends up being a real friction point because there are all these different stakeholders, all these different people within the process that have to be communicated, but instead of communicating them once within Waterfall, now you’re communicating with all of them every Sprint, every two weeks. And it’s hard to deal with, and it’s hard to adjust to, and there are solutions, strategies to that as well, but in terms of the larger friction point, having to manage and deal with all this communication as you’re passing off deliverables can be cumbersome and tricky to do.

Luke Preston: So, what can you actually do about that in terms of tools to use? Do you have any best practices for how to communicate better? Yeah, I feel like that’s such a pressing issue in the industry, is kind of like a game of telephone where it’s, oh, this person said that, and so I think it’s going to be about this and whatever, and it just ends up ruining the whole process of from point A to point B. So I was just wondering, do you have any articles that you read, books, or is it just you have a natural t for just being able to communicate with people across the team?

Nate Bauer: There are a couple of things I want to mention here. So one is, we’ve talked about the philosophy of what Agile is. There’s another philosophy that’s referred to as Lean, and a lot of folks use these words interchangeably, but they do have sort of intrinsic differences between them and how they function. So if we’re defining Agile as the methodology of quickly iterating in individual cycles, then it’s important to understand that Lean is the methodology of understanding value with the least amount of effort. So, for example, I’ve got what I refer to as the 80% principle, and the 80% principle attempts to explain that hey, if I’m working on a project and I get to 80% satisfaction with the output of that project, that’s when I should stop working on it and get feedback and validate effort. So let’s say that that 80% satisfaction, let’s say it gets 10 hours, it takes me 10 hours to get there. I could get to 85% or 90% satisfaction on that project if I put more time into it, but what I find is the amount of time it takes to get to 90% could be an additional 10 hours. It could be twice the amount of effort, and I could get to 100% or 95% effort, but even then, it’s like dramatically more time when at the end of the day, 80% was good enough, usually almost always is. So, Lean is the philosophy of understanding the most amount of value for the least amount of effort, and Lean practices enable us to learn a lot without having to expend a lot of time, money, and effort along the way.

Did I answer your question? I forgot where I was going with that.

Luke Preston: Yeah, I think I think you did a good job answering that. I was just kind of trying to understand, um, what you personally do to, besides the Lean strategy and everything like that, do you personally do to handle communication issues?

Nate Bauer: Right, the communication best practices. There’s another thing I want to talk about. So there’s Lean. So with the Lean philosophy, it also… So with the ability to build an output and start getting feedback and validation at 80%, it also means that you communicate pretty fast. So if you’re working in two-week Sprints, there are cadences that one could utilize within that two-week Sprint, including demos. And this is not terribly novel for Agile workflows, but I, in my workflows, typically have several demos. One is with just the product owners and the devs to validate feasibility and momentum. I have a second demo with the larger stakeholder team, validating that the application is solving the corrected business objectives. But even before then, at the very beginning of a Sprint, I’ll have a lean sort of walkthrough of a product canvas to attempt to solve business objectives, user needs, and then just target audience in general. And then we’ll build hypotheses, and then as a team, align on what we’re attempting to solve for just that Sprint. So what’s cool about that is, uh, the communication in Agile and the communication within a Lean structure is sort of like built into having, at all times, team alignment. A lot of in-person meetings or remote meetings if that’s your jam, uh, and then the communication is sort of constant throughout that process.

I’ve also got a deliverable. So if I design a thing and then I have to pass it off to the devs, I’ve got a deliverable that I call slicing that solves that methodology as well. Happy to dive more into what that communication looks like, but I’ll, uh, yeah, I’ll let you lead the conversation if you want to go that way.

Luke Preston: Let’s definitely go that way because I know a lot of my viewers always ask about or want to know more about the handoff between designers and developers. Like, what is the process like? Because many don’t have a lot of real-world experience, and these job applications are saying you need eight years of experience for an entry-level job, etc., whatever. So they kind of want an inside glimpse as to how do I most effectively deliver my designs to the dev team, and what does that overall look like?

Nate Bauer: Delivering an output in an Agile environment ends up having a lot of interesting friction points along the way, and we’ve solved that. So my company, Centene, is the healthcare company that I work at. We’ve solved a lot of these nuances with a process that we call slicing, and at a high level, a slice is an amount of effort that we are attempting to solve for a particular iteration. And it’s going to be a little tough to talk about in the abstract here. Uh, in a future call, if we, if I want to, if, if you want to like have another chat, and I can share my screen and walk people through this, totally open to that as well. Actually, if you’re open to it, I wrote an article about it. We can potentially link to it in the description or something. But at a, so a slice is an amount of effort that we’re attempting to solve for a particular Sprint.

So what is a slice, and how does it differ from a Sprint itself? So if we look at all the individual stakeholders that we’re trying to get sort of feedback and validation on for each iteration, we find that there are a couple of different personas that have specific needs that we can solve for. So, for example, we know that devs are a stakeholder in this process. We, at some point, have to provide an output for devs to build. So what are the devs actually need to know? So they need to know what they’re going to build, and they need to know how they’re going to build, and sort of like what the aesthetics are of that particular thing, and what problems that product, that output, is trying to solve. So there’s the devs. But we also got product owners. Product owners are mostly interested in what problems are being solved and if the correct problems are being solved in the right order. Product managers are mostly interested in, is the momentum of the entire application moving correctly?

And then there’s a variety of other stakeholders too, like the higher-level folk who are overseeing the entire team. They want to know just, hey, what are you guys doing? Is the momentum also factoring incorrectly? There are other stakeholders like adjacent departments, uh, just want to know what you’re working on, if there’s a redundancy in effort, anything like that. Uh, then there’s other UX designers. Is there redundancy in what I’m designing versus what you’re designing? So we have a document called slicing, which attempts to address all of these in unique ways. So if I were to pull up a Figma document and show you what a slice looks like, you would find a bunch of designs on that page, and there would be arrows between these designs dictating the flow of how this application works, how a user would move through this application. And then next to each, next to each, uh, design, there would be documentation for the developers describing, hey, what’s the motivation of this particular feature that we’re introducing, or screen that we’re introducing? It would walk them through how it works, what’s the functionality behind this particular thing. So you’ve got documentation there. And then beyond that, at the top of that entire flow, there would be a broad-level description dedicated toward the, uh, the larger stakeholders who just want to know what the momentum is. They don’t need the deeper documentation of how it works. So that description would say, hey, in this particular slice of effort, we’re attempting to solve X, Y, and Z, with a business objective of solving this particular outcome. So there’s slice one. How’s that, Luke? How’s that sounding so far? Is that making sense?

Luke Preston: Yeah, no, I never heard of slicing, so this is interesting. I’d love for you to keep going.

Nate Bauer: Totally. So that’s what we would call a particular slice. But where the power of slicing comes in is, well, we’ve built slice one, and for the particular Sprint that we’re working on, we’ve said, hey, we’re going to build slice one for this, for this iteration. I, as the UX designer, then going to be working on slice two. And what you’d find in slice two is all the same screens that we just designed for slice one, but with the adjustments and enhancements to it that we want to focus on for the next generation. And then I work on slice three, which has all the exact same screens again, but with the new features and the new outcomes that I’m trying to provide for. So what you find is as you go through slice one, slice two, slice three, anybody can look into all these different slices and see the story of how this application has evolved over time. Uh, this also factors into another concept called dual track Agile, and this is where the differentiation between slicing and Sprints comes into play.

So let’s say we’ve got an Agile team, and we are working on Sprint number four, whatever. I could be attempting to design slice number seven or something like that. So as the UX designer, I’m working on slice seven, but the developers, they’re still working on slice 2. So I am several slices and several iterations ahead of the dev team, and we’re working at different cadences, working on the same project but on different portions in different, like, evolvements of that application at the same time. So that’s dual-track UX. We’ve got the developers working on one track, the UX designers working on a different track. And while we’re working on the same application at the same time, we’re in like different future states of it, which is super cool.

Luke Preston: That is super interesting. So, how do you actually successfully do that? ‘Cause that sounds very difficult, like, to be honest. Like, you’re explaining the concept, but how do you successfully go about that?

Nate Bauer: So, one of the friction points with designing an application at a future state that it’s actually in is some of the core philosophy of Agile. So Agile says if we’re going to tackle two weeks at a time and then test and validate if we’re actually heading the right direction, then why would the UX designer move several slices ahead of the dev team? Doesn’t that sort of, like, invalidate the process of validation and testing? And the answer is, yeah, kind of. Uh, the ideal approach is that the UX designer is ahead of the dev team, but I don’t want to, I don’t want them to be too far ahead of the design or of the dev team because then you lose that sort of testing and validation stage. So, in the example I just gave, I said the dev team was on slice two, the designer was on slice seven. I would argue that’s too much. I, I would t, I typically find comfort in being, uh, one slice or two slices ahead. But because we’re in Agile, we can test and validate, and if we want to say, hey, that slice either just made that the devs haven’t looked at yet, we’re going to throw that away, or we’re going to re-prioritize it to a later slice, you can totally do that. That’s, that’s not a big deal. And because, like, worst-case scenario, you end up throwing that particular slice away because we’re pivoting to a different direction, you only lose two weeks of effort. And when it comes to affordability and the cost of losing two weeks on the grand scale of things, it’s really not a huge deal. Not to mention, it’s the correct sacrifice for the amount of velocity you gain from Agile and from this slicing process.

Luke Preston: Gotcha. Yeah, no, that that is a very slim margin of loss, um, for two weeks of time compared to what it could be. Um, I just want to ize a question here. So that seems to be, to me, judge me if I’m wrong, that seems to be some high-level, uh, like you said, abstract, uh, concepts that you just explained, right, with the slicing that you could go on and on forever about for people just starting off and let’s say they’re just getting involved in a project, and they’re just starting off getting involved with an online team. What practices, um, or should I say methodologies, should they incorporate right off the bat? Or is it kind of just let’s feel each other out and understand our own work processes, what we’re building, and then we’ll figure out, um, how we collaborate from there? Or is it kind of you, we go into this with, okay, we’re going to Agile approach, and then we’re going to just form around that?

Nate Bauer: Yeah, that’s a great question. Uh, so what you’re describing is, I, I think what you’re describing is how one defines the maturity level of a particular Agile team, and there are different phases of maturity that teams can adopt and adhere to. And over time, the more mature the team gets, the more succinct and, um, the higher the velocity the team has. However, if an Agile team is just starting out, these practices are novel, and they’re new, and they’re usually kind of difficult to grasp, given that most folk coming from a Waterfall mindset, and this mindset is totally different. So in those occasions, a lot of sort of like fundamental, uh, Agile philosophy comes into play. Uh, part of part of the Agile process is that testing and validation phase, and that means that we take a look at that product and see if we’re headed the right way. But that also means let’s see, let’s check in with the team, how are we doing, are we doing the right thing here? And then you get retrospectives that come into play where you sit down as the team and say, hey, this is what worked over the last couple weeks, this is what didn’t work over the last couple weeks. And the more you utilize these retrospectives, the higher in maturity the team ends up getting over time.

If one wanted to utilize a slicing process or the ability to build an output within an Agile environment, don’t you don’t have to design the entire application with every slice and add iterations in, in different future states of that slice. Instead, potentially tackle it from a feature perspective. And I say that with an asterisk here because our main objective should be tackling outcomes and not outputs. But if you want to say that, hey, for slice one, I’m not going to tell the entire story of the application, I just want to build features one, two, and three for slice one, then just design those features. It’s also, it eases the communication. The developers can see exactly what you’re working on, and then other stakeholders can really quickly see, hey, just adding three more features to the slice. So yeah, in terms of the difficulty of slicing, if you want to simplify it for your particular team’s environment, that’s fine, do, do that. That’s great.

Luke Preston: Gotcha, cool. Do you think, um, the best approach is to have kind of a project manager, team lead to be in charge of this entire process? Or is it kind of just we’ll just keep each other accountable, and we’ll go, uh, the fast route, and we’ll just see how it works out?

Nate Bauer: Yeah, so there is one of the more common frameworks you’ll see in Agile environments, very often corporate environments, is a particular flavor of Agile called Scrum. There are other flavors of Agile; there’s one called SAFE out there that is also common among large enterprise, uh, corporations, and there are other smaller ones as well. Uh, at a high level, Scrum is a communication strategy that attempts to dictate when you should communicate and how you should communicate. So one could, for example, adopt Scrum into their Agile framework, and that would dictate how you communicate and when and what particular processes you should be following. But if you’re a small team, like you’re a startup, for example, you’ve got three folks that you’re working on, there’s really no need for that additional process of communication, and instead, I would just say, hey, you as the UX designer, uh, if you’re wanting to formalize Agile and Lean practices, then congratulations, you’ve now become the facilitator for this process. And it’s also a great place to be. You, you are the person that builds team alignment. You facilitate how these processes should function, and you are the person that ends up re-encouraging that mindset of getting things right eventually and not on the first try. As long as you keep going back to that motivation, I think you’re going to experience Agile practices pretty fluently.

Luke Preston: Okay, for let’s say getting started as a designer, do you think Agile is really important to master and learn off the top of your career at the very beginning?

Nate Bauer: That’s interesting. Um, Agile is a tool, right? So it’s one of those things where there are occasions in which Agile is phenomenal, there are occasions when Agile is not. I would argue that in the terms of like most product design environments, Agile is superior to Waterfall. But if we go back to that house metaphor, clearly, if you’re actually building a physical house, Agile is not the right solution. No one’s going to buy just an office and not have the rest of the house built right. So, like, there are occasions in which Waterfall is realistically the better outcome. Uh, so whether or not you need Agile right away, I do think it’s a superior format for product development because you, in product space, you totally can only design one portion and forget the rest, and then start getting value off that one little portion, the you don’t need to build the rest of the house. So I don’t know, it depends on your environment. In general, I would argue that Agile is a superior framework for product design, but I’ll, I’ll leave it up to the, the comments below to, to name all the occasions in which I’m wrong about that.

Gotcha, okay. Yeah, because I was just wondering, off the top of my head, that there are a lot of beginner designers out there that are trying to build up their portfolios with individual projects or just working on, um, idea concepts with other people online, and they don’t necessarily understand how to communicate or get things done. But they all have kind of this passion or growth mindset of getting better. So I think a lot of the things that you were covering, you could really implement and help out your situation because I think a lot of projects get ghosted, and um, the, the passion and spark initially fades away. And I guess the purpose of this whole talk was to try to give out key processes that corporations use, that high-end freelancers use all the time with, with their teams as well, to better understand how to work through a project idea concept to completion. So I didn’t know if you had any other recommendations or communication techniques, or I don’t know if you use project management software, believe in that, but anything that could kind of guide them or help them, uh, in that trajectory, I think would be cool to kind of wrap up and talk about.

Nate Bauer: Let me repeat that question back to you to make sure I’m understanding it. Am I hearing that you’re looking to better understand if there are any particular, like artifacts, or, or, um, frameworks that one could utilize to adopt and better understand how to use Agile?

Luke Preston: So I guess what I’m asking is, what other techniques can entry-level people in the tech space use to better complete projects from initiation to execution?

Nate Bauer: I don’t know if I have anything that we haven’t already talked about. I think the Lean philosophy goes a long way. That 80% strategy that gets them, that gets them there fast, the Agile approach solves the validation that you’re heading the right direction. Um, there’s an educational aspect in there that we haven’t talked about, of like, how one improves their skill as a UX designer, and and adopts a more Agile mindset. But I think that’s just generic education that one learns either through formal sources or with experience. I don’t know if I have anything to add in terms of techniques unless there’s something more specific you’re looking to tackle.

Luke Preston: I actually wasn’t looking for anything specific. I, I just was curious, to be honest. But so I, I think in terms of a lot of team collaboration and a lot of fast-moving things, and not having a clear picture of the roadmap ahead for a lot of these people working on themselves and other ideas, and through what I found, it’s always nice to have a decision maker and a lead in these types of projects. And either they’re experienced or not, I think someone just to clarify that we’re going to go route A, not B or C, is super beneficial to perhaps maybe even an Agile approach where speed and, um, convenience and communication is key. So I think the whole idea is to not get stumped on the small things and keep things rolling and test and validate rather than to sit there and ponder about what’s right and what’s wrong because the only way that you’ll figure out what’s right is to, to actually put something out there.

Nate Bauer: Yeah, the sooner you can get feedback on the stuff that you’re building and validate if you’re actually working toward that greater outcome where your metrics should be, the sooner you can do that, the faster velocity you have, and the more successful and impactful the stuff you’re working on ends up becoming. That’s great.

Yeah, so I think from all the topics that we covered, from Healthcare to Agile to slicing, you could all incorporate that into the projects that you’re working on, or the teams that you’re involved in, or just personally, if you’re just, if you didn’t even get anything out of the Agile framework or anything like that, just use the 80/20 rule that you were talking about too. Um, so I hope, uh, I hope that all these little golden nuggets can help you throughout your project journeys, and I, I wasn’t sure if you had anything else to kind of…

Nate Bauer: I kind of do. I’ve got, if you’re open to it, I’ve got a conundrum that I have been trying to figure out how to solve. I don’t know how to Google it, and I was hoping I could toss it toward your audience, and then if anybody has any insight, I could, I could read through the comments and see if anybody has any insight. It takes a couple minutes. Do we have time?

Luke Preston: Yeah, I heard about that. Yeah, let’s talk about it.

Nate Bauer: So, uh, I haven’t found a perfectly succinct way to describe this, but I’ve got a methodology of getting there. So let me, let me walk you through this analogy here. I’ve got this entire thing has to do with building and repositioning mental models. So I’ve got a mental model of what I perceive frustration as, and my mental model is that frustration is like a cup. And as you get frustrated, as you get more frustrated, that cup gets fuller and fuller, and eventually, that cup gets so full that it spills over, and you lash out, and you become overly frustrated. But throughout your life, the more times that this cup gets filled up, the larger the cup gets, and the more patient you become as a person, the more stuff you’re able to put in that cup without blowing up.

Yeah, so that’s my mental model of how I think frustration works. So now you, as the audience, you as the person listening or watching this, a few things happened in your mind just now. One is, you didn’t have a mental model for what frustration is, and now you do, now you’ve adopted this one. Or you already had a mental model for it, and you’ve chosen not to adopt this one. Or you had a mental model, you’ve heard this one, and now you’ve combined them to create a new mental model, and then a couple of other scenarios as well. So, circling back to healthcare, I work in the healthcare space, and one of the difficulties, friction points with healthcare is that it is a repertoire of archaic software, hard software built on solving problems in old-fashioned manual ways. As I’m building software, I’m attempting to innovate these processes and create different mental models for how these problems should be solved. But I’ve got thousands and thousands of people using, utilizing the software. How do I, how do I reposition all their mental models to this new mental model? And I love this question because it dives into like philosophy of how one communicates, it dives into marketing of how to position a product, it dives into persuasion of how one translates and communicates the needs of a different mental model. And I, I genuinely don’t know how to research this, but I have to imagine that this isn’t a novel concept. I have to imagine someone’s talked and written about, about this before, and if anybody knows any direction I can go to to learn more about this, I’d love a book recommendation or an article or a podcast or something because there’s got to be something out there.

Luke, any thoughts on any of that? Because I’m, I am dying for something about that.

Luke Preston: I wish I had an answer, just like you. Um, now that you got me stumped, I want to hear, just like, maybe a quick sneak peek into like, what made you start with all this, like, what sparked?

Nate Bauer: Yeah, so we didn’t really talk about it. My education is actually in marketing, and I found UX to be this, like, really interesting, uh, adjacent field of marketing because I genuinely utilize a lot of marketing principles in my UX career. So with marketing, of course, comes with a lot of rhetoric of advertising, persuasion, salesmanship, and all the other shenanigans that marketing has, right? I tend to specialize more on the branding and communication side, but, you know, there are other portions of marketing that are kind of a bummer. Uh, long story short, marketing has a whole lot of thoughts about how one persuades and how one builds mental models on a thing, but it doesn’t directly translate to software. And there’s a Venn diagram of interests here that I’m sure somebody knows something. I’m sure somebody knows more than I do, and I’d love to pick their brain about it.

Luke Preston: I’d love to pick their brain too, honestly. Get me on the same call because now you got me hooked.

Well, Nate, well, it’s a pleasure to have you on. Um, I think I, I definitely picked out a lot of things that I could even implement into my daily life out of this conversation. So, um, once again, appreciate you being my first guest, and hopefully, we could chat again.

Nate Bauer: This has been a pleasure. I’m honored to be the first guest, and I’m, I’m hopeful that we can chat again in the future, and maybe walk, do some, uh, screen sharing, and maybe walk us just through some more in-depth slicing methodology in the future. But it’s been a pleasure, really appreciate the time.