Interactive Prototypes with PowerPoint

by:   |  Posted on

Have you ever wished your early design mockups could come to life, so you could try out the navigation, test an interaction, or see if a button label just feels right when you click on it?

Sure, you could invest in a dedicated prototyping tool, but you can create surprisingly quick and effective prototypes with a software program that’s probably sitting on your hard drive right now. It’s PowerPoint—and no, I am not kidding.

I’ve met many designers who use PowerPoint for blocking out screens without ever discovering the interactive features for creating hyperlinks, buttons, and dynamic mouseover effects. Yes, PowerPoint can do all that. When I show people an interactive PowerPoint prototype, someone inevitably asks what I created it in. The reaction is always the same: “PowerPoint can do that?”


To see what PowerPoint can do, here’s a sample interactive prototype created in Microsoft Office PowerPoint 2003 for Windows. (Important: View the document in slideshow mode to see the interactivity. Links and orange buttons are clickable.)

Though there are other prototyping tools out there, here are the main reasons I lean toward PowerPoint:

  • It’s fast. You can try something, hate it, and try something else—all in a matter of minutes.

  • It’s low-fidelity. A PowerPoint mockup doesn’t try to look exactly like the final product, so it’s easy to work on high-level design issues and not get bogged down in details like colors or exact text. I also like being able to jot down notes in the margins of an early design, which I’ve never found a good way of doing in HTML or Flash.

  • Everyone has it. One of the great things about PowerPoint is that the people on your team usually have it. You can easily email a PowerPoint prototype to people for review and feedback.

Basic Interactivity

To begin, create a simple PowerPoint mockup, each slide depicting a separate screen in your site or application. You can use shapes, text, and clipart to populate the screens. I like to leave a little space in the margins for notes and half-baked ideas.


Once your basic mockup is in place, you can add hyperlinks to text, shapes, or images. The links won’t be active in regular working mode; in slide show view, clicking on a linked object will go to a specific target screen.

Ready to give it a try? Let’s take a look at how to do it.

Note about versions: The detailed steps and screenshots in this article apply to PowerPoint 2003 for Windows. It’s possible to achieve similar results using other Windows versions of PowerPoint, but please be aware that the exact steps will vary.

Hyperlinking Text

  1. Select the text you want to hyperlink. Be sure to select the text itself, not just the box around the text.
  2. Right click, and select “Hyperlink…” from the menu.
  1. In the “Insert Hyperlink” dialog box, choose “Place in This Document” from the left menu.
  2. Click on the screen you want the hyperlink to lead to. Click OK.
  1. Voila! The text is now hyperlinked. View the PowerPoint as a slideshow to see it in action.

Hint: PowerPoint automatically applies a style to text links, but only if you apply the hyperlink to the text itself, not the box around the text. You’ll probably want to change the default sea-foam green color. Here’s how:

  1. Open the “Slide Design” panel from the Format menu

  2. Click on “Color Schemes”

  3. Click on the “Edit Color Schemes” option, which appears at the bottom of the screen.

Two settings control the color of links: The “Accent and hyperlink” color (for active links) and the “Accented and followed hyperlink” color (for visited links).

Creating Buttons and Hyperlinked Images

Follow the same basic process to create buttons and images that link to other screens.

  1. Right-click on the image or button. (I use a simple rectangle to represent a button.)
  1. Choose “Hyperlink…” and select the target screen following steps 3 and 4 above.
    Hint: Try giving hyperlinked buttons a different color so you (and reviewers) can tell which ones are active in the prototype.

Simulating the Back Button

PowerPoint has a “back” control, but it steps back to the previous slide in the presentation. With hyperlinks, this may not be the slide the user just viewed.
If you want a back button that lets the user get back to the screen he came from, you’ll need to build it yourself. Here’s how:

  1. Right-click on the item you want to use as a back button.
  2. This time, instead of clicking “Hyperlink,” choose “Action Settings…”
  1. In the “Action Settings” dialog box, choose the “Hyperlink to:” radio button.
  2. Select “Last Slide Viewed” from the list.
  1. That’s it! Now, when viewed in slideshow mode, this link will take the user back to the screen he just viewed.

Hint: Even without a back button, you can go back in slideshow mode by right-clicking anywhere on a slide and selecting “Last Viewed.” However, keep in mind that other people who click through your prototype might not know this.

Advanced Interactivity

PowerPoint can go beyond basic hyperlinks and simulate dynamic behavior, such as mouseover effects for a Rich Internet Application.

Creating Mouseover Effects

  1. Start with two slides: one “before” the mouseover effect and one “after.”
  1. On the “before” slide, right-click on the item that will trigger the mouseover effect, and select “Action Settings…”
  1. In the Action Settings dialog, click on the “Mouse Over” tab.
  2. Select the “Hyperlink to” radio button.
  3. Choose “Slide…” from the drop-down menu.
  1. second dialog box will let you select the “After” slide.

Now, in slide show view, mousing over the item you selected will switch to the target slide: the one that shows the “after” mouseover effect.

Hint: There’s no “mouse out” effect in PowerPoint. The best way I’ve found to simulate it is a bit clunky, but it gets the job done:

  1. On the “After” slide, draw some boxes around the item you want to apply the mouse-out effect to.
  2. Apply a mouseover action to the boxes around the object. (For example, if you want to return to the previous slide when you mouse off an item, give the boxes around the item a mouseover effect that returns to the previous slide.)

  3. Make the surrounding boxes transparent.

Mouseover behaviors can get out of control quickly in PowerPoint. This is partly because creating the mouse-out behavior is awkward, and partly because you need to create “after” screens for each individual mouseover effect. PowerPoint can help you try out a mouseover behavior (e.g., wire up a single example), but for prototypes with lots of dynamic effects—or many instances of the same effect—you’re probably better off with another tool.

