Ep. #936 - SDLC: Design and Prototyping

Matt DeCoursey 00:00
And we’re back! Back for another episode of Startup Hustle. Matt DeCoursey here with Matt Watson. Hi, Matt. What’s going on, man?

Matt Watson 00:16
I’m designing and prototyping stuff. I’m just trying to, you know, build models. I got my popsicle sticks out. I got some pipe cleaners, my glue stick, and a little glitter.

Matt DeCoursey 00:19
Sounds like a weekend in my house with my four kids. Yeah, I stole a little glitter from my daughter. And I realized that was a really bad idea. I spilled the glitter, and now I gotta sell the house. Because there’s no way out of it. But yeah, so I mean, that’s what you do when you design and prototype stuff, right? You get out the popsicles. I got a bar napkin here, a golf pencil? Let’s do it. I think I found an erector set. Or just some rusty Knodel? I’m not sure it’s one. I’ll bring the Legos. No, because then I’ll step on them and get mad. Is there anything that hurts worse than stepping on a Lego with bare feet?

Matt Watson 00:55
Tax?

Matt DeCoursey 00:58
Well, we’re back for episode four of a and our foray into the software development lifecycle. For those of you listening, if you go back to the prior Friday episodes, we have three other episodes before this one that wants a general overview of the process. In 826, we talked about planning and just planning your software project in general. Nine-two, we talked about defining requirements. Today we’re going to talk about design and prototyping, which I’m gonna go ahead and say is a tough thing to talk about in an audio medium. I’ll tell you why right after I remind you that today’s episode of Startup Hustle is powered by FullScale.io. Hiring software developers is difficult, and Full Scale can help you build a team quickly and affordably and has the platform to help you manage that team. Go to full scale.io. And learn more, there is a link in the show notes for that amount. What’s your opening? What are your opening remarks about designing and prototyping?

Matt Watson 01:59
Well, so we started out talking about planning, right? And so, you know, and that one of the hardest things is trying to get the executive team, the management team to even, you know, all agree on what the plan is and what the priorities are. Right? So we started there, we got to plan, we got priorities, okay. And the next step is to do the requirements. So we met with all the people. We understand what it needs to do and how it needs to work. We understand all the details. Now you get to the next step is designing and prototyping. It’s like, okay, how do we do this? We know what the requirements are. So it’d be like, Hey, we know we need a car that can drive this fast, has this fuel economy, can hold this much cargo capacity, right? Like that would be kind of like the requirements. Now it’s time to design this thing. It’s like now we have to figure out how to actually accomplish those goals within whatever limits we have with this type of architecture. It has to look like this has to be this color, whatever has to be aerodynamic, like whatever the design requirements are. But now it’s time to go from the requirements to actually make it come to life and design what it would look like if it came to life.

Matt DeCoursey 03:01
One of the things I think that we have discovered and pointed out and tried to help clear through the series is the importance of various levels of expertise when it comes to either full-time members of your team or perhaps getting input. And this is another stop where we’re going to find the data as the case. So you know, over the last, I’d say really the last 10 years, the world of you, user interface and user experience have? Well, it’s getting a lot of love and attention. I thought 10 years ago, a lot of people had built a lot of back-end-centric software products that turned gears and did stuff inside the magical world of the server, and then as their products and needs evolved, so did the expectations of the interface. And that’s part of the design and prototype we’re talking about. And that all leads to the UX, which is user experience. And those two things together have turned into a whole segment of employees and x and expertise with the UI UX designer. And then well, yeah, and that’s, and you know, I mean, do you agree with the timeline of how that kind of occurred, because you know, 10 years ago, UI UX was trashed for so many of you, we were still like, mobile dot your site.com kind of stuff, rather than now. We have things that are a lot more responsive and kind of adapt to whatever savviness.

