Wireframing 101 for SaaS Startups – with Leon Barnard [361]

This is machine-generated transcript.

[00:00:00] Omer: Welcome to another episode of The SaaS podcast. I'm your host, Omer Khan, and this is a show where I interview proven founders and industry experts who share their stories, strategies, and insights to help you build, launch, and grow your SaaS business. In this episode I took to Leon Barnard, the education team lead at Balsamiq and co-author of the book Wireframing for Everyone alongside Michel Angel and Billy Carlson.

Wireframes are fast and easy to make, can be created and understood by anyone, and can be used for both creative ideation and practical UX design. But many teams still struggle to work effectively with wire frames and others. Assume that wire frames is something that only. Product designers should create.

Today we're gonna give you a Wireframing 101 for SaaS Startups Masterclass. Our goal is to give you the knowledge and tools needed to craft effective wireframes, dodge common pitfalls, and navigate the wire framing process successfully so you can design great SaaS products. In this masterclass, we're gonna cover the critical role of wireframing and product design and development proven techniques for creating user-centric wireframes the benefits and drawbacks of various wire framing tools.

Common mistakes in the wireframing process and how you can avoid them, and practical methods for designing without a designer. So I hope you enjoy it. So, Leon, welcome to the show.

[00:01:29] Leon: Thank you. Great to be here. Thanks for having me.

[00:01:32] Omer: So, Tell us about the book. We're gonna talk about wire Framing for everyone.

Although the title is fairly obvious, tell us what is the book about, who is it for, and what's the main problem you're helping to solve?

[00:01:45] Leon: Sure. Yeah. So it's called Wireframing for Everyone. Got a copy here for your video viewers. It's published by a book Apart. I wrote it with two of my other Balsamiq colleagues, Billy Carlson and Michael Angeles. So the three of us work at Balsamiq. You know, you mentioned the title Wireframing for Everyone. We feel like the for everyone is a really important part of , which is why we put it in the title because we, we feel like wireframing. Is not something just for designers.

You know, we were kind of inspired by books like Lean U X , UX for Lean Startups, the Lean Product Playbook, some of these books that your listeners might already know, and all of those books mentioned. Either wireframing or kind of this idea of, you know, quick and dirty prototypes or just being very iterative and not, you know, spending tons of cycles on big design or doing the kind of anti waterfall.

And so we felt like in these books, when they got to the part about wireframing, where like, it would be really great if there was more of a deep dive into how to actually wireframe. As part of kind of a, a lean, more efficient more iterative process. And so, you know, our experience was, there was a lot of books about UX design, UX techniques and the way it's taught in, in bootcamps and things like that, it's, it's a very, it's kind of taught in a vacuum.

And so we really wanted to have a book about. UI design and wire framing in the context of the real world and how to use it as part of a process and, and kind of a way of thinking really. Because it's not really so much a design technique as it is a way to communicate and collaborate better. And so we really felt like there was something missing out there in the market.

[00:03:28] Omer: Okay, great. So, Before we, we get into talking about like why, why framing is important and why people listening to this should be thinking more about using why frames if they're not currently already doing. So let's just start off with like, what's the simple definition of why framing for someone who doesn't know?

[00:03:49] Leon: You know, we try to really zoom way out and take a really high level and say, wireframing is just a new way to sketch. It's a more efficient way to sketch like you would on paper, like people have been doing for hundreds of years. So it's, you know, when you think about sketching or drawing on a whiteboard, it's, you think about brainstorming, coming up with ideas, sharing your ideas.

It's just really a more efficient way to do that because it's optimized for UI design. So once you get to the part where you're talking about what the product will look like and what it does, It's really a great technique for, for sketching and communicating ideas.

[00:04:27] Omer: Great. I like that. Okay, so let's talk about why, wireframing matters.

Why should somebody listening to this be thinking more and more seriously about? Implementing the use of wire frames with their product development.

[00:04:45] Leon: So I know your audience leans towards founders and SaaS founders specifically, and I think for, for those people it can be really, really useful because when you have an idea for a business, you know, these days, building the product, writing the code shipping it is, is kind of the easy part relative to the, to the other thing, you know, to the other parts why a lot of businesses fail is because they don't have product market fit or they're not doing a good job of solving the customer problem that they set out to.