Other Tips & Tricks

Use slide masters for persistent navigation

If your mockup uses a persistent navigation framework (tabs, left navigation items, etc.), create the navigation elements in a slide master, and apply hyperlinks that lead from the master to individual screens. This way, each slide you create will already have the navigation built in. If you need to make changes, edit the master and the changes will automatically apply throughout the prototype.

Disable standard slideshow controls

Even with interactive elements in place, PowerPoint continues to work like a slideshow: clicking a slide advances to the next one. This can be disorienting for people using your prototype. When they click on something you didn’t make interactive (which—trust me—they will), the slideshow will advance to something that doesn’t make sense.

To avoid this confusion, I suggest turning off the slideshow behavior. Your hyperlinks will still work, but clicking outside them won’t advance the slideshow.

  1. Select “Slide Transition…” in the “Slide Show” menu.
  2. In the “Advance slide” section, remove the checkmark next to “On mouse click.”
  3. Click the “Apply to All Slides” button.

Note: In PowerPoint 2007 for Windows Vista, this feature is under the “Action” item on the Insert ribbon.


It’s possible to take the interactivity a step further with the Control Toolbox and ActiveX controls in PowerPoint, but I find that the techniques outlined here are all I need for early-stage prototypes. They help me test-drive an interactive design, get feedback, and make improvements early in the process.

Of course, PowerPoint isn’t right for every project. Here are some trade-offs to keep in mind if you’re deciding whether PowerPoint is a good fit for what you’re doing:

  • Sample interactions vs. all interactions. PowerPoint works well for creating a skeleton of a site or application and for testing individual interactions. But since it’s not especially object-oriented, it can be awkward to apply the same basic interaction to multiple things. For example, imagine a list where each item leads to a separate details screen. You can do this in PowerPoint, but each individual page and each individual link need to be created manually. It’s a lot of work, you wind up with a huge file, and God help you if you need to modify anything. Keep PowerPoint in mind for sample interactions, but if you’re looking to build a complete prototype where everything is truly functional, keep looking.
  • Low-fidelity vs. high-fidelity. PowerPoint is great for testing interactivity, but it won’t give you a realistic sense of what any one screen will really look like. You’re not going to get a sense of exact layout from PowerPoint. Also, remember that PowerPoint screens don’t scroll, so if you’re designing for the Web, your mockups won’t necessarily get a full-size picture of any one screen.

Overall, PowerPoint can be a blessing for interaction designers who want to create interactive prototypes quickly and easily. Interactive PowerPoint mockups can give a flavor for how a site or application will feel when you move through it—which is what interaction design is all about.

Practical Plans for Accessible Architectures

by:   |  Posted on

If the relationship between accessibility and architectures intrigues you, see the Editors’ Note at the end of this article for more information about what we’re doing and how to get involved.

The United Nations recently commissioned the world’s first global audit on web accessibility. The study evaluated 100 websites from 20 different countries across five sectors of industry (media, finance, travel, politics, and retail). Only three sites passed basic accessibility checkpoints outlined in the Web Content Accessibility Guidelines(WCAG 1.0), and not a single site passed all checkpoints.

These guidelines are well established and were first advocated by the W3C in 1999. They simplify the knowledge required to produce accessible code and content. Despite developments in assistive technologies and web content, these guidelines are still invaluable today. They provide developers and editors with a foundation for creating accessible design, which is essential to people who have different access requirements. A second version of the WCAG is now available as a public working draft (WCAG 2.0).Nevertheless, a challenge remains in determining which members of the design team are responsible for accessibility. As more people are involved in the design, development, and editorial process, there needs to be agreement on how to best design for content management and customization, while also allowing for greater accessibility.

Accessible design requires a deeper understanding of context. It’s about providing alternative routes to information, whether that route is a different sense (seeing or hearing), a different mode, (using a tab key or a mouse), or a different journey (using an A to Z site index instead of main navigation). However, accessibility is much easier to achieve when the right foundations are put in place as prerequisites during site planning and strategy.

Approaches to Designing for Accessibility


Labeling and controlled vocabularies

Controlled vocabularies can have a positive impact on accessibility by supporting the development of contextually relevant navigation and consistent, understandable labeling. The WCAG 1.0 , Guideline 13 in particular, is written to ensure that navigation is meaningful to people who process information in different ways.

A person using a screen reader can call up a link summary for a given page or tab through links to obtain a general gist of the site. These browsing methods requires web developers to create navigation link descriptions that can be understood without reference to surrounding page context. For example, the purpose of a link should be clear. A user should not have to rely upon nearby visual elements or textual content to understand its meaning.

A dialog showing an automatically generated list of links over the Boxes and Arrows events page

Image 1: A link summary from a Boxes and Arrows page.

Different types of navigation taxonomies allow pages to be defined using both concise and longer contextual link names. This allows naming conventions to retain their consistency and ensures that the right amount of context is displayed across the entire site, not just in the main navigation. For A to Z indexes and site maps, more context is needed to distinguish choices presented to the user. Using contextual names in an index ensures that users are not confused by identical labels that might lead them to different destinations.

Navigation frameworks and wireframe design

When designing indexes and supplementary navigation, it is important to consider how different HTML elements can help shape information. Sometimes headings are a useful way to cluster menus, but it’s often more helpful to make headings active links to prevent important information from being lost.

An easy way to evaluate the hierarchy or order of page elements, such as headers and lists, is to use the “Firefox Accessibility Extension;”: its navigation tool displays the underlying semantic structure and ordering of HTML elements.

