Hall of Bright Carvings

Wireframing and prototyping are increasingly important steps in the
development process, they allow you to clearly and definitively establish the requirements for a project before anyone has invested too much into it. They provide clients and developers with a clear and well defined road map of what the project will deliver and what a user can expect when it comes to using the resulting site. In this article we’ll take a look at some of the more common ways Information Architects create wireframes as well as a way for web developers to develop practical, effective and relevant wireframes and prototypes using the skills they use every day.

Traditionally, wireframing sits between gathering client requirements and design. It allows clients, developers and designers to all be clear as to the site structure, page structure and, to a certain extent, the functionality involved in developing the project. Wireframes can be anything from complex prototypes through to a few sketches on the back of  napkin.

Imagine a client who wants to develop a site called ‘Document World’. A place where authors and editors can upload  documents, share resources and collaborate with each other to edit their documents. The client wants the site to be  community driven and simple for non-technically minded people to use. We spend some time chatting with the client,  taking notes and gathering the various requirements and elements she would like to see on the site.

Once we’ve documented these requirements and different elements we can start producing wireframes that will help  the client confirm that we’ve understood what they want.

We can use any number of tools to produce those wireframes. Some popular choices, in increasing level of fidelity, are:

Pencil & Paper

There’s nothing wrong with simply sitting down with a notepad and a pencil and just sketching out a few basic ideas. It’s cheap, fast and incredibly productive.

In fact, whatever your eventual tools, your first step should always be some quick paper diagrams. They will help to get your thoughts into a coherent shape quickly and effectively.

Pencil

A firefox addon that allows for development of quick and easy wireframes that are a step up from pen and paper. For very simple sites this addon is an excellent tool.

Visio, Omnigraffle, InDesign, DIA

Traditional wireframing tools for windows or mac. These are excellent tools for developing standard wireframes, but tend to lack the features that allow for the development of functional prototypes.

Once an industry standard, there is a growing trend away from these tools as wireframes lose ground to prototypes and the need for increasing complexity to take into account user interactions and states.

Axure RP, iRise, Balsamiq Mockups

Prototyping tools that can replicate some very complex interactivity. As usability becomes more and more refined in web projects, it’s becoming increasingly important for develoeprs and clients to get a sense of how things will work  before committing to what may be an expensive and complex development process.

Other

There’s another option, one that more and more people are starting to turn to as they look for the best way of  wireframing and prototyping elements and interactions on a website: HTML, css and javascript. It makes sense that one of the best ways of modelling behaviour is to use the languages you will be using to develop the project itself.

Implementing an HTML wireframe

To begin with an HTML wireframe we need to start with a layout. You can either use any standard css template you have that is appropriate or find one from the plethora of css support sites that provide suitable templates.

An HTML wireframe is not a website, as such browser compatability is not a high priority. Pick a single browser your  client should view the wireframes in and build to that. The focus should be on speed, the time for progressive  enhancement, accessibility and compatability comes later; during development.

What will likely slow you down initially is establishing some standard rules and templates for laying out the various page elements but if you try a few practice wireframes and keep track of elements you find you use again and again you should very rapidly generate a library of classes and rules that allow for some very complex layouts and elements
to be assembled with startling ease. Once you’ve written a single login or registration form, for example, make sure that you store the markup for it somewhere easily accessible so you can use it again in your next wireframe.

At the very least you should be developing two wireframes for a client – a homepage and a standard content page. Make sure that the standard content page has examples of every HTML element that can be styled so that when the designer gets the wireframes they will know they need to produce designs for them all. A list of HTML elements
can be found at the W3 site.
Some of them you can ignore, but you should strongly consider including any that have a visual element.

An example HTML wireframe for this project can be seen here

Once you’ve produced the appropriate wireframes for the client you can bring in the client to show them because one of the first rules to wireframing is that clients never get to see wireframes on their own. Being there to walk them through the user journeys and explain the decisions regarding why certain elements need greater weight or a certain location is a very important part of the process which can easily get confused and muddy if the client isn’t kept focused on the main responsibilities of a wireframe. The client seems happy, then they turn and say ‘I really like these, but if I could just make one or two suggestions?’

The fine line between wireframe and prototype

Depending on the nature of the client’s suggestions you’re almost certainly going to have to make a choice at this point. If the suggestions relate simply to the issues wireframes are responsible for clarifying; that is, weight of elements, grouping of related components, or illustrations of paths of navigation then you should be able to deal with them with a few changes or annotations. More likely however the client will want to bring in either some design or interaction issues that are not the responsibility of a wireframe. At this point you either need to help the client understand the nature of the wireframe process and concentrate only on the issues it relates to, or you need to make the decision to progress the wireframes from being static wireframes and into interactive prototypes.

There’s a fine line between wireframes and prototypes and frankly, the line is getting thinner everyday and it’s made thinner again by the very nature of HTML wireframes, but it is important to understand that there is a line between them and that they serve different purposes. A wireframe is a static tool while a prototype is a much more open-ended and interactive exploration of how certain functionality and elements are supposed to work.

Let’s pretend that the changes the client is asking for consist of the following

• “In the right column it would be nice if the ‘Recent Editors Comments’
  was above ‘Your Recent Documents’ to give it more weight.”
• “Can we have the ‘Documents, Comments, Resources’ sections in the
  right column work like an accordion with the ‘Editors Recent Comments’
  open as default?”
• “How does the page look when the user is logged out?”

Part 2 of this HTML wireframing tutorial can be found here