In this episode, we talk about why it’s so important to have a design process to create an amazing UI or UX. Without any sort of process, you may—or may not—be solving the right user problems. But if you learn and follow a good design process, you can vastly increase your chances of UI/UX success.

Listen in to discover why it’s crucial that you understand the people who’ll be using your solution—and the problems they face, when and how to include them in the process, and why it’s essential to validate your ideas before you invest a ton of time into development.

We also touched on the importance of good communication throughout the design process.

Whether you’re a seasoned designer or just getting started, this episode is packed with valuable insights and practical advice.

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.
• About IDEO: Our Story, Who we Are, How We Work
• Software Estimation - By Steve McConnell
• Mapping Experiences - By James Kahlbach
• FileMaker UI/UX Design Community - Join our Facebook group!

Ep 2. Design Process

Sometimes we start projects and we just get started. We don't even know really what success looks like.

If you actually create the software, then you'll know how big it is once you've done it. But we're trying to get that before we actually invest all this time creating something.

Now we have to do a lot more scoping work at the very beginning to be like, "What are we actually solving? What is the output we're creating here? And let's define those and set some metrics around that so you can then measure and validate that.

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 mor--at www.everyonecan.design.

In this episode, we talk about how your design process can make or break your UX project. Without any sort of process, you may not be solving the right user problems. But if you learn and follow a good design process, you can vastly increase your chances of UI UX success. Whether you're a seasoned designer or just getting started, we hope you'll gain valuable insight from our conversation.

Matt, last week you said something really interesting. You said, when you were building things, you thought you understood people's problems. You thought, "Hey, all you need is a piece of software, I can build that piece of software." And then you realized that you had improved some things, but overall maybe you weren't actually helping people solve a core problem they had, or perhaps you were shifting the problems to another area.

Yeah. There were times where we were successful, right? We built stuff, it helped people. It was obvious. And we're like, "Oh, that's great." But there were also times when you think you're doing the exact same thing that you were doing the last time. And then you get to that implementation phase. You get kind of late in the game. You've already built everything, and you hand it off to them and you're like, "Oh, maybe we didn't actually solve their problems the way that we thought we actually had."

I realized it was more of a crapshoot in that case. There wasn't anything in there that was obvious of, "How do we replicate that every time and really solve their problems?" So that was kind of the impetus for me to like, figure out, what do we do differently? How do I do this differently?

So how I solved that issue when I was doing design was to figure out a process, and to understand, okay, "How do I actually approach a design from the beginning so that I have some idea of what steps do I need to do, in what order, so that at the end, I actually can produce something that is going to be effective?"

I actually developed my own process. And now it's based on a lot of other processes out there that are more formalized, that already exist. And I call it the 5-Step Workflow Design Framework.

Step one is to define what it is that you're building. So, define your scope. Define your actual problems. What are the problems you're going to be solving?

The second step is to research. So you're going to figure out your information architecture based on understanding who is going to be using the application, what the data is going to be inside of that application, and what kind of goals the people need to actually achieve.

The third step is to visualize it. So you're creating wireframes, you're creating sketches, you're figuring out which design patterns you should be using, which screens do you need, that kind of stuff. The fourth step is to build it, and then the last step is to test it.

And then you might have to go through some of these steps again. And we talk about this iterative cycle where you're going around and around. So if you test it and you discover, "Hmm, we missed a problem that we didn't know about," you can go back, define that problem, research it, visualize it, and so on.

So that's the basic process that I use. Is that similar to what you are doing? How are you doing it? I know you're in a sort of larger environment with more people involved, larger teams, the applications are reaching more people. So I'm interested to hear your perspective of how is it the same, how is it different?

What, what's your take on it?

Yeah. I think, well, when I wanted to become a designer and, and get into it, I started researching and searching for people that had stuff online, and what was out there for me to look at. And I would see things from IDEO and the Stanford D-School, I would see stuff from Adaptive Path at the time. I would see their different ways of describing a design process. I was confused at the very beginning of it, of like, "Why are all of these people top-in-their-game designers, yet they all have different language and different ways of describing what this process is?"

And it had always confused me--again, you know, coming from that developer mindset of, "Well, there's like rules and you follow the rules, right? There's a process, there's a thing. And I struggled with that for the longest time until I really understood each one and I realized like, "Oh, they're all kind of saying the same thing. They're just using slightly different language to mean the same stuff."