A headers dialog showing the structure of the Boxes and Arrows events page

Image 2: Selecting the navigation menu from the Firefox toolbar to display a list of page headers.

When developing a framework for navigation, it’s important to consider how users move between different menu systems. A front end developer will need to determine whether a skip link should read “skip to main menu” or “skip to content”. However, if IAs choose to use several different menu systems—perhaps to maintain organization—they should document the priority of menus and suggest practical uses for skip links. This will help developers define document structure and effectively use skip links. The structure of information elements depends on whether the page is high level and navigation-focused, or low level and content-focused.

The diagram below shows how the tab key allows users to move between links on the Boxes and Arrows events page. The heading levels serve as a guide so users can access menus (with the aid of shortcut keys). This type of semantic markup helps users of assistive technologies navigate more easily. Even if they are using a linear form of access such as audio, it’s possible to skim the page for information.

A page with styling removed and the order highlighted between different structural elements
Image 3: A wireframe illustrates page order and structure, as well as ideas for skip links

Ready deliverables

These diagrams can help web developers define and optimize page structures by organizing information elements early in the design process. Dan Brown’s page description diagrams demonstrate an effective way of communicating information elements, rather than using a set layout to display them.

When wireframing, IAs can use annotations to support designers and developers in meeting accessibility checkpoints. Nick Finck’s wireframe stencils can be used to identify Headings 1, 2, 3, etc., and illustrate how they should be ordered to display a logical hierarchy on the page. For example, the events list above is structured using the H3 tag. Describing each event as a list item conveys that the section is an index of upcoming events. This is beneficial to people who use assistive technologies, as there are commands that allow users to to skim the page from header to header or list to list.

While these approaches are helpful, they are not panaceas. There is ambiguity regarding correct semantic markup for complex pages. Consider homepages, where one may have top story headings, event listing headings, page section headings, and menu headings. How does the developer or designer determine the proper hierarchical structure for headings; how should they simplify the page so its purpose and structure are more understandable?

Widgets vs. Browser functionality

Another debate centers on how and where accessible design should be implemented. Consider text change widgets that enable users to enlarge or decrease font size. Resizing text is better left to user agents and browsers so that content displays more consistently. However, text widgets have become common page tools, as browser-based text resizing is hidden from users and most are unaware of this feature. Solutions to this problem include creating a user help page explaining how browser functionality works, or referring users to sites that explain browser customization and the benefits of assistive technologies. The BBC’s My Web My Way offers such examples. This site provides instructions on changing browser settings, text-background color, font size, and explains how to use assistive technologies.

However, one needs to consider whether its more beneficial to provide instructions, which may eventually become outdated, or direct users to an external site to learn about a particular technology.

Alternative ways to view content

An important aspect of accessibility is providing alternative ways to use and view information. Presenting information in a user’s desired format (indicated by his or her profile) would increase accessibility. Strategies to deliver alternative views include the following:

  • Reuse of information through alternative formats. For example, the ability to change the format of a document on the fly from PDF to RTF or XML is supported by some CMS systems.
  • Google Map’s HTML view conveys information about geographic locations in a format that can be read aloud by a screen reader.
  • Multimedia resources can be made more accessible through the addition of captions or transcripts. Inexpensive, “automated captioning web-based services”: and websites that enable users to “tag video content”: are making translations of this sort easier to implement.
  • Leveraging application programming interfaces (APIs), as “demonstrated by T.V. Raman”: of Google, can produce mashups, which offer alternative ways to view a particular data source. They enhance accessibility by providing customized views when a one-size-fits-all solution does not work. For example, services that offer map data at two times the normal magnification could be a resource for users with poor or corrected vision.

These examples demonstrate that accessibility is not just about compliant code. It requires an understanding of how information can be structured and transformed to make user interaction more flexible.

Customization strategies

Taking the idea of tailoring information access one step further, there is also scope for implementing user profiles or customization strategies to meet a specific audience’s needs. Imagine a website where navigation, search results, and content can all be accessed dynamically according to a user’s barriers to information, content needs, or disabilities.

Hildegard Rumetshofer and Johannes Kepler explore requirements (paid download) for providing comprehensive accessibility as part of a tourism information service. They illustrate how a system could deal with four distinct questions about a person’s information and service needs:

1. Does the tourism service meet individuals’ access requirements? (medium profile)
2. Is the tourism service able to meet individuals’ specific interests? (user profile)
3. Is information presented in an accessible, barrier-free format? (WAI guidelines)
4. Can search or access services be specifically tailored to individuals’ disabilities? (search and metadata strategy)

Accessibility is becoming more dependent on the design of an information system’s components, and no longer a simple question of how content is presented. This is an arena where IAs excel.

Getting started

Understanding the importance of accessibility in the design process is only the beginning. Information architects need to understand accessibility considerations so they can design practical, inclusive solutions. A good starting point is the Web Accessibility Initiative’s (WAI) website and its guidelines and techniques page. The following guidelines provide additional information and resources.

  • Web Accessibility Content Guidelines : 1.0, 2.0 in draft)
    Established checkpoints written for designers and developers to help them create accessible code and content.
  • Authoring Tool Accessibility Guidelines:
    Useful for projects that concern requirements for information management or the procurement of a new CMS.
  • User Agent Accessibility Guidelines: (UAAG)
    Intended for the developers of assistive technologies and browsers, these recommendations can help IAs understand the interplay between different sets of guidelines. For example, some information design problems are better handled by browsers and assistive technologies, while others are better handled by individual sites.


Accessibility audits and benchmarks remind us of the difficulties disabled people encounter when attempting to negotiate their way through today’s online media. Information architects need to think about representing pages of information as linear streams, not just wireframing a collection of adjacent menus and content.

