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.

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.

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.

About the Author

Neal McGann is a User Experience producer specializing in conversion testing and usability. He has a B.S.C. in Applied Science, and an M.A. in Interactive Media from the Dublin Institute of Technology. Neal works for VKI Studios.

7 Comments

Neal,
Great conclusion to your 2-part series. Knowing what type of wireframe you need for a specific stage in your project’s development, or depending on your client, is very important to receiving the right type of feedback to get you the best results.

I agree with your top 10 tips. I think numbers 2 and 10 are very important and somewhat related.

A tool not mentioned in Part 1 is ProtoShare. After sketching, you can refine your wireframes as simple gray-box or evolve them into hi-fi prototypes. Then share & discuss with others for feedback, or export to a hosted URL for user testing or to a Word doc for detailed specifications. Designers can even upload design comps and add links or share for feedback.

As you previously mentioned, there are a lot of tools out there, it’s just about finding the one right for you and for the job.

Richard, she’s just adding information about something that can be valuable for the readers and even the author: there are plenty of wireframing/prototyping tools so he might simply have missed some.

Justinmind is neither listed in Part 1 but it’s definitely worth having a look. It’s really focused on communication and feedback gathering, it offers the possibility to create extremely hi-fidelity software prototypes and later share it with your clients, gather remotely their feedback and even run usability tests online.

Thanks for this ‘two-parter’, Neal! It’s both enlightening and comforting to see the various approaches to wireframing.

I especially like your tip about involving others in the process. I see this as a necessary step in the over-arching creative process, and it’s potential helpful in times where Hi-Fi wireframes are used.

Consistently involving the visual designer will get them directly involved in interactions, and I personally find this relieving: they have a seasoned eye for layout and how hierarchy can affect UX.