But then later I realized, " Oh, well, there's a reason, though, that all of them say it slightly differently, and it depends upon the place in which they are designing." You've probably worked over time to define like, well, this is my process because it works for me, for the work that I'm trying to get done, with the people that I'm working with and the output that we are expecting. And I similarly had a process that was pretty similar to a lot of the stuff you see online of, all right, there's research at the very beginning, whether you're calling that empathy, whether you're calling that discovery. Again, a number of different bits of language that you could use. But there's research that's happening at the very beginning to understand the people and the problems. You obviously have a hypothesis of what problems you're trying to solve, but you're trying to really understand the problems and do deep dives into that and do root-cause analysis. But also understanding who the people are and what they're trying to achieve, where they're coming from, what their mental models are.

There's the definition of like, all right, here's the actual problems we're solving. Here's the people. Here's their mindset. What have I learned? How am I going to define that? And let's all agree upon that. And then it goes into like, let's ideate on solutions. Let's figure out what are the different ways we could solve this problem. Let's then, design that, winnow down to the exact things that we want, the exact solutions we want to go for.

And then throughout that process, constantly finding opportunities to validate, but also validate as quickly as you can with the least amount of effort. There was a phrase --I can't remember what book it came from-- but I would hear one of my old coworkers, Steve Lane, say it, a lot, called The Cone of Uncertainty. And that like, if you imagine a timeline of me working on a project that at the beginning, the opening of the cone is very wide because there's so many things that I don't know. And the opportunities of where I could end up are huge. But over time, I'm doing work to again, winnow those down and learn more, and validate more, and find the things I need to do to the point where I get to the end.

Now the funny thing was that when I was using that process as a consultant, that was our discovery phase of, or discovery part of the work. We then created a Statement of Work, said, “This is what we're going to build.� We would have in there, then, usability testing, some of the stuff you said at the very end. We're testing that stuff to make sure it's working the way that we expect it to and the people understand it. That would then happen after.

The thing I deal with now, where I'm working in corporate, when you're like, "Oh, I can't follow the same process every time." The problem and the output are different for each of the different projects I'm working on.

And so now we have to do a lot more scoping work at the very beginning to be like, "What are we actually solving? What is the output we're creating here? Is it a software solution? Is it a process? Is it just understanding and alignment by people? Is that the only thing we're designing?" And then from there, working forward of like, "All right, what is our process going to be like for this project?" And we know the basic formula of it, of there's research, there's definition, there's ideation, there's design or creation. But the things that you're doing along the way are completely different. So the question I'd ask back to you is like, okay, you, you talked us through what your process is. But I'm curious how that has changed over time or, like, where it came from and then how you got to it here based on the projects that you've worked on.

I came to it partially because I wanted to be able to repeat the process. So I think originally I was doing these steps, but it was more haphazard. They weren't as clearly defined in my mind. I had a client a few years ago before I did my talk in 2019 on workflow-based design. I don't know if you saw that talk, but, it was really pivotal for me because I realized certain things about designing.

The way that I came up with it is that it was a brand new client and I met with them and they had certain problems that they knew they wanted to solve. One of them was a lack of transparency into what a particular department was doing. They didn't know how much time they were spending on certain types of work. So they had a very clear goal that they needed to accomplish.

And normally what I would do is I would take all the information they gave me, I would go back, I would look at their existing screens, and I'd try to figure out how to just get it all on the screen, like, put it all onto a layout. And this time I said, "Okay, wait a second. What if I were to actually start with their goal and figure out how do I get them where they need to be? And rather than starting with the data, starting with the information that they want to collect, I start with the people who need to put in the information in order to achieve this goal down the line?"

The second thing that happened on that project was, I ended up not having any list views. So they had a very standard form and list pattern that they were using, which is very common. I, I like to think that people are doing it less now because it's not as useful for them.

'Cause of the fun of mobile design, right? The idea of list and detail. It started to go away a little bit more.

That's right. So I ended up not having any list views, and I remember the client asking me, "Where's my list view?" And I said, "Do we need a list view? Is there something that you're missing that we need to display in a list?" And the answer was, "No, I just feel comfortable with the list view" essentially. And I said, "Okay, well, if we get to a point where we need a list view, we will make one." And we actually didn't get to that point.

