Integrating Prototyping Into Your Design Process

Written by: Fred Beecher
Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you.

Prototyping is a big deal right now. We get wrapped up in mailing list threads, new tools are released at an astonishing pace, books are being published, and articles show up on Boxes & Arrows. Clients are even asking for prototypes. But here’s the thing… prototyping is not a silver bullet.

There is no one right way to do it.

However, prototyping is a high silver content bullet. When aimed well, a prototype can answer design questions and communicate design ideas. In this article, I talk about the dimensions of prototype fidelity and how you can use them to choose the most effective prototyping method for the questions you need answered.

The dimensions of fidelity

A prototype’s fidelity has the most influence over its effectiveness. Fidelity simply refers to how realistic the prototype is. Most of the time when we talk about a “high-fidelity” prototype we are referring to a prototype that has some visual or industrial design applied to it. But that leaves out what’s most important to UX designers, what it’s like to actually work with the prototype!

Fidelity is multidimensional.

Not only can you have a prototype that looks like a realistic product, but you can also have a prototype that works like a realistic product. I call these dimensions of fidelity “visual fidelity” and “functional fidelity.” By varying your prototyping methodology along these two dimensions you can ensure that your prototyping effort is successful given your particular context. Let’s take a look at some examples.

version w/ arrows

A prototype can be as simple as a series of hand-sketched wireframes that flow together. This is a good example of a low visual fidelity prototype. These wireframes show layout and functionality but have no visual design. Take the same wireframes, integrate a visual design, and your prototype has a high visual fidelity. While you might think of them as being similar, these two prototypes are most effective in two different situations.

That same series of sketches is also a low functional fidelity prototype. Moving through screens drawn on paper is much different than working with the developed system. But if you render those sketches in HTML, JavaScript, & CSS, they have a high functional fidelity. Working with an interactive prototype is very similar to working with the developed system. Again, high- and low-fidelity prototypes are most effective in two completely different situations.

After spending all this time talking about fidelity, I want to share one of my favorite quotes on prototyping. Bill Buxton said this in his Interaction08 keynote:

There is no such thing as high or low fidelity, only appropriate fidelity.

Appropriate Fidelity

“Appropriate fidelity” refers to a level of prototype fidelity that allows you to achieve the goals you’ve set for doing a prototype in the first place. By varying the fidelity of your prototype along the dimensions of visual design and functionality, you make your prototype more effective at achieving some goals and less effective for others.

bottom left Low Visual and Low Functional Fidelity

Very low fidelity prototypes are extremely useful to UX designers. Why? They can be made swiftly, changed without repercussion, and still help visualize a concept. Low visual & functional fidelity prototypes are helpful at answering large structural questions. Here are some examples:

  • Does the system have all the features required to support the user’s goals?
  • Does the workflow make sense at a high level?
  • Which UX concept works best?
  • Coming to consensus on a UX concept with stakeholders, e.g.“Is this what you meant?”

bottom right Low Visual and High Functional Fidelity

In my own practice, this is the type of prototyping I do most often. What I make are interactive, HTML interactive wireframes. Everything is black, white, and gray, but the interactions are extremely close to what they’d be in the developed system. These types of prototypes are effective in many situations:

  • Evaluating the usability of proposed designs for new systems
  • Exploring isolated interactions as a proof-of-concept
  • Validating UX design direction with stakeholders
  • Validating the implementation of requirements with stakeholders
  • Supplementing printed documentation for development teams
  • Performing remote testing

Remote testing has become more and more important over the last several years. At Evantage, we do approximately 75% of our user testing remotely. It would be difficult for us to get good data about our designs for modern, highly interactive sites if we were limited to representing those designs using low-to-medium functional fidelity prototyping techniques such as clickable PDFs or interactive PowerPoint presentations.

By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an application around it…. If those ideas are actually pretty slick, I can release the design with confidence instead of with gritted teeth.

I also want to expand on proof-of-concept testing. This technique supports creativity and innovation. By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an entire application around it. This allows me to explore my crazy ideas and find out if they are, in fact, crazy. But if it turns out that those ideas are actually pretty slick, I’ll know that and can release the design with confidence instead of with gritted teeth.

top left High Visual and Low Functional Fidelity

At first thought, these prototypes may not make much sense. Why bother making something look nice if it doesn’t work? Well, because how something looks can have a huge impact on how easy it is to use. A high visual and low functional fidelity prototype allows you to test that with users. You can print out screen images and do a paper prototype test with them, or you can image map some JPGs and do what I’ve heard termed a “slap and map” test from within a browser.

top right High Visual and High Functional Fidelity

High visual and functional fidelity prototypes are the Rolls-Royce of prototypes. They take more time and effort to build than a lower fidelity prototype and are correspondingly more complicated to manage. Most of the time, this extra cost isn’t worth it. But there are a few situations where it is:

  • Evaluating the usability of proposed UX designs for an existing system
  • Performing usability tests with non-savvy user groups
  • Supplementing printed documentation for offshore development teams

Prototype testing is all about data, right? In the first two situations above, the prototype’s high visual fidelity reduces the confounding factors a wireframey prototype can introduce into test results, thus maintaining the quality of your data. In the third situation, the high visual fidelity helps minimize the design communication and interpretation problems inherent in offshore development.

Integrating Prototyping Into Your Design Process

What I’ve talked about so far has focused on the tactical, on how to prototype effectively to achieve specific goals. What I want to talk about now is more strategic. How can you integrate prototyping effectively into your design process?

First off, do what you’d do to begin any organizational change. Start small. Find a small project, express the value of prototyping and your interest in doing it, and do it. It would be best to start with something richly interactive though, as prototyping is more crucial the more interactive a system is. Of course, make sure you use a prototype of the right visual and functional fidelity for your purpose.

People like shiny things that move. The cool factor of prototyping will be difficult to resist.

As you near completion of the prototype, make sure you walk through the prototype with the project’s stakeholders. Ask them if something like this was what they had in mind. This will impress them on two levels. First, people like to feel important, and you’re soliciting their opinions. Second, people like shiny things that move. The cool factor of prototyping will be difficult to resist. When these stakeholders are involved in future projects, it’s very likely they will actually request a prototype as a result of their first experience with you.

Once you get buy-in, you can start integrating prototyping into your process. But just like different methods of prototyping are more effective for answering certain questions, different business contexts call for different ways to integrate prototyping.

Corporate, Agile, Mature UX Practice

This situation is fast-paced and iterative, but as an employee (as opposed to a contractor or consultant) you have the opportunity to own the UX of your company’s products. In this situation, there are three points in the design process that prototyping can be of benefit.

  • Low visual and functional fidelity prototypes can help select good UX concepts from several that you develop at the beginning of a project.
  • High functional fidelity proof-of-concept prototypes can help develop those concepts into usable designs.

You can work with a dedicated prototyper to build a separate prototype using code that can be reused in the production system to build efficiencies into an Agile process.

Corporate, Waterfall, New UX Practice

In this situation, the organization might not be comfortable enough with UX design to support the development of multiple UX concepts. You might just have to begin developing the wireframes and prototypes to meet the organization’s need for documentation and measurable signs of progress. This situation relies heavily on the prototype for communicating and validating direction with project stakeholders, with user testing often not yet being a real possibility. Here’s how prototyping can help:

  • High functional fidelity prototypes can help you communicate better with stakeholders and get their input on your direction
  • These prototypes should also be used for user testing, if at all possible.
  • Walk through the interactive prototype at the same time you walk through the printed documentation for the developers during handoff.

Consulting/Agency