So wireframing is a, tool and the technique to help you stay in that kind of early ideation, creative phase where you're thinking about all the big problems. You know, what is it that people really wanna do? How, what are some creative, innovative ways to solve these problems? You know, how do we differentiate ourselves?

And, you know, once you get into the, the coding or the, the look and the feel, that's not the the time to be. Thinking about those things, you know, it's kind of too late at that point. You're kind of locked into a certain design or a certain implementation, but when you're in those early phases and you know that you have a really cool idea, it's worth taking the time to come up with 10 different variations for how that, how you might do that.

In the, in a product. Because once you start down that path towards coding, it's really too late to start making big, drastic changes. But early on, that's the time to explore, get creative, think about new and innovative ways to do things. You know, our philosophy is really take that extra time to kind of play around and get creative early on, because that's what's really gonna set your product apart.

[00:06:25] Omer: Yeah, I think with, with a lot of no code tools today, it is really easy to build a product, and there's a danger that you fall into this trap because it's so easy. You kind of go ahead and just say, I'll just go and build a product. I have the idea, why don't I do that? But it's almost the same as me saying, well, I have Microsoft Word, and I could use something like Amazon to self-publish a book. So why don't I just start typing today and publish something next week? Because it's pretty easy to publish a book, right? But that, as we know, is, is not as, as simple as that. And there's a lot of, you know, work that needs to go into figuring out the kind of, all the different aspects of, of, of a bestselling book before you can just start typing and publishing one thing before we, we sort of get into sort of the nuts and bolts and some practical advice, who should be creating these wireframes? Now, is this like something only designers should be doing? If there is a founder, maybe a solo founder today, you know, should, should they be doing it themselves?

Should they be. Finding a designer to help them, like, like who, who should own wireframing and, and kind of who's the best person to, to, to work on this.

[00:07:53] Leon: Yeah. That's always, that's been a longstanding debate and you'll find designers who hate it when PMs wireframe and it's frustrating for PMs or, founders who are like, I'm not, I have this idea for something yet, and yet I'm not allowed to draw it.

And I think it's. You know, you get into this kind of siloed way of thinking, or black and white and I, I, I think it's really the wrong way to go about it. It's not who should be doing them, it's. When is the right time for different roles to be doing them? And what phase of the, of the product are cycle are we in?

So in in the book we actually described three different phases of wireframing. You know, you're kind of early phases where it's just for you. And I think that's when founders, PMs, business people, developers, designers, anybody can be you know, bring out the wireframing tool or, or whiteboard or whatever.

And they should definitely be wireframing and coming up with ideas and iterating on those ideas. Just to, you know, you have this idea in your head and you, you wanna get it down, you wanna see it. And so, you know, do that and then see where that leads you to more ideas. And don't worry about is it gonna be understood by other people?

Where is this going? You know, just get it all down. I mean, it's just kind of that classic brainstorm or, or brain, brain dump. So there's this early phase where it's just for you just to clarify your own ideas and then you can get to a second phase where you're kind of trying to think about, okay, well what would this actually look like?

Where I to build it? You know, how do I translate some of these ideas into into a user interface? And then the last phase is not actually. Making them high fidelity and look like the finished product. But it's thinking then about who you're delivering them to and kind of fine tuning them and optimizing them for say, the next person down the line, whether it's your designer or your developer, thinking about how to communicate them.

But they're really just a tool to help you, you know, flesh out and articulate your ideas. So rather than thinking about them as the wire frames or the deliverable it's just another tool or technique, you know, and you can mix and match. You can put a wireframe inside of your, your PRD or your pitch deck or whatever.

And so sometimes a, you know, a picture is a better way to communicate than words. And so don't feel like you, you're not allowed to draw a picture, you know? And then, so the designer should be comfortable getting wireframes, so, and being able to have a conversation around them without feeling like, okay, this is the product that I have to design and my job is just to make it look pretty.

You know, it's, they should really be seen as these kind of transitional artifacts.

[00:10:34] Omer: Yeah. I, I think this idea of saying wireframing is really, a visual way to communicate an idea instead of through words is a great way to frame this, because essentially that's what it is. And if everybody understands that, I don't think anybody gets upset, whether you're writing something down or sketching something to communicate what's in your head.

