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.