All this to say is that I started thinking a little bit differently about how do I actually design? And then I took a step back and I said, "All right, what if I were to really sit down and formalize these steps?" And given my previous knowledge of other projects that I've been on, I know that doing the design upfront will save me time. But this was the first one where I really embraced that wholeheartedly. And I worked out my process mostly, I think, through that particular project. But I also had projects after that. And then I started to refine what it was that I was doing.

Then I also, like you, did some research and I said, "Okay, well what are other designers doing?" We're not the only ones in the world designing applications. How are other designers out there doing their design process? And like you, I saw Design Thinking, IDEO. Probably a few others as well.

And then when I wanted to teach design, I had to further formalize it and make it into a process, because now it's not just me knowing what to do in my head, I actually need to explain this to other people and teach them how to do this process. I found my process wasn't exactly like some of the existing processes and I said, "Okay, that's all right." I'm in a slightly different niche. I have slightly different types of clients. We're not doing websites, we're doing very robust business apps. So I'm okay with having my own process and calling it my own thing.

What's interesting, though, is that I actually do the definition first and then I do the research. So as I said before, on that project I was just talking about, the client already had a specific problem. They had already defined what their challenge was. And so that formed the scope. And the first step is, what are we building? Why are we building it? Who are we building it for?

Clients can buy any software off the shelf. Clients can go out and buy Salesforce. They can buy SAP-- maybe that's out of their budget. So why are they asking you to build it? Why are they going with custom software? So that's really important to know because that will give you your measure of success.

Sometimes we start projects and we just get started. We don't even know really what success looks like. So it's important for me to do that definition. Then I can do the research. And I also talk about the Cone of Uncertainty too. I learned about it from Steve McConnell, who is an...

That's right. That's where it's from. Thank you, actually remember where it's from. I just heard the person that quoted it all the time.

Yes. Well, I read about it because that's the other thing that I was struggling with is, how do I estimate?

People were asking me, how long is this? And I used to have a client who used to like to say, "Well, how long is a piece of string?" So we have to measure it first, right? If you actually create the software, then you'll know how big it is once you've done it. But we're trying to get that before we actually invest all this time creating something.

So for me, it is investing that time up front to define, which is relatively short. That doesn't take a huge amount of time. Usually people come to you with their problems. They kind of know what their problems are. They have an idea. And then you might need to do some digging, which is the research part. You're validating, as you said, you're asking questions, you're talking to their staff and finding out from them, from their perspective. 'Cause a lot of times management will be the one calling you in and they have their own agenda, right? They have their own idea what the problems are. But the people doing the work, they might have a slightly different perspective. So it's important to not just impose on them, but just ask them, right?

And then the Cone of Uncertainty... again, at the beginning of the project, the cone is very, very wide. There's a big bunch of stuff. It's just a heap of undifferentiated information, and then you have to kind of make some organization out of it. And as you do that, your Cone of Uncertainty gets less and less because you understand things more and more.

Yeah. There are a few things there that you said that resonate. I think one of them being we take it back to where you said like, "Well, where's the list view?" You probably didn't ask this question exactly this way, but you said like, "Well, why do you need it?" The way I would reframe that question would be like, "Oh, what were you hoping to get done with a list view?"

It's also opening it up to that conversation of, "There are things I might have missed here. Tasks and jobs that you're trying to get done that I don't know about yet. I'm not going to expect that in all the conversations I've had with you that you've said every little thing that you hope to do and get done." And that's actually one of the biggest problems obviously that happens in a lot of software development. We've all dealt with it before of like, you think you have that perfect requirement and that perfect spec, and then you get to the very end and you're like, "I built everything that you said you wanted."

And then they're like, "Well, where's this?" Like, "We never talked about that." Or, "We talked about it, but then I said I wasn't going to build it 'cause it's going to cost you more money and time and whatever." And that's always the toughest part of the conversation. But I think it's a realization that so many of us have, to come back and be like, we're not going to get everything. There's going to be stuff we miss. So when that comes up, instead of turning it into a conversation about like, "Well, you didn't tell us," it's a conversation about like, "Well, what are you trying to get done?" And then, hopefully you've built up enough rapport with the people to be like, "All right, so this is the first time we're hearing about this. How do we deal with this?"