Matt Watson 04:33
I think, in some sense, I’m not a fan of them. But I think in some sense, we can actually think of Apple for this about 15 years ago with the iPhone, right? Like love or hate Apple. One thing that Apple has always done a good job of in almost all their products is creating good user extracts making an easy-to-use product. It’s beautiful. And the original iPhone did a good job at that. And for a lot of people. A lot of people didn’t like it and were like, oh, it’s not as cool customizable, I can’t do this, I can’t do that. But they’re like, look, we’re gonna make it simple. We’re gonna make it beautiful. And people, over time, have embraced that. And I think, you know that you know, in some sense, they kind of lead the way. And everybody else, you know, enjoys using beautiful simple software. Nowadays, I would say Android phones are just as easy to use as iPhones which are also more customizable. But their early Android phones were more difficult to use. I’m not gonna argue that. But in some sense, I could say we, you know, Apple have sort of led the way about 15 years ago, and maybe even before that, with the iPod and stuff like that, of making a simple and beautiful user experience.

Matt DeCoursey 05:36
Well, I don’t think that needs to be your goal. Because as I mentioned in the prior episodes, my role was to build software and answer the question, is this annoying? And if the answer is anything other than No, you have some more work to do. And that is directly related to user experience. And user experience can go wrong in a number of ways. And a number of places, too many clicks, too many steps, too many pages. Things like, you know, we went through this with Giga book, because Giga book is highly customizable. In fact, that’s the niche like I’m not we’re not, we’re not Calendly like Calendly is like a simple free tool to connect your Google Calendar to like your email signature. And it lacks customization, it lacks the depth and, and complexity that some people need when it comes to taking, you know, appointments, bookings, yadda, yadda, yadda, so. So with that, what we realized is we had all these switches, all these levers, and yeah, and it made a kind of a shitty user experience, because the question is, how do we even explain to you, show you or help you understand that those things even exist? So you know, so I think when you talk about design and planning and prototyping, if I was going to build a software platform, again, from the beginning, I’m going to start right where it starts, which is how do we get people into it? How do we build an onboarding and a setup flow that gets someone into a software platform with the minimal amount of effort necessary to set it up but the maximum amount of usability once they’re actually in there? Then there’s, there’s a whole school of thought around this too because you even look at like, Twitter is known for having the world’s simplest onboarding. It’s like, click, click boom, and you have a Twitter account. Yep. You know, so I mean, do you agree with like, now, if you had to start a brand new software platform, are you going to build the platform and then figure out the onboarding? Are you going to look at the onboarding first?

Matt Watson 07:31
So there’s two, there are two things that I would comment on. Definitely, when you’re signing up a brand new customer, and they’re logging in for the first time and starting to use the product, the most important thing is getting them to that aha moment, as fast as possible, right, getting them to see, like, I signed up for this thing, and now I see the value in it, and why would use it. So having a curated experience that can hold their hand, you know, maybe the software has to be pre-populated with data or test data to work with or whatever it is. So they can very quickly and easily get to that aha moment that is really important. And honestly, that was one of the big problems we had in my last company stack phi is, it’s like, well, they had to actually install it on their server or configure this thing, or configure code and deploy it. And like, it’s just really hard to get them to see value in the product if there’s like no data in it, right? Like, that’s really a struggle from that onboarding, user experience.

Matt DeCoursey 08:22
I think that the struggle with design and prototyping is that unless you have a masterful grasp on the entire industry that you’re trying to serve or provide solutions to, it can be very difficult to understand and know what is truly important to your future users. Like you can get as you can maybe hit some of that, and, you know, completely mess on the other side of things. And, you know, like when you talk about a gag about the way we saw this, as we created a thing called SmartStart. That just asked. It’s a very short number of questions like, do you want to use this for appointments? Do you make any group bookings? Do you want to take payments? Do you want to sync with calendars? You know, a few simple things like that? Do you want to send text message reminders? You know, and with that, based on those? Do you have more than one person at your company? And just those simple, yes or no questions would then tailor an experience and the design that set you towards the platform and only had to answer the questions that you needed. Now I know we’re talking about design and prototyping, but your design and prototype don’t matter if no one ever gets to it. And that’s why I wanted to kind of address this because, as you said, that aha moment. And the problem we have is people get we try to get people in as fast as you can. But then we’d get them in before SmartStart. We got them onto the platform, and they couldn’t even schedule an appointment, or they had to go to eight different places to set stuff up. So they didn’t stick around. There was no Aha.

