This is our very first episode of the show! We (Alexis and Matt) discuss the idea that everyone can design. We talk about how design is not just for “designers”, and how more software developers should recognize their role as designers—even if they’re building something small or seemingly insignificant.

We also talk about why it's crucial to understand user needs, and how hard it is to design for behaviour and process change.

We tackle the age-old debate about the difference between UI and UX design—and why that difference might not matter too much in the long run!

Ultimately, we agree that designing is really about solving problems for people and making their lives easier, and that everyone making software has the ability to contribute to that goal.

Resources mentioned in the show

• The UX Design Workshop - Learn UX Design for Claris FileMaker - The premier all-in-one UX design course for FileMaker developers. Learn to confidently create effective and usable apps—even if you’re a UX design novice. Skip the trial and error and get the expert guidance you need to get your app built right, the first time.
• Resources - UI/UX Design for Claris FileMaker - Download free design resources here
• FileMaker UI/UX Design Community - Join our Facebook group!

Ep 1 - Why Everyone Can (and Should) Be a Designer

If you're creating something, even if it's something very small, it is designing something. And I think that the more people know about it and the more they understand it, that to me is, like, the best.

I realized early in my career that I was building things and then realizing I wasn't actually solving people's problems, as much as I thought I was.

It does come down to, yeah, we're all trying to understand the right customer problems in order to solve them in the right way.

Welcome to Everyone Can Design, a podcast exploring the world of user interface and user experience design. We want to demystify UI/UX design and make it accessible to everyone. I'm Alexis Allen, a Claris FileMaker designer and developer, and the founder of fmdesignuniversity.com. And I'm Matt O'Dell an Experience design leader, strategist, and educator.

We bring you practical, actionable advice to help you improve your UX design skills. You can find detailed show notes and more at www.everyonecan.design.

This is our very first podcast episode, Why Everyone Can (and Should) Be a Designer, and we're so excited to share it with you! In this episode, Matt and I talk about how design is not just for quote- unquote "designers," and how more people should feel empowered to consider themselves designers. Ultimately we agree that designing is about solving problems for people and making their lives easier, and that everyone has the ability to contribute to that goal. We really hope you enjoy the show! And now, here's our conversation.

Hey, Matt!

I am so excited about this podcast because uh, we've known each other for a long time, from the FileMaker world. I don't even know how many years we've known each other, like at least 10, I'm gonna say.

I'd say more than 10 years because I'm sure we first met while I was having to travel across the Great White North when I was living in New York and having to go up to Canada every now and again. So that was probably, 2008 to 2012. So somewhere in there at...

Okay. Yeah, I remember you did a presentation at the Design Exchange, and I think you were answering questions about the latest version, which is probably like what, version 8 or something?

Oh no, it was, it was after that. I think when I joined it was like FileMaker 9 or 10. 10 I think was coming out right after I joined. It was probably 12. It was when all the layout stuff changed. That was probably it, right?

Yeah. Yeah.

And yeah, so we see each other at the conferences and we keep in touch at other times as well. We've always had this mutual interest in interface design, and we've always had really good chats about it.

So I know you're now not in the FileMaker world anymore, but you're still in the design world. So, I really like that, because it means you might have a slightly different perspective from the sort of wider world of software design and software engineering or whatever, user experience, all of that good stuff.

And, I'm strictly a FileMaker designer, like I don't do, you know, websites and other types of applications. That said, a lot of design is universal, right? It doesn't really matter what your platform is. I guess in some cases it does because maybe the way you design something is dictated to some extent by the capabilities of that platform.

But people are people, right? The technology changes, but people don't change. And the idea I had about this podcast really was to kind of demystify the world of design for people, and allow them to really feel that they can design. Like, the name of the podcast is Everyone Can Design.

If you're creating something, even if it's something very small, or seemingly insignificant, it is designing something. And I think that the more people know about it and the more they understand it, and the more they learn to appreciate even their own abilities to learn design, and to evaluate design in the wider world, that to me is like the best. So tell me a bit about your philosophy, I guess, or your approach. You know, what brings you to design?

