Stop Counting Clicks.

The Myth is Busted. by:   |  Posted on

Every user interaction is a decision. Every decision can lead to an exit. So the more options we offer, the more exit opportunities we create, which will reduce the probability of conversion. Right? Well…

In fact, the number of interactions a user makes is in no way directly related to conversion rates. It might be a surprise, but there is no statistical evidence to prove that this widely held belief is true. When establishing the amount of clicks that are appropriate for a task, it actually solely depends on the requirements regarding complexity, security, and usability. In this article, we’re going to share with you how we use these requirements to assess how many clicks are appropriate on a page. Once we started looking at clicks through this lens, we were able to increase conversion, reduce task time, and increase customer satisfaction. 

The 3-click rule is dead

The “3-Click Rule” has been causing a ruckus for decades. In 2001, Jeffrey Zeldman suggested in his book »Taking Your Talent to the Web« that all information should be available on a website within three clicks. If you take a look at the state that web design was in back then, this isn’t a big surprise. It seemed like the more information that was on the page, the better. At that time of course, the data on interactions with digital services was quite scarce. 

Continue reading Stop Counting Clicks.

Integrating Prototyping Into Your Design Process

by:   |  Posted on
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

by:   |  Posted on

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

by:   |  Posted on

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

by:   |  Posted on

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

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

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.

Practical Applications: Visio or HTML for Wireframes

by:   |  Posted on

As information architects attempt to carve their niche in the world of web design, they are forced to balance the needs of several disciplines at once:

  • Clients require their business objectives be met;
  • Engineers require designs that do not exceed technical limitations;
  • Visual designers require specific skeletal work, but not direction;
  • Quality assurance teams require infinite detail;
  • And project managers require everything to take shape within the scope of the project.

All of these considerations must take place while keeping the goals and needs of the end user in mind. Once requirements have been gathered and features defined, IAs use a primary tool to fulfill these specific needs: wireframes.

“Clients become engaged when they can interact with HTML wireframes. Clients not only enjoy the process more, but they also get a better contextual understanding of the features than with paper prototypes.”Wireframes provide specific, screen-level information, detailing which elements need to appear, the implementation of these elements, and the hierarchy among them. They also describe the various navigation mechanisms and help orient the viewer to the current location within the proposed application. They suggest an optimized layout, but often do not dictate these constraints to a visual designer.

As wireframes have such a varied and diverse audience, both internal and client, the format within which they are developed has been an often-debated topic. Currently, there are two primary schools of thought on this issue. One touts Microsoft’s Visio, a diagramming program available on the market since 1991. The other firmly believes in HTML-based wireframes (also described as “high-fidelity prototypes”). While the two schools are not mutually exclusive, an individual IA tends to settle on a preferred method and work with it as much as possible.

(Author’s note: While there are other wireframing options such as Microsoft Power Point and Norpath Elements Studio, the two techniques described in this paper are the most often used. As the popularity of other techniques grows, their merits will need to be compared with the status quo.)

As design organizations (design shops, user experience groups within companies, etc.) mature, they inevitably run across the debate of Visio versus HTML wireframes. The decision for one over the other is never a clear-cut one since, as with all things IA-related, it depends. This article seeks to sort out the issues in this debate by describing the pros and cons of each technique and pointing out specific situations where one may be more effective than the other.

Pound for pound: The contenders weigh in

Interactivity
The greatest and most obvious benefit of HTML-based wireframes is their interactive nature. The web application can “come to life” in the form of these clickable wireframes. The development team has the opportunity to click through a mock-up of the site, allowing them to make quick determinations about issues with flow and navigation. The client has the opportunity to view an early version of the site and determine whether it is going to meet their business objectives, as well as whether they have the resources to populate all the proposed features with valuable content.

Sean Gallivan, creative director at Braun Consulting, notes, “Clients become engaged when they can interact with HTML wireframes. Clients not only enjoy the process more, but they also get a better contextual understanding of the features than with paper prototypes. This understanding gets earlier and more complete feedback.”

Visio, though a static diagramming program, has attributed its increased use in the web design community to its hyperlinking feature. Any element on any page can be hyperlinked to any other element or page within the document, to an external file, or URL. Additionally, Visio has the ability to export the entire wireframe deck to HTML, allowing developers and clients to click through a Visio wireframes set fairly easily.

Working with visual designers
HTML-based wireframes can cause some real problems in the development process. Most important is the issue of setting the client’s expectations about how the final application (or site) will appear. Wireframes, by their nature, do not dictate exact screen layout. They imply hierarchy between elements and suggest screen layout but, ultimately, it is the visual designer’s skill and talent that determines the final “look and feel.” By developing high-fidelity prototypes, the IA can inadvertently bind the designer into a screen layout that the client has seen in the wireframes. This can result in a less than optimal design and cause strain within the development team.

It is an often-held misconception that developing wireframes in HTML will allow the team to see what elements of the design end up “above the fold.” As wireframes are intended to show the skeleton of the application and not the full graphics-intensive version, making this determination based strictly on wireframe presentation is premature. Costly redesign decisions can be avoided by saving judgment on this issue until the visual designer has had a chance to exercise his/her skill.

The basic appearance and geometric nature of Visio diagrams help limit the client’s expectations as to the final layout and design of the application. By not having a mental picture of what the site will look like, the client can review the visual design in an objective manner. This leaves the creativity with the visual designer, as blocks and shapes representing specific page elements do not dictate a certain look and feel. The ability to quickly shift these elements around the screen also offers a flexibility not found with HTML wireframes. All of these elements combine to form the true essence of what wireframes should be: the skeleton of the application.

Client review
Often, a client likes to take deliverables with them for review when they leave the office. Even with today’s paperless trends, it is still very convenient to review wireframes on paper. This allows careful studying of the prototype without the exacerbated eyestrain caused by long-term monitor fixations. Also, writing notes directly on a specific wireframe is a convenient way to convey edits and suggestions. HTML wireframes do not print in a fashion that guarantees a complete wireframe will fit on one sheet of paper. Usually, the page breaks occur at random points and cut off content midstream, encumbering the review process.

As a diagramming program, Visio behaves within the context of printed “pages.” Because of this, designs can be constrained to one page or a deck of pages. Each page can be developed to contain the information for one screen of an application. This allows for easy presentation and review of wireframes. Pages are noted by either their name or number and follow a sequential order determined by the author.

Visio allows for clean, logical printing of the wireframes. Each page equals a screen. This allows clients, both external and internal, to print a wireframe deck and review it on the road, against the development environment or as a final QA assessment. Notes can be written directly on the printout and handed to an IA for modifications.

