Practical Applications: Visio or HTML for Wireframes

Written by: Jeff Gothelf

As information architects attempt to carve their niche in the world of web design, they are forced to balance the needs of several disciplines at once:

  • Clients require their business objectives be met;
  • Engineers require designs that do not exceed technical limitations;
  • Visual designers require specific skeletal work, but not direction;
  • Quality assurance teams require infinite detail;
  • And project managers require everything to take shape within the scope of the project.

All of these considerations must take place while keeping the goals and needs of the end user in mind. Once requirements have been gathered and features defined, IAs use a primary tool to fulfill these specific needs: wireframes.

“Clients become engaged when they can interact with HTML wireframes. Clients not only enjoy the process more, but they also get a better contextual understanding of the features than with paper prototypes.”Wireframes provide specific, screen-level information, detailing which elements need to appear, the implementation of these elements, and the hierarchy among them. They also describe the various navigation mechanisms and help orient the viewer to the current location within the proposed application. They suggest an optimized layout, but often do not dictate these constraints to a visual designer.

As wireframes have such a varied and diverse audience, both internal and client, the format within which they are developed has been an often-debated topic. Currently, there are two primary schools of thought on this issue. One touts Microsoft’s Visio, a diagramming program available on the market since 1991. The other firmly believes in HTML-based wireframes (also described as “high-fidelity prototypes”). While the two schools are not mutually exclusive, an individual IA tends to settle on a preferred method and work with it as much as possible.

(Author’s note: While there are other wireframing options such as Microsoft Power Point and Norpath Elements Studio, the two techniques described in this paper are the most often used. As the popularity of other techniques grows, their merits will need to be compared with the status quo.)

As design organizations (design shops, user experience groups within companies, etc.) mature, they inevitably run across the debate of Visio versus HTML wireframes. The decision for one over the other is never a clear-cut one since, as with all things IA-related, it depends. This article seeks to sort out the issues in this debate by describing the pros and cons of each technique and pointing out specific situations where one may be more effective than the other.

Pound for pound: The contenders weigh in

The greatest and most obvious benefit of HTML-based wireframes is their interactive nature. The web application can “come to life” in the form of these clickable wireframes. The development team has the opportunity to click through a mock-up of the site, allowing them to make quick determinations about issues with flow and navigation. The client has the opportunity to view an early version of the site and determine whether it is going to meet their business objectives, as well as whether they have the resources to populate all the proposed features with valuable content.

Sean Gallivan, creative director at Braun Consulting, notes, “Clients become engaged when they can interact with HTML wireframes. Clients not only enjoy the process more, but they also get a better contextual understanding of the features than with paper prototypes. This understanding gets earlier and more complete feedback.”

Visio, though a static diagramming program, has attributed its increased use in the web design community to its hyperlinking feature. Any element on any page can be hyperlinked to any other element or page within the document, to an external file, or URL. Additionally, Visio has the ability to export the entire wireframe deck to HTML, allowing developers and clients to click through a Visio wireframes set fairly easily.

Working with visual designers
HTML-based wireframes can cause some real problems in the development process. Most important is the issue of setting the client’s expectations about how the final application (or site) will appear. Wireframes, by their nature, do not dictate exact screen layout. They imply hierarchy between elements and suggest screen layout but, ultimately, it is the visual designer’s skill and talent that determines the final “look and feel.” By developing high-fidelity prototypes, the IA can inadvertently bind the designer into a screen layout that the client has seen in the wireframes. This can result in a less than optimal design and cause strain within the development team.

It is an often-held misconception that developing wireframes in HTML will allow the team to see what elements of the design end up “above the fold.” As wireframes are intended to show the skeleton of the application and not the full graphics-intensive version, making this determination based strictly on wireframe presentation is premature. Costly redesign decisions can be avoided by saving judgment on this issue until the visual designer has had a chance to exercise his/her skill.

The basic appearance and geometric nature of Visio diagrams help limit the client’s expectations as to the final layout and design of the application. By not having a mental picture of what the site will look like, the client can review the visual design in an objective manner. This leaves the creativity with the visual designer, as blocks and shapes representing specific page elements do not dictate a certain look and feel. The ability to quickly shift these elements around the screen also offers a flexibility not found with HTML wireframes. All of these elements combine to form the true essence of what wireframes should be: the skeleton of the application.

Client review
Often, a client likes to take deliverables with them for review when they leave the office. Even with today’s paperless trends, it is still very convenient to review wireframes on paper. This allows careful studying of the prototype without the exacerbated eyestrain caused by long-term monitor fixations. Also, writing notes directly on a specific wireframe is a convenient way to convey edits and suggestions. HTML wireframes do not print in a fashion that guarantees a complete wireframe will fit on one sheet of paper. Usually, the page breaks occur at random points and cut off content midstream, encumbering the review process.

As a diagramming program, Visio behaves within the context of printed “pages.” Because of this, designs can be constrained to one page or a deck of pages. Each page can be developed to contain the information for one screen of an application. This allows for easy presentation and review of wireframes. Pages are noted by either their name or number and follow a sequential order determined by the author.

Visio allows for clean, logical printing of the wireframes. Each page equals a screen. This allows clients, both external and internal, to print a wireframe deck and review it on the road, against the development environment or as a final QA assessment. Notes can be written directly on the printout and handed to an IA for modifications.

Exporting is another strength of Visio. While Visio does not exist on every desktop or in the Macintosh world, the myriad of formats that can be generated from it provide more than adequate coverage for any conceivable file format need. These formats range from HTML to PDF (with Adobe Acrobat Distiller) to EPS to JPG.

Using popular development tools such as Macromedia’s Dreamweaver, information architects have the ability to create site templates that function as shells for pages of similar type. These templates can be configured to contain a consistent area dedicated to screen-specific information. Elements such as screen title, version, author, page logic notes, and callouts can be listed in one convenient location. This section, however, can be very distracting when the prototype is used in a usability test. Removing this section would require recoding all the templates or creating a duplicate set of wireframes without it.

Templates also allow the IA to make global updates to various screens that share the same template. The main drawback here is that there is no way to create a global template. In a situation where a change needs to propagate throughout a site, each template must be updated to reflect the change. Occasionally, this problem can be solved using a global “find and replace” feature, but this is not always the case.

On the issue of maintenance, HTML files must be linked to each other in order to maintain their interactive strengths. This results in fixed filenames for each wireframe. As updates are made and versions updated, it is not possible to update the filenames with version numbers without adjusting the hyperlinks on every screen that links to it. Whether it’s for versioning or other reasons, a changed filename can become a tedious chore to update throughout an extensive wireframe set.

Performing some of the same duties as Dreamweaver’s templates, Visio additionally offers the concept of “layers,” which allows for templates to build on top of one another.

For example, the base layer can contain nothing but project information—project name, author name, file save date, copyright, etc. This layer can then be used as the background for another layer which could contain, for instance, global navigation elements. The benefits here are that each layer can be used individually or can build upon another layer. When a global change needs to be made, the appropriate layer is simply adjusted and the change is applied to all pages and layers using that layer as a background. There is no danger of editing the layers within each page as their elements are rendered uneditable.

Finally, as one becomes more expert with Visio and begins to use a consistent array of shapes and elements, a custom stencil can be created. This stencil allows all of the commonly-used elements to reside in one place throughout the design process. This provides a consistent palette for the IA to use when building similar applications (websites) and is a considerable timesaver.

