Wireframes and prototypes are two important types of UX artifact that are often mistaken for one another. While each has a specific purpose and application, there is some overlap which can cause confusion – even to practicing UX professionals. Let’s break it down so we can all finally get on the same page.
Think of wireframes as just a step beyond hasty sketches on the backs of bar napkins. This is how all plans are hatched and great ideas begin to take shape. It’s also how crappy ideas get crumpled and tossed in the trash. This is essential to early ideation, and it doesn’t cost much. Wireframes are static, low-fidelity drawings of a product. Their purpose is to depict structure, hierarchy, and general functionality.
We prefer to make wireframes prior to building out an actual product in code – much the same way an architect creates blueprints before they start welding giant beams together. Blueprints are cheaper and can be changed faster.
Prototypes are a full measure of complexity beyond wireframes in that they actually do stuff. They’re interactive. Clickable. Users can click through use cases much as they would on a regular website or app. Prototypes also cost significantly more, so they’re not appropriate in all cases. There are two main reasons to build prototypes:
- Prototypes enable you to conduct user testing* prior to building your final product.
- Prototypes can help flesh out complex use cases or novel user interactions that are easier to show than to explain.
* You can do some degree of user testing with static wireframes, but they won’t be as instructive or reliable as testing done with functional prototypes.
You still didn’t tell me which one I should be using.
Okay. Both. Sometimes.
Both wireframes and prototypes can offer enormous value to a project. Whether a given project calls for one or the other (or both) is determined on a case-by-case basis. Two examples:
Example 1: If you’re redesigning your website but your “Contact us” form isn’t going to change much, a wireframe is sufficient to convey the functionality and required fields to a developer. Done. There’s no reason to create a prototype with functioning fields and a thank you message. Instead, spend that money on something that makes the product better.
Example 2: If you’ve got an idea for enhancing the mobile user interface on the product detail pages of your e-commerce website, a few quick wireframes might be necessary to capture the kernel of that idea, but you’ll probably want to dive into prototyping pretty early on in order to capture the nuance and detail of your nascent user interaction.
Now let’s talk about fidelity.
You’ve probably heard the words “low-fidelity” and “high-fidelity” applied to interactive prototypes. They can mean different things depending who you talk to, but here are some definitions that make sense to us.
Low fidelity, or Low-fi, means something along the lines of the aforementioned bar napkin, with only as much detail as that particular medium is capable of depicting. It’s a note-to-self type of document that really only makes sense to the design and dev team. It’s probably not a deliverable that’s suitable to present to a client.
Medium-fidelity (we say mid-fi; nobody says med-fi, sorry) is how we do most of our wireframes and prototypes. They look enough like actual interactive elements so that anyone who encounters them will immediately feel grounded in the context of the website or app we’re creating. The relative sizes of placeholder text and interface elements are approximate to a real website or app, but no brand elements, colors, fonts, or photos are used at this level of fidelity. Only structure and function are represented.
High-fidelity, or high-fi, means what you think it should mean. These prototypes contain everything found in the mid-fi, plus colors, fonts, logos, and even that subtle hover effect on the tertiary nav drop-down menu are also accounted for. The prototype looks very much like an actual finished product.
This might seem like overkill. In most cases it would be. But sometimes high-fi is necessary.
When is high-fidelity prototyping necessary?
Different users require different levels of fidelity before they really get what’s going on. A low-fi prototype might be enough for the dev team to fully understand the designer’s intent, but the CEO might start to question the designer’s work ethic unless they present something that looks like an actual website or app.
Generally speaking, higher fidelity prototypes grab and hold users’ attention more effectively than low-fidelity. This is particularly true when conducting user testing. Most users can orient themselves in a prototype that looks like an actual website or app much more thoroughly than they can staring at a bunch of black and white boxes drawn on a screen.
The key is finding the sweet spot that adequately addresses both the complexity of the interface being presented and the sophistication and imagination of the testing audience.
But if we’re doing high-fi prototypes, haven’t we already crossed into UI design territory?
No. Regardless of how high your fi gets, you’re still only likely to be going high-fi for a segment of your overall project, not the whole enchilada. Not to say the UI folks can’t help with these high-fi prototypes – they can. They should! But that’s still not the UI phase. Only after all the user testing and UX tweaks are done can the UI team bring the full weight of their expertise to bear on the product as a whole.
If all you need is basic structure so your dev team and designers can get started, go with wireframes. If your product has complex use cases or novel user interactions and you need to test them, then make prototypes for just those sections. Fidelity should be just high enough to keep testers and stakeholders oriented and focused on what matters.