Interfacial Relations: Part 8

The User Interface Prototype

By Joost Romeu, San Francisco, California

Interface design controls the way a program appears and the way it interacts with the user.

Simply put, everything that’s obvious to the user is part of the interface design process; everything that’s beneath the surface is a program design issue.

Successful interface design is a delicate balancing act. The interface designer has to:

• Subscribe to platform specific interface standards;

• Design an interface unique enough to respect the capabilities of the software;

• Satisfy the user’s workflow requirements; and,

• Impart a look and feel that recognizably and patently communicates your product line.

The most effective and accurate way to communicate user interface designs and submit those designs to user testing is through prototypes. The prototype is the primary user interface design vehicle.

The Prototype

A prototype is a model. It simulates what the user will encounter when using the program.

In a classic software development situation, user interface (UI) design is just part of a functional spec. Interface is prescribed (rather than demonstrated) using natural language descriptions.

As interfaces become more complicated, it’s debatable whether natural language isn’t in fact inadequate to the task of accurately describing UI responses and sequences. Prototypes allow the UI designer to convey UI specific information in ways impossible through a natural language description.1

A prototype should not be a program substitute or competitor. It should not attempt to upstage your programming effort in complexity of scope. Instead, it should be concise and specific. Once its point has been made, it should be applicable to many areas of the program. If, for example, you’re investigating a new menuing system, it might not be necessary to prototype every menu in order to make a point that will be applied to all menus. Prototypes that are too all encompassing may dilute the issues so much they fail to make any point at all.

Consider your audience. If, in portraying an object/verb paradigm prototype, you need to show a dropdown menu with items selectively filtered. You probably don’t need to fully prototype the action of the menu dropping down. Most observers understand how a dropdown menu operates.2

Prototypes and Context

Over and above all specific enhancements, UI developers are responsible for assuring the program complies to the users’ needs in a manner that is contextually responsive. It is this concern with the greater gestalt that distinguishes the UI designer from the rest of the development team.

This gestalt can be categorized as the synthesis of visual, logical, and procedural contextual factors.

• Visual context: What’s visually happening on the screen must be designed with an eye to what’s already happened as well as what’s about to happen.

• Logical context: What’s logically happening must be designed with an eye to what’s already happened as well as what’s about to happen.

• Procedural context: What’s happening has to relate to the program at hand as well as the workflow that the program is being applied to.

Contextual issues are never clear cut. User interface standards provide guidelines but they can’t be applied uncritically or unambiguously. Even design standards you might think incontestable (such as a “consistency issue”) need to be considered on a case-by-case basis when they are applied to a particular product. Failing to critically consider an implementation that has been designed with consistency in mind, may result in a function whose very rationality interferes with the user’s job requirements or insults the user’s common sense.

Prototypes as Iterative Events

User interface design problems tend to surface and resurface. This is natural because software developers go through the following stages:

• They Plan: think about goals, consider scenarios

• Implement: prototypes, write specs, build product

• Measure: informal feedback, usability testing

• Learn: identify problems, isolate causes, update requirements

• and then rePlan reImplement reMeasure reLearn

Any prototype will probably go through a few generations. It’s important to make sure you’ve placed your prototypes in an environment that allows you to describe, discuss, and develop future prototypes and recall previous prototypes in as painless a manner as possible.

Prototyping Objectives

Prototyping has not been completely accepted by the industry. To successfully promote your prototyping efforts, you should attempt to:

• Develop prototypes as early as possible. From the onset, accustom the development team, management, or (if you’re the programmer) that part of you that’s going to do the programming, to the fact that the prototype will be the primary way user interface will be communicated. The earlier you do this, the sooner the rest of your team will accept and incorporate it into their vocabulary. The more consistently you enforce this approach, the easier it will be for the team to appreciate the differences between functional, programmatic, and user interface concerns.

• Gear your prototypes to program specifics. The prototype is not intended to communicate everything the software product can do. That’s the job of the software product.

