Like with wireframing tools, there hasn’t been much consensus on wireframing technique. There are lots of different approaches which range from quick and dirty 30 second thumbnail sketches, to Hi-Fi wireframes using Illustrator, to creating wireframe mockups in HTML.
Techniques
Quick and dirty
The quick and dirty approach is especially useful at the outset, as it allows for the broad outlines of the design to be put in place very quickly. The intent is to avoid getting bogged down in small details and just sketch out the big picture, i.e. wireframing with a sharpie or with a boxing glove on. Avoid obsessing over minutia. Instead, as Harry Brignull put it, focus on the:
- Proposition – Is the overall idea useful?
- Concept – How does it deliver value?
- Context – Would it fit with the other things the user is doing, e.g. before and after using it?
Hi-Fi Wireframe
Though anathema to some, there can be real value in fleshing out your 30 second sketch so as to more accurately tests interactivity, dimensions, font sizes, and padding. There are definitely pitfalls with this approach: time can be wasted and the creativity of the designer can be stifled. Additionally, if wireframes look rough and ready, then they communicate to the client that this is a relatively early stage of the process and they should provide high-level feedback (concept/design). Hi-fi wireframes generate much lower-level feedback (small details).
That said, as long as you consider the impact that fidelity has on feedback, hi-fi wireframes can be a great way to tease out potential issues at an early stage. They work well for early user testing (requiring less assumptions to be made by the test participants) and are invaluable if site development is being outsourced (since developers typically require very detailed instructions). Finally, this approach also presents a great opportunity to begin incorporating a grid system into your design.
HTML Wireframe
There is a growing band of designers who create their wireframes in HTML & CSS. This can be a real time saver later on. Additionally, text rendering within image editors can be hit and miss, so it’s great to be able to get it into the browser. Finally, the website exists to communicate ideas, these ideas are usually driven by content, and so design should follow content. By starting early in HTML & CSS, it’s possible to add the content in and design the site around it.
Putting it all together
I see the three techniques listed above as part of a continuum of approaches. Each has its place and can be useful for different projects or at various stages of the design process. While I don’t typically use the full-on CSS and HTML process espoused by Megan, I do like to embed my wireframe images in a little HTML so they can be displayed in the web browser, opening up the possibility of adding some interactivity. Most importantly, however, is that by presenting them as hosted HTML you can share them with clients or user test participants. No need to worry about people being able to receive attachment or open files. Best of all, you retain the power to tweak and refine them whenever you want.
An example of this type of wireframe setup can be seen here.
I usually include one very basic interaction: click anywhere on the mockup to cycle through to the next wireframe. If I need anymore interaction than that (i.e. functional top navigation), I jump back into Fireworks and add some hotspot links.
Here’s a download link to my simple wireframe HTML and CSS framework files. I use these as the starting of point for my wireframe presentations. To create your own you’ll need a tiny bit of HTML and CSS knowledge. It’s quite simple: swap out my wireframe PNGs for your own (it’s easier if you keep the file names the same) and then change the width within the CSS file to match that of your images (don’t forget to update the documentation notes at the bottom).
Top 10 Wireframe Tips
To round off our review, we’ll leave you with 10 tips for creating wireframes:
- Start Sketching
Sketch them first with a pencil and paper for a quick sanity check. This should take about 30 seconds and opens up the possibility of getting early feedback. This can save a lot of time and money. The feedback can be gained through peer review or, best of all, from some early and informal user testing (you may need to spend a little more than 30 seconds on the sketches if they’re for user tests). - Focus on Communication
The key point of wireframes is to communicate. Don’t forget this. Keep them simple and stop working on them as soon as they communicate their key information. - Use Proper Documentation
Since wireframes are meant to communicate something, provide some accompanying notes. Whenever possible, each wireframe should include documentation, i.e. revision date, author, page title, interaction notes, etc. - Host the Wireframes
If possible, host the wireframe files yourself, rather than sending them out as email attachments. My preferred method is to export the files as PNGs and then embed them within some simple HTML files. This way they’re easy to share and update. - Don’t Forget the Goal Of the Page
Keep the goals of the page in mind when designing a wireframe. Focus on driving action. Organize the information into a hierarchy that serves the goal of the page. - Pick Your End Point
Prior to commencement, work out who will be consuming the wireframes, how they’ll consume and what level of fidelity is required. Remember that there’s a relationship between the level of fidelity and type of feedback. Will quick paper sketches suffice or will they need to be fully interactive with accurate dimensions? Keep in mind: the less precise the wireframes are, the more liberty and creativity a designer is going to take with them. On the other hand, if you they look perfect designers may feel inhibited and merely “color in” the wireframes, preventing the design process from really getting going. - Loop the Rest of the Team in
Wireframes are not just for clients. All members of the web team should provide feedback on them, buying into the process at an early stage. - Consider the Content
If your wireframes aren’t sketches then be realistic about the amount of content that will be added to the page. This holds true also for number (and length) of links in navigation. If practical, use accurate sized fonts, images and consider what will happen when more text than is ideal is added. Nothing on the web should be etched in stone, so ask if the design will flow as required. - Use Common Elements
If designing a set of pages, use tools that allow you to make multiple changes to all common page elements at once. Moreover, as you’re creating the wireframes, look out for design patterns that repeat. Leveraging these is key to gaining efficiency and consistency. - Get Feedback
Don’t be afraid to test your wireframes in a couple of informal user tests. Grab people from around the office and ask them to find various bits of information or explain what they think the function of certain elements is.