Exporting is another strength of Visio. While Visio does not exist on every desktop or in the Macintosh world, the myriad of formats that can be generated from it provide more than adequate coverage for any conceivable file format need. These formats range from HTML to PDF (with Adobe Acrobat Distiller) to EPS to JPG.

Maintenance/iteration
Using popular development tools such as Macromedia’s Dreamweaver, information architects have the ability to create site templates that function as shells for pages of similar type. These templates can be configured to contain a consistent area dedicated to screen-specific information. Elements such as screen title, version, author, page logic notes, and callouts can be listed in one convenient location. This section, however, can be very distracting when the prototype is used in a usability test. Removing this section would require recoding all the templates or creating a duplicate set of wireframes without it.

Templates also allow the IA to make global updates to various screens that share the same template. The main drawback here is that there is no way to create a global template. In a situation where a change needs to propagate throughout a site, each template must be updated to reflect the change. Occasionally, this problem can be solved using a global “find and replace” feature, but this is not always the case.

On the issue of maintenance, HTML files must be linked to each other in order to maintain their interactive strengths. This results in fixed filenames for each wireframe. As updates are made and versions updated, it is not possible to update the filenames with version numbers without adjusting the hyperlinks on every screen that links to it. Whether it’s for versioning or other reasons, a changed filename can become a tedious chore to update throughout an extensive wireframe set.

Performing some of the same duties as Dreamweaver’s templates, Visio additionally offers the concept of “layers,” which allows for templates to build on top of one another.

For example, the base layer can contain nothing but project information—project name, author name, file save date, copyright, etc. This layer can then be used as the background for another layer which could contain, for instance, global navigation elements. The benefits here are that each layer can be used individually or can build upon another layer. When a global change needs to be made, the appropriate layer is simply adjusted and the change is applied to all pages and layers using that layer as a background. There is no danger of editing the layers within each page as their elements are rendered uneditable.

Finally, as one becomes more expert with Visio and begins to use a consistent array of shapes and elements, a custom stencil can be created. This stencil allows all of the commonly-used elements to reside in one place throughout the design process. This provides a consistent palette for the IA to use when building similar applications (websites) and is a considerable timesaver.

User testing
The interactive nature of HTML wireframes increases the ease with which the site can be user tested. Participants have something with which they can interact in real “web time.” Micah Schwalb, Senior Information Architect at Braun Consulting, touches on this point by mentioning that, “By having low-fidelity mock-ups of the page built in HTML, we can quickly usability-test those models with our target population (or even people off the street) without having to spend the time to explain the concept of a paper prototype.” Transactional applications can benefit from this greatly, as test participants can give instant feedback on the process flow, and modifications can be made long before the project moves into the build phase. Specific implementations of features can also be tested to ensure the best mechanisms (drop-down menus, radio buttons, checkboxes, etc.) were selected.

The ability to export Visio decks into clickable image maps proves handy when performing early usability tests. Process flow and site navigation can be tested effectively, but Visio really shines when testing labels. Test participants often note the “lo-fi” nature of HTML’ized Visio wireframes and seem to focus primarily on labeling rather than specific content.

However, testing of Visio wireframes does not yield optimal usability testing results. The results that are collected need to be analyzed carefully and modifications need to be made cautiously because it is typically the flow and labeling that is being tested and not the entire user experience.

Notation
During the design process, it is often necessary to add descriptions to features with the use of notation. This notation bears direct relevance to a specific element on the wireframe and needs to be tied to it. HTML wireframes make it difficult to place notes at exact locations on the screen. While the actual “action” (e.g., drop-down menus) that HTML elements can portray solves this issue some of the time, there are other instances, such as length of text entry areas that need to be noted elsewhere. These notes would most likely be implemented in a “screen notes” section, where they lose their immediate connection to the item they describe.

Through the use of background layers in Visio, IAs can set aside a consistent area on each page dedicated to screen notes. This area remains constant and offers the same page logic elements described in the HTML discussion. Additionally, since there are no table-based constraints as there are in HTML, callouts and notes can be made directly on the diagram and visually tied directly to the element they are describing. For example, the contents of a drop-down menu can be clearly listed without the need for any further examination by using a callout tied to a drop-down element.

Process
Proponents of HTML wireframes believe that, if developed according to company standards, the HTML can be reused to build the actual site. This would require the IA to have expert coding skills that take advantage of the latest developments and trends in coding such as XML, XHTML, and CSS. However, by building a high-fidelity prototype that is meant to be the codebase for the actual application, the IA has less room to experiment with various architectures and ideas as changes could alter code marked for reuse. Again, the “screen notes” section could not be implemented as it would not be part of the final application. This would relegate any supporting documentation to an external document which would then need to be compared with the prototype.

On a different process note, Visio has a tendency to appear as an extra step in the process during smaller projects and within smaller user experience groups. This can cause some pushback from the client questioning why this perceived “extra” step is being done. It is important to remember that, in a small-scale situation, developers often wear many hats, leading to the potential elimination of this step. However, in a more robust project, this step is critical in conveying the needs of the client along with the needs of the user to the engineering and design staff. It ensures that all elements are accounted for and provides a tangible record of what will be developed before coding begins.

Accessibility
Accessibility of HTML wireframes is a non-issue since all one needs to view them is a web browser. While the clean-printing nature of Visio is one of its strengths, viewing Visio files requires the user to have the program installed on their machine or to export the Visio deck into one of many formats, some of which can subsequently be viewed in a web browser.

Context of use
So when do HTML wireframes work well? There are several situations where this technique can really shine. Primarily, HTML wireframes work well on smaller projects and internal projects. Projects that require minimal visual design or adhere to a corporate intranet standard can benefit from this technique as it will speed up delivery. Data-heavy designs with high information density can be better illustrated using HTML wireframes, and they allow developers to see flow and density issues early in the project lifecycle. They can also be used in conjunction with other types of wireframes to illustrate a particularly complex transactional process. Finally, HTML wireframes can aid resourcing crunches, especially if the user experience group is small or their resources are limited. One multi-skilled IA can often handle developing wireframes and site authoring, combining the two tasks into one.

Visio’s true merits surface in robust projects with a large screen count. It can efficiently and effectively convey the implementation of complex features and illustrate the flow of transactional components. When “webifying” an existing thick client, Visio is an excellent intermediate step when attempting to translate features into an HTML-based environment. It simplifies the review process for clients, allowing them the freedom to work at their convenience, while offering clear and concise design information. It is also well-suited for brand-intensive engagements in which the visual designer needs to exert more control.

Conclusion