I started my career as a software developer and then into sales engineering and technical marketing, and so I've always been kind of design- adjacent, right? And only in the past six or eight years now, somewhere around there, have I finally started to dive into it as a career. I've been both in the position of, you know, consultant, the freelance designer, the person who's working on a project or a system for a company. But I've also been in the position now of working in different places, of being the staff designer or part of a design team that is there to support a product team and to support engineering. And so there's, there's so many different perspectives between having those two different roles and the things that are necessary for those.

Working in a big company, working in a corporate environment versus working as like the sole contractor or the sole person, or with a small team of one developer and maybe a project manager, if you're lucky. Or being the project manager and the designer and the salesperson, and the engineer at times, I've been in those roles as well. So, I've, I come to this just because I realized early in my career that I was building things and then realizing I wasn't actually solving people's problems, as much as I thought I was. I was like, "Oh, this is gonna help people. This stuff I built, right? This makes total sense to them because it makes sense to me." And then realize, "Oh wait, I'm not everybody and everybody is not me."

I. So yeah, that's, that's how I kind of came to this of like, "Ooh, maybe there's better ways of doing this kind of stuff," so that if I'm helping people, I can actually help them, and not help them in how I would help myself.

Yeah, you said something really important there, which is you're not the user, right? You're not the person who's going to be using the tool, and so I think that's really challenging for a lot of people, is to realize that people are coming to the tool with whatever is in their lives at that moment, just like we all are. You know, maybe they're having a bad day, Maybe they're not particularly technologically savvy, whatever the case may be. But they still deserve good design. I really believe that everyone deserves good design.

But you do need to think about, How are you going to design for somebody? How are you going to meet your audience's needs?

And you said something about like, you were designing things, but you weren't, you wanted to make their lives better, but you weren't necessarily doing that. Uh, what did you say? I can't remember what your quote was.

It was just realizing that when I was building things, I thought I understood their problem. I thought I understood, "Hey, all you need is a piece of software and it's gonna make your life easier and I can build that piece of software for you."

And then you realize, "Oh wait, I actually built a piece of software that gave you just same amount of overhead, the same amount of work as the original thing." It didn't actually solve any problems. It just, like, changed the problems to be, "I'm focusing somewhere else. I'm having to spend my energy elsewhere, instead of actually solving the thing that I wanted the software to solve for me." So that was a thing I realized when I was a developer, that I was like, "Oh, this is what I need to do better. This is where I need to focus and, and get better."

Yeah, I've recently had an experience with a client where they were asking me to design a scheduling system and the way that I had done it made sense to me, but they really didn't resonate. And I tried a bunch of different ways to kind of educate them, help them learn the system that I was trying to build.

And eventually I had to realize that even if I think my system is better, if they don't understand it and they can't use it, then it's not better. There may be certain advantages that the system has from my perspective. But the users are who they are, and if they can't use it, then I might as well not have built it for them.

I was listening to Jakob Nielsen, who's a well-known user experience, I guess guru. And he said you have to design for how people are, not for how you'd like them to be. And I really resonated with that because that happens all the time.

If you're a developer, strictly a developer, let's say, you're a one- person shop. You're wearing all the hats, right? And maybe you're coming to the FileMaker platform from an engineering perspective. You can't assume that the people using your software are gonna have that ability to abstract, you know, the knowledge, the deep knowledge of the structure.

They lack all of that. They don't know any of that stuff. They are there to do a job. Like, maybe they're a librarian, you know, maybe they're a teacher, who knows. They're in something completely different. And so a lot of, you know, what I teach in the Workflow Design Workshop is, "How do you get to know what the users are, and how do you understand their needs from their perspective?"

While you know, in the back of your mind, trying to figure out a way to solve that problem.

Yeah, I, I will say like one of the toughest design problems is when part of the solution that your stakeholders are trying to suggest is behavior change, right? "The people on my team aren't doing this right now, or aren't doing this well right now. And so we need to build a system or build a thing or build tools or a new process or training or documentation or you know, incentives, whatever. We need to do that for behavioral change within a group of people. That is the toughest thing to design for, in my opinion, because you really have to know what's going to get that person to exhibit those changes. And so to your point of like, it's easier when you can meet them where they're at.

And in most cases you wanna do that. You wanna find, "Hey, where are they at? How do they see the world, what are they trying to get done, and then from there, let me build a thing that fits how they see the world and how they work . Let me try to fit into where they're at." That's gonna be easier of a sell than, "Hey, here's this thing that is a completely new way of doing things. And so we have to train you and then hope you remember the training."

