What's More Important -- Wireframing or Prototyping? w/ Peldi, Founder and CEO of Balsamiq

Hey everybody, it's Mike Belsito with Product Collective, back for another product lunch session. So appreciate everybody joining us on your lunch break, if it is your lunch break. For a lot of people, it is morning. For some of us, like our guests, it's actually close to dinner time. So regardless of what the time is on your end, I appreciate you being here. I wanted to, you know, we have our guests Peldy from Balsamiq, and I'm super excited for him to join. But I just— a couple quick announcements first. I mentioned it in the chat. If, you know, once we get started, sort of difficult for me to help troubleshoot. If you have any issues, usually a quick restart always helps. But these are all recorded and you could stream this session immediately afterwards. So that's pretty cool in case you miss out on anything or something pops up and you have to leave us. Hope that you don't, but know that that will be the case. Also, just, we have, well, 3 things I wanted to mention. First, we at Product Collective actually have a podcast coming up. So keep your ears open for that. If you already get emails from us, great, you'll be hearing about it soon. If not, you can send me a note, mike@productcollective.com. I can make sure we can keep you posted, but really excited. We've done a few interviews already. It's specifically for product people. I think it's gonna be a fun podcast and hopefully we'll learn a lot too. So stay tuned on that. Also, the next product launch session, it's coming up in 2 weeks. It's, well, it's actually Wednesday, June 7th, and it's with Jeff Lash, who's a VP at Serious Decisions. We'll be talking about the perfect product team. So I think that that will be a lot of fun as well. And then just one last announcement here, and that's for those of you keeping tabs on our conference industry, we just announced the last batch of speakers announced. So now the full lineup's available. We have a preliminary schedule. You could go to insum.com for that. Actually, there's just a green button there, so you could click on that later on and check that out. But the last two speakers we announced, Blade Cuttelly, who's a design leader at Sonos, and Nick Caldwell, VP of engineering at Reddit. So super excited for them to join us along with everybody else who'll be joining us as well. So that should be a lot of fun. But with all that, I wanna get into the meat of today, which is a conversation with Peldi. Peldi, thank you so much for joining us. I really appreciate it.

Thanks for having me.

And, you know, with your role at Balsamiq, by the way, I'm, I'm sure you're a familiar face to a lot of people that are joining us for the session. Um, but for those that haven't, you know, for some reason spent a ton of time in Balsamiq before, maybe you could just give sort of a, a quick shout, quick intro of, of what Balsamiq's all about and, and your role there.

Sure, Balsamiq is a wireframing tool. Hopefully this crowd all knows what that means, but we'll talk about it later, I think, as well. But it's just a little software tool for desktop and the web, and it's my baby. I started it by myself in 2008, and it's been growing ever since, and now we have a fantastic team of 25. If you can believe it, for such a small tool. It takes a village. But we have so many customers, we wanna support them as best as we can, and so we grow the team accordingly.

That's awesome. Well, you know, I know one of the things that you and I had gone back and forth about is that one of the things you're passionate about is the differences between terms like wireframing and prototyping. And sometimes they might be used interchangeably when they really shouldn't be. Could you maybe just talk a little bit about that and maybe share your perspective on that?

Absolutely, absolutely. The term prototyping is kind of like the term UX, where it now means everything. It kind of stuck as an umbrella term, but if you were to differentiate wireframes from prototypes, I think the, The best way to do so is that a prototype is sort of designed to mimic the end product as much as possible. So things like dynamic content or conditional flow, animations, uh, data coming from a server, you know, or, uh, views that are reactive to the window size, you know, or you could do math in it. All these things are really things that you do in a prototype. Wireframing, on the other hand, competes more with pen and paper. So to me, they're very different things. One is early stage and one is optional. I think it's a waste of time 90% of the time, but, but it, it's designed to be more like the finished product, so Um, some people call Balsamiq a prototyping tool because we have the ability to link screens together, but I die a little every time people say that we're a prototyping tool. Um, we're a wireframing tool where you can do a very, very lightweight prototyping.