I think it's worth making the distinction between low fidelity and high fidelity design because we're gonna talk a little bit about the differences as we go on, and I think sometimes the reason that maybe designers might get a little upset or there's some conflict between teams and PMs and whatever is when.

A wireframe kind of looks more like a high fidelity design, which kind of implies, well, all the decisions have been made, this is what it's gonna look like, and now you need to make it just polish it up. Whereas with low fidelity, it's pretty clear this is not the final product. This is a sketch, this is an idea.

And so I think people would tend to focus less on the color of the button and stuff like that. So just kind of just explain to us. Low fidelity versus high fidelity. What's the difference?

[00:11:57] Leon: You really nailed it. And that's such an important point, that if you deliver something that looks like a final product, you're gonna have a a, an entirely different conversation around it.

You know, maybe your designers or your developers are gonna push back because they're gonna say, well, that doesn't line up with our design system. Or, you know, the, I don't know how to write the code for that or, or whatever. But if you put out something that just looks like a rough sketch, then then the goal is kind of like, let's have a conversation about this.

Let's talk about this. We're gonna make changes. And it's actually a way of bringing people into a conversation rather than kind of putting everybody into their buckets of, I do this, you do this. It's a way to say, Hey, let's all have a conversation about this idea I had. And what's nice, actually one trick is to kind of like go into a meeting with a bunch of different ideas so that it doesn't, so it makes it very clear that you're not saying, okay, here's what I think we should build.

Go build it. But hey, here's three different ideas. And one of them is totally unfinished, you know? And so you can all kind of get on the same page. You can get buy-in from people. You can ask your developer, Hey, which of these. Is gonna be easier for you to build, and then all of a sudden they're becoming an advocate for the design because you asked for their help.

[00:13:14] Omer: So let's let's talk about building your first wireframe. So let's say I'm a founder. I've got this idea in my head. I want to communicate this to my team. And it's in the early phase, right? It's just, it's an idea and I can either write it down or I can communicate it visually. So, how should I think about this?

Because there's always this danger, whether you're using low fidelity or high fidelity, you kind of get stuck into, you know, where, where is the button going to go? And you know, things that really don't matter at this point. Right. So maybe kind of just walk us through like, you know, some steps that, you know, somebody should take when they kind of start the wireframing process.

[00:14:02] Leon: Yeah. It's definitely a challenge, especially for founders and people who don't have a designer is that. The person, then the founder or whomever feels like it's their job to be the designer, and then they think they have to do what they think a designer does, which is make, you know, make a prototype, make something that looks really good.

But you know, in my experience, I was a UX designer for 10 years and early on. You know, it was very much just production work. Just make the thing look good. But as I went on, I found out that what I was missing, it was an understanding of what's the problem you know, an understanding of who the user is and that, that has such an impact on the design itself.

And so I think that a founder shouldn't step out of their founder role. The their, the knowledge that they have about the customer and the problem. And don't try to just think about how am I gonna build this thing, but really try to think about, okay, what, you know, try to focus on asking the right questions.

Cuz in my experience as a designer, the best designers are the ones that ask the most questions or the best questions. So it's not, how do I make this look pretty, but it's how do I find the best way to address this issue. And so I think the best way to start a wireframe is with a really bad wireframe.

So don't get hung up on trying to make a great wireframe. You know, going back to what I said earlier about kind of these early phase wireframes where it's just for you, that's your time to not have to think about the usability so much. Just think about the user and then one of our chapters is all about how to learning about basic.

UI controls and UI patterns and templates and how to think like a UI designer, which is okay if I have this workflow, okay, I know this is maybe gonna be a form. Here's some best practices for designing forms. Here's some best practices or some different ideas about how to design navigation. So in your head, maybe the best thing to do as a founder, as as a non-designer, is just draw a site, map or draw kind of a, a flow chart or a diagram.

You know, think about how things are connected and then, you know, learn a little bit about the basics of navigation. Is it horizontal navigation? Is it vertical navigation? Is it tabs? You know, what are the pros and cons of these? And go out and look at other products and other sites that do things similarly, even if it's completely outside of your domain.