In one of the last consulting teams, I was on, we had a thing built into all of our SOWs called a contingency budget, which was specifically for this. It's like, "Hey, your budget for the project is all of this, plus this little bit of extra." And they're like, "What is that?"

I'm like, "Well, we've probably missed something. Let's just, just all agree upon that. And we might not use all of it. We might use all of, we might have to go more than it, but we're going to build in a little bit here for the small things that we've missed, we'll come back and get to."

So I love that ability to have that conversation and say like, "All right, I, I tried something, I went out on a limb here and didn't do the thing that I would normally do, because I didn't see the need for it. Like the need never came up for that thing, so I'm not going to do it." But then like, when the person then asks for it, that's a great opportunity to have that conversation. Like, "Well, why? What are you trying to get done? What do you do with that list view? What do you learn from that list view?"

And have them try to articulate that is part of the fun of doing design, right?

Absolutely. Also, one thing I ask quite a bit in my meetings is, "Is there anything else?" I learned to ask that question, because often there is. They may still not mention something important until very late in the game, it still happens, right?

I've been on a project where you're a couple of months from launching, and suddenly you discover a part of the system that they never told you about before because it just didn't occur to anybody.

Totally. Yeah, "We talked about that on the third day, right?" No, we never, you said that to us.

Or sometimes it just legitimately doesn't come up. Or perhaps the person who uses that area just hasn't been in the room. So that's another thing I try to do is get all of the people who are involved, who are going to be touching the solution in some way-- especially if they're going to be using it-- I try to get them involved as early as possible.

Yeah, totally.

So this question, "Is there anything else?" does help to unearth some of these unknowns and it helps people to think about, "Oh, is there anything else I need to mention that we haven't already talked about?" I always conclude meetings with that, and sometimes it's truly done and that's good. But that's really helpful, for me, in terms of trying to find as much as possible.

Yeah. At the beginning of every project, you are hoping that you are in agreement with all of your partners or stakeholders or clients. And like, "All right, we're solving something that looks like this, in this general direction. That's cool. We generally know what problems this thing has, that is the reason, the impetus for why we have asked you to build this new thing." So I think there's general agreement on that.

The thing I always bring up is that is based in your collective knowledge, which is correct at a certain level, but is potentially missing things that we don't have yet. You want to at that point as much as you can, start to agree upon, "What are the goals of the thing that you're launching? What are you hoping to achieve out of this? Is it savings and time for people? Is it about getting things out faster to your clients? Like, what is it about? What are the things that you're hoping? And let's define those and set some metrics around that so you can then measure and validate that at the very end of the project."

Going from consulting world back into corporate world... In the consulting world, in many cases, like, okay, you finished the project and there's a few little things you clean up and you probably have like a service agreement, or some sort of maintenance agreement that you're doing with them.

But there's normally not, in many cases, that time to come back and be like, "Did we actually solve the problems? Did we actually, can we measure the ROI of this amount of time and effort and money that we spent?" And a lot of that doesn't really happen when I was in consulting, at least I didn't see that in a lot of the places I worked for.

But it's something that I'm now seeing a lot more in corporate, because we kind of have to speak to like, "Why did we spend so much time and energy on something someone in leadership wants to know?" And then also you have the time to do it, in many cases.

I do encourage that on my projects as much as possible. First of all, to define what they're hoping to achieve, and if there is something measurable, if there is an ROI, what is that ROI and can we actually measure that? At least you're attempting to measure it. You're attempting to move them towards a future where they can realize that ROI.

Now, whether it happens or not, whether they actually are able to measure it or not, that may be a slightly different story. But I think it's really useful, even if you're not able to do the metrics after the fact, to even just have that in your mind. Because then that becomes your guiding light of, should I be doing this feature? This is what we're trying to achieve. You know, we're trying to, uh, get the project from estimation to invoice as quickly as possible. And they're asking for, I don't know, like a PDF report that someone uses once a year. Like, is that going to help us achieve the goal, yes or no?

And I think sometimes what happens is clients get excited when you're there to help them to solve their problems, and they start throwing all kinds of stuff at you. And if you chase those rabbits down the road, you end up getting sidetracked off of the main problem you're trying to solve.

Oh yeah.

And then they get upset because they don't have enough budget left to actually finish the stuff that they wanted you to do in the first place.

Yeah. The stuff they need.

Yes. So what I try and do is, take all of those, write them down, create user stories of everything that you hear. But then, really be rigorously about prioritizing the things that you absolutely must do to get them from where they are now to where they want to be.