Like I remember... I think this is one of those scenarios that like, resonates with me now at this age, which was when I was in high school I think, or maybe I was junior high, that my mom's company that she worked for was doing a thing where they were moving to like JD Edwards or something.

It was like one of those, "We're going to SAP," or "We're going to JD Edwards." And she's like, "Oh yeah, we're having to do this thing, and it's taking forever." And I think one of them had really good consultants and one of them had really bad consultants and the really bad consultants were like, "Well, we're just gonna train you on how to do everything that the system does," and the good consultants were like, "Our thing is flexible and we can actually tune it to how you work." And so she would tell all these stories of like, "The company wasted hundreds of millions of dollars trying to get this one tool in, and it failed.

And then they brought in the other tool, and it worked, because they actually did it differently." And of course, like at the time I was in high school and just kind of laughed because my mom would come home and complain about all these meetings she had and how people weren't listening to them. And then years later, I'm now in this line of work and I was like, "Oh, oh, that's what she was talking about."

Now I completely understand 'cause I'm that person that's sitting across the table or have been that person sitting across the table and been like, "Alright, People That Work Here, how do you work? How do we need to build this to fit into what you're trying to get done?"

Yeah. And that comes to the thing we talk about a lot in design, which is empathy.

We're trying to understand and empathize with somebody who's doing a job that we may not be familiar with. We're trying to figure out who they are, what they need, what is their environment like? And we need to actually put ourselves in their shoes in order to understand what it is that they might need.

And there's various ways of doing that, in terms of research and so on, which we'll probably get to in another future I'm sure episode, as well as what you mentioned before, which was change management. You know, how do you get people to adopt the thing that you've built and to agree.

I wanna just wanna pick up on something you said earlier, which was, you know, behavior change. And also add to that, which is process change. I find a lot of times when I'm speaking with companies, they actually may not know what their process is, or they may not have ever really thought about it. And there might be five people in the sales department and they're all doing things slightly different way and they've all got their own little Excel, you know, system going or whatever, that nobody has visibility into, and you're losing the benefit of having a database, right? Because you do not have one source of truth where everybody's adding to it and everyone has access. And you know, if you wanna know something, you just go to the database. It's all siloed into people's computers. But, when there's process change, that is really hard. And sometimes you have to facilitate these conversations among the client. It's not even something they need from you.

It's just something that they need to speak about among themselves and actually figure out, you know, what is this process that we're doing?

Yeah, that's actually where, like, the role of designer as facilitator can come in really handy. And again, we we're probably gonna go in, in depth, into like all of these different types of skills that like you can have as a designer. Like, "Where do you want to go deep, and what are you good at?"

Facilitation can be one of those things. I make this joke too often with the people that I work with I'll say to them, before a meeting that we're about to have, "All right, this is the meeting where we need to be the therapists for these people that are in this group because they, they need a little help.

And they haven't been talking to each other. And we need to get them to see each other's way of seeing the world or whatever the work is that they're doing, and get them to come to a consensus on how we're gonna move forward together." And, not to make a light of real therapy work, which is probably much harder than whatever we do, but it's, it's in that direction of like, we need to be there to facilitate hard conversations with people.

And that's, a skill in and of itself, being able to come in there and do that.

Yeah, absolutely.

So I guess we should start off by defining, "What is user experience?" Like, what does that mean? And it's a bit of a fuzzy term, maybe. I think the term has probably evolved over time.

And I guess maybe we should also talk about user interface design versus user experience design. How are they the same? How are they different?

I heard a quote from a designer named Dain Miller saying, "UI is the saddle, the stirrups and the reins. UX is the feeling you get being able to ride the horse."

Do you wanna just comment on that?

I, well, I will say, when you proposed this as being the first topic for like one of our first ever podcasts, I laughed a little bit to myself because of, like, this kind of debate or what, you know, people call it a debate, uh, "serious conversation" that people are having on Twitter and other things.