The constant demand to produce a quality online experience drives us to create better processes for its development. This article discussed two techniques widely used in creating wireframes for web applications. While each has its own merits and drawbacks, it is the IA’s specific situation that dictates which one to use. As user experience groups grow larger within organizations, they begin to add refinement steps to their processes in an effort to add value to their deliverables. It seems that the bigger the UE group is, the more likely it is to tout the benefits of finely detailed, meticulous design. For this type of design, Visio seems to fit the bill more appropriately with its capabilities of detailed notation, clean translation to paper, and ability to create “layers.” In a smaller or more rapid-paced situation, the multi-faceted IA can make great strides by creating high-fidelity prototypes in HTML. Which technique is best for your current needs? The answer is, as always, it depends.

Jeff Gothelf is a Senior Information Architect at Braun Consulting’s Boston office. He has been practicing web design and information architecture since the mid-90s in the Mid-Atlantic and New England regions. His career has spanned a multitude of industries including retail, financial services, and pharmaceutical. While the majority of his work has focused on the web and its many applications, his ultimate goal in life is to create the world’s most beautiful and usable toaster (one that would make Don Norman proud). When he’s not playing music he keeps tabs of his thoughts at Scattered, Smothered and Covered.

HTML Wireframes and Prototypes: All Gain and No Pain

by:   |  Posted on
“Using HTML as the basis for your wireframing and prototyping can be a quick and rewarding experience with fabulous benefits, including easier user testing, improved client communication, and faster, more effective use of design time.”

Mention the use of HTML for wireframing or prototyping, and some information architects and interaction designers frantically look for the nearest exit. In some circles, HTML has acquired the reputation of being a time-consuming, difficult undertaking best left to developers. I’m here to convince you that this is very far from the truth. In fact, using HTML as the basis for your wireframing and prototyping can be a quick and rewarding experience with fabulous benefits, including easier user testing, improved client communication, and faster, more effective use of design time. As a matter of fact, at Sliced Bread Design, Dreamweaver is the ONLY tool we use for our wireframes, and we love it. For those of you who may stop right now because you don’t know how to do HTML, let’s first discuss why you would want to use it. Then, read the HTML Wireframing Primer to find out how to do it yourself.

What people are using now
Henri Olson of guuui.com recently conducted a survey of 52 people to understand their use of web prototyping tools. He found that only 28.3 percent of interaction designers surveyed use HTML tools such as Dreamweaver or FrontPage for prototyping. The rest use visual and diagramming tools such as Visio, Illustrator, PowerPoint, or paper. While I am happily surprised by the quarter of designers using HTML tools, I am still left wondering why more people don’t take advantage of the benefits of HTML. In fact, the survey found that over 67 percent of HTML prototypers agree with the sentence: “I’m perfectly happy with the prototyping tool I’m using.” And, in a question that measures how well their current prototyping tool lives up to their functionality requirements, prototypers agreed that HTML tools came out with the highest overall score. This compares to only 8 percent of diagramming tool (i.e. Visio) users and 50 percent of graphic design tool (i.e. Illustrator, Photoshop) users who are perfectly happy with their tool. So the question is, if HTML is so great for design, why aren’t more people using it?

Definitions
There are many different definitions of wireframes, prototypes, and visual design, so let’s start by defining how these terms will be used in this article. A wireframe is a grayscale block diagram that illustrates the overall navigation and the blocks of elements such as content, functionality, etc. that will go on the screen. It does not contain pictures and doesn’t necessarily need to link to anything. It just demonstrates what elements a web page or application screen will contain and roughly where they might go—although the location can change. It does not include visual design. An HTML wireframe is created in HTML using a program such as Dreamweaver. A flat wireframe is created using a program such as Visio, Illustrator, or Photoshop and does not have interactive components, but is a flat image of the elements on the screen.

What I call an interactive HTML prototype goes a step further by linking navigation on an HTML wireframe to other wireframes representing subsequent screens, filling in content as needed, and adding mock functionality such as drop-down menus and fields that don’t tie into any backend. Note that this sort of prototype is somewhere between high- and low-fidelity as defined by Chris Farnum in his recent Boxes and Arrows article. This prototype does not represent any visual design other than simple layout. It does not require enlisting the help of a developer because the interaction designer does all of the work in a program such as Dreamweaver.

The screen shot below shows one page of this sort of prototype. Notice that it shows that the design will have primary navigation with four categories (Dashboard, Database Setup, etc…), secondary navigation that integrates the steps of a wizard with navigation (an idea we were testing), a form to fill out in the middle that a user can try out, and navigation at the bottom that might be buttons or links when the design is complete.

By linking together multiple pages of HTML wireframes for a site or an application, you can quickly end up with a prototype to user test or show the client. For the purposes of this article, when I use the term “wireframe,” I am referring to an HTML wireframe and will use the term “flat wireframe” to refer specifically to wireframes not in HTML.

Why avoid HTML?
I’ve heard many reasons why designers don’t want to use HTML for wireframing and prototyping. The most common reason they are reluctant to use HTML is because they are already comfortable with tools such as Illustrator and Visio. I’ve heard people say, “Making HTML really work is difficult” or “I don’t know JavaScript.” To combat these concerns about ease of use, the accompanying HTML Prototyping Primer article teaches you how to create quick, functional, flexible wireframes without any real programming by using Dreamweaver. But the flexibility and functionality of Dreamweaver is not the main reason to switch to HTML. Let’s go on a short tour of the benefits of HTML wireframing and prototyping that will convince you to make the switch.

Increased user testing
The most important interaction design benefit of HTML is the way it lends itself to ongoing user testing. Because of their interactivity, HTML wireframes are regularly used to user test design ideas on the fly with people in the office, friends, or anyone who happens to stop by. When there is no one around to show, we post designs to the web and instant message a friend to try them out – we always get some quick, useful feedback. For example, Sliced Bread Design recently worked with a company called Elevon on a new version of their enterprise budgeting software. From the beginning, the client had many different ideas for the flow of the set-up wizard. Some parts of the set up had to be done in a specific order, while other tasks could be done at the user’s convenience. We approached these different aspects of the functionality by creating a list of tasks involved in the set up, and disabling the tasks that could not yet be started (see Figure 2 below). Then, we quickly user tested the wireframe with people in the office to see if they understood the interaction idea. After validating the base design, it was ready to show to the client.

When everyone is satisfied with a wireframe, like the one above, we can then link all the screens together into a wireframe prototype and conduct more formal usability testing without having to do additional set up work. Of course, for formal usability testing we still have to create a script for the tasks that we need to test. Your prototype might need more or less modification to fully cover those areas you need to test. However, we’ve found that our wireframe prototypes convert to user test material with minimal effort because the framework for every page is already in place and is very flexible. Above all, our reliance on HTML wireframing lets us promise all of our clients that the final design will ALWAYS be user tested, even if only via guerrilla user testing – especially important if the budget is tight.

