This is the Nielsen Norman Group UX Podcast.
I'm Therese Fessenden. When it comes to designing interfaces, prototyping tools are more powerful
than they've ever been before. Some even have integrations with well-known AI models and can
enable designers to produce high-fidelity prototypes faster than ever before. All good things, right?
So it might seem a little strange that given the state of prototyping tools today, we're
here sharing an episode about wireframing. But despite claims that wireframing may be obsolete,
it may actually be the missing link that helps designers unlock a level of creativity
otherwise inaccessible when focusing on making prototypes pixel perfect. Today, we're featuring
a conversation I had with Leon Barnard. He's a content manager at Balsamic and co-author
of the book, Wireframing for Everyone. In this episode, we talk about what wireframes are
and how they're different from prototypes or mock-ups, when in the design process they can
be especially useful, and how to get team members and stakeholders interested in using them, even
when you're being pressured to make more polished designs. It's a pretty good episode I'm excited
to share. So with that, here's Leon. I certainly know a bit about you because you've done
some talks with us in the past, but I would love for you to share a little bit about how you
got here. So how did you even get involved in this field and what brought you to being an author,
co-author on this book? Yeah, it's been a journey. I guess the short version is that I worked as a UX
designer for close to 10 years. And then after that, I joined Balsamic, which makes a well-known
wireframing tool, but I didn't join as a designer. I joined as someone, kind of an in-house UX expert
to help kind of evangelize UX within the organization and then also teach our customers and our audience
about UX and wireframing. And I really, when I was a designer, I really fell in love with Balsamic,
the product, and also just wireframing in general. I found that it was a really good way to communicate
and it was just really effective in my work as far as actually getting my design work implemented and
actually getting products built. And so I became kind of a big fan and evangelist for wireframing.
And so I lead kind of our education and content team at Balsamic. And, you know, for a couple of
years, we've been talking about, oh, we should write a book someday. And then we finally just were like,
yeah, let's do it. And so we, me and my, two of my colleagues, Billy Carlson and Michelangeles,
who are also designers by training. We all work together on this, this pitch. We sent it to a
book apart, which is a publisher that we really like and respect. And they said, yeah, so they
helped us with editing it. And it's really everything we know about wireframing kind of
condensed into a fairly short guide. And yeah, it was, it was an exciting process to actually work on a
book and really get an opportunity to articulate and explain what we felt like were most, the most,
you know, interesting and valuable things about wireframing.
Yeah, I'm super excited. I've gotten kind of the sneak peek version sent over to me and
everything is so fascinating about that book, both because I think wireframing was something I realized
I did when I was first getting involved in the field, but I didn't know there was a word for it.
And then to have a word for it and not only know that there is a word for it, but also that it's
a practice that can actually be really beneficial to do and not just something I just felt like
sketching, right? That's, that's just really validating, I guess, is the best way to put it.
Now, I guess on that topic, since obviously I didn't know there was a word for wireframing,
could you share a little bit, just what is a wireframe to establish some like basic terminology?
Yeah, I think that's a good place to start because there's so much terminology in our industry and
outside of our industry. I would summarize it as a wireframe is really just a sketch or,
or maybe a schematic of a user interface. So, you know, if we look at the word itself,
it comes from the world of 3D designs where you would actually use wires and kind of construct a,
kind of a frame for a physical object. And so in the, in the 2D, two dimensional world,
it's kind of the same idea. It's also, it's kind of like a blueprint that an architect would make,
you know, which shows kind of the structure and the layout and has some labels and some annotations
on it, but it's not going to show you the house color, you know, and nobody's going to mistake it
for, you know, a model of the final thing. It's clearly intended to communicate some basic
information about it, but it's not a full scale model. And so it's, it's really just a way of
sketching user interfaces.
That's helpful. I think it's helpful to think of it too. And that type of perspective,
like literally this is a set of wires that people would use in the past to create these like
three dimensional shapes. But like you were saying, can be very clearly distinguished as
like, this is by no means the final outcome, but it's conceptually what we're thinking about and
how we might start to visualize something, uh, in its most bare kind of components. Um,
yeah, exactly. Okay. Now the thing that often crosses our minds, I think is when is the best time to do
these? And at the same time, I feel like there's also conflicting terms, which can further confound
that question. So before I get into that question, which is when to do these, um, what would you say
would be the difference between a wireframe versus a prototype versus a mock-up? Because I feel like
those terms do tend to get kind of used synonymously when I don't necessarily think they're going to lead to
the same outcomes or goals. What are your thoughts on these? Yeah, that's a really good way to put it.
There is some overlap, but they're actually really quite different. Um, so a prototype, for example,
is really meant to be a representation of that final product, you know, to, to use, to test it or
validate it, you know, and that's, it's really created usually in the second half of the design
process. Once you kind of already know what you're going to build, you know, so it will contain a lot of
the elements, like the structure, the visual appearance, and sometimes even functionality,
so much so that it can be substituted for the real product, you know, or sometimes mistaken for an
actual product. Um, and then if we look at a mock-up, that's really, it's, it's more simple. It's kind of
purely meant to be a visual rep, you know, visual example of the final product. It's not going to
include functionality. Um, and it's really there just for visual purposes. So a lot of times you'll see
something that looks like a screenshot, you know, it's got all the, all the pixels in place and the
branding, but it doesn't have any functionality. It's not interactive. Um, then that's a mock-up.
It's kind of a static screenshot of a final looking product. Um, whereas wireframes are really kind of
at the opposite end in terms of fidelity or level of realism. Um, and they're not intended to look
or work like the final product. Um, they're intended more for coming up with and exploring
solutions. So they're kind of like a prototype without the functional and the visual layers,
but the advantage to that is that they're really fast and easy to create and, you know, throw away
even if you need to. Yeah. And I appreciate that sentiment as well, is that they're like,
we haven't invested that much time into them. So if there is something we sketch and we're looking
at it, like, Ooh, maybe we realize that what we've created, maybe it was nice in our heads,
but now that we're looking at this on paper and maybe starting to envision the flow of activity,
we quickly realize, okay, maybe we should change course of it. So in a way it kind of allows for
that failure a little bit earlier and not in a bad way, like good kind of failure where you're
learning something meaningful and, and not having too much rework to do, uh, as a result.
Yeah. Yeah. And I mean, if anybody's ever gone down the path of getting to code and building
something and developing something, and then finding out that they missed something, you know,
you know how much work it is to redo once you've actually started coding. So if you're going to make
a mistake or be wrong about something you want to find out, uh, early on.
Definitely. Definitely. Now, when I first got involved in this field, like I, I was lucky that
I sort of joined around the time that sketch was in its infancy. And obviously there's like
no shortage of tools available. Um, but in particular, like Adobe creative suite was sort of
the, the kind of pinnacle of visual creation software to kind of just bucket all of the different
tools. Cause obviously there's many different ones, Photoshop, et cetera. Um, and I think that
barrier to visual design was a lot higher back in the day and even higher for things like
prototype building, interactive prototype building. Um, now with sketch, like I said, I was lucky in
that that barrier was a bit lowered with sketch. It was a bit easier to learn. And with Figma, it's
probably the lowest it's ever been. Um, now Figma, I have good feelings. I have lots of great
things to say. I've also got some other things to say, but before I get into any of that, how do
you think Figma has impacted wire framing and prototyping? And certainly, I guess you can lump
sketch in there too, but I think Figma is the more popular one at the moment.
Yeah. Yeah. I think, um, it's had a big impact. You know, I I'm with you both in, you know, both
in positive and negative ways. Um, I think in two ways I would say, you know, positively, we finally
have tools that are made for UX designers. Um, you know, I started out, uh, using Photoshop,
you know, which is intended for photo editing, you know, and, and yeah, you can use it to make
really nice looking screens, you know, mock-ups basically, but it's not really good for the,
the iterative nature of building software. And it didn't have any, anything in there for
translating those designs to code, you know? So it's really nice that we finally have tools that are,
that are made for us and not that we're borrowing from other design disciplines. Um, and then
another really big thing with Figma and other tools is that they're so collaborative, you know,
being on the web, you can get other people involved, you know, so it's, so it's a design
tool, but it's also, I think a big reason for its, you know, adoption is that so many people can
work on it together. And, you know, one of the points in the book we wrote is that, you know,
good design really comes about from, you know, communication and collaboration. So it's not just about
what tool you're using, but it's getting the insights and opinions and, um, ideas from,
from lots of different people. Um, but I, I also think that a tool like Figma is kind of too focused
on UX designers. So yes, it's collaborative, but I don't think it really, uh, encourages non-designers
to really participate in the process. You know, it allows people to, to give feedback. Um, but it's,
uh, you know, I think the bar is still a little bit, you know, or the barrier is still there for
non-designers. Um, and I think that's just the nature of high fidelity tools. Um, and they also
don't really encourage that early stage exploration and high level iterating. Um, you know, they're great
for moving towards a solution once you've gotten to that point. Um, but you know, you want to start
out with that, you know, if you follow a double diamond or a single diamond where you have kind of a
divergent stage in the beginning where you want to just generate lots and lots of ideas.
And I think that's what wireframes and, you know, even specifically wireframing tools are really good
at. They make it really easy for anybody to kind of go in and just get their ideas down and say,
this is what I'm thinking and kind of branch out and explore different variations. And I think that's
really where a lot of innovation and creativity comes is in those early phases when you haven't yet
decided on what that solution is. So I think that's kind of one of the downsides of these
really powerful tools. And, you know, Figma is getting deeper into that flow of going from design
to code and introducing things like variables and, um, you know, it's, so it's more powerful,
but I think it, it isolates it a little bit more from other people, uh, who, you know, should be
involved in the process. Yeah. I think that's a really, really important point. And I'm glad you brought
that up because I mean, Figma is used for our, for prototyping fairly frequently, obviously. Um,
and actually it's come up more frequently recently with like kind of the sub tools within Figma,
like FigJam, which has, you know, whiteboarding capabilities. And I think FigJam is great in
general, because again, we're, we're sort of focusing on something that's more sketch oriented,
more, um, low, low visual fidelity, right. Where it's more about the idea and the concept
versus something being pixel perfect and ready to ship. And I think on the one hand, that is a good
thing, but can everyone use FigJam? I, I would venture to guess, you know, if we wanted to involve
non UX roles, uh, such as, you know, maybe we're trying to ideate on improving something that is
frequently complained about with customer support reps. Well, maybe we can bring the customer support
reps to this ideation session and will they be able to participate in FigJam? You know, maybe,
but the likelihood that it might be a bit more of a barrier to that, you know, sort of ideation and
that contribution or co co-creation, I guess is the right word. Then, you know, that might be a risk
as well. So I appreciate that you said that because on the one hand, this movement toward democratizing
design, right. Maybe not just democratizing the whole design process, but even parts of it where
we can start to empower other people to bring their ideas to the table. Yeah. That, that tool or rather
that technique that we use should be one that's easy to pick up. And certainly wireframing is one of
those. Um, yeah, you, I love the words you use to describe that. And, and I think, you know, these days
it's just so easy to get caught up in, in tools. Um, but you know, I mean, why wireframing can be done
on a whiteboard, you know? And so you don't really think of that as a tool, but, um, you know, I'd
rather have a group of people wireframe on a whiteboard than try to get into a high fidelity tool just
because there's, you know, there's zero barrier to entry for that. Yeah. Yeah. So I guess related to
that, like, obviously with these tools, I think there's a temptation a bit to, and I can't blame
designers, newer designers, because I probably would be tempted to, if I was using Figma to make
something really polished and really, you know, wow worthy where it's like, I can make this look
almost ready to ship. If I just put a few hours into this and on the one hand, that's great. But on
the other hand, if we're, you know, what you were saying earlier about the power of these wireframes is
that they can allow us to fail quickly and, you know, discover early on whether or not we should
change a design, right? In a way we're kind of removing that flexibility, um, in that process
of, of being pixel perfect too early. Um, but I'm, I'm wondering, like, I know some people might be
listening to this being like, Oh, do I really need to like do this formality? Do I really need to do
this step? Like, what would you say to folks who are, you know, in that sort of skeptic, like, I don't
know if wireframes are still relevant. Um, I think it gets back to what you were saying about
viewing wireframing as a, as a technique rather than, than a tool. So if you ever find yourself
staring at a black page, a blank page, or not really sure what to build, then, you know, that's
where wireframing can really help you clarify your own ideas. Um, and it, it kind of makes it easier to,
yeah, like you said, fail and explore and experiment. So if you're getting stuck, it's a
great way to get unstuck, uh, which is going to save you time. You know, it's kind of like
picking up a pencil before a paintbrush, you know, you just kind of want to sketch something out,
get into the flow, get that idea out of your head onto the page without feeling like it has to be
perfect. So, you know, that's really going to get those creative juices flowing and get you started,
um, without feeling like, you know, without having too many options available.
I love that metaphor of the, the pencil versus the paintbrush, right? Yeah. Cause on the one is
a bit more permanent, not to say you can't change things with a paintbrush, but like
the pencil gives you so much freedom. And I think there's something liberating about that as well.
And, um, and not just, so it's not just about failing, but also just the liberation of, Hey,
we have a lot of things to explore. Let's, let's explore more ideas in the same amount of time.
It might take us to make something really pretty with just one, right? So I think that's a really
important takeaway too. Yeah. Now when it comes to, you know, when in the process, so to revisit the
question I was sort of chewing on when thinking about wireframes versus prototypes versus mock-ups,
sounds like the best time may be early in the process is the best time for wireframing. Um,
how early would you say? Yeah. Um, well earlier I mentioned, you know, getting more say non-designers
involved in the process, because if we look at design is really just trying to get your idea for
the product down, you know, onto the, onto the page. That's something that can start with a product
manager or the person who's really working on the requirements. And so I think, um, you know,
they, you don't have to wait until it gets to the technically, you know, officially the design phase
to start designing or start wireframing. So, um, in the book, we talk about three different phases of
wireframing, um, but they all occur kind of from the beginning to maybe the, the late middle of the
process. So I would say, you know, anywhere between kind of requirements gathering and the time that
coding would, would start. Um, so yeah, you, you know, you want to do it early on when, um, you
know, you feel okay exploring ideas, you know, before you really have solidified, you know, what
you're going to build. Got it. Okay. So yeah, in a way there's some malleability or there's some
flexibility as far as when you can incorporate this. It's, it's not just, uh, we're going to wait
until the precise ideation step. Like what, what I'm kind of envisioning in my head right now is the,
um, design thinking framework and how there's obviously different steps in that process,
like the emphasize, define, ideate, prototype, test, and, um, implement phases. Um, and now we
have it as like a cycle. So obviously this is something you're doing, uh, you know, in regular
intervals, but at the same time, right, there could be perhaps some wireframing just conceptually
to build a hypothesis to say, Hey, we have this hypothesis, but we don't even know if
this is something people want. Right. And so in a way we can use wireframing that early,
or we can also wait, maybe we have a hypothesis, but we don't have a visual to a company, right?
We can, we can also use it in the ideation stage or like right before prototyping perhaps.
Yeah. And they're also just really good for communicating an idea. So if you ever find yourself
trying to describe a user interface solution or writing up a big document that details it,
you know, it's just like, just give it a, give them a picture, you know, do a rough wireframe
sketch and maybe include some words in it. You don't have to think of it strictly. Like I'm in
the design phase. Like it's just, sometimes it's a more efficient way of communicating is just to draw
something. And so, um, if you think of wireframes that way, you know, then they're just kind of a way
to communicate more effectively if you're talking about a software product.
I appreciate that too. Cause I've, I know I've been guilty of saying I have this idea.
I write five paragraphs. Is someone going to read all five paragraphs? Maybe, but, but if I have a
visual, like a really compelling visual that can kind of summarize that or even better, maybe I just,
if I, if I do write anything, it's the takeaways, but I now have some visual that kind of takes that
point, uh, and makes it for me, that's going to be a really powerful communication tool and not
only lead to, you know, more visually impressive, you know, communications. I mean, that's a nice
bonus. Certainly not the main intent, right? The main intent is I'm communicating more clearly and
that's essential, right? Yeah. Yeah. And, and I love this idea of kind of mixing and matching
wireframes and, and words and other, you know, techniques because you want to communicate. Yeah.
Like you said, most effectively. So you don't need a prototype to communicate a UI idea, you know,
and you, it may be, but it may be a more effective way to communicate than, than yeah, like a page of
text. Right. You mentioned earlier how it can be really effective as a way to communicate. Um,
and I think you mentioned like product managers, but I'm wondering, is there someone who should be
responsible for making these or collaborating on them? What do you think?
Mm-hmm. Um, well, I liked the idea of, like you said, democratizing design and having kind of a,
a shared ownership. So, um, you know, I don't think necessarily that I think each role has something
that they're responsible for, but I don't think it should be tied so much to the tool, you know? So I
think a PM, they should be responsible for kind of understanding and clarifying the problem.
And then the designers, they're kind of taking that problem and coming up with potential solutions
and then validating them. And the developers are kind of building it, but each of those roles can
use wireframes or other design techniques in their own way. So I don't think wireframes should be seen
as, as artifacts so much, but really just more part of the process. They're not something that
ships to the customer, you know? So there's just a way to either clarify your own ideas or, or to
communicate them. So, um, I think they, they work really well as kind of in between or, or handoff
artifacts where you're talking to say the person next in, in the line. So a PM talking to the designer
and say, here's what I'm thinking, what do you think? And you can kind of have a conversation
around them. And so it's really, I think the conversations that come out of them that are
the most meaningful, um, and not getting so much into this mindset of like who owns
the design, because I think everybody should own some amount of the design.
Yeah, that's a really good point. And, and I think also kind of goes back to what you were saying
earlier about, um, about wireframes being a communication tool, right? To kind of see it
not so much as a design artifact, but more so as a way that we can speak to each other.
And I think that kind of lowers the tension perhaps, because I do know that there can be,
there can be some butting of heads around this product doing this, or is researcher design doing
this, is UX doing this. Um, and I mean, I, we have full day classes dedicated to like managing the
relationships there. But, but I think if we view it more as a communication device, then it's not like,
you know, it's not like, Oh, who's in charge of writing memos or who's in charge of writing
reports? Like everyone is. It's not so much something that's exclusive to this, uh, particular
discipline of UX, although it probably is something very common, right?
Yeah. You know, you, you described it earlier as a technique, and I think that's a great way to
think about it more as a technique than a tool. So if you think about like brainstorming, like that's
a technique, you know, but it's not associated with a specific tool. So it's seen more easily as
something that doesn't belong to any particular role. And I think wireframing should see, be seen
more like that. You know, it's a, it's a technique for developing, fleshing out, communicating your
ideas. Um, and that's something that everybody can do. Yeah, absolutely. Um, and actually one thing you
mentioned earlier is that, you know, most of the time users don't see these like end users aren't
going to see them. And I think there's a positive to that on, on one hand, which is that we feel
again, to, to use the word liberated, right? We don't feel this pressure of it must look perfect
because the user's going to see this and it's going to represent us as a brand, right? This is
just, this is just a concept. This is just us kind of, you know, going back and forth and working
together to maybe mold it into something else. And, and maybe the lack of pressure to show it to an
user can be a positive. Um, on the other hand, I can also see to play devil's advocate. I can also
see an alternate philosophy where maybe wireframes can be helpful for communicating something that
doesn't exist yet, but maybe we're trying to validate whether this is something that people
would be interested in as a concept, right? Even before we've done prototyping. Um, what are your
thoughts? Like, what do you think? Do you, maybe that's a loaded question.
Well, I, yeah, I mean, just going to answer by saying it depends. Um, I think it depends
mostly on the relationship you have with your users or your customers, because I think wireframes,
they, they, they, they don't work as well without context. So, um, you know, so they work really
well if you're going to show them to users where you're more in a qualitative mindset, you're not
doing user, you know, testing where you're timing things and gathering, you know, hard data, but it's
great where you have kind of an informal relationship or an informal setting where you can kind of talk
through as a design, um, be flexible with the format, you know, ask them open-ended questions,
kind of like explain to them more, tell them a little bit more of the story. Um, you know, and
some organizations, even they like to involve users in the design. I think it's called like
collaborative design or something. So I think wireframes are great with that and you can even
help them feel involved in the design process. Um, but regardless, I think it's important to allow
enough time for changes if you're going to show designs to users. So if you show wireframes,
it's great because you're very early on. Sometimes if you have a really polished prototype that you
spend a lot of time on, like you kind of secretly just want them to sign off on it so you can ship
it, you know, and sometimes it's too late in the process. And then maybe there, you get a lot of
feedback that shows that you kind of missed something big and you're like, oh man, now we got to go,
you know, or recode our prototype or something. So don't go too far, uh, into showing something
that's nearly done with the assumption that everything is, is good, you know? So you want
to always be open to, to suggestions and feedback from users. Yeah. I appreciate that you said that
about this being like a qualitative task, um, that is a way to kind of, you know, prevent yourself from
going too far down a rabbit hole, but I think it doesn't have to be quantitative, right? In fact,
maybe it's better that it's not. Um, and part of it is right. When we think about quantitative
versus qualitative techniques, right? Quantitative research would be something like an AB test where
we're going to see, does this one perform better or this one and which one has lower time on task?
Like at this stage, it wouldn't make sense budget wise, I think. Um, especially because again,
the way we tend to use wireframes is to look at many different ideas and it may not be cost effective
to look at 15 different concepts, right? But if we were to use it as just a quick qualitative method
to figure out, okay, maybe content wise, does this make sense? Or are there perhaps things that users
are looking for that also kind of lowers the stress of, oh, do we need to recruit a hundred people to
look at this sketch? Essentially what is a marker sketch, right? Um, versus, Hey, let's just get a few
people to talk to us about what they think, what kind of, um, activities they're going to do. Is this
going to help them? And I think that kind of conversation, framing it more as like a conversation
almost can be, uh, particularly helpful. Yeah. Yeah, for sure. Yeah. Now I guess one other question
I have is lots of teams are probably accustomed to producing really high fidelity screens on demand
very quickly. And it's not because, you know, wireframing is inherently, you know, boring. I
think people just don't know about them. Um, so what advice could you give to designers who are looking
to start incorporating this step as a way to, you know, improve their, their end results, ultimately,
how can they like justify that to, to say their, their supervisors or, or team members?
Yeah, it's, it's kind of a paradigm shift. So I think that's the, that's the hardest part is, is thinking
about them differently. Um, and I would say, you know, maybe don't even think about them as part of the
design process then, you know, I mean, just the way that you don't necessarily, you know, if you're
just sketching something on paper, you're not thinking, oh, I can't do this. I need to be doing
this in my high fidelity tool, you know? So think about them as a way to kind of like clarify things
in your head, you know, think of them as part of the process of understanding and the kind of the,
the pre-design, the pre-work that you do before you, you know, dive into high fidelity. Um, you know,
they're, they're going to save you time if you, if they help you figure out what to build. Um,
and that, that's really, you know, where you want to, that's where a lot of the time comes in is
spending time building the thing. Um, but if you don't know what you're building, then you don't
want to go, you know, too far down that route. So it's just a way for you to kind of like explore it
and, and yeah, clarify and understand your own ideas. Cause sometimes you don't know what you don't
know. Yeah. Right. Right. And I think that reminder is helpful as this isn't, this isn't an
artifact, right? This is, this is just a communication technique. Right. And, and I think
in doing so, even in your, you know, in your communication, like, let's just say someone's
like, all right, we're going to make the design now. And we haven't done wireframes yet. Right.
Even just saying, okay, before we start on the design, right. Even like, even the mental model
of separating it, just before we do that, I wanted to check, like, here's some ideas I have,
right. That, that sort of frames it as something different. Right. Cause I think one of the
challenges is if we frame it as we're starting on the design and then we send this and then
a stakeholder or executive looks at this as like, that's not a design, right. They interpret it as
what happened. Where's our usual high fidelity or like, where's our usual beautiful,
um, concept art essentially. Uh, so I think to be able to frame it more as
I'm communicating an idea to you, I think that certainly really helps with them being accepted
a bit more readily. Yeah. And if you say, you know, we really want to be innovative and we want to be
creative. And so we need a little bit of time to, to explore, um, and, and iterate and, you know,
get feedback and do some, do some thinking, uh, before we just go straight into building.
Absolutely. Well, for those who are, or who have been doing wireframing for a while,
could you share any tips for how to get the most like out of their wireframing practice? Cause I
feel like it's easy to say, Oh yeah, just sketch concepts. But like, if you could give a tip to be
like, this is what's going to make your wireframe a lot more useful for you. What would that tip be?
Yeah. I would say, you know, think about it as a separate part of the process. Uh, it's not just
really a simplified prototyping, uh, tool or step. Um, so don't think about the UI, uh, right away.
You know, you can even start by putting just some words down on the page or some kind of thoughts or
just basic shapes, you know, start at the, the, the highest level, the most zoomed out so that you
can really try to focus on what, you know, keep in mind the user's problem and really focus on the
problem more than the solution. You know, you're not trying to design something final right away.
I know it's, it's hard because you want to get something. It's kind of uncomfortable when you're in
that in between uncomfortable phase, you know, but you have to kind of linger in that uncertainty that,
you know, out of your comfort zone area to explore, because I think that's where some of the best ideas
come out is when you're really pushing into the unknown a little bit. Um, and so in, in our book,
we have a lot of tips about how to kind of get that out. Um, and so I think it's, don't just think,
oh, I'm, I'm building you a user interface, but think I'm just exploring ideas and stay really,
really high level. Um, and just kind of sit in that space for just a little bit longer than you
might ordinarily. Absolutely. And then, so that's, that would be a great tip, I think for anybody,
whether you're experienced doing wireframing or whether you are brand new, but I guess for those
who are like super brand new to this, I'm like, I, this is the first day I've heard anything about
wireframing. What resources could you point some of these folks to? Uh, well, that's really what we
wrote, wrote our book for. So I would give a plug for our book wireframing for everyone. Um,
and then another book, I would say, you know, go with something like, don't make me think,
you know, another book for non-designers, which is really focused on, um, getting into that mindset
of usability and user experience. And, you know, what are the things that frustrate users and, you know,
it's, it's having too many steps or things that don't make sense. You know, it's not that visual
layer. It's, you know, it's the lack of kind of deliberate thought about solving a real problem.
And so, you know, these, these kind of non-design, these books for non-designers that
get you into that right mindset, I think are really helpful. Um, but also on the Balsamic website,
we have a whole Balsamic Academy, which is all about learning about wireframing and, and kind of this,
this mindset, um, that balsamic.com slash learn. And we've got articles, courses,
interviews, um, and all kinds of stuff, um, you know, to supplement the material in the book.
Absolutely. Well, we'll definitely include those links. And of course, the link to your book
in the show notes, um, and any other links that we, you know, we obviously have some, uh, resources
as well at NNG that we'll also link to. Um, but Leon, thank you so much for taking the time to share
the adventure that you've taken to basically create this amazing resource for the community.
Um, I'm really excited for you and excited to see how many people it helps. Um, and otherwise,
I guess if people wanted to follow you personally and your work, is there any social media handle
or website you'd point people to? Uh, I am my full name, Leon Barnard on, on Twitter, X,
whatever you call it. And I think on, on LinkedIn, um, I post, uh, maybe a little bit more on LinkedIn
these days, um, about these sorts of things. So that would be a good, a good place to start.
All right. Well, thank you again. I appreciate your time and hope you have a great rest of your day.
That was Leon Barnard. Check the show notes for links to anything we've referenced so far, but
remember that we have thousands of articles, videos, and reports on our website about UX design,
research, strategy, and even UX careers. That website is www.nngroup.com. That's N-N-G-R-O-U-P.com.
And if you enjoyed this show in particular, please follow or subscribe on your podcast platform of
choice. This show is hosted and produced by me, Therese Fessenden. All video editing and post-production
is by the Larimore production company. That's it for today's show until next time. Remember, keep it simple.