And there's even a Twitter account called like, "UX versus UI" that is a joking account where they say, like, "UX is this and UI is this," and it's all run by like an AI bot that comes up and like, "Someday we're gonna figure out what the right metaphor is here, between these things." But, well, similar to the, the example you gave, I think like the one I've seen the most is that picture of, like, a college campus quad area, and it's like "UI" and I see how this can be derogatory to UI designers, so I don't mean it to be, but this gets used a lot, which is, they say, "UI," and it's like, here's all of these nice concrete paths that have been built and then they're like, "UX" and it's here's this worn path in the grass that people keep walking 'cause it's shorter than following the longer way on the concrete that they made.

Like they made this really nice concrete thing. But it's 20 steps longer than just walking across the grass so everybody walks across the grass instead. And like, for me, the fun in this kind of like, "What is UX versus what is UI?" is the context of how we're using it.

I think that example that I talked about comes from product people or certain companies that, they're very much used to, like, "I tell you to design this screen, and then they go and design the screen and give it back to me," which is quote- unquote UI. You're doing the UI for it, versus someone who sees themselves as a UX designer is like, "Well, no. I need to do the research and I need to understand the person, or I need to have the right research and understand their problems and their mental model of the world.

And then from there I can figure out what is the right screen or right screens to build. And from there make better choices." That's like for me, where I think part of the debate comes from of UX versus UI, is people wanting to not be limited of just like, "Well, you're just designing screens for me."

But it's like, "No, there's more to it than that. I'm having to understand the problem. I'm having to understand the world. I'm having to do this other work. I don't want you to cut my role down." But then what you end up getting is people on the UI side that then fight back and be like, "Well, as much as you wanna understand that, it also is really important to make something that looks good, and feels right, and has the right typography, and the right spacing and the right color contrast." Like, all of those things are important. And you can't have really one without the other. But that's my, like, diatribe and rant on the subject of like, UX versus UI.

I often wonder if it's even helpful to make the distinction. I guess maybe it's more so in large companies, where the jobs are more specialized and you have like a dedicated person for UI, a dedicated person for UX. You know, you have different people doing all these roles. From my experience as a FileMaker developer, I might be the only person taking care of all the design on a particular project, right? So does it matter there's a difference between UI and UX? I don't know. It's really hard to separate. I mean, nevermind even trying to define what design is. Designing in and of itself, it's hard to even define, "What are we doing?" I mean, we're creating things, right? And if you're creating something, to me, you're designing it, because you're making decisions about what should go there, what is the goal of the person who's gonna be using this?

And you're having to create something. And so that is design. And if you're creating something that they can click on and interact with, then that's user interface design, I suppose. But then user experience is a bit, I don't know, I guess it's a bit of a broader term. Jakob Nielsen said, the way that they originally thought of it was that user experience is a person's complete experience. Not just the software, but maybe it's the marketing, maybe it's, you know, all of the user's journey with a particular company. And now that's called customer experience.

And now user experience is meant to be just the technology. Maybe like the way that the shopping cart is set up or the way the website runs or whatever. So it's, it's all a little bit fuzzy. I guess at the end of the day, we're really trying to solve problems for people, by setting up a tool in such a way that it helps them to easily get to their goal from where they are now to where they wanna get to.

Does that make sense to you?

Yeah, I think if you got a group of designers who had different titles in their jobs, it's like, I'm a this or I'm a service designer, versus I'm a researcher, I'm a whatever, that you will find that obviously there's a lot of similarity in the type of work that they're doing. And again, I think they're all going after the same goals. There is definitely specialization there. I think you hit the nail in the head there of in larger organizations that you start to specialize more and you can have someone who does this versus does this other thing.

But it does come down to, yeah, we're all trying to understand the right customer problems in order to solve them in the right way. And we all have certain skills that we can be better at, whether that's, "I'm better at the research side of things." "I'm better at the writing of content and understanding content and how to put it together."

"I'm better at the visual elements of something." "I'm better at data visualization." There are all of these different like little niche things that you could be better at. And we talk a lot about like, all of us have to be good enough at everything as a designer. All of those different things.

But we we like to joke about like, "Where's your 'T'"? Which is like, you know, a "T" has a line at the top and then one that goes really deep, right? And so like, where is the area where you go deep in? Where's, the one thing across all of these that you go deep? Where's your "T" at?