Creating visible client value from the start
Another big benefit of HTML is visible value for the client at the beginning of the project. Some of our clients are confused about the difference between interaction and visual design. By focusing on creating something interactive at the beginning of the project in the form of an HTML wireframe, we can demonstrate that the focus of our work will be on how people use the product as opposed to how it looks. And, as we are busy showing off our knowledge of interactivity, we are also demonstrating our awareness of technical constraints. Even if your wireframe is based on the simplest HTML out there (ours always are) and only takes 10 minutes to create, the fact that you have ventured out of the realm of graphics software demonstrates your concern with creating something that is implementable, not just a blue-sky concept.

Improved client communication
When it’s time to show the work to the client and demonstrate its value, the next benefit of HTML becomes improved client communication. Sometimes it may be difficult for a client to understand the brilliance of the user experience that is being proposed because they cannot experience it for themselves. Miscommunication can result from misunderstood verbal descriptions of how users will interact with a flat prototype. We experienced this on a project where client team members were located on multiple continents and had varying English skills. By demonstrating the functionality instead of describing it, we were able to greatly reduce miscommunication that initially resulted from teleconferences and documents in rough English. Furthermore, team members in different time zones could review designs that we posted on their own time without additional explanation. By allowing our client to experience the interaction, we knew that they understood exactly what we were talking about and had agreed with the direction we were heading early on in the process.

Communication through demonstration is especially important when the project does not have a pre-defined functional specification, i.e., a definitive list of the functionality and/or content areas that the product must have. For example, on the Elevon project, we were hired at the beginning of the project to help replace old desktop client server software with a shiny new web application. At this stage, there was no specification, so our work played an integral part in helping define the product’s functionality. By creating interactive wireframes that represented the functionality under discussion, we were able to quickly reach agreement on what worked best for the end users. Furthermore, everyone could click through the wireframe prototype to make sure that all the pieces were in there, and any functionality that had been casually discussed wasn’t getting lost. The Elevon team also used the prototype to reach internal consensus and demonstrate the project’s progress to management.

Disqualifying poor ideas
Another client communication benefit becomes apparent when your client suggests some interaction scheme that they are sure will work, and you are sure won’t. If a gentle suggestion to steer the client in the other direction doesn’t work, we’ve found that creating an HTML wireframe to demonstrate the problems of the proposed interaction is much more convincing than further discussion. Often experiencing an idea is very different from describing it. And, since the idea is now prototyped, it can easily be user tested if you need more ammunition to disqualify it.

Simplified implementation
If I haven’t yet convinced you of the benefits of HTML prototyping, perhaps this point will: return on investment (ROI). These days, everyone is chatting about the hot topic of ROI. By emphasizing your use of HTML to the client, you can also make legitimate claims about decreased development costs through more consistent implementation and quicker specification. We use our HTML prototypes directly in our specification to communicate to developers exactly how the final product needs to work. More complex functionality, not in the prototype, is explained via bullet points under the screen itself. Although the prototype lacks the final graphic design, it demonstrates the functionality and the flow, leaving little room for developer confusion, which in turn saves time during the development cycle. Furthermore, your client saves money because your time isn’t spent explaining every detail in a text heavy specification.

Upsell to marketing
And finally, the last client benefit is actually a potential follow-up project for you. Since you saved the client money in specification, you can now spend it by selling them a robust version of the prototype. Well-crafted HTML prototypes can easily be turned into marketing prototypes once the visual design is complete. Many projects that we’ve worked on take a long time to implement, but inevitably the marketing team always needs something to show next month at the big conference. Voila! With an existing prototype, it is easy to apply the final visuals for your client to show their customers before the final project is complete. Everybody wins.

HTML is for more than just the Web
Hopefully, now that I’ve sold you on HTML prototyping, the important thing to note is that HTML wireframing and prototyping is for more than just web projects. In the past, we have used HTML prototyping for both desktop and cell phone applications. For example, through the use of screen shots and some carefully placed web layers, we were able to create an interactive prototype of a Windows file management system. On another project, we prototyped in WAP (roughly HTML for cell phones) using a Dreamweaver plug-in. By creating a mobile phone interface to user test, we were able to capture interaction problems before we presented the ideas to the client. Once you get hooked on HTML wireframing and prototyping, you really can’t go back.

OK, I’m ready. What do I do next?
Read the HTML Prototyping Primer for concrete instructions that will make you more comfortable with Dreamweaver. Although it might be hard to abandon what you are used to and get turned on to HTML, hopefully, I have emphasized that in today’s tight economy, the benefits are well worth it.

  • Results from a survey of web prototyping tools usage
  • What an IA Should Know About Prototypes for User Testing by Chris Farnum
  • Definitions used in this article:
    Wireframe: a grayscale block diagram that illustrates the overall navigation and blocks of elements
    HTML wireframe: wireframe created in HTML using a program such as Dreamweaver
    Flat wireframe: wireframe created in graphics program such as Illustrator, diagramming programs such as Visio, or on paper
    HTML prototype: HTML wireframes with actual content and interaction components filled in that are linked together to form a rough interaction

Julie Stanford has been a practicing experience designer since 1996 and is a partner at Sliced Bread Design, an interaction design and usability agency. Through her work at Sliced Bread, Julie has specialized in designing complex online, wireless, and voice applications for clients such as Elevon, Tellme, Agilent, and Casio.

Dreamweaver Primer

by:   |  Posted on
“I recommend Dreamweaver for wireframing and prototyping because it is easy to learn, offers palettes with all the necessary interface widgets, and has built-in project management tools like source control, which is useful if you are working with a team.”So, you’ve read the article, “HTML Wireframes and Prototypes: All Gain and No Pain” and now want you want to make an HTML wireframe. I’m here to help make this an easy and pain-free process, using Macromedia Dreamweaver 4.0.

By the end of this primer you will have:

  • Become familiar with the basic functionality of Dreamweaver
  • Made a sample HTML wireframe that you can use as a template for future wireframes

How to use this primer
This primer assumes that you have never used Dreamweaver before. Although there are many HTML editing applications out there, I recommend Dreamweaver for wireframing and prototyping because it is easy to learn, offers palettes with all the necessary interface widgets, and has built-in project management tools like source control, which is useful if you are working with a team. If you are already familiar with Dreamweaver, you can skip the Dreamweaver Basics section and go right to the “Let’s start wireframing” section.

Also, this primer is designed to be used while you are running Dreamweaver. The instructions are accompanied by illustrations and examples so you can try the techniques in Dreamweaver as you read along.

