Separating Content from Visuals in Web Site Design
Jeanette Fuccella, jfuccell@us.ibm.com
Jack Pizzolato, jackp@us.ibm.com
IBM Corporation
Introduction
A well-designed Web site represents the successful fusion of many elements:
good layout, effective graphics, exciting content, intuitive navigation. As
Web professionals, we strive to build Web sites that seamlessly integrate these
varied elements into a cohesive whole. Ironically, while this is the ultimate
objective of any good Web site design, integrating these elements too early in
the design process can actually work against this objective and mask problems
that might otherwise be detected early.
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.
Our Experience
As software engineers, we know the importance of early and rapid prototyping.
Initially, we built Web site prototypes that integrated the proposed structure
for the site (if not some content) with a preliminary visual or graphical treatment.
Our goal was to gain early feedback from users on both the content and appearance of
the site. However, while testing the usability of these designs, we discovered that
users focused much more on the visual elements in the prototype than the proposed
content or structure of the site. In fact, users were so drawn to the visuals that
we had difficulty in getting feedback on critical questions about content and
navigation.
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
Incorporating the use of a wire frame into our Web site design process has
tremendously enhanced our ability to design quality sites. Our team, our clients,
and our users, have all benefited from this approach.
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
Separating visual elements from the architecture and content of the site
during the early design phase has allowed us to gather equally important
feedback on visuals without distracting users with actual content or navigation.
The approach also enables us to get an approval from the client on the high-level
visual design for the site separately from the approval for the architecture.
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.
Getting Started
The following resources are provided to assist you in getting started creating
wire frame and greeked visual designs. As with any rapid prototyping technique,
it is not important what tools you use to create the prototype. Rather, focus on
finding a technique that works best for your team and your specific project --
all the while remembering that the goal is to reduce overall development time
and still provide a superior product.
- CNET Site Planning Tips
- Testing Whether Web Page Templates Are Helpful (Nielsen Alertbox: May 17, 1998)
- Creating Web Site Designs Based on User Expectations and Feedback
© Internet Technical Group
Last update: March 1, 1999
URL: http://www.sandia.gov/itg/newsletter/mar99/wireframe.html
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.