And it doesn't mean that you have to throw the rest of the things away. You know, people get excited in a meeting and there's all these ideas and you don't want to squash people's ideas. At the end of the day, they may end up falling to the bottom of the list. I have a friend who says "down the road," right?

And sometimes "down the road" means it is never going to happen. But at the same time, you may actually do some of those down the road, but they're just not as big of a priority. And it helps you to really focus on what do you actually need to do, because the clients themselves have the potential to sink you and make you look bad because you didn't tell them "No," enough along the road.

And that's why it's also so important to do this ideation phase, discovery, whatever you want to call it, this work upfront where you're really writing down what it is that you are expecting to give them. But also, some amount of, how is it going to work? Some amount of user stories is what I suggest, right? "Here are the user stories. Here's who is going to be using it, this is what they want to accomplish, and this is why." Right? And then that way you have something you can use to estimate. And then, you know, do these user stories support solving the problem that we defined in the problem statement?

So I, I guess I do think that we should be doing the ROI as much as we can. Sometimes it's not possible, but even for our own selves, even for the part that we're involved with, which is defining and building the software, that is helpful in my opinion .

Yeah. Back to the idea of a design process and I need to constantly be communicating to the point where people know like, here's the time I'm spending, here's the effort, here's the money. 'Cause that's a lot of money. In startups or in corporate worlds, there is definitely scoping in terms of like, how long is this going to take? When is this going to be launched? How many people from the team are you using? Do you need more people? There's a little bit of that. It's a little bit less.

Those kind of money conversations aren't happening as as much as prioritization conversations like, what am I prioritizing? But in either case, it still does come down to that idea of, what are we doing? Like, what is the reason for what we're going to do? Who needs to be involved? What are we hoping this thing solves? That going into the beginning of what we tend to call like foundational research, because, like, you're doing research and checking back in with people throughout the process.

But at this very beginning, it's that, "Okay, let's understand this thing-- and the people-- and let's understand it as best as we can. The things and the people." and it's like, all right, I'm understanding those things. I'm defining the problems that we're solving and really getting to like root cause and like how we want to solve them. If it's a really wicked problem and we don't already have an idea of like, " We're building software." Then, you could be like, "Well, it's this problem with a part of a city, and we're trying to figure out what we're doing with that part of the city, so what are we going to do?" Well, the ideation can be huge, right? The number of options for you is huge. So we need to, like, take that time. But you do that ideation, you figure out, what are the best ways to solve that problem? You validate. You slowly hone in and create better designs, start building stuff.

That's where I get into, like, prototyping and that kind of stuff. I love that kind of work. I love prototyping and different levels of prototyping. And then from there, like you're, now you're getting into software development. That's where the design process starts to end, and becomes now a software development process. And that's another thing that like, again, corporates and startups have to deal with, is the idea of shared process. Design has its process that it's going on to try to solve the problem. But our product teams have their own process that they're going on in terms of like getting everybody prepared, and going through legal, and having all of the different i's dotted and t's crossed and whatever. And so they have their process that they're going through to try to get this thing done.

And Engineering teams, they have their own process that they're going through. So where do we meaningfully connect to make those things happen so that it's a smooth transition from one team to the next and the thing gets built properly? But like, realizing it's not just a design process, it's a larger process around design and building. And like, that's the fun of this, is design is just one element in this larger thing that is trying to get whatever we're designing out into the world.

Yes, I totally agree with that. I was going to pick up on something you said, which was root cause analysis. Root cause analysis is so important. I think we touched on it a little bit last week, where we said, "symptoms versus causes." And I think it's so important for us to not just take the client's word for it of, "This is my problem," because that's the problem that they see, but they may not understand what is the underlying problem.

It may be coming from different parts of the company. Maybe it's a cultural thing about tracking time or something like, people have never been asked to do it and they don't want to do it, but the company needs to know where the time is going. Are those software problems, are they people problems? Are they process problems?

Yeah, now you're getting into a whole 'nother area that I, I could spend hours talking about, which is, "How do you get people to do stuff that they've never had to do before and see as extra work?" That's a whole 'nother thing.

We, we will get that 'cause I have a way of dealing with that as well. The other thing you talked about too was validation. So once you've done this root-cause analysis, you have to discover of whether or not the solution you came up with actually works. And to me that means bringing the people in...

