35. Wireframing & Prototyping (feat. Leon Barnard, Content Manager, Balsamiq)
37:11 Share

This is the Nielsen Norman Group UX Podcast. I'm Therese Fessenin. 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 Balsamiq 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 mockups, 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, how did you even get involved in this field and what brought you to being an author coauthor on this book? Yeah, it's, it's been a journey. I,

I guess the short version is that I worked as a UX designer for close to 10 years. And then after that, I joined Balsamiq, 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 design.

our customers and our audience about UX and wireframing. And when I was a designer, I really fell in love with Balsamica 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

a big fan and evangelist for wireframing. And so I lead kind of our education and content team at Balsamiq and

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 me and two of my colleagues, Billy Carlson and Michael Angelus, who are also designers by training, we all worked together on 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 an exciting process to actually work on a book and really get an opportunity to articulate and explain what we felt like were the most interesting and valuable things about wireframing. Yeah, I'm super excited. I've gotten kind of the sneak peek.

uh version sent over to me and uh everything is so fascinating about that book both because i think wireframing was something i realized i did uh 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 um

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 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 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 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 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 in its most bare kind of components. Yeah, exactly. Okay. Now the thing that often happens,

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, 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

use 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. So a prototype, for example, is really meant to be a representation of that final product to use to test it or validate it. 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. 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 or sometimes mistaken for an actual product. And then if we look at a mock-up, that's really...

It's more simple. It's kind of purely meant to be a visual example of the final product. It's not going to include functionality. And it's really there just for visual purposes. So a lot of times you'll see something that looks like a screenshot. It's got all the pixels in place and the branding, but it doesn't have any functionality. It's not interactive. Then that's a mock-up. It's kind of a static screenshot of a final looking product.

Whereas wireframes are really kind of at the opposite end in terms of fidelity or level of realism. And they're not intended to look or work like the final product. 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 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, 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 as a result. Yeah, yeah. 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 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 early on. Definitely, definitely. Now,

When I first got involved in this field, like 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. 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, because obviously there's many different ones, Photoshop, et cetera. 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.

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. 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 wireframing 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 it's had a big impact. You know, I'm with you both in, you know, both in positive and negative ways. I think in two ways, I would say, you know, positively, we finally have tools that are made for UX designers. You know, I started out

using Photoshop, which is intended for photo editing. And yeah, you can use it to make really nice looking screens, mockups basically, but it's not really good for the iterative nature of building software and it didn't have anything in there for translating those designs to code. So it's really nice that we finally have tools that are made for us and not that we're borrowing from other design disciplines.

And then another really big thing with Figma and other tools is that they're so collaborative. Being on the web, you can get other people involved. So it's a design tool, but it's also, I think, a big reason for its adoption is that so many people can work on it together. And one of the points in the book we wrote is that good design really comes about from communication and collaboration. So it's not just about what tool you're using, but it's getting the insights and opinions and

ideas from lots of different people. But 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

encourages non-designers to really participate in the process. It allows people to give feedback, but I think the bar is still a little bit, or the barrier is still there for non-designers. And I think that's just the nature of high fidelity tools.

And they also don't really encourage that early stage exploration and high level iterating. They're great for moving towards a solution once you've gotten to that point. But you want to start out with that, 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 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 Figma is getting deeper into that flow of going from design to code and introducing things like variables. So it's more powerful, but I think it isolates it a little bit more from other people who 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 Figma is used for prototyping fairly frequently, obviously.

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 sort of focusing on something that's more sketch oriented, more 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 would venture to guess, you know, if we wanted to involve non UX roles, 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-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 tool or rather that technique that we use should be one that's easy to pick up. And certainly wireframing is one of those.

Yeah, I love the words you used to describe that. And I think these days it's just so easy to get caught up in tools. But wireframing can be done on a whiteboard, and so you don't really think of that as a tool. But 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 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 too. 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, right?

in that process of being pixel perfect too early. But I'm wondering, like, I know some people might be listening to this being like, 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. Yeah.

I think it gets back to what you were saying about viewing wireframing as a technique rather than a tool. So if you ever find yourself staring at a blank page or not really sure what to build, then that's where wireframing can really help you clarify your own ideas. And 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, which is going to save you time. It's kind of like picking up a pencil before a paintbrush. 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 that's really going to get those creative juices flowing and get you started without having too many options available.

I love that metaphor of the pencil versus the paintbrush, right? Yeah, because 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 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 mockups. Sounds like the best time may be.

early in the process is the best time for wireframing? How early would you say? Yeah. Well, earlier I mentioned getting more, say, non-designers involved in the process, because if we look at design as really just trying to get your idea for the product down 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

