Episode 143: Harnessing the Power of Wireframes with Ellen Chisa, Partner at boldstart ventures, and Leon Barnard, Education Team Lead at Balsamiq
In this episode of Product Thinking, product experts Ellen Chisa, Partner at boldstart ventures, and Leon Barnard, Education Team Lead at Balsamiq, join Melissa Perri to discuss the importance of wireframing in product development. They explore the collaborative power of wireframes in product teams, using wireframes as conversation starters, and the benefits of designers having front-end coding knowledge for efficient product outcomes.
You’ll hear them talk about:
[01:44] - Leon and his colleagues at Balsamiq authored "Wireframing for Everyone," with a foreword by Ellen Chisa. The motivation behind the book was to fill a gap in available resources, highlighting wireframing as a universal tool across all software disciplines. The book targets Product Managers and non-designers. Ellen states that even while working on the programming language Dark, wireframing was crucial. As an investor, she now advocates for early-stage founders to employ wireframes to improve clarity and collaboration in their teams.
[05:20] - The roles and responsibilities in product teams aren't just restricted by titles or traditional terminologies. It's essential to focus on effective collaboration and communication to get work done. Sports analogies like a baseball or basketball team highlight teamwork, practice, and communication over individual superstars. Different team members, including PMs and UX designers, can use wireframes to share their ideas more clearly. While wireframes may differ based on the creator, their primary purpose remains to visually communicate an idea and resolve uncertainty.
[09:47] - When creating wireframes, it's essential to maintain a high-level perspective and avoid getting lost in tiny details. Using tools like physical whiteboards or purposefully limited wireframing tools can help teams stay focused on the broader picture. You can also assign someone the role of ensuring the conversation remains top-level. Avoid overcomplicating with powerful UX tools that may distract attention from the user's primary goals. Remember, the objective is to prioritize the overall user experience over complex details.
[15:07] - The shift towards a mobile-first approach in design has been increasing. However, one of the significant developments in web and app design has been the rise of design systems and pattern libraries, offering pre built components. To streamline the design process, integrate these systems into wireframes, providing placeholders that mirror real components. For designers presenting to executives, using wireframes should aim to spark dialogue rather than seek some form of approval. Making designs slightly ambiguous can encourage engagement and questions, turning wireframes into real conversation starters.
[22:10] - Jumping straight to a high-fidelity prototype or coding might seem efficient, but it can lead to wasted effort if the final product doesn't meet real-world needs. While high-fidelity prototyping is valuable close to development, the initial ideation phase is crucial to ensure product-market fit and differentiation. It's like prototyping methods for choosing between a pencil and a paintbrush: each has its time and place in the creative process, and one doesn't necessarily replace the other.
[29:33] - Designers can greatly benefit from knowing front-end coding, especially when using actual code that will be part of the end product. This knowledge helps in maintaining consistency and making better design choices. Just as product managers debate their need for technical knowledge, designers too should have coding awareness, which, in the end, leads to more efficient product outcomes.
Episode Resources:
Other Resources:
Melissa Perri – 00:00:36: Hello and welcome to another episode of The Product Thinking Podcast. Today, we're talking all about wireframing and the importance of it for product managers. Joining us today are product experts, Ellen Chisa and Leon Barnard. Ellen is a partner at boldstart ventures, a seed and early stage venture firm. Before working with boldstart, Ellen started Dark, a backend programming language, and worked primarily in the product sphere prior to that at companies such as Lola and Kickstarter. Leon is a user experience specialist who now leads the education team at Balsamiq, a wireframing tool company. He's the author of Wireframing for Everyone and started the Balsamiq Wireframing Academy. Leon has almost 20 years of experience and interaction in UX design for companies such as OptimisCorp and Ataccama Software.
So before we dive into all things wireframing, it's time for Dear Melissa. On this segment of the show, you can write into me any question that you have about product management, product strategies, situations at work, whatever it is, and then I will answer them for you.
All right, so if your UX designers are not doing any user research whatsoever, and they have no desire to learn about your customers, they're a graphic designer, they're not a UX designer. I expect all of my UX designers to understand deeply what the customer is doing, to want to know what the customer is doing, to want to understand the product and how all those things come together. And if you're working with somebody who's not doing that, you kind of have to take some of the reins and give them a lot of direction. So you've got to go in and step in and do the user research, you should be doing it anyway, but you're going to have to guide them a lot. And in this case, I'd say they're probably doing your team a disservice because they're just kind of there to make things pretty, but not necessarily usable. So what can you do to help them steer in the right direction to solve good problems? Anytime you get designs back from them, I would start to critique it on a level of, can people use this? Does it solve a problem? How usable is it? Does it actually accomplish what people want to accomplish with their goal? And start to ask those questions. And as a Product Manager, you do have the right to critique UX designers' designs, right? You don't want to ship a product that's not going to solve problems for other people. So I think you want to take a step back and understand with your UX designer, are they not doing user research because they don't know how to, or they haven't done it before? In which case, can you guide them? Can you do it with them? Can you introduce them to this type of framework? Or are they doing it because they don't want to and they just want to make pretty designs in a corner and never talk to anybody again? If it's a lack of knowledge, you can actually solve for that. You can help get them the right coaching that they need. You can help steer them in the right direction. But if it's a, I don't really want to do this, then we're going to have bigger problems, right? And it might not be the best fit for your team.
Now, as a Product Manager, you don't have the ability to choose your team, which is definitely frustrating. So you're going to have to make the best out of it. You might have to step in and do a little bit more legwork on the UX side, which is never fun, to take on more work when somebody's there and hired to do it, but you're definitely gonna want to do that for the sake of your product. How do you help steer this person in the right direction? And how do you surface up maybe to management that the expertise aren't there if somebody's not willing to learn? Or how do you get them the coach that they need? You want to make sure that you're acting in the best interest of your customers, and that means making them great products. So you want to make sure that whoever's on your team is succeeding in that. So I would definitely raise concerns if there is concerns to be raised there.
For your UX designer, though, can you bring some user research into them? Can you show them usability studies or do usability tests with them so that they start to understand that the customers are not using it in the same way that you intend them to do? Can you bring them on user research trips? How do you get them exposure? And that's really where it would start first and see if it starts to turn things around. And if it doesn't and there's not a willingness to learn, that's where I would start to escalate those issues. All right, that's it for the Dear Melissa segment today. If you have any questions for me, remember, go to dearmelissa.com and drop me a line. Now, let's talk all things wireframing with Ellen and Leon. Ever wish for total alignment with executives, the end to those never-ending debates, results that make everyone sit up and take notice, amplifying influence across your organization, the secret, it's not just about managing, it's about facilitating. Level up your ability to facilitate clear, powerful conversations with stakeholders through Voltage Control's Facilitation Certification Program. Learn more and get $500 off at voltagecontrol.com/product. We'll be putting that link in the show notes for you as well. So Leon, can you kick us off maybe and tell us about why you wrote this book, Wireframing for Everyone?
Leon Bernard – 00:05:25: Yes, of course. I'd like to start by saying that I co-wrote the book with two of my colleagues at Balsamiq, Michael Angeles and Billy Carlson. It's published by A Book Apart, just released a couple of weeks ago. Ellen Chisa wrote the foreword, so really excited to talk about it. In short, we wrote the book because we felt like this book was the book that we wanted to have, but it didn't exist. Wireframing, I think, is something that really cuts across all the disciplines in software, and I think there's not a lot of books that are targeted at various roles on a team. I think it's really an underrated tool for communicating across those roles, and I think it does deserve its own book. And we wanted to factor in the real world of software design as well. There's a lot of material out there about Wireframing in UX realms and UX Bootcamps and such, but often those are in a vacuum. So this book is targeted specifically at PMs and non-designers, and it's all about how to get those roles involved in the design process, because a lot of those roles do design work, even if it's not called design.
Melissa Perri - 00:06:31: So Ellen, you wrote the foreword as Leon just said, your last company that you started though was a backend programming language. So why Wireframing? What made you passionate enough to say, “yeah, I want to write the foreword for that”
Ellen Chisa - 00:06:44: It's true. Before Dark, I did more UX-related things, and wireframes made a lot of sense. But I actually think wireframes are extremely helpful while working on Dark. While it was a programming language, it was also integrated into its own editor and infrastructure. And IDEs and the tools that engineers used to write software do have a lot of experience elements to them. And one of the things that was particularly interesting was when we went on our first team offsite, and all of us were engineers at this point, probably about six people. And what we did in order to work on the product was we said, “okay, here are some of the big high-level concepts we're thinking about tackling this year, whether it's the layout of the canvas, whether it's the way each API endpoint looks, whether it's how we're thinking about error handling when your code is running”. And we each drew separate wireframes of each of those concepts and just used them as a way to talk about all of the ideas and get everything out there that might be interesting for those parts of the products. And I think it was one of the most productive things we did as a small early team. And that means that when I'm talking to early stage founders today as an investor, it's one of the things I really encourage them to do to help make things clear and collaborate more effectively.
Melissa Perri - 00:07:45: That's a really nice story. I like that you all were generating the solutions for it too when you're talking about the wireframing. So Leon, can you tell us a little bit more about what's in this book? You said it's for non-designers. So what can they expect to learn?
Leon Barnard - 00:07:59: Yeah, I think PMs, founders, even developers, those are some of the core audiences who can benefit the most from wireframing. And so this book is roughly split into three parts. The first is all about why you should wireframe. And then there's a deep dive into how to actually wireframe from early stage to middle stage to more advanced wireframing techniques. And then the last bit is all about how to wireframe on a team, how to present, how to give feedback, how to use wireframes collaboratively. So we really wanted to have all three of those parts together because I think it's more than just about how to wireframe. And this book is really about not just about wireframing. It's more than wireframing. It's about how to enable better communication and collaboration using wireframes.
Ellen Chisa - 00:08:47: I think that's one of the things that stood out to me too about the book is I feel like I've often worked with designers who are good at wireframing and excited about it, but are figuring out how can I get all these other stakeholders on board. My executives don't necessarily want me to add another heavy stage to the process and they need to share how it can be quick. Or on the flip side, I've met other people who are interested in getting more involved with the design process. And so the book walks through how to actually do the wireframes and give them a little more confidence in how to engage. So I think each of the sections really applies to different challenges people may be facing.
Melissa Perri - 00:09:18: So you both just brought up this concept too, that it's not just the UX designers doing wire frames. Whose job is it for wire framing, right? Is it everybody's job? Is the UX designer responsible, but involves other people? How does that actually work?
Leon Barnard - 00:09:33: I think really one of the themes of this book is, and one of the challenges that we're faced with is, the limitation is the terminologies we use and the categorizations we use. So if we think about, talk about the UX group or the design or who does the wireframes, and I think it's better to really just think about what needs to be done to get the work done effectively. I was listening to your recent podcast when Jared Spool was on and he was talking about the analogies of a baseball team versus a basketball team. And I think one of the reasons why these sports analogies are so useful is that they have a clear metric for success, winning and losing. But anytime anybody talks about sports and about the keys to victory, it's never about having the superstars. It's all about teamwork and practice and communication and these sorts of things and it's about the coaching. And so I think we have to get started thinking in that way as product teams also. So it's not, people have different specializations, but you really have to think about the communication and collaboration as a whole. And so I think there are different types of wireframes, there are different uses for wireframes and the types of wireframes that a PM might make might be different than the ones that a UX designer or a developer might make. So a PM I think should sketch out some of their ideas in a wireframe. Sure, they can write their spec documents or whatever, but if they find themselves spending paragraphs and paragraphs explaining what's happening in the UI, they can just load up a wireframing tool and do a quick sketch that's going to communicate that idea. That's not the same thing as designing the application, they're just using this tool to communicate an idea. So everybody on a team can use wireframes in different ways simply to communicate an idea because you're all working around a user interface.
Ellen Chisa - 00:11:25: To make that really tactical, I feel like we probably all worked with PMs who maybe use an unclear word for what they're saying. I've been on teams where a PM said search, and it was clear once they did that they actually more meant something like filtering rather than just having a search bar where someone typed in text. And that might not come across in a PRD, it might not come across in a conversation because they're just using the word search. But as soon as you get to the point of sketching something, you've resolved that ambiguity.
Melissa Perri - 00:11:49: So when you're looking at getting these things down on paper, what are the challenges that you find arise from involving like non-designers in here for people who are not used to sketching, people who maybe have never like drawn an interface in their life?
Leon Barnard - 00:12:03: That's one of the things that we address in the book, and I think it also goes back to a mindset. The biggest problem that I see when working with non-designers is that they put on their designer hat. They think about, I need to make something that looks like an end product. But you really have to think about wireframes as a tool for bringing out your creativity or bringing out, getting all of your ideas or generating more ideas. So it's more about, it's not about the output. It's not about coming up as an artifact or a deliverable. It's almost like a brainstorming tool. So in one of our chapters, we talk about just how to sketch with wireframes. And yeah, you can add sticky notes. You can add words. You can add screenshots. It's more like a whiteboard that's optimized for UI design. Don't go in there thinking that I need to make something that looks like a finished user interface.
Melissa Perri - 00:12:56: One of the things that I really liked when I was first starting to teach UX, somebody came over and showed me, they were like, “hey, when we think about wireframes, everything is just squares, circles, and triangles”, if you really come down to it, right? And I loved that concept. I remember where it was. It was at a agile conference and we were doing a wireframing design studio, and that's what it was. So we had a bunch of developers, a bunch of agile coaches in there, and the person who was putting this on was showing people that everything was just boxes and lines, shapes that you could do every day. And I think if you break it down and start to think that way about it, it does become a lot less daunting of, “hey, I have to invent the swiping for tinder mechanism”, right? How will people not understand that instead just being like, “hey, we're going to talk about good big ideas, good placement, good layouts, things like that, that are bigger concepts than in the nitty gritty pieces”. So when you're thinking about pulling these wireframes together as well, what do you feel like are best practices to make sure people are staying at a higher level and not getting super nitty gritty into, “hey, this is exactly the text that must show up or this button has to look exactly like this?”
Ellen Chisa - 00:14:08: I like to get people on a physical whiteboard if they're in the same space. Like those whiteboard markers are not, or using Sharpies, I'll do sometimes too, but giving them something where they can't write an entire paragraph of text is like a pretty easy one to keep people thinking at a high level. And so I think that's my first go-to. And then the other one is just correcting people as they go off course. So every time we get deeper into something, like giving someone the responsibility up front to say, “hey, you're wearing the hat of making sure we stay at the high level when you hear us going down a rabbit hole”, just say, “hey, I hear us going down this rabbit hole, this is a really interesting discussion, I'm going to put it back in a parking lot so we can revisit it when we get to the right stage of the process and make sure it's not lost so the person feels like it's being addressed, but it doesn't take away from the high level conversation”.
Leon Barnard - 00:14:53: I'm a little bit biased because I work at Balsamiq, which is a dedicated wireframing only tool. And for years, we've turned away feature requests for more powerful features. And I think that is one of the dangers of UX tools becoming more and more powerful is that people start to having fun with them or you get too focused on the details and you start to lose sight of the user or the overall goal. So I think having a tool that is limited on purpose, whether it's paper and pen, whether it's whiteboard, whether it's a bare bones wireframing or diagramming tool, something that doesn't let you get too deep into the details is a key because people are going to want to finesse and fine tune things and get focused on the wrong details.
Melissa Perri - 00:15:38: When you brought up Balsamiq too, it made me think that was one of the first wireframing tools that my boss in a startup at the time gave me in 2011. So it's been out for quite a while and I know we've been using it in teaching product management or UX for a very, very long time. What have you seen happen in that space? It's been 12 years ago. 12 years, you've been looking at Balsamiq, you've been looking at the state of wireframing. What different trends have you seen out there and what has Balsamiq stayed core to?
Leon Barnard - 00:16:09: You know, it's so interesting because people on the outside don't see what happens inside of companies, but one of the things that I often tell people, which doesn't seem related at all, is the business model and the funding model and the company behind the tool. So Balsamiq is bootstrapped. We have no investors, no funding, and therefore no pressure to rapidly grow. We're 15 years old and we have 35 people, which is unheard of, and we're slow and steady growth is our mantra, and so we don't need to dominate. We don't need to capture tons of market share because the market for UX tools is growing and growing and growing. So we're happy to stay in our niche, and I think a lot of companies that get investment, obviously, and VCs are very essential for tech tools and products these days, but sometimes if there's tons of pressure to grow rapidly, it can make tools that are really, really complicated. So Balsamiq as a tool is not that different from what it was in the very beginning. We've just really been trying to optimize it and do a better job of teaching people how to wireframe and spread the message that wireframing is not just for designers.
Melissa Perri - 00:17:19: I think that's, you're absolutely right. I feel like Balsamiq did not change from when we were using it in 2011, except like little things here and there. I know some parts of it did change and I'm sure if I opened up the 2011 version now, it would look completely different. But it always, I loved the commitment to it staying towards a really like easy to use interface. Ellen, what do you want to add to?
Ellen Chisa - 00:17:42: Oh, I also remember this. I feel like I must have started using Balsamiq. And I want to say I was still in college, so maybe 2009. I used it actually in my work exercise when I got my job at Kickstarter. So shout out Balsamiq. I went into that one. But the big things I remember being added was when there were big paradigm shifts that changed what you would need to make wireframes for. Like, I remember when there started to be more elements dedicated around mobile, because there were such different interfaces. I guess, actually, Leon, I've never asked you this. But I would be curious if you have thoughts on, does wireframing change if you have an application where you're building the mobile version and the web version? Do you encourage people to do them at the same time? Do you encourage them to do it separately? I don't think you got into it in the book, but I would love to think about that a little.
Leon Barnard - 00:18:24: Yeah, the whole thing about responsive design and some of the tools today are really nice in that they allow you to design that as one thing. I think personally as a designer, I really embrace the Mobile-first design mindset and so I think that's a nice way to start. So if you start designing for mobile or in between size, it is easier to start with maybe more constraints. It really forces you to think about what needs to be there absolutely and designing a linear top to bottom way is a good way to think about, okay, the most important things should be at the top. So sometimes for new designers, that can actually be a better way to start than having this very wide canvas space that's overwhelming and thinking, oh, I can put things in all of these different quadrants or columns.
Melissa Perri - 00:19:11: It’s interesting because I feel like a couple years ago too, maybe a couple, maybe more than a couple, I feel like I'm dating myself now, but we had the whole big mobile-first push, right? Where it came out and everybody said, we're first going to design in mobile. Like we won't look at desktop. So from a, I hear you Leon from like a teaching designers how to do it, we can constrain their space. What about if you were just for the like sake of the idea, do you have a mobile first approach? Like which one do you feel like you should start with desktop or mobile or how do you decide?
Leon Barnard - 00:19:41: You know, going back to this idea of what's changed, I'd say one of the biggest changes, at least on the web and web application is the increase in design systems and pattern libraries. So what's nice is that today you have so many widgets and pre-built components for your app already. And so one of the things that we advise in the book and I've written articles about is using wireframes along with design systems. So take a look at your design system and you'll have responsive widgets in there and you'll have rules for how they adapt responsibly. And so maybe make wireframe versions of those and use them in your wireframing tool. And so you're actually working with placeholders for what the real components are like. So make something based on one of your responsive widgets and build maybe a mobile first version of it. And then you will know based on the behavior of that design system component, what happens to it when the screen gets stretched out.
Ellen Chisa - 00:20:40: I love this. I feel like one of the things I've struggled with as a product person that maybe some of Melissa's listeners have too, is when you get an executive who glazes over when you show them just a sketch and doesn't really engage with it. But I feel like if they have an idea of what the components are and they're seeing a wireframe with the sketchy version of it, but they can project out what it will be, they're probably more likely to give you good feedback in that scenario.
Melissa Perri - 00:21:03: Yeah. Leon, do you have any tips for the challenge that Ellen is talking about there for, you know, you show this to an executive and they just dismiss it or they're not really looking at it because they just see a bunch of boxes and lines and scribbles.
Leon Barnard - 00:21:15: I think if anything, I would say maybe make it more ambiguous so that they're forced to ask questions. So include some things that they're not going to understand maybe so that they can't just say, “it looks good or it doesn't look good or I don't like this color or whatever”. You know, try to think of your wireframes as a conversation starter. If you deliberately leave some details out or leave some important things out that will cause them to comment on it, or maybe give them two or three or four different options so that you can, the goal is to try to get some opinion, some engagement from them. So by leaving out details that will prompt them to say, what does this do? Or you want to increase engagement from them. So I think what you don't want is something that they're just going to give a yay or nay on. So some way to draw them in so that they can start to have a conversation with it. Or even just have an empty spot in there or have something with some question marks on it, or something like that that's really saying, “hey, I'm not here to just hand this off to you or present this to you. I'm here to have a conversation about this with you and I'm presenting my ideas to you and I want to engage with you. I want to have a conversation about this”.
Melissa Perri - 00:22:30: Facilitation is a skill I see as a fundamental difference between good and great product managers. Yet it's often overlooked. Great product managers focus on guiding clear conversations and steering stakeholders to the best outcomes. You can develop these facilitation superpowers in Voltage Control's Facilitation Certification Program. Ready to unlock your greatness? Apply today at voltagecontrol.com/product. Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great Product Manager. Use code Thinking to save $200 at checkout on our premier course, Product Management Foundations. I know one of the principles when we're doing usability testing, let's say, is to not point out all the things on the wireframe or over explain it. Is there a different way of doing it with a low fidelity wireframe? Or do you still give it to people, let them look through it? Like how do you run that session?
Leon Barnard - 00:23:48: Yeah, I would say different rules apply. I think prototypes can be good for usability testing where you've done the thinking about it, about the goals, the workflows, the product-market fit or the need for that feature. You've answered all the big picture questions and you want to do one last validation step or you want to fine tune some of the details and it should be able to stand on its own. But I think a good wireframe shouldn't necessarily be able to stand on its own or look and feel like the final product. So maybe if you're not able to be there, you include a document, a how-to guide or some comments or call-outs or sticky notes or something like that. I think pairing wireframes with words of some kind is really good, but a lot of confusion can arise if you don't include that information and you just expect it to stand on alone, the same way that Ellen was talking about working on a whiteboard. You wouldn't just draw on a whiteboard and then leave and have somebody go and look at it and say, tell me what you think.
Ellen Chisa - 00:24:45: What's up in point? A lot of my good experiences with wireframes and discussing them have been real-time collaborative. Do you think you can have a good collaboration on wireframes in an asynchronous way? I'm thinking about how many teams are now remote first or fully distributed. Do you do that? How do you do that?
Leon Barnard - 00:25:02: We at Balsamiq, we design most of our products in Balsamiq. So we rely, one of the new features, relatively new features that we've added is the ability to add comments and have multiple people working on the file at the same time. And everything is cloud-based now. So everybody can easily have access to it. You're not emailing files back and forth like you used to be able to do, or you used to have to do. So, but there's also sometimes you just need to get in a meeting together or there's these tools, loom or whatever, that allow you to do a screen recording as you go through it. So I think it's really, you have to think about collaboration. So it's the same way you would work asynchronously with anything else. You know, wireframes are visual, but they're just a picture is worth a thousand words. They're just another communication tool. Just as you might struggle to explain something in words, you want to supplement it with something. So it's a good excuse because it, or it forces you to collaborate, which I think is actually a really good thing. Whether you do it asynchronously or synchronously or in the same place or not, you know, people are getting more comfortable working that way. And so anything that forces you to make sure you're on the same page, I think is actually a good thing.
Melissa Perri - 00:26:13: There's been a lot of talk and we were touching on this a little bit about different tools hitting the market that are really good at doing high fidelity prototyping fast. We got Figma now, we've got a lot of other wireframing tools that came out too after Balsamiq, but really skewed more high fidelity while you guys stayed extremely low fidelity, which is really nice dichotomy right there. And I've heard a lot of talk lately from people in the industry saying like, “we should just jump into doing high fidelity prototypes or we should just like use those tools because it will make us faster”, right? Starting from the beginning or doing low fidelity wire frames are like useless. What do you think about that? What's your opinion on that?
Ellen Chisa - 00:26:55: I completely disagree. I guess to give you one example, I've definitely been involved in lots of projects we said, “we'll go fast, we'll go straight to code and just get it out there”. One was I was working with a designer and we were rebooting the Activity Feed Page of Kickstarter, which is basically the page that aggregates every project update. So you back something, the creator sends you updates about their creative process. And we had this idea that we wanted to make it much more visual, much more poppy. It was going to have more of a card style, which was a very popular UI element at the time. And we went through and we built an entire working prototype of it, only to learn that most updates didn't have photos. And so there were obviously the exemplar set of updates that we worked from that did have them, and it would have made for a super cool page. But what we really should have done was something much lower fidelity and just sketched them out with the actual data from, say, the most 10 recent updates in my feed or my friend's feed. And I think it would have saved us a lot of time. At the end of the day, the thing we thought would save us time by going all the way through and just building it and being ready to ship, we got to the end and we're like, oh, this isn't, we can't do this. This isn't going to work at all. And so maybe it saves you time on some projects to get to the end. But I think the expense of how many things you're going to build and then throw away will be higher than the extra stage of low fidelity.
Leon Barnard - 00:28:06: Yeah, I also obviously agree. I think they're very different. I know that when you had Jared Spool on, he talked about UX being this black box or whatever, you hand them their ideas and they come out with a solution, then developers build it. But that process is actually much longer and should be shared more. So there's the initial ideation phase where you're talking through ideas and then much closer to development, you're actually starting to think about the solution and refining it. And I think prototyping is good when you get to that point where you're getting ready to start to build. But if you think about why are the reasons that companies fail today or why products aren't successful, it's because there's not product-market fit. There's not a need for it. There's too many products that do that already. I think the key to success is about differentiation. It's about coming up with more creative novel ideas. And that's all stuff that has to happen in this ideation creative phase early on. And if you start right away with a very powerful but complex tool, you get sucked very quickly into building the thing. And when you have maybe not even thought through all of the scenarios or all the challenges, or you get too fixated on building and coding and the logic and all of that stuff, and you lose sight of who my building is for, what if we did this a different way? And you've invested too much to start over. But if you think about sketching, or I came up with this idea the other day, just because you have a pencil and a paintbrush, you don't say, “oh, well, this paintbrush is more powerful, so I'm going to start with the paintbrush”. “No, you still want to sketch out a few ideas, make sure you're on the right track, maybe get an overall layout for things”. And so both are very different ways of thinking. There are different phases in the process. They're different tools for different things. And so I don't think that one is a replacement for the other.
Ellen Chisa - 00:29:55: I think, often when people have that criticism too, they often overestimate the amount of time people are expecting them to spend in that low fidelity stage. And so if you're like, “oh, we're going to have two weeks of low fidelity and then two weeks of discussing and then two weeks of high fidelity and then two weeks, maybe that would be fast for a huge enterprise”. But for most teams, I know you want your cycle to be a lot shorter. And maybe the phase is like, oh, we all got in a room for a couple hours and drew out a bunch of things and have the debate. And so you're talking about an hour's investment, not a week's investment. And that really changes the calculus.
Melissa Perri - 00:30:27: I think maybe does it have something to do to on how big of a concept we're talking about as well? I'm sure if there's some little changes, you can just do it in code, right? But when you're talking about a new feature, a new product, something like high and conceptual, I totally understand what you're saying. We need to stop. We need to think. And we don't want to go through 18 iterations in code, have to delete it, try to figure out how to get it untangled from the rest of our code and all that stuff, even though people think, “oh, that's just going to be faster. We'll get to the end result”. So what threshold do you feel like is there for, go straight to the high fidelity or go straight to coding versus like, hey, no, actually, let's start from the low fidelity. Like, how would you measure that?
Ellen Chisa - 00:31:09: I think there's a lot of nuance here. But I would say on one side, things that you would just go and do in code, like small bug fixes, we're going to add one more thing to a menu that already exists but isn't overloaded. The types of things where an engineer would write a pull request and it would be improved by two other people pretty much immediately. Super minor tweaks, really easy to go back and change again if necessary. Not a lot of thought going in. The other side is things that are so complex, maybe entirely new product verticals, maybe completely reimagining how a product works that I don't even know if wireframing would be where you would start. You would have a whole conversation about, why are we making this big shift and invest in this company? And it's probably a board level discussion about what you're doing. And I think the sweet spot for starting with wireframe is somewhere between those. So it's adding a new large and substantial feature to an existing system, but not a completely new system. I think the new system takes a bit more. But I'm sure Leon has better opinions here, too.
Leon Barnard - 00:32:02: Yeah, I was just searching for, I wrote an article a while ago and I was thinking about trying to find the wording I used, but I think it's about ROI. And so I think that point at which you start encountering diminishing returns on the information that the audience needs to know is where you should be focusing on. So if a designer is going to be spending an hour configuring the behavior of a button or a certain widget that already exists in your design system or your code, that's not a good use of their time. They could just draw a static image or a wireframe and say, “use this design system component”. And just, it's a combination of a static picture and some words or an email and not having to build something that somebody else is just going to have to rebuild. So you shouldn't be spending more time on something when the goal is really just to communicate. You have to think about what information am I trying to communicate and who am I trying to communicate it to? If I'm communicating to a developer who knows these widgets inside and out, I don't need to tell them all the specifics of it because they know that stuff. And so a lot of times if you're just building a feature, you can even just explain it in words. Maybe if you know those design system component names or you can have simple boxes that don't look like the final thing because you can just tell the developer, “hey, use these controls”.
Melissa Perri - 00:33:22: So it's like having a common language and having an understanding of what all those things are will definitely get you there faster is what we're getting at here. Yeah. I think that's a really nice way of thinking about those different levels of thresholds there. So one of the things I really wanted to ask you about too, and maybe I'll start with you, Leon, along the same topic, there has also been talk about designers learning how to do front-end code. And I had Jason Fried on the podcast just recently, and he said that everybody at Basecamp, who is a designer, also does the front-end coding. How do you feel about that? And do you think in those cases where designers can code, should they still be doing low-fidelity prototypes, or should they be just jumping in?
Leon Barnard - 00:34:04: I'm a fan of it, especially if it's front-end code. One of my most successful projects was working with a developer using a design system. And I did wireframes for it. We had meetings about it. And then I would generate either the front-end code or the style sheets for it. And then they could hook up the back end. And so, a lot of that stuff is just on the front end is copy paste or drag and drop. And so, and what I like about it is you're using the actual code that the developers are going to use. What I don't like is if designers are spending time coding things that are not going to result in the end code that's going to go into the product. So I don't want designers learning how to use variables in Figma if those are not going to translate to the end product. But if they're writing front end code using the design system widgets or whatever, and they're copying and pasting, I think that's great. I also think I've had a really good experience understanding enough of the front end code to know what's easy, what's hard, what exists already. As a designer, I'm not designing things that are brand new when we have something already that does the same thing because consistency is really important. So I think it's really good for designers to at least have an understanding of the frameworks and the front end to better communicate with the developers and vice versa.
Ellen Chisa - 00:35:27: As a PM, there's always that fundamental question of do PMs have to be technical or not? And I think designers get that too, of should designers be able to code? I think they're analogous. And I think we really hit on it. You only have to do it so much as it helps you understand how much work things are going to be so you're making better decisions in the context of the product. And I think that's the exact right point. A designer who is thinking in code has that awareness going in and is likely going to make better upfront choices. And so there can be less of that back and forth of someone saying, “oh, this is hard. Can you cut this corner?” Or proposing a technically easy solution that doesn't work as well. I think you get a better end outcome when you both have the familiarity with the code base or at least basic parts of the code base.
Melissa Perri - 00:36:07: I totally agree with that. I'm actually teaching our designer at Product Institute some UX and he's doing some UI components for the new site we're building. And when he first showed them to our developer, he was like, there were certain parts where he was like, “oh my god, that's so hard”. Like, “no, I can't do it”. And I was like, “okay, that's fine”. We can, you know, I was able to see it and be like, “we'll just tweak this. We'll tweak that. It'll be fine”. But I think over time, you're seeing him start to understand what's hard, what's not hard. But at the beginning, especially if you're a new designer too and you don't know that much about tech and then you've got developers being like, “oh my God, that's so hard”. And you don't have somebody else there. Like he has me there. But if you don't have somebody else there, they could end up trying to redesign the whole system around what's easy, rather than around what's good design with the thought in the back of here's how we build things and this is how we're going to get it out the door. So I do like that premise of thinking of the more you understand how things are built, the better you'll understand how to apply them to good design as well. So that's a nice way, a nice diplomatic way of putting it too.
Leon Barnard - 00:37:03: I was just going to say one quick thing to add on that is that that's exactly why I think wireframes are great. Because they're visual, and you can show them to the developer, and they can immediately say, “oh, that's going to be really hard to do”. And then the designer, as a developer, can even do some wireframes and say, “this would be easier”. And so it's a common artifact, because everybody gets them right away. They don't take a lot of time to create, and anybody can make them. So that's a perfect example of how people can pass wireframes back and forth. Because if you were to describe that feature in words, everybody might think that they are looking at the same thing when they're really not.
Melissa Perri - 00:37:38: Yeah, that's a really good point. And I think it brings us back to what we were talking about earlier as well. It's not time consuming to actually do this high fidelity work in things like Figma. And even if you could code, you still have to write out that code or copy and paste those components in a certain way to do it. And I have seen a lot of designers go out and struggle and make really nice high fidelity prototypes and then show it to a developer and they go, can't do that and then you got to go back and start from scratch. So I think that drives this point home as well that it's not just about coding that is time consuming. It's actually mocking everything up even in Figma. Like Figma is easy to use, but it's still time consuming. It's not like instantaneous that you get a design out of things. So that's another win for us. Along the similar lines that we were talking about, we're talking about product managers doing some design work now. And there's been big debates about, does UX own the design or does product managers contribute to it? And I know we said throughout this podcast, everybody's heard to say, “everybody can wireframe”. How do you, as somebody who wants to contribute to the wireframing, either as a Product Manager or a developer, maybe work with a UX designer who's feeling very territorial or like, “no, this is mine. This is my solution”. Because I've seen that out there a lot. I've gotten that a lot on the Dear Melissa episodes of “hey, my designer is like, no, you're not allowed to tell me anything about the solution. You can only bring me problems to solve and then that's my job to solution it”. And then they kick the PMs out. How do you deal with that?
Ellen Chisa - 00:39:07: I feel like part of this is sometimes when teams are too siloed, like we're saying wireframes are a good collaboration point. But I like equally on the other side get designers who say, “my PM won't bring me into the early customer conversations, or I have no idea what's happening at this executive table, and like I need to know those things to do my job well”. And so I've had a fair amount of success with the give before you get. And not that I would ever not draw a sketch, like you'll draw a quick sketch and show it to someone, and hopefully that doesn't trigger anything, but being like, “oh, hey, like, do you want to come with me to this call?” And like, then it's a natural like, “oh, want to do some brainstorming together, and then you're wireframing together, and then you're really collaborating, bringing out your strengths”. I think that's one way to do it.
Leon Barnard - 00:39:46: Yeah, to build on that, I think doing work together is a great way to get buy-in. So if you have that designer sitting in on a customer call or observing something, they're going to think about when the customer said, “oh, I really hate it when this happens”, or “oh, I really wish you could do that”, or something when maybe that's not the sexiest, funnest feature, but they're thinking, “oh, this is really important”, or “I really want to help that real person”. And similarly, if the designer says, “oh, I'm really having a hard time trying to figure out a good way to do this”, and they ask the developer or the PM, man, that is a great way to get them on your side and get buy-in. If you go and ask for help to somebody outside of your role, then they're like, “hey, I helped design this, or this person wanted my help”. So I think that's a great way to start thinking about things. And then in general, just be comfortable with some uncertainty and ambiguity. So if a PM, you're going to have an idea in your head for what this feature looks like, and it's so frustrating if somebody tells you, “don't even draw that”. So I don't think that is a good way of working. Let the PM sketch that idea out, but don't then go and say, “here's what we're going to build”. Say, “here's what I'm thinking, this is the first idea I had”. Or as a PM, spend a few more minutes with that and say, “what if we did it a little differently and come up with four or five different ideas?” Then you're definitely not saying, “here's what we're going to build”. You're saying, “here are some ideas”. And then that, again, invites a conversation. It's a way to collaborate. It's a way to bounce ideas. It's a way to generate ideas together. So there's nothing wrong with sketching out your ideas. Just go into that next conversation or that handoff. With this attitude that this is something we're going to figure out together, or there's something that I know that the designer doesn't know, and vice versa. So it's about sharing information, it's about working together. One of the analogies we use in the book is that software development is a relay race. So everybody has their specialization, but if you have really fast people and they drop that baton, you lose. And so you really have to work on that time that you overlap and really practice it and ask, what do you need? What's helpful? If I give you something, finished, do you want more words? Do you want more details? What do you want more or less of? So we'll actually work on this handoff process so that you have something, so you know what the person next in line wants and expects from you and what's useful to them and what's not. So really have a conversation with them. What information can I give you that's helpful for you?
Melissa Perri - 00:42:14: I really like that way of approaching it. And I don't want anybody listening to this who has a UX designer going, “oh, she's like crapping on UX designers”. Because that's not what I'm trying to do. And I know there's a bunch of product managers who own the solutions and tell the designers to just make it pretty as well. So I've seen that side. And this has been a really fun conversation for me too, because I started as a hybrid Product Manager UX designer back in the day when nobody told me they were two separate roles. And I started mock-ups in Photoshop before Balsamiq. So I was Photoshop making it pixel perfect everywhere. And then I went to the low fidelity stuff. And then I started getting into all the different prototypes. But I also had the experience where the one company where I was a hybrid, they brought in a UX lead and was like, “hey, Melissa, she's going to do all the design work. And you can just scope out what's going to be built”. And we separated my role. And so I became pure product management. And then I UX sat over here. And she told me a lot about really good UX design. So I very much valued that. And I was like, “oh, I want to be involved”. And I wasn't involved in any of the design stuff. I wasn't allowed in it. And then I left and I went somewhere to be just the UX designers. And then none of the product managers let me be in the customer interview question. So I had to weasel my way back into those things. And nobody wanted to let me be in it. But they just wanted to dictate at me what to build into perfect pixel everything. So I've seen both sides of it over time. And I agree, the places that it's worked the best is when everybody collaborates and ideates and brainstorms these things together. And it's not like a war about this is my stuff and not your stuff. Where we can actually overlap and have those conversations. Because things get figured out faster. So I personally love wireframes. I think they're such a great tool. And I hope everybody out there is really looking at this too and not getting super swayed by all the fancy Figma stuff that's going on, which is fantastic and really useful. And it's helped me in a bunch of other ways. But I hope they turn to this too and see that wireframing is just important. And this is why we teach it to both UX designers and product managers. So I want to say thank you so much for both being on the podcast today. And if people want to learn more about the book or learn more about wireframing, where can they go?
Leon Barnard - 00:44:25: So our Balsamiq Wireframing Academy is balsamiq.com/learn. There's tons of articles and videos about how to wireframe, philosophies about wireframing interviews about wireframing, and then the book is called Wireframing for Everyone, published by A Book Apart. So you can just go to the, A Book Apart website, abookapart.com and you'll find it there.
Ellen Chisa - 00:44:45: I want to give Leon a shout out that the first printing of the book sold out, but it's, I think it's now been restocked, but that means people were liking it already.
Melissa Perri - 00:44:53: Amazing. And Ellen, where can people find more about you and connect with you?
Ellen Chisa - 00:44:57: Yeah, I would love to connect with people, especially anyone who's thinking about these concepts in terms of early stage developer tooling startups. That's really where I invest right now, although technically anything enterprise or SaaS. So you can email me at ellen@boldstart.vc or I also have a newsletter where I did write a little bit about wireframing. And so that's @ellenchisa.substack.com.
Melissa Perri - 00:45:17: And where can they follow your work, Leon, besides the book?
Leon Barnard - 00:45:19: I'm on Twitter and other social networks @LeonBarnard, my full name.
Melissa Perri - 00:45:24: And we will link to that in the show notes. Thank you both so much for being on the podcast today. And thank you for listening to The Product Thinking Podcast. We'll be back next Wednesday with another Dear Melissa. So if you have any questions for me, please go to dearmelissa.com and let me know what they are. We'll see you next time.