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 less than stellar 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 or website.
The purpose of wireframes is specific. They should depict:
- Hierarchy, and
That’s it. Any additional design flourishes may be misinterpreted by a client, UI designer, or developer.
I 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 more, so they’re not appropriate in all cases. There are two main reasons to build prototypes:
- Prototypes enable you to conduct more thorough 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. The UI designer may need to do little more than apply styles to the fields and copy. 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 and wireframes. They can mean different things depending who you talk to, but here are some definitions that make sense to me.
Low fidelity, or Low-fi, means anything between the aforementioned bar napkin and the standard wireframe, depicting only as much detail as necessary to move the conversation forward. If you’re planning to show the wireframes to your client – as opposed to keeping them as an internal project document – then it’s sometimes important to explain that, “No, this is not the design of your website. This is just showing functionality and hierarchy. Design comes later.”
High-fidelity, or high-fi, means what you think it should mean. A hi-fi wireframe or prototype starts to look like an actual website or digital product. To varying degrees, these artifacts can use accurate screen element sizes, more refined layout, even fonts, colors, and the logo. And if it’s important for testing, you could even throw in that subtle hover effect on the tertiary nav drop-down menu. A high-fi prototype looks much closer to how the finished product will look.
This might seem like overkill. In most cases it is. 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 UX designer’s intent, but a CEO new to the user-centered design process might start to question the design team’s work ethic unless they present something that looks like an actual website or app. I’ve seen this happen.
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 your 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 part of 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. While some UI teams work in parallel to the UX, the finishing touches don’t happen until the UX is approved.
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.