Oh yeah.

early in the process who are going to be involved, especially if they're going to be using the system and you want to make them feel included-- and it's not just performative. You don't want to just make them feel included, but they're not really included. You want to both include them and make them feel included.

You don't want to just have them fill out a form and send you a bunch of information. If you can talk to them and say, "Hey, you know, Management has asked me to create a piece of software to help with this problem. Tell me about your experience with this process, or tell me about your job. Tell me, what are your pain points? What things do you struggle with? What do you think you do well? Or what does the company do well?" When they feel included, it's much easier. If they feel like something's just being imposed upon them from above, some people will just revolt.

They just won't do it because they don't understand why. "Why should I be doing this? What's the point?" If you involve them, then they feel a sense of ownership and a sense of contribution, and you genuinely value their contribution, even if it means sometimes you have to say," No." They might ask for something , you might say, "That might not be possible," for whatever reason. But just the fact that you're there to listen, to hear them, that to me is a really important part of the process. I guess what we talked about was empathy, right? It's a form of empathizing, a form of communication, a form of listening and being open, being humble, having hypotheses, testing them.

And that's really important I think, in design, right?

Oh yeah. It's not just about bringing them in early, but it is about bringing them along on the ride at the right times. As an example, there is what I tend to call foundational research. I'm talking to them, I'm saying, "Hey, we're here to do this. I want to understand your role in this and who you are and what you try to get done and what you value. And also like, where does this fit in your workday and all the other things that you're doing?" We're doing that kind of a foundational research to understand the people and the problems.

But then, if I can bring them in for ideation in certain cases, I will. There's definitely a whole idea around what's called co-creation. Like, let's not just have this be something that we're designing and then giving to you, but it's something that you have a say in.

I did it a little bit less when I was in consulting, 'cause again, we all kind of agreed that the solution was going to be software at a certain point. But if it got to outside of software, if it got to like process change, if it got to other things, then I would bring them in more, because that's a bigger thing that I want them to have a say in.

Also then, as I'm designing stuff and I'm starting with paper prototypes and then moving up to low-level mockups and high-level mockups, I am coming back to them and saying, "Hey, here's this thing you told me you do," or, "Here's this thing that you told me is part of your job."

"Here's this thing I designed, and it's still early, or here's a few different versions of it." Maybe I created three on paper that are just like, literally a Sharpie on a piece of letter paper, you know? And I'm saying, "All right, let's take you through. I want you to pretend this is a screen and use your finger and click on it. What would you enter here? Let's just write that on a Post-it and throw the Post-it in like it's a field that you're filling out." And I would have them do that kind of work and then get their feedback from that of, "What felt natural, what felt right? Where did you have troubles? Why were you having troubles?"

And then from there, you're honing in that Cone of Uncertainty. I'm honing in like, "All right, here's how they see the world. Here's where their issues are." But then again, as you said, it gives them the feeling like, "I have some sort of say in this and I can see what that output's going to be."

And then throughout the process, as those prototypes are getting more refined, I'm coming back to them, and I'm doing it again. It's like, "All right, we're closer here. We think it's going to be like this. What do you think?" And, actually, I should take that back. I'm not asking, "What do you think?" That's not the question.

It's, "Try to do this thing and walk me through how you feel about doing it, and what your thought process is as you're trying to get it done." And then using that as an opportunity for conversation around, "Okay, what are we missing? How is this hard for you? Where can we improve this so that it makes your life easier or it achieves the thing you are trying to achieve for that specific job that you're trying to get done?"

Yeah. It's so interesting. We were talking a lot about language... Asking the question, "What do you think?" versus asking, "Please try and do this process." You know, framing the question is so important. I actually never ask clients, "What do you think?"

Yeah, I never ask that either. Yeah.

Or, "What do you want?" Because...

Oh yeah. Yeah. That's even worse. Don't don't do that.

They don't know. They know what they want to achieve, though. If you say, "What do you want?" you're putting the onus on them to figure out what the problem is, come up with a solution. In my opinion, you're not just there to execute their vision. You're there to help them actually solve their problem. One thing that I use quite frequently are workflow diagrams. And, you know, in this world of always being virtual all the time, sometimes you're not in front of them physically to do a paper prototype.