User testing
The interactive nature of HTML wireframes increases the ease with which the site can be user tested. Participants have something with which they can interact in real “web time.” Micah Schwalb, Senior Information Architect at Braun Consulting, touches on this point by mentioning that, “By having low-fidelity mock-ups of the page built in HTML, we can quickly usability-test those models with our target population (or even people off the street) without having to spend the time to explain the concept of a paper prototype.” Transactional applications can benefit from this greatly, as test participants can give instant feedback on the process flow, and modifications can be made long before the project moves into the build phase. Specific implementations of features can also be tested to ensure the best mechanisms (drop-down menus, radio buttons, checkboxes, etc.) were selected.

The ability to export Visio decks into clickable image maps proves handy when performing early usability tests. Process flow and site navigation can be tested effectively, but Visio really shines when testing labels. Test participants often note the “lo-fi” nature of HTML’ized Visio wireframes and seem to focus primarily on labeling rather than specific content.

However, testing of Visio wireframes does not yield optimal usability testing results. The results that are collected need to be analyzed carefully and modifications need to be made cautiously because it is typically the flow and labeling that is being tested and not the entire user experience.

During the design process, it is often necessary to add descriptions to features with the use of notation. This notation bears direct relevance to a specific element on the wireframe and needs to be tied to it. HTML wireframes make it difficult to place notes at exact locations on the screen. While the actual “action” (e.g., drop-down menus) that HTML elements can portray solves this issue some of the time, there are other instances, such as length of text entry areas that need to be noted elsewhere. These notes would most likely be implemented in a “screen notes” section, where they lose their immediate connection to the item they describe.

Through the use of background layers in Visio, IAs can set aside a consistent area on each page dedicated to screen notes. This area remains constant and offers the same page logic elements described in the HTML discussion. Additionally, since there are no table-based constraints as there are in HTML, callouts and notes can be made directly on the diagram and visually tied directly to the element they are describing. For example, the contents of a drop-down menu can be clearly listed without the need for any further examination by using a callout tied to a drop-down element.

Proponents of HTML wireframes believe that, if developed according to company standards, the HTML can be reused to build the actual site. This would require the IA to have expert coding skills that take advantage of the latest developments and trends in coding such as XML, XHTML, and CSS. However, by building a high-fidelity prototype that is meant to be the codebase for the actual application, the IA has less room to experiment with various architectures and ideas as changes could alter code marked for reuse. Again, the “screen notes” section could not be implemented as it would not be part of the final application. This would relegate any supporting documentation to an external document which would then need to be compared with the prototype.

On a different process note, Visio has a tendency to appear as an extra step in the process during smaller projects and within smaller user experience groups. This can cause some pushback from the client questioning why this perceived “extra” step is being done. It is important to remember that, in a small-scale situation, developers often wear many hats, leading to the potential elimination of this step. However, in a more robust project, this step is critical in conveying the needs of the client along with the needs of the user to the engineering and design staff. It ensures that all elements are accounted for and provides a tangible record of what will be developed before coding begins.

Accessibility of HTML wireframes is a non-issue since all one needs to view them is a web browser. While the clean-printing nature of Visio is one of its strengths, viewing Visio files requires the user to have the program installed on their machine or to export the Visio deck into one of many formats, some of which can subsequently be viewed in a web browser.

Context of use
So when do HTML wireframes work well? There are several situations where this technique can really shine. Primarily, HTML wireframes work well on smaller projects and internal projects. Projects that require minimal visual design or adhere to a corporate intranet standard can benefit from this technique as it will speed up delivery. Data-heavy designs with high information density can be better illustrated using HTML wireframes, and they allow developers to see flow and density issues early in the project lifecycle. They can also be used in conjunction with other types of wireframes to illustrate a particularly complex transactional process. Finally, HTML wireframes can aid resourcing crunches, especially if the user experience group is small or their resources are limited. One multi-skilled IA can often handle developing wireframes and site authoring, combining the two tasks into one.

Visio’s true merits surface in robust projects with a large screen count. It can efficiently and effectively convey the implementation of complex features and illustrate the flow of transactional components. When “webifying” an existing thick client, Visio is an excellent intermediate step when attempting to translate features into an HTML-based environment. It simplifies the review process for clients, allowing them the freedom to work at their convenience, while offering clear and concise design information. It is also well-suited for brand-intensive engagements in which the visual designer needs to exert more control.


The constant demand to produce a quality online experience drives us to create better processes for its development. This article discussed two techniques widely used in creating wireframes for web applications. While each has its own merits and drawbacks, it is the IA’s specific situation that dictates which one to use. As user experience groups grow larger within organizations, they begin to add refinement steps to their processes in an effort to add value to their deliverables. It seems that the bigger the UE group is, the more likely it is to tout the benefits of finely detailed, meticulous design. For this type of design, Visio seems to fit the bill more appropriately with its capabilities of detailed notation, clean translation to paper, and ability to create “layers.” In a smaller or more rapid-paced situation, the multi-faceted IA can make great strides by creating high-fidelity prototypes in HTML. Which technique is best for your current needs? The answer is, as always, it depends.

Jeff Gothelf is a Senior Information Architect at Braun Consulting’s Boston office. He has been practicing web design and information architecture since the mid-90s in the Mid-Atlantic and New England regions. His career has spanned a multitude of industries including retail, financial services, and pharmaceutical. While the majority of his work has focused on the web and its many applications, his ultimate goal in life is to create the world’s most beautiful and usable toaster (one that would make Don Norman proud). When he’s not playing music he keeps tabs of his thoughts at Scattered, Smothered and Covered.

HTML Wireframes and Prototypes: All Gain and No Pain

Written by: Julie Stanford
“Using HTML as the basis for your wireframing and prototyping can be a quick and rewarding experience with fabulous benefits, including easier user testing, improved client communication, and faster, more effective use of design time.”

Mention the use of HTML for wireframing or prototyping, and some information architects and interaction designers frantically look for the nearest exit. In some circles, HTML has acquired the reputation of being a time-consuming, difficult undertaking best left to developers. I’m here to convince you that this is very far from the truth. In fact, using HTML as the basis for your wireframing and prototyping can be a quick and rewarding experience with fabulous benefits, including easier user testing, improved client communication, and faster, more effective use of design time. As a matter of fact, at Sliced Bread Design, Dreamweaver is the ONLY tool we use for our wireframes, and we love it. For those of you who may stop right now because you don’t know how to do HTML, let’s first discuss why you would want to use it. Then, read the HTML Wireframing Primer to find out how to do it yourself.

What people are using now
Henri Olson of recently conducted a survey of 52 people to understand their use of web prototyping tools. He found that only 28.3 percent of interaction designers surveyed use HTML tools such as Dreamweaver or FrontPage for prototyping. The rest use visual and diagramming tools such as Visio, Illustrator, PowerPoint, or paper. While I am happily surprised by the quarter of designers using HTML tools, I am still left wondering why more people don’t take advantage of the benefits of HTML. In fact, the survey found that over 67 percent of HTML prototypers agree with the sentence: “I’m perfectly happy with the prototyping tool I’m using.” And, in a question that measures how well their current prototyping tool lives up to their functionality requirements, prototypers agreed that HTML tools came out with the highest overall score. This compares to only 8 percent of diagramming tool (i.e. Visio) users and 50 percent of graphic design tool (i.e. Illustrator, Photoshop) users who are perfectly happy with their tool. So the question is, if HTML is so great for design, why aren’t more people using it?

