original posted on http://www.strangesystems.net
Wireframes serve a central function in the development of a web site. It is a key tool in communicating the content and layout of each web page for internal and client reviews as well serving as a blueprint for graphic designers to produce designs and for programmers develop functionality.
What are wireframes?
A wireframe is a stripped-down visual representation of a single web page, devoid of any graphic treatment. As the name suggests, it is a framework made with wires, which define basic layout and placement of content and page elements such as navigation; header & footer; branding etc.
They are sometimes referred to as “page schematics”, “page architecture” or even “blueprints” (though the term “blueprint” sometimes refers to a more overall site design).
It is sometime helpful to use the architectural blueprint metaphor in understanding wireframes. Architectural blueprints show you the form of the building, define the functionality of the spaces and paths for circulation, while provide the contractor and interior designer specifications from which to build from. Likewise wireframes define areas of content and functionality, navigation strategy while providing a framework from which the programmer and graphic designer can build from.
A full wireframe needs to deliver the following information:
-
Layout: General placement of page elements such as headers, footers, navigation, content area, and often branding; It communicates decisions that as been made as to the navigation strategy of the site; it also shows the prioritization of the content on the page.
-
Content inventory: What content needs to be present on the page
-
Web elements: Headers, links, forms, lists, images etc.
- Behavior: Notes/annotations may be added as to how elements should be displayed (such as number of elements, default display etc.), or what functional behavior occur when an element is activated (popups, page refresh, link to another page, or external site etc.)
When are wireframes created?
Wireframes as deliverables are developed as a part of Information Architecture phase. It usually follows the “Business Requirements” phase of the project and precedes any graphic design and technical development.
Usually this is the role of the information architect. On smaller projects, this often become the role of the project manager.
Who is it for?
The following table shows the consumers of wireframes and how they are used.
A blueprint with which they can review whether the design meets their needs; a preview to the actual site design; Key deliverable, the signoff of which kicks of design and development phases of the project
Consumer | Usage |
---|---|
Project Team | A communication tool around which aspects of strategy, technology and user experience can be discussed |
Client Stakeholders | |
Graphic Designer | A guide upon which they can develop mockup designs |
Web Programmer | A requirements document that details layout, content display and functional behavior of a web page to certain extent |
Types of wireframes
-
Content-only wireframes (aka Powerpoint wireframes): Powerpoint is used to define the key pages of the site. Name of the page, and a list of content items are captured on each page without information about layout or placement. This technique can be used to quickly capture client requirements and sketch out a site without having to go through the labor intensive work or creating detailed wireframes. Tools: Powerpoint
-
Block diagram wireframes: This type of wirefames is one step higher than the Content-only wireframes in that it offers basic layout information through blocks of functionality, and content grouping. These wireframes can be used in conjunction with detailed wireframes to provide a high level strategic overview to the wireframes before diving into the details. Tools: Powerpoint, Visio
- Detailed wireframes: Fully-loaded wireframes with layout, content, web elements information along with notes and annotations on page behavior. Tools: Visio, OmniGraffle
Developing wireframes
Here are some basic steps an information architect would take when developing wireframes.
Gathering information
-
Business requirements: Ideally you would already have documentation from the the Business Requirements phase. This document will spell out major site functionality, key site pages and what content/functionality would need to be presented on them.
-
Content requirements: If there is no documentation from a previous phase it is important to meet with client and sketch out what needs to be presented on key pages of the site. A content-only wireframe is a good tool to do this.
-
Existing design requirements: Additional information such as need to integrate with existing site guidelines or need for consistency with previous site design, etc. should also be noted.
-
Bandwidth requirements Some clients may have to serve a low-bandwidth user base in which case, the design will have to be more text-reliant and less image heavy.
- Software requirements Some sites are CMS-driven or software driven (such as blogs). Many software packages have layout and navigation rules the design will have to conform to.
Prioritizing/grouping information
- Once the information has been gathered, it is important to first group and then prioritize how they need to be displayed on the page.
Navigation strategy
- Clients may have strong preferences as to how navigation should work and be placed on the page. If there is no strong preference, software requirements and usability should dictate how navigation should be configured.
Drawing wireframes
Wireframes should include:
-
Key page elements & location: header, footer, navigation, content objects, branding elements
-
Grouping: side bar, navigation bar, content area, etc.
-
Labeling: page title, navigation links, headings to content objects
- Place holders: dummy text (lorem ipsum dolor…), and image place holders
The question often arises: how many wireframes should I create? The answer is how ever many you need to get the job done. (or in our case how ever many we said we will create). Having said this the follow should be included in any good set of wireframes:
Required:
-
Homepage
-
Major sub-pages and “portal” pages
-
Key template pages
- Pages with forms
Optional:
-
Search results page
-
404 Error pages
- Any other pages that provide clarification to the overall development process
Great details there. I have a question. When should a project manager do to apply this wireframes?
Afrer getteing thr SRS the project manager request for thr wireframes.
You’ve basically made a second list here! Ya have a heck of a lot to do as a new blogger.