And then learn some of these techniques for taking, you know, a structure and convert it and converting it into a user interface. So one of our chapters is all about learning just what you need to know about UI design which I think we'll go a long way. You don't have to become an expert in it.

[00:16:48] Omer: I, I don't know if you're familiar with the, the concept of like fat marker sketches that Basecamp, you know, the team 37 Signals, I dunno what, what they call themselves these days. Is it Basecamp or 37 Signals?

[00:17:00] Leon: I didn't know that it came from them, but that is one of my favorite kind of analogies or, or ways of talking to people about this sort of thing.

[00:17:08] Omer: Yeah. So I, I, I'll include a link in the show notes to maybe a page with an example of a fat marker sketch, because that actually is great because it's, it's a way of, I mean, no one is gonna look at one of those sketches and say, oh, you designed the product. Right? It's like, okay, here's an idea. You're trying to communicate that, and the way they do it, it kind of helps you avoid thinking about layout.

It's almost like just stack things on top of each other, right? Okay. There's gonna be a feel, there's gonna be a button, there's gonna be something that's gonna do this. I don't really know how it's gonna get laid out. I just know it's gonna be on the page somewhere and let's talk about, you know, whether this is the right way to solve this problem or not.

So I think that is actually before we even get into talking about, you know, using tools that actually is a really a very simple and easy way for someone who isn't a designer or a founder who wants to communicate or articulate something that's in their head, that's something they can do. Relatively easily.

But I do like the idea of coupling that with some of the, at least having a basic understanding of what you talked about in the book about design patterns and some things like that, because that will only help you to kind of understand what, what's expected, what's good practice, what isn't good practice.

So even though it's still just a sketch, at least you have some of those thoughts in the back of your mind to. To come up with something that makes more sense to whoever you communicate that to.

[00:18:38] Leon: Yeah. Actually, one of the, that's a good reminder. One of the techniques that we mentioned in the book is, is about like content modeling or say you're designing a landing page, just write a bunch of sticky, sticky notes, whether it's, whether they're digital sticky notes or actual ones, and think about the priority of, of them. And put the most important ones at the top and then go down from there. And so it's kind of this mix of, it's mostly words, but there's a visual element to it in that.

By laying them out, not necessarily how they would look on a website, you know, this is the navigation over here, the sidebar, all of this stuff. But just from top to bottom, you know, if you have a landing page, the most important thing should be at the top and maybe it should be the, the full width. So to kind of like do this very basic kind of block or chunk kind of diagram, which is just barely visual in the sense that it's just, things taking up space, but it's, it has the word, so you know what goes there.

So thinking about the content first, and that's the first step to design before you then think about is the navigation gonna be across the top or on the side.

[00:19:46] Omer: Yeah. Yeah. I agree. For people watching this on video, so this is from basecamp.com where they talk about fat marker sketches. And so I think anybody watching on this video can quickly get an idea of you know what that looks like. It's not very sophisticated but it communicates an idea. Let's move on. Let's talk about tools.

So, you know, we, we've kind of talked about these phases, which I think is a really useful way to think about this, right? So if everybody knows, look, we're in an early kind of phase, we're gonna have different ideas that we're gonna consider try out.

Nothing is, you know, set in stone right now. We just exploring that, that just kind of having, just kind of everybody knowing which phase you're in, kind of, I think it will help to set expectations. Kinda more clearly with everybody. So I like that a lot. Let's, let's talk about, okay, if we want to kind of progress beyond fat marker sketches and maybe start looking at a wireframing tool.

Obviously when it comes to low fidelity, you know there's Balsamiq cuz you guys work on that everyday. Give us kind of a, you know, a quick overview of like, you know, what, what's kind of achievable in Balsamiq. And then also, since I don't want this to be just a Balsamiq promo, let's also talk about some other tools that people can consider using.

[00:21:10] Leon: Yeah. So yes, all three authors do work at Balsamiq, but we really wanted this book to be very agnostic to the tools. There's only a very short section on tools in the book. And it's basically just two points. And it's that our recommendations for a tool for wireframing are only two things. One, that you have some kind of widget library that you can drag and drop so you're not just, you know, when I started out wireframing, I would use PowerPoint and I, you know, you could draw shapes and you can do this in a lot of tools.