Creating an accessible web experience requires the coordination of independent groups. Initiating, managing, and designing for accessibility starts with strategy and ends with site evolution, content creation, and quality assurance. As IAs we should be advocating, designing, and supporting teams that provide equal access to information, as well as easier access for our primary personas. We should be looking for practical, design-driven ways to make accessibility a consideration through every phase of a project, and not just an afterthought.

While accessibility requires expert web developers to maintain high levels of access (especially on larger sites), it still needs the help of IAs who understand the scope and constraints that lead to accessible design, and who are conscious of the duty to prevent discrimination when making information management decisions.


“BBC’s My Web My Way”:
“W3C Web Accessibility Initiative”:
A to Z Site Indexes

“Somerset County Council”:

Alternative Views on Content

“Google Blog: Web APIs, Mash Ups and Accessibility”:
“Google Video Help Center”:
“Semantic Maps and Meta-data Enhancing e-Accessibility in Tourism Information Systems, IEEE Computer Society”:
“Tagging Multimedia Content”:


“Accessify Forum”:
“Dublin Core Accessibility Metadata Community”:

Debates and Futures

“Accessibility Panel, UK”:
“The Great Accessibility Camp-out”:

Standards and Guidelines

“Introduction to WCAG Samuri Errata for Web Content Accessibility Guidelines (WCAG 1.0)”:
“Web Standards Project”:


Editors’ Note


Our “podcast with Derek Featherstone”: marks the start of a theme for Boxes and Arrows. Accessibility guidelines are not only beneficial to those who need special affordances to experience our products more fully. Taking these recommendations and “web standards”: into considerations will guide what you build, strengthen its inherent structure, and help to encourage the development of better products for everyone.

Over the next several months, we’re looking to further explore these ideas as they apply to designers and the designer-developer relationship. Contribute to the series by sending an idea. (Eds.)

Faceted Feature Analysis

by:   |  Posted on

Everyone has ideas. Many of those ideas are held passionately. Some are brilliant, some are unrealistic and some are down-right stupid.

  • How can you make sense of ideas from multiple sources—formal requirements, brainstorm sessions, contextual inquiry, and input from the boss’s wife?
  • How do you entertain all ideas and still weed out the good stuff from the garbage without hurting someone’s feelings—especially when that someone signs your check?
  • How do you factor in real constraints and capabilities before these ideas become etched in stone?
  • How do you take in the different points of view that come from a programmers or business owners, not to mention the actual users of your product?
  • How do you do all these things and define project scope with some level of integrity that’s more than intuition or politics?

This article explains a process called “Faceted Feature Analysis.” It’s an exercise that I’ve been using for nearly 8 years on projects both large and small. The facets refer to three characterizing facets in any project: business value, ease of implementation, and user value.

Faceted Feature Analysis also uses three constraints that govern every project: cost, time, and quality.

By crossing the characterizing facets with constraints, you are combining the subjective needs of the project stakeholders with the objective constraints of the project in a way that ensures all points of view are fairly considered. It also ensures that a project requirement is not included or excluded simply because one person yelled louder than the others.

The process involves six steps:

  1. Rating the Feature List
  2. Creating a Flexibility Matrix
  3. Mapping
  4. Scoring
  5. Sorting
  6. Fine-Tuning

Step 1: Rating the Feature List

Compile a feature list from whatever sources are available. These typically include some sort of requirements documentation created by the business owner but can take in suggestions from a brainstorm session, ideas generated from contextual inquiry, competitive analysis, or other sources, formal or informal. As with brainstorming, there are no “bad” ideas at this point. This is important because, as you’ll see, the process is designed to weed out the impractical or ridiculous without any single person having to directly put it down.

Once the list is compiled, create a spreadsheet with the list of features and three adjoining columns: “Business Value,” “Technical Ease of Implementation,” and “User Value.” Ratings from 1-5 are assigned to each feature (1 being low). However, only the people who own each domain provide the ratings for that column: the business owners rate the Business Value column, the tech team rates the Technical Ease, and the user experience folks rate the User Value.

In this way, everybody is in a position to speak to their own area of expertise. Also, the rating of a particular feature isn’t as subject to the whims of the most charismatic or forceful person at the table, so you get a truer assessment of the general value of a feature.

Preliminary Ratings on a Feature List
Figure 1: Preliminary Ratings on a Feature List

Step 2: Creating a Flexibility Matrix

Flexibility matrices have been around for a while. Historically it has been a project management tool used to gain consensus on the constraints that govern a project. Every project is subject to three constraints: cost, time, and quality.

Blank Flexibility Matrix
Figure 2: Blank Flexibility Matrix

To create a flexibility matrix, the project team needs to agree on which of the three has the least amount of flexibility associated with it. For example, if there are certain features and functions that absolutely must be developed, then quality is the least flexible constraint. Use an “X” to note it on the matrix.

Developing Flexibility Matrix
Figure 3: Developing Flexibility Matrix

That leaves cost (the project has a finite budget of…) and time (the project must be completed by…). The result is a matrix similar to Figure 4.

Completed Flexibility Matrix
Figure 4: Completed Flexibility Matrix

This doesn’t mean that cost is not important. It just means that later, if you had to decide whether or not to cut something from the project, the quality or time involved would be considered first.

h3. Step 3: Mapping

The project constraints map loosely to the value columns where:

  • Cost = Business Value
  • Time = Technical Ease
  • Quality = User Value

By making this association you can add weight to the ratings in any column. In this case quality is the least flexible constraint so you multiply by 3 all of the ratings in the User Value column. As time is the next least flexible constraint, the ratings in the Technical Ease column are weighted by a factor of 2 and the ratings in the Business Value column are not weighted, because cost is the most flexible of the three constraints.

