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