You don't have to wait until it gets to technically, officially the design phase to start designing or start wireframing. So in the book, we talk about three different phases of wireframing, but they all occur kind of from the beginning to maybe the late middle of the process. So I would say anywhere between kind of requirements gathering and the time that coding would start.

So, yeah, you know, you want to do it early on when, you know, you feel OK exploring ideas, you know, before you really have solidified, you know, what you're going to build. Got it. OK, 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 we're going to wait until the precise ideation step. Like what I'm kind of envisioning in my head right now is the design thinking framework.

framework and how there's obviously different steps in that process, like we emphasize, define, ideate, prototype, test and implement phases. And now we have it as like a cycle. So obviously this is something you're doing, 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 if you think of wireframes that way, then they're just kind of a way to communicate more effectively if you're talking about a software product. I appreciate that too, because 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 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 I love this idea of kind of mixing and matching wireframes and

and words and other techniques because you want to communicate, like you said, most effectively. So you don't need a prototype to communicate a UI idea, but it may be a more effective way to communicate than a page of text. You mentioned earlier how it can be really effective as a way to communicate. And I think you mentioned 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.

Well, I like the idea of, like you said, democratizing design and having kind of a shared ownership. So, 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 artifacts so much, but really just more part of the process. They're not something that ships to the customer, you know, so they're just a way to either clarify your own ideas or to communicate them. So

I think they work really well as kind of in-between or handoff artifacts where you're talking to, say, the person next 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 and not getting so much into this mindset of like who owns the design, because I think it

everybody should own some amount of the design. Yeah, that's a really good point. And I think also kind of goes back to what you were saying earlier about

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.

And I mean, we have full day classes dedicated to like managing the relationships there. 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, it's not so much something that's exclusive to this community.

discipline of UX, although it probably is something very common, right? Yeah, you know, 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 be seen more like that. You know, it's a technique for developing, fleshing out, communicating your ideas. And that's something that everybody can do. Yeah, absolutely. 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 one hand, which is that we feel, again, 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 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 end user can be a positive. 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.

What are your thoughts? Like, what do you think? Do you, maybe that's a loaded question. Well, yeah, I'm just going to answer by saying it depends. I think it depends mostly on the relationship you have with your users or your customers, because I think wireframes, they don't work as well without context. So, 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 testing where you're timing things and gathering 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 the design, be flexible with the format, ask them open-ended questions, kind of like explain to them more, tell them a little bit more of the story.

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. 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, recode our prototype or something. So don't go too far 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, um, that is a way to kind of prevent yourself from going too far down a rabbit hole, but yeah,

I think it doesn't have to be quantitative, right? In fact, maybe it's better that it's not. And part of it is right. When we think about quantitative versus qualitative techniques, right? Quantitative is,

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. 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? Versus, hey, let's just get a few people to talk to us about what they think, what kind of

activities are 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 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,

I think people just don't know about them. So what advice could you give to designers who are looking to start incorporating this step as a way to improve their end results ultimately? How can they justify that to say their supervisors or team members? Yeah, it's kind of a paradigm shift. So I think that's the hardest part is thinking about them differently and

And I would say, maybe don't even think about them as part of the design process then. 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. You know, they're, they're going to save you time if you

if they help you figure out what to build. And 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. 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 and clarify and understand your own ideas because sometimes you don't know what you don't know. Yeah, right, right. And I think that reminder is helpful as 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, OK, 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 sort of frames it as something different, right? Because 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 is like, that's not a design, right? They interpret it as what happened. Where is our usual high fidelity or like, where's our usual beautiful design?

concept art, essentially. 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 explore and iterate and, you know, get feedback and do some thinking.

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 out of their wireframing practice? Because I feel like it's easy to say, oh yeah, just sketch concepts. But 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. It's not just really a simplified prototyping tool or step. So don't think about the UI 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 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 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. And so in our book, we have a lot of tips about how to kind of get that out. And so I think it's don't just think, oh, I'm building you a user interface, but think I'm just exploring ideas and stay really, really high level 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, or 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 getting into that mindset of usability and user experience and

you know, what are the things that frustrate users and, you know, 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 Balsamiq website, we have a whole Balsamiq Academy, which is all about learning about wireframing and, and kind of this, this mindset, um, that balsamiq.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 resources as well at NNG that we'll also link to. 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. I'm really excited for you and excited to see how many people it helps. 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?

I am my full name, Leon Barnard on Twitter, X, whatever you call it. And I think on LinkedIn, I post maybe a little bit more on LinkedIn these days about these sorts of things. So that would be 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 dot 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 Laramore Production Company. That's it for today's show. Until next time, remember, keep it simple.