Interface 8
Volume Number: 9
Issue Number: 6
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 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 rePlanreImplementreMeasurereLearn
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