Got it, got it. And you know, for, for the session we're doing today, a lot of the folks that are joining us, they're, they're product people, and, and some might be UX professionals and designers as well, but I know that there are a lot of product managers. Should wireframing be important to a product person, or is it something that is specifically for, you know, design UX? Maybe you could share, especially, you know, seeing the types of people that have maybe used Balsamiq in the past and now who uses it, like maybe you could talk about what types of people these tools actually can serve or should serve.

Sure. So, um, I, uh, am a developer. I used to be a developer. And, um, uh, Adobe, I worked with a product team that had, um, a product manager, developer, um, designer, um, etc., etc. But, uh, so we will get in a room and wireframe on the whiteboard like crazy, and then I would have to go and take a picture, you know, do not erase, you know, and try to replicate it. But, um, what was nice about that is that, um, everybody— the, the playing field was pretty even. Everybody could jump in with their idea, right? Um, it's not the same with Photoshop. It's not the same with prototyping tools because they have a steep learning curve. And so, well, for instance, for visual design, so the look and feel of each screen, it was— we always had to go through the graphic designer, right? We all— it was always a, okay, you do it, you put your hands in the design, and we just were only allowed to tell you what we would change, right? And it's the same thing with prototyping tools. If, if they're tools that are hard to use, it ends up that it's inefficient. You have to go through one play, uh, one person. You cannot truly collaborate on an even playing field. Uh, or why wireframing tools are different because they're simple to use. I designed, um, I had the idea for, uh, Balsamiq by talking to a product manager friend of mine who had fantastic ideas but didn't have any way to express them other than writing requirements in text. And she will go through great lengths trying to describe these interfaces, and she was afraid to sketch on paper because she felt like, oh, that doesn't look professional enough, you know, or maybe I should leave the designer to do this. But her ideas were much better than the designer. Our designer was more of a graphic design guy, not a information architecture guy. So I was like, let's find a tool for you. And I looked and looked to try to help her, and I would sit with her and try to do it with her, and I couldn't find one. So I thought, I'm designing a tool just for you. It has to be for product people because they have great ideas and no way to express them. It has to be as easy to use as PowerPoint, because, uh, product managers know Office better than anyone else, right? Uh, it has to be, um, as easy to use as PowerPoint but also powerful enough that the development team will adopt it. So it's got a bunch of keyboard shortcuts and stuff. And that has to be decent enough that designers will also adopt it to collaborate, to participate in the, uh, in the process. So to answer your question, yes, wireframing should be absolutely what product managers do, and a ton of our customers are product managers.

Yeah, I love that. I didn't know that really the origin story involved empowering a product person to get involved in the process. I think that's awesome. By the way, to everybody else, before I go on with questions, or I rather, I will go on with questions. But if you have questions for Peldi, especially if it's about one of the topics we're talking about, there's a special section for that, questions and answers. Put it there. I have that pulled up right in front of me too. So I love checking every so often to see if there's questions from the audience. I love to try to integrate that. So you don't have to do it now, but feel free to do it at any point during the conversation. You know, one of the questions I had for you is just, You know, we had in the past somebody who had really the whole session was how product people could best work with designers, developers. I imagine, you know, wireframing, it's a process that involves really all those groups, but especially the design team and the product team working together. Do you have any feedback on how those groups can best collaborate, especially when it is, you know, going through the process of something like wireframing? I imagine that you know, you've seen how teams collaborate well and maybe some things that didn't work out so well too. So I was curious about that.

Sure, yeah, definitely. Definitely, you know, if a team wireframes, teams that wireframe together stay together. Meaning that we think of wireframing as really drawing on a pencil, right? Drawing with a pencil or a marker on a whiteboard. So Everybody should be allowed to do it. It shouldn't be just the designers that do it because good ideas come from all over the place. Now, it doesn't mean that, you know, with a pencil you could draw really well or you could draw terribly. So wireframing is a tool and you have to know how to use it effectively. So I think by setting good expectations and having good team dynamics where ideas are accepted from everywhere and critique is accepted openly, then the more people wireframe, the better, because you get little bits of ideas that you can then that you can then collate into, into a final design. Um, we even include our customers in wireframes. We say, we're thinking of building this, what do you think? And they send us their own version because they use the product more than we do, so they, they know it better, right? So, um, so very much, uh, I would say, uh, encourage everybody to wireframe, um, encourage everybody to learn How to wireframe well? Study some books or do some classes. We have a website called UX Apprentice that is designed to sort of help you, you know, learn how to make good wireframes, not just any wireframes. And, you know, a lot of it is common sense stuff that can be learned fairly easily. We're gonna put out a lot more content this year about, user interface design specifically for beginners. Just, you know, to help people work with the tool well. And then, yeah, I'd say that's it. Basically, use tools that everybody can use to communicate more effectively. And don't be afraid to jump in.