Finally, the techniques suggested in this primer are specifically for creating wireframe prototypes, not for creating launchable sites with working backends. As a matter of fact, many of the techniques here would probably make a web developer’s hair stand on end—they do not produce implementable code. However, since the goal is to communicate design concepts, not to implement a site, it is okay to take shortcuts where possible. Working faster facilitates easy iteration and the creation of many different design ideas.

Dreamweaver basics
When you launch Dreamweaver, it will open a blank web page called “Untitled Document.” This default Dreamweaver document window is divided into 5 horizontal sections. These sections, and the most useful buttons in the window, are labeled in Figure 1. Since we will be doing all of our work in the design view area of the window, you can close the code view area by clicking the design view button in the toolbar.

stanford_img3.gif
Figure 1: The default Dreamweaver document window and its key functionality.
Click the design view button to hide the code view area.

Now for a tour of the tools that are available for your wireframing work. Dreamweaver provides access to tools via floating palettes, which you can display by choosing them from the Window menu. The palettes that are the most useful for wireframing are Objects, Properties, and Styles.

Objects palette
The Objects palette offers most of the visual elements that we will add to the wireframe. When you click an item in the Objects palette, Dreamweaver places that object where you last clicked in the document.

stanford_img4.gif
Figure 2: The Objects palette showing Common objects, Character objects, and Forms objects.

At the top of the Objects palette is the Category drop-down menu, which lets you control which object types appear in the palette. For wireframing, we will primarily use the Common, Character, and Forms object categories. Figure 2 shows how the Objects palette looks with each of these three categories selected and labels the most useful items in each set.

Expanding the Properties palette
Often, the bottom portion of the Properties palette is not displayed when you open it. This portion contains useful properties that you don’t want to miss! To expand the palette, click the small white arrow in the bottom right corner of the Properties palette. If the arrow is pointing up, you know that the palette is expanded and you are seeing all of the properties.

Properties palette
Each object that you insert into your document has a set of properties associated with it, which you can view and modify in the Properties palette. When you select an object, its properties appear in this palette. For example, Figure 3 shows the properties for some text in a table cell. The top portion of the palette governs the properties of the text, while the bottom portion controls the properties of the table cell.

You can use the Properties palette to format text, add links, specify background colors, indentation, and alignment, create lists, and so on. For example, you can create a link by selecting a block of text and entering the URL in the Link field. When a table is selected, the Properties palette is useful for specifying the size of the table or the number of rows and columns in it.
stanford_img5.gif
Figure 3: The Properties palette when text in a table cell is selected in the document window.

Table cell property definitions
Cell spacing: This is the number of pixels that Dreamweaver puts outside each table cell and around the table as a whole. For example, specifying a cell spacing value of 2 pixels puts 2 pixels between each cell and a 2-pixel invisible border around the entire table.

Cell padding: This is the number of pixels that Dreamweaver uses to pad the inside of a table cell. To remember the difference between padding and spacing, I think of the padding on the walls inside a cell at an asylum.

CSS Styles palette
The CSS Styles palette is used for setting up the CSS (Cascading Style Sheet) styles that will govern your wireframe. A style is a description of the formatting properties that you apply to text or a table cell, including things like font color and size, background color, etc. Styles are useful for ensuring that all of the wireframes you create look consistent. If you have ever used styles in Microsoft Word, CSS styles work in much the same way.

Figure 4 shows a CSS Styles palette with the various styles I used for the example wireframe in this primer. The most important command to remember when using the CSS Styles palette is New Style, the button for which is available at the bottom right of the palette.

stanford_img6.gif
Figure 4: The CSS styles palette.

Other palettes
Other useful (but slightly more advanced) palettes for wireframing are the Behaviors and Layers palettes. While we will not explore their functionality in this article, I encourage you to try these palettes once you are comfortable with Dreamweaver. They offer tools to help you do things like produce pop-up windows and have page elements dynamically appear or disappear.

Let’s start wireframing
Now that you know the basics of what is available to you in Dreamweaver, let’s put together a wireframe. For this example, I will walk you through the steps to create a wireframe for an inside page of a website about dogs. When we are done, the Dreamweaver document for the wireframe that you have created will look like this:


Figure 5: The finished wireframe for a dog website as it will look in Dreamweaver. Click to enlarge.

In a browser window, the finished wireframe will look like this:


Figure 6: The finished wireframe as it will look in a web browser. Click to enlarge.

You can download this finished wireframe as a basis for your own work here.

Now, let’s get started.

Step 1: Define a site

NOTE: If you are going to put all of the files or documents related to a project in subfolders that are contained within a main folder, you should select that main folder here, not just the wireframe folder. That way, if you put the HTML files in one folder and the images in another and the site maps in a third, then Dreamweaver site management can help you manage them all.

The first thing you should do when beginning a new wireframing project in Dreamweaver is “define a site.” When you define a site, Dreamweaver groups all of the wireframes for the site together into a single project, which allows for easy updating of links when you move pages around, and, if you are working with a team, source control.

To define a site:

  1. Select “New site” in the Site menu, which will open a dialog box.
  2. Enter the name of the site and select the root folder where you will save the wireframes for the project. If you will be sharing these documents on a server, select the “Remote info” category on the left side of the dialog box and choose how you will access these files in the Access drop-down menu.
  3. If necessary, enable source control after you select an access type. Source control facilitates file sharing by checking files in and out.
  4. You can ignore the other options in the dialog. Click OK to close it.

After you close the dialog, you will see the Dreamweaver site window, which works similar to Windows Explorer or the Mac OS Finder for accessing your site files. For now, we’ll ignore this window and move on to Step 2.

Step 2: Set up your document work space

  1. Go to the Untitled Document that Dreamweaver launched on start-up and save it with an appropriate name.
  2. If they are not already open, open the Objects, Properties, and CSS Styles palettes by selecting them from the Window menu.

Step 3: Set up your basic wireframe layout
Every HTML wireframe consists of tables that make up the basic layout of the page. Usually, I create separate tables for the top global area (including the logo), primary navigation, secondary navigation (if it is horizontal), and the content area. Also, I always make the tables 760 pixels wide, assuming a minimum 800 x 600 screen resolution. To set up tables in general:

  1. In the Objects palette (Common category), click the Table button to insert a table. This will open a table dialog box.
  2. Enter the necessary properties for the table and click OK.
  3. Click to the right of the new table to deselect it, then press Enter to position your cursor for insertion of the next table.
  4. Follow steps 1-3 to insert the rest of the tables.