Now you can have circles and squares and arrows and things like that, but then you end up spending a little bit too much time trying to create these UI widgets from very fundamental shapes. So what's great about a lot of wireframing tools beyond just Balsamiq is having these templates or widgets that you can, that are built in that you can just drag and drop for.

You know, all the most common UI controls, and they don't have to be interactive or anything like that, but you should, you know, if you want to put together a table with an accordion or whatever, you should just be able to drag those onto the, onto the canvas. And then the other thing that I say to look out for is it kind of on the opposite side of things, which is not having too much customizability and not having too many.

Options that you can play with and configure because it's kind of natural to get into the details and get into fidgeting and fussing and trying to get everything perfect. So kind of like your, the fat markers thing. You know what's great about fat markers is they prevent you from doing anything too, too fine grained.

And so if you use a tool that's really powerful, you might end up spending, you often do end up spending too much time on fine tuning. At the phase that it, that doesn't matter. So I believe that there is, room for tools that both do high fidelity on one end and separate tools that are meant for low fidelity on the other end.

And that they shouldn't really, and they should be used separately, they should not be used, you know, to do both. So on the lower end of the spectrum. There's tools like Balsamiq whimsical is another tool that has wire framing capabilities. Nero is really popular. There's an a lot of new kind of whiteboarding tools, and I would much rather have somebody create their wireframes in a tool that's really good for whiteboarding and kind of general.

Sketching than to do their wireframes in Figma. And I know that Figma is really popular. It's really useful. It's very well designed. It has its place, but I don't think it should be used for these early phases where you're really trying to answer some fundamental questions. Once you start, once you open up Figma, you're gonna get fixated on on building the thing and what does this look like and how does it work, and all of these things.

And if you do that too soon, you're gonna lose sight of who you're building it for, what the real problem is that you're solving. And so, you know, you don't have to use some although it is optimized for wireframing. But I think it is really good to use something that is kind of limited on purpose. And even if that's a, just a plain old whiteboard in your office, you know, the old fashioned way, I think that.

You're gonna have much better wireframes using a tool like that than a really powerful, complex tool that's focused on on UX designers.

[00:24:25] Omer: Yeah, I used to, when, when I started, you know, I'm not a designer, but when I started creating wireframes like over 15 years ago I was doing it in PowerPoint, so I was like creating the shapes and, and all that stuff.

And it was tedious and it was slow and, and painful. And then I remember, I dunno if you remember this, what was it called? Keynotopia? Yes. So some guy, I can't, I can't remember his name, I'm sorry, is he created this library of all of these elements that you could use and then just drag them in and, you know, you've got a button, you've got a form and all of this stuff.

And that made life wonderful. But, and you could do that in Keynote, which I guess, which is why it was called Keynotopia cuz maybe that's where it started. And but I felt that I, that was for a later stage because most of the things in the library were quite high fidelity. And so if you wanna go for sketching, low fidelity wireframing, it wasn't really you, you were more likely to piss off the designer by coming and saying, Hey, this is how it looks.

And you know, the, the kind of the final design. And so I don't do many wireframes these days, but when I want to, when I'm working with a founder or, or a team at a startup and I'm, I'm trying to communicate an idea about a product, I find it much easier these days just to use my iPad and I use an app like Good Notes or Notability and just use the Apple Pencil, sketch something out, export that as a PDF or jpeg and, you know, job done because, you know, they can go and use the wireframing tools to kind of think of the next step.

But again, it goes back to, what's useful, what's simple that, that you can use to, to communicate those ideas. And I think that that's the, the other thing that I think, you know, you and I had talked about this earlier is that we want to kind of make sure people understand is the, there is no perfect tool.

It's, you gotta pick the right tool for you. Like what's gonna help you. To be able to communicate the ideas and do it as quickly as possible. And if you can use a tool and it's gonna take you 10 times, as long as sketching it on a piece of paper, well then paper and pencil is probably the better tool for you to you know, communicate wireframes.

Absolutely. Okay. So we've talked about is there anything else that you want to add on what we, we've just sort of mentioned about the tools or.

