Jordan Hudgens: The first time I heard "low fidelity wireframe" I had no idea what that was. Give us a high-level description of what they are and why you would choose to make one instead of something more detailed.

Jesse Cook: Again, this is a "dealer's choice" kind of thing. Different designers and creative directors might just say "wireframe", but I like breaking it up into both low and high fidelity wireframes. The reason is that with a low fidelity wireframe you are strictly focusing on the user experience. It's very easy to get carried away and start to design things. You're excited, so you're putting all these objects on there, but the main objective of building low fidelity wireframes is that you know all of the objects that need to exist on every page. It doesn't necessarily matter how big the button is, you just need to know that the button needs to be there.

So the idea with the low fidelity wireframe is to not be thinking of the user interface at all. I mean, maybe 5-10% percent, and saying "I'm going to make a square to mean a button," but that's the extent of it. The important part is that you're actually saying, "For these actions to happen, what objects need to exist?" That may include my nav bar, or some buttons, or a profile picture that's just represented with a circle or something. It's very very low fidelity.

This approach forces you to identify the holes. It helps you figure out things that you hadn't realized while building the sitemap. You might think you've got everything answered once you're done with the sitemap, and then find that a little more context helps you find some more problems.

JH: Absolutely. For anyone that's gone through our UML or Problem Solving course, there are some pretty big areas of overlap here. For example, in the UML specification, it's actually a requirement that you start with your most high-level, generic things first. And that's for the practical reason. You may end up wasting a lot of time if you get too detailed over how a button looks, because you may find out later on that you don't even need the button at all.

JH: I remember the very first time I was ever sent a low fidelity wireframe. I was surprised because I usually was getting more detailed mockups, like Photoshop screens. They sent me this wireframe and it looked really ugly.

JC: Oh yeah.

JH: But that's good! That's the way it's supposed to be. Like you mentioned, you don't care about user interface at this point.

JC: Right.

JH: You're just trying to get one step closer to the goal line and make sure that, when you finally hand it off to the developer, they know exactly what they need to build.

JC: Exactly. And it allows some of the backend tasks to get started while you're doing the high fidelity mockups. Getting that high fidelity design finished can take some time, especially when you're working with the client. They can get really picky at that point, so that process can go a little bit slower. But if you have these low fidelity wireframes, the backend developers can get started because they know the objects that need to exist. They know the data that needs to be there. They don't care how it looks, but they have something that they can start with to build out the app while you're working on other parts of it.

And, really, I can't emphasize this enough: the low fidelity wireframe is so important because it forces you to focus on the user experience. Even something as simple as Tinder; there are a lot of user interface pieces to it, but let's take the single user experience concept of "what's the best way for me to cycle through profiles?" That gesture kicked off a whole slew of apps using that exact same gesture. It wasn't necessarily a user interface decision. It was saying, "I'm on this screen and I need to take some sort of action. I don't want to use a button, so I'm going to use a gesture."

This wireframing process forces you to think through those specific things and say, "Man, there's a lot of stuff on this page, this is really complicated." or, "Wait a second, how do I know what number to put in here if I haven't pulled this data from this other screen?" It's forcing you to think through that page-by-page user flow. At this point, you'd be wasting your time designing buttons and making everything balance properly, only to discover that you need 10 more objects on the page. That's going to affect everything, and that five hours of design you just did is now worthless because you have to go and change everything.

So this forces you to just focus on that single user experience problem and create a nice flow from screen to screen to screen. You're going to come back and design it, or a designer is going to design it, but from the user experience standpoint this part is absolutely critical to get right.

JH: Yes. That's one thing I've noticed as a team lead on projects. When low fidelity wireframes were used, it automated a lot of the other processes for the development team. I used to wait until the designer was done with the entire system before I really started coding. That was mainly because I'd had many bad experiences where I thought they were done, and I would start building it, but then I'd have to wipe the slate clean and start from scratch because they had changed something very significant. Now, when I work with these types of low fidelity wireframes, it gives me a head start. I don't have to wait for the designs. I can be confident that a significant portion of the user experience in that interaction is accurate. So I can take those wireframes and code straight from them. I don't have to worry about the design; I know I'll take care of implementing that part whenever the high fidelity wireframes are done.

You've mentioned elements such as images, buttons, and even gestures. Are there any other types of elements or any other types of actions that you try to capture?

JC: Maybe not actions as much as identifying what data you're pulling in. So, if it's a dashboard, you're saying, "I need to be able to show this piece of metadata and this piece of metadata," which helps the backend developer. He doesn't care what it looks like, just that it needs to be in there.

JC: Take DailySmarty for example. One of the objects in your wireframe might be a post. On the post index page, what type of metadata do I need to pull in? Do I need to pull in categories? Do I need to pull in post author? Do I need to pull in the date? With a low fidelity wireframe, I can actually show you that you need all this data here. I don't know how it's going to look, but I can represent it really quickly. I don't care about font sizes, I don't care about much, but it gives you a clear idea of the things you need to pull in to actually start building it.