• Generate prototypes in response to current problem situations. Submit programming problems to usability testing as soon as they crop up.3 Programming problems tend to resurface as UI dilemmas. If they can be prototyped early, then the whole problem might be able to be nipped in the bud.

• Submit user interface artifacts (icons, dialog boxes, etc.) to static prototype presentations. Each artifact might look great on its own, yet work terribly in conjunction with the others. Static prototypes such as storyboards and tables can effectively show design relationships one can’t normally catch by operating the program and encountering these objects sporadically.

• Finally, test the final product’s UI implementation to assure that it corresponds to the design and intent of the prototype.

Prototyper skills

Designing a prototype involves more than just knowing how to build an animation or organize a presentation. You must know your audience, their needs and their desires. You must decide how you’re going to classify interface requirements into manageable chunks and how you might string them together to design prototypes that will effectively address unique problems and communicate specific solutions. Finally, you must be prepared to modify the prototype to address problems and concerns that may arise.

The more prototypes you implement, the better you’ll be able to determine where shortcuts can be introduced to speed up the prototype development process.

No matter how simple your development effort is-whether you’re developing a product for single or multiple platforms-you’re going to be managing a set of prototypes. Two prototype managers are worth pursuing from the onset: a database to house and present prototypes and an archiver (and orderly archiving process) to store and recall previous prototypes and their versions. The effort you spend with these approaches is well worth the time. A properly designed database and archive will be modified and reused frequently.

Prototype Tools

The prototype is the primary user interface design tool. To generate and maintain prototypes, the UI developer requires prototyping software/hardware, presentation software/ hardware, database software, and archiving software.

Because prototyping can be an extremely time intensive activity, it’s important the prototyper use the appropriate tool for the appropriate job. The tools you use must be able to generate, maintain, and update prototypes in the most efficient manner and shortest time frame possible.

First, let’s refine our definition of a prototype.

• A prototype is a model, not a description. A complete prototype includes a demonstration (commonly considered the “prototype”), a presentation and feedback mechanism (database), and an archiving mechanism.

Prototypes are visual representations. They may or may not be animated. (Prototypes may be supplemented by tables and diagrams.)

• The animated prototype must be capable of generating convincing-interactive if possible-situations that accurately replicate how the program will operate.

Demonstration tools:

Prototype animation or presentation software should reflect your sense of design. It should not be a testament to your ability to program or create Emmy-winning multimedia animations.

If your prototype is intended to reflect non-platform specific concerns, the software must provide a palette that can reflect your vision rather than be tied to the interface requirements of an existing platform.

Conversely, if your intent is to reflect a design subscribing to the requirements of a particular platform (e.g., a dialog box design or menu ordering), then the prototype software should be designed to reflect that platform’s look and feel. Though you may be able to emulate any platform’s look and feel using a bare bones package such as MacroMind Director, if you use software designed to address a particular platform (such as AppMaker or Marksman), you’ll be more accurate and probably more efficient. It also provides the service of doublechecking your design’s compliance to that platform’s UI requirements.

Many designers use HyperCard or SuperCard to generate interface prototypes. HyperCard’s readily available interface widgets, direct drawing tools, and growing library of user programmed XCMDs make it a very rich prototyping environment. SuperCard’s better cursor control, color, and more sophisticated drawing tools make it a prototype tool of choice if you want to demonstrate more drawing specific tools. WindowMaker by Heizer Software is an extremely powerful HyperCard window and dialog making environment which allows you to generate highly functional dialog boxes of practically any design. A drawback to HyperCard and SuperCard is that in some cases (especially testing situations where responsiveness is important), they aren’t very fast. In the HyperCard environment, you might gain the speed you need (at the loss of language flexibility) by compiling a script using Heizer’s CompileIt.