Matt Watson 09:49
So that, you know, we talked about the onboarding part of it, but then, you know, just creating a very good user experience and every aspect of your software even past the onboarding is important. Yeah, right. And, for example, I’m more into software right now that has to do with configuring AdWords, you know, ads and budget, all that stuff. And the target audience is a plumber who is on a job site somewhere and needs to modify his marketing. Yeah, it’s got to be really damn simple, right? Like, you know, we but the problem is like, oh, there’s like these seven custom optional levers and switches, like you said, like, well, what if they need to make the ad go to this different target URL, or they want to set a different target ad budget for this thing, or whatever, like all these optional things, it’s like, you know what, 95% of people don’t care about any of this. And to some degree, you’re like, what we’re not going to do, we’re not even going to worry about what the 5% care about because we know it would destroy the user experience of the other 95%. And that’s always the hard thing, especially if you’re selling enterprise products, and this is what makes enterprise products so complicated, is you’re like, you know what, but the sales guy said, they’re gonna sign up for our product and pay $300,000 a year, but we need to add this one checkbox. fuck do you add like seven of those checkboxes? The next thing, you know, the whole damn user experience is complicated. But that’s what happens in complex enterprise software, they all inevitably get to that exact same place. Just like if somebody came to Gigabook and said, hey, we’ll give you a giant check to add three features to it, you’d like you know, find all out the three features. And the next thing, you know, that just keeps happening. And that’s just the nature of software, it all ends up being really complex enterprise software eventually, if that’s the target audience that you’re at, we’re on the other hand, you have like your example earlier, Twitter who’s like completely the other end of the spectrum is like, we’re in shit. Like, we won’t even let you edit the tweet. Yeah, well, the other end of the spectrum.

Matt DeCoursey 11:36
Yeah. Well, and you know, so in that regard, like Twitter did add some more steps past that, they let you skip them, but they are, they are often li referred to as the, the fastest setup that you’re going to find. And, yeah, now back to the whole idea of the design and a prototype. So like, what is a prototype? And why do you need it a prototypes and initial creation of a product that shows the basics of what a product will look like, what the product will do and how the product operates, we’ll put a link to the show notes in that because we’ve got a we have, we have some other just look in the show notes, there’s more resources, more things in there. But you know, a prototype is often is and I mentioned this in the last episode, it’s it’s like your, your, your minimally viable product, which we have referred to as an MLP, the minimum lovable product, anything when it comes to the building a prototype, I just going to tell you, because after doing it wrong, in the past, I’ve learned that you need to pick two or three things at the most, and get real frickin good. Adam, before you worry about doing 12 other things. And you know, we, you know, you look at we were referencing Gigabook, like Gigabook, at its core is an appointment booking platform. So like being able to book a single appointment, would be an example of what its prototype needed to do. And then you might say, Well, with that you want to run a notification on a reminder, okay, get real good at those three things before you start trying to take payments and do rescheduling and like a whole bunch of other shit, because those basic tenants of your platform don’t work. The rest of it doesn’t matter. No one’s gonna stick around, no one cares.

Matt Watson 13:19
Well, the hardest part is design. I lost my train of thought.

Matt DeCoursey 13:25
Well, I’d say and see there you go. See the user experience I named Matt with the user experience, they’re not well, there’s some tools and things that can help with this. And, and when we talk about planning, we’ve talked about buy or build, you can buy framework, you can buy framework for this stuff, like you talked about needing to build a dashboard, like someone’s already designed that you can for like $100 or less, you can go buy a professional license of something, whether it’s Bootstrap or anything, yeah, CSS themes, and you’re going to customize a lot of someone else’s design work. So that’s the end, when you buy those, those dashboard templates, they will first off, they’ll come with the code base that you can just upload they have. So upload the whole thing to your server, if you don’t have any users and you’re starting from scratch, upload the whole thing and then start by just removing the stuff you know you won’t need.