Yeah, that's great. That's great. And actually, this— there's a question that popped up from the audience in terms of wireframing as a tool or a process. And the question was, do you view it as a thought tool? You know, is it a demo tool, interface spec, all of the above? Or, you know, maybe you could, you could just talk about like which of those areas it works best for, or maybe what it doesn't work best for too.

Yeah, yeah, yeah. So that's a great question. It's definitely, it serves more than one role. There's definitely a moment where you just put your headphones on, you have an idea, and you just have to clarify your idea to yourself. And so we— in Balsamiq, you can turn on background music, which is this sort of zen, relaxing concentration music built into the app so that you can, you know, close Slack and all the other distractions and just bang it out in half an hour or so. So that's definitely, I think, my favorite part because it's the most super creative part. And you do one and then you do another one because wireframes are quick. That's the whole point. You throw it away, you start over. Let's explore another idea completely. The more you do this, the better the end result is. So as a thought tool, it's absolutely critical. Some people like to do this first phase on paper, totally legit, you know, because you might be in bed, you know, and with a little notebook, right? And you have an idea. So we see people that do that and then switch to Balsamiq to finish clearing out their thoughts. That's totally fine. Then once you have the design, it becomes more of a, let me sell this to the team. Phase, right? And so maybe you do some user testing, maybe you go to a team, and, uh, but again, I think there should be a little intermediate phase where, hey, what do you say? This is my idea, but it's still a draft. Let's talk about it and be ready to throw it all away and do it again. And wireframes are great for this. Then, um, and so we have a sketch, sketchy look, just because We want to make sure that people give good, quick, real feedback. If they don't like it, they're going to tell you, right? So it has to look like you did it really quickly. Then what you could do is if you have to sell it to a client or someone, you could switch the skin to what we call the wireframe skin, which is more clean lines. Basically, this is— this means I don't really want any more feedback on this. I'm just presenting it and this is what, you know, I'm 90% ready with this. So you switch the skin and it looks nice, professional, and people hesitate giving you feedback at that point. We've heard this from several customers. And then it's more of a presentation, right? And you talk to, uh, uh, whoever, uh, about the, uh, what the, what the plan is, and you go through all the different screens. Then there's another, uh, role which is, uh discussion with development. And so there you add a bunch of annotations— this, this, and this— and the development gets involved and they add their own annotations and they say this is too hard, this is— this will take too long, blah blah blah. So there are really— they're a really effective communication tool that serves these phases. Uh, some people before they go to development, they, they go to a prototyping tool That's fine too. And then they go to development. But yeah, so it's very much for the first 2 or 3 early stages of ideation.

Got it. I'll take another audience question here. Somebody had asked, do you find users specifically are wireframing more for the web, like actually, you know, traditional web or mobile, or really, and this is my addition to it, is it just Hey, it depends on really the product. You know, I guess curious if you see wireframing used in one use case more than the other these days.

Uh, so these days we, uh, when we see, uh, sightings of people using it all over the web, uh, there's always an iPhone, uh, in the wireframe. It's very much mobile first. Um, but then, uh, we have a lot of web. When I started 2008, desktop was the sweet spot. And now it's kind of coming back, uh, with the, you know, the trend of having desktop apps that sync data to the cloud but, uh, you know, have the power of desktop as well. So, so it's really for everything. Um, but yeah, we see mostly mobile these days. Yeah, which is nice.