There are many different definitions of wireframes, prototypes, and visual design, so let’s start by defining how these terms will be used in this article. A wireframe is a grayscale block diagram that illustrates the overall navigation and the blocks of elements such as content, functionality, etc. that will go on the screen. It does not contain pictures and doesn’t necessarily need to link to anything. It just demonstrates what elements a web page or application screen will contain and roughly where they might go—although the location can change. It does not include visual design. An HTML wireframe is created in HTML using a program such as Dreamweaver. A flat wireframe is created using a program such as Visio, Illustrator, or Photoshop and does not have interactive components, but is a flat image of the elements on the screen.

What I call an interactive HTML prototype goes a step further by linking navigation on an HTML wireframe to other wireframes representing subsequent screens, filling in content as needed, and adding mock functionality such as drop-down menus and fields that don’t tie into any backend. Note that this sort of prototype is somewhere between high- and low-fidelity as defined by Chris Farnum in his recent Boxes and Arrows article. This prototype does not represent any visual design other than simple layout. It does not require enlisting the help of a developer because the interaction designer does all of the work in a program such as Dreamweaver.

The screen shot below shows one page of this sort of prototype. Notice that it shows that the design will have primary navigation with four categories (Dashboard, Database Setup, etc…), secondary navigation that integrates the steps of a wizard with navigation (an idea we were testing), a form to fill out in the middle that a user can try out, and navigation at the bottom that might be buttons or links when the design is complete.

By linking together multiple pages of HTML wireframes for a site or an application, you can quickly end up with a prototype to user test or show the client. For the purposes of this article, when I use the term “wireframe,” I am referring to an HTML wireframe and will use the term “flat wireframe” to refer specifically to wireframes not in HTML.

Why avoid HTML?
I’ve heard many reasons why designers don’t want to use HTML for wireframing and prototyping. The most common reason they are reluctant to use HTML is because they are already comfortable with tools such as Illustrator and Visio. I’ve heard people say, “Making HTML really work is difficult” or “I don’t know JavaScript.” To combat these concerns about ease of use, the accompanying HTML Prototyping Primer article teaches you how to create quick, functional, flexible wireframes without any real programming by using Dreamweaver. But the flexibility and functionality of Dreamweaver is not the main reason to switch to HTML. Let’s go on a short tour of the benefits of HTML wireframing and prototyping that will convince you to make the switch.

Increased user testing
The most important interaction design benefit of HTML is the way it lends itself to ongoing user testing. Because of their interactivity, HTML wireframes are regularly used to user test design ideas on the fly with people in the office, friends, or anyone who happens to stop by. When there is no one around to show, we post designs to the web and instant message a friend to try them out – we always get some quick, useful feedback. For example, Sliced Bread Design recently worked with a company called Elevon on a new version of their enterprise budgeting software. From the beginning, the client had many different ideas for the flow of the set-up wizard. Some parts of the set up had to be done in a specific order, while other tasks could be done at the user’s convenience. We approached these different aspects of the functionality by creating a list of tasks involved in the set up, and disabling the tasks that could not yet be started (see Figure 2 below). Then, we quickly user tested the wireframe with people in the office to see if they understood the interaction idea. After validating the base design, it was ready to show to the client.

When everyone is satisfied with a wireframe, like the one above, we can then link all the screens together into a wireframe prototype and conduct more formal usability testing without having to do additional set up work. Of course, for formal usability testing we still have to create a script for the tasks that we need to test. Your prototype might need more or less modification to fully cover those areas you need to test. However, we’ve found that our wireframe prototypes convert to user test material with minimal effort because the framework for every page is already in place and is very flexible. Above all, our reliance on HTML wireframing lets us promise all of our clients that the final design will ALWAYS be user tested, even if only via guerrilla user testing – especially important if the budget is tight.

Creating visible client value from the start
Another big benefit of HTML is visible value for the client at the beginning of the project. Some of our clients are confused about the difference between interaction and visual design. By focusing on creating something interactive at the beginning of the project in the form of an HTML wireframe, we can demonstrate that the focus of our work will be on how people use the product as opposed to how it looks. And, as we are busy showing off our knowledge of interactivity, we are also demonstrating our awareness of technical constraints. Even if your wireframe is based on the simplest HTML out there (ours always are) and only takes 10 minutes to create, the fact that you have ventured out of the realm of graphics software demonstrates your concern with creating something that is implementable, not just a blue-sky concept.

Improved client communication
When it’s time to show the work to the client and demonstrate its value, the next benefit of HTML becomes improved client communication. Sometimes it may be difficult for a client to understand the brilliance of the user experience that is being proposed because they cannot experience it for themselves. Miscommunication can result from misunderstood verbal descriptions of how users will interact with a flat prototype. We experienced this on a project where client team members were located on multiple continents and had varying English skills. By demonstrating the functionality instead of describing it, we were able to greatly reduce miscommunication that initially resulted from teleconferences and documents in rough English. Furthermore, team members in different time zones could review designs that we posted on their own time without additional explanation. By allowing our client to experience the interaction, we knew that they understood exactly what we were talking about and had agreed with the direction we were heading early on in the process.

Communication through demonstration is especially important when the project does not have a pre-defined functional specification, i.e., a definitive list of the functionality and/or content areas that the product must have. For example, on the Elevon project, we were hired at the beginning of the project to help replace old desktop client server software with a shiny new web application. At this stage, there was no specification, so our work played an integral part in helping define the product’s functionality. By creating interactive wireframes that represented the functionality under discussion, we were able to quickly reach agreement on what worked best for the end users. Furthermore, everyone could click through the wireframe prototype to make sure that all the pieces were in there, and any functionality that had been casually discussed wasn’t getting lost. The Elevon team also used the prototype to reach internal consensus and demonstrate the project’s progress to management.

Disqualifying poor ideas
Another client communication benefit becomes apparent when your client suggests some interaction scheme that they are sure will work, and you are sure won’t. If a gentle suggestion to steer the client in the other direction doesn’t work, we’ve found that creating an HTML wireframe to demonstrate the problems of the proposed interaction is much more convincing than further discussion. Often experiencing an idea is very different from describing it. And, since the idea is now prototyped, it can easily be user tested if you need more ammunition to disqualify it.

Simplified implementation
If I haven’t yet convinced you of the benefits of HTML prototyping, perhaps this point will: return on investment (ROI). These days, everyone is chatting about the hot topic of ROI. By emphasizing your use of HTML to the client, you can also make legitimate claims about decreased development costs through more consistent implementation and quicker specification. We use our HTML prototypes directly in our specification to communicate to developers exactly how the final product needs to work. More complex functionality, not in the prototype, is explained via bullet points under the screen itself. Although the prototype lacks the final graphic design, it demonstrates the functionality and the flow, leaving little room for developer confusion, which in turn saves time during the development cycle. Furthermore, your client saves money because your time isn’t spent explaining every detail in a text heavy specification.

Upsell to marketing
And finally, the last client benefit is actually a potential follow-up project for you. Since you saved the client money in specification, you can now spend it by selling them a robust version of the prototype. Well-crafted HTML prototypes can easily be turned into marketing prototypes once the visual design is complete. Many projects that we’ve worked on take a long time to implement, but inevitably the marketing team always needs something to show next month at the big conference. Voila! With an existing prototype, it is easy to apply the final visuals for your client to show their customers before the final project is complete. Everybody wins.

HTML is for more than just the Web
Hopefully, now that I’ve sold you on HTML prototyping, the important thing to note is that HTML wireframing and prototyping is for more than just web projects. In the past, we have used HTML prototyping for both desktop and cell phone applications. For example, through the use of screen shots and some carefully placed web layers, we were able to create an interactive prototype of a Windows file management system. On another project, we prototyped in WAP (roughly HTML for cell phones) using a Dreamweaver plug-in. By creating a mobile phone interface to user test, we were able to capture interaction problems before we presented the ideas to the client. Once you get hooked on HTML wireframing and prototyping, you really can’t go back.