Matt Watson 14:19
And that’s a good one. I was going to a good place everyone. I was gonna say no, yeah. Oh, you’re back. You’re back. I’m back. Yeah, sorry, my brain stopped working for a second. So a lot of times, you know, we’re talking about user experiences and all this. And in some sense, you’re talking about designing a brand new product, right? But a lot of times it’s not necessarily about brand new products. It’s just about a specific project or new feature or whatever you’re doing right and, and honestly, one of the things you can do for prototyping a lot of times is just using freaking Excel, and tools like that as well. You know, like, for example, at my company now we’re working on a project to do with reporting and the the team like not the development team, but the other team has figured about how to use Excel and import a bunch of data into it and do the calculations they want and even add a chart to it or whatever. And like they’ve got this Excel document that has like some pretty report, right? And it’s like they built the prototype. And actually, it’s like the product right now they just manually have to do all this shit. But now they can hand that over to the engineering team and say, Look, this is what we need, we did it in Excel, this is all the data, this is how we wanted to look. Now just like go build it and add it as a feature to the software. Right? Like they were actually able to use Excel as sort of like the UX like prototyping tool.

Matt DeCoursey 15:34
And that, and that is a prototype. I mean, that’s, that’s it, you’re just trying to give an example. So where would you need a prototype? A prototype, like that mentioned, could be an example or showing the design team. So you talk about, okay, so a lot of, there’s a lot of data centric stuff out there. And like, you know, like, so that a prototype could even be like Matt mentioned, like an Excel sheet, which would show the formulas and the math of how you got you arrived at something that you arrived at. And trust me, your design team is going to thank you for not making them have to figure that out on their own. Right. And, you know, another thing was, as you might make a prototype, we’ve mentioned a couple instances where like, here comes enterprise customer X, and they’re like, We need this and if we get it, we’re gonna give you a $25,000 a month contract, well, you might want to build a prototype for that too, because you might need to in order to get them to give you the money to build it. Also, just so you’re on the same page, and little basic prototypes are going to while it can be tempting to just try to build them run into the platform, sometimes you’re going to build a prototype and be like, Okay, this is going to be a lot more complex or harder to build than we thought it was, maybe this isn’t as good of an idea.

Matt Watson 16:49
So we thought, well, I’m in that stage, right now, we are trying to add a bunch of functionality to our software. So we can go meet with some potential customers slash partners. And they’re like, Hey, we don’t want to have that meeting until we have something to show like, we just need a prototype, it doesn’t have to be perfect. But we need something to show off, you know how this would work to go show this potential customer. And hopefully, then they’ll write us the big check. And then we’ll figure out, you know, the rest of it later.

Matt DeCoursey 17:14
Yeah, and then, you know, back to the MVP, or the minimally lovable product. I mean, that is a prototype. I mean, in a lot of cases, you get people that they’re looking for investment, they’re looking for validation, they’re looking for a lot of stuff. And being IV, I’ll tell you right now that being able to show someone, even if it’s a rickety version of it, show them give them an idea of how it works, then it makes it a lot more tangible and easy to understand now, the world, well, I’m going to give you a couple tips on what you can do to I got a couple of tools to suggest for you. But how long, someone’s going to need to build all this stuff for you. And if you are trying to figure that out, or you feel like you need to add to your team, you need to know that finding expert software developers, it doesn’t have to be difficult math, it does not have to be as challenging as some people make it, especially when you visit full scale.io where you can build a software team quickly and affordably. Almost 300 people in our office are working diligently on finding solutions. Now they design and prototype things, you can use the Full Scale platform to define your technical needs, and then see what available developers, testers, and leaders are ready to join your team. You can do all of that at full scale.io. That’s no longer a prototype map that has a working model. But you know, some of this is because there are some cool tools out there. I mean, Figma is a very popular one, when it comes to designing actual UI UX. And I mean, a mockup tool. Yeah, it’s a mock up tool. It’s like that and then another one, if you want to really be in love, like bubble.io has gotten really popular. Now bubbles, no code. One thing with bubbles that is doubtful is for most going to be at best a prototyping tool, because you don’t actually have heard a lot of success with it, though. Yeah, but you can show it, you can show an example. You can I mean, stuff together. And once again, when we talk about the design and planning phase, if you have something for your developers to follow, and look out and see, well, you’re gonna do it faster and better, in my opinion.

