What makes a good wireframe? - Inktrap

What makes a good wireframe?

Sam Lester
  • Oct 09, 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.

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).

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 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.

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!


More like this