OK, I’m ready. What do I do next?
Read the HTML Prototyping Primer for concrete instructions that will make you more comfortable with Dreamweaver. Although it might be hard to abandon what you are used to and get turned on to HTML, hopefully, I have emphasized that in today’s tight economy, the benefits are well worth it.

  • Results from a survey of web prototyping tools usage
  • What an IA Should Know About Prototypes for User Testing by Chris Farnum
  • Definitions used in this article:
    Wireframe: a grayscale block diagram that illustrates the overall navigation and blocks of elements
    HTML wireframe: wireframe created in HTML using a program such as Dreamweaver
    Flat wireframe: wireframe created in graphics program such as Illustrator, diagramming programs such as Visio, or on paper
    HTML prototype: HTML wireframes with actual content and interaction components filled in that are linked together to form a rough interaction

Julie Stanford has been a practicing experience designer since 1996 and is a partner at Sliced Bread Design, an interaction design and usability agency. Through her work at Sliced Bread, Julie has specialized in designing complex online, wireless, and voice applications for clients such as Elevon, Tellme, Agilent, and Casio.

Dreamweaver Primer

Written by: Julie Stanford
“I recommend Dreamweaver for wireframing and prototyping because it is easy to learn, offers palettes with all the necessary interface widgets, and has built-in project management tools like source control, which is useful if you are working with a team.”So, you’ve read the article, “HTML Wireframes and Prototypes: All Gain and No Pain” and now want you want to make an HTML wireframe. I’m here to help make this an easy and pain-free process, using Macromedia Dreamweaver 4.0.

By the end of this primer you will have:

  • Become familiar with the basic functionality of Dreamweaver
  • Made a sample HTML wireframe that you can use as a template for future wireframes

How to use this primer
This primer assumes that you have never used Dreamweaver before. Although there are many HTML editing applications out there, I recommend Dreamweaver for wireframing and prototyping because it is easy to learn, offers palettes with all the necessary interface widgets, and has built-in project management tools like source control, which is useful if you are working with a team. If you are already familiar with Dreamweaver, you can skip the Dreamweaver Basics section and go right to the “Let’s start wireframing” section.

Also, this primer is designed to be used while you are running Dreamweaver. The instructions are accompanied by illustrations and examples so you can try the techniques in Dreamweaver as you read along.

Finally, the techniques suggested in this primer are specifically for creating wireframe prototypes, not for creating launchable sites with working backends. As a matter of fact, many of the techniques here would probably make a web developer’s hair stand on end—they do not produce implementable code. However, since the goal is to communicate design concepts, not to implement a site, it is okay to take shortcuts where possible. Working faster facilitates easy iteration and the creation of many different design ideas.

Dreamweaver basics
When you launch Dreamweaver, it will open a blank web page called “Untitled Document.” This default Dreamweaver document window is divided into 5 horizontal sections. These sections, and the most useful buttons in the window, are labeled in Figure 1. Since we will be doing all of our work in the design view area of the window, you can close the code view area by clicking the design view button in the toolbar.

Figure 1: The default Dreamweaver document window and its key functionality.
Click the design view button to hide the code view area.

Now for a tour of the tools that are available for your wireframing work. Dreamweaver provides access to tools via floating palettes, which you can display by choosing them from the Window menu. The palettes that are the most useful for wireframing are Objects, Properties, and Styles.

Objects palette
The Objects palette offers most of the visual elements that we will add to the wireframe. When you click an item in the Objects palette, Dreamweaver places that object where you last clicked in the document.

Figure 2: The Objects palette showing Common objects, Character objects, and Forms objects.

At the top of the Objects palette is the Category drop-down menu, which lets you control which object types appear in the palette. For wireframing, we will primarily use the Common, Character, and Forms object categories. Figure 2 shows how the Objects palette looks with each of these three categories selected and labels the most useful items in each set.

Expanding the Properties palette
Often, the bottom portion of the Properties palette is not displayed when you open it. This portion contains useful properties that you don’t want to miss! To expand the palette, click the small white arrow in the bottom right corner of the Properties palette. If the arrow is pointing up, you know that the palette is expanded and you are seeing all of the properties.

Properties palette
Each object that you insert into your document has a set of properties associated with it, which you can view and modify in the Properties palette. When you select an object, its properties appear in this palette. For example, Figure 3 shows the properties for some text in a table cell. The top portion of the palette governs the properties of the text, while the bottom portion controls the properties of the table cell.

You can use the Properties palette to format text, add links, specify background colors, indentation, and alignment, create lists, and so on. For example, you can create a link by selecting a block of text and entering the URL in the Link field. When a table is selected, the Properties palette is useful for specifying the size of the table or the number of rows and columns in it.
Figure 3: The Properties palette when text in a table cell is selected in the document window.

Table cell property definitions
Cell spacing: This is the number of pixels that Dreamweaver puts outside each table cell and around the table as a whole. For example, specifying a cell spacing value of 2 pixels puts 2 pixels between each cell and a 2-pixel invisible border around the entire table.

Cell padding: This is the number of pixels that Dreamweaver uses to pad the inside of a table cell. To remember the difference between padding and spacing, I think of the padding on the walls inside a cell at an asylum.

CSS Styles palette
The CSS Styles palette is used for setting up the CSS (Cascading Style Sheet) styles that will govern your wireframe. A style is a description of the formatting properties that you apply to text or a table cell, including things like font color and size, background color, etc. Styles are useful for ensuring that all of the wireframes you create look consistent. If you have ever used styles in Microsoft Word, CSS styles work in much the same way.

Figure 4 shows a CSS Styles palette with the various styles I used for the example wireframe in this primer. The most important command to remember when using the CSS Styles palette is New Style, the button for which is available at the bottom right of the palette.

Figure 4: The CSS styles palette.

Other palettes
Other useful (but slightly more advanced) palettes for wireframing are the Behaviors and Layers palettes. While we will not explore their functionality in this article, I encourage you to try these palettes once you are comfortable with Dreamweaver. They offer tools to help you do things like produce pop-up windows and have page elements dynamically appear or disappear.

Let’s start wireframing
Now that you know the basics of what is available to you in Dreamweaver, let’s put together a wireframe. For this example, I will walk you through the steps to create a wireframe for an inside page of a website about dogs. When we are done, the Dreamweaver document for the wireframe that you have created will look like this:

Figure 5: The finished wireframe for a dog website as it will look in Dreamweaver. Click to enlarge.

In a browser window, the finished wireframe will look like this:

Figure 6: The finished wireframe as it will look in a web browser. Click to enlarge.

You can download this finished wireframe as a basis for your own work here.

Now, let’s get started.

Step 1: Define a site

NOTE: If you are going to put all of the files or documents related to a project in subfolders that are contained within a main folder, you should select that main folder here, not just the wireframe folder. That way, if you put the HTML files in one folder and the images in another and the site maps in a third, then Dreamweaver site management can help you manage them all.

The first thing you should do when beginning a new wireframing project in Dreamweaver is “define a site.” When you define a site, Dreamweaver groups all of the wireframes for the site together into a single project, which allows for easy updating of links when you move pages around, and, if you are working with a team, source control.

To define a site:

  1. Select “New site” in the Site menu, which will open a dialog box.
  2. Enter the name of the site and select the root folder where you will save the wireframes for the project. If you will be sharing these documents on a server, select the “Remote info” category on the left side of the dialog box and choose how you will access these files in the Access drop-down menu.
  3. If necessary, enable source control after you select an access type. Source control facilitates file sharing by checking files in and out.
  4. You can ignore the other options in the dialog. Click OK to close it.

After you close the dialog, you will see the Dreamweaver site window, which works similar to Windows Explorer or the Mac OS Finder for accessing your site files. For now, we’ll ignore this window and move on to Step 2.

Step 2: Set up your document work space

  1. Go to the Untitled Document that Dreamweaver launched on start-up and save it with an appropriate name.
  2. If they are not already open, open the Objects, Properties, and CSS Styles palettes by selecting them from the Window menu.

Step 3: Set up your basic wireframe layout
Every HTML wireframe consists of tables that make up the basic layout of the page. Usually, I create separate tables for the top global area (including the logo), primary navigation, secondary navigation (if it is horizontal), and the content area. Also, I always make the tables 760 pixels wide, assuming a minimum 800 x 600 screen resolution. To set up tables in general:

  1. In the Objects palette (Common category), click the Table button to insert a table. This will open a table dialog box.
  2. Enter the necessary properties for the table and click OK.
  3. Click to the right of the new table to deselect it, then press Enter to position your cursor for insertion of the next table.
  4. Follow steps 1-3 to insert the rest of the tables.

Now, let’s work from the top down to set up these four basic tables. Select a table and, in the Properties palette, enter the following table properties:

  • Global area table (for the logo and search and help links): 1 row, 2 columns, width = 760 pixels, border = 0, cell padding = 0, cell spacing = 0
  • Primary navigation table: 1 row, 5 columns (for the five primary navigation categories), width = 760 pixels, border = 0, cell padding = 0, cell spacing = 3
  • Secondary navigation table: 1 row, 8 columns (for the eight secondary navigation categories), width = 760 pixels, border = 0, cell padding = 0, cell spacing = 0
  • Content area table: 2 rows, 1 column, width = 760 pixels, border = 0, cell padding = 4, cell spacing = 3

When you are done, your Dreamweaver document should look like this (without the table names marked in blue):

Figure 7: Dreamweaver window with the four basic layout tables. Click to enlarge.

Step 4: Set up the primary navigation
Once you have set up your basic table layout, you can fill in the primary navigation elements. To format the navigation area, let’s create our first style in the CSS Styles palette:

  1. Click the “New style” button at the bottom of the palette. This will open a dialog box.
  2. Enter the style name .primaryNav_unselected. Click OK.
  3. Since this is your first style, Dreamweaver will open another dialog box asking you to name your new style sheet. All of the styles that you create will be associated with this style sheet. Name your style sheet and press Enter.
  4. This will open the edit style dialog box in which you can specify the format of your new .primaryNav_unselected style.
  5. Select Verdana font, size 12.
  6. Click the Background category (on the left side of the dialog), then select light gray (#CCCCCC) as the background color.
  7. Click OK.

Congratulations! You have created your first style. Creating additional styles should be easy. Now let’s apply this new format to the primary navigation table that you created and fill in the table with the navigation categories:

  1. Select the entire primary navigation table.
  2. Click the .primaryNav_unselected style you just created in the CSS Styles palette. This should make the entire table gray.
  3. With the primary navigation cells selected, apply the rest of the formatting by entering the following options in the Properties palette: text justification = center, horizontal alignment = center, vertical alignment = middle, height = 25 width = 152.
  4. In each cell of the primary navigation table, type in one of the primary navigation categories: Home, Breeds, Buying a dog, Training, and Health.
  5. Create fake hyperlinks for each of the primary navigation items by selecting the category name and entering “#” in the Link field of the Properties palette.
  6. Create the selected state for the primary navigation by making a .primaryNav_selected style in the styles palette with these properties: Verdana size 12, type color = burgundy (#663300), background color = medium gray (#999999).
  7. Select the cell that contains “Breeds” and apply the primaryNav_selected style to that cell.
  8. Select the “Breeds” text and apply the primaryNav_selected style to the text.

At this point, your document window should look like this:

Figure 8: The Dreamweaver document showing the complete primary navigation table. Click to enlarge.

Step 6: Format the rest of your navigation elements

Special Tip: Tag Selector
At the bottom of the document is an area called the Tag Selector (marked in blue in Figure 8). This area shows what HTML tags are applied to the currently selected element of the page. For example, in Figure 8, the selected text is located within a <div> tag, which is within a table cell (<td>), which is within a table row (<tr>), which is within a table (<table>), which is within the body of the document. Click a tag to select it and all of its content and then apply a style to your selection. The Tag Selector also shows what style is currently applied to an item. For example, the <td> cell in Figure 8 is displayed as <td.primaryNav_selected> to indicate that the .primaryNav_selected style has been applied to that cell.

Format the remainder of the tables, including the secondary navigation table and the background color of the content area table, by repeating the basic process described above. To facilitate the formatting of your wireframe, I have created a style sheet with all the styles you’ll need; you can download it here. To attach this style sheet to your document, save it in the same folder as your wireframes, then from the Text menu in Dreamweaver, select CSS styles >Attach Style Sheet. This will display a dialog box that asks you to select the style sheet to attach. Choose the one in your project folder and you are in business.

Note: The rest of this primer assumes that you have downloaded and attached this style sheet.

Step 7: Add the search tools
For this example, we are creating a wireframe for the inside page of a dog site. Specifically, this wireframe lists all of the breeds of herding dogs and lets you search through them. To add the search tool to the page:

  1. In the first row of the content area table, type in the page title “Herding dog breeds” and apply the page_title style to it.
  2. In the second row of the content area table, type in the instructions for the search (“Search for dogs with desired characteristics:”) and apply the body_text style to it.
  3. Below the instructional text, insert a new table to house the search fields: 1 row, 7 columns, width = 100%, border=0, cell padding=3, cell spacing=0. Each search field and label will go in a separate cell of the table.
  4. Enter the name of the first label for the search (“Size”) and apply the field_label style to it.

Now, let’s add a multiple-select box for the Size options in the second column of the search tool table. Since Dreamweaver does not automatically create multiple-select boxes, we’ll need to make one from scratch:

  1. Create a small table: width=100 pixels, 1 row, 2 columns, border=1, cell padding=0, cell spacing=0.
  2. Use the Properties palette to set the border color of the table to gray.
  3. In the left cell of the table, insert checkboxes from the Objects palette and add a label for each checkbox.
  4. For the right side of the multiple-select box, take a screen shot of a scroll bar and edit it to the proper size in Dreamweaver (in this case, 60 pixels tall), or download one here. Place the scroll bar in your table by clicking the Insert Image button in the Properties palette.

Next, add the Exercise drop-down menu:

  1. In the next column of the search tool table, type “Exercise” and apply the field_label style to it.
  2. In the Objects palette, select the Forms category and click the Insert List/Menu button.
  3. With your new drop-down menu selected, click the List value button in the Properties palette. This will open a dialog box.
  4. Enter a label for each item in the drop-down menu (i.e., ”don’t care,” ”low,” “medium,” “high,” “very high”). You can ignore the Value field.

Add the Shedding radio buttons and the Search button:

  1. In the next column, type “Shedding” and apply the field_label style to it.
  2. In the Objects palette, with the Forms category selected, click Insert Radio Button twice to insert two radio buttons.
  3. Add labels to the radio buttons and apply the body_text style to them.
  4. Click Insert Button again to place the Search button on your page.

Step 8: Add the table of breed details
Now, let’s create the table of dog information.

  1. Type in the label for the table: “Displaying: 1-10 of 150 dogs.” Apply the table_label style to it.
  2. Directly under the label, insert a new table: 11 rows, 6 columns, width = 100 %, border = 1, cell padding = 3, cell spacing = 0
  3. With the new table selected, choose a light gray border color for the table in the Properties Palette.
  4. Fill in the contents of the table, using the table_header style for the column headers and the table_content style for the cell content.

Step 9: Apply the finishing touches

  1. Add the page counter (“Page 1 of 15”) and the “Next >” link for accessing subsequent pages of the site (use “#” for the link again).
  2. In the global area table, put a logo placeholder in the left column and links to search and help in the right column.

Voila! You are done!
Creating this wireframe should have taken you between 30-60 minutes. In the future this should go even quicker because you can reuse the basic elements you’ve already set up.

Finally, the following is a list of tips and reminders to help you tackle more wireframing situations with ease:

  • Reuse and recycle! Once you have made one wireframe, there is no reason to ever start from scratch. You can download the wireframe created in this primer here and use it, or create your own.
  • Use “#” for URLs to create placeholder links that won’t cause “file not found” errors when you click them. Once you have created wireframes for other pages on your site, you can replace the #s with links to those pages to make an interactive prototype.
  • Use cell padding and spacing to create margins between table columns and cells.
  • In general, specify the size of main tables in pixels; specify the size of tables within other tables in percent.
  • Dreamweaver does not make it easy to make multiple-select boxes, so I walked you through making one above. It is easy to fake other functionality not provided by Dreamweaver through clever use of screen shots.
  • Much of the functionality described above is also accessible by right-clicking (option-clicking on a Mac) on an element to bring up its contextual menu. For example, right-clicking inside a table will display a table edit menu for adding and deleting columns and formatting text.

Julie Stanford has been a practicing experience designer since 1996 and is a partner at Sliced Bread Design, an interaction design and usability agency. Through her work at Sliced Bread, Julie has specialized in designing complex online, wireless, and voice applications for clients such as Elevon, Tellme, Agilent, and Casio.

Defining Feature Sets Through Prototyping

Written by: Laura S. Quinn
The Vision Prototype allows the user-centered vision to be seen—and discussed—by all team members.Over the last couple of years, a standard method for user-centered interaction design has begun to emerge. First, you gather background from the clients and stakeholders, conduct user research, and look at competitive sites. Then you build personas and scenarios, do workshops, and conduct brainstorming sessions. All of that is analyzed down into a grand vision of what should be built.

But what happens after that? Most of the literature in this area assumes that once the designer has a vision in mind, it’s time to move straight into sitemaps and wireframes and the rest of the business of functional design. But I’ve never seen it actually work that way. In my experience, there are always clients who need to approve the vision, scope that needs to be defined, and project managers who want detailed and concrete functional requirements from which to manage. If I’m not involved, they’ll do it without me, often leaving me with a scope and a set of requirements that doesn’t have much to do with the vision with which I started.

To address this issue, over the years I’ve put together a method to translate a conceptual vision into a set of concrete functional requirements, by way of what I call a Vision Prototype. The Vision Prototype allows the user-centered vision to be seen—and discussed—by all team members. Because the prototype serves as an explicit visual representation of the project’s needs, it can be easily translated into a set of functional requirements.

What is a vision?
This method assumes that a vision has already been defined in someone’s mind, using one of several user-centered interaction design techniques (see “For More Information” below). The vision doesn’t need to be extremely detailed, but it should answer these basic questions:

  • What’s the purpose of the site?
  • What are the main things the users will do with the site?
  • What’s the general conceptual structure?

Let’s look at an example of a high-level vision. Let’s say I’m building a website that allows Quinn Exhibition, an imaginary trade show company, to sell booth space online. In my—fictitious—user research, I observed that the floor plan for the exhibition was critical in everyone’s thought process in determining everything from number of booths to the position of a competitor’s booth. Typically, sales reps fax annotated floor plans to potential purchasers and buyers show them to their bosses.

Based on this data (and backed up by my fictitious competitor research, personas, scenarios, and workshops), my vision for the website is to use a visual floor plan as a key interface metaphor. Potential clients can see what booths are available and where booths are located by perusing a familiar floor plan format. They should be able to buy straight from the floor plan.

Documenting the vision
It’s not easy to jump from a vision in your head to a list of concrete functional requirements, and it’s not desirable, for a number of reasons. At the most basic level, creating formal documentation of a vision ensures that a vision does in fact exist. While this sounds obvious, it’s a problem that I’ve seen frequently, especially in more traditional software development processes. It’s easy to build a requirements document by piecing together what everyone says they want without any overarching idea of where the system as a whole is going. Needless to say, this often results in sites that are less than cohesive.

A visual representation also makes the vision tangible and understandable to clients, users, and the rest of the project team. This makes it possible to get feedback in this early phase and serves as a touch-point for the rest of the project. When scope creep begins, it’s possible to say “Is that feature really important to what we’ve defined?”—with some assurance that others on the team will share your view of what was decided.

This is where the prototype comes in. I’ve had great success in documenting an ideal vision with a conceptual prototype which, in anywhere from four to ten linked pages, shows the high-level functionality and conceptual structure of the site. I’ve found that this type of Vision Prototype is both easy to create and easy to understand.

The prototype is built not to show the interface, the page flow, or the fields, but to represent an ideal feature set that makes the vision happen. For instance, I’ll often represent site functionality with a number of significantly labeled buttons (i.e., “Add New Location” or “Advanced Search”). These buttons serve as functionality shorthand—there’s no need to show an Advanced Search page in the prototype if the team will understand what a button labeled “Advanced Search” implies.

Because the prototype is primarily documenting an intended (or ideal) feature set, I carefully determine the right level of detail and functional feasibility. I try to represent the site functionality to just the necessary level of detail to allow an engineer to estimate the approximate time and money needed to create each feature. This means representing some specifics (especially for a more unusual feature), but certainly not every field on every page. I also go to some effort to ensure that the prototype feature set is ”blue sky” enough to be inspiring without being completely infeasible for the time and money. I generally think of the prototype as representing the feature set of the site two or three phases down the road.

The illustration shows two pages—a Floor Plan and a Booth Detail page—out of a Vision Prototype for the example website. The pages use both an interface-like structure and suggestive buttons (“Search All Available Booths,” “Split this Booth into Two”) to show the feature set. The prototype would include a few pages in addition to this: an overview or homepage, a static content template (to show that the content links are just pages of text), and perhaps the Buy Booth page itself.

When scope creep begins, it’s possible to say “Is that feature really important to what we’ve defined?”—with some assurance that others on the team will share your view of what was decided.A prototype this early? Are you nuts?
It’s worth pausing here to acknowledge that the idea of building a prototype before even defining scope alarms many reasonable and experienced interaction designers. I’ve heard two different but related arguments as to why it’s a bad idea:

  • Argument 1: Functional requirements by definition should talk about needs and specifically avoid any consideration of design like conceptual structure or specific features. Something as tangible as a prototype should come after the definition of requirements, to ensure that all the issues and parameters are considered before jumping to a design solution.
  • Argument 2: Clients aren’t able to separate a conceptual prototype from an interface design or a live website. They’ll focus on the wrong details (like the page flow or graphic design), fixate on a particular detail that will turn out to be infeasible, or just generally misunderstand the intent of the prototype.

Both of these arguments are rooted in the same premise that it’s preferable to first work at a fairly abstract level to define the scope and needs of the project before looking at a visual representation that might start to limit the field of design possibilities or encourage people to determine how things should be implemented as opposed to solely what the system should do.

While this premise makes sense in an ideal world, I believe that it simply doesn’t work in the vast majority of project situations. Information architects are comfortable working in the realm of abstract functionality (that’s one reason why we’re hired), but clients generally are not. In the same way that we wouldn’t show a user a text list of features and expect to get good data about the usefulness of the system, we can’t expect a client to be able to adequately give feedback on a high-level description of functionality.

By creating a visual representation of the project vision early, we give up a little to get a lot. We give up tight control of precisely what the client will be thinking about at each phase of the project. This can sometimes result in early discussions about things, such as page flow or graphic design, that are unrelated to the decisions at hand (by the way, I’ve seen this type of thing get somewhat irritating on a project, but I’ve never seen it cause any lasting harm). But by giving this up we gain a huge advantage: we gain the active understanding, participation and buy-in of our clients. Ultimately, ensuring our clients can effectively understand, review, and discuss important project concepts will result in better products and fewer problematic misunderstandings down the road.

Does it have to be a prototype?
That being said, a Vision Prototype may not be appropriate for every project. I’ve found that a prototype is particularly good at representing highly complex functional sites. For this type of site, it can represent a lot of complexity in a format that makes it easy to review and understand. In addition, prototypes are familiar to the many companies who already use them as a standard to get buy-in on a project.

For smaller projects, however, I’ve found that it’s difficult to build a conceptual prototype without detailing every field, simply because there’s not that much to say about the site vision. A prototype also may not effectively handle the structural issues of a content intensive site. For this type of site, the prototype can be replaced by anything that’s tangible, non-technical, and fairly comprehensive—perhaps a content map, a comprehensive set of scenarios, or a page flow (when there’s not a lot of complexity in the page flow itself).

Verifying and getting buy-in on the vision
One of the main reasons to create a Vision Prototype is to allow the rest of the project team and the client to understand, review, and provide feedback on the vision. Because the prototype makes the ideas under discussion visible and concrete, it’s common for new needs or concerns to come up at this point—even in areas that might have been completely covered in previous conversations. It’s simply hard for many people to think abstractly about the same things that are made obvious by the prototype.

User focus groups can also be useful at this point. A successful vision will generally get a “Of course, how else would you do it?” response, with some suggestions for minor additional features. Confusion, lots of questions, or lots of suggestions for major new features are all signs that the vision does not correspond with the users’ expectations and model of the system, and needs to be reconsidered.

At this point we resolve any issues, and ensure that the whole team is happy with the prototype before moving forward. In this way, the prototype becomes the documentation of the entire team’s vision.

Creating a functional requirements document
Because the Vision Prototype contains a comprehensive look at ideal functionality, iterated and approved, it is itself a representation of the functional requirements. In order to translate these ideas into a more traditional document, one can simply systematically write down the functionality shown on each page. It’s also important to think through any administrative or tangential features (user administration, for instance).

For instance, looking at the Quinn Exhibition prototype, I can pull the following functional requirements (among others) from the Floor Plan page:

  • The position of each booth is displayed on a visual floor plan.
  • All hall infrastructure is displayed on the floor plan.
  • The status of a booth (occupied or available) is displayed on the floor plan.
  • Booth details, such as the size and the occupant, can be easily seen on or linked to the floor plan.
  • The user can search for a booth based on key booth criteria.
  • An administrator can define the hall infrastructure and initial booth layout for an exhibition.

Note that there’s a great deal of work left to do to completely define the functionality. What criteria can be used to perform a booth search? How does the administrator define the original floor plan? The point of this functional requirements document is not to completely design the site or define all business rules, but to establish the functionality to the point that the site can be estimated.

I put each requirement on a separate line in an Excel spreadsheet, and prioritize each based on my user research findings and client priorities. I generally use Core, High, Medium, and Low. Core requirements are ones that the site wouldn’t make any sense without—in the example site, for instance, “The position of each booth is displayed on a visual floor plan” is a core requirement. The technical team also assigns a complexity (High, Medium, and Low) to each requirement.

The actual writing of requirements takes a little practice to ensure they’re at a useful level of detail and are relatively unambiguous.

Defining scope
The last step in defining a feature set is determining what set of the functional requirements can be implemented in the next phase. I start by working with the development team to determine approximately how much time and money will be left over after achieving just the “Core” priority features. If the time and money can’t accommodate even the “Core” requirements then there’s a problem, and we need to revisit the vision. This is why it’s important not to make the original vision too ”blue sky.”

We then spend several hours as a team going through the rest of the requirements and creating a draft scope. Features are quickly reviewed and separated in to those that should obviously be included (such as High Priority/Low Complexity requirements) and those that obviously shouldn’t (Low Priority/High Complexity). Most of the discussion is around the High Priority/High Complexity and Medium Priority/Medium Complexity features and determining what can be included to create the best mix of basic functionality and strategic features. Determining a scope is more of an art than a science, as the features tend to be dependent on each other in complicated ways. Once there is a draft scope, a more detailed estimate can be made. Often there is too much for our schedule and budget and we have to go back to determine what else can be removed.

Unless the client is very detail-oriented and very close to the team, I’ve found it nearly impossible to involve them directly in the creation of the draft scope. There’s simply too much detail and too many time and money sensitivities. Once we’re internally comfortable with the scope, we can summarize it and present it. While the client almost always has changes, it’s fairly straightforward to iterate the scope because the team internally understands the trade-offs and complexities.

All the previous steps set up a framework in which to consider the issues, generally making the actual definition of scope fairly straightforward. The development and iteration of the Vision Prototype allows the whole team—both the internal team and the client—to solidify a team vision and working relationship. Scope definition, which can often be a painful process of wrangling over favorite features, is made much more straightforward by the imposition of a common vision.

Laura S. Quinn is a technology strategy and information architecture consultant for both corporate and nonprofit clients. Her company, Alder Consulting, specializes in helping nonprofits build powerful internet and database systems with the resources they have (learn more about Alder Consulting at In her spare time, Laura prepares for a new career as a homesteader with faithful practice in cooking, gardening, sewing, and weaving.

What You Should Know About Prototypes for User Testing

Written by: Chris Farnum

There are several important factors to consider when you are planning to do prototyping for user testing. You will want to make careful choices about fidelity, level of interactivity and the medium of your prototype.

Degree of fidelity “An information architecture wireframe is NOT graphic design. I swear, it’s really not!!!”Fidelity is the degree of closeness to the “depth, breadth and finish of the intended product” (Hakim & Spitzer). Opinions vary a great deal on how much a prototype should resemble the final version of your design. Usability practitioners like Barbara Datz-Kauffold and Shawn Lawton Henry are champions for low fidelity —the sketchier the better! Meanwhile, Jack Hakim and Tom Spitzer advocate a medium- to high-fidelity approach that gives users a closer approximation of a finished version. You’ll want to make a decision about the right approach for you based on the needs of your project.

Low fidelity
You can use hand-drawn sketches to create a paper prototype. If you go this route, you may also want to help your users get into the spirit of things during the test by creating a complete low-fidelity, paper environment. This could include a cardboard box made to look like a computer and an object to hold to point and click with. These techniques help users to suspend their disbelief and get their imaginations involved so that they can better visualize the interface. The advantage of using rough sketches is that users will have an easier time suggesting changes. They may even grab a pen and start making their own changes (Datz-Kauffold and Henry).

In theory, low-fidelity sketches are also a time-saver, but this really depends on your point of view. Personally, I like to draw diagrams and wireframes in Visio where I can revise and move things around without erasing and redrawing. If you prefer to work this way too, and if time allows, you can always have those Visio drawings hand-traced or use them as a roadmap for making sketches to test with. You might even find a graphics tool with a filter that will convert a Visio-generated graphic into a hand-drawn sketch with wavy lines.

High fidelity
This approach takes you as close as possible to a true representation of the user interface —screen-quality graphics. All of the blanks on the page are filled in, and it looks good. However, you might not have all of the technical or backend problems worked out yet, or you might have only a small part of the entire site rendered. That’s why it’s still considered a prototype. For example, it might consist of a small series of Photoshop images or HTML pages with just enough functional links to convey the feel of the site’s flow. You may need to enlist the help of a graphic designer or web developer to build these in a reasonable amount of time. Advocates for high-fidelity prototypes argue that they are easier for users to understand just by looking at them. There is no disbelief to overcome, and it is easier to determine when they really do not understand the design. If you choose a high-fidelity prototype, make sure the you have enough of the design fleshed out so that users can complete several tasks. Decide on these tasks early, so you know which areas of the design need to be represented for your tests. Otherwise, you will be in for a great deal of preparation work.

Medium fidelity
In the grand tradition of Goldilocks, I find myself drawn to the middle approach. A medium-fidelity approach tends to include some visual design and a level of detail somewhere between high and low fidelity. Does this sound familiar? As an information architect, I’m accustomed to creating wireframes I can hand off to decision-makers, graphic designers, web developers and programmers. An information architecture wireframe is NOT graphic design. I swear, it’s really not!!! But… I’ll admit that it has enough visual design to convey a rough version of the user interface. Because I create these with drawing tool software, they tend to have more polish than hand-drawn diagrams. Hakim and Spencer are champions for medium-fidelity prototypes because they fit more seamlessly into the design process while providing more realism for users. I found this to be true during a project to design a search interface for Egreetings with my colleagues at Argus. I created rough draft wireframes for the prototype, and after testing I revised them for use in my deliverables.

Interactivity describes how your prototype behaves. Does your prototype react to user inputs with feedback? Can they “click” on something to go to another page or fill in a form? Will buttons appear to depress and drop-down menus work?

Static prototypes
Prototypes used for testing are static if they are pages or page elements shown to users, which don’t provide any feedback. It can sometimes work well to show a page to a user and ask them to explain it to you or to guess where they can go from here. In this kind of test, the user interprets the prototype rather than interacts with it. This is a good way to validate your design by checking to make sure users understand it. It’s also easy to score this sort of test when you have a standard list of questions to ask about each page.

Automated prototypes allow users to make choices that cause changes. The testing prototype provides the user with feedback. Elements are “clickable” and forms can be filled out. The interface reacts to the user while the tester observes. One way to do this is to create the prototype in HTML or some application that allows interactive elements such as Flash, Visual Basic or even PowerPoint.

Another way to achieve a kind of pseudo-automated interactivity when you have chosen a paper prototype is to pretend (Datz-Kauffold and Henry). Have you ever seen children at play pretend that they are driving a car by setting up chairs for the front and back seats, drawing a dashboard on a cardboard box, and using a Frisbee for the steering wheel? If you have set up the right environment for your users, you can ask them to pretend scraps of paper on a table are their computer screen. When they “click” on a drop-down menu by touching the element with a pointer, a tester assigned to the role of the computer provides feedback by swapping the closed menu for an open one that shows choices. The “computer” may need to write on some elements before showing them to the user, i.e., “Your search retrieved 523,621 hits.” It takes a few minutes to get test participants used to the idea, but if you encourage them to have fun with it you will learn a great deal. You can also easily try out different possible reactions to user input.

This method worked well during the Egreetings project. We especially emphasized the technique of asking the users to click and then provide feedback. We found it useful to laminate the screen components so we didn’t need to produce a clean copy of the test for every subject. The users could write on the laminated pieces with thin whiteboard markers when making selections and entering search criteria. Of course, this meant that we needed to take careful notes because of the need to erase between each test subject.

Here are some other tips to try for low-fidelity testing with simulated interactivity:

  • Bring extra paper so you or the respondent can sketch out an idea if the opportunity arises.
  • As with any user test, it really helps to ask the respondent to think aloud.
  • If you have the luxury, bring a team of three to the test: someone to take notes, someone to play the “computer” and another to facilitate.
  • Use a piece of posterboard as your “screen.”
  • Cut your design into separate pieces or zones as appropriate and ask the user to rearrange them in the order they prefer.
  • Attach the folder tabs that come with hanging files to components so they are easier to grab.
  • Invite users to throw away or cross out components that they don’t think are important.
  • Number the pieces so that you can easily refer to them in your notes and keep them organized.
  • If you do decide to bring separate copies of the test materials for each session, tape down the components to a larger piece of paper as arranged by each user so you have these artifacts to analyze later.

Prepare a kit for yourself containing:

  • Scissors and tape,
  • Different sizes and varieties of sticky notes (which make great drop-down menus),
  • Markers and pens in various colors and sizes,
  • Paper clips and binder clips for keeping slips of paper organized, and
  • Objects that the user can pretend are the mouse pointer, such as a feather or a small toy.

There are many possible combinations to choose from for building your prototype. One of the first choices to make is whether you want to have your prototype viewed on an actual computer screen or if you’ll be working on a tabletop with a paper prototype. Believe it or not, fidelity and interactivity are independent of the medium you choose. It’s probably most natural to think of the extreme cases. An automated HTML prototype is often high-fidelity and, of course, the medium is a computer screen. Likewise, a natural medium for a low-fidelity automated interactive prototype is hand-drawn sketches on paper. However, you can also have the following:

  • Low to medium-fidelity wireframes built in PowerPoint that show only lines and boxes with text;
  • animation features provide automated interactivity,
  • Static Photoshop prototype pages shown to users on a computer screen, or
  • Same as above, but printed out in color on paper.

Mixing the variables
You can mix these three variables (fidelity, interactivity and medium) in many different combinations. The exact combination you choose should match the goals you determine for your testing. Possible goals for an IA prototype include:

  • Testing the effectiveness of labels and icons.
  • Finding out the right balance of depth and breadth of a topical hierarchy.
  • Determining the right options to offer for narrowing a search.
  • Choosing the most important metadata elements to show on a search results screen.
  • Settling the question of whether your target audience accomplishes tasks better with a task-oriented organization scheme or with a topical organization scheme.

If you live and breathe NetObjects Fusion and don’t have much time, your preference might be to create a medium-fidelity prototype. That way you could test that sitemap you are working on using some rough placeholder graphics or text instead of the finished graphic design. How you mix the variables depends on the time and budget you have available, as well as your work style. Try experimenting with different approaches to learn how prototyping will work best with your design process.

For more information

  • Evaluating Information Architecture,” Steve Toub (2000).
  • UPA 2000 Proceedings:
    #28 – “Waving Magic Wands: Interaction Techniques to Improve Usability Testing Low-Fidelity Protoypes,” Barb Datz-Kauffold & Shawn Lawton Henry.
    #32 – “Prototyping for Usability,” Jack Hakim & Tom Spencer.
  • “Prototyping for Tiny Fingers,” Marc Rettig, Communications of the ACM, Vol.37, No.4 (April 1994). (ACM Membership required)
  • Using Paper Prototypes to Manage Risk,” User Interface Engineering.
Chris Farnum is an information architect with over four years’ experience, and is currently with Compuware Corporation. Three of those years were spent at Argus Associates working with Lou Rosenfeld and Peter Morville, the authors of Information Architecture for the World Wide Web.