What are wireframes?

When most people think of UX, they think of the line-and-boxes diagrams called wireframes. Unfortunately, many people think that doing wireframes is the same as doing UX.

 

What are not wireframes?

 

Before we get started, you should know What Isn’t a Wireframe, just in case you have let some bad habits into your own process (or your company’s process). A wireframe IS a planning document. It IS a technical instruction document for the “builders”. Wireframes allow us to say insightful stuff like “Oops, I forgot the main menu!” in the same way an architect could say “Oops, I forgot the front door!” The following is a list of how wireframes can be used incorrectly.

 

Wireframes are not a basic sketch

Often we treat wireframes like a quick and dirty sketch, or like step 1 of the design. “Just make a wireframe for now!” They aren’t. Wireframes specifically exclude design, to show how the site/app will work, not how it will look. Those napkin drawings you (and I) make at the beginning are important for sorting out our thoughts, but they’re not wireframes. Explain early concepts/thoughts in words and pictures, not with wireframes. Show flows as icons, hand-drawn sketches, site maps, slides, or user stories instead… they’re better, faster to make, and easier for the client to understand.

 

Good wireframes take time

I know they look basic, but there is a lot of thinking behind those empty rectangles. Every little piece must be planned, placed carefully on a specific page. Every link needs a destination. Every page needs a link (on another page) to get there. Every button needs to be where the user needs it, and not to be where the user doesn’t need it. Wireframes are 90% thinking, 10% drawing. Make sure everyone respects the need for the 90% part!

 

Wireframes aren’t presented in phases

Everything made by humans goes through “drafts” as we perfect our ideas, but wireframes are either ready or they’re not. If they’re not finished it is because something isn’t solved, isn’t organized, won’t work, will be hard to use, or is missing. If you can’t start to build, the wireframes are a work-in-progress. Don’t be afraid to say that to a client or your manager! Making decisions based on half-ready wireframes is a nightmare waiting to happen. I say this from experience.

 

Wireframes should be taken seriously

I have watched people move a printed wireframe (on paper) from one section of a site to another because it “feels” better. I have seen a 70-page set of wireframes for a social network that didn’t have a profile page (designed by one of the top ad agencies in the world!). I have seen user-generated content that cannot be generated anywhere. I have seen a client cross out a “register now” button because it’s “ugly” in the wireframe. I have seen a site designed & launched by a global agency without a main menu (you thought I was joking when I said that, didn’t you?).

 

These may or may not seem like a big deal, but each is an example of a crippling mistake that could destroy a product or service.

 

Plan enough time for wireframes — especially in large projects. Label and describe (i.e. — “annotate”) each element of each page, so a developer never has to ask you what a button is supposed to do.

Continue reading?

Share this article

asds