The Guided Wireframe Narrative for Rich Internet Applications

by:   |  Posted on
Wireframes. We’ve all done them. We’ve all had to make sure our clients look at placement, labels, flow, and real estate distribution—but ignore color and design at all cost because, after all, they are wireframes.

Just as IA/UX/ID designers were settling into a comfortable working rhythm, the next step in the never-ending information architect’s challenge arrived: designing for rich internet applications (RIA).

The problem is both predictable and inescapable: our technologies improve faster than we know how to effectively design for them. It may be that AJAX, Laszlo, Flex, and other technologies enhance usability and challenge the way we think and design but, more importantly, they also put a heavier demand on our deliverables.

We were all told in Writing 101 to “show, not tell.” And in most cases this approach makes sense: there is no better form to express structure, conventions, and flow than “showing” the client a prototype. However, when projects are tightly constrained by time and cost, we have discovered that “telling” the client is an acceptable second choice. Fortunately, you don’t have to settle for second best: composing a narrative that “shows” requires only the tools and techniques that you are already familiar with: Microsoft PowerPoint and wireframes.

This case study covers the “guided wireframe narrative” technique used to design a typical web-based application.

Business problem:

The client, an industry leader in commercial and residential fencing and related products, wanted to update their web-based application used to perform key operational tasks. It was a big project, and as with all big projects, business and technical requirements were abundant. The client was also adamantly committed to and expected the highest levels of usability and user experience possible, under the ever-so-typical time-and-cost constraints.


Non-RIAs could satisfactorily accomplish most of the application’s requirements. However, we realized that building a rich internet application was the only way to reach the expected level of usability and user experience. The strategy to enhance usability and experience was twofold: improving feedback and response time, and contextually guiding users through tasks–perfect for RIAs.

Understanding the time and budget project constraints, we decided the best way to illustrate our design was through the guided wireframe narrative method.

Guided wireframe narrative

The key to using a low-context medium (wireframes) to illustrate high-context information (rich internet applications) is to narrate the information in layers or in dimensions. In short, because we couldn’t build a prototype (due to time and budget constraints), we built a story. But because it wasn’t a linear application, multiple stories needed to be constructed. We call these stories the Guided Wireframe Narrative.

Our story or narrative focused on four main dimensions:

  • Hierarchy
  • Screen real estate
  • Design conventions
  • Interaction patterns

Presenting one dimension of information at a time allows clients to focus on one particular aspect of the design at a time, avoiding information overload and the inevitable resulting confusion. This approach also works because we (the IA/UX/ID designers) can focus on setting patterns, not designing or documenting every single “page” or “state.” We simply design the patterns and the exceptions.

This is done by developing a click-by-click walkthrough in PowerPoint using commentary bubbles, progressively narrating each convention or process. The architect must hit every convention and task to illustrate all design conventions and patterns of interactivity. The only thing left to do is to design the exceptions–which, by definition, are few.

The narrative design process:

  1. Do preparatory work (client meetings, requirements review, user interviews, establishing creative strategy, etc.).
  2. Design as you would any other wireframe.
  3. Import the wireframe images into PowerPoint (or something similar).
  4. Focus on one of the four design dimensions.
  5. Point out the different aspects of the given design dimension using callouts.
  6. Sequence each callout such that one callout is revealed at a time, building to comprehensively describe and document the dimension.

Before moving forward with this case study, we have to address the question that comes up again and again: Why continue using wireframes? At all?

Wireframes are our friends because they are:

  • Familiar. We know how to make them, clients know how to read them.
  • Cheap. It takes a lot less money to put together ten screens in wireframes than in HTML.
  • Quick. Producing wireframes in Visio (or something similar) is simply faster than hacking at HTML.
  • Understood. If you can click on it, then people expect it to work. Wireframes are generally not expected to “work” – affording a higher tolerance for discovery and strategy.

The images bellow illustrate a simple narrative that progressively reveals some of the design conventions. Imagine only seeing frame six. The end result would be patchy understanding and maybe even confusion. This is why focusing on one design dimension and progressively revealing one concept at a time through a narrative is effective.


Admittedly, the example above is relatively simple, but after all, that’s the point, right? It’s almost like designing a user-friendly presentation of your design. Developing narratives for the visual hierarchy, screen real estate, and design convention dimensions should be relatively straightforward. The real challenge with this technique is nested in developing the interaction patterns narrative. However, if you have experience developing storyboards, this dimension shouldn’t be too difficult to design since some of the basic ideas are very similar.

As with all dimensions, the key is to place unwavering focus on the type of concept or pattern that you are trying to convey, ignoring everything else. For example, if the task is to search for a customer, only the steps in that process should be narrated. This approach keeps the process clean, allowing you to set the pattern with more ease.

In this next example we narrated the flow for creating a new customer. The process for creating a new customer is very simple:

  1. Search for the customer to make sure it doesn’t already exist (a business requirement).
  2. Select from search results or select “Add New Customer.”
  3. Enter New Customer information.
  4. Validate entered information.
  5. Provide feedback.


In this sequence, we “talk” the client through the process, narrating animation, flow, and functionality. Notice that four different things were said in this one sequence, yet only one wireframe was used. Before moving onto a new wireframe image, it is important to connect the two wireframes through narrative. For instance, the client should not be surprised that the next wireframe sequence contains the search results pane.


It is important to introduce a new sequence before the current sequence gets too complicated or textured. The next sequence is the final sequence before the task is complete.


Without explicitly “saying” so, this simple narrative successfully established several fundamental interaction patterns that could be applied to other tasks across the application without actually having to explicitly express them in wireframes.

Interaction patterns covered in this simple narrative:

  • How to search
  • How search results are displayed
  • When to fan panes close
  • When to fan panes open
  • How to transition from one pane to another

After narrating other processes, all interaction conventions were eventually captured. We typically opted to flesh out the most common tasks first because, in addition to setting interaction patterns, it also documented the most important user flows. It is important to have a full understanding of the entire application before design starts. That way you will specifically know which tasks and exceptions to flesh out.

Lessons learned and other observations

  • Clients are always open to money-saving processes and techniques that work. As with anything else, be sure to manage their expectations. The client normally asks something along the lines of “What do you mean you are not going to flesh out every task?” They become more receptive to the technique after we tell them the work we have to do is not “throwaway.” The work has to be done regardless of the technique used. Showing them an example and quantifying the time and money savings extinguishes any lingering doubt.
  • In this particular case, the client’s understanding of the design was greatly improved by presenting the design. We now budget time for a presentation whenever we use this technique.
  • The project’s technical team found the output of our process equally as useful as the clients did. They were able to write their detailed technical requirements from our deliverable. No detailed UI/UX design was needed to complete the UAT release.
  • We did, however, have to provide “clean” wireframes—developers found the bubble-ridden printouts from PowerPoint too difficult to read and code from.
  • The UAT release looked and behaved exactly as we had envisioned and how the client understood it.
  • As with all Internet-based projects, the ink never dries. Changes will come up. When they do, keep the technique’s principles present—design for the pattern while considering how that pattern applies to the specific task or convention.
  • This technique is not appropriate for every project. You have to use your best judgment and decide if the output is appropriate for the project and the client.