For pure animation facility supported by a scripting language that allows a high degree of interactivity MacroMind Director is hard to beat. Using Director you can simulate practically any 2D interface. You should operate Director under MultiFinder with access to a drawing program such as Canvas and/or a paint program such as Studio 32 to handle your graphics items. Director’s scripting language, Lingo, is powerful, but only if you plan to run the prototype from Director. If you plan to save your demonstrations in QuickTime format, all your Lingo efforts will be in vain. Director allows you to save file run time versions for distribution.

None of these demonstration tools adequately address 3D interfaces where you might be hard pressed to hand draw the effect you want (such as might be desired in a virtual reality or 3D program). These tools don’t seem powerful enough to address situations where, rather than choreograph an activity you want to experiment with various algorithmic responses. Interface design sometimes involves problems where you have an idea what will generally happen yet you can’t adequately predict what the exact behavior of the interface will be. For example, you may want to observe the behavior of multiple cursors affecting a multicolor raster terrain or single cursors with multiple hot spots/areas moving over multiple objects. This experimental work requires higher-level programming languages beyond the scope of this article.

Presentation tools:

A good presentation tool permits the viewer to page through, play, or interact with the prototype with a minimum of effort. Animation software and drawing programs (with an exception cited below) aren’t necessarily satisfactory presentation devices. Presentation programs are often designed to support a formal presentation with slide presentations and supplementary material (e.g., handouts) and not to provide the independence a prototype requires.

Prototype presentations require a presentation database.

Multimedia programs such as Director can provide the interactive functionality you require, but a program such as HyperCard driving Claris’ QuickTime init in tandem with a good reporting utility such as Reports, by Nine to Five software4, is a powerful way to access and play single or multiple QuickTime prototype demonstrations (culled from various sources).

You want to end up with a presentation that permits the viewer to play and compare prototypes for consistency, read related comments, and respond to the prototype in a way that’s specific and complete.

My favorite combination is Director and HyperCard. MacroMind Director is used to generate the guts of the animation. Director’s scoring grid permits me to organize and categorize the animation in parts, and its cast permits me to store and substitute alternative interface artifacts (imported from Canvas and Studio 32). I save the Director animations as QuickTime movies. This gives me an easily modifiable base file in Director format and relatively tamper proof QuickTime files for distribution.5 I import the movies into a HyperCard stack. Each card’s title and title modifier fields determine which QuickTime routine that card will access. Each card contains a description field to describe nuances worth noting in the demonstration and a comments field to solicit feedback. My stack contains lists and buttons to locate and activate the QuickTime animation and perform finds and sorts to peruse the database without having to page through it card-by-card. I’ve added to the stack a report generator to address prototype specific concerns.6 Animations can be run forward, reverse, step-by-step, etc.

Concerning hardware, the faster the machine, the more the memory, and the larger the screen the better. Efficiently operating in Director requires the room to open up multiple windows and to inspect large chunks of the score and cast and the memory in order to switch between the animator and the draw/paint programs you’ll be using to generate graphics. Efficiently viewing a HyperCard stack and simultaneously running one or more animations requires memory and a large landscape.

A new approach which might be more serviceable to someone experienced with drawing programs is that posed by Aldus’ Intellidraw. This application permits you to cycle through drawing layers based on “smart” graphic objects and contains associative graphic capabilities that allow you to set up intelligent templates and maintain spacing and alignment relationships.

Why a Database?

The database concept is important enough that it deserves closer inspection.

A prototype is an attempt on the part of the UI designer to speak in a language that reflects the (communication) environment the user faces when confronted with a piece of software. The prototype is an attempt to circumvent natural language descriptions. However, because it is part of a greater programming effort that has nothing to do with the user (but is more concerned with developer capabilities, marketing directions and schedules, etc.), it cannot completely avoid natural language description. Most of the in-house feedback (from other developers, managers, and power users) the UI developer receives will be couched in natural language. To manage this feedback, to ensure changes respond adequately to this feedback, to provide an information pool which might be used by QA and documentation, and to provide a groundwork for future development, it’s necessary to record comments and descriptions in a form that unambiguously associates them directly with the prototype sequence in question.7 This can be accomplished by integrating the database with the demonstration.

