Wireframes & Prototypes: What are they, how do we use them and when?

By Steven Shyne

Wireframes and prototypes are two essential creations in the user experience (UX) design process. In fact, according to a study by Neilsen Norman Group with UX design professionals and how they communicate their work, “Static wireframes were the most frequently produced deliverable overall (71% of respondents produced static wireframes ‘often’.)”  Additionally it was noted that “Interactive prototypes are the most popular deliverable across multiple different target audiences.” 

So they're widely used, but what are they? Also, what makes them different and when do you use them? Keep reading, friend.

Wireframes

‍

In its most basic form a wireframe is a rough sketch of a web page, app screen, kiosk monitor, or any other interface. Included in a given wireframe is an outline of the interface features, functionality, and approximate layout.

This can be (and often is) doodled in a sketchpad, scrawled across a whiteboard, or slapped together in some visual editor (heck, even MS Paint might work in a pinch), but it is more likely created using a UX design tool, like Adobe XD, Invision, Figma, Balsamiq, or the like, as it’s far easier to revise, iterate, and collaborate in those tools, especially when geographically separated. Each of these software solutions have their own host of benefits, but that head-to-head comparison will be discussed another day.

Regardless of where they are made, be it the pages of sketchbook or the pixels of a program, wireframes are intentionally low fidelity, meaning they are made up of simple boxes, arrows, copy (potentially even placeholder) and are typically completely grayscale. This is intentional as they are meant to be a vehicle for getting ideas down fast, which can in turn kickstart review, revision, and collaboration. As for process, iteration isn’t optional; it is required to create a good UX design. 

But static wireframes are not without their limitations...

1. Firstly, they are often singular in scope. One wireframe may not connect with another and requires a high level of familiarity with the project to piece them together mentally. 
2. Secondly, they are “static,” meaning there’s no interaction - so not ideal for a stakeholder or developer understanding of interaction states or functionality.
3. Thirdly, the low-fidelity, box-and-line look typically means they are not ideal for gaining outside feedback like stakeholder review or usability testing, as it may create more confusion than insights (that said, we always suggest bouncing ideas off another designer, just to clear out assumptions and workshop good and bad ideas). 
4. Lastly, they are not pixel-perfect. A wireframe is a great jumping off point for visual designers who have a strong sense of brand identity, color theory, proper use of white space, and lots of other visual design things that make them an expert, which is why you’ll often see wireframes in grayscale as a way to avoid the temptation to start tinkering with aesthetics (also known as pixel pushing).
   

In short, wireframes are a relatively quick, cheap, and easy way to get web page or app layouts down and ideas flowing. They should help a team visualize interface layout, features, and hierarchy and explore ideal states as well as fringe use cases.

Before talking about prototypes, here are three tips on wireframe creation:

1. Spend some time with wireframes to explore the dark corners of your design. Try using the shortest and longest possible character counts, mess with fringe device dimensions, and otherwise try to "break" your wireframes. It’s much better to iron out all these wrinkles now before moving into a visual design (or even worse, development).
2. This applies to all responsive design, but it’s so common these days that it’s worth mentioning: wireframe for your smallest state first – it’s far easier to fill new-found visual real estate than to squish and smoosh your large monitor desktop design into a commonly used smartphone viewport. Save yourself the headache and start small.
3. This may be a hard pill for some designers to swallow, but your wireframes won't be right, especially the first draft. In fact, the first few should be wrong; they are meant to present collective thinking, outline discussed content, and provide solutions to problems, not solve everything in one sweep. Expect rejection, embrace failure, and know the criticisms are for the wireframes and not your work. 

If you remember nothing else, remember this: wireframe should be collaborative, iterative and exploratory.

Prototypes

‍

If a wireframe is a quick sketch, then a prototype is a blueprint for the entire user experience. And while a wireframe can be on the back of a napkin, a prototype is definitely done in a UX design tool (again, different tools may have different capabilities and features – pick your poison).

One other piece of nuance: “prototype” also implies a clickable or tappable functionality to move around through the prototype, and in fact is commonly and even best referred to as an “interactive prototype,” but nuance aside, we will use “Prototype” to mean the same thing.

As to where prototypes fit within a UX project stage, prototypes are most often created as a product of progress. Once enough wireframes have been created and approved, they can be grouped together with click, tap, and other UX functionality (modals, sticky headers, etc.) to create a simulation of the designed UX, all without any code. This way, teams can see the flow from one page to another, the expected interactions that should be designed, and ensure all is intuitive and smooth, with relative ease and with fairly low effort to revise.

Building this interaction is time consuming but worth it as it provides a platform for clients, usability testers, or other stakeholders to emulate the intended user flows. As such, adding in more true-to-life details, like product images, copy, or calls to action makes prototypes all the better, and the better the prototype, the more likely you’ll be met with resounding "ah-ha's" from all involved. 

But this lifelike likeness comes with a cost: the inclusion of interaction and the overall high-fidelity nature of prototypes makes them a high-effort deliverable, so larger revisions should be kept to a minimum. They will happen – afterall the point is to see and explore the UX designs and their flow from one to the next – but this is why we start in wireframes and move into prototypes versus jumping straight into a high-effort prototyping. 

This sounds like a heavy lift, but you know what’s more time consuming? Sending your wireframes down the pike to visual design then into development and once built and pushed to the live site only then thing finding quirky, wonky, or just-plain wrong experiences that could have been found and solved for in the UX design stage. Measure twice. Cut once. 

One of the most elegant parts of prototyping is building digital experiences visually and without any code. Like wireframing, this is your chance to explore, bend, and break your designs. 

Here are three tips to keep in mind when creating interactive prototypes:

1. Think about who you’re really designing for. And we’re not just referring to the end users at this point. If you’re adding slick, sexy interactions and animations into your prototype, are you doing this to feel cool or to stave off boredom? If so, you’re likely just adding noise. Keep it simple(ish).
2. Use those software tips and tricks. If you’re just starting out in UX design, or if it has been a while since you used a particular platform, save yourself from headache and project fatigue and watch some training videos to get up to speed on the newest features and capabilities of your chosen UX tool. Simple things like creating groupings, components, and palettes can save hours of tedious revisions – which is good news for your workday, your sanity, and your burndown report.
3. Like a tip previously mentioned for wireframing, design for the most complex, crazy state you can. Add in all the things that you think the team might have on the slate for the future, and when you move into visual design have those comps designed only with what will be built. This way, When that new login feature, product grouping, or search bar gets added into scope down the road, you and your team already know exactly where they will go, and have an approximation for the user flows in and out of those features.
   

Again, if you remember just one thing about prototypes, they breathe life into wireframes, often with higher fidelity and emulating intended experiences. 

If you want to hear more about what how we help clients with user experience research, strategy, and design, drop us a love note: hello@cxperts.io