But I often will screen share and I will draw diagrams with them during the meetings and ask, "Okay, what happens first? What happens next? Okay, So then there's a choice here," and I'll walk through it. And the reason I do that is because that way they understand that I know what they're talking about.

Yeah.

That I understand that we're talking about the same thing. We've got something on paper and it's a lot easier to estimate it at that point because you've sketched out mentally at least what the high level steps are going to be. And it makes it a lot easier to have the discussion and to make sure that you're all on the same page.

I don't know how many conversations I had early in my career, where the client thought that they were communicating one thing and I was understanding something else. We didn't find out until later that there was a mismatch there, right? So, these diagrams, are something similar to your clickable prototypes, are something concrete that I can show to people that they can understand and it makes sense to them. And if it doesn't make sense to them, well, then we work on it until it does make sense to both of us.

Oh yeah, there's a great book by Jim Kahlbach from MURAL, called "Mapping Experiences." It's one of like the O'Reilly series of, you know, animal books. I think there's a bear on it for some reason. But, in that, he does a great job of describing like those different types of-- I know you said workflow, workflow is an example-- but, customer journeys, service blueprints, swim lane diagrams, all of that kind of stuff that you might use to describe, "What is the process here? And then who are the people, and what are they trying to get done? Why are they trying to get that done? What are their mental models as they're trying to get those things done? What are their attitudes and feelings as they're trying to get that stuff done?" Super important.

And yeah, those different ways of diagramming that stuff is a great way of getting alignment across different people and making sure we're all speaking the same language before I then get to like design any sort of screen . Um, so yeah.

I had some students who'd ask me, "Are you sure we should be showing these workflow diagrams to the clients? Are they going to understand them?" And

Yes, you need to.

Well, I think there's just a bit of concern that, "I don't want to overwhelm the client. I don't want to scare them. I don't want to involve them in decisions that they don't know how to make, or I don't want to show them a bunch of jargon or stuff that is overwhelming."

But I absolutely think that the workflow diagrams, they absolutely can understand them, and I think it gives you actually even more credibility to do it in front of them. Show them, let them peek curtain. It's totally fine.

Yeah, I create them with them. I mean, that's the exactly like you said, like, I had one client, and I had just gotten like this roll of paper I from like a family member that was like, "Oh, we've, we got this like giant roll of paper, do you want it?" I was like, "Yes, I'll take it." And it's like like three feet wide and then, you know, just a roll that goes forever. And I, like, put that in my car so that whenever I'd go see a client, I'd have that and like a bag of Post-it notes --this is where the Post-its come in, right? As a designer, we have to talk about Post-its at some point, right?

Absolutely!

So I bring, I just bring that out and I'd like roll it out and I'd cut it and I'd tape it up to the wall. That was the blue painter's tape, right? That's your bag, if you're doing this in person. You know, this is pre-pandemic. Post-pandemic, it's like, just use Mural. It's fine, it's digital, it's better.

But, back then it was like, "All right, I'm going to bring this out and I'm going to draw a service blueprint on this thing. Here's backstage, here's frontstage. Here's all the different swim lanes. Let us fill this out together and let's talk through the different things that are happening and the different people that are doing these different tasks, and we'll do it together."

And I will use that to challenge certain things and challenge my own understanding of things and make sure I'm understanding it right, because I'm probably not, at first. So, yeah.

It's also important to allow them to correct you, right? You want to show them something so that if you're wrong, they can tell you where you're wrong. I think it's really important to set up those conversations and say, "This is my understanding. But if you see anything on here that you disagree with, or that you think needs to be further elaborated or, it's plain wrong, please tell me. Please! I want to know now. I don't want to find out three months from now."

Yeah, that's, I think for me, that was the thing I picked up when I got into design in the first place was that, "Hey, uh, you're going to be wrong, and that's okay." So again, that's what the process is for. How do I guide myself over time to challenge my own assumptions and make sure that whatever I think is right is actually right? And so, the process and then the methods that go into that process, I think, are what's useful. And actually, we'll maybe finish up with this, as like a, final thing, which is, some of these processes have now gotten a bad name out there.