Mapping Flexibility Matrix to Ratings
Figure 5: Mapping Flexibility Matrix to Ratings

Step 4: Scoring

Simply add up the weighted ratings into the Total column.

Scored Ratings
Figure 6: Scored Ratings

Step 5: Sorting


This is where the magic happens! Sort the features according to their scores. Invariably, those features with the highest aggregated values rise to the top and those with the lowest values sink to the bottom.

Step 6: Fine-Tuning

What about the stuff in the middle? After you’ve sorted the list, you can usually find some natural cut-off point in the list where everything above the line constitutes a complete solution and everything below the line is either a feature for another day, a variation on a feature that made the cut, or something that might be best forgotten.

The question now is whether or not that natural cut-off point aligns with the constraints. In the case of quality there’s no need for further analysis because you’ve effectively said “regardless of cost or time, we need to have the features we’ve identified here.” In the case of cost or time, it is sometimes necessary to get estimates from the team on the hours needed for each feature. That way you can associate cost or time with each feature to negotiate the cut-off point by “horse-trading” with items of similar value above and below the line.

Effort Estimate
Figure 7: Effort Estimate

When the negotiating is done, you may discover one of three things: * You have defined the scope within the constraints * The constraints need to be revisited and the cut-off line needs to move * The constraints cannot be revisited and the project should not proceed (an extreme outcome)

The Benefits

  • Increases objectivity. You are leveraging individual bias to generate unbiased feature rankings. This occurs because participants are limited to rating features only from the perspective of their areas of expertise and using overriding, agreed-upon constraints, rather than personal influence, as the means of emphasis.
  • Assists in project planning. Scope and estimates provide the basis for a traditional project Gantt chart or the backlog that will feed an Agile iteration plan
  • Mitigates churn. This process greatly reduces the second-guessing during development that may occur when features have not been pre-qualified. There are fewer surprises downstream.
  • Minimizes politics. A feature rises or drops in the list on its own merit as it relates to the project constraints, not because anyone knocked it down or ram-rodded it to the top. (This can still happen but it’s harder to do without obviously and publicly disregarding the point of the exercise.)


A Few Thoughts By Way of Addenda

Understand that this process is not the way but simply a way to qualify a project’s scope.

The process is true enough to make sense out of a lot of information but not airtight in its logic because, as I mentioned, the associations between the values and constraints are loose and there is still usually some negotiation involved in the fine tuning phase. This means it is still possible for someone with influence to trump the findings in a particular exercise, based on their own agendas.

That said, by not being too prescriptive, the process allows for a great deal of flexibility. For instance, the checkout process on an e-commerce site is a feature on its own but it also has a number of sub-features like “review your purchase,” “enter shipping information,” or “confirm purchase.” So, while the team agrees that you need a checkout function, by rating the sub-features individually you’ll weed out some things for later development.

In your matrix, you can also include additional columns for more specific descriptions of proposed new features or columns for other metadata such as data source or legal mandate. Such additional information helps characterize the proposed features, making them easier to rate.

In my experience, this process has proven itself over and over as easy to do, easy for everyone to understand. It doesn’t take long and it yields both material and intangible value. However you apply it, you have a way to take a granular look at a lot of information and determine earlier rather than later whether or not something should be built, rather than if it could be built. That will save you and everyone else the downstream heartache that comes in the form of increased cost, increased time, and lack of quality. It also eases that boat ride because everyone participates in a way that brings their needs into the equation, making the outcome much more digestible and less likely to be challenged.

After all, if you can help create great products on time and under budget you’ll be a hit at parties and that’s why we do this sort of work, isn’t it?

Straight From the Horse’s Mouth with Dan Brown

by:   |  Posted on

iTunes     Download     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gif Christina Wodtke traveled with microphone to the IA Summit in Las Vegas this year and sat down with some of the most interesting and accomplished information archictects and designers in all the land. Bill Wetherell recorded those five conversations, and now B&A is proud to bring them to you. Thanks to AOL for sponsoring these podcasts.

In this bat episode, Dan Brown, “consultant”: and “author”: extraordinaire, deftly parries Tom Wailes’ repeated calls to oust the wireframes and task flows for prototyping and simulations. Our stalwart hero defends mindful subversion of the status quo as the best path in many corporate and public sector projects.

While exciting to throw out the bathwater, not every baby is fed by radical innovation alone.

Thanks to Tom for taking the voice baton after his previous turn as interviewee.

We discuss…

*Conceptual vs Design Documentation*
Ideation processes is where the team needs to think bout creativity and innovation. As designers, we create a set of artifacts to help us communicate.

*More detail required?*
Rather than using Wire Frames, Tom Wails says that his core artifacts are more detailed prototypes rather than wire framing, calling Dan’s approach to using Wire Frames into question.

*Know more than your audience*
Dan discusses the importance of knowing not only your audience but also understanding the corporate culture into which you’ll be working and designing.

*Government Work*
Dan points out a constraint to innovation from his experience is that most contracts are very specific with respect to deliverables. The challenge is creating within these set parameters. Dan provides examples of such creativity when designing Wire Frames.


[musical interlude]

Announcer: Boxes and Arrows is always looking for new thinking from the brightest minds in user experience design. At the IA Summit, we sat down with Dan Brown from EightShapes.

Tom Wailes: Hi, my name is Tom Wailes. I’m User Experience Director for Yahoo! Local and Maps. I’m going to be discussing with Dan Brown a few issues that came up today at the IA Summit.

Dan Brown: That sounds awesome. I look forward to it.