Matt Watson 19:23
Well, so we talked for previous episodes about the value of having a product owner and a product team, right? And, you know, I go through this every day at my company, it’s like, oh, we need to build a dashboard. It’s like, well, well, what should be on the dashboard? Nobody knows. Well, stuff. One of the best things you can do is just beg, borrow and steal, right? Like we’re going to look at all of our competitors. What do they do? We’re going to get ideas from them. We’re going to talk to industry experts and figure out okay, what are the KPIs that our customers should be tracking that we should put on this dashboard? And then we’re going to go talk to customers. We’re going to talk to other employees who also talked to customers every day. It’s like, you have to talk to a lot of people and sometimes the best thing you do is look at your competitors and steal ideas from them and figure out what they miss. Like, Oh, that’d be way better if they added this thing. But you just sort of beg borrow and steal from every place you can. And don’t don’t feel bad about ripping off other people’s ideas.

Matt DeCoursey 20:14
That’s not off because they want your competitor to not invent the administrative dashboard and software looking for inspiration. Yeah, I’ve actually done that with designers and people in the past. I’m like, here’s three things to get. Use these as some fodder for your future thoughts about what we need. And how can we do it better than this? Yeah. And I don’t think that ripping off is the right term, because that indicates and, you know, like, it was, it was your we’ve been using Giga Buchan as an example. It’s like, okay, the Romans invented the calendar. So sure, you know, like, I just say, I’m like, there’s no, there’s no real intellectual property there that, you know, I could have grabbed from Calendly, or Google or whatever. So don’t, I think some people get a little picky about some of that. And, you know, I don’t think you need to worry about it. But yeah, I think knowing and understanding what the industry standard is, as key is key, and it’ll and then maybe just ask your users.

Matt Watson 21:18
So we’ve been talking a lot about prototyping and mock ups. And those things are really important. As we talk more about the design phase. You know, as we mentioned earlier, that’s where you have to go from the requirements to figuring out the actual design. And there are several different aspects of the design itself that you have to take into account and account for. And one of them is the user experience, which we’ve been talking a lot about. But there are other design considerations, things like architecture or performance, or like, are we going to, how are we going to design this thing? Is it like an IoT thing? And I need to deploy it on-site? Or is it a mobile app? And I have to design it to run on mobile? Or I have to install it on their desktop? Or is it going to run in the cloud? Like there’s other design considerations that happen based on the requirements? Right? If your requirements are like, well, the software has to control drones, it’s like, okay, well, how would we design it to do that? Like, what type of software is it? Where would we deploy it? Right? So there’s a lot of other design decisions that go into the architecture, the tech stack, where we would deploy the app that have to back up whatever the requirements are, whatever the requirements are, now, we have to design how to accomplish those requirements. And so once you get into the design, it’s not all about user experience. It’s also the technical design as well, which gets into, you know, what does our tech stack look like where we’re going to deploy it? Things like risk and identifying security risks and other things?

Matt DeCoursey 22:41
Like we’re building bank software, coding languages to, like, I know, you mentioned some of that, like, are we gonna use React? Yeah, use JavaScript, right? Use. Those are all JavaScript, but that’s where you’re gonna get back into your design team fighting about shit.

Matt Watson 22:56
Yeah, everybody wants to use the shiny new object, the cool new thing, we talked about that before, right? It’s like, you gotta have the resources to actually execute and have the talent required, right?

Matt DeCoursey 23:09
That’s part of the requirements. In some cases, you can, you can continue if you’re planning on change. So you talked about the front end of things. And, you know, when I first started doing this, it was almost like every designer was a full stack designer, or a full stack developer, excuse me, like they kind of everyone kind of did everything. And what you’ll find now is that developers have largely identified themselves as being back end developers or front end. And I think if you can afford it, when you’re building your team, when it comes to your user, experience, your UI all that you can probably best to have someone that is passionate about that side of building technology.