There's these things where people are talking about, like Design Thinking and why it's good or why it's bad, or how it's not helpful. And I think the interesting thing that I've read in a lot of those places is people then thinking like, well, "All I have to do is follow this process, right? And now I'm golden. I've got it now." But that's just the backbone, that's the paved road for you. But you still have to know how to walk the road, and know, like, which direction you go. And, uh, you have to know the right things to take with you and be like, "All right, here's what we need to do, and how we're going to do it along the way." And then know how to vary those based on the client, the problem, the thing that you're hoping for at the end, what you know, what you need to validate.

And that's actually where the hard work comes in, and where, like we said, everyone can design, but you need to not just know the process, but you need to know the methods. You need to know the work. And maybe that's where we, like, get into in future conversations.

And I think that's really what this podcast is about, is that everyone is designing anyway. You The fact is the design is happening whether people are aware of it or not. So to my mind, if you are going to be designing, if you are going to be creating things, even just learning the lingo, even learning these confusing, sometimes, terms is important because it helps you put a framework around what it is that you're doing. It helps you to wring more value out of those meetings that you're having. You are designing the software because you're making decisions. You're putting things on the screen. So design as a discipline has many different areas. There's graphic design, there's interior design, there's all kinds of designing of things, and I think the world is only going to need more designers as time goes on.

This idea of communication, this idea of empathy, this idea of humility, hypothesis, validating. That's the same no matter what it is that you're designing. But I, I take those criticisms of say, Design Thinking of being, "Well, I'm just going to empathize and then that'll be good enough."

You need to start with empathy, but it really is about thinking about what the impact is that you're going to be having, how are you going to actually be implementing this-- that was another, I think, pitfall which is that, it's not just enough to come up with the ideas, you actually have to put them into practice.

For me, that's not a problem because I'm always doing the design with the software in mind at the end. And most of the people who do what I do are doing the same thing. In your situation, yours is a little more open-ended because you might be designing software, you might be designing something else, and there's different processes, techniques, methods that come into all of those things.

I do think that everyone is a designer in some respects, and so it's really about intentionally choosing to design and learning more about it. What you need to think about are people, how you're affecting them, how you're going to help them achieve their goals.

Yeah, and I think if there's one thing to take away from the conversation around process is that you will see different versions in different people's language of how they do it. And for me, the takeaway is just understand, that is based on the type of stuff that that person is designing, the type of problems that they're getting asked to solve, the types of outputs that they are creating. The high level stuff is the same.

If you want to be a great designer at a certain point, it's about figuring that out for yourself of like, "All right, well, here's these high level things that I know need to happen in a general order like this. And then, how does that change, based on the things that I'm designing? And what are the methods and tools that I need to do for the research that I need to do? How do I need to validate my prototypes, or validate the things that I'm putting together?

"How do I need to include people? What are the right methods for that, based on your client?" Again, who the people are, how, how much time they have to give to you. All of those things are variable and, like, you need to then know the methods and know the work to go and say like, "All right, well for this project, I'm going to do it this way."

And that's the thing I very much learned moving from like a consulting world into a more corporate world of like, "Oh, the possibilities of this stuff are endless." Because the, the number of types of projects I might get added to, that range-- everything from, like, "Yeah, I'm just designing a small piece of software," to, "We're designing experience of people taking trainings. We're designing new processes and new onboarding for people."

Very different than just designing like, "Okay, here's a piece of software for you." And knowing that, like through all of that, I need to do different things in order to get to those outputs that I need.

I think we can agree that having a design process is a good thing. You have a process, you can follow it, you can refine it over time. So that's the value of it, is to start somewhere, have a set of steps that you plan on doing and then see, validate for yourself, right?

The bottom line for me is having a process has helped me just be a much more effective developer, because I know what I'm doing.

It has made my clients happier, because I'm using their time much more effectively, they have a better idea of what they're getting at the end, and they have more confidence in their investment.

So I think having a design process is really nothing but good. So the more you can go out there and learn about having a process, whatever that process looks like for you, the better.

Yeah, and I think, yeah, something probably for a future conversation of, "How do you communicate what you're doing, to those people that are paying the bills along the way?" And yeah, being able to know what you're doing and what's next, and show them where you're at and how you're making progress, is necessary. But that's again, another, larger topic for another day.

See, if you thought we were going to run of topics, we really are going to for a long time before we run out of topics.

We've got so much stuff we can about.

Absolutely. All right, well thanks a lot, Matt. This was really fun. I hope people are inspired to go out there and figure out the design process for themselves.

No problem. Have a good one. See ya.

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.