[00:26:50] Leon: Well, just as you were talking about all this, old stuff. I mean, I was, I started wireframing at the same time, so it brought back a lot of memories. But one of my co-authors, Michelangelo achieved some notoriety a long time ago because there was this tool OmniGraffle, I think it's still around.

And he created a, a wireframe. Oh, they, they called them stencils in, in, in OmniGraffle. So he, he created the first or the most popular wire frame stencil kit for OmniGraffle. That really was kind of a precursor to Balsamiq in that it was this generic drawing tool for flowcharts and things like that. But now he created these kind of generic stencils that allowed you to make wire frames, and they were really, really popular.

You could just, you know, buy it or download it and just add it onto the product. And that really, if anything, validated the desire, the interest in having a tool with these prebuilt wireframe widgets, but yet that weren't overly prescriptive or overly designed to look like the final product.

[00:27:48] Omer: Okay, so let's talk about some common mistakes that people make with wireframing.

I think we've talked about why somebody should be using wireframes. We've talked about, you know, how to go about, you know, approaching this and thinking about the different phases and, and how you should think about your first wire frame and, and all the other things you should be thinking about before you start actually sketching it out and terms of who's the user, what's the problem that we're trying to solve and so on.

And some of the different tools that people can use. So all that sounds great, but there's also. A lot of pitfalls along the way when it comes to wire framing and very easy to kind of screw things up. Let's talk a little bit about that. Like what, what are some of the common mistakes that, that you've seen in your experience?

[00:28:36] Leon: Well, we kind of alluded to it earlier, but it's the most common mistake is diving too fast into the design. Too early thinking that the goal of creating a wire frame is to create kind of a, you know, a, a skeleton of the final product. If you do that right away, then you're gonna end up tied to that product and you're gonna start, wanna start building it.

But really kind of take a pause, slow down, try to stretch out that phase and try to see. Instead of asking, you know, like, how should this product look? Think about what are all the different ways that I can solve the problem that I know is really pressing? You know, and you know, when you come up with your first couple of ideas, try to push beyond that and question those and say, oh, you know, well, what if.

I did a workflow for an authentication or a login workflow. What if we didn't do authentication? We just let people use the product right away, and then you can go and just, you know, kind of throw that together in another 10 minutes and you're not really wasting any time because you might, that might result in something really useful.

Maybe you'll realize, oh, I can delay login and let them create something right away that they can. You know, make use of, and then, and have that stored locally or something. And then maybe that's a better way to get people to use, to use the product. Or what if I did this primarily as an API or a WordPress plugin?

You know, you get fixated on what it's gonna look like and that closes off a lot of possibilities to other ways that it could work or other ways that it could solve a problem. So, you know, so many products they get, they get rebranded, they, you know, a lot of things can change. Later on, but focus on the things that are harder to change later on.

And a good thing is just to start with words. Just draw out in your wireframe, you know, arrows, connecting things together. Just sticky notes. Write down, okay, who are the users? What are they using it for? What are the different use cases or scenarios? Try to think in terms of just, you know, using words.

In kind of a visual way, or connecting things together and seeing things at a really high level and looking at the connections before you think about the user interface. Even if you're in the wireframing tool that allows you to generate a user interface, use some of the more generic widgets, you know, the boxes and arrows and sticky notes and things like that to kind of like just try to exhaust all the possibilities before you start thinking about about the user interface.

[00:31:10] Omer: Yeah, so just thinking about some of the things that people should be doing before. They start actually wireframing. It reminded me that I recorded an episode with, with Matt, who's the, the founder and president at Planorama Design, where we went through teaching people about using user stories.

And I think that's very complimentary to thinking about wireframing because at when you're using user stories, You're using words to think less about how will the product work? And it's more about what does the user want and how do we solve that or meet that need, solve that problem, or meet that need.

And so that's an, I think it's just looking it up. It's like episode 326. So that might be a useful thing to compliment with, with this episode to sort of think about if you're not sure what to do before you start wireframing and you wanna think a little bit more deeply about the user. Consider user stories as, as a way to think about that.

[00:32:11] Leon: Yeah. If I could just add two, two things to that, one, my, one of my very first articles that I wrote at Balsamiq was about how to use wireframes with user stories. Because as a UX designer one of my previous jobs I was in a UX role. There was also a business analyst role, so I was writing user stories and what I found worked really well is having this combination of user stories and wireframes and, and it goes back to what you were saying earlier about doing what is kind of the most efficient.