Now, let’s work from the top down to set up these four basic tables. Select a table and, in the Properties palette, enter the following table properties:

  • Global area table (for the logo and search and help links): 1 row, 2 columns, width = 760 pixels, border = 0, cell padding = 0, cell spacing = 0
  • Primary navigation table: 1 row, 5 columns (for the five primary navigation categories), width = 760 pixels, border = 0, cell padding = 0, cell spacing = 3
  • Secondary navigation table: 1 row, 8 columns (for the eight secondary navigation categories), width = 760 pixels, border = 0, cell padding = 0, cell spacing = 0
  • Content area table: 2 rows, 1 column, width = 760 pixels, border = 0, cell padding = 4, cell spacing = 3

When you are done, your Dreamweaver document should look like this (without the table names marked in blue):

Figure 7: Dreamweaver window with the four basic layout tables. Click to enlarge.

Step 4: Set up the primary navigation
Once you have set up your basic table layout, you can fill in the primary navigation elements. To format the navigation area, let’s create our first style in the CSS Styles palette:

  1. Click the “New style” button at the bottom of the palette. This will open a dialog box.
  2. Enter the style name .primaryNav_unselected. Click OK.
  3. Since this is your first style, Dreamweaver will open another dialog box asking you to name your new style sheet. All of the styles that you create will be associated with this style sheet. Name your style sheet and press Enter.
  4. This will open the edit style dialog box in which you can specify the format of your new .primaryNav_unselected style.
  5. Select Verdana font, size 12.
  6. Click the Background category (on the left side of the dialog), then select light gray (#CCCCCC) as the background color.
  7. Click OK.

Congratulations! You have created your first style. Creating additional styles should be easy. Now let’s apply this new format to the primary navigation table that you created and fill in the table with the navigation categories:

  1. Select the entire primary navigation table.
  2. Click the .primaryNav_unselected style you just created in the CSS Styles palette. This should make the entire table gray.
  3. With the primary navigation cells selected, apply the rest of the formatting by entering the following options in the Properties palette: text justification = center, horizontal alignment = center, vertical alignment = middle, height = 25 width = 152.
  4. In each cell of the primary navigation table, type in one of the primary navigation categories: Home, Breeds, Buying a dog, Training, and Health.
  5. Create fake hyperlinks for each of the primary navigation items by selecting the category name and entering “#” in the Link field of the Properties palette.
  6. Create the selected state for the primary navigation by making a .primaryNav_selected style in the styles palette with these properties: Verdana size 12, type color = burgundy (#663300), background color = medium gray (#999999).
  7. Select the cell that contains “Breeds” and apply the primaryNav_selected style to that cell.
  8. Select the “Breeds” text and apply the primaryNav_selected style to the text.

At this point, your document window should look like this:

Figure 8: The Dreamweaver document showing the complete primary navigation table. Click to enlarge.

Step 6: Format the rest of your navigation elements

Special Tip: Tag Selector
At the bottom of the document is an area called the Tag Selector (marked in blue in Figure 8). This area shows what HTML tags are applied to the currently selected element of the page. For example, in Figure 8, the selected text is located within a <div> tag, which is within a table cell (<td>), which is within a table row (<tr>), which is within a table (<table>), which is within the body of the document. Click a tag to select it and all of its content and then apply a style to your selection. The Tag Selector also shows what style is currently applied to an item. For example, the <td> cell in Figure 8 is displayed as <td.primaryNav_selected> to indicate that the .primaryNav_selected style has been applied to that cell.

Format the remainder of the tables, including the secondary navigation table and the background color of the content area table, by repeating the basic process described above. To facilitate the formatting of your wireframe, I have created a style sheet with all the styles you’ll need; you can download it here. To attach this style sheet to your document, save it in the same folder as your wireframes, then from the Text menu in Dreamweaver, select CSS styles >Attach Style Sheet. This will display a dialog box that asks you to select the style sheet to attach. Choose the one in your project folder and you are in business.

Note: The rest of this primer assumes that you have downloaded and attached this style sheet.

Step 7: Add the search tools
For this example, we are creating a wireframe for the inside page of a dog site. Specifically, this wireframe lists all of the breeds of herding dogs and lets you search through them. To add the search tool to the page:

  1. In the first row of the content area table, type in the page title “Herding dog breeds” and apply the page_title style to it.
  2. In the second row of the content area table, type in the instructions for the search (“Search for dogs with desired characteristics:”) and apply the body_text style to it.
  3. Below the instructional text, insert a new table to house the search fields: 1 row, 7 columns, width = 100%, border=0, cell padding=3, cell spacing=0. Each search field and label will go in a separate cell of the table.
  4. Enter the name of the first label for the search (“Size”) and apply the field_label style to it.

Now, let’s add a multiple-select box for the Size options in the second column of the search tool table. Since Dreamweaver does not automatically create multiple-select boxes, we’ll need to make one from scratch:

  1. Create a small table: width=100 pixels, 1 row, 2 columns, border=1, cell padding=0, cell spacing=0.
  2. Use the Properties palette to set the border color of the table to gray.
  3. In the left cell of the table, insert checkboxes from the Objects palette and add a label for each checkbox.
  4. For the right side of the multiple-select box, take a screen shot of a scroll bar and edit it to the proper size in Dreamweaver (in this case, 60 pixels tall), or download one here. Place the scroll bar in your table by clicking the Insert Image button in the Properties palette.

Next, add the Exercise drop-down menu:

  1. In the next column of the search tool table, type “Exercise” and apply the field_label style to it.
  2. In the Objects palette, select the Forms category and click the Insert List/Menu button.
  3. With your new drop-down menu selected, click the List value button in the Properties palette. This will open a dialog box.
  4. Enter a label for each item in the drop-down menu (i.e., ”don’t care,” ”low,” “medium,” “high,” “very high”). You can ignore the Value field.

Add the Shedding radio buttons and the Search button:

  1. In the next column, type “Shedding” and apply the field_label style to it.
  2. In the Objects palette, with the Forms category selected, click Insert Radio Button twice to insert two radio buttons.
  3. Add labels to the radio buttons and apply the body_text style to them.
  4. Click Insert Button again to place the Search button on your page.

Step 8: Add the table of breed details
Now, let’s create the table of dog information.

  1. Type in the label for the table: “Displaying: 1-10 of 150 dogs.” Apply the table_label style to it.
  2. Directly under the label, insert a new table: 11 rows, 6 columns, width = 100 %, border = 1, cell padding = 3, cell spacing = 0
  3. With the new table selected, choose a light gray border color for the table in the Properties Palette.
  4. Fill in the contents of the table, using the table_header style for the column headers and the table_content style for the cell content.

Step 9: Apply the finishing touches

  1. Add the page counter (“Page 1 of 15”) and the “Next >” link for accessing subsequent pages of the site (use “#” for the link again).
  2. In the global area table, put a logo placeholder in the left column and links to search and help in the right column.

Voila! You are done!
Creating this wireframe should have taken you between 30-60 minutes. In the future this should go even quicker because you can reuse the basic elements you’ve already set up.

Finally, the following is a list of tips and reminders to help you tackle more wireframing situations with ease:

  • Reuse and recycle! Once you have made one wireframe, there is no reason to ever start from scratch. You can download the wireframe created in this primer here and use it, or create your own.
  • Use “#” for URLs to create placeholder links that won’t cause “file not found” errors when you click them. Once you have created wireframes for other pages on your site, you can replace the #s with links to those pages to make an interactive prototype.
  • Use cell padding and spacing to create margins between table columns and cells.
  • In general, specify the size of main tables in pixels; specify the size of tables within other tables in percent.
  • Dreamweaver does not make it easy to make multiple-select boxes, so I walked you through making one above. It is easy to fake other functionality not provided by Dreamweaver through clever use of screen shots.
  • Much of the functionality described above is also accessible by right-clicking (option-clicking on a Mac) on an element to bring up its contextual menu. For example, right-clicking inside a table will display a table edit menu for adding and deleting columns and formatting text.

Julie Stanford has been a practicing experience designer since 1996 and is a partner at Sliced Bread Design, an interaction design and usability agency. Through her work at Sliced Bread, Julie has specialized in designing complex online, wireless, and voice applications for clients such as Elevon, Tellme, Agilent, and Casio.

Defining Feature Sets Through Prototyping

by:   |  Posted on
The Vision Prototype allows the user-centered vision to be seen—and discussed—by all team members.Over the last couple of years, a standard method for user-centered interaction design has begun to emerge. First, you gather background from the clients and stakeholders, conduct user research, and look at competitive sites. Then you build personas and scenarios, do workshops, and conduct brainstorming sessions. All of that is analyzed down into a grand vision of what should be built.

But what happens after that? Most of the literature in this area assumes that once the designer has a vision in mind, it’s time to move straight into sitemaps and wireframes and the rest of the business of functional design. But I’ve never seen it actually work that way. In my experience, there are always clients who need to approve the vision, scope that needs to be defined, and project managers who want detailed and concrete functional requirements from which to manage. If I’m not involved, they’ll do it without me, often leaving me with a scope and a set of requirements that doesn’t have much to do with the vision with which I started.

To address this issue, over the years I’ve put together a method to translate a conceptual vision into a set of concrete functional requirements, by way of what I call a Vision Prototype. The Vision Prototype allows the user-centered vision to be seen—and discussed—by all team members. Because the prototype serves as an explicit visual representation of the project’s needs, it can be easily translated into a set of functional requirements.

What is a vision?
This method assumes that a vision has already been defined in someone’s mind, using one of several user-centered interaction design techniques (see “For More Information” below). The vision doesn’t need to be extremely detailed, but it should answer these basic questions:

  • What’s the purpose of the site?
  • What are the main things the users will do with the site?
  • What’s the general conceptual structure?

Let’s look at an example of a high-level vision. Let’s say I’m building a website that allows Quinn Exhibition, an imaginary trade show company, to sell booth space online. In my—fictitious—user research, I observed that the floor plan for the exhibition was critical in everyone’s thought process in determining everything from number of booths to the position of a competitor’s booth. Typically, sales reps fax annotated floor plans to potential purchasers and buyers show them to their bosses.

Based on this data (and backed up by my fictitious competitor research, personas, scenarios, and workshops), my vision for the website is to use a visual floor plan as a key interface metaphor. Potential clients can see what booths are available and where booths are located by perusing a familiar floor plan format. They should be able to buy straight from the floor plan.

Documenting the vision
It’s not easy to jump from a vision in your head to a list of concrete functional requirements, and it’s not desirable, for a number of reasons. At the most basic level, creating formal documentation of a vision ensures that a vision does in fact exist. While this sounds obvious, it’s a problem that I’ve seen frequently, especially in more traditional software development processes. It’s easy to build a requirements document by piecing together what everyone says they want without any overarching idea of where the system as a whole is going. Needless to say, this often results in sites that are less than cohesive.

A visual representation also makes the vision tangible and understandable to clients, users, and the rest of the project team. This makes it possible to get feedback in this early phase and serves as a touch-point for the rest of the project. When scope creep begins, it’s possible to say “Is that feature really important to what we’ve defined?”—with some assurance that others on the team will share your view of what was decided.

This is where the prototype comes in. I’ve had great success in documenting an ideal vision with a conceptual prototype which, in anywhere from four to ten linked pages, shows the high-level functionality and conceptual structure of the site. I’ve found that this type of Vision Prototype is both easy to create and easy to understand.

The prototype is built not to show the interface, the page flow, or the fields, but to represent an ideal feature set that makes the vision happen. For instance, I’ll often represent site functionality with a number of significantly labeled buttons (i.e., “Add New Location” or “Advanced Search”). These buttons serve as functionality shorthand—there’s no need to show an Advanced Search page in the prototype if the team will understand what a button labeled “Advanced Search” implies.

Because the prototype is primarily documenting an intended (or ideal) feature set, I carefully determine the right level of detail and functional feasibility. I try to represent the site functionality to just the necessary level of detail to allow an engineer to estimate the approximate time and money needed to create each feature. This means representing some specifics (especially for a more unusual feature), but certainly not every field on every page. I also go to some effort to ensure that the prototype feature set is ”blue sky” enough to be inspiring without being completely infeasible for the time and money. I generally think of the prototype as representing the feature set of the site two or three phases down the road.

The illustration shows two pages—a Floor Plan and a Booth Detail page—out of a Vision Prototype for the example website. The pages use both an interface-like structure and suggestive buttons (“Search All Available Booths,” “Split this Booth into Two”) to show the feature set. The prototype would include a few pages in addition to this: an overview or homepage, a static content template (to show that the content links are just pages of text), and perhaps the Buy Booth page itself.

When scope creep begins, it’s possible to say “Is that feature really important to what we’ve defined?”—with some assurance that others on the team will share your view of what was decided.A prototype this early? Are you nuts?
It’s worth pausing here to acknowledge that the idea of building a prototype before even defining scope alarms many reasonable and experienced interaction designers. I’ve heard two different but related arguments as to why it’s a bad idea:

  • Argument 1: Functional requirements by definition should talk about needs and specifically avoid any consideration of design like conceptual structure or specific features. Something as tangible as a prototype should come after the definition of requirements, to ensure that all the issues and parameters are considered before jumping to a design solution.
  • Argument 2: Clients aren’t able to separate a conceptual prototype from an interface design or a live website. They’ll focus on the wrong details (like the page flow or graphic design), fixate on a particular detail that will turn out to be infeasible, or just generally misunderstand the intent of the prototype.

Both of these arguments are rooted in the same premise that it’s preferable to first work at a fairly abstract level to define the scope and needs of the project before looking at a visual representation that might start to limit the field of design possibilities or encourage people to determine how things should be implemented as opposed to solely what the system should do.

While this premise makes sense in an ideal world, I believe that it simply doesn’t work in the vast majority of project situations. Information architects are comfortable working in the realm of abstract functionality (that’s one reason why we’re hired), but clients generally are not. In the same way that we wouldn’t show a user a text list of features and expect to get good data about the usefulness of the system, we can’t expect a client to be able to adequately give feedback on a high-level description of functionality.

By creating a visual representation of the project vision early, we give up a little to get a lot. We give up tight control of precisely what the client will be thinking about at each phase of the project. This can sometimes result in early discussions about things, such as page flow or graphic design, that are unrelated to the decisions at hand (by the way, I’ve seen this type of thing get somewhat irritating on a project, but I’ve never seen it cause any lasting harm). But by giving this up we gain a huge advantage: we gain the active understanding, participation and buy-in of our clients. Ultimately, ensuring our clients can effectively understand, review, and discuss important project concepts will result in better products and fewer problematic misunderstandings down the road.

Does it have to be a prototype?
That being said, a Vision Prototype may not be appropriate for every project. I’ve found that a prototype is particularly good at representing highly complex functional sites. For this type of site, it can represent a lot of complexity in a format that makes it easy to review and understand. In addition, prototypes are familiar to the many companies who already use them as a standard to get buy-in on a project.

For smaller projects, however, I’ve found that it’s difficult to build a conceptual prototype without detailing every field, simply because there’s not that much to say about the site vision. A prototype also may not effectively handle the structural issues of a content intensive site. For this type of site, the prototype can be replaced by anything that’s tangible, non-technical, and fairly comprehensive—perhaps a content map, a comprehensive set of scenarios, or a page flow (when there’s not a lot of complexity in the page flow itself).

Verifying and getting buy-in on the vision
One of the main reasons to create a Vision Prototype is to allow the rest of the project team and the client to understand, review, and provide feedback on the vision. Because the prototype makes the ideas under discussion visible and concrete, it’s common for new needs or concerns to come up at this point—even in areas that might have been completely covered in previous conversations. It’s simply hard for many people to think abstractly about the same things that are made obvious by the prototype.

User focus groups can also be useful at this point. A successful vision will generally get a “Of course, how else would you do it?” response, with some suggestions for minor additional features. Confusion, lots of questions, or lots of suggestions for major new features are all signs that the vision does not correspond with the users’ expectations and model of the system, and needs to be reconsidered.

At this point we resolve any issues, and ensure that the whole team is happy with the prototype before moving forward. In this way, the prototype becomes the documentation of the entire team’s vision.

Creating a functional requirements document
Because the Vision Prototype contains a comprehensive look at ideal functionality, iterated and approved, it is itself a representation of the functional requirements. In order to translate these ideas into a more traditional document, one can simply systematically write down the functionality shown on each page. It’s also important to think through any administrative or tangential features (user administration, for instance).

For instance, looking at the Quinn Exhibition prototype, I can pull the following functional requirements (among others) from the Floor Plan page:

  • The position of each booth is displayed on a visual floor plan.
  • All hall infrastructure is displayed on the floor plan.
  • The status of a booth (occupied or available) is displayed on the floor plan.
  • Booth details, such as the size and the occupant, can be easily seen on or linked to the floor plan.
  • The user can search for a booth based on key booth criteria.
  • An administrator can define the hall infrastructure and initial booth layout for an exhibition.

Note that there’s a great deal of work left to do to completely define the functionality. What criteria can be used to perform a booth search? How does the administrator define the original floor plan? The point of this functional requirements document is not to completely design the site or define all business rules, but to establish the functionality to the point that the site can be estimated.

I put each requirement on a separate line in an Excel spreadsheet, and prioritize each based on my user research findings and client priorities. I generally use Core, High, Medium, and Low. Core requirements are ones that the site wouldn’t make any sense without—in the example site, for instance, “The position of each booth is displayed on a visual floor plan” is a core requirement. The technical team also assigns a complexity (High, Medium, and Low) to each requirement.

The actual writing of requirements takes a little practice to ensure they’re at a useful level of detail and are relatively unambiguous.

Defining scope
The last step in defining a feature set is determining what set of the functional requirements can be implemented in the next phase. I start by working with the development team to determine approximately how much time and money will be left over after achieving just the “Core” priority features. If the time and money can’t accommodate even the “Core” requirements then there’s a problem, and we need to revisit the vision. This is why it’s important not to make the original vision too ”blue sky.”

We then spend several hours as a team going through the rest of the requirements and creating a draft scope. Features are quickly reviewed and separated in to those that should obviously be included (such as High Priority/Low Complexity requirements) and those that obviously shouldn’t (Low Priority/High Complexity). Most of the discussion is around the High Priority/High Complexity and Medium Priority/Medium Complexity features and determining what can be included to create the best mix of basic functionality and strategic features. Determining a scope is more of an art than a science, as the features tend to be dependent on each other in complicated ways. Once there is a draft scope, a more detailed estimate can be made. Often there is too much for our schedule and budget and we have to go back to determine what else can be removed.

Unless the client is very detail-oriented and very close to the team, I’ve found it nearly impossible to involve them directly in the creation of the draft scope. There’s simply too much detail and too many time and money sensitivities. Once we’re internally comfortable with the scope, we can summarize it and present it. While the client almost always has changes, it’s fairly straightforward to iterate the scope because the team internally understands the trade-offs and complexities.

All the previous steps set up a framework in which to consider the issues, generally making the actual definition of scope fairly straightforward. The development and iteration of the Vision Prototype allows the whole team—both the internal team and the client—to solidify a team vision and working relationship. Scope definition, which can often be a painful process of wrangling over favorite features, is made much more straightforward by the imposition of a common vision.

Laura S. Quinn is a technology strategy and information architecture consultant for both corporate and nonprofit clients. Her company, Alder Consulting, specializes in helping nonprofits build powerful internet and database systems with the resources they have (learn more about Alder Consulting at www.alderconsulting.com). In her spare time, Laura prepares for a new career as a homesteader with faithful practice in cooking, gardening, sewing, and weaving.