It is true that RIAs make our jobs harder. But it is also true that they introduce some very exciting opportunities that can significantly improve user experience and flow. The Guided Wireframe Narrative technique allowed us to quickly and accurately articulate different design dimensions using familiar tools and techniques. If the job fits the technique, it’s a win-win.

Know Your Place

by:   |  Posted on
“As IAs, it is important that we grow our capabilities to communicate more complex structures and interactions so that colleagues can comprehend, visualize, and ultimately build the experiences we envision.”

Web standards, browser support, and continued creativity are resulting in increasingly sophisticated web-based experiences. As information architects (IAs), it is important that we grow our capabilities to communicate more complex structures and interactions so that colleagues can comprehend, visualize, and ultimately build the experiences we envision.

As such, conversations about how to evolve our tried-and-true approach of wireframing are rampant. Some argue eloquently that we should move away from wireframing altogether and instead prototype a living, functionally evolving target experience (such as Garret Dimon’s “AJAX & DOM Scripting: Just Build It”). That’s also the direction espoused recently in “Getting Real” by 37signals. Others have demonstrated techniques to enrich wireframes by simulating in-page interactions via interactive storyboards (such as Bill Scott’s “Storyboarding Rich Internet Applications with Visio”).

However, IAs may be unable (lacking technical know-how) or unwilling (because of time, culture, or other constraints) to illustrate design solutions with such technically demanding methods. So, in keeping it old school, many will continue to focus on improving wireframing techniques. One improvement is to illustrate and document a design’s modular framework via efficient reuse of a similarly modular set of artifacts.

Tired of cutting and pasting the same page module throughout a myriad of different wireframes? Even more frustrated when, late in the design cycle, it turns out that you need another tab or link in that header that you’ve already cut and paste into 22 wireframes? Ever wondered how you can improve your spec documents to generalize elements repeated across pages by using the same artwork that you’ve used in your wireframes? Do you reuse and centralize the storage of varied design artifacts throughout your process?

Front-end developers have long used “includes,” which are HTML markup snippets that are abstracted from a single page and reused across an entire site via a single code source. Similarly, site styles can be abstracted into linked cascading style sheet files shared by all pages in a site.

Our commonly used wireframing tools, such as Adobe Illustrator and Microsoft Visio, enable us to approach our challenges in illustrating and documenting our UI design within artifacts in a similar, scalable way.

Views and modules
Regardless of what stage of the design process you are in, at some point you’ll begin wireframing one or more views (commonly, web pages) to represent a structured display in a specific, static context.

In all but the most small-scale design processes, modules begin to emerge that are repeated across different views or variations of the same view. A module is an element or meaningful group of elements on a page that, while possibly static and unchanging, typically varies in presentation based on dynamically populated data, display conditions defined by business rules, and changes in state triggered by events and interactions.

Initially, perhaps it’s just a header that contains a tab set and text indicating “You are logged in as John Doe (Log Out).” But eventually, numerous views (or variations of the same view) reuse more and more modules, even if those modules vary only subtly in different scenarios. Common examples of modules include:

  • A product item displayed in search results may be on sale, out-of-stock, also available via auction, or without a thumbnail image
  • A hierarchical tree view or navigation list, such as a structure that includes expandable/collapsible items for Inbox, Sent Items, Trash, and more
  • A context-sensitive bar for common actions like Add, Copy, and Delete
  • An article list, such as a link set generated by an RSS feed

Modules can be far more page- and context-specific (and less like a reusable design pattern), particularly if a single context warrants illustrating a range of instances, such as:

  • A configuration tool for a wireless rate plan that varies based on audience, active promotions, expanded and collapsed elements, and more
  • Shipping method (e.g. overnight) and destination (address) that varies based on prefilled customer options, customized corporate-specific displays, types of items in the order, etc.

If a module is used in more than one illustration, then abstract and manage it in its own file. Once abstracted, you can reuse it in other deliverables such as views, flows, or specs as necessary. For example, if you have a header that’s used in two views, then cut and paste the header into a separate file and place that file in every view that contains a header.

Cut each module from the view and paste it into a new, separate file

Tip: If saving artwork in Adobe Illustrator with the intent to include it in a different file, then ensure you check Create PDF Compatible File in the Illustrator Options dialog during the Save process. That way, not only will the artwork be visible in the document within which you include it, but you can also subsequently view that Illustrator file in various versions of Adobe Acrobat, including the free Adobe Acrobat Reader.

Placing artwork
Inserting a module from a separate file into an illustration can be accomplished via the following commands:

Adobe Illustrator CS2

  • Click File > Place
  • Browse and find the separate .ai file in which you’ve stored the artwork to place
  • Check Link so that the artwork will be linked to the file and subsequent changes to that file will be reflected in this document
  • In the subsequent Place PDF dialog, select Crop to Art and click the OK button.

Note that when you place Illustrator artwork in a separate file, artwork outside the file’s Artboard boundary will not be visible once placed.

Microsoft Visio 2003

  • Click Insert > Object…
  • Select Create From File to toggle the dialog to enable file selection
  • Browse and find the separate .vsd file within which you’ve stored the artwork
  • Check Link to File so that the artwork will be linked to the file and subsequent changes to that file will be reflected in this document
  • Click the OK button

Microsoft Visio’s Insert Object dialog

By following these commands, you should now see the artwork from the included file as an object. You can move, resize, crop, and even edit the module from within the current document. However, since the artwork is linked, the module remains independent and can be reused across other documents. As you change and extend the module over time, updates will propagate automatically to every other document that links to it.

Embracing modularization
Numerous capabilities arise through a modular file approach:

  • Change once and have updates propagate everywhere
  • Nest relationships of modules within each view (and view variation), modules within modules within views, modules within views within flows, etc.
  • Abstract design elements progressively as each module emerges, solidifies, and extends
  • Reuse and share between designers and across projects

Additionally, nomenclature you establish during this process can permeate the team’s discussions and downstream development efforts. Take the advice of Christina Wodkte and Nate Koechley, who point out “If you’re making up a name, make it something we can all use.” Your modular concepts could align with CSS naming conventions, influence the markup, and even suggest core objects built during the development of client-side scripting.

But a module’s usefulness is not limited to reusing a single representation. Within the file, you can create multiple variations of a display, apart from the representation or scenario where the module initially emerged.