When doing UX design for an external client, a lot of the magic is worked behind the scenes. The result is a process that is relatively unencumbered by internal politics. The challenge is to convey the importance of iterative prototyping to clients who sometimes feel like they’re paying for the same thing twice.

  • Sketch two or three of your design concepts into simple, low visual and functional fidelity prototypes and test them to decide which to go with. At this stage, testing can be very informal and done with anyone capable of putting themselves in the user’s shoes (e.g., other UX designers, customer service staff, or product managers who used to be users).
  • Build a small interactive prototype that shows the critical interactions, walk through it with stakeholders to validate your direction, then test with users.
  • Revise the prototype based on the test results, flesh it out to support more holistic tasks, and test again.
  • Revise the prototype and use it to supplement the paper documentation as you walk through both with the development team.

Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you. If you follow the simple guidelines above and prototype to an appropriate level of fidelity for your context, you will achieve your goals and improve your design. No firearms required.

Prototyping with XHTML

Written by: Anders Ramsay

Illustrations by Leah Buley

If you design user experiences for standards-based websites and applications (i.e. those built with XHTML, CSS, and JavaScript), there are several great reasons for adding XHTML prototyping to your UX tool kit. Perhaps you’ve found that traditional wireframes just aren’t sufficient and are looking for more powerful ways to explore and communicate design solutions. Perhaps your current practice is based on the traditional waterfall model (i.e. first creating wireframes, which are handed off to creative, who hand off comps to tech, and so forth), and you want to explore more contemporary methodologies, such as agile and iterative development. Regardless, a great way to embark on that journey is to start prototyping with XHTML.

So what does it mean to prototype with XHTML? Essentially, it’s the process of using the XHTML itself, and related technologies, to evolve and define your design solution. And what does an XHTML prototype look like? While, as we’ll see, that depends on where you are in your prototyping process, an XHTML prototype generally looks like any other web page built with XHTML, with some links or features perhaps being non-functional. In other words, anything you can build with XHTML, from consumer websites to enterprise applications, you can also prototype with XHTML. As we’ll see, there are numerous advantages to this approach compared to designing with wireframes or other prototyping tools.

An Iterative Process

While prototyping with XHTML isn’t tied to a specific design process, iterative development seems to effectively leverage its strengths. There are many reasons for this, but perhaps the most significant is that in both cases the prototype, and later the application itself, doubles as a specification. We’ll explore what that means in a bit, but first let’s walk through a suggested process for prototyping with XHTML.Let us start with an overview of the larger design process:

In this (iterative) methodology, rather than design the entire application before starting to build it, one designs and builds a unit of the application and then uses what has been built to inform and serve as a starting point for other application units. As with other design methods, the design work begins with sketching, which plays a particularly important role relative to prototyping.

Sketching: A Freeform Question

The term ‘sketching’ refers here to any freeform exploration unconstrained by a specific technology. This includes production of wireframes, which in this model are reframed, as it were, from specification artifact to refined sketch. When thought of, and presented to stakeholders, as sketches, its more natural to discard your wireframes once the design has evolved beyond them. This is usually after a prototype equivalent has been produced. With the design team I work with, we’ve found that when prototyping with XHTML, wireframes often became superfluous, and it’s more effective to go directly from sketch to prototype.

Prototyping: A Concrete Response

Prototyping has a counterpoint relationship to sketching. To paraphrase Bill Buxton, while sketches ask a question—“Is this a good design idea?”— prototypes provide a response. By making the idea manifest, prototypes force upon it the concrete realities and user experience idiosyncrasies of the actual production technology and offer a crisp verdict on the quality of what you dreamed up in drawings.

The Prototype/Build Relationship

When prototyping with XHTML, especially in an iterative model, the build and prototype become very intertwined. If you’re prototyping a new application or product, the XHTML prototype is essentially a rough draft of the actual application. However, when updating the design of an existing application, the production version can serve as the starting point for the prototype of the new solution.

Three Integrated Layers: Structure, Behavior, Foundation

The model for XHTML prototyping is based on the best practices model for actual site production: start by setting the foundation with XHTML, add a presentation layer with CSS, follow it by a behavioral layer using JavaScript then iterate.

Let’s start by looking at the structural layer.

Structure: Set the Page Foundation

The first step in production of the XHTML prototype is to create a structural foundation. Similar to how we create a wireframe, we start by representing the main content areas on the page, except we do so with text-based XHTML markup.

| If our sketch or wireframe looks like this | …our XHTML might look like this: |
|^. |^.

My Account

Account options

Account details

Account Help


(We’re only displaying the relevant snippet of the XHTML here.)
|

Next, we add detailed content elements that have been defined, using the XHTML structure appropriate for the corresponding content.

| For example, if our detailed sketch looks like this | …we’d represent the list of account help topics as an unordered list (i.e. use the ul tag): |
|^. |^.


|

Continuing to add detailed content to the page, we have essentially produced a structured content inventory of the page. This serves as a foundation for the rest of the prototype production. While wireframes force us to represent a page’s information architecture within a specific layout, this is pure structure and hierarchy, and, in my opinion, represents the true information architecture of a web page.

By defining the information architecture directly in the XHTML, we can also easily define accessibility-specific attributes, such as being cognizant of how users traversing the page with a screen reader will experience the page, and order content blocks accordingly. Additionally, we can more easily define elements often overlooked when working with wireframes, such as effective use ofLabel tags in forms.

If one were to view the structural layer in a browser, it would essentially look like an unstyled web page, and would not be interesting to look at. Just as building foundations are not known for their aesthetic qualities, but instead for the impact their quality has on the building they support, so too will the quality of the page structure significantly impact the overall quality of the web page. In fact, that absence of style is a key advantage of working with XHTML.

Evolving the Presentation Layer

With a page structure in place, we are ready to focus on how content will be presented. Looking back at our sketches, we’ve already explored some layout concepts, which we can begin to apply to our content structure. The way that look and feel is developed and applied will vary widely from team to team. While you may choose to do your initial exploration of look and feel with design comps, especially if you are also developing an overall brand, it’s worthwhile to redefine comps similarly to how we previously redefined wireframes. Just like wireframes are great as sketches, design comps are great for initial exploration of look and feel. But the practice of fully developing the presentation layer away from the actual technology, and then cutting it up and applying it wholesale to a web page is like wallpapering a façade onto a building. It’s impossible to be aware of all the dynamic aspects of a web page when working in static illustration software. However, when prototyping with XHTML, you can leverage the power of rendering your design in the same way that it will be seen by users, and incrementally evolve page presentation based on this immediate and rich feedback.

Issues that don’t easily reveal themselves when working in illustration software will often be obvious. This includes issues related to your design and the browser viewport, from the basic question of if the design should center itself in the browser window, to more advanced issues, such as how to design for different window sizes and browser resolutions. For example, for small windows sizes, is it okay if some content disappears out of view, or should the design adapt to the window size? When look and feel is designed solely with illustration software, questions like this are often unexplored to the detriment of user experience.

Adding Behavior: Unreinventing the Wheel

When prototyping with XHTML, you are designing within the larger ecosystem of the web, which effectively becomes your always-up-to-date UI library. Instead of laboring over the design of a detailed piece of functionality, start by letting Google inform you if anyone else has designed and built something similar, and then use that as the starting point for your solution. This can include anything from date-pickers to web widgets to whatever cutting edge UI idea was just created. Additionally, prototyping with XHTML makes it easy to incorporate and simulate Web 2.0 functionality, such as embedded widgets and syndication. If you don’t know JavaScript, or whatever technology is being used, you can collaborate with your developer on integrating the solution. Of course, you’re not going to find a solution for all your design needs online. In those cases, go back to sketching and collaborating with your team.

Iteration: Discovery, Evolution

The true power of prototyping really emerges during iteration This is when users can interact with your prototype. On a recent project, we sketched out a solution in which users could drag videos from a library onto a playlist. Looking at the static illustrations, it seemed a simple and elegant idea. But when users were able to interact with the solution, dragging and dropping video thumbnails, they found that it was a pretty tedious activity, especially for large numbers of videos. In other words, the prototype allowed us to discover a design problem that went unnoticed when looking at a wireframe.

And therein lies a core problem with using static artifacts to communicate interactive solutions; they effectively force the user to prototype the solution in their imagination, where all solutions seem to function in glorious perfection. With XHTML, we minimize the cognitive leap that users need to make, allowing them to instead experience and respond to something nearly identical to the actual solution.