Tom: So a little bit of background. Dan gave a talk today, “Communication Design”. So something to summarize, I guess, his book what I thought about some of the design deliverables that information architects and designers who typically delivered over the years and made some very senseful suggestions for some refinement improvement to that. I gave a talk with a colleague of mine from Yahoo! Kevin Cheng that talked about different kinds of design deliverables, primarily storyboards and prototypes and simulations. So I’m here to talk with Dan about where he sees this to working together or not.

So Dan first, I kind of teased you a little bit in my talk after praising your talk. It was very good, I enjoyed it. But then, noting that you hadn’t already talked at all about prototyping or simulation, storyboarding, things like that which is what my team has been doing a lot of and we’ve been very little wireframing. So your reactions to that.

Dan: I think it strikes me as a very important part of the work that we do as designers. I didn’t sense any sort of disconnect between your story and my story. In a sense, I was speaking to all those people who have to jump on a project after a concept has been approved and funded and need to hash up the details. At the same time my, I guess, philosophy is meant to help people provide a critique of their own documentation and I wonder if there’s an interesting synergy there in looking at the kinds of conceptual documents that you do dividing it into layers as what I suggest.

So very important stuff that’s critical to the document versus the more extraneous stuff and using that as a model for evaluating conceptual documentation as much as design documentation.

Tom: So can you clarify a little bit what you mean by conceptual documentation versus design documentation?

Dan: Sure. What I got out of your talk was there’s this ideation process. There’s this process where we need to spend some time just spending some brain cells to think about what could be or let me get a better understanding what the problem is. We created a set of artifacts to either better articulate what that problem is, help get our heads around it, or, in the case that you were discussing, we’ve got this concept, we’ve got this idea to improve your product or create a new product and we need to sell it to the people who make the decisions and hold the money. That’s certainly what I got out of your talk and it’s something that I’ve had to do a lot in my career.

Why that stuff didn’t make it into the book, I would say is only because I was trying to –there’s a long list of documentation, I’d to cut it off that one of the things that people really do everyday in their jobs. And I was looking at your little video, I’m going, “God, if I could do that everyday, my job satisfaction would go –I mean, I love my job as it is, I’m self-employed, etc., etc.–but my job satisfaction would go through the roof”. So I see the conceptual stuff as sort of trying to sell and capture big ideas about a product or product direction. Whereas the design documentation, elaborating on the details and providing directions to the people who have to implement it.

Tom: So one thing I didn’t really cover today but it’s also part of our process that we’re trying, we’re experimenting and sort of making up as we go along, frankly. But it’s not just using interactive visualizations for the concept, but it’s also for the details that designs are right now, rather than doing wireframe or anything like that, we’re continuing only detail prototypes to help us work out more detailed aspects of the product, and that ends up being our core documentations.

It’s not to say we won’t go on to do some wireframes later but we’re involving the engineers right now in that so that they can start thinking about, “Oh, you wanted an interacting look like that. Let me think about it.” So using those kinds of –documents is kind of a funny word to use.

Dan: Artifacts.

Tom: Artifacts, those are our core artifacts now throughout the process, not just the ideation but as we’re working through the details. So how do you react to that?

Dan: I think that’s an amazing opportunity that you have. I remember you polled people at the beginning and ask them, for example, “Do you have a 20% role in your organization that allows you to just simply trying to innovate for one day a week?” And only a handful of people raised their hands and I think if you ask them, “Could you experiment with the kinds of documentation that you do to try and continue some of these prototyping or conceptual type of stuff throughout the life cycle of a project?” you get a similar number of hands.

I come from a world of government contracting, working with large Fortune 500 companies that are stuck in old school tradition, wireframes are, in a sense, –I know this is maybe shocking– innovation enough for them as far as a new kind of document. They’re used to sort of, I imagine, 1980’s IBM, big binders of functional requirements, the idea that we can translate those into some digital format is radical in and out of itself.

Can we get to a point that we’re all doing that kind of documentation? I would love that, in 10-years time we will be but in 10-years time you, guys, are going to be doing a whole another kind of creating another kind of artifact to capture functional requirements of behaviors and all those kinds of things. Does that answer your question?

Tom: It does, well, I think it does. So are you really saying that there are just core differences in the type of industries and the type of projects that might make it incredibly hard to break away from more traditional documentation like wireframes and flows and requirements, documents and things like that?

Dan: I’m not even in charge of industry thing, I just think it’s a corporate culture thing as far as there are some companies that are just not –one of my clients, for example, is a hospitality company. They’re not a technology company, they’re not geared towards that kind of innovation.

They grew out of this idea of selling hotel rooms to people. So that kind of culture is throughout the organization. They have technology people there, and they are fighting an uphill battle to do the kind of innovation that you are talking about. That hill is culture of 100 years of hospitality industry.

Tom Wailes: Obviously I know nothing about that company and that project, but I can imagine… You talk about hospitality and selling hotel rooms. At least me, from the outside, I can imagine a great opportunity to start with some visualization and prototyping to get across some concepts, particularly since you are talking about selling. I don’t know the details of that.

So what would stop you, what would make it very hard for you to say “You know what? I’m going try something different on this project”. What are the main inhibitors for you?

Dan: Oh, I’m not afraid to try something different. But I think, as designers, we need to be responsible… I’m no Steve Jobs, so I need to be responsible for about just exactly how much I am going to push the envelope.

The kind of conceptual stuff that you are creating is working for you and your organization and your culture and the kinds of products that you are working on. I think that there are opportunities to create those kinds of artifacts and documents in other organizations but maybe not push the envelope so much.