And so, like I say, for myself, my "T" is on that research- slash- relationship- building of stuff, that's where I tend to go deeper. I love that area of the work. If I'm a UI designer, maybe I'm going deeper in that visual design element of stuff. If I'm a researcher, I still have to be good at all of those other things, or at least good enough.

I need to know what they are and how to do them. But I go deep in like, "What are the right methods for doing research?" Or again, we talked about facilitation. Am I a good facilitator? Am I there to work with groups of people and bring out ideas from them or have them see the same thing in the same way, or come to a consensus? Maybe that's your area that you go deep on.

We're also getting dangerously close to probably another topic that we'll have to have in another another conversation, which is like the difference between UX versus Customer Experience versus Human-centered Design versus Service Design. Like, or what's the name I use to describe what I'm designing for? And am I designing for a service? Which is, as you said, the encompassing of all of the experiences someone has, but also has like a backend layer where I'm designing for how that service is being supported behind the scenes.

You could say that human-centered design is about like just understanding the full parts of the human, not just how they work with this at this company and what their mental model is, but, "What are all of the things about them that would help me make better decisions about how to design for that person?"

So different language changes start to mean slightly different things based on how someone has figured out, or wants for themselves to describe, the type of work that they do and how they solve problems.

Yeah, absolutely. And the language is always evolving, You know, as we get more experience with the technology, as a culture, as new technologies come out and then you can do new things. So I think these terms do evolve and change and that's totally fine. And I think even Jakob Nielsen said, well, as a user experience person, you want to meet people where they're at.

And if yes, we coined this phrase, but now people are using it in a different way, we kind of have to accept that and just... that's the reality, and that's okay. I think from a FileMaker perspective, a lot of us are doing, all of the jobs, right? We're wearing all of the hats.

I don't know how important it is for the general developer to understand the slight nuances between all of these terms.

I tried to create the course in such a way that people could get an understanding of the bare minimum that they would need to do in order to do their design efficiently.

'Cause I think there's this feeling out there that design is like this extra thing. It's a burden that you're gonna be adding to your project. It's gonna make everything take longer. And I really don't believe that at all. I really believe that when you start with design, you are gonna save yourself so many headaches down the road. And you're gonna help yourself when you're wearing that developer hat six weeks from now, you're gonna have a whole bunch of documentation that you can then refer to that's gonna help you do a much better job on the development side of your business.

So when I developed the course, it was really about, "Okay, what are the things that you absolutely must have or the things you absolutely must do?" And what's the least amount that we could do to still get that good result, that good quality on the other side after we've done all the work of figuring out," Who are our users, what problems are they trying to solve?" All of those kinds of things.

Because you're right, it really takes a lot of different skills and there's different things that you need to do along the way. And I actually find that fun. I like that about right? But if you're not what they are and they're not your forte, you might not even know that there are things you should be doing or that could make your life easier if you did them.

Exactly. Yeah. And I think that if we're thinking specifically of consultants or maybe even like in-house developers that are both designing the things that they build as well as building it. For those people, then yes, you are doing all of these roles. right?

You're doing the research, you're doing the prototyping, you're doing the visual design, you're doing everything. That's what I did when I was a, a consultant as well. That was my role of like, you're doing a little bit of everything and you need to know enough about everything that you can do a little bit of everything and that's fine.

'Cause that's what the project calls for. But to your point of, like, finding the value in it. And I'll take it actually back to like , the example you gave before, you put together a, scheduling thing and the company was like, or the people, I wouldn't say the company, the people-- it's more important-- were like, "Yeah, this isn't resonating. I can't work and use this." And to me that was always the thing I sold. The way we would always sell it is, we are going to do the work in a way that when we have to spend the hard time coding, 'cause like, coding's hard, it takes a while, it takes a lot. And you wanna be sure, as much as you can be, that what you're building is going to work and is going to solve the problems in the way that it's going to be helpful to people. And so this is why, I don't know how long ago this was probably like eight years at this point, but like would give sessions about prototyping and how to do different, you know, levels of prototyping.

And for me, that was the biggest part of design. That was the sell as a consultant with design was, "We're gonna prototype this thing and we're gonna do it in a way that allows you to have an experience with this. And pretend that you're using it, but it's going to take me as the designer a few hours to put together the whole thing.

