|Column Tag:||Interfacial relations
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 thats obvious to the user is part of the interface design process; everything thats 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 users 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.
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, its debatable whether natural language isnt 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, youre 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 dont 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: Whats visually happening on the screen must be designed with an eye to whats already happened as well as whats about to happen.
Logical context: Whats logically happening must be designed with an eye to whats already happened as well as whats about to happen.
Procedural context: Whats 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 cant 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 users job requirements or insults the users 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. Its important to make sure youve 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 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 youre the programmer) that part of you thats 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. Thats 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 cant normally catch by operating the program and encountering these objects sporadically.
Finally, test the final products UI implementation to assure that it corresponds to the design and intent of the prototype.
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 youre 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 youll 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 youre developing a product for single or multiple platforms-youre 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.
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, its 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, lets 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.
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 platforms look and feel. Though you may be able to emulate any platforms 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), youll be more accurate and probably more efficient. It also provides the service of doublechecking your designs compliance to that platforms UI requirements.
Many designers use HyperCard or SuperCard to generate interface prototypes. HyperCards readily available interface widgets, direct drawing tools, and growing library of user programmed XCMDs make it a very rich prototyping environment. SuperCards 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 arent very fast. In the HyperCard environment, you might gain the speed you need (at the loss of language flexibility) by compiling a script using Heizers 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. Directors 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 dont 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 cant 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.
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) arent 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 thats specific and complete.
My favorite combination is Director and HyperCard. MacroMind Director is used to generate the guts of the animation. Directors 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 cards 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. Ive 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 youll 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, its 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 its 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.
UI development is a changing process requiring continual modification based on user, coder, and interface designer concerns. Often youll find yourself recalling and rehashing previous concepts and approaches. Its 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 Ive 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
Weve 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. Its 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 others 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 Im prototyping with enough precision to be accurate, yet enough leeway to allow me to communicate effectively. After Ive 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 cant 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 whats 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.
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 interfaces 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 youll end up with a product thats more natural to use.
AppMaker: Bowers Development, Lincoln Center, MA. (508) 369-8175.
CompileIt: Heizer Software, Pleasant Hill, CA 94523.
HyperCard: Claris, Santa Clara, CA 95052-8168. (
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.
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.
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, its 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 youd make in this excellent HyperCard adjunct.
5 QuickTime is a reasonable movie medium because its a general format exportable to various programs (including spreadsheets, word processing documents, and databases); its primarily a playback medium; and its relatively secure and easy to manage.
6 For example, the report generator can compile a list of all the titles/feedback Ive 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 doesnt subscribe to the dictates of the IDEF methodology.