Wireframes are the extensive documents full of empty rectangles with labels like “user name here” and “image”. I admit, they can be boring. But they’re important, if not essential. If we are the “architect”, wireframes are the blueprints.
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!”
But this week’s ProTip isn’t about what a wireframe is. It’s about what a wireframe ISN’T.
The following is a list of how wireframes can be used incorrectly. See if you recognize yourself in any of the Top 5 unforgivable (!) wireframe sins:
1) 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.
2) 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!
3) 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.
4) 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.
5) Wireframes are not meant for display.
I die a little every time I see wireframes colored blue and presented in a stylish way. Immediately I know that the people behind those wireframes have no respect for what they’re doing: they have not used color with meaning (red for warning, etc.), they have tried to pass important things by a client/boss by making them prettier, and they have put the focus on the “look & feel” in a document that is primarily for technical purposes. Making a wireframe look like a blueprint is the equivalent of using Comic Sans to write a contract.
And that’s what a wireframe isn’t. Were you surprised? Tell me about it on Twitter!
Have a great week!
****
If you liked this ProTip, try ProTip Tuesday #9: Create a No-Fail Environment.