Yeah, got it. Somebody else had asked, hey, you know, if prototyping, if that is more of a waste of time You know, what, like, do we go right from wireframing into coding as far as user experience? Or maybe you could talk a little bit about why you feel like prototyping isn't often the answer that people think that it is.

Absolutely. Prototyping is still kind of considered hot, but it's really a legacy of the waterfall days where you would do a spec in Word and it was 20 pages. And then you would send it to development and the development would take 2 months, 3 months to get anything back that you could play with. And then of course, so in that case, it makes sense to do a prototype because you make, that way you can, you know, convey as much information as possible and sort of reduce some of the risk because if the developers take 3 months and they come back with something crappy, then you're in trouble, right? But, but those days are gone. Now it's agile, now it's quick sprints, it takes a week, the tools are easier. Um, it's so much easier to, uh, to take an idea from a wireframe and code it up real quick using Bootstrap, using whatever framework you're using. Um, and so do that in 2-3 days, uh, just enough to play with it. It doesn't have to be hooked up to the server, you know, but it's super simple to do that. For a developer and then play with that. And that's the real thing, so it will feel exactly right. And guess what? That code you get to use in the real product. You don't have to throw away the prototype, right? So just go back and forth, and if it doesn't look good— we do it all the time— you go back to the wireframe, do another iteration on the wireframe. We might— you might throw away 15% of that code, but you get to keep the other 85% usually. So yeah, do quick sprints and go wireframe, code, wireframe, code, wireframe, code. Unless you're doing a satellite where it's in space and you can't really change things once they're in space, then in that case, sure, prototype the heck out of it. But, or a car, I don't know, there's some cases where it makes sense. But 90% of people these days work with fast developers that use tools that, you know, allow them to be really fast.

Yeah, well, I wanted to ask you a question, and this is kind of going back from, you know, my early days as a product person. I was lucky enough to have an awesome UX, you know, professional that I worked hand in hand with, and that person would really end up doing, you know, a lot of the wireframing and those types of things. But I, you know, I do think if I was getting back into that role now, like fast forward, or if I could rewind time, I suppose, It would be really beneficial for me to have had that experience. For people that might have been in my shoes where they're just, you know, product people, not even designers, just product people that are just getting their feet wet with wireframing. Do you have advice for them on the best place to start, or at least, you know, advice on how to, how to get going the right way and not put themselves in a bad place for later?

Definitely. There's not really a bad place because you learn pretty quickly. Or what I would say is a couple of tips. One is put your wireframes in front of users as quickly as possible. Don't be proud and don't be afraid. That is the best thing you can do to get better, right? So do paper prototyping. You print them out and you show it to them. And that is really, I think, the most painful way to learn because you realize that they don't see the big button that's right there, right? And that teaches you a lot. The other tip I would say is buy a book, like a classic, like About Face, Alan Cooper, right? That's the Bible. It will— there's a whole chapter on when to use a checkbox versus a radio button. When to use a button versus an icon button versus a menu button, you know, or a combo box. So it's the basics, right? Buy the book, read it, and you'll, you'll be, you know, on your way for sure. Or do an online class, or come to our website and we'll help you out, you know. But there's really no, no wrong way to go about it. The learning curve is really quick, meaning that you can get started right away and you get better really— it's like snowboarding. The first couple of days suck, but then you're fine, then you're done. You've learned 90% of what you need to learn, right? Similar thing.

Yeah, I like that, I like that. Well, I bet a lot of people that are joining us live they have much more experience than that. Some people might even be quite experienced at wireframing, yet I bet still there are mistakes being made. I'm curious your take on common mistakes you've seen, especially, you know, even for people that would consider themselves to be, you know, veterans or really experienced with wireframing.