Maybe 10 hours. Instead of the hundred hours it would take to actually build everything. It's gonna be 10 hours of design. It's gonna be a few hours of research. Gonna be some back and forths. But overall, that's gonna be a lot less amount of time than us assuming we know all the answers to everything and then build it and then find out three- quarters of the way through the project that like, this is not how you actually work. Or this is not actually gonna work for you. And so we had prototypes that were like, basically this is every screen and you were able to click through and do everything that you wanted to in your system in a clickable prototype.

And we would usability test that with our clients and get them to do that. And that was how we sold the design. We, we know when we get into coding that like, we're building the right thing for you, and you've seen it and you know what it's going to be too, so you feel comfortable with it as well.

So that was, that was our way of dealing with...

I, I totally agree.

It makes sure that you and the client are on the same page and it allows you to do a bit of work to validate that. And then they have confidence that you know, and you understand them, and then you have confidence that you understood them correctly. You're not gonna have, you know, a nasty surprise at the end where they're like, " This isn't what I was thinking," or, "Isn't this included? I thought it was included." You have an opportunity to kind make it a lot clearer about what you're building and also it helps you to estimate as well. You can estimate a lot better when you do that because you have some idea of what the scope is.

And the other thing too, I wanted to pick up on, is that one of the reasons the software doesn't always work is because you're not sure that you're solving the right problem, right? A lot of times what they come to you, what they think is the problem is not the actual problem. And so you need to go and find out, "Well, what is the actual problem? What are they actually trying to do?"

Because what they come to you with might be much more of a symptom, you know. "People are too busy" or something like that. Something very vague. And it takes a lot of research to figure out, okay, well, what is their actual problem?

And then once you have the problem defined, then you can go ahead and build your solution, and you have a lot more confidence that you're actually solving the right problem. And of course I have a module in my course about problem solving, for that reason. Because I've, I've come to it so many times, where a client will come and they're, "Okay, here's my problem."

And then after you do a bit of talking and interviewing and bit of work, you discover, actually that's not exactly correct.

It's harder than you might think to disentangle symptoms and actual problems. That's not always straightforward and easy to figure out, even though it seems like it should be. You know, they don't know what their process is sometimes, they have a bunch of different processes, so it's not always clear exactly what the solution is. And you have to take a step back, I think, as a designer, and be a bit humble and say, "Okay, I actually, I know technology really well. I know my software really well. I know my platform. I know how to solve problems. But I don't know this client's business. I don't know all the people who are working there. I need to get to know them and I need to not assume and walk in with an assumption." And this goes back to something we were saying right at the beginning, because I'm not gonna be the person using the software, right?

It's gonna be these other people.

Yeah. I, I think if we wanna come back to the title of the podcast of like, everyone can be a designer and we then come out with at least one thing to remember as part of all of this is that, aside from the skills to learn, which I'm sure we will cover in detail in other episodes. But the first thing for me that was useful in transitioning from my work as a developer or developer- adjacent into doing design, was a bit of ego death. Of like, "You do not know the answer. Do not assume that even your best thing that you think is the answer today is actually going to be the answer. Until the problem is solved, you do not know the answer."

Everything you have is a hypothesis. And you need to be willing to throw your work away and throw ideas away and be up for that and be like, "That's okay. That if this thing doesn't work, then it doesn't work, and that's fine." Or like, "What did I learn from that? Where do I go next? What do I think will work?"

And until it's out there in the public, and people are using it and it's actually solving people's problems and saving them time or whatever your metrics of success are, until you know that for sure, then you don't know. You just need to be willing to accept that. And again, do the work along the way to narrow that gap of unknowns. Of like, "I'm pretty sure this is gonna solve the problem. I feel a lot better about it now, and I'm gonna do the work along the way that gets me to a place where I feel comfortable with it."

Yeah, I feel like at the beginning I use this metaphor of painting or sketching. Like just, you're drawing it in pencil at the very start, right? Because you're not super sure exactly what the parameters are yet, and so you're just drawing on the page very lightly to get a general shape of things.

