What makes a good wireframe?

Sam Lester
Oct 9, 2019 · 4 min read

We make a lot of wireframes at Inktrap, from quick sketches on paper or a whiteboard, all the way up to fully fleshed out interactive prototypes. But what makes a good wireframe? Why are some wireframes effective and others not? Turns out getting wireframes right is much more complex than it appears.

Let’s have a look at some of the things we do to make sure our wireframes work really well. In particular, we’ll focus on the sort of high fidelity wireframes that you might make into a prototype to run user testing sessions.

Don’t make them too beautiful

As a designer, it’s always tempting to fall into interface design when you’re putting together a set of wireframes. We use the same tools for both UX and UI designs so it’s really easy to start nudging things into a nicer layout, or changing fonts. There are a lot of wireframes out there that look like greyscale UI designs.

Screenshot of Dribbble showing bad wireframe shots
Screenshot of Dribbble showing bad wireframe shots
Dribbble is a pretty awful place to look for wireframe inspiration!

Effective wireframes are about content placement and user flows, not visual design. Resist the urge to make them look beautiful — this will slow down future iterations and introduce more confusion during testing.

This is easier to do if you’re using a pre-built solution like Blueprint, the wireframe kit which we created to make our own process quicker and more focused. If you’re using a kit you can restrict yourself to using mainly pre-built components and text styles, and reduce the factors you need to think about when designing.

Use the default style

We’ve certainly heard clients comment that the design looks a bit ‘basic’ or ‘empty’ because they’re looking at a wireframe with some of their brand elements, not a UI design!

For our prototypes we try to keep things bland and default as possible, so the visual design is as invisible as possible. That means we use Helvetica in black for text, a few greys for backgrounds, and a bright blue to highlight buttons and links. Very occasionally we’ll also use a few other bright and simple colours for specific purposes (e.g. traffic light style statuses).

Sample of interface elements in a simple style including buttons, form fields and text styles
Sample of interface elements in a simple style including buttons, form fields and text styles
A sample of the styled elements in the Blueprint wireframe kit

We also avoid adding in client logos as having a bright, recognisable image in the corner of the wireframes can distract from the user flow when testing. If we absolutely need to put a logo in (for example when testing designs where users need to select a brand) we’ll use a one-colour version so it doesn’t stand out too much.

Actions should be clear

When testing with wireframes we’re normally focusing on how a user moves through a product, from screen to screen. For this we’re creating interactive prototypes (using InVision) where it’s essentially a bunch of screens tied together with hotspots.

It’s really important that test participants can navigate between screens by discerning which elements are ‘clickable’ and which aren’t. The focus should be on the flow through your app/website, not trying to figure why one piece of text is a link and another isn’t.

Two example cards components, one with blue links and buttons, one with grey
Two example cards components, one with blue links and buttons, one with grey
The primary colour on the left design makes clickable areas really clear

As mentioned above we use a bright blue to show clickable areas. As a good rule of thumb, if you turn off the hotspot markers in your prototyping tool of choice, it should still be clear.

Make the content realistic

In an ideal world, we wouldn’t be making wireframes before we’d generated a bunch of content (particularly for marketing websites). Sometimes this happens which is brilliant, but other times we need to work on designs without completed content.

Realistic looking content can make your wireframes feel more complete, and make testing less confusing. Always use real content when you can, but if it’s not possible don’t use generic placeholder text. Instead, you could add in simple content you’ve written, or copy-paste some relevant content from other documents or partially written drafts.

The only exception to this would be images, which we avoid altogether. They instantly change the weight of different elements in the design, and it’s too easy to bias user tests with image selection.


All design rules are made to be broken of course, but hopefully these points are a good place to start. The most important thing is to keep your wireframes simple, and focused on what they’re best at!

We’d love to hear what you think makes a good wireframe — chat to us over on Twitter!

If you’d like to keep up-to-date with what we’re up to and our future freebies at Inktrap, follow us on Twitter and sign up to our weekly design newsletter Minimum Viable Publication.

Thanks to Liz Hamburger, Jon Barker, and James Hanks

Sam Lester

Written by

Co-founder, designer and front-end developer at @InktrapDesign. Sandwich enthusiast.

Inktrap

Inktrap

Thoughts, feelings and emotions from the Inktrap team

More From Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade