Category: Prototyping

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

Interactivity
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.

Maintenance/iteration
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.

Notation
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.

Process
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
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.

Conclusion

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.

“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.

• Sample Wireframe file
• Sample CSS file
• Macromedia Dreamweaver

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.

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.

• Beyer, H., & Holtzblatt, K. (1998). Contextual Design. California: Morgan Kaufmann Publishers.
• Cooper, A. (1999). The Inmates are Running the Asylum. Indiana: Macmillan Computer Publishing.
• Gause, D., & Weinberg, G. (1989). Exploring Requirements: Quality Before Design. New York: Dorset House Publishing.
• Kovitz, B. (1998). Practical Software Requirements: A Manual of Content and Style. New York: Manning Publications Company.

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 www.alderconsulting.com). In her spare time, Laura prepares for a new career as a homesteader with faithful practice in cooking, gardening, sewing, and weaving.