Oh, for sure. I mean, developers always start from the data. How the data is saved, right? They have in their mind how, how I'm going to save all this data, and then basically they map that one-to-one to the screen, right? The database columns become all the different inputs, and that's usually too much stuff on one screen for, for normal people, right? So that's, that's one thing. The other problem thing that developers, uh, mistake that developers make is to have this sort of religion about being consistent. So if we do, if we give the ability to color a button, then we have to give the ability to color everything. That's not true. You know, humans are not like that. Humans are imperfect machines. And so, you know, do what makes sense for the human. You're not their target customers. And then for product managers, I don't know. I don't know of more glaring mistakes, but usually the most normal one is to try to cram too much in one screen and not give visual hierarchy or, you know, there's some, there's some It is an art and people who do information architecture and wireframing as a career, they're very valuable because it does take a long time to become really good at it. And so over time you learn about making things in context, right? So if there's something that needs to be edited, don't put the controls too far away to edit it, put them as close as possible, right? There's a lot of best practices that you sort of learn over time. And at the beginning, you don't know, so you're kind of— it's too much. And in fact, a lot of product managers adopt Balsamiq because they're intimidated by the white sheet of paper. But we give you 75 different pre-built pieces, and they feel a little more comfortable using that because they know that if they use those, then those are buildable, you know, by a developer. Yeah, jump in.

Yeah, well, and I did want to— I saw in the, in the chat there are some people that have been using Balsamiq for years, easy to use. It's probably one of the reasons why. There are also a couple people that had said, hey, um, it might even be even more easier or faster, uh, if it— if there wasn't Flash on the backend. Some people had asked, hey, is there, is there a plan? Is that a part of the roadmap at all?

We've done nothing other than getting rid of Flash for the last 2 2 years basically. Um, the current code base has 1.5 developers on it, uh, for the last year or so. We have like 7 or 8 developers rewriting the whole thing so we can, uh, be native on web, desktop, uh, you know, Mac, Windows, and tablets coming next year. Um, right now we are in a private beta of the new web version that is no flash required. We're gonna go early access in a few weeks. So it's finally coming to the end of the tunnel and it kicks ass. It's quite amazing actually.

It sounds like you're gonna make a lot of people happy. So that's awesome. I'm glad—

Ourselves first.

Great to hear your product launch today.

Yeah, yeah, yeah.

Well, we're getting towards the end of our time, Peldi. Just any sort of final thoughts that for folks that are here that you know, again, product people specifically, if there was one takeaway that you wanted them to leave the session with, does anything specifically come to mind?

Uh, yeah, basically the— first of all, help, help me out here and try to use the right term, wireframing or prototyping tool. Um, and, you know, spread the, spread the gospel. And the other thing about prototypes that I wanted to say is that, um, The inherently, you know, real rich prototypes, they take a while to put together. There's no, even with the best tools out there, and there's some great prototyping tools out there, but it's good. You're not going to do it in half an hour. You're going to build a prototype in a day, 2 days, 3 days if you're good. I've heard lots of people where it takes a week or 2. And what happens is once you spend a lot of time on something, you grow attached to it. Even if it's not good, you've spent so much time doing that, you don't want to change it anymore. That's why I think that prototypes are actually harmful a lot of the times because once you've grown attached to it, and you will because it takes so long, you're not going to take feedback as openly. People are not going to give you as honest feedback because they know you spent so much time on it. They don't want to hurt your feelings. And so what happens in the end, you ship products that are suboptimal just because you chose the wrong process, right? So do quick wireframes, don't fall in love with them, go to code right away. It's so much more, you end up with a better product for your end users.

Yeah, well, I appreciate that. And we're at the end of our time. I just want to thank you again for being a part of this. There's a lot of awesome feedback and advice that you had shared. And you had mentioned actually before we went live, Peldi's going to join us in the Product Collective Slack. So if you have more questions, you could ask them there, and maybe he'll be able to even jump in every now and then and get to see some folks there. So I appreciate you doing that, Peldi. That means a lot.

Absolutely. If you have any questions that I didn't get to today, I'm going to hang out in the chat in Slack for a couple hours today and then tomorrow. So And then I'll keep it open. I love, you know, I'm a wannabe product manager. I wanted to be a product manager and I couldn't get a promotion to do so. So I quit and I decided to start my own thing instead.

Well, I think for everybody's sake, you made the right decision there. So glad that you did that. Well, thanks again for joining us. And yeah, I'll see you in the Slack and I'll see everybody else there too.

Awesome. Thanks everyone.

Bye everybody.