Once users provide feedback and the team begins work on the next iteration, another measure of the quality of the prototyping methodology comes into play: how rapidly are you able to iterate? The longer an iteration takes, the less valuable your prototype. When prototyping with XHTML, iterations can be incredibly fast, first because the prototype can be easily presented to users, since it’s usually just a question of posting your files and sending out a URL. Second, because XHTML is text-based, iterations such as text changes or basic functional updates can often be completed in just a few minutes. More advanced design updates usually don’t take more than a few hours of actual production time.

How XHTML Can Double as a Specification

One of the most powerful aspects of XHTML is that it is self-describing. The same XHTML markup that tells a browser what to display can also double as a specification for a developer. For example…

^.

^.

This markup Would be read as
^.

“This is the start of the header content block.”
   
^. XYZ Application “display the product name, which should link to the homepage”
   
^.

Signed in as Jane Smith (Editor)

;

^. “display user information, including the user’s role (or set of application permissions”

In buzzword-speak, the practice we are applying here is writing semantically meaningful markup, which means we are selecting tags and naming our IDs and Classes such that they communicate the meaning and function of the content they enclose.

Annotations Visible Only to Those Who Care About Them

Another advantage of using XHTML as a specification is that IDs and Class names can double as annotation references. In other words, the annotations for the content block with the ID “account-options” would appear under the heading “Account Options” in your specification.

Rather than obscure and clutter a page design by placing annotation callouts on top of it, a common practice when using wireframes, that may confuse and distract non-technical viewers, references are only in the markup view for developers who are interested in seeing them. And since the XHTML file itself is so richly informative, the actual annotations written tend to only be short bullet points.

More Standards, Less Noise

One of the biggest problems with wireframes is the lack of a standardized notation. In other words, my wireframes certainly don’t look anything like your wireframes. This means that visual designers and developers who use wireframes are continually relearning how to interpret our work, leading to noise between author and reader. To compensate for the lack of a standard, we have to create highly detailed wireframes, with often lengthy annotations that explain what our wireframes mean and how elements in them work. These, in turn, are collected in large specification documents that usually are so labor-intensive they become impossible to maintain. When they are no longer kept up-to-date, the team stops trusting and relying on them as the design specification, which leads to all kinds of bad things happening.

In contrast to wireframes, XHTML is a standardized notation, anyone who knows XHTML can read your document. More importantly, it is a language spoken fluently by a key target audience of your design documents, the developers. And those who don’t know or care about XHTML can view the part they do care about, the page design, by opening the document in a browser.

Using a standardized notation also means you are not confined to specialized wireframing or prototyping software, but can use anything from a simple text editor to the range of tools available for editing XHTML files. Also the compact syntax of XHTML, particularly compared to verbose wireframe annotations, combined with the fact that you are just typing in a text file, leaving it to a browser to deal with the visuals, allows you to work rapidly and efficiently.

A Small Amount of Knowledge Goes a Long Way

If you’re new to XHTML, you’ll discover that a small amount of knowledge goes a long way. Spend just a few hours following any of the innumerable online tutorials and you’ll be writing XHTML markup in no time. (Two great places to start are htmldog.com or w3schools.com) Better yet, rather than invest time learning the UX tool du jour, you deepen your understanding of the technology that realizes your design.

Dividing and Conquering

The redefining of a wireframe from a blueprint to a sketch has a domino effect on who does what and when in evolving the page or application design. After a rough page design has been sketched out, rather than have one team member toil away in isolation, wireframing detailed representations of each page design, this model takes a divide-and-conquer approach. On the team I work with, I might produce an initial cut of the XHTML and some of the CSS, while other team members build on that, updating the XHTML, adding more advanced CSS, as well as JavaScript. If the team as a whole conceives of a solution, why not also have the team as a whole design it? In other words, rather than creating one person’s vision of a team’s solution, why not have the entire team contribute their particular expertise? When working with XHTML, we can use the tight integration of CSS and JavaScript to allow team members to contribute their dimension of the design via a set of integrated artifacts.

Where To Go From Here

This has, of course, been a mere whetting of the appetite for anyone interested in prototyping with XHTML. If you are interested in exploring the methodology further, particularly if you currently follow a traditional waterfall-oriented process, I recommend a many-small-steps approach. In other words, prototype the methodology itself, working with your team on a small project, and then building on that. If your experience is anything like mine, you’ll find it an incredibly powerful addition to your UX toolbox — a more effective way to straddle that proverbial divide between user experience and technology.

Quick and Easy Flash Prototypes

Written by: Alexa Andrzejewski

To tackle the classic “how to prototype rich interactions” problem, I developed a process for translating static screen designs (from wireframes to visual comps) into interactive experiences using Flash. Requiring some fairly basic ActionScript knowledge, these prototypes proved to be a quick yet powerful way to bring interaction designs to life.

When asked if I could find a quick and easy way to prototype a web application my project team had wireframed in Visio, I first turned to PDF prototyping. Using a PDF of the wireframes as the base, I overlaid clickable elements and some interactive data entry fields. Everything was wonderful—until the client asked us to add color to the wireframes. The Visio document was updated, a new PDF had to be made… and all that interactivity had to be reapplied. (It is tedious and time-consuming to replace page content in a PDF.)

Not wanting to repeat this tedious process again and again, I turned to Flash. I was excited to find that Flash not only felt more streamlined and intuitive when creating basic click-throughs, but it also offered almost limitless potential for prototyping rich interactions. With some basic ActionScript (a scripting language used in Flash to define interactions) knowledge and a bit of resourcefulness, I was able to create functional combo box navigations, type-ahead mechanisms, and eventually a complex, drag-and-drop scheduling application similar to Google Calendar. And whenever the screen designs changed, all I had to do was import the new background images, while the interactivity layers stayed happily in place, requiring only minimal tweaking.

Quick and easy yet powerful and flexible

The idea of working with Flash may seem daunting, but the effort required to create a basic click-through is comparable to that required by other applications, while the flexibility and potential for extending the prototype is far greater. (After all, Flash was designed for creating interactive applications, not presentations [like PowerPoint], diagrams [like Visio] or portable documents [like Acrobat].) Considering the additional benefits it offers, Flash prototyping is well-worth adding to your interaction design toolkit:

  • Flash prototyping allows you to add interactivity to screen designs and wireframes you’ve already created. You don’t have to recreate the layouts in another application.
  • Flash allows screen images to be updated without losing your interactive layers, which is much more difficult in PDF prototyping, as I described above.
  • Flash includes a robust library of customizable user interface components that can be dropped into your prototype and used as they are to add realism (e.g., a text field you can actually type in) or programmed using ActionScript to serve as fully-functional interface controls.
  • You can export prototypes as stand-alone applications (suitable for running from a thumb-drive at an on-site usability test where the Flash plugin may be blocked) or as HTML pages with embedded Flash (in which the browser can be used to scroll up and down through tall prototypes).
  • You don’t have to hire a professional Flash developer to achieve all of this. (I’m certainly not a Flash expert.) You can create simple, yet believable, prototypes with very little knowledge of ActionScript. All it takes is resourcefulness, creativity, and experimentation.

A valuable tool and impressive deliverable

Flash prototypes can be both a valuable tool for project teams and an impressive deliverable for clients. At the consultancy where I first employed Flash prototyping, these prototypes quickly became an invaluable part of the design, testing and buy-in process for many projects, and clients loved them. Here’s why:
By experiencing the interactions we were proposing, we were able to quickly sense when something that seemed good on paper didn’t feel right in reality.
By testing realistic prototypes, which users perceived to fully-functional, we were able to collect accurate user feedback about how novel interactions (such as a type-ahead search) felt and functioned in a real context.
By providing clients with functional demos, we were able to see our concepts move towards reality as clients enthusiastically used them to rally organizational support for concepts.
Having learned a lot through trial and error in creating these prototypes, I’d now like to share the process I developed through a step-by-step tutorial.

How to use this tutorial

In this tutorial, you’ll be creating a practice prototype using static screen images from Facebook that I’ve annotated using Visio. You should be able to complete it in 1 hour or less. To see what you’ll be creating, you can try out the final prototype files:
You’ll also want to download the files needed to complete this tutorial:
If you don’t have Flash CS3 or higher, you can download a 30-day, fully-functional trial from:
The major steps of this tutorial are in bold. If you have some Flash experience, you may be able to complete the tutorial using the bold steps and the annotations on the screens. For those who are new to Flash, I’ve provided detailed sub-steps and definitions.

Table of Tutorial Steps

Preparing screen designs for prototyping

To prepare for Flash prototyping, you’ll need to have images showing each possible screen and state in the scenarios you want to demonstrate. Often, you’ll have already created many of these screen designs in the wireframing phase of your project. The fidelity of these images may range from wireframes to visual design comps, depending on your prototyping needs. It doesn’t matter what software you use to create your images (e.g., Visio, Illustrator, Photoshop, etc.), as long as you can export them as raster images (e.g., GIF, PNG, JPG).

While images have already been prepared for you in this tutorial, here are some helpful tips for creating and exporting screen designs for use in Flash:

Creating the screens

Create neat layouts using grids and guides to keep items aligned from page to page to prevent inappropriate jumpiness (if only part of a page is supposed to be changing, such as when a menu appears, and the entire page shifts a little, it will detract from the prototype’s realism). Test page-to-page alignment by viewing images full-screen.

Ensure that images are all the exact same size by using a common background image or canvas size for all screens. In Visio and other page layout applications, you must be sure to remove or hide anything that protrudes outside of this background before exporting. Placing annotations that don’t belong in the prototype and anything else that will exist outside of the content area (page titles, footers) on a separate layer allows them to hidden before exporting the images.

Planning interactivity

Add a unique identifier to each screen or page that, unlike the page numbering (if you’re using a page layout program), will not change. You’ll be saving each screen as a file named after this identifier (e.g., “W05.png”). Using these identifiers, if your page ordering changes or you add or delete pages, you’ll still know which page corresponds with which exported image later.

Mark up the screens with callouts explaining everything that should be interactive and what should happen when elements are interacted with. For a basic click-through, most of these callouts will point to an element and read, “Go to X” (where X is the target page identifier). Make sure these callouts don’t extend outside of the image area. These callouts will make the Flash work much easier, and the callout version of the prototype makes a useful “practice prototype” that can help future users learn how to navigate the prototype. You’ll re-export the images and create a version of the prototype without callouts later.

Saving or exporting images

Save or export each screen as an image that will fit on a screen without scaling (preferably a lossless file such as GIF or PNG) using the page identifier as the filename. If you’re using vector-based software (like Visio), make sure the resolution of the exported files is set so that the resulting images will fit on the screen without scaling or scrolling. If your screen dimensions are 1024×768 points, for example, and you want the resulting images to be 1024×768 pixels, you would need to set the export resolution to 72×72 pixels/in.

Welcome to Flash

Note: If you don’t see some of these panels, use the Window menu to locate and turn them on.
You’ll be introduced to each of these elements and to key principles of ActionScript as you work through this tutorial. In the Appendices at the end of this document, you’ll find a handy reference guide and summary of everything you’ll have learned about Flash and ActionScript.

Setting up the Flash document

The images needed to complete this tutorial from scratch can be found in the SourceImagesAnnotated folder of this zip file:
While setting up the Flash document may feel tedious, what’s exciting about Flash prototyping is that after you’ve set up a document once, you can save your work as a template for future prototypes so that you don’t have to start from scratch. All you’d have to do to start a new prototype is import a new set of images with the same filenames and add or remove keyframes as needed depending on the number of screens.
If you’re already familiar with Flash basics and would like to skip to creating interactions, you can download an already-set-up template and begin working through the tutorial from the “Basic principles of interaction” section.

Creating a new prototype template

1. Create a new Flash document that uses ActionScript 2.0 and has a 1024px by 768px stage.
1.1. Open Flash and create a new Flash File (ActionScript 2.0).

ActionScript 2.0 vs. ActionScript 3.0

The latest version of ActionScript is ActionScript 3.0, a much more sophisticated but unfortunately a little harder to comprehend rendition of the language. Because AS 2.0 is a little more direct and intuitive (you can add scripts directly to buttons and objects), I recommend starting there. In fact, if you’re only using Flash for simple applications (like most prototypes will be), AS 2.0 is all you really need. If you eventually want to catch up with the AS 3.0 trend, understanding AS 2.0 first can help you make the conceptual leap to AS 3.0.

When working in ActionScript 2.0, you’ll want to make sure that tutorials and scripts you find online and in books are compatible. Look for tutorials written for Flash MX 2004, Flash 8, or Flash CS3 using ActionScript 2.0.

1.2. To define the size of the stage, in the Properties Panel, click the button next to "Size" that shows its current dimensions. Change the dimensions to the size, in pixels, of your exported screen designs—1024px by 768px in this tutorial. Press "OK.”
The Stage is your visual workspace or canvas. This is where you’ll specify where objects appear. Objects in the grey area outside the stage will not be visible when the exported flash movie is viewed at the correct size.
2. Import the images to keyframes by using Import to Stage and selecting the first file in the sequence. Flash will automatically prompt you to import the rest of the files and place each image on its own keyframe.
2.1. From the File menu, go to File > Import > Import to Stage. Browse to the folder where your images are located and select only the first image in the series—“W01.png.” Click "Import."
2.2. A dialog will appear asking if you want to import all of the images in the sequence. Click “Yes.” All of the images will be imported to your Library and automatically placed on separate keyframes in the timeline.

The Timeline is where you define when objects appear or disappear from the stage. The timeline contains frames and keyframes which can be on multiple, independent layers. The layers in Flash work in an identical fashion to layers in Photoshop.

Frames are displayed as blocks. They are grey when they contain content and white when they are empty.

Keyframes are frames marked with circles or dots. A keyframe is a frame where a change can occur without affecting the previous frames. Changes made on keyframes persist until the next keyframe unless “tweening” is used to fill in the blanks. You can also add commands (ActionScript) to keyframes, which will be executed when the player reaches that frame.

2.3. Note that when you click to select one of the screen images, you’ll notice that the properties of this image are shown in the Properties Panel, including its X and Y position on the stage (measured from the upper-left corner by default). The X and Y positions should both be “0” by default. If you ever move one of the images out of place accidentally, you can use the Properties Panel to place it back in the upper-right corner by re-entering “0,0” as its position.
The Properties Panel is context-sensitive—it shows/allows you to set properties for the last frame or instance that you selected. It is shown at the bottom of the Flash interface.
3. Name the current layer, “Wireframes.” Label each keyframe using the image’s identifier. Insert four frames between every keyframe to make these labels visible.
3.1. In the Layers area at the top of the workspace, double-click on the words, "Layer 1" and type "Wireframes." Press Enter to commit the change.
3.2. Click on the first keyframe to highlight it.
3.3. Press F5 four times to insert four frames after this keyframe.
3.4. With the first keyframe still selected, in the Properties Panel, change “” to the image’s identifier, “W01” (remember, ActionScript is case sensitive).
Frame Labels can be assigned to keyframes so that they can be referred to using ActionScript. It is generally better to refer to frame labels in ActionScript than to frame numbers because frame numbers are subject to change as you add or remove frames.
3.5. Click on the second keyframe to highlight it. Insert four frames after it and label it “W02.” Repeat for the remaining keyframes, including the final one. This part may seem a little tedious, but you should not have to repeat it again unless you insert additional screens. You’ll be able to update these images without recreating the keyframes and labels in the future.
The Properties Panel is where you can assign frame labels to frames and instance names to instances.
4. Create a new layer called, “Frame Actions.” Make sure the Flash movie does not automatically play by adding a “stop();” action to the first frame.
4.1. Right-click or Ctrl+click (Mac) on the first layer’s name and choose “Insert Layer.”
4.2. Rename the new layer, “Frame Actions.”
4.3. Select the first keyframe in this new layer.
4.4. Go to Window > Actions to turn on the Actions Panel.
The Actions Panel is context-sensitive—it shows/allows you to add scripts to the last frame or instance that you selected. Look at the tab name near the bottom of the Actions Panel to verify what you are adding actions to.
4.5. With the first keyframe selected, type the following in the Actions Panel:
stop();
Notice that a small “a" appears in the middle of the keyframe to indicate that actions will be triggered when that frame plays.

ActionScript is case sensitive.

Semicolons should be used at the end of every statement (generally every line).

Frame Actions are attached to keyframes and are triggered when that frame is reached.

Functions are built-in actions that you can call on using keywords. These commands are keywords followed by parentheses in which specific details can be added if necessary.

Creating a reusable button

5. Create a button symbol. Make the button invisible—an invisible button is clickable but does not display anything on the stage when the Flash file is compiled: It has a clickable area (a “Hit” state) but no visible states (Up, Over, and Down are all blank). This button should be a rectangle and the size of an average clickable area in your prototype. You’ll be able to resize instances of this button as needed. You will be using this button overlay to simulate most interactions.
5.1. Go to “Insert > New Symbol…”
Symbols are objects that can be used and reused. They are similar to Shapes in Visio and Stencils in Omnigraffle. Symbols include imported content, Movie Clips (objects that can have their own, independent timelines), Buttons (special movie clips with four frames in which four possible button states can be created), and Graphics (objects that may contain drawings and/or imported images).
5.2. In the dialog that appears, name it "invisibleButton" and choose the type "Button."
5.3. Notice in the Edit Bar that you are now editing “invisibleButton.” This button’s “timeline” consists of four labeled frames. Each frame represents a unique button state. Typically, you would draw what the button looks like normally in the “Up” frame, you’d draw the rollover state in the “Over” frame, and you’d draw the pressed state in the “Down” frame. “Hit” is an invisible state used to designate the clickable area of a button. Since you want your button to be invisible, you will only be creating the “Hit” state. Right-click or Ctrl+click (Mac) on the frame labeled, “Hit” and choose “Insert Keyframe.”
The Edit Bar (Navigation Area) indicates which timeline you are currently viewing. In this tutorial, you will generally be working on the main timeline, labeled “Scene 1” by default, but you will eventually be creating objects that have their own, independent timelines. These objects can be nested inside of each other. When you are inside an object’s timeline, a breadcrumb trail will indicate where you are in the grand scheme of things, e.g., Scene 1 > CarObject > WheelObject.
5.4. Using the Rectangle Tool and Fill Color picker if necessary, draw a solid-colored box on this keyframe. The color does not matter, as it will not be visible. It also doesn’t matter exactly what shape and size it is—you’ll be resizing each instance as needed. Just make it the size of a typical button in your prototype.
The Tools Bar contains tools you can use to create and manipulate graphics and objects on the stage.

5.5. In the Edit Bar, click the Back Arrow or "Scene 1" to go back to the main movie.
5.6. Your "invisibleButton" symbol should appear in the Library Panel.

Creating a layer for interactive elements

6. Add another layer to your movie, called “Interaction,” for buttons and controls. In this layer, insert one keyframe per screen.
6.1. Right-click or Ctrl+click (Mac) on the “Wireframes” layer’s name and choose “Insert Layer.”
6.2. Rename the new layer, “Interaction.”
6.3. Lock the “Wireframes” layer by clicking in the padlock icon column to prevent accidental changes.
6.4. Right-click or Ctrl+click (MAC) on the frame above the keyframe labeled, “W02” and choose “Insert Keyframe.” Repeat, inserting a keyframe in this layer above every labeled keyframe.

Basic principles of interactivity

I’ve provided a Flash file in which all the steps to this point have been completed so that you can experiment with the more interesting aspects of Flash prototyping. If you’d like to start the tutorial from this point, open the file called FlashPrototype_Template.fla from this zip file:

Creating a basic click-through

7. Place invisible buttons over all the “go to X” elements in the images (the ones specified using green callouts). Add gotoAndStop(“frameLabel); actions to each button, telling Flash to go to the frame label specified in the annotations when that button is released.
7.1. Click on the first keyframe of the Interaction layer.
7.2. Drag an instance of the invisibleButton onto the stage and drop it over the “Edit” button in the screen design. It should appear to be a transparent, blue area. You can use the Free Transform Tool (which you can find in the Tools bar) to make it cover just the area that should be clickable.
Instances are unique occurrences of symbols in your Flash movie. You can drag as many instances of a symbol into your movie as you like. If you update the symbol, all of its instances will be updated as well, however, certain properties (such as scaling and positioning) can be customized on an instance-by-instance basis. Later you’ll learn how to name instances so you can refer to them specifically using ActionScript.
7.3. Next you are going to make the button interactive. When you add an action to an object (vs. to a keyframe, as you did earlier), it must be contained within an “Event Handler” so that Flash knows when to execute the action. With the button selected, type this Event Handler in the Actions Panel:
on(release) {
}
Event Handlers are used to specify behaviors that trigger actions. Actions contained within an event handler’s curly braces will be triggered only when the event preceding them occurs (e.g., when an button is pressed and when it’s released).
7.4. All of the actions that should happen when the button is clicked and then released should go within the two curly braces. You’re going to use the gotoAndStop(“frameLabel”) function to tell the prototype to go to the frame labeled “W02” when the button is clicked and released.
on(release) { // When this event occurs…
gotoAndStop(“W02”); // these actions should be triggered.
}

Curly braces can be used to group statements.

Comments that don’t affect the code can be added by preceding comment text with two forward slashes.

7.5. To ensure that the main timeline is controlled (vs. the timeline of the button the script is attached to), you can precede gotoAndStop with the name of the timeline you’re targeting. The main timeline is referred to as the “_root” in ActionScript. The final script should read:
on(release) {
_root.gotoAndStop(“W02”);
}

Actions are context-sensitive. They act on whichever movie or timeline they are attached to. If actions are placed in the main timeline, they’ll act on the main movie. If they’re placed on a timeline within an object, they’ll only act on that object unless otherwise specified.

To target specific timelines and objects, refer explicitly to the main movie as “_root” and other objects by their assigned “Instance Names.” If you’re unsure which object an action applies to, use explicit targets to ensure your actions will work as intended. You’ll learn more about Target Paths later.

7.6. If you go to Control > Test Movie (Ctrl+Enter on PC, Apple+Enter on Mac), you should see that the button symbol is invisible, but that you can still click on it to go to frame “W02.” It gives you the impression that the “Edit” link is working—your pointer should change to a hand cursor, and clicking the link should take you to frame “W02.”
7.7. On keyframes W02 through W04, wherever you see a green, “go to X” callout, add an invisible button with the appropriate script. The easiest way to do this is to copy and paste the button you’ve already created. This creates a new instance of the button while preserving the script you’ve added to it. All you have to do is change the destination frame label.
7.8. Test your prototype (Ctrl+Enter on PC, Apple+Enter on Mac). You should be able to follow the trail of green callouts through the first five frames.

That’s all there is to creating a basic click-through using Flash. The prototype at this point should be comparable to what you could create in Visio, PowerPoint or Acrobat.

What makes Flash a worthwhile prototyping tool, however, is that it makes it easy to add realism and “smarts” to your prototypes. Flash’s “Components Library” offers a robust collection of customizable user interface components that can be dropped into your prototype and used as they are to add realism (e.g., a text field you can actually type in) or programmed using ActionScript to serve as fully-functional interface controls. Using one of these components and some simple ActionScript, you’ll next learn how to add basic logic to your prototype.

Adding a conditional button

There are many applications for conditional buttons in prototypes, including demonstrating error handling.
8. Add a CheckBox component named “termsBox” to frame “W05” of the “Interaction” layer.
8.1. Select the keyframe in the “Interaction” layer above the frame labeled “W05.”
8.2. Open the Components library (Window > Components).
The Components Panel contains a special library of user interface objects, such as radio buttons and combo boxes, and have customizable properties. These properties can be edited in the Parameters tab of the Properties Panel and/or changed using ActionScript.
8.3. In the “User Interface” folder, you’ll find the CheckBox component. Drag it onto the screen and place it over top of the check box in the image.
8.4. In the Properties tab, give the Instance Name, “termsBox” to this checkbox.
An Instance Name can be assigned by selecting an instance and entering a unique name in the Instance Name field in the Properties Panel. Since a symbol in your library can be used in your Flash movie multiple times, each occurrence needs to have a unique name if you want to address it using ActionScript.
8.5. With the check box selected, in the Properties Panel, click the Parameters Tab. Select the “Label” field in the Parameters Tab and delete the label text.
The Parameters tab of the Properties Panel is where you can edit the special properties of components. Each property is listed on a separate line.
9. Create an invisible button that determines whether the check box is selected or not and sends the prototype to the appropriate screen.
9.1. Drag an invisible button over the "Upload Picture" button on frame “W05.”
9.2. Select this button, and in the Actions Panel, add an event handler:
on(release) {
}
9.3. Within this event handler, you’re going to add a conditional statement, an “if Statement,” to check whether “termsBox” is selected. The condition contained within the “if statement” will be tested when the event (on release) occurs. It is constructed as follows:
on(release) {
if(CONDITION) { // If this condition is met…
// perform all actions contained within these curly braces.
}
else { // Otherwise…
// do these actions.
}
}
The If Statement describes a condition that must be met for certain action(s) to be performed. It can optionally be followed by an “else” statement specifies what to do otherwise.
9.4. The condition that you’re checking for is whether the “selected” property of “termsBox” is “true.” To refer to properties of objects, use the object’s target path, followed by the name of the property (for example, _root.termsBox.selected).
Target Paths are like web URLs or file paths, only they use dots (.) instead of slashes to indicate hierarchy. Eventually you’ll be using ActionScript to address movies inside of other movies. An easy way to do so is using “absolute paths,” which indicate the location of an object relative to the main movie (the “root”) using objects’ instance names. (For example, to address an object with the instance name “spokes,” you might write: _root.car.wheels.spokes) You can also use “relative paths,” which you can learn more about in Flash’s documentation.
Properties of an object are special keywords that Flash recognizes. You can evaluate or change properties of an object using ActionScript. Components, movie clips and other types of objects all have unique properties. You can look up a particular object type’s properties and their possible values in Flash’s documentation.
9.5. To test whether something is equal to something else, you’ll use the “equals” operator, which consists of two equals signs. Your condition will read:
on(release) {
if(_root.termsBox.selected == true) {
}
else {
}

}
Operators are used in If Statements to compare one value to another in the format, “if(x OPERATOR y).” The most common operators are:
== equals
> is greater than
< is less than
!= is not equal to
<= is less than or equal to
>= is greater than or equal to
9.6. The complete script that will be placed on the button, which includes the actions that should happen when the condition is met or not met, is:
on(release) {
if(_root.termsBox.selected true) {
_root.gotoAndStop("W07");
}
else {
_root.gotoAndStop("W06");
}
}
9.7. Repeat steps 8 and 9 on the next keyframe, “W06,” only name the checkbox “termsBox2” and add this script to the button:
on(release) {
if(_root.termsBox2.selected == true) {
_root.gotoAndStop("W07");
}
}
10. Test your prototype (Ctrl+Enter on PC, Apple+Enter on Mac). Try selecting the checkbox and clicking the button. Test it again and see what happens when it is not selected. You should be able to complete the entire first part of the prototype.
10.1. If it doesn’t seem to work, you may want to:
10.2. Make sure your scripts were attached to the button, NOT to the checkbox or to the keyframe.
10.3. Check that your syntax is correct (don’t forget your {,}, and ;).
10.4. Ensure that your buttons point to the correct frame labels.

Exporting your prototype

If you made it this far, good job! You’ve learned some of the fundamentals of Flash and ActionScript and have created a simple, yet smart prototype. All that’s left is exporting the prototype as a stand-alone file that can be shared with clients and usability testers. To do this:
11. Go to File > Publish Settings. Choose “Windows Projector” or “Macintosh Projector” (or both), enter a file name, and press “Publish” to create a standalone, self-executing file of your prototype. It will be created in whatever folder the Flash file is in.
While the annotations make the prototype easy to test and navigate, it wouldn’t be very challenging for test participants! To make a version of the prototype that is not annotated:
12. Remove or hide the annotations in the software you used to create the screens.
13. Export or save each of the screens to a new folder using the same file names that you used before. Flash doesn’t care what folder an image comes from, if it has the same name, it considers it to be the same image.
14. In Flash, use “Save As…” to create a new copy of the prototype.
15. Go to “File > Import > Import to Library” and import all of the final images at once (use Ctrl+A or Apple+A to select all). Since the names of these images match the names of the images you imported previously, Flash will ask you whether you want to replace the existing items. Since this is exactly what you want, select “Replace existing items” and press “OK.”
16. Click through each keyframe to make sure the prototype looks right (the buttons are aligned properly and the screens are updated).
17. You can now publish another copy of the prototype without the annotations by going to “File > Publish Settings” and giving the files new names.
Open Andrzejewski_Prototype_Mac.app or Andrzejewski_Prototype_Windows.exe to see the final prototype. You can also open FlashPrototype_Completed.fla from Andrzejewski_SourceFiles.zip to see what the final Flash file should look like.

Resourcefulness, creativity, and experimentation

Using only the principles learned in this tutorial and a little resourcefulness, creativity, and experimentation, you can create quite robust prototypes. In fact, using just what you’ve already learned, you could conceivably simulate rich interactions ranging from fly-out menus to type-ahead search.

Look for a follow-up article that will show you more examples of what’s possible.

The wonderful thing about Flash is that Flash prototypes can be as simple or as complex as they need to be. Start building your click-through prototypes in Flash. Once you’ve built a few of those, try a scenario that involves a little logic. When a more complex situation arises (“Could you make this area turn yellow when you drag that icon over it?”), do some research on sites like ActionScript.org to see if you can find an easy way to show it or at least fake it.

While you may not be able to take full advantage of Flash’s prototyping potential immediately, the benefits of using Flash, even when creating simple prototypes, make it a worthwhile addition to any interaction designer’s toolkit.

Appendix A: The Flash Interface

Note: If you don’t see some of these panels, use the Window menu to locate and turn them on.
The Stage is your visual workspace or canvas. This is where you’ll specify where objects appear. Objects in the grey area outside the stage will not be visible when the exported flash movie is viewed at the correct size.
The Timeline is where you define when objects appear or disappear from the stage. The timeline contains frames and keyframes which can be on multiple, independent layers.
Frames are displayed as blocks. They are grey when they contain content and white when they are empty.
Keyframes are frames marked with circles or dots. A keyframe is a frame where a change can occur without affecting the previous frames. Changes made on keyframes persist until the next keyframe unless “tweening” is used to fill in the blanks. You can also add commands (ActionScript) to keyframes, which will be executed when the player reaches that frame.
Frame Labels can be assigned to keyframes so that they can be referred to using ActionScript. It is generally better to refer to frame labels in ActionScript than to frame numbers because frame numbers are subject to change as you add or remove frames.
The Edit Bar (Navigation Area) indicates which timeline you are currently viewing. In this tutorial, you will generally be working on the main timeline, labeled “Scene 1” by default, but you will eventually be creating objects that have their own, independent timelines. These objects can be nested inside of each other. When you are inside an object’s timeline, a breadcrumb trail will indicate where you are in the grand scheme of things, e.g., Scene 1 > CarObject > WheelObject.
The Library contains symbols—the “actors” that appear on the stage. Symbols are objects that can be used and reused. They are similar to Shapes in Visio and Stencils in Omnigraffle. Symbols include imported content, Movie Clips (objects that can have their own, independent timelines), Buttons (special movie clips with four frames in which four possible button states can be created), and Graphics (objects that may contain drawings and/or imported images).
Instances are unique occurrences of symbols in your Flash movie. You can drag as many instances of a symbol into your movie as you like. If you update the symbol, all of its instances will be updated as well, however, certain properties (such as scaling and positioning) can be customized on an instance-by-instance basis. Later you’ll learn how to name instances so you can refer to them specifically using ActionScript.
The Components Panel contains a special library of user interface objects, such as radio buttons and combo boxes, that have customizable properties. These properties can be edited in the Parameters tab of the Properties Panel and/or changed using ActionScript.
The Actions Panel is context-sensitive—it shows/allows you to add scripts to the last frame or instance that you selected. Look at the tab name near the bottom of the Actions Panel to verify what you are adding actions to.
The Properties Panel is also context-sensitive—it shows/allows you to set properties for the last frame or instance that you selected. This is where you can assign frame labels to frames and instance names to instances. The Parameters Tab of this panel is where you can edit the special properties of components. Each property is listed on a separate line.
The Tool Bar contains tools you can use to create and manipulate graphics and objects on the stage.

Appendix B: ActionScript Recap

You don’t need a deep understanding of ActionScript to create convincing prototypes. Simply understanding the following principles, all of which you’ve already put into practice in this tutorial, can take you a long way.

ActionScript 2.0 vs. ActionScript 3.0

The latest version of ActionScript is ActionScript 3.0, a much more sophisticated but unfortunately a little harder to comprehend rendition of the language. Because AS 2.0 is a little more direct and intuitive (you can add scripts directly to buttons and objects), I recommend starting there. In fact, if you’re only using Flash for simple applications (like most prototypes will be), AS 2.0 is all you really need. If you eventually want to catch up with the AS 3.0 trend, understanding AS 2.0 first can help you make the conceptual leap to AS 3.0.

When working in ActionScript 2.0, you’ll want to make sure that tutorials and scripts you find online and in books are compatible. Look for tutorials written for Flash MX 2004, Flash 8, or Flash CS3 using ActionScript 2.0.

ActionScript Grammar

ActionScript is case sensitive. Semicolons should be used at the end of every statement (generally every line). Curly braces can be used to group statements. Comments that don’t affect the code can be added by preceding comment text with two forward slashes.

Making something happen using ActionScript

First, when do you want it to happen?

  • When a particular frame is reached: Frame Actions are attached to keyframes and are triggered when that frame is reached. For example, you might select the last keyframe in a movie and add a “stop();” action so that the movie will not loop when it reaches the end.
  • When a specific event occurs: When you add actions to objects on the stage, you must use one or more event handlers to specify exactly when they should be executed. Event Handlersare used to specify behaviors that trigger actions. Actions contained within an event handler’s curly braces will be triggered only when the event preceding them occurs (e.g., when an button is pressed and when it’s released). Useful event handlers include:
    on(press) { } on(release) { } on(rollOver) { } on(rollOut) { }
  • The above, but only when a particular condition is met: Within Frame Actions and Event Handlers, you can add additional conditions that must be met for an action to be performed. Note that the condition will be evaluated only when the frame is reached or event occurs. The If Statement describes a condition that must be met for certain action(s) to be performed. Its form is: “if(CONDITION) {ACTIONS}”It can optionally be followed by an “else” statement specifies what to do otherwise. Operators are used in If Statements to create conditions by comparing one value to another in the format, “if(x [operator] y).” The most common operators are:

    == equals
    > is greater than
    < is less than
    != is not equal to
    Multiple conditions can be combined using the operators:
    && and
    || or
    For example, if(x false && y false) means “if x is false AND y is false.”

Next, which object or timeline are you commanding?
  • Actions are context-sensitive. They act on whichever movie or timeline they are attached to. If actions are placed in the main timeline, they’ll act on the main movie. If they’re placed on a timeline within an object, they’ll only act on that object unless otherwise specified.
  • To target specific timelines and objects, refer explicitly to the main movie as “_root” and other objects by their assigned “Instance Names.” An Instance Name can be assigned by selecting an instance and entering a unique name in the Instance Name field in the Properties Panel. Since a symbol in your library can be used in your Flash movie multiple times, each occurrence needs to have a unique name if you want to address it using ActionScript. If you’re unsure which object an action applies to, use explicit targets to ensure your actions will work as intended.
  • When objects are nested inside each other (every object is technically nested inside the main movie, or the _root), address them using their complete “target paths.” Target Paths are like web URLs or file paths, only they use dots (.) instead of slashes to indicate hierarchy. Eventually you’ll be using ActionScript to address movies inside of other movies. An easy way to do so is using “absolute paths,” which indicate the location of an object relative to the main movie (the “root”) using objects’ instance names. (For example, to address an object with the instance name “spokes,” you might write: root.car.wheels.spokes) It doesn’t hurt to get in the habit of always referring to the main movie as “_root”—as this becomes important when using embedded movie clips.You can also use “relative paths,” which you can learn more about in Flash’s documentation.
Finally, what do you want to happen?

  • You can use Flash’s many built-in functions to perform all kinds of actions. Functions are built-in actions that you can call on using keywords. These commands are keywords followed by parentheses in which specific details can be added if necessary. Some useful functions for prototyping include:

appendix_table1

  • You can also change properties of an object using ActionScript. Properties of an object are special keywords that Flash recognizes. You can evaluate or change properties of an object using ActionScript. Components, movie clips and other types of objects all have unique properties. You can look up a particular object type’s properties and their possible values in Flash’s documentation. You can use the “equals” sign to change a property of an object. For example, to change the text of a text box called “welcomeMessage” you might write:

welcomeMessage.text = "Hello!"

 

Some useful properties include:

appendix_table2

 

 

Flash workshop at UX Week

Alexa will be leading a workshop on Flash Prototyping (http://www.uxweek.com/workshops/prototyping-with-flash) at UX Week (August 12- 15, 2008) in San Francisco. This workshop offers the impetus, skills and inspiration you need to get started with Flash prototyping. Come and learn how to bring your wireframes to life!
Use discount code FOAA for 15% off.

PDF Prototypes: Mistakenly Disregarded and Underutilized

Written by: Kyle Soucy

Creating a clickable PDF to prototype a new design is not a new concept, but it is a valuable tool that is often overlooked and underutilized. While working over the years with other designers, information architects and usability professionals, I’ve noticed that many of my colleagues believe the same fallacies about the limitations of PDFs. Contrary to popular belief, you can do more than just create links and interactive forms with PDFs; you can also add dynamic elements such as rollovers and drop-down menus, embed audio and video files, validate form data, perform calculations and respond to user actions. PDF prototypes have the ability to replicate most interactive design elements without investing a lot of time and effort.

Debunking common misconceptions about PDFs

Misconception #1: Dynamic elements can NOT be created in a PDF.

Image rollovers and similar dynamic effects can be created in a PDF without even writing a line of code. Although they may not be typically found in a PDF, fore- and background color changes, tooltips, pop-up boxes and other common DHTML scripts can be easily simulated in a PDF. (See an example of a PDF prototype for an eCommerce website.)
Screenshot of eCommerce site pdf.

Misconception #2: PDFs are only good for prototyping page-based applications.

Many people believe that a PDF can not be used to prototype screen-based applications, but this is simply not true. You can easily mimic certain Ajax-like functionality by updating only parts of the PDF instead of an entire page. PDFs also have the ability to hide or show certain form fields and layers based on a user’s actions. (See an example of a PDF prototype for an eCommerce checkout form.)

Note: PDF layers are only supported if the original document was made with InDesign, AutoCAD, or Visio, with the compatibility set to Acrobat 6 (PDF 1.5), and with “Create Acrobat Layers” selected in the export PDF dialog box. The example above is not using layers; only hidden form fields.
Screenshot of eCommerce checkout form pdf.

Misconception #3: PDFs can NOT include multimedia.

Audio and video files (including Flash movies) can be directly embedded into your PDFs for enhanced interactivity. Furthermore, you can select to have these files play automatically in response to specified triggers (such as when the user clicks on the “Product Demo” button). With a little creativity, you can mimic just about any interaction with an interface by taking advantage of this excellent feature. Integrating video clips into PDF usability reports is also an excellent way to report your findings. (See an example of a PDF usability report with integrated video.)

Note: This example PDF prototype requires version 6.0 or later of Acrobat or Adobe Reader to view the media files. Please get the latest version of Acrobat Reader. When you add a movie or sound clip to a PDF document, you choose whether the clip is available in Acrobat 6.0 or later, or in Acrobat 5.0 or earlier. If you select Acrobat 6, the movie clips can be embedded in the actual PDF document.
Screenshot of user testing report pdf.

Remote User Testing with PDF Prototypes

One of the best benefits of a PDF prototype is that it can be tested remotely. Paper prototyping is such a wonderful method, but one of its biggest drawbacks is that you can’t test the prototypes remotely. By using clickable PDFs, we bring our paper prototypes to life and still make it possible to test remotely with users, early in the development cycle. For websites or computer applications, this can be a huge advantage since the user doesn’t have to stretch their imagination by playing with paper; they get to interact with the prototype on a computer by using an Internet browser, the same way they would with the real end product.

All of the benefits of paper prototyping and remote testing is combined when using PDF prototypes. You’re able to collect invaluable feedback from users, in their natural environment, no matter where they are geographically located, without investing a huge amount of time or money in coding or designing your product.

When to Consider Using a PDF Prototype

Using a PDF prototype is a great option when you want to gather quick feedback on a design, early in the development cycle. It’s an optimal prototyping medium if you have minimal coding, Flash or graphic design skills. It’s important to remember that, just like with paper prototyping, a PDF prototype is meant to be low-fidelity. If you want to achieve a much more detailed and functional prototype, than I would highly suggest creating a CSS, DHTML or otherwise coded prototype.

Creating a PDF Prototype

Creating an interactive PDF couldn’t be easier. You will need to install Adobe Acrobat to convert your existing documents into PDFs. If you want to create interactive forms you would need Adobe Acrobat Professional.

There are multiple ways that you can create a PDF. You can start by working from your preferred wireframing program. Once you open up your wireframe file, simply choose to print your document and select the Adobe PDF printer. Once your document is converted, you can begin adding your desired level of interactivity into your PDF prototype using Adobe’s advanced editing tools (choose Tools > Advanced Editing).

Image of advanced editing toolbar.
Advanced editing toolbar.

If you prefer the ease and quickness of hand drawing paper prototypes, you can easily scan your drawings and convert them into interactive PDFs as well. (See example of a hand drawn PDF prototype.)
Screenshot of paper sketch pdf.

Creating Links

Creating a link to another page in your PDF prototype is very easy. Follow the steps below to learn just one of the many ways that this can be done. Links can also be set to open up a file or go to a web page.

  1. Choose Tools > Advanced Editing > Link Tool, or select the Link tool ( Link tool icon ) on the Advanced Editing toolbar.
  2. Drag around the area you want to have a link to create a rectangle. This is the area in which the link is active.
  3. In the Create Link dialog box, choose the settings you want for the link appearance.
  4. To set the link action to link to another page, select Go To A Page View, click Next, set the page number and view magnification you want in the current document or in another document, and then click Set Link.

Creating Image Rollovers

To create a rollover, you will need to have the image(s) you will be using already created and ready to insert into your PDF. Acrobat’s ability to hide or show form elements and the fact that buttons can have alternate appearances, determined by mouse behavior, makes it possible for us to create a rollover. The following steps will guide you through making a button, changing its appearance (essentially turning your button into your imported image file), and adding button actions based on mouse actions.

  1. Using the Button tool ( Button tool icon ), drag across the area where you want the rollover to appear. You have now created a button.
  2. While the Button tool is still selected, double-click the button you just created to open the button dialog box.
  3. In the button dialog box, click the Appearance tab. If needed, deselect Border Color and Fill Color.
  4. Next, click the Options tab and choose Icon Only from the Layout menu.
  5. Choose Push from the Behavior menu, and then choose Rollover from the State list.
  6. Click Choose Icon, and then click Browse. Navigate to the location of the image file you want to use and then click OK to accept the previewed image as a button.
  7. Select the Hand tool and move the pointer across the button. The image field you defined appears as the pointer rolls over the button.

Adding Movie Clips

Follow the steps below to add a movie clip to your PDF prototype. You will need to have the video(s) you will be adding already created and ready to insert into your PDF. Buttons can also be created in your PDF to control playing, stopping and pausing the video clip.

  1. Choose Tools > Advanced Editing > Movie Tool, or select the Movie tool ( Movie tool icon ) from the Advanced Editing toolbar.
  2. Drag or double-click to select the area on the page where you want the movie to appear. The Add Movie dialog box appears.
  3. Within the dialog box, select Acrobat 6 Compatible Media to embed your movie clip directly into the PDF Prototype.
  4. To specify the movie clip, type the path or URL address in the Location box, or click Browse (Windows) or Choose (Mac OS) and double-click the movie file.
  5. Click OK, and then double-click the movie clip with the Hand tool ( Hand tool icon ) to play the movie.

Adding Forms

A PDF form contains interactive form fields that the user can fill in using their computer. A PDF form can collect data from a user and then send that data using email or the web. After the user fills out the form, you can choose to have them print, email or submit their data online to a database.

In order to create interactive forms you will need Adobe Acrobat Professional. The steps below will discuss adding form fields to an already existing document. You can also create a new form by using Adobe Designer. Designer is an application that comes with Adobe Acrobat professional. Designer lets you lay out a form from scratch (static parts in addition to interactive and dynamic form elements) or use a form template.

Forms toolbar
Forms toolbar.

  1. Choose Tools > Advanced Editing > Show Forms Toolbar.
  2. On the Forms toolbar, select the form field type that you want to add to your PDF.
  3. Drag the cross-hair pointer to create a form field of the required size and the Properties dialog box for that form field will appear.
  4. In the dialog box, set the form field’s property options, and then click Close.

You’ll notice a lot of different options in the Properties dialog box depending on which form element you are creating. Form elements can be marked as required to perform client-side error checking in your PDF form. Text fields can be checked for spelling and you can also specify the format of the data entered (such as number, percentage, date, time, etc).

Giving PDFs a Try

The ability to add dynamic elements and multimedia to a PDF makes it a great tool for rapid, low-fidelity prototyping. For me, one of the best perks of using a PDF prototype is that it’s quick and easy to make changes, which is especially useful when I want to tweak a design between rounds of user testing.

A PDF is NOT the perfect prototyping medium for all projects, but I hope that knowing the possibilities of what you can do with a PDF provides you with another tool for your prototyping toolbox.

References

Interactive Prototypes with PowerPoint

Written by: Maureen Kelly

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?”

Overview

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.

BasicInteractivity_1_v2.gif

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.
HyperlinkingText_1.gif
  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.
HyperlinkingText_2.gif
  1. Voila! The text is now hyperlinked. View the PowerPoint as a slideshow to see it in action.
HyperlinkingText_3.gif

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.)
CreatingButtons_1.gif
  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.
CreatingButtons_2.gif

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…”
BackButton_1.gif
  1. In the “Action Settings” dialog box, choose the “Hyperlink to:” radio button.
  2. Select “Last Slide Viewed” from the list.
BackButton_2.gif
  1. That’s it! Now, when viewed in slideshow mode, this link will take the user back to the screen he just viewed.
BackButton_3.gif

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.”
Mouseover_1.gif
  1. On the “before” slide, right-click on the item that will trigger the mouseover effect, and select “Action Settings…”
Mouseover_2.gif
  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.
Mouseover_3.gif
  1. second dialog box will let you select the “After” slide.
Mouseover_4.gif

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.
DisableSlideshow_1.gif

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

Conclusion

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.