And then, as you get more and more information, as you become more certain, then you can start drawing those strokes more confidently in pen or marker. And then you start coloring it in. I'm sort of mixing my painting and drawing metaphors here. But um, you know what I mean, the fact is that you're trying to, at the start be very open-minded about what is the problem, who are the people, and not jump to conclusions too quickly. Because as soon as you do that, you end up on the wrong path. I can't remember what it's called, but there's a feature of people's brains, which is like, once your brain thinks it has a solution, it becomes very difficult to get off of that track. That idea keeps asserting itself and it blinds you to other possibilities because your brain's like, "No, I got this, I know what this is." And even if you want to, it's really hard. So for me, I found the best thing to do is just take a step back and always feel like you're holding lightly to your goals.

A bit zen, you know, or, or Buddhist, where you have these goals.

but you're holding lightly to them. You're not clinging to them, and uh,

you're willing to let them change if you find new information right? In the face of new information, then the thing can evolve and change.

Yeah. There's a phrase we use a lot-- buddy of mine, Joe, he was the one I heard use it the most, and I'm sure he wasn't the one who created it. But it is a phrase I tend to use a lot, which is, " Strong conviction, loosely held." just this idea of I'm gonna, I, ,"I'm gonna come into a thing having a strong conviction that like, "Yes, I think that this is going to be the answer," but I need to hold onto that very loosely and be willing to throw it away or have that challenged and then be like, "You know what, maybe there is a better way."

And on that same thing, like always trying to validate. Like, what are the ways to validate that you're going in the right direction? That you think that this is the answer. What do you need to do to test that that's the answer? Again, prototyping is a version of that. It's one way of doing it.

But it's not the only way. What are your different ways that you can test your assumptions and test your ideas along the path to learn more? And that you're not done learning once you, like, you don't just do the research at the beginning and then you're done. Research is happening throughout the whole project.

It's just happening in different ways with different methods, with different techniques. But it's always about learning to get closer to whatever that solution is.

Yeah, I absolutely agree .Completely. I actually don't do a ton of prototyping. I do wire frames and workflow diagrams and I guess it depends, you know, prototyping is always a little hard because when does it warrant a prototype? How much do you put into the prototype? But I sense another podcast episode in that conversation.

So we're not gonna go there just yet.

That's for sure. Yeah, we can, I can talk about that for hours, that's for

sure. Yeah. Well, and that's what I like as, as well, is we have slightly different approaches. I don't think we work in exactly the same way, but that's good. I think that we can all learn from one another, and there's not just one way or one right way of doing it, which maybe makes people uncomfortable.

Maybe that's the thing that people find about design is, if you're coding it works or it doesn't work. But even there, there's multiple ways to achieve the same results, right? And it's not always the same path to achieve the same result at the end. So it's not that different in that regard, but perhaps it just feels a little bit more nebulous in terms of, "What is the right thing to do?"

Yeah, I mean, it is about figuring out and understanding, "Here are all of the tools at my disposal." Different methods, right? Different types of techniques and things you can do. Ways of facilitating, ways of diagramming, ways of describing.

It could be a prototype, it could be a flow diagram, it could be a journey map. There's so many different ways to do research, to communicate information, to get buy-in, to facilitate conversations. But knowing when to use one versus the other is tough 'cause it doesn't feel as cut-and-dry as like, "Oh, I need to send an email. Well then, what's the tool I use to send an email? Well, the one that's called Send Mail." Like I, know the answer --it's in the name. Um, It's not as cut-and-dry as that. Or at least it wasn't for me. And so that was my learning journey, trying to become a designer.

Yeah. Absolutely. Alright, well I think that's a wrap for today.

Thank you so much, Matt for being on this adventure. I have no idea what I'm doing, but, that's

Hey, we'll, we'll figure it out, right? This is, is what we do. This is our prototype. We're learning as we go. So give us a little grace please, Audience.

We're experimenting and we're learning. It's all a learning curve.

Well, I can't wait for our next conversation, and until then, well, you know, have a great day. I don't know how to end this.

Yeah. This is the first time, right? So we'll just say B, b, b. Bye everybody.

Bye.

Thanks. Bye.

Do we wanna do it again?

No, that's fine.

It's good.

Make it awkward the first time I think it it endears people to us. And then you can fade out as I'm saying this.

Thanks for listening to the Everyone Can Design podcast. To view the complete show notes and all the resources mentioned in today's episode, visit www.everyonecan.design. Before you go, make sure to subscribe to the podcast so you can receive new episodes as soon as they're released. And if you're enjoying our podcast, please leave us a review.