Good variations
Module variations are critical in comprehensively depicting behaviors, state, dynamic data, and conditional displays during wireframing.

For example, consider a mini-shopping cart displayed in many views of a shopping experience. Over time, teammates will need clarity on how the mini-cart appears in different states:

  • Empty
  • Contains 1 item
  • Contains 2+ items
  • Transitions when updated in real-time via an interaction to add an item to the cart from elsewhere in the view (without a refresh)
  • Transitions when an item is interactively removed (without a refresh)

A grid of module variations based on display conditions and interactions

The module’s file is an ideal, consolidated location to store and evolve these variations. Within this file, you can quickly illustrate many variations in concert and manage those illustrations simultaneously.

This process frequently yields a grid of variations and enables visualization of patterns and differences across data, display rules, and state. With the consolidated display, teammates can more broadly understand how context influences the flexibility and scalability of the module’s elements. Additionally, if you need to update the module (whether to add a variation, update an element, or even modify copy), you have a single source.

Harvesting your crop
With module variations prepared, you can more quickly prepare many example views and flows. But, as you place a module file into each view, you now have an illustrated grid of instances instead of just one representation. Therefore, you must crop the placed artwork to show only the variation applicable to that view’s context.

Adobe Illustrator CS2
There are many techniques for cropping artwork in Illustrator, including:

1. Create a clipping mask
Regardless of how variations are arranged within a module’s file, you can use a clipping mask to hide all but the variation of interest:

  • Create a path (such as a rectangle with a stroke color but no fill color) surrounding the variation of interest and above the placed artwork
  • Select the path and placed artwork simultaneously
  • Select Object > Clipping Mask > Make (or CTRL-7)
  • Use the Selection tool to arrange the cropped illustration within the view or flow

2. Placement options
If a variation is at the artwork’s edge or corner, avoid the potential maintenance issues of a clipping mask and instead use the Placement Options dialog:

  • Select the placed artwork
  • Click on the artwork’s filename in the Control Palette (displayed via Window > Control Palette), and click on Placement Options in the resulting menu
  • Select to preserve: File Dimensions, select the corner or edge of the variation in the Alignment grid, and check Clip to Bounding Box
  • Click the OK button
  • Drag object handles to hide portions of the placed artwork except the variation of interest
  • Use the Selection tool to arrange the cropped illustration within the view or flow

Microsoft Visio 2003

  • Select the placed artwork
  • Click the Crop tool (if the Picture toolbar is not visible, select View > Toolbars > Picture, which will display the toolbar that includes the Crop tool), or click CTRL-SHIFT-2
  • Drag a selection handle to hide portions of the placed artwork except the variation of interest
  • Select the Pointer tool (or click CTRL-1) to arrange the cropped illustration within your broader view or flow

Cropping or masking a grid to show only the variation of interest

Tip: Module, view, and flow placement is supported by your design tool’s related product for creating documentation, such as Microsoft Word (for Visio-based artwork) or Adobe InDesign CS2 (for Illustrator-based artwork).

Spec and flow
Although boxes and arrows may be sufficient to illustrate a sequential experience path, flows that directly incorporate wireframes result in a far more engaging understanding of an experience. With variations of each view in your path (each built upon module variations), you are better positioned to efficiently construct numerous flows. Such storyboards are more compelling and accessible, relative to your audience’s cognitive struggle to map boxes and arrows to wireframes, relate decision points and business rules, and construct the experience in their mind’s eye.

As the design matures, many reach a point where the design must be annotated or thoroughly documented. The existing abstraction and relationships you’ve built significantly ease the documentation process; in fact, a modular structure should directly suggest a design’s decomposition into specification. You can consolidate your modular artifacts (flows, views, and modules) by placing each into this central document and then detailing each to your heart’s content.

Ideally, a spec’s detailed descriptions are layered onto and beside each type of placed artwork. Examples and variation grids are displayed in tandem with referenceable descriptions of dynamic data and attributes, display conditions, and events (including triggers, transitions, and resulting states).

Module placed into a spec document and subsequently annotated

Managing a hierarchy of modularized artifacts
Ultimately, a result of modularization is an interdependent hierarchy of linked files: modules in views and spec, views in flows (to illustrate sequences and storyboards) and spec (to consolidate examples), and flows in spec (for high-level paths and understanding of the experience).

Examples of linked documents: modules in views and spec, views in flows and spec, and flows in spec

An IA can certainly adhere religiously to their own style for managing files and folders. Why not? If it ain’t broke, don’t fix it–especially if it fits your process or model. Up to now, you may not even have worried about this because all of your artwork has been in a single file. However, this modular approach requires that you consider how to store what could end up as many artifacts. One solution is to create directories that mimic your artifact types, such as:

  • /projectName/modules/
  • /projectName/views/
  • /projectName/flows/
  • /projectName/spec/
Tip: Consider an archive subdirectory (such as /projectName/modules/ archive/) where you store older versions to which you can refer or revert. Such a file structure becomes even more important as you share your modular artifacts with a larger team via a network drive or versioned storage system.

Pros and cons
Of course, such an approach has pros and cons:


  • Easier updates throughout
  • Scales well
  • Enables asset sharing for larger projects or multiple projects
  • Engenders analysis to consider more peripheral behaviors and scenarios
  • Triggers discussions of the team’s shared concept of the experience
  • Simplifies design decomposition for documentation


  • Remains only a static representation of an interactive experience
  • Requires discipline and initial effort to abstract modules
  • May need to re-crop artwork as variations are added to a file that has already been placed and cropped
  • Updates require tinkering to cascade through multiple placement levels across files (in InDesign and Illustrator)

Tighten your use
Some additional ideas to enhance your modular approach:

  • Manage your links
    Adobe’s products offer a Links palette for viewing, reloading (because of updates), and editing your linked files of placed artwork. Microsoft Visio offers the Drawing Explorer to identify what artwork has been inserted.

  • Establish size and grids
    Once you break out artwork into separate files, it will be very painful to reuse illustrations and maintain consistency unless you establish standard sizes for elements (headers, boxes, form elements) and a grid for placement. Of course, this assumes you’ve conveyed what your wireframes are meant to depict (and not depict) to your visual design and development staff.

  • Review your artifacts with their audience!
    Seek out visual designers, developers, and quality assurance staff early to ensure your technique produces something they want. The better the spec, the better the questions, and ultimately the better the product.
    Parting thoughts

I’m all for interactive prototypes. In the near future, I look forward to seeing static wireframe and spec artifacts increasingly combine with interactive prototypes via an approach that simultaneously documents and demonstrates our designs in a single presentation.