Matt Watson 23:49
Yeah, and you’re absolutely right, when you talk about the design, as I mentioned earlier, depends on the type of app you’re building, right? Like if we’re building banking software, I might be doing a lot of API’s to various, you know, financial institutions or banking stuff. That’s a lot of API’s. I mean, maybe the project we’re working on has no user experience at all. Like I’m working on something today. That’s integration with Google AdWords, like, there really is no user experience. It’s all this integration work I have to do. And again, that comes down to the requirements and the type of project that you’re working on. There may be no user experience, even in the design.

Matt DeCoursey 24:24
I feel like I need to say this even though I cringe feeling like I have to because it’s 2022 and anything you build should be compatible on mobile or desktop. The technology is for you to come out of the box without me and it does. It might not be perfect, but it’s you you shouldn’t like, don’t like to keep that in mind along the way. Because like you mentioned a plumber needs to change something and he’s literally standing and shit. You know, he’s not breaking out of his laptop on that.

Matt Watson 24:56
We’re standing in the sewer. You’re in the middle of fixing the septic tank right now. But he’s got to take a call and schedule his next appointment for next week. And he’s got to have technology to do it. Right.

Matt DeCoursey 25:08
Yep. You know, I’m not much of a construction guy, I’m out. But I do know rule one and plumbing and that’s that shit flows downhill. I worked, I worked enough construction when I was younger to learn that role. And it’s true. It’s there, I believe that it’s validated. So, okay, so, you know, there’s, as I mentioned, at the beginning of the episode, you know, part of this part of discussing this side of it, it is, I mean, this is almost where I wish we had a little bit of a show and tell where we could bring listeners to see, you know, us actually showing you some things. So Matt, when you think about like an overall like them, so you have design and prototyping and you know, the, I think the thing is, is with us as, okay, if you’re building a new platform, I think that in this part of the process, it’s important to not drive yourself crazy about having the shiniest car on the block. Because as you continue to build the whole thing, like these are you, there’s a lot of things, you’re going to just polish at the end, that if you get too obsessed with Polish in this part of it, you’re just gonna find you’re polishing a lot of stuff that you end up throwing away or changing anyway, and you’re gonna drive yourself crazy. Doing it.

Matt Watson 26:20
If we use the analogy of building a house, you know, you’ve got the planning of the house, and you’ll have the requirements. Like I want to have three bedrooms and this many bathrooms and whatever you start and all the requirements. And then you get into the design phase. Now you get more into architecture and like we gotta draw the blueprints and and figure out like, what kind of wood are we going to use and exactly what you get you get into right, like now you get into interior design. But it’s like how far do you go? Right? Like how far do you overcomplicate like now you know, like, we haven’t built the house at your house yet. And you’re worried about if the couch is going to be leather and what kind of leather, right? Like there’s a diminishing return, somewhere around how much design work you have to do, like, hey, we did the blueprints of the house. And we know we want it to be wood. And maybe we know some of the paint colors. But some of that you figured out later, like we will figure out the paint color later. Like after like we’re in the middle of the construction. But that’s while it’s agile development to the right, because some of those decisions have been made on the fly later. But you know, I think the analogy of building a house is a good one. In this sense. It’s like how much do you go from architecture drawings to interior design, and there’s a line somewhere you don’t want to cross.

Matt DeCoursey 27:28
I compare it to restoring a classic car. And that you don’t you don’t you know, if you’re do redoing the engine and the interior, the first thing you do, you don’t come and paint the frame, and wax it and polish it up and then do all the rest of that you do a lot of that stuff in the end. And, you know, no matter how great your planning and in your project gathering requirements are, you are guaranteed to change stuff probably quite a bit before you get to that colorations and management phase. And that’s whether you have a new something new or you’re building on to something that exists. So the polish is the least important thing until it actually works.
Matt Watson 28:11
Yeah, and back to the house example. It’s like it doesn’t make a lot of sense to pick out a couch until you can walk in the space and see like, you know what, maybe we should get a smaller couch. Like some of it you just can’t answer those questions until you have something you can touch and feel. And then you can make more educated decisions later. Like you’re too early in the fit in the design phase. To make some of those final decisions. You just can’t do it.