The other critical prototype component that the database should provide is a feedback mechanism. Along with supplying relevant descriptions of what is happening in the prototype, the database should allow the observer to freely insert comments relating to the prototype.

Traditionally the user gets feedback through conversations and e-mail. No matter how accurate this feedback may be, separating it from the direct visual material it’s relating to increases the possibility the feedback will lose its relevance. Tying the feedback cycle to something concrete serves both the designer and the responder.

Archiving tools

UI development is a changing process requiring continual modification based on user, coder, and interface designer concerns. Often you’ll find yourself recalling and rehashing previous concepts and approaches. It’s not unusual for someone-late in the development cycle-to request a situation that is virtually synonymous with an earlier approach. A properly designed and maintained archive can save a lot of wasted time8.

Retrospect, by Dantz Software, provides reliable, full featured, and automatic (if desired) archives to any media. Its search and browse facilities are unparalleled. Recently I’ve been using file synchronization programs (e.g., Magnet) to set up mirror image directories of my current work so that I can have a quick and dirty backup version of my current files on hand.

Other formal devices

We’ve covered the essential prototype requirements. However, there are instances where you need to communicate other interface particulars such as dialog box designs, or interface generalities such as consistency issues.

When attempting to communicate UI aspects such as consistency issues or continuity strings, you should consider using devices such as forms, tables, spreadsheets, etc. These formal means are concise and specific and complement the programming requirements the rest of the team must adhere to. They also force the UI designer to think and communicate rigorously.

UI is an informal medium. It’s more amenable to conversation than calculation. Conversation tends to take up space and time. For efficiency sake, every effort should be made by the UI designer to formalize UI development procedures as they relate to the rest of the developer group.

Formalization cuts through descriptive conversation and concentrates on the problems at hand. It helps the parties understand each other’s needs more clearly. Finally, it provides a clearer paper trail to inspect and evaluate which directions the program might take in the future.

A formal device I find particularly useful in ordering my thought processes and clearly presenting my ideas is the IDEF flowchart method meticulously enforced by Meta Software in its Design/IDEF program.9 Using the IDEF structured analysis and design method, I can design a clear set of flowcharts that map the relationship of input, output, and internal mechanism and control elements. It graphically conveys the functionality of the interface I’m prototyping with enough precision to be accurate, yet enough leeway to allow me to communicate effectively. After I’ve established a base set of templates, I can map a new function onto an existing template and visually determine how well the two are behaviorally equivalent.

IDWF diagrams are also excellent communications devices. More often than not, in order to satisfy time constraints, changes have to be made to the design. I use the IDEF diagrams to determine how a feature can be eliminated without adversely affecting the functionality around it. More important, I can-without disturbing the whole diagram-visually gray out or box in the removed areas. Later, I can easily return to the lost feature when the opportunity to reinstate it resurfaces.

Whenever I feel a need to organize information quickly, the software I turn to is Claris FileMaker Pro. There are few database applications which this fast and flexible database can’t handle. Its Macintosh/Microsoft Windows inter-functionality should make it a logical database for networked cross-environment development groups.

UI designers want to design user interfaces. Programmers want to program. Formal devices provide both of these parties the vehicle they need to communicate without having to worry about the vagaries of being a “writer”.

What Is a Prototype

Trying to Communicate

The prototype should be the primary communication tool UI developers use to communicate their designs to the rest of the development community.

Prototypes should convey the following information:

• Compliance to general design principles stated in the product spec.

• General Appearances: through pictures (static prototype)

• Specific Movements: through animated pictures (moving prototype)

• Descriptions: through description field(s) residing on the database that holds a particular prototype.

• Feedback: through a feedback field on the database that carries the prototype.