So, if I were to show that to someone who is so used to, in the flip side, seeing certain kinds of documents, it may not speak to them as well. They may be saying “why are you wasting my time with a comic?”

There is no controversy here. I am not trying to say that I don’t think there is a place for those things. I have not been able to cultivate a place for those things in the kinds of clients that I work on.

Tom: OK, I have two comments. The first is, in our environment, people were used to wire frames and requirements documents and things like that. We had been using those but we decided just to experiment with new methods like the comic storyboarding. The reaction actually wasn’t “I don’t understand that or I don’t get that or don’t want that”. It was like “oh my gosh, can you do more of this? I can see much more clearly what the core ideas are. I can be involved in giving my opinions now”. The wireframes and other kinds of documentation are much harder to be involved in. So that would be one comment.

The second comment is we talked about starting small. In what ways could you perhaps start small? I can understand you cannot just turn your client overnight into completely new processes. You have deadlines, budgets, and things like that. But in what ways do you think you could start small in introducing new ways of working?

Dan: There are things we do all the time. That culture may have given rise to a certain kind of wireframe, and I may see opportunities to encourage them to go in a different direction.

They may start with a conventional site map, and I might move them more to a conceptual model that includes things beyond web pages. It encourages them to think about maybe incorporating their users into that picture so they have a better sense of that. So I think there are definitely small opportunities. I believe we take advantage of them as much as possible.

The other constraint I wanted to point out was that, as an outie, as someone who is not inside an organization… I mean, to a certain extent, you serve clients inside your organization. But as a complete outie, my contracts are structured to do something very specific for a particular client.

So, if they hired me to help improve a set of pages or a particular function on their site and I said “OK I’ll do that but let me show you this first” they would really not happy with that because they are paying me to achieve something very particular.

I am working within the constraint of that particular project scope I need to find a way to do that things you are talking about and sell them on big ideas. The book, Communicating Design, talks about using documentation and use it in different contexts and those contexts, as the contexts vary, they will impact the nature of the documentation itself, as well. I don’t know if I answered your question.

Tom: I think you did. I’m still not entirely convinced that you can’t introduce new ways of working in a very small way where maybe you do not take any of the client’s time or maybe you only take a day. We gave some example today. I can show you some stuff later that just took two days to visualize some ideas.

So it might be something that is very lightweight and you are not beating the client of the head with it and saying “oh my god we’ve got to work this way”. It’s just like “yeah we are going to do all the things we are contractually committed to doing but, by the way, why don’t you have a look at this as well”.

Dan: I am not disagreeing with you at all. I completely think there are opportunities to do that, but my primary concern (I may get in trouble by saying this) is less about doing cool work period and more about doing cool work within the constraints that have been handed to me.

So I do want to push that envelope as much as possible but my primary concern, as a consultant, is customer service. Ultimately I can feed the kid by getting hired again. So I will do a little thing. I will show them a different kind of document. I will take their wireframes to the next level or I will show them how they can incorporate all of their flows. Who knows what it is.

I might produce a comic. We have done a couple of projects where we have done comic-like things that incorporated user commentary and very explicit screens or wireframes along with some more technical contexts. Not a comic in the true sense of the word, but something leaning in that direction. Those can be very helpful, especially when clients themselves are struggling with the scope.

That was a long rambling answer to say I agree with you.

Tom: OK, let me challenge you a little bit then. What if I was to put it to you that you would actually do better work and serve your clients better if you did less wireframing or other traditional kinds of documentation, and more prototyping, simulations and storyboarding?

Dan: I think you are right. So ha! So try and challenge that! [laughter]

I agree that there is an opportunity to do more prototyping and stuff like that. It is balancing that with the expectation of what we are going to get and what is going to work inside the organization.

In some cases, we are shielded from the development team entirely. So I am working to support to user experience team, and they are burdened with communicating with the developers. If I am going to ask them to challenge their developers, that is not very responsible on my part.

Tom: OK, thanks very much. So we sort of agree, and disagree, and agree again.

Thank you so much for your time.

Dan: I look forward to our next conversation.

Tom: Me, too.

Comics: Not just for laughs!

by:   |  Posted on

Every project has its own unique set of “opportunities”—also known as challenges. Many of these challenges relate not to the quality of our work, but rather to the communication of our ideas. Often in the course of design, you must communicate complicated concepts to a non-technical (and often uninterested) project sponsor, client, or stakeholder. So how do you capture their interest, get their understanding and buy-in, and finally move on?

A Real-Life “Opportunity”

I work as a user experience designer on an interactive team at a mid-sized strategic communications firm, Capstrat, based in Raleigh, NC. One recent web project presented our team the opportunity to communicate using comics. We were redesigning a family of more than 120 individual franchisee websites into one common web strategy, look and feel, and information architecture (IA). The challenge (“opportunity!”) was that governing umbrella organization had never enforced any kind of control over the web and the brand had been fractured by an inconsistent online user experience.

Our team was faced with getting consensus from a committee of more than 40 individuals, all with equal interest and many with their own motives. We knew getting buy-in from this hugely diverse group on the design for the new common web strategy and CMS was essential.

At the time, we were prepping for an international presentation where we would unveil new website designs, information flow, and shared CMS strategy. After the presentation, a Q&A session and formal vote were planned; the outcome would determine if and how proceeded with the project. We had some difficult concepts to communicate to a large audience in a limited amount of time. In just 30 minutes, we had to cover:

  • The overall look and feel of the new websites
  • How external users would move through the website to complete common scenarios
  • How the site design would maintain brand and structure consistency when propagated out to more than 120 individual sites while still offering flexibility to accommodate each website’s individual needs
  • How a non-technical administrator for each of the individual websites would engage and interact with a CMS to set up and maintain their site

