Blogging From the "Design Process" SkillSwap | October 6, 2003

I'm going to be blogging from tonights SkillSwap event entitled "Design Process - Evolution of the Wireframe". However I'm gonna try and keep this one concise as I spent more time blogging and less time actually listening to the last talk.

The talk is being given by Web Producer and local blogger, Richard Rutter of

Any project will go through these 5 stages.

Websites can be one of two things, hypertext pages or web applications.

The user expirience is made up of the following parts

Because it's very difficult to specify everything at the start, you need to iterate through the design process.

Teams can be big. They can involve lot's of people from different backgrounds. What's needed is some way of communicating what's going on in a project to all these people.

Richard explains how he used to work as an engineer building oil plants and how everybody would refer to a PID diagram. This would be something that everybody could refer to, use and understand.

Jeffrey Zeldman defines a wireframe as:

Functional visual storyboards showing the proposed elements in relation to each other, but not in any way indicating how they will eventually look and feel.

Richard shows some examples of wireframes. Pages with blocks indication the position of various page elements like site logo's, global nav, content areas etc. Richard shows wireframes built using powerpoint, freehand and also a html wireframe.

The good thing about doing wireframes in html is that they are interactive. The links work and you can actually start to feel how the site is working. You can use them to run user tests and the wireframes then become a non-functioning prototype. You can even turn your wireframes into the final site.

On his html wireframes, Richard uses dhtml to show and hide various parts of the page to various parts of the page to various people.

The talk then opens up into a general discussion. Around 4-5 of the people present use wireframes on a regular basis and discuss the benefits of using them. They allow the clients to know exactly what they are getting up front. some people only use tec specs but many clients will not fully understand them. They can be difficult to read and it's easy to miss things out. Wireframes can be great discussion points and enable you to plan applications more effectively. Wireframes help create a more iterative process rather than a prescriptive one.

There is some concern that wireframing takes quite a bit of time and many people can't afford to do them. However a number of people feel that wireframing actually cut's down the time spent. You spend more time in the planning phase, but much less time in the execution phase. Clients know what their getting up front and it's much easier and cheaper to make changes to the wireframes than it is to change the completed application.

There is some discussion about the benefits of html wireframes over paper wireframes. It's easy for people to write comments on paper wireframes. Some people also feel that it's quicker to make paper wireframes. Also it's easier to create paper wireframes that cover all eventualities. However html wireframes can act as excellent non-functional prototypes and allow for easy testing. Also if done well, these wireframes can form the basis of the actual site.

Basically the type of wireframe you make depends on a number of things and is usually down to personal preference. However most people agreed that wireframing was an extremely useful tool and one that could bring tangible benefits to their web design process.

The session winds down and we all head to the pub.

Posted at October 6, 2003 5:40 PM


Taylor said on October 6, 2003 9:34 PM

I’ll be looking forward to seeing what you learn. I really enjoyed (and found very useful) your last documentation on SEO @ Skillswap.

Have fun!

Jacob Patton said on October 7, 2003 3:04 AM

Thanks for the notes—as a novice web developer, I’m always on the lookout for ways to refine my process. I’ve found the book Web ReDesign | Workflow that Works (Goto, Cotler; 2002) very insightful.

Do you know of any other resources (book or web) regarding development and production processes?

Andy Budd said on October 7, 2003 8:53 AM

Return on Design, featured in my books section, is also a very good book detailing the design process.

pid said on October 7, 2003 10:16 AM

I have a diagram?

Guy said on October 7, 2003 1:28 PM

We use a process called ‘paper-prototyping’ which I guess is kind of similar. IBM have some useful info on this process here:

I look forward to your notes from tonight.

Andy Budd said on October 7, 2003 2:06 PM

Often the terms wireframe and paper-prototype are used interchangeably. They are essentially the same thing.

The difference, if any, is that that wireframes tend to document only the key pages/user paths of a system and tend to include descriptions and instructions to the clients and web design team.

Paper prototypes tend to cover all the various permutations of a user path (including error messages etc) and tend not to include specific instructions to the development team.

Wireframes are therefor more general that a paper prototype and are designed for the use of the development team. Paper prototypes tend to be an extension of the wireframes, with comments removed, and all the various possible paths filled in, allowing the prototype to be tested.

However the distinction is semantic at best.

Oh, and they were my notes from tonight. i did say I’d be keeping them short :-)

Andy Budd said on October 7, 2003 2:09 PM

Also while wireframes by their nature tend not to have any design treatments applied to them (hence the term wireframe), paper prototypes can often include the design as well as the informational layout.

Guy said on October 7, 2003 2:48 PM

All useful information. Now I know. Got my dates confused. That’ll teach me to read things properly. Cheers once again.

Jacob Patton said on October 8, 2003 4:51 AM

Thanks for the notes and the book recommendation; I’ll definitely check it (and a few others) out.