So use the user stories, to describe things and then use the wireframes to kind of supplement. And I think also user stories are a really good example of where constraints or limitations help you. You know, a lot of people complain about the user story format, but it's written that way for a reason to keep you focused on the user and the problem they're trying to solve and not think in terms of features.

And so the reasons that wireframes are limited is very similar because it kind of forces you to think about the things that are more important in that phase, which is not the colors and whether the button is left aligned or right aligned. So, you know, limitations can really be, be helpful to keep you focused.

[00:33:20] Omer: Totally agree. So the, the first summarize, just the first kind of mistake pitfall we talked about was focusing too much on designing the solution too early. And not really thinking about, you know, some of the bigger picture stuff. We talked about these phases. So you know, the early stage kind of when you start to think about product design and then eventually fine tuning in, being able to hand it over to a designer or whoever, having a founder in the early stages create wireframes.

I think seems fine. Makes sense. They've got ideas they wanna articulate that maybe they've been going out and spending, you know, a bunch of time talking to potential customers and they want to come back and, and share that and, and sort of just get those ideas down or some but there's also this danger that as a founder who maybe doesn't have design skills, thinking they can keep carrying this all the way to the end and just hand it off to a developer.

To, to go and build it. Or maybe I'll hire a, a visual designer to make this look kind of cooler than it. It really is, and I think there's this fundamental piece missing there, which is really understanding what is the role of a great designer, a product designer, a UX designer. I think if a founder kind of runs with it, that is a potential pitfall or mistake, and there should be at some, at least some point in the process.

You should be involving some type of designer, whether it's somebody on your team or finding, you know, a great freelancer to at least review what you've done and, and help you kind of address some of the, the flaws in the, in the design and the way you're thinking about the product. Right?

[00:35:01] Leon: Yes. And actually the, I mean, that is one of the things that we put in the book that we felt is really missing is how to translate your rough, your bad wireframes into decent wire frames where you're starting to think about, okay, what kind of UI components would be appropriate here?

And then learning how a, a user interface designer thinks. So you can actually do a little bit of that on your own because it's not that hard to do the basics. So I do think that that is missing out there. It's, well, not a lot of people know how to do that. And so our book does try to address that. But beyond that, if you do work with a designer, try to find somebody who kind of gets that and, and understands the role, and is not just gonna give you 500 high fidelity wire frames that are gonna show you every screen and every variation on that screen, and charge you a ton of money. Think in terms of templates. You know, think about, have them create some basic templates.

Have them create a basic, you know, design scheme or design system. Think in terms of consistency and reusability. Don't think on a screen by screen basis, but look for commonalities. Look for reusing things. Look for patterns that other sites use that do well, and you can just say, Hey, there's, you know, we can use the Google login authentication.

Or, you know, we can this, you know, Dropbox has already figured out a really good way to do revisions or version control or something like that. You know, we don't have to steal that, but use that from information and you realize that, you know, you don't wanna reinvent the wheel. And there's so many design user interface design patterns, and.

Templates and best practices that are already out there. So don't feel like you need to design everything from scratch and hire somebody or work with somebody who understands that and is going to kind of opt, optimize their effort for the things that are most specific to your problem. And you know, if.

Yeah, like I said, if they're coming up with a, an image or a visualization of every single screen, that's really overkill When they can just come up with design templates, because that's how the code is gonna be written anyway. It's gonna be, you wanna have a design system or reusable widgets, reusable code.

So that's the way the developers think. And so it's a good way for our designers to think also you know, if you're thinking about how am I actually gonna. Implement this, at some point this is gonna turn into code, so you also have to think a little bit like a, a developer.

[00:37:28] Omer: Yeah, that's, that's great advice.

I think the idea of just thinking about templates, reusable components, not just for code, but also for design is, is a great approach and I think it'll actually save, save people a lot of money that they potentially could spend creating thousands of, you know, screens and, and maybe put more of that budget towards hiring a, a more experienced.