Matt DeCoursey 28:34
Well, I was gonna say that you don’t know what the paint really looks like on the wall until it’s on the wall. But then I was reminded of our guests, Joel Tapley, who actually designed the app for PP and G and all of the paint companies that actually used a neural network to accurately show you what the paint looks like on the wall. So yeah, we might be right. Technology outpacing us, man, we’re gonna have to come up with some new examples. But yeah, like I said, You don’t you don’t wax and shine the car. I was actually joking before we recorded. I told Matt, I took a country drive last night and on my way out, I saw coin operated carwash, so I sprayed all the bugs and everything off the car. And then I got in and I was like, Shit, I got 20 miles to drive home. There were actually more bugs on my car when I got home than when I left. So that was like building software. Yeah, don’t don’t don’t press through your country drive. Yeah.

Matt Watson 29:29
You fixed half the bugs during the build. And then there’s half the bugs waiting for you after the delivery.

Matt DeCoursey 29:34
I would feel like there if I hadn’t done that, I actually would have had fewer bugs because some of the bugs would have hit the existing ones. Yeah, maybe. Definitely made things worse on that. Okay. So look when it comes to design and prototyping. There are a couple other things that I have suggestions for. This is a part of the process. We’re having someone that has some D’S sent design skills. And I mean, kind of like graphic type design skills can be quite helpful. There’s a ton of tools out there that you mean, just Google Design and prototyping tools I mentioned Figma. And Figma is popular because you can really kind of polish it and actually, kind of, then begin to turn that into your code. So it’s not just like, if you’re just going to create a design, you’re going to do it in something like Photoshop. Keep in mind that it doesn’t just immediately translate to your webpage or your server. It has to. You got to chop it up and code it up. I do still really want to just suggest that you buy and build a mentality that you look for an existing framework because there is an ungodly amount of high-quality templates out there that someone else built that have all the objects when I say objects that are like a field, a square, a form.

Matt Watson 30:54
You have an example that is Bootstrap. Yeah. Right. Like most people use Bootstrap these days. And, and it does a good job with just basics, you know, spacing, and padding and, and all that stuff. And like you want to drop in a button and how big the button should be, and the size of the button and whatever. Those things help so much with just creating, like, at least a basic design. Like it doesn’t have to be perfect, but it’s really good, like you just kind of standard design.

Matt DeCoursey 31:15
Yeah. And I have a couple other closing remarks. Right after, I want to ask everyone, do you need to hire software engineers, testers, and leaders? Because Full Scale can help with that, we have the people, the platform, and the processes to help you manage your team of experts to go to full scale.io. It’s not so easy. Just answer a couple questions. We made that prototype really simple. And the system will match you up with people that have qualifications and experience doing what you need to be done. You can schedule interviews and get everything going. And that same platform is going to help you with the time clocks and reports a whole lot of different stuff. We’ve really done a lot of design and prototyping, and testing. Yeah, come set to make the building of your software team fast and easy, Matt. We built the whole company out of our own needs. And I think that made us pretty damn founder friendly. So pretty excited about that. But yeah, so we mentioned the kind of closing remarks that I think the main thing I wanted to visit is that with a prototype, it can be simple. It doesn’t have to be that this isn’t the finished product. Otherwise, it wouldn’t be called a prototype.

Matt Watson 32:22
You know, if you have to iterate on it, right? And, you know, I had a meeting actually, before this today, and we’re working on designing a dashboard for our software. And our product manager is like, well, what if we just asked the developers to figure out what this is supposed to look like? And I’m like, Are you fucking kidding? No, I have no idea. They have no idea. We have to design this. We have to design this and give them the requirements. Like we can’t just go to them and say mega dashboard. Like it doesn’t work that way, man, we have to design it. We have to give them the blueprints. And they are engineers, they are engineers, you told them what to do, and they will build it, but you have to tell them what you need. Or otherwise, they’re just not going to know you’re gonna come. They’re gonna come back with some crazy shit.

