You are here: Articles --> 2006 --> Creating interactive prototypes
Vous êtes ici : Essais --> 2006 --> Creating interactive prototypes
By Geoff Hart
Previously published as: Hart, G. 2006. Creating interactive prototypes: let's move beyond "paper prototypes". Information Design and Architecture SIG newsletter. July 2006. http://stc-on.org/id/topics/information-design/2006/07/25/creating-interactive-prototypes-lets-move-beyond-paper-prototypes/#more-126
Traditional storyboarding techniques work quite well for primarily linear presentations such as videos. Because these techniques work so well, it’s tempting to extend them to cover user interfaces and multimedia presentations. Unfortunately, the paper-based model for prototyping doesn’t extend well to the nonlinear world of interfaces, hypertext, and multimedia.
There are several reasons:
Despite these problems, people persist in using paper for developing and testing prototypes. Paper fails the “usability” test for these and other reasons. Isn’t it time we came up with a better approach?
To create a prototype that is both an effective proof of concept and something that is easy for the design team to revise and update, you must be able to satisfy certain criteria:
Although most final authoring is now done using application development environments (for software programming) or dedicated multimedia packages such as MacroMedia’s Flash, Director, and Authorware, these production environments have difficult learning curves and are too expensive to be installed on the computers of every team member. Creating a usable design can also take considerable time for designers who have only basic skills in the software. Fortunately, less-expensive and easier solutions are available. These fall into two broad categories:
Both sets of tools meet the four criteria for effective prototyping. There are other options, such as technical illustration software and help-authoring software—with a little creativity, you can even create interactive prototypes in Microsoft Word using the hyperlinking function. However, presentation and Web-authoring software are inherently visual rather than textual, and thus offer more flexible options than Word; on the other hand, they are more widespread than more powerful dedicated authoring software, and easier to use, which makes them easy solutions to adopt for rapid prototyping.
For this reason, we have chosen Microsoft PowerPoint as an example of how you can use presentation software to create prototypes and Dreamweaver as an example of how to accomplish the same effects using Web-authoring software. Other programs in these categories can work every bit as well, with minor differences in the approach, once you learn how they handle each of the four main criteria that are necessary for a useful, usable prototype (that is, consistency, minimal abstraction, interactivity, and distribution).
For the sake of this article, we will be referring to features built into PowerPoint 97 and X (its Mac equivalent). Newer versions have more sophisticated versions of these features that are worth exploring, but the key is that even older software can easily meet the basic needs of prototyping.
PowerPoint provides two main forms of template: a “master slide” for the presentation as a whole, and the ability to override this design for individual slides.
Master slides let you control the overall appearance and location of the presentation by defining the default locations and formats for (1) recurring elements such as text blocks, (2) standard graphics that must appear on every screen (for example, a company logo), (3) special-purpose graphics that appear only on certain screens (for example, photos or illustrations that will appear as part of certain screen), (4) navigation buttons and transitions between slides, and (5) the overall design (for example, typography; background color or pattern).
To change background graphics and colors, you have a few options:
Transitions between screens, such as adding bullets one at a time or determining the time interval before automatically moving to the next slide, are defined by opening the Slide Show menu and selecting Custom Animation. Most commonly, these transitions are defined at the level of the individual slide, but if you define them while viewing the master slide, the entire presentation will use the same transitions. Changing the master slide’s design affects all slides defined using that template, greatly facilitating the process of experimenting with designs until you achieve the desired effect.
Provided that you also update any slide-level changes to account for such overall design changes, all screens in the presentation will remain visually consistent with minimal effort.
To choose the size of the display, open the File menu and select Page Setup. One option is “Custom”, which lets you define a slide size that matches the final size of the product that you’re prototyping. For example, you can simulate the large full-screen display that would be used at an information kiosk or the tiny screen that would be used on a cell phone or PDA. By incorporating the desired graphical elements for each page, as well as any sound or animation, the resulting presentation provides a surprisingly reliable “what you see is what you get” mockup of the final product.
You’ll probably use the following options during prototyping:
Once you’ve built the basic prototype, you can then run the slide show in “slide show” mode to test the overall appearance, and can immediately return to the editing mode to correct any problems that become apparent. Make the change, relaunch the slide show, and you’re working with a revised prototype instantly.
The most familiar form of interaction with a PowerPoint presentation involves moving from slide to slide in a linear sequence. What you might not know is that PowerPoint also provides limited hypertext abilities that let you link to other presentations. To create links to content stored outside the presentation, start by creating the object or text that you want to serve as the link; for example, draw a colored square behind text to create a button or simply convert the text into a hyperlink.
To create a hyperlink, select the text, then open the Insert menu, select Hyperlink, click the “Browse…” button, then navigate to and select the desired file.
Alternatively, open the Slide Show menu and select Action Settings. This dialog box lets you link an object to another PowerPoint file or even to an executable program, and also provides access to PowerPoint’s “mouseover” features, in which moving the mouse over a button or other interface object causes that object to become highlighted or exhibit some behavior (for example, displaying a dropdown menu).
This approach lets reviewers interact with the prototype to follow the branching logic that represents the available paths through the program. Unfortunately, there is no “history” function that automatically lets you retrace a multi-link path to your point of origin after following a link. However, the Action Settings dialog also lets you link to any other slide within a presentation, or to any other presentation, and that gives you several useful options.
Under the heading “Action on click”, select the checkbox for “Hyperlink to”, then:
Once you’ve created a functional mockup, you can distribute the PowerPoint file to anyone who has a compatible version of the software. Doing so lets the recipient edit the presentation (particularly useful when you’re working in a team) and insert comments, which appear in the form of yellow Post-it notes. (To insert comments, open the Insert menu and select Comment.)
For those who don't have PowerPoint, you can create and distribute a self-running version of the presentation. To do so, open the File menu and select Pack and Go. This launches a wizard that will package the presentation for use on someone else’s computer; in the fourth step, you can opt to include a Viewer application that lets you run the presentation on computers that don’t have PowerPoint installed.
PowerPoint also lets you save presentations as HTML so that anyone with a Web browser can view the presentation. However, the HTML support is fairly primitive, and Dreamweaver is a better authoring tool if HTML is your distribution medium. Of course, if you have Adobe Acrobat, you can also create a PDF version of the Powerpoint file that reviewers can annotate using Acrobat’s built in tools.
For the sake of this example, I’ll refer to features that have existed since at least Dreamweaver 3, since many colleagues still use older versions of the software. These features will still exist in subsequent releases, though perhaps in slightly different form. More importantly, they broaden the applicability of this approach to any Web authoring software, since I won’t be focusing on any of the powerful features that may be unique to a given authoring tool. Needless to say, you can create even better prototypes by taking advantage of more sophisticated features such as scripting.
Like Powerpoint, Dreamweaver offers “templates” that contain the standard, recurring elements of a page, along with features such as background colors, and that define which portions of a page are uneditable (that is, that remain consistent for all pages) and editable (that is, content areas that can change from page to page).
Dreamweaver also offers “library items” that let you define a recurring element such as a copyright notice; if you update these elements, they are automatically updated in any page that includes them.
Dreamweaver also provides strong support for CSS (cascading style sheets), the Web standard for controlling the typographic attributes and positioning of text elements in portions of the page.
By changing a template or style sheet, you can automatically update all pages based on that standard, thereby updating the entire prototype in a matter of seconds.
In Dreamweaver’s authoring environment, the “what you see is what you get” display may be encumbered by various clues the software uses to facilitate the layout of the page (for example, grid lines, rulers, table borders). To actually see the results of the design and test its interactivity, you preview the page in the Web browser of your choice—including multiple Web browsers if you want to fix any compatibility problems that arise from a development team using a range of different browsers instead of a single standard choice.
Similarly, you can display any graphics (whether static or animated) as they will actually appear in the browser and present any sound effects (for example, music, voiceovers) the way they will sound. Both may vary slightly from computer to computer based on differences in the quality of (respectively) the monitor and the speakers; they may also vary somewhat between browsers, since despite efforts to standardize HTML and its associated languages, browser developers continue to forge their own paths rather than adhering consistently to standards. In any event, if you restrict yourself to the most common and simple features supported by all browsers, reviewers and users of the resulting Web pages will see the actual design rather than having to imagine it.
Dreamweaver by itself is less powerful at handling transitions between screens than Powerpoint or Flash, so either of those programs may be a better choice for simulating complex transitions such as dissolves or wipes. However, Dreamweaver offers a simpler and more powerful solution than either of these programs when it comes to creating and managing links. Moreover, by displaying content in a browser, the software offers the power of the History feature (a complete record of every screen you have visited) and bookmarking (to easily return to a favorite screen).
Because you can construct a prototype as a series of Web pages, it is possible for reviewers to test any interaction supported by their browser. This includes linking within and between pages, displaying multimedia content, displaying mouseovers, and running external programs such as small programs written in Java or more complex presentations designed in Flash that can be used directly within a browser window. Moreover, more recent versions of Dreamweaver provide tools for database connectivity that let you test dynamically generated screens based on input from a database. Macromedia also offers a “course builder” option for Dreamweaver that lets you build interactive courses and track the results of tests.
Using the table-construction features of any Web authoring software, you can even design and test software interface features such as dialog boxes that formerly required extensive programming knowledge and access to an expensive application development environment. For example, the columns and rows of a table let you precisely position each element of a dialog box, and add borders and colors to cells to simulate features such as buttons and groups of related functions. You can then add hyperlinks to any text or graphical objects that serve as “buttons”, which lets you simulate linking to dialog boxes or tabs within a tabbed dialog box.
Because Dreamweaver creates standard HTML files, prototypes can be easily distributed for review: any current Web browser can display the prototypes. Better still, the prototypes can be published on a Web site for easy review by reviewers at remote locations.
As I've noted in this article, both products have certain strengths and weaknesses. PowerPoint, for example, can produce unwieldy file sizes, and lacks powerful media-management features. Moreover, it lacks a scripting or programming language designed to support multimedia applications. However, it can be found in most modern workplaces (since Microsoft Office is shipped with so many new computers), and is very easy to learn; thus, it offers a simple, readily available authoring tool that can produce surprisingly effective prototypes.
Dreamweaver, on the other hand, is more expensive, must be purchased separately (it does not come with most computers), and is arguably more difficult to learn. Compensating for these minor drawbacks is the tremendous flexibility offered by the software; in trained hands, Dreamweaver can create a prototype that is nearly indistinguishable from the real thing, particularly if you plan to deliver the real product over the Web.
Both tools provide a fast, easy way to create consistent, readily modified prototypes that closely resemble the final application (in appearance and interactivity), and that are easily distributed for review. Once approved, the prototypes can be quickly transformed into a final product using more powerful dedicated software such as Authorware, Director, or Flash. With Dreamweaver, the prototype can actually become the application if the target for the application is a Web site.
The key advantage that both programs (and their many competitors) offer is the following: with very little training and very little investment of time, you can rapidly create prototypes that can be instantly tested and revised until you consider the prototypes suitable for formal usability testing with your actual audience.
Intriguingly, both products offer another possibility that has formerly been unavailable to most usability testers: the ability to instantly modify a prototype and test a hypothesis generated during the course of a usability test. For example, if midway through a usability test you discover a problem with the prototype and think you might know how to solve the problem, you have the option of completing the test and then modifying the prototype, so you can determine whether the modification actually solves the problem for that user.
To do this, you would have to modify your approach to conducting the usability test so that the test design permits the possibility of such iteration within the constraints of the test. I’m not sufficiently familiar with the research literature to know whether this is being routinely done, but the potential to iteratively explore your insights into user behavior and interface problems seems worthy of further investigation.
Even in the absence of iterative testing, the power of this updated approach to storyboarding greatly outweighs the drawbacks—enough so that it makes little sense to continue creating paper prototypes for anything other than paper-based products. If you’re considering the move into interface or multimedia design, or are currently working in this field or the closely related field of usability testing, experiment with your own presentation and Web-authoring software to determine how this approach can save you time and offer both more design flexibility and more powerful usability tests.
Connelly, J.O. From print to pictures. (This column on developing scripts for visual presentations ran from 1993 through 1995 in Technical Communication.)
Kavanagh, R.; Soety, J. 2000. Prototyping using Visio. Usability Interface 7(1):1, 10–12.
Kim, L. 2005. Tracing visual narratives: user-testing methodology for developing a multimedia museum show. Technical Communication 52(2):121–137.
Shelton, S.M. 1993. Script design for information film and video. Technical Communication 40(4):655–663.
©2004–2017 Geoffrey Hart. All rights reserved