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.
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
- User Needs & Site Objectives
- Content Specs/Functional Requierments
- Interaction Design/ IA
- Information Design/ Navigation
- Visual Design
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