However, while such interactive prototypes are valuable, the industry (or at least the type of environment where I most often find myself) is far from denying the need for printable, reviewable, versioned, and auditable documentation that details a design. The waterfall development process, for better or worse, is still a world where many of us live. Therefore, in the short term, modularization is but one way to more efficiently, clearly, and comprehensively illustrate a complex design via wireframes.

Interaction Modeling

by:   |  Posted on
“The relationship between actions and cognitive processes is important because it explains user behavior and translates to supportive arguments for good design solutions.”

Interaction modeling is a good way to identify and locate usability issues with the use of a tool. Several methods exist (see Olson & Olson 1990 for a review of techniques). Modeling techniques are prescriptive in that they aim to capture what users will likely do, and not descriptive of what users actually did.

Most methods—descriptive or prescriptive—fail to incorporate the relationship between user actions and cognitive processes. Models of cognitive processing, for example, might attempt to explain how or why a particular task is mentally difficult, yet the difficulty does not directly relate to observable user actions. Conversely, descriptive techniques such as path metrics, click stream analysis, and bread crumb tracking take little or no account of cognitive processes that lead to those user actions.

The relationship between actions and cognitive processes is important because it explains user behavior and translates to supportive arguments for good design solutions. Both prescriptive and descriptive techniques are necessary for characterizing the cognitive processing and user action (cog-action) relationship.

Collecting and reporting user data without presenting cog-action relationships results in poor problem definitions. In fact, practitioners often present no relationship between observed user behavior and the claim that there is a problem. Usability problems are presented as user verbalizations such as “I don’t know what I’m supposed to do here.” Although there is a cognitive reason why the user has fallen into this apparent uncertainty state, that reason is seldom presented. Further, the relationship between an identified problem and the solution to fix it is often not provided. If we don’t know why the behavior is a problem we can’t design a good solution.

This article presents a three-part method of interaction modeling where:

  • A prescriptive, preferred interaction model (PIM) is created
  • A descriptive user-interaction model (UIM) derived from an actual user study session is created
  • A model of problem solving and decision making (PDM) is used to interpret disparities between the first two models

Preferred Interaction Model (PIM)
A usability study design establishes success criteria. These criteria should be expressed as assumptions about user processes and behaviors. Creating PIM, or the process you would like the user to follow, specifies success criteria. Interaction models are a great tool for this endeavor and have enjoyed many published successes (for good review of case studies see Fischer 2000). There are three important things to remember about PIMs:

  • The PIM is created by the designer
  • The PIM should be based on task requirements, not functional requirements
  • The PIM exists in the system, not in the head of the user

Interaction models are typically quantitative frameworks requiring statistical validation. I use the term ‘model’ in more relaxed, qualitative way. The idea is to establish the PIM as a type of hypothesis or intended goal of development: “The system we designed supports X task/activity” (see e.g., Soudack, 2003). The method presented here is a structured approach for handling that hypothesis based on observation and theory. It lends itself to quantitative methods but doesn’t require them.

Creating a PIM
A PIM is a type of flow diagram that represents the user’s probable decisions, cognitive processes, and actions. Here is a simple example for retrieving a phone number from a contact database (Fig. 1).

[Figure 1: PIM for a phone number retrieval interface of a contact database application]

PIM entities are the decision (diamond), cognitive process (rounded box), action (square box), and system signal (circle). The model ends with a special action entity represented by a rhombus shape.

