Omer (00:09.760)
Welcome to another episode of the SaaS Podcast.
I'm your host, Omer Khan and this is the 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 Michelangeles 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 wireframes and others assume that wireframes are something that only product designers should create.
Today, we're going to give you a Wireframing 101 for SaaS startups masterclass.
Our goal is to give you the knowledge and tools needed to craft effective wireframes and dodge common pitfalls and navigate the wireframing process successfully so you can design great SaaS products.
In this masterclass, we're going to cover the critical role of wireframing in product design and development, proven techniques for creating user centric wireframes, the benefits and drawbacks of various wireframing 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.
Leon Barnard (01:29.750)
Thank you.
Great to be here.
Thanks for having me.
Omer (01:32.550)
So tell us about the book.
We're going to talk about Wireframing 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?
Leon Barnard (01:46.150)
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 Angelus.
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.
Part of it, which is why we put it in the title, because we feel like wireframing is not something just for designers.
You know, we were kind of inspired by books like Lean ux, UX for Lean Startups, the Lean Product Playbook, some of these books that your listeners might already know.
And all of those books mention either wireframing or kind of this idea of quick and dirty prototypes or just being very iterative and not spending tons of cycles on big design or doing kind of anti waterfall.
And so we felt like in these books, when they got to the part about wireframing, we're 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 lean, more efficient, more iterative process.
And so our experience was there's a lot of books about UX design, UX techniques, and the way it's taught in boot camps and things like that.
It's kind of taught in a vacuum.
And so we really wanted to have a book about UI design and wireframing in the context of the real world and how to use it as part of a process 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.
Omer (03:34.740)
Okay, great.
So before we get into talking about like, why wireframing is important and why people listening to this should be thinking more about using wireframes if they're not currently already doing so, let's just start with what's the simple definition of wireframing for someone who doesn't know?
Leon Barnard (03:57.180)
We try to really zoom way out and take it 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 know, 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 sketching and communicating ideas.
Omer (04:35.030)
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 wireframes with their product development?
Leon Barnard (04:53.160)
So I know your audience leans towards founders and SaaS, founders specifically.
And I think for those people, it can be really, really useful.
Because when you have an idea for a business these days, building the product, writing the code, shipping it is kind of the easy part relative to the other thing, 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 a 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 want to do?
What are some creative, innovative ways to solve these problems?
How do we differentiate ourselves?
And once you get into the coding or the look in the field, that's not the time to be thinking about those things.
It's kind of too late.
At that point you're locked into a certain design or 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 you might do that 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.
Our philosophy is really take that extra time to play around and get creative early on because that's what's really going to set your product apart.
Omer (06:34.780)
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, 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 not as simple as that.
And there's a lot of work that needs to go into figuring out kind of all the different aspects of a best selling book before you can just start typing and publishing one thing before 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 should own wireframing and kind of who's the best person to work on this?
Leon Barnard (08:03.530)
Yeah, that's always, that's been a long standing debate and you'll find designers who hate it when PM's wireframe and it's frustrating for PMs or founders who are like, I have this idea for something 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 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 product cycle are we in?
So in the book we actually describe three different phases of wireframing.
Your 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 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 want to get it down, you want to 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 going to 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 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 were I to build it?
How do I translate some of these ideas 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 flesh out and articulate your ideas.
So rather than thinking about them as the wireframes or the deliverable, it's just another tool or technique.
And you can mix and match.
You can put a wireframe inside of your PRD or your pitch deck or whatever.
Sometimes a picture is a better way to communicate than words.
And so don't feel like you're not allowed to draw a picture.
And then so the designer should be comfortable getting wireframes 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.
They should really be seen as these kind of transitional artifacts.
Omer (10:48.180)
Yeah, 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 going to 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 going to 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 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?
Leon Barnard (12:11.190)
You really nailed it.
And that's such an important point that if you deliver something that looks like a final product, you're going to have an entirely different conversation around it.
Maybe your designers or your developers are going to push back because they're going to say, well, that doesn't line up with our design system or the, I don't know how to write the code for that or whatever.
But if you put out something that just looks like a rough sketch, then the goal is kind of like, let's have a conversation about this.
Let's talk about this.
We're going to 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 that 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 going to 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.
Omer (13:28.540)
So let's talk about building your first wireframe.
So let's say I'm a founder.
I've got this idea in my head and 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 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.
Leon Barnard (14:16.830)
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 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 was an understanding of what's the problem, 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 knowledge that they have about the customer and the problem.
And don't try to just think about how am I going to build this thing, but really try to think about, okay, what, you know, try to focus on asking the right questions.
Because 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.
Going back to what I said earlier about 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 going to be a form.
Here are 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 a non designer, is just draw a site map or draw kind of a flowchart 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 converting.
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 will go a long way.
You don't have to become an expert in it.
Omer (17:06.800)
I don't know if you're familiar with the concept of like Fat Marker sketches that basecamp, you know, the Team 37 signals.
I don't know what they call themselves these days.
Is it basecamp or 37 signals?
Leon Barnard (17:20.320)
I didn't know that it came from them, but that is one of my favorite kind of analogies or ways of talking to people about this sort of thing.
Omer (17:28.560)
Yeah.
So 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 a way of.
I mean, no one is going to 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 going to be a field, there's going to be a button, there's going to be something that's going to do this.
I don't really know how it's going to get laid out.
I just know it's going to be on the page somewhere.
And let's talk about 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 using tools.
That actually is a really 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'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.
Leon Barnard (18:59.680)
Yeah, actually, one of the.
That's a good reminder.
One of the techniques that we mention in the book is about, like, content modeling or say you're designing a landing page, just write a bunch of sticky notes, whether it's.
Whether they're digital sticky notes or actual ones, and think about the priority 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 has the word so you know, what goes there.
So thinking about the content first, that's the first step to design.
Before you then think about, is the navigation going to be across the top or on the side?
Omer (20:08.480)
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 we 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 the early kind of phase, we're going to have different ideas.
That we're going to consider try out.
Nothing is set in stone right now.
We're just exploring that.
Just kind of have just kind of everybody knowing which phase you're in, kind of.
I think it will help to set expectations kind of more clearly with everybody.
So I like that a lot.
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, there's Balsamiq, because you guys work on that every day.
Give us kind of a quick overview of what's 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.
Leon Barnard (21:34.410)
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, 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 canvas.
And then the other thing that I say to look out for is 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 the fat markers thing.
You know, what's great about fat markers is they prevent you from doing anything 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 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 to do both.
So on the lower end of the spectrum, there's tools like Balsamiq.
Whimsical is another tool that has wireframing capabilities.
Miro is really popular.
There's 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 going to get fixated 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 going to lose sight of who you're building it for, what the real problem is that you're seeing, solving.
And so, you know, you don't have to use Balsamiq, 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 just a plain old whiteboard in your office, you know, the old fashioned way, I think that you're going to have much better wireframes using a tool like that than a really powerful, complex tool that's focused on UX designers.
Omer (24:53.880)
Yeah, I used to, 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 all that stuff and it was tedious and it was slow and painful.
And then I remember, I don't know if you remember this.
What was it called?
Kinotopia.
Leon Barnard (25:15.530)
Yes.
Omer (25:16.330)
So some guy, I can't remember his name, I'm sorry.
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, because maybe that's where it started.
But I felt that that was for a later stage because most of the things in the library were quite high fidelity.
And so if you want to go for sketching low fidelity wireframing, it wasn't really.
You were more likely to piss off the designer by coming and saying, hey, this is how it looks and you know, 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 a team at a startup and 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 GoodNotes 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, what's, what's useful, what's simple that you can use to, to communicate those ideas.
And I think that that's the, the other thing that I think you and I had talked about this earlier is that we want to kind of make sure people understand is there is no perfect tool.
You got to pick the right tool for you.
What's going to 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 going to 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 communicate wireframes.
Leon Barnard (27:14.920)
Absolutely.
Omer (27:15.880)
Okay, so we've talked about.
Is there anything else that you want to add on what we've just sort of mentioned about the tools?
Leon Barnard (27:23.160)
Well, just as you were talking about all this old stuff, I mean, I started wireframing at the same time, so it brought back a lot of memories.
But one of my co authors, Michelangelos, achieved some notoriety a long time ago because there was this tool, Omnigraffle.
I think it's still around.
And he created a wireframe, they called them stencils in Omnigraffle.
So he created the first or the most popular wireframe 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 wireframes 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 pre built wireframe widgets, but yet that weren't overly prescriptive or overly designed to look like the final product.
Omer (28:21.460)
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 how to go about approaching this and thinking about the different phases and how you should think about your first wireframe and all the other things you should be thinking about before you start actually sketching it out in 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 wireframing and very easy to kind of screw things up.
Let's talk a little bit about that.
What are some of the common mistakes that you've seen in your experience?
Leon Barnard (29:10.730)
Well, we kind of alluded to it earlier, but the most common mistake is diving too fast into the design too early, thinking that the goal of creating a wireframe is to create kind of a, you know, a skeleton of the final product.
If you do that right away, then you're going to end up tied to that product and you're going to start, want to 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 the product.
Or what if I did this primarily as an API or WordPress plugin?
You know, you get fixated on what it's going to 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 the user interface.
Omer (31:46.730)
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 Matt, who's the founder and president at Planorama Design, where we went through teaching people about using user stories.
And I think that's very complementary to thinking about wireframing, because 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 problems that.
Or meet that need.
Solve that problem or meet the 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 complement with this episode to sort of think about if you're not sure what to do before you start wireframing and you want to think a little bit more deeply about the user.
Consider user stories as a way to think about that.
Leon Barnard (32:48.160)
Yeah, If I could just add 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 that 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 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 thinking 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 limitations can really be helpful to keep you focused.
Omer (33:58.650)
Totally agree.
So 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 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 off 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 want to articulate that maybe they've been going out and spending a bunch of time talking to potential customers and they want to come back and share that and sort of just get those ideas down.
Awesome.
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 go and build it.
Or maybe I'll hire a visual designer to make this look kind of cooler than 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 least some point in the process you should be involving some type of designer, whether it's somebody on your team or finding a great freelancer to at least review what you've done and help you kind of address some of the flaws in the design and the way you're thinking about the product.
Right?
Leon Barnard (35:40.110)
Yes.
And actually, 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 wireframes where you're starting to think about, okay, what kind of UI components would be appropriate here?
And then learning how 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 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 understands the role and is not just going to give you 500 high fidelity wireframes that are going to show you every screen and every variation on that screen and charge you a ton of money.
Think in terms of templates.
Think about, have them create some basic templates, have them create a basic design scheme or a 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, we can use the Google login authentication or, or Dropbox has already figured out a really good way to do revisions or version control or something like that.
We don't have to steal that, but use that information and we realize that you don't want to 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 optimize their effort for the things that are most specific to your problem.
And you know, yeah, like I said, if they're coming up with an image or 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 going to be written anyway.
It's going to be, you want to 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 designers to think.
Also, you know, if you're thinking about how am I actually going to implement this, at some point this is going to turn into code.
So you also have to think a little bit like a developer.
Omer (38:09.310)
Yeah, that's great advice.
I think the idea of just thinking about templates, reusable components, not just for code, but also for design, is a great approach.
And I think it will actually save.
Save people a lot of money that they potentially could spend creating thousands of screens and maybe put more of that budget towards hiring a more experienced UX designer who can come in and really help them nail 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 there's some lessons to be learned about, you know, not kind of doing this the right way?
Leon Barnard (38:49.470)
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 code and the look and the feel, but they kind of bypassed that early step of asking the right questions, asking the big picture questions.
And so obviously then they 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 want to 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 going to 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 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 develop them further on.
Omer (40:31.830)
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 wireframing, then we're never going to 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 some of the benefits.
And if you're already wireframing, then hopefully, you know, people got some takeaways here on how they can improve 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.
Leon Barnard (41:20.270)
Definitely.
It really boils down to that.
Omer (41:23.930)
Tell us about where can people get hold of the book?
Leon Barnard (41:27.690)
So the book is published by a book apart.
You might know them.
So if you go to the Bookapart website at bookapart.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 Balsamiq 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@balsamiq.com learn.
So there's a lot of really good supplemental information there.
Omer (42:03.010)
Great.
I created a redirect because that was a bookapart.com product.
Wireframing, whatever.
Leon Barnard (42:10.130)
Right.
Omer (42:10.690)
So if people go there and it's not on the homepage, just go to SasClub IO Wireframing and that will redirect you there.
You can get it from Amazon, 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 what is it, like a PDF or something?
Leon Barnard (42:31.210)
I think it gives you three different formats.
The mobi and ePub, whatever the standard formats are, as well as PDF.
Omer (42:38.330)
Okay, great.
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 Balsamiq Academy, because I think that's a useful resource for people thinking about wireframing, whether they're using Balsamiq or pen and paper or whatever.
You can learn some stuff there.
So congratulations on getting the book published.
I know it's not an easy process.
And this took you guys, it was three of you and it took well over a year to get that done.
Leon Barnard (43:13.330)
I definitely am very thankful to editors and the work that they do to take a bunch of random ideas and make them into something cohesive.
Omer (43:22.690)
Awesome.
Well, thank you so much for joining me.
Leon, it's been a pleasure and congrats again.
And hopefully we have done our job in helping some startups out there not throw away their products.
Leon Barnard (43:40.510)
Yeah, well, it's a really valuable thing that you offer here with all your lessons, but I really appreciate you having me on.
I enjoyed the conversation.
Omer (43:48.110)
My pleasure.
Okay.
All the best.
Take care.
Cheers.
Thanks.