Matt DeCoursey 33:02
For whatever reason you say, that story reminded me of Big Daddy, the Adam Sandler movie where he, you know, he kind of suddenly likes, has a que les the kid name himself and he names himself Frankenstein. And you know, and stuff like that. I was also like, just, you know, with my kids, I was asking, I was like, Hey, do you want to get a horse? And they’re like, Yeah, that sounds great. What would you name it? Baby Yoda. I’m like, you know, so? Yeah.

Matt Watson 33:30
Pretty much. Yeah. So their requirements and design are critical for phase two development. And a lot of times, it’s like you just spend a little extra time in the requirements and the design phase and then hand that off to the engineering team. And that gives them the blueprints that they need to at least get started. They will have more questions, and there will be things you didn’t think about, but at least they have a basis for what they’re doing. It’s so important.

Matt DeCoursey 33:55
Yeah, they look for prototyping tools for UI UX. Like here you have Figma, I have no vested interest in you using any of these people. I’m not getting paid to say this. I probably should be. You have envisioned a studio that’s another popular one where a lot of these things help you make clickable prototypes. Now that doesn’t mean that the back-end part of your software is doing its thing, but it’ll demonstrate the user experience and help you refine what it looks like. Adobe XD Webflow is another popular one that’s got gained popularity over the years as DSU zoar origami studio just in mind sketch sketches actually I run into I’ve had a lot of people show up to meetings about building the team at Full Scale, and they have used the sketch that’s sketch and Figma are probably the two that I run into and then and then the Envision studio and then a lot of people just have mock Oh, and visions huge. Yeah, and those all these are things like you make clickable things like it’ll like you’re going to prototype things to the point where you click the submit button, and it’ll take you thank you for you’ve submitted your data, and we’ll get right back to you now that didn’t actually go anywhere.

Matt Watson 35:14
Yeah, these different tools, some of them are better for different personas, right if you’re a graphic artist if you’re doing things in Photoshop, something like envision is great, because you can create like really high fidelity stuff and build it. Same thing with Adobe XD. You can build really high-fidelity stuff. And you have something like Figma, which is probably more of my alley, where it’s just like, I’m creating buttons and labels and whatever and making it just kind of high level, you know, but hell, I’ve even used I’d like to use Google’s slight like PowerPoint, or Google Slides like that even works for doing mock ups like stuff sometimes.

Matt DeCoursey 35:48
I’ve used cam Yeah, just because I’m familiar with Canva. You know, like, and they’ve been a sponsor of the show. There you go. Canva, there’s some free advertising. I finally got paid for one of them. Not this one, though. But Canva because it’s simple. I literally just kind of, I’m kind of known for my shitty drawings, like my whiteboard drawings, where my squares aren’t square, and my circles aren’t round. That’s okay. That’s okay. Yeah, you’re trying to give a message over to Yeah, yeah, you don’t, you don’t have to draw. And then when I really want to get tools with it, I actually like to have a pad of graph paper and some colored pencils. And just like a little drawing, that’s the easiest too. Yeah, I bought it for 20 to 25 bucks. I’ve got like, like a round, you know, the round ruler, the little square, like, all of that stuff. And in a box of colored pencils. And you know, and like and all sometimes sketch it out like that. And so, at the beginning of the episode, I wasn’t joking. Like, I mean, a bar napkin and a golf pencil can be prototyping tools. Whatever works, it doesn’t really matter. Until you get it out of your head and into something else. It’s almost not real. It’s a fantasy.

Matt Watson 37:00
So any visual at all helps people understand what you’re trying to do.

Matt DeCoursey 37:03
I’m gonna go draw a bunch of stuff now. I’m filling in what I almost said expired. That’s not good. I’m feeling inspired. Alright, I’m gonna go draw pictures. Now I’m at more, not square squares and not round circles. See you next week.

Matt Watson 37:20
See yah.