The PIM starts with a decision (get #?) insuring that the model can fit into the context of a larger model. Notice the sequencing of “cognitive state” then “action.” This is similar to the ordering of thinking, and then acting, that we would observe while watching users perform tasks. It also cues the modeler to encode a cognitive state (either decision or mental process) on either side of an action.

Decisions are modeled as yes/no or true/false statements. If multiple outcomes of a decision are necessary, consider using sub decisions. For example you might have a decision structure that looks like Figure 2.

[Figure 2: Nesting decisions can allow a complex outcome (choice A, B, or C, rather than just choice A or B]

The granularity of the model detail can be determined based on the needs and constraints of the system. Perhaps a higher level model of the contact number example (Fig. 3) might be more useful with different study criteria.

[Figure 3: Models can be high level and need not articulate procedural, physical actions (e.g., click on red button then move cursor to front of text, etc.]

Frequently on projects, the PIM has been loosely established and exists in some unarticulated form. Parts of the PIM might be discovered within prototype interface mockups, development requirements and/or design plans of stakeholders. The PIM can be difficult to construct from such varied sources. However, completing it makes assumptions about preferred interaction explicit and testable. Clearly defined, testable, assumptions are a necessity for this line of work.

User state-trace analysis: recording the user-interaction model (UIM)
State-trace analysis (Bamber, 1979) compares a given group’s performance under controlled conditions to performance under actual conditions. The method results in many interesting metrics and affordances. Collecting data on the UIM is somewhat similar to state-trace analysis yet differs in important ways. The UIM is collected under actual conditions (or as close as possible to actual conditions) and is then compared to is the PIM.

Rather then trying to perform traditional state-trace analysis, user state-trace analysis focuses on the goal of the method. Here, we wish to capture qualitative behavioral data while observing users as they transition from cognitive states to action states. We then use this data to “trace” the user’s path through these states as they complete the provided task. The result is a model of the user’s performance that contains valuable information about decision-making and problem-solving based on the system interface in the context of the task. The UIM can be compared to the PIM because they are similar in form and represent a similar process architecture.

Creating the UIM
User state-trace analysis is a type of coding that allows a researcher to trace the path of behavioral and cognitive states the user exhibits while completing a task. Use the same PIM entity types to create UIM diagrams. Instruct the user to “think out loud” and then trace the user’s path from cognitive processes to action states while they perform the provided task with the system.

This type of analysis has some caveats. First, real-time coding (i.e., recognizing, categorizing, and recording) of states is doomed to fail. The user might transition into states that are not well defined in terms of the task (e.g., an uncertainty process, or a stall action). The best practice is to video tape the study session and review it directly afterwards.

Expect upward of 10-20 times the video session length to complete a full-blown, accurate state-trace. Although a trace can be completed in an hour or less, plenty of extra time is spent determining salient user actions, arguing interpretations, and refining the complete trace model. As is the case in most endeavors, the more decision makers involved equates to more time spent.

If the task seems daunting, however, try restricting your level of trace detail to high level cognitive processes and actions and using the trace as an exploratory tool. This approach will drastically speed up the process.

When you start a trace diagram it is a good idea to use the PIM as a reference point for your coding. Have a printout of the PIM on a data collection sheet in order to take notes over top of it. Above all else, be honest while collecting data. You shouldn’t find yourself making rationalizations such as:

  • “Well they pretty much did that state … I’ll just mark it on the UIM.”
  • “They weren’t actually in a ‘confused’ state for very long … I don’t think that counts.”
  • “This user isn’t even sticking to the task anymore … none of this really counts anymore.”

Be aware that there is a tendency to establish an entire process-action-process relationship before writing anything down. Instead, try to first recognize and label a few states and actions on your data collection sheet. Leave these observations as labels anywhere on the sheet yet do not “link them up.” As you complete a significant phase of a task, start to organize and edit your labeled entities. Working this way allows the trace to develop while taking the mental burden off of the analyst to “guess what will happen next.”

Below is an example excerpt of a PIM and the constituent UIM retrieved from a user state-trace analysis session (Fig. 4). The representation in Figure 4 was obtained from a usability study of an interaction modeling tool. An analyst was asked to review a transcribed user study and assign models of decision making to various text passages.

[Fig 4: Excerpt from PIM/UIM of modeling tool process study.]

User state-traces provide several useful measurements:

  • Departures: the number and magnitude of states that happen outside the preferred model
  • Logical errors: the number of errors and recoverability from errors that resulted directly from departures
  • Lags: the amount of unproductive time spent in departures
  • Return steps: the number of obstructive returns to previous states
  • External processes: the dynamics of reoccurring processes that exist outside of the preferred model
  • Bandwidth constraints: the ability of the user to carry out cognitive processes and the amount of necessary resources available for them to do so
  • Action constraints: a cognitive process results in X possible actions though only a subset of these is available
  • Modal tracking: the discrepancy between application mode shifts and user mode shifts

Obtaining measurements from a user state-trace can result in a valuable dataset that reveals interesting patterns and trends. User state-trace analysis, however, is not a means of drawing inferences from these patterns nor is it a method of interpretation. A user state-trace reveals how the user performed the tasks, not why. The architecture of processes and actions exhibited by the user is generated by a cognitive mechanism the user engaged to deal with the task they were given. A better understanding of the underlying problem-solving and decision-making mechanisms will explain observed actions.

Problem-solving and decision-making model (PDM)
Cognitive mechanisms assist in solving problems and/or making decisions in order to complete a task. These tend to fall into four basic classes (Lovett 2002):

  • Rule-based: The user decides that if X situation arises then they will take Y action. Rule-based models are often engaged when the interface adheres to a dialog-driven, procedural task design. Examples are grocery store checkout systems, and operating system setup wizards.
  • Experienced-based: The user has been in this situation before. Last time they did X and it resulted in a desirable outcome, so they will do X again. Experience-based models are often engaged while performing tasks on systems users have familiarity with. In usability studies, however, participants are frequently recruited based on the criteria of limited or no experience with a system.
  • Pattern-based: The user has seen a situation that appears to have all the same elements as the current situation. In the former situation, X resulted in a positive outcome, so they will do the analogous version of X here. Pattern-based models take surrogate roles for missing experience-based models. The mechanism that handles the pattern-to-experience-based replacement can itself be expressed as a model. In fact the mechanism is regularly referred to as the users “mental model.”
  • Intuition-based: The user has a hunch that X will result in a desirable outcome so they will “follow their gut.” Intuition-based models are not well understood. Think of them as the user’s ability to distinguish patterns in the problem space that are far more detailed than the problem statement or situation will allow. Expert decision making is often categorized as intuition based.

To employ a model of problem solving and/or decision making (PDM) as an explanatory tool, it helps to diagram the model. An example of a rule-based mechanism is the satisficing model of decision making (Lovett 2002) (Fig. 5). In this model, a user chooses the first option they feel will accomplish the task without considering other options/ information. In the following example the satisficing model is recruited to interpret departures observed between a PIM and the recorded UIM:

[Figure 5: The Satisficing model of decision making]

Example Scenario: The application “Story Teller” (Fig. 6) allows a user to add characters from a story to a database. Characters are added to the database using the “add new character” function. Once a character is added, the application allows the user to count the frequency of appearance for a listed character. The PIM for adding a character to the database is illustrated in Figure 7. A user is recruited for participation in our study and given the simple task, “add a character to the character database and determine the number of times the character appears in the short story. The story file has already been loaded into the application.” Figure 8 shows the state-trace of what the user actually did.

[Figure 6: The Story Teller application interface with add character dialog]

[Figure 7: PIM of adding a character to the database]

[Figure 8: UIM obtained from a usability study session]

The UIM shows large departures. It appears that the user tried to “add a new character” for every time they saw the character in the story. We might be tempted to explain this as a problem with labeling in the interface or poor task clarification during the study. We could instead employ the satisficing model to explain the departures for a more rich interpretation:

  • Claim: There is a problem with the current interface.
  • Evidence: Large disparities between the PIM and state trace data (i.e., UIM) were observed.
  • Explanation: The user may be adhering to a satisficing model of decision making. Therefore, the user continually adds the same character as a new entry to the database because the text field that allows the user to enter a character is the first available entry point to the data input process. The text field also signals the user to recruit an experience-based model of problem solving: they copy and paste text to save time when the task is thought to require repetitive data entry. Additionally, the editable dropdown menu functions like a textbox therefore invoking the “data-entry model” to prompt the copy-paste action.
  • Solution: Place a list of available (previously entered) characters below the “New Character” input box. If the list has the name of the character and a clearly identifiable number representing the current number of instances next to it, the user will be allowed to select the character name in the list box and press submit. This will fix the problem of re-adding the same character in addition to allowing the user to include character aliases in the count (e.g., Matt, and/or Matthew).

The satisficing model is an example of a rule-based model yet assumes that the user is affected by cognitive bias. Common examples of cognitive-bias models are:

  • Anchoring and adjustment: Initial information presented to the user affects decisions more than information communicated to the user later in the task.
  • Selective perception: Users disregard information that they feel is not salient to completing the task.
  • Underestimating uncertainty: Users tend to feel they can always recover from faulty decisions in an application.

A good resource for the above models and a more detailed list can be found at the Wikipedia entry for decision making and problem solving (Wikipedia 2005).

It is a good practice to diagram several candidate cognitive-bias models before attempting to use them for explaining a specific departure. The diagramming allows you to get specific about exactly how the model explains the observed departure between the PIM and UIM. The final step is to include the cognitive-bias model as an annotation to the PIM with superimposed UIM (Fig. 9).

[Figure 9: Complete PIM, UIM, and PDM model integration]

The interaction-modeling technique provided here is useful in establishing usability success criteria and uncovers usability issues. The PIM acts as a testable hypothesis and the UIM establishes coded behavioral data. Major disparities observed between the PIM and UIM work as evidence to support the claim that there is a viable usability issue. The use of cognitive decision and problem solving models (PDMs) helps interpret and explain why the disparities exist. The essential components of a viable usability claim, behavioral evidence, and theory driven interpretations will inform the creation and rationale for good user interface design solutions.


Olson, J. R., & Olson, G. M. (1990). The Growth of Cognitive Modeling in Human-Computer Interaction Since GOMS. Human-Computer Interaction, 5(2-3), 221-265.

Bamber, D. (1979). State trace analysis: A method of testing simple theories of causation.
Journal of Mathematical Psychology, 19, 137-181.

Soudack, A. (2003). Don’t Test Users, Test Hypotheses. Boxes and Arrows, October 27.

Lovett, M.C. (2002). Problem Solving. In H. Pashler & D. Medin (Eds.),Stevens’ Handbook of Experimental Psychology: Memory and Cognitive Processes. New York: John Wiley & Sons.

Decision making. (2005, November 17). Wikipedia, The Free Encyclopedia. Retrieved December 1, 2005 from

Fischer, G. (2000). User Modeling in Human-Computer Interaction. User Modeling and User-Adapted Interaction, 11, 65-86.

The Lazy IA’s Guide to Making Sitemaps

by:   |  Posted on
“I would suggest that making sure the little boxes line up is a waste of an IA’s mental abilities. … So what is an IA to do?”

This article further develops the excellent Automating Diagrams with Visio by Michael Angeles.

Sitemaps are common deliverables, desired by clients who want a visual representation of a site. Since they are rarely used to make decisions, information architects may not consider them the valuable tools they are. The effort required to make and maintain them requires time that might be better used elsewhere. In fact, I would suggest that making sure the little boxes line up is a waste of an IA’s mental abilities.

Especially when your sitemap looks like this.

So what is an IA to do? Turn to Excel, of course. Storing sitemap data in a structured data format such as Microsoft Excel makes the data easy to edit, easy to share with the team, and easy to elaborate on (e.g., adding example notes and URLs that may not be appropriate for the map itself). Unfortunately, this approach requires maintaining a spreadsheet in addition to maintaining the visual sitemap.

Or does it?

This article includes step-by-step instructions on how to make sitemaps with:
1. Excel and Visio 2000 or Visio 2003 (Windows only)
2. Word and Inspiration (Mac OS and Windows)

Use these lazy techniques and spend your time on better and more interesting problems than lining up little boxes!


I’ve chosen these three options because they use standard applications that store the sitemap data in a format that can be edited by non-IAs. Each option demonstrates how you can store the data in the first format (Excel or Word) and import it into the second program (Visio or Inspiration) to—Voila!—create the sitemap.

You can use this zip file to access all the templates referenced in this article. I suggest doing the exercise once with the sample file to get the hang of it, then editing that file to your needs. The Excel spreadsheet has been written to do some semi-fancy calculations to let you store your data on the import sheet in a nice format and to output Visio-readable data on the output sheet.

1. Only edit data on the Input page.
2. Eliminate blank rows in the middle of your data.
3. The top sitemap box must be in field A2.
4. The template is defined for up to 200 elements

Technique 1: Excel and Visio 2000 / 2003

This approach uses the import data feature of Visio 2000 (Note that this feature has been removed in Visio 2003) and (mis)uses the “Organization Chart Wizard” from Visio 2003. You store and manage the sitemap data (the list of links in a structured organization) in Microsoft Excel, save it as a text file, and import it into Visio for quick visualization.

Step 1: Enter your sitemap data in the “Input” sheet in the file “template_for_visio_2000_and_2003.xls.”


For Visio 2003, proceed to the variation below.

Step 2: Go to the “Output for Visio 2000” sheet (and pay it no mind).

Save as Type “Text (tab delimited).”

You will see two alerts. Click OK and Yes.


Close the file. You may get the alerts again, hit “OK” and “Yes.” Closing the file is actually important!

Step 3: Open Visio 2000. Click “Open.” Choose Files of Type “Text (.txt, .csv).” Choose the file you just saved.

Step 4: When the dialog box pops up, set Field separator to [Tab] Text Delimiter to “Comment Character to ;. Click “OK.”

Step 5: A sitemap! Edit your sitemap to suit your fancy.

Variation for Visio 2003

Step 2: Click on the Sheet tab “Output Visio 2003” (and pay it no mind). Save the Excel file and close it.

Open Visio 2003. Select the “Organization Chart Wizard.”

Step 3: Select “Information that is stored in a file or database.” Click “Next.”

Step 4: Select “A text, Org Plus (*.txt), or Microsoft Excel file. Click “Next.”

Step 5: Find the demo file included with this presentation “example_visio_2003.XLS.” Click “Next.”

Step 6: Leave these defaults. Click “Next.”

Step 7: Remove “Title” as a displayed field. Click “Next.”

Step 8: Ignore the Custom Property fields (though you might be able to think of some use for the other fields in some interesting way). Click “Next.”

Step 9: You can make sitemaps that span multiple pages. Choose “specify.” Click “Next.”

Step 10: This allows you to define the top Sitemap box on the page. If you follow the Excel template, you can leave this alone. Click “Finish.”

Step 11: A sitemap!

Step 12 Right click on the sitemap to edit properities.

“Arrange subordinates” changes the sitemap layout.

“Change Position” changes the look of the boxes

Technique 2: Microsoft Word and Inspiration

This (mis)uses the flowcharting tool Inspiration. To do so, you format the sitemap in Microsoft Word outline format, save it as a RTF document, import it into Inspiration, and modify the diagram to look like a sitemap. The outline format can also be created directly in Inspiration, but storing the data in Word allows you to better collaborate with coworkers and clients.

Step 1: Outline your sitemap using Microsoft Word’s Outline format. Save it as a RTF file. (Step 1 is optional: you can make the outline in Inspiration, but some users may wish a more accessible format, like Microsoft Word.)

Step 2: Open Inspiration. Create a new file. Open the RTF file.

Step 3: Inspiration converts the RTF file to its own format. You may have to do some minor editing to remove blank rows, as shown above. (See image 26)

Step 4: Click the ”diagram” button at the upper left. What a mess! But click the “arrange “ button…

Step 5: Select diagram type “Top down Tree” and Lower level stacking option “Right.”

Better arranged, but visually lacking.

Step 6: Select all then click the rectangle in the menu bar. Now you can do things like take off the drop shadow, change the fill color to white, change the line color, etc.

A sitemap!

Working hard, hardly working
Sitemaps can be useful tools and are a whole lot easier when you separate the data from the visualization. After you have done these steps a few times, you will be able to update a sitemap in under a minute.

All these techniques can be expanded and improved upon. Let me know what you have done and what works for you. Have fun, but don’t work too hard!

This article references the following downloads:

Templates referenced in article (Visio, Inspiration, Excel)

For more information
This article includes step-by-step instructions on how to make sitemaps with:

Excel and Visio 2000 or Visio 2003 (Windows only)

Word and Inspiration (Mac OS and Windows)

Downloadable excel Site Map Thanks to Jon Stuckey and Marcia Stanton.

Storyboarding Rich Internet Applications with Visio

by:   |  Posted on

With the recent rise in popularity of web technologies such as Flash and AJAX, it has become possible to create richer user experiences on the web. Even though these technologies are not actually new, we are now seeing their widespread adoption. Within the last six months, we have seen the christening of the term “AJAX” and its broad acceptance. Most major websites are adding rich interaction to their existing features.

What has changed?

The traditional paged Internet application (PIA—part of what is sometimes referred to as Web 1.0 or classic web) has these characteristics:

  • The user enters information at the page level or clicks on a link to go to another page.
  • The page refreshes to show the result of the user's request.
  • Everything is framed in the context of a document content model.

A rich Internet application (RIA—part of what is now called Web 2.0) behaves like this:

  • The user interacts directly with items within the page and the feedback is immediate.
  • The page does not have to refresh to complete the user's interaction (data flows seamlessly in the background, allowing for instant feedback).
  • The interface can be thought of as an application model containing interface objects.

Moving from designing primarily for PIAs to RIAs presents us with a specific challenge: how do we document these richer interactions?


Wireframes capture the structure and relevance of information for a given screen or page. Wireframes and PIAs are a match made in heaven. Each wireframe corresponds directly to a page. The interactions typically move from wireframe to wireframe (page to page), making the interaction model simple to understand.

In the world of RIAs, wireframes are still a very powerful tool. Information still must be structured and its relative importance must be presented. However, with the deepening of the interaction dimension, it becomes more challenging to illustrate to clients, developers, and users how the intended interface will behave. This is due in part to the wireframe's static nature. It also becomes more challenging to test early designs with users since wireframes do not naturally simulate the more complex interactions of an RIA.

Enter Visio

At my previous company, Sabre, I led the user experience team for Airline Solutions. I built Visio stencil libraries that contained shapes simulating all of our web and desktop components (see figure 1). This simplified the creation of wireframes. The stencil libraries incorporated things like:

  • Intelligent layout using Visio connectors (Lego-like snapping)
  • Simulation of component states with right-click menus (select/deselect checkbox; show/hide borders)
  • User interface code-generation for both JSP (Java Server Pages, web) and Java Swing (desktop)
  • Requirements generation

Wireframe Stencils

Figure 1. Wireframe Stencil Library

However, one thing was lacking—the ability to simulate rich in-page interactions. I addressed this by creating a new stencil library that could simulate user interactions within a page. I used a storyboard metaphor for the stencil library (see figure 2).

Storyboard Stencil

Figure 2. Tools Provided in the Storyboard Stencil Library


Storyboards were originally conceived at Disney Studios about seventy years ago. They are a sequential series of illustrations or rough sketches, sometimes including captions of events. Storyboards provide a synopsis for a proposed story (or a complex scene) involving its action and characters (see “storyboard” at ).

Storyboards transfer well into the world of the user interface. With a storyboard we can present as frames each step in a sequence of user interactions. Viewing the interaction in a story format helps to refine the interaction and provide feedback for user testing.

The Visio storyboard stencil library

The storyboard stencil library contains four basic tools:

  1. Storyboard Name. Describes the storyboard scenario and is used to reset the interaction animation.
  2. Storyboard Step. Describes a step in the animation and shows or hides interface elements as needed.
  3. Click. Used to document the user interaction with the mouse.
  4. Drag & Drop. Used to document a drag and drop interaction.

Underpinning the Storyboard library is the layer feature in Visio. Layers can contain shapes and be shown or hidden. Showing a layer causes all of the shapes that are within the layer to be made visible. Hiding a layer hides the shapes it contains; however, if the shapes are part of another layer that is visible, they will still appear. Any number of layers can be created on a page, and shapes may be associated with a single layer or with multiple layers.

The storyboard stencil library provides a way to associate a storyboard frame (or step) with a given set of layers that can be turned on or off. In this manner we can create a crude animation (much like a children's flip-book) that walks through the steps of an interaction.

The purpose of the storyboard stencil is to simplify animating the interaction steps with Visio layers.

Example: inline editing

So let’s imagine we have a photo sharing site and we would like to like to be able to edit the title of a photo directly (inline content editing an RIA concept) without having to go to a different page for editing the title (separate page editing a PIA concept.)

See figure 3 for the wireframe for this simple page. It consists of a title and a photo.

Photo Site Wireframe

Figure 3. Photo Site Wireframe

What we would like to simulate in our storyboard are the following interactions:

  1. Show that the title can be edited. Hovering over the title uses highlighting to indicate that the title is editable.
    Start editing the title:
    a. Clicking in the title allows direct editing of the text string “My Photo”. The text is surrounded by a rectangle, indicating the field is editable. Save and Cancel buttons are displayed next to the field.
    b. The entire text of the title is selected.

  2. Type in a new title. New text will replace the selected text “My Photo” with the new text “Rain Forest”
  3. Save the title. Hitting the Save button saves the title.
  4. Show the new title as no longer editable, but a simple part of the page content. The Save, Cancel. and text edit rectangle disappear on a successful edit. The new title appears as part of the normal content of the page.

See figures 4-8 for how this looks, frame by frame.

Step 1

Figure 4. Title Available for Editing

Step 2

Figure 5. Title Being Edited

Step 3

Figure 6. Title Has Been Changed

Step 4

Figure 7. Title About to Be Saved

Step 5

Figure 8. New Title: part of the page content

Notice that a number of additional shapes appear and disappear during the sequence of interactions. These are the additional interface elements that are needed to simulate the user interaction. In this example, we need eight shapes:

  1. Highlight
  2. Tool tip with cursor
  3. Text edit rectangle
  4. Text selection rectangle
  5. Save button
  6. Cancel button
  7. ‘Rain forest’ text
  8. Mouse click for the save button

See figure 9.
Interaction Shapes

Figure 9. Interaction shapes needed for storyboarding inline edit

In order for us to hide and show interaction shapes as needed, we have to associate them with layers that we can turn on and off at each interaction step. It is important to remember that the layers in Visio—not the individual shapes—are what get hidden or shown.

You might be tempted to think that if you have five interaction steps then you will always have five layers to manage. But that really depends on how fine-grained the interaction will be. Since an interaction step can turn on or off one or more layers, there is not always a one-to-one correspondence between the number of steps and the number of layers.

In our example, we need to show the text as selected in step 2b but remove the selection during step 3. This requires us to control the selection individually. To do this, we create a layer that only contains the selection—allowing us to control its visibility in turn.

OK, so here are the five layers we need to control the individual shapes:

  1. showTitleIsEditable. Contains the highlight and the tool tip.
  2. startEditing. Contains the text edit rectangle, Save, and Cancel buttons.
  3. selectEdit. Contains text selection rectangle.
  4. changeTitle. Contains the new title text.
  5. saveTitle. Contains the mouse click for the Save button.

The five interaction steps described earlier are modeled with five storyboard steps. The storyboard name will reset the animation. Each storyboard step will hide and show layers to simulate the user interaction. See figure 10.

Storyboard Steps

Figure 10. Complete Set of Storyboard Steps for Inline Editing

In order to drive the animation, we need to configure the storyboard name and each of the storyboard steps to control the hiding and showing of the correct layers.

What we need now is a way to tell the storyboard name and each storyboard step which layer or layers they will control. Fortunately, Visio provides a feature called custom properties that allows us to provide this additional information. Custom properties are a way to associate named data with a Visio shape. The storyboard name and storyboard steps come packaged with a custom property named Target Layers. The storyboard name’s Target Layers property will control which layers get turned on or off when resetting the storyboard animation. Each step’s Target Layers property will control what gets turned on or off at that particular step in the interaction.

Valid values for this property can be:

•  The name of a single layer
The layer will be made visible when the step is activated.

•  The name of a single layer preceded by the minus (‘−’) character
The layer will be hidden when the step is activated

•  A comma separated list of layers (each of which may optionally be preceded with a minus character)
Multiple layers will be hidden or shown. If the minus character precedes a layer it will be hidden. Otherwise it will be shown.

Double-clicking the storyboard name willThe storyboard animation is reset by double-clicking the Storyboard Name.

So for our example, let’s see how the Storyboard Name and the five Storyboard Steps have their Target Layers property configured.

Storyboard Name – Inline Edit of Photo Title
-showTitleIsEditable, -startEditing, -selectEdit, -changeTitle, -saveTitle
All interaction layers are hidden to start with (acts like a reset).

Step 1 – Show Title is Editable
The layer showTitleIsEditable is turned on. This shows the highlight and the tool tip instruction.

Step 2 – Start Editing
We get rid of the highlight and tool tip and show the text edit rectangle, Save button, Cancel button, and the text selection rectangle.

Step 3 – Type New Title
We get rid of the selection for the old title and show the new title text

Step 4 – Save Title
We show the mouse pointer and hint that the user will be clicking the Save button to save the title

Step 5 – Title Saved
We turn off the save the title hint as well as all of the editing affordances.

To view custom properties, make sure the View:Custom Properties Window menu option has been turned on. See figure 11.

Custom Properties

Figure 11. Target Layers Property Value for Step 3 – Type New Title Step

Stepping Through a Storyboard

To review we have

•  Five storyboard steps

•  Each step configured to hide/show individual layers

•  The correct user interface shapes mapped to each layer

We can now use the storyboard name and storyboard steps to simulate a user editing the photo title inline.

Double-clicking the storyboard name will reset the interaction. See figure 3.

To step through the inline edit interaction, double-click each storyboard step in sequence. See figures 4-8.

While this example is fairly trivial, more complex interactions can be built. In addition multiple storyboards can be used to represent different use cases. This is important for showing error conditions as well as different edge-cases.

Managing Layers in Visio

In the interest of getting you into storyboarding as early as possible in this article, I skipped some very important details on how to manage and manipulate layers directly in Visio. Let’s look at how to manage Visio layers.

Layers are managed using the View:Layer Properties menu command. The Layer Properties Window that pops up allows you to add, delete, rename and manage the visibility of layers. Note that without the Storyboard stencil library you would have to use this window to turn layers on and off for each step. Obviously this would make animating an interface very tedious as well as distracting because you would have to set each one yourself.

While you will not normally use the Layer Properties Window to manage layer visibility (this is handled by the storyboard steps), this will be the way that you create, delete and rename your layers.

In the in-line editing example, you would create each of the five layers by clicking the New button for each layer and naming them individually. See figure 12 for what the Layer Properties window should look like after adding these five layers. (Storyboard is automatically created and used by the stencil library.)

Layer Properties Window

Figure 12. Visio Layer Properties Window

The other important thing you need to know is how to associate shapes with a Visio layer. Select the shape or shapes you want to add into a layer. Then right click and from the popup context menu choose the Format:Layer command. This will allow you to add the shapes to a specific layer or to multiple layers. See figure 13.

Format Layer Window

Figure 13. Shape Layer Formatting Window

Two important toolbar shortcuts

Since the View:Layer Properties and the Format:Layer tools are used constantly when animating an interface, a good shortcut is to add both of these commands to one of the Visio toolbars.

Let’s add the View:Layer Properties command to a Visio toolbar. You can do this by selecting the Tools:Customize menu command and selecting the Commands Tab from the Customize dialog that pops up. You can find the Layer Properties command under the View category. Drag this command to the toolbar − any spot will do.

Now let’s add the Format:Layer tool to a Visio toolbar − the best place is beside the Layer Properties tool you just added. The Format:Layer tool is under the Format Shape category; there are two different Layer tools listed, so pick the one that has a drop-down box beside it. Drag this command to your toolbar.

Now you have one-click access for adding layers (View:Layer tool) and changing the layer with which a shape or shapes is associated (Format:Layer tool). See figure 14.


Figure 14. View Layer and Format Layer tools added to Visio toolbar

Now that the Format:Layer tool is located on the toolbar, you will find that the drop-down list of layers provides a nice way for viewing on which layer a currently selected shape resides. In addition, by selecting a new layer from the drop-down list, it will change the selected shape’s associated layer.


First, you will need to have Microsoft Visio 2003 installed on your machine. Second, you will need to download the file. Third, unzip this into your My DocumentsMy Shapes folder. (My Shapes should have been created by Visio when you installed it.) Now that it is installed, you can navigate to this directory and double-click inlineEditWireframeExample.vsd to experiment with the photo editing example or you can start your own wireframe by double-clicking the Wireframe.vst file.


These tools provide a way to extend a common wireframe design tool, Visio, to support a technique for storyboarding wireframes. The storyboard metaphor is a simple concept to grasp. As we demonstrated designs to our Product Marketing teams at Sabre we received complimentary remarks about how much easier it was to understand interactions documented with storyboards; this made it simple to spot issues very early in the design phases.

A nice touch is to walk through the storyboard scenarios recording the animation with a video capture tool. The video can then be distributed to other groups and customers for early feedback on the interaction design with no instructions needed for walking through scenarios.

At Sabre, we were able to demonstrate for an important customer very complex application interfaces simulating in-page process flows, drag and drop, and rich data interaction. The interface we demonstrated had actually gone through several rewrites in previous years with less than satisfactory results.

Using the Visio storyboarding techniques outlined here we were able to present three iterations of the interface in a span of a few weeks. The final walkthrough was a success, with the client very happy with the new proposed interface. Additionally, their comments were extremely positive about being able to see and participate in the design at the earliest phases.