You know, UX designer who can come in and really help them nail you know, what they need to do with the product. Do you have an example maybe from a case study or something that we can talk about where, you know, there's some lessons to be learned about? You know, not, not kind of doing this

the right way.

[00:38:08] Leon: We, we do mention a story in the book, which is my co-author Michael heard about it of a team who had worked really hard on this product. And they did a lot of, they even did user testing. They kind of felt like they had a really good process and then they launched it and they were really excited and the feedback they got was really, terrible because they spent so much time on the implementation and the details.

And they didn't do enough exploration early on to really see if they were building the right product. So they got so fixated on getting this out the door and. The, the code and the look and the feel, but they kind of bypassed that early step of, you know, asking the right questions, asking the big picture questions.

And so obviously then they had basically had to scrap it and start over. And so, you know, a counter example to that, which I just heard on the radio one day, is they were interviewing a really famous chef and he was saying, he was talking about his test kitchen and he tells his sous chefs, you know, I wanna create 10 different ideas for the menu, for everyone that actually goes out there.

You know, you have to have out of 10 ideas, you know. Nine of them are not gonna be the ideal. And so don't just go up, go out and cook something and put it on the menu. But you have to have this exploration phase, phase where you, where you play around where you're free and where it's inexpensive to make mistakes.

So give yourself time to make mistakes early so that you don't make them later. So there's actually a lot of lessons that can be learned outside of software about this technique, this idea of just spending time exploring things and getting things right before you really. We've developed them further on.

[00:39:48] Omer: All right, great. So I think that's a wrap here. I think we've covered quite a lot. If you're not convinced now that you should be doing more wire framing, then we're never gonna persuade you. But hopefully I think it's clear enough to people listening that if they're not already wireframing why they should be doing it and, and, you know, some of the benefits.

And if you're already wire framing, then hopefully. You know, people got some, some takeaways here on how they can improve and, and do things better, and it's always just that example you shared. It's a lot easier and cheaper to throw away a wireframe and redo it than to throw away a product. And go back to scratch if nothing else.

Like that should be the big takeaway here.

[00:40:35] Leon: Definitely. It really boils down to that.

[00:40:38] Omer: Where can tell us about, like, where can people get hold of the, the book?

[00:40:42] Leon: So the book is published by A Book Apart. You might know them. So if you go to the book apart website, abookapart.com. You'll see it on the front page there.

And you can also buy it on Amazon and some other places now too. You can learn more about wireframing on The Balsamic Wireframing Academy. So we have a section of the Balsamiq website dedicated to teaching people about wireframing. So we have a lot of talks, interviews, videos, articles, and that's at balsamiq.com/learn.

So there's a lot of really good supplemental information there.

[00:41:13] Omer: Great. I created a redirect because that was a book apart.com/product/wireframing-whatever, right? So if, if people go there and it's not on the homepage, just go to SaaS club.io/wireframing. And that will redirect you there. You can get it from Amazon, but, but when I looked, there was only the paperback version there and there is an ebook that people can buy as well.

It's not a Kindle book, but it, it what is it, like a PDF or something?

[00:41:40] Leon: I think it gives you three different formats. The mobi and epub, whatever the, the standard formats are as well as pdf.

[00:41:47] Omer: Okay, great. So, so if you want those, you'll probably have to go to the book part website. Awesome. And I'll also include a link in the show notes to the balsamic Academy, cuz I think that's a, a useful resource for people thinking about wireframing, whether they're using Balsamiq or pen and paper or whatever.

You can learn some, some stuff there. So congratulations on getting the book published. I know it's It's not an easy process. And this took, took you guys, there was three of you, and it took well over a year to, to get that done.

[00:42:17] Leon: It was, definitely very thankful to editors and the work that they do to take a bunch of random ideas and make them into something cohesive.

[00:42:26] Omer: Awesome. Well, thank you so much for, for joining me on. It's been a pleasure and you know, congrats again and hopefully we have done our job in helping some startups out there not throw away their products.

Yeah. Well that's a really valuable thing that you offer here with all your lessons.

[00:42:45] Leon: So, but I really appreciate you having me on. I enjoyed the conversation.

[00:42:48] Omer: My pleasure. Okay. All the best. Take care. Cheers.

[00:42:51] Leon: Thanks.