Sigma Imaging Systems
622 Third Avenue, 30th Floor
New York, New York 10017
(212) 476-3000
In a business environment, resource, budget and schedule constraints profoundly affect a product's user interface design. This paper describes the design of a graphical workflow application as it was affected by compromise between management, design and development during the product life cycle.
The product is tracked from its initial implementation as a highly functional utility with a non-standard user interface, to its brief life as a prototype representing the ultimate workflow tool. Primary focus is on the third, most recent version, and the design problems that arose in delivering a highly usable interface within practical, real world constraints.
Iterative design, resource constraints, compromise, prototyping, usability testing.
RouteBuilder 1.0, released in 1990, was the first graphical
workflow product on the market, allowing businesses to
define the routing of work between users for processing.
The goal was to enable business managers to create and
maintain department workflows without knowledge of
programming or scripting languages. Developed by a small
group of programmers with limited user interface expertise,
RouteBuilder 1.0 focused on utility rather than usability.
The ability to build a workflow using drawing tools was
revolutionary, setting the standard subsequently copied by
other software companies. Still, major portions of the
interface were difficult to use. While the RouteBuilder 1.0
development team had a thorough understanding of the
users' needs, no formal usability testing was performed
before release.
After release of the initial product, developers worked
closely with users for three years to understand how they
utilized and interacted with the product. Problems were
corrected, features added incrementally, and
recommendations gathered for future iterations. This field
experience, together with trends in the marketplace, formed
the basis of later versions.
RouteBuilder 2.0, a prototype, focused on an appealing
user interface, and illustrated future product direction. The
goal was to identify the scope of work necessary to
implement a new front end incorporating added
functionality, and to surpass other companies beginning to
release competing products. The front end was prototyped
using visual programming tools and designed without
consideration of practical constraints. The cost of actually
implementing expensive user interface features was
disregarded, encouraging over-featuring of the product.
RouteBuilder 2.0 was created by a user interface designer
and a product manager, with limited input from
development. This version, demonstrated at trade shows
and conferences, was very well received.
RouteBuilder 3.0, currently in the development process for
release in 1995, strikes a balance between the two previous
versions, focusing on both functionality and usability. The
goal was to design a powerful, usable product that could be
implemented within budget and schedule, while laying the
groundwork for future versions. The product was designed
by a larger, more varied team, applying a more structured
approach to software development The design cycle
included requirements definition, functional specification,
prototyping, usability testing and quality assurance testing.
The RouteBuilder 3.0 design team consisted of a core of
developers with a range of GUI and workflow experience,
two project leaders responsible for resource management
and scheduling, a user interface designer, and a marketing
person familiar with existing users and industry trends.
Periodic input was solicited from documentation, quality
assurance and graphic design experts. This
multidisciplinary approach encouraged discussion and
allowed many perspectives and areas of expertise to be
incorporated into the final product. However, it also
brought together people with different, sometimes
conflicting agendas.
Project management's agenda was to deliver a product that
satisfied the functional requirements, within schedule, with
the allocated development staff. Marketing wanted to
provide functionality and a user interface competitive in
the marketplace. The interface designer' s objective was to
provide an elegant, easy to use interface camouflaging
complex underlying technology. Development's goal was
to implement a stable, technically powerful, state of the art
product, optimizing programming efficiency by reusing
programming code across the application. The system
designers, much to their credit, rarely allowed
implementation issues to cloud the front end design.
Disagreement between team members was resolved in
several ways. In most cases, project management's agenda
took priority. They weighed necessity against affordability
and either included or cut features. In several instances,
upper management vetoed decisions made by project
management. One figure in upper management, heavily
invested in interface design, became the user interface
champion, salvaging components that he deemed necessary
for the product to be competitive by allocating additional
resources. Issues were occasionally decided by personal
factors, such as how persistent and energetic each team
member was, and who argued the most eloquently or
screamed the loudest.
This team approach to design resulted in a well balanced
application. The interface model was preserved, though
with less front end functionality than originally specified.
Practical constraints resulted in features being cut,
especially those provided solely to enhance ease of use.
Multiple techniques for performing the same task were
eliminated. Interface behavior was occasionally revised to
allow reuse of program components or to increase
performance. For example, when the algorithm for drawing
workstep connection lines proved too slow, the visual
design was changed to optimize performance. Some
functionality, eliminated during the estimation process, was
restored after testing proved it necessary for ease of use. In
addition, features supported at low cost by a new class
library, Microsoft Foundation Classes (MFC), were
exploited. This boosted the quality of the user interface and
its compliance with Windows GUI standards.
These design modifications affected departments outside of
development. Documentation, quality assurance and
marketing departments began writing user guides, test
scripts and promotional materials. They soon discovered
that they were documenting a moving target. As this
problem became clear, they were informed of upcoming
design revisions more quickly. While the iterative design
cycle slowed their documentation process, frequent
communication helped avoid duplication of effort.
In this development environment, the role of the designer
became to design the most reasonable interface within
practical constraints, eliminating or revising features and
exploiting easily supported functionality. It also became an
exercise in revising, refining and documenting highly
detailed designs, and communicating these changes to
development, documentation and quality assurance
departments. Multiple versions of design documentation
were maintained, to be used when cut features were
restored, and to provide input for future product versions.
A primary responsibility was to argue for features that, if
eliminated, would jeopardize product usability or preclude
future enhancements. However, the designer was
occasionally too reluctant to abandon designs and could
have spent less time on detailed definition of features likely
to be cut. The design cycle was a lesson in compromise,
paring down the ultimate yet impractical front end to
achieve a scaled down, usable and implementable
interface.
RouteBuilder 3.0 includes several unique and innovative
features that distinguish it from other graphical workflow
tools. The evolution of these features, including graphical
route creation, dynamic and intelligent rule creation,
prepackaged worksteps and legends, is described below.
Specific design goals for RouteBuilder 3.0 included tightly
integrating visual elements with underlying behavior,
camouflaging the complex workflow engine, eliminating
redundant tasks, and complying with GUI standards and
state of the art interface techniques.
Prototyping was advocated by management from the
beginning of RouteBuilder 3.0. Prototypes met with
varying degrees of success based on the tools used, the
suitability of the features selected for prototyping, and the
technical skill of the individual building the prototype.
Usability testing included paper prototypes, on-screen
prototypes built using Visual Basic, Visual C++ and MFC,
and customer presentations and reviews. RouteBuilder 3.0
was coded in segments, allowing features to be tested and
revised on an ongoing basis, rather than waiting for testing
of a complete product.
Window structure and components vary between the three
product versions, based on design decisions,
implementation constraints and changes in GUI standards.
The main windows of the three product versions appear in
figures 1-3.
FIGURE 1.
RouteBuilder 1.0
FIGURE 2.
RouteBuilder 2.0
FIGURE 3.
RouteBuilder 3.0
The RouteBuilder toolbar changed dramatically between
product versions. RouteBuilder 1.0's static toolbar was
replaced by RouteBuilder 2.0's dynamic toolbar (figure 4),
whose elements changed as different tools and route
objects were selected.
FIGURE 4.
RouteBuilder 2.0 dynamic toolbar
RouteBuilder 3.0 initially called for the highly dynamic
toolbar prototyped in version 2.0. The 3.0 design was
revised several times due to tradeoffs between costly user
interface behavior and practical budget constraints.
Deemed too costly to implement, the dynamic toolbar was
replaced by one with static buttons. Microsoft Foundation
Classes allowed advanced interface behavior scaled down
during functional specification to be integrated into the
final product. MFC facilitated the implementation of
behavior compliant with emerging Windows interface
standards that had not existed during toolbar specification.
The result was not exactly like the 2.0 toolbar, but was
equally usable and had additional capabilities, including
user configurability. RouteBuilder 3.0 now features a state
of the art toolbar with context sensitive elements. Segments
can be rearranged and docked along any window edge, or
torn off to become free floating palettes. The toolbar (seen
in figure 3) also features popup Tool Tips and status bar
messages to provide users with on-line help.
Toolbar icons for RouteBuilder 1.0 were designed by a
graphically competent programmer. For version 3.0,
management realized that hiring a graphic designer to
create an icon set would not cost more than a programmer
doing the equivalent work, and would produce far superior
results. Visual Basic and MFC were used to prototype
toolbar composition and behavior. On-line usability tests
(figure 5), created in Visual Basic and distributed
electronically, were used to validate icon design, select the
contents of the RouteBuilder icon library, check icon size
and color on a variety of monitor types, and determine the
composition of toolbar segments. In addition to user
responses, hardware information, such as monitor
resolution, was captured automatically. The toolbars were
initially tested in-house, then distributed to customers in
the United States and finally tested internationally. Testing
resulted in 25% of the original icons being totally
redesigned, and another 30% modified slightly.
Prototyping and usability testing of the toolbar were
successful for several reasons. Visual Basic and MFC
facilitated rapid development at low cost. Visual Basic, in
particular, did not require much technical expertise. It also
helped automate the test distribution and data gathering
process. Finally, the toolbar feature was suitable for
prototyping since it could run standalone, not requiring
integration with the entire workflow system.
FIGURE 5.
RouteBuilder 3.0 icon usability test
Each RouteBuilder workstep represents a processing
activity. User generated rules determine the routing of
items between worksteps. Unlike other workflow tools,
RouteBuilder provides a graphical interface for rule
creation, and does not require users to program.
RouteBuilder 1.0 provided a linear technique for rule
creation (figure 6), requiring navigation through multiple
modal dialog boxes, with rules created and viewed
individually. Complex rules could be created, yet the
interface was cumbersome.
FIGURE 6.
RouteBuilder 1.0 Rules dialog
The RouteBuilder 2.0 Rules dialog (figure 7) retained the
basic rule creation structure, but replaced multiple modal
dialogs with a single dialog box. Rules were set via
controls displayed dynamically based on context. Users
could view and manipulate multiple rules simultaneously.
FIGURE 7.
RouteBuilder 2.0 Rules dialog
RouteBuilder 3.0 expanded the scope of the rules,
requiring the addition of interface elements to support new
functionality. This motivated total revision of the rule
creation interface (figures 8-10). Controls were originally
specified to appear dynamically within the rule, providing
context sensitive selections and allowing direct
manipulation (figure 9). While this seemed usable as
documented, and even as tested with paper prototypes, it
was visually disconcerting on screen. When the design
problems could not be resolved within the time allocated,
the moving prompt was revised to be displayed in a fixed
location (figure 10). The resulting interface is effective for
experienced users, but daunting to novices. Features to
assist users, including context sensitive help and support of
novice and expert modes, are contingent on scheduling.
Rules prototyping was originally intended to be done with
MFC, with prototype code being used for the actual front
end. This plan failed because inexperience with the new
tools, including Visual C++ and MFC, made turnaround
time too slow to be effective for rapid prototyping and
revision. More successful was the use of Visual Basic for
quick, disposable prototypes demonstrating individual
aspects of rule behavior. Simple behavior was
demonstrated effectively using third party applications not
usually considered as prototyping tools. For example,
formatting and line wrap were shown using tables in
Microsoft Word. Cut, copy, paste and delete were
demonstrated using Excel macros. These prototypes were
useful in validating design decisions, communicating ideas
between team members, and raising design details for
resolution.
The RouteBuilder 3.0 rule design process was challenging,
intensely detailed and the cause of much anxiety. The
commitment to solving and implementing this design
reflects on its high degree of support by upper
management, determined to provide a unique interface
suitable for novices and experts. Were it not for this
support, the design would have been initially resolved in a
less risky manner. Of all the specified RouteBuilder
functionality, it was most difficult to envision the final look
and feel of the rule interface. It was understood from initial
design that the end result may be revolutionary for
workflow applications, or may prove to be difficult to use.
The interface is being refined and is subject to change.
FIGURE 8.
A preliminary RouteBuilder 3.0 Rules dialog
FIGURE 9.
An early Rules dialog with in-place editing
FIGURE 10.
The most recent RouteBuilder 3.0 Rules dialog
Years of field experience showed that similar workstep
types were being created by many customers. This resulted
in a new prepackaged workstep feature (figure 11), making
the creation of predefined workstep types instantaneous.
While in previous versions, workstep icons were purely
visual, prepackaged worksteps couple icons with
predefined functionality.
Packaged worksteps highlight the value of examining
product usage and providing functionality that automates
common tasks. Conceptualized by team members with
extensive customer experience, knowledge of workflow
system functionality and an understanding of how to
package that functionality, this feature would not have been
realized by a less diverse team.
FIGURE 11.
RouteBuilder 3.0 Workstep Gallery with Packaged Worksteps
The RouteBuilder 3.0 Legend feature (figure 12) allows
line styles and colors to represent different types of work
flowing through a route. Motivated by the complex,
spaghetti-like route maps generated by users of the initial
product, Legends allow hiding and displaying of
connections by style, filtering the map. The original
concept was to tightly integrate visual representation with
underlying behavior. By associating rules with Legend
styles, users could quickly generate complex rule sets by
simply drawing a connection between worksteps.
Due to time constraints, the Legend feature will provide
visual mapping of styles to user defined descriptions, and
toggling of individual styles. The ability to associate rules
with a Legend style has been postponed.
FIGURE 12.
Figure 12. RouteBuilder 3.0 Legends
Below are lessons learned as a designer working in a
business environment.
Keep the ultimate product vision in sight and define base
functionality which cannot be compromised. Learn to
distinguish between features that are critical and shape the
product's future direction from features that can dropped or
added incrementally after release.
Create a detailed and explicit user interface functional
specification, and maintain multiple versions as features
are revised. On the RouteBuilder 3.0 project,
documentation of all features was saved even after features
were revised or eliminated. When features were
resurrected, it was simple to provide developers with the
necessary specifications. Such documents also provide
ideas for future versions of the application.
Develop rapid and disposable prototypes, rather than time
consuming code, which management may feel committed
to use after expending resources. Prototype individual
features until a complete product is available for testing.
Simple behavior can be demonstrated quickly using third
party applications such as Word and Excel, not usually
associated with prototyping.
During the estimation process, beware of questions that
start with "How much would you mind if.." and "How bad
would it be if..."
Communicate design revisions with departments external
to development affected by the changes. Overlooking this
factor early in the RouteBuilder design revision process
caused quality assurance to rewrite test scripts. Informing
documentation, training, Q.A. and marketing of
modifications in a timely manner helps avoid duplication
of effort.
Track the user interface as it progresses through all phases
of development. Test interim versions of the software.
Discuss interface behavior with the developers
implementing each feature. This helps avoid
misinterpretation or oversights by managers and
developers. It also allows clarification of details missing
from the functional specification and resolution of design
problems arising during implementation.
Most importantly, realize that a user interface designer,
developing a product within practical constraints, after
negotiation and compromise, is part of the creative process.
PROJECT HISTORY
THE DESIGN TEAM
The Role of the Designer
ROUTEBUILDER USER INTERFACE DESIGN
Prototyping and Usability Testing
GRAPHICAL ROUTE CREATION
TOOLBAR DESIGN
DYNAMIC RULE CREATION
PACKAGED WORKSTEPS
LEGENDS
LESSONS LEARNED
