A wireframe is a simple visual model of a website (or CD-ROM if you want!), It is produced by a very quick and cheap method so that it can be used early in a project, for example during requirements analysis It might be made using PowerPoint, Visio, or hand-drawn pages, or in HTML, Flash or a specialized wireframe software. Wireframes are excellent for discussions within the project team, and can also be used for paper prototyping and simple usability tests. They provide a model of the website that is easier to understand than, say, a flowchart or long descriptive document. Long Documents Send People To Sleep, but even a primitive model of the website can be excellent in flushing out misunderstandings and "unknown unknowns".
I often find that I need to explain why a wireframe makes no attempt at showing the visual design (colours, fonts, graphics). The point is that these will be agreed and added later (probably after some effort and cost, which we are trying to avoid while we hammer out the early ideas and find what is going to work). For the same reason, a wireframe often does not contain much actual website copy. The point of the wireframe is to focus on what key components should be on every page and how the pages should link together (it is often possible to get the wireframe to demonstrate the latter - for example, by hyperlinks between the pages).
It is worth thinking out exactly what you want to do with the wireframe (e.g. is it merely for the project team, or will it be used for usability testing and if so how?). Being able to explain how this very primitive-looking model fits into the design process is very helpful to reassure stakeholders that the final site will not look this bland and primitive!
As I mentioned, there are a number of tools that can be used. Since the idea is to produce something quickly and cheaply that can be easily changed when it has (helpfully) uncovered misunderstandings or problems, I think the key factor is to choose a tool you can use easily. In an interesting article HTML Wireframes and Prototypes: All Gain and No Pain, Julie Stanford makes a case for making a wireframe in HTML (she uses Dreamweaver). Comments on her article give opposing points of view about the pros and cons of using HTML - helpful stuff if you are trying to decide whether to give the HTML approach a try. If you do want to give it a try, Julie gives a primer on how to prepare a wireframe using Dreamweaver (making a lot of use of HTML tables). As I say, I think the important thing is for someone close to the requirements analysis to be able to build it quickly and easily. So probably the choice is as much dictated by tool familiarity as by anything else. Using HTML means that you have the option of actually using some of the wireframe code to make the real site - the pros and cons of this get an airing in the comments on Julie's article.
To show that even a very humble wireframe can be useful, check out this example in PowerPoint:
This wireframe is for a (fictitious) publisher’s website – AAD Publishing Limited, publishers of Arts, Architecture and Design books. For demonstration purposes (or because AAD is only a very small publisher requiring only a simple site) it contains only a few pages. But hyperlinks allow you to move between them in a way that gives a reasonable impression of how the site will work. I would use a wireframe like this for early discussions in the project team, and perhaps for some quick informal usability tests on any sentient human being who doesn't run away too fast (e.g. co-workers, neighbours, spouse). Even a wireframe as primitive as this can be worthwhile to throw up questions about scope, navigation and usability such as:
- •What have the project team assumed the purpose of the site is? And are they right? What have they missed?
- •How can we keep the home page interesting? It may need frequent updating – who will do this and will it be sufficiently easy for them to load copy onto the site?
- •Should the 3 categories of Art, Architecture and Design (as shown in teh current wireframe) be further subdivided?
- •Decisions will be needed about the order in which things appear on the page – e.g. for the books is it latest publications first? Bestsellers first?
- •There is no way of searching the site – is that an omission?
- •How can a customer buy a book he or she sees on the site? Is there an order form to post to us? Do we want to offer online purchase (there is currently no shopping cart in the design – is that an omission)?. Including a shopping cart would of course introduce various issues about how to take and fulfill online orders (potentially a problem for a small publisher). Do we prefer simply to be an affiliate, (e.g. of Amazon), until it is clear how much business can be generated?