• The demonstration(s) is the actual prototype; the presentation is the vehicle through which the user accesses the demonstration and understands what’s being attempted by the demonstration; the feedback mechanism is the means by which the user can respond to the demonstration.

The Kiosk concept: a communication environment

The Kiosk Concept consists of strategically placing a few prototypes in areas where they can be accessed, responded to, and updated. (Storyboard prototypes may be posted on walls bordering well traveled routes.) Kiosked prototypes enable users to interact with the prototype on a casual conversational level. The user is free to observe and operate whatever part of the prototype he desires and respond in whatever ways he deems appropriate. At selected intervals you “collect” all the responses and update the prototype.

Conclusion

Prototypes are demonstrations that simulate (rather than describe) software functionality. Prototypes include everything from hand drawn storyboards and tables showing icon design alternatives to interactive animations.

A prototype may be simple-demonstrating an aspect of an interface’s design-or complex-allowing the user to interact with the prototype much as the user might interact with the final program. A prototype may be specific (covering a feature) or comprehensive (covering the interaction of many features).

Resign yourself to the fact that your software development cycle will be iterative-that as you or your associates become more aware of the intricacies of your product that you will probably have to reconsider similar problems over and over albeit from slightly different perspectives. Accept the fact that iterative problem solving is natural to the development process and you’ll end up with a product that’s more natural to use.

Product Index:

AppMaker: Bowers Development, Lincoln Center, MA. (508) 369-8175.

CompileIt: Heizer Software, Pleasant Hill, CA 94523.

(510) 943-7667.

HyperCard: Claris, Santa Clara, CA 95052-8168. (

408) 727-8227.

Design/IDEF: Meta Software Corp., Cambridge, MA 02140. (617) 576-6920.

Intellidraw: Silicon Beach Software, San Diego, CA 92126. (619) 695-6956.

Magnet: No Hands Software, Palo Alto, CA 94306.

(415) 321-7340.

Marksman: IT Makers, San Jose, CA 95173. (408) 274-8669.

QuickTime (XCMD for HyperCard): Claris, Santa Clara, CA 95052-8168. (408) 727-8227.

Reports: Nine to Five Software Company, Boulder, CO 80301. (800) 292-5925.

Retrospect: Dantz Development Corp, Berkeley, CA 94709. (510) 849-0293.

SuperCard: Silicon Beach Software, San Diego, CA 92126. (619) 695-6956.

WindowMaker: Heizer Software, Pleasant Hill, CA 94523. (510) 943-7667.

Footnotes

1 Natural language is NOT an adequate tool to express interface design. Natural language is (by its very nature) descriptive, non-contextual, subject to extreme variations of interpretation, and difficult to upgrade and maintain consistently over the range of the interface.

2 It is not only inappropriate, it’s often counterproductive to attempt to be totally comprehensive. For example, it can be more time consuming to update a prototype incorporating the full-menu condition than it might be to update a smaller prototype devoted to demonstrating a particular point.

3 Future articles will discuss usability testing.

4 Reports may be the single most useful utility available for HyperCard stacks. Though it is possible to build reporting capabilities into any stack, the time and effort required far outweigh the investment you’d make in this excellent HyperCard adjunct.

5 QuickTime is a reasonable movie medium because it’s a general format exportable to various programs (including spreadsheets, word processing documents, and databases); it’s primarily a playback medium; and it’s relatively secure and easy to manage.

6 For example, the report generator can compile a list of all the titles/feedback I’ve received in this stack, or list all prototypes that address the problem from a verb/object point of view.

7 Commenting the UI portion of a product spec narrative seldom addresses the UI context adequately.

8 Archives maintain a running record of versions. Backups maintain a temporary set of archives which is periodically replaced.

9 Meta software also provides a state of the art flowchart programming environment, Design 3.0. Less expensive than the IDEF version, Design doesn’t subscribe to the dictates of the IDEF methodology.