This paper describes an approach our team has adopted for separating the visual "look and feel" of a site from its content during the early stages of design. The approach has designers prototype and test the structure and content of a site independently from the site's visual design to obtain a more complete and accurate picture of how users perceive these individual elements.
As a result of these experiences, we decided to try an alternative approach to Web site design and prototyping. We made the decision to separate the content and visual layers of the site and to gather feedback on each layer independently.
At the same time we were making this transition, a member of our team attended a conference presentation that highlighted a useful technique for outlining Web site content called a "wire frame." A wire frame is a simple HTML model of a proposed a Web site. Its primary purpose is to identify the navigation scheme and location of content within the site. In order to keep the design as simple as possible and to allow for rapid iterations, few if any visuals are used within the wire frame.
To complement this approach and still gather feedback from users on the visual design during its evolution, we created separate visual design prototypes that used "greeked" text as placeholders for actual content on the site. By gathering feedback on the content separate from the visuals, we found that we were able to get higher quality feedback from users on both aspects of the design. Of course, after the initial prototypes were complete, we merged the designs and gathered feedback from users on the total Web site.
Wire Frame Benefits
As a design tool, the most important benefit of the wire frame for our team has been the way in which it speeds up the Web site design process. This is not only because designers are able to prototype and make changes to the design more quickly, but also because the prototype actually evolves over time into a finished site. As a result, an enormous amount of coding time is saved. In our process, we use the wire frame to identify the location and type of content that will be on the site long before we have actual content. Over time, as content is created for the site, it replaces the content descriptions in the wire frame. Similarly, we might use text or HTML elements (a box, for example) to simulate graphics or other visual elements.
As the visual designers define the overall look of the site and create images, the team incorporates those finished elements into the wire frame as well. This approach has made our visual designers huge proponents of the wire frame model. Before we used wire frames, our visual designers had to make a lot of guesses about what they were designing to -- for example, the amount and type of content. As often as not these guesses were wrong, forcing the visual designer to go back -- literally -- to the drawing board. By quickly identifying and verifying site content and navigation using the wire frame, the Web designer gives the visual designer a stable model that they can work from.
The second most important benefit of using the wire frame approach came as an unexpected surprise. Until we started using this approach, we had a difficult time getting our clients to visualize how the site structure would work. We used flowcharts and other devices to illustrate the site, but not until site was actually put together, did the client have a clear picture of the outcome. As a result, clients often requested major changes to a site late in the development cycle, causing delays and significant re-work. With the wire frame approach, clients actually interact with a functioning model of the Web site at the design stage of the project. They can click on links and see where they go. They can begin to "feel" what it will be like to use the site, and in doing so, provide us with critical feedback much earlier in the design process. In fact, we now require that our clients provide a formal approval of the wire frame before we proceed to the development stage of our process. This ensures that we have agreement on the high-level navigation and architecture of the site before significant development work has been done.
Being able to interact with the site early on makes our clients happy, but it also serves another purpose: it becomes a checklist that they can use while gathering content for the site. Remember that we identify exactly what content will go where (and usually who owns it) in the wire frame, and that we fold the actual content into the wire frame as we obtain it. So, our client and our team can easily scan the wire frame during status meetings to determine what content is missing and the owner of that content. If due dates are decided upon, these can also be indicated in the wire frame. This eliminates the need to maintain a separate tracking mechanism, saving time and potential errors.
Using the wire frame also allows us to identify areas where visual design features can positively impact the overall usability of the site. Typically, in our wire frame testing, we will identify the need for affordances in our design. This information can be passed along to the visual designer.
If your Web site requirements include a text version of the site, another benefit of the wire frame approach is that your wire frame can very easily become the text version of your site. You simply don't integrate graphics at the end of the process. Because your wire frame is simple in design and doesn't include any fancy coding, it is likely to meet any accessibility requirements that your text-only site must adhere to.
Finally, for usability purposes, the most obvious benefit to using the wire frame approach to Web site design is that it allows the design team to prototype and iterate extremely quickly. Different variations of the same design can be prototyped easily and quickly for comparisons by users. If resources are tight, virtually anyone on the team with minimal HTML knowledge can make updates and changes to the wire frame design.
Greeked Visual Design
The approach of using greeked visual designs early in the design process brings with it all the same benefits as does rapid iteration with a wire frame. In order to allow clients and users to "feel" what it will be like to use the end product, we typically prototype a set of pages for a particular design metaphor (minimally a home page and second level page) and then use client-side image maps to link them together appropriately.
During these early iterations with the visuals, we focus the attention of the client and users on the distinctly visual aspects of the site. For example, the designs should try to portray a "visual personality" – is the site whimsical, technical, serious, friendly? We evaluate where the user's eye is drawn when they first look at the site, comparing the results with where we'd like them to look and what's most important on that page. We also determine if the visual cues are indeed acting as cues and assisting the viewer rather than providing barriers to access.
Because these designs are being created independently of the wire frame design, development of both can happen in parallel. And because neither party has hard dependencies on the other for creating a prototype, both designs can be iterated and prototyped much more quickly.
© Internet Technical Group
Last update: March 1, 1999
hosted by Sandia National Labs
Disclaimer: Neither Sandia Corporation, the United States Government, nor any agency thereof, nor any of their employees makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately-owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by Sandia Corporation, the United States Government, or any agency thereof. The views and opinions expressed herein do not necessarily state or reflect those of Sandia Corporation, the United States Government or any agency thereof.