We knew that presenting wireframes or flow diagrams to such a large group had the potential to be disastrous, but we also recognized that presenting flat visual design screenshots would leave too many unanswered questions. That’s when we considered the idea of using comics.

Why Comics?

Comics are becoming recognized as an effective means of communicating difficult concepts to diverse audiences—even in the most staid corporate environments and with the most serious topics.

In fact, in August 2006, Sid Jacobson and Ernie Colon released “The 9/11 Report: A Graphic Adaptation,” an illustrated digest of the 9/11 Commission’s 586-page report. About their choice of the comic medium, they said, “In a culture that has become the most visually oriented in the history of humankind, comics retain the original concept of storytelling and remain a potent force of information.” It is the storytelling attribute of comics that allows them to strike an un-intimidating and familiar chord with many audiences, even when dealing with sobering topics such as the 9/11 terrorist attacks.

Comics are effective not only because they are essentially narrative, but also because they are unpretentious, easy to follow, and accessible. Whereas a functional specification document uses words and often “tech speak” to communicate functionality, comics use pictures and interactions to get ideas across. Comic artist and Yahoo! staffer Kevin Cheng put it best, calling comics “the universal language.”

In contrast to many of the common tools of our trade (for example, use cases and process flows), the sequential nature of comic frames can communicate the progression of time (see image 1). Scott McCloud, author of “Understanding Comics,” notes that “creating meaning differences” in sequential comic frames is what transforms a series of separate illustrations into the “art of comics.”

Using a series of comic frames sequentially helps illustrate the progression of time.

Image 1: Using a series of comic frames sequentially helps illustrate the progression of time. (Click to enlarge.)

Comics can also easily illustrate a user’s response to an onscreen interaction. A flow diagram with an end error state or confirmation message may require the reader to decipher it, but the comic character’s facial expression can clearly reflect frustration or pleasure (see image 2) with a specific computer interaction. Using characters in your comic forces you to focus on the user experience implications of design decisions, one of the basics of a user centered design (UCD) approach.

A user's satisfaction/dissatisfaction with the outcome of a specific computer interaction can be illustrated using facial expressions.

Image 2: A user’s satisfaction/dissatisfaction with the outcome of a specific computer interaction can be illustrated using facial expressions. (Click to enlarge.)

Screenshots of user interface (UI) elements can also be incorporated into comic frames (see image 3) to give readers additional insight into the user’s experience. When presenting comics and page elements, this approach allows your audience to provide timely feedback on a screenshot, low fidelity prototype, or wireframe while understanding a page element in a greater context.

Including wireframe or screenshot functionality in a series of sequential comic frames communicates the context for interaction.

Image 3: Including wireframe or screenshot functionality in a series of sequential comic frames communicates the context for interaction.

How do you use comics to explain user experience?

Here’s how we made it work:

Step 1: Focus on the point (forget the details)
I was already well aware of our key scenarios and use cases, so I crafted brief stories in paragraph form for each one. Taking the time to write these stories before incorporating them into a comic allowed me to focus on the main points and the completeness of the message without the clutter of images and thought bubbles.

Step 2: Go from script to strip
I then thought through how to logically translate each scenario-based vignette into a series of frames. Each frame needed to communicate a key action or thought process in the scenario. To do this I created empty square frames and pasted in portions of my story in each.

Step 3: Fill in the Details
With the outline of my comic strip completed, I was ready to start filling in the details. Based on what I’d learned from Kevin Cheng1 and others2, I knew I really didn’t need a lot of different designs, just a few varying facial expressions and illustrations of individuals at computers. With help from Microsoft’s Clip Art Gallery Live and a thought bubble tactic from Dan Brown, I added my characters and text. Finally, I carefully selected elements from the wireframes to incorporate. It looked something like image 4.

Draft version of a scenario-based comic.

Image 4: Draft version of a scenario-based comic. (Click to enlarge.)

While no work of artistic mastery, the rudimentary sequential frames were easy to follow and communicated how an external user would move through the website.

At this point, we could have decided to intersperse the visual design screenshots with the comic strips for the presentation. However, our creative and interactive directors decided to have the comics turned into cartoons, which included having them professionally drawn and voiced and the still frame transitions animated.

So, I completed five or more comic strips for the most common website scenarios. Each frame was then pasted into a storyboard that captured the audio content to support it. The storyboard also captured when and where the visual design screenshots would be incorporated into each story.

Shortly thereafter, the transitions between the individual comic frames were animated and interspersed with the visual designs to show not only what the site would look like but also how users would interact with it. The animated transitions also showed how administrators would manage and create the sites in the CMS.

The presentation successfully communicated how users would engage with the site in addition to how it would look. Audience members commented on the use of comics as “a really cool way to demonstrate functionality.” While the team also got a few “how did they do that?” responses, others mentioned how easy it was to understand the process with comics. Using comics, we were able to quickly communicate complex concepts to a large, diverse audience. The comic medium also allowed us to illustrate answers to many of the audience’s questions before getting to the Q&A session.

A bonus of the project: I now have a generic Visio template that includes comics that I can reuse for future projects. (Download it here.) When using the professionally-created frames in Visio3, remember that you can create your own comics using hand-drawn art or clip art.

It’s not the technical skill of the drawing that matters; rather, it’s the essence of what is being communicated. Be it wireframes, use cases, or scenarios, the comic strip is merely a vehicle that allows you to communicate your work effectively and powerfully.

1Kevin Cheng, Communicating Concepts through Comics.

2Carson Van Osten, Comic Strip Artist’s Kit

3To use this template in Visio, download it to your “My Shapes” folder. It should then appear in Visio under Files > Shapes > My Shapes.