Inventing the Future with Structured Planning
Systems Design Methodology for Software Products
Version 2.1, June 6, 1995
1. HUMAN CENTERED DESIGN
1.1 User Interface Clones
Despite increased attention to software user interface design in recent
years, it rarely goes beyond mimicry.
At first every "user friendly" system attempted to be a lawsuit-proof
Mac clone, itself a derivative of Xerox PARC's STAR System. Procedures
like dragging a file name across the screen to an iconic trash can soon
became the standard, though arguably not the best (much less the only)
way to remove a file. Some have replaced it with a black hole,
presumably appealing to "power users", and we can easily imagine
recycling bins for the environmentally conscious, but the basic concept
is the same. Wisely (but just barely), the industry avoided a
debilitating intellectual property rights battle over the concept of
electronic trash and its disposal.
One size fits all.
All too often user interface design simply means providing "windows"
(which are more akin to stacks of paper) and "GUIs" that relegate all
computer interaction (save actually typing text) to point-and-click
operations. Interface design often simply means complying to the "look
and feel" guidelines of the host operating system, which are themselves
all the same except for minor differences among widgets like buttons
and scroll bars. Companies employ visual designers to create clever
icons, fine tune the graphical layout and spec typography, but
essentially one size fits all.
The copycat and faddish character of interface design is arguably
becoming counter-productive. As icons proliferate, many are as cryptic
and obscure for visual memory as the alphanumerics they were meant to
replace. Consequently, we must often rely on an associated text label
to derive an icon's meaning, and the icon itself is reduced to little
more than a target for the mouse cursor, not a medium for information.
Groping for a workable conceptual model, the software industry has been
a-buzz with the latest fad concept, for example that of "metaphors", a
useful but obvious and simplistic idea, but hardly a complete design
paradigm. Certainly it is important to leverage off the existing
skills of the user community. But while they may be appropriate for
the extremely inexperienced user, isometric drawings of an office desk
complete with notepad, clock, desk calendar, file cabinet, and the
mandatory trash can seem somehow archaic for a technology that is
supposed to be "enabling". What metaphors exist for downloading a
graphic image to your car's cellular phone-cum-fax machine, or turning
email text into sound and forwarding it to somebody's voicemail?
1.2 Interface Standards
The auto industry standardized on nuts and bolts, not the look and
feel of the Model T.
Afraid of being left out or left behind, many
companies clamor for interface design standards just as they do for
engineering standards. Whether for Mac OS, MS Windows or UNIX Motif,
the assumption seems to be that the art has been reduced to a science.
While consortium efforts like COSE/CDE may offer mechanical benefits in
cross-platform engineering and an apparent tour de force against a
common competitor, standardizing on primitive interfaces is a way to
institutionalize the mediocre - to everyone's disadvantage. Any
company that cannot or will not go beyond copying everyone who is
copying everyone else is guaranteeing its products won't be any better
than those of its competitors. The auto industry standardized on nuts
and bolts, not the look and feel of the Model T.
1.3 Usability and Productivity
People use software in ways that are familiar but absurdly
inefficient. No surprise to most software engineers, this is even true
for non-technical people working for the companies that produce it.
Consider the seemingly simple task of writing and printing an ASCII
file. People typically use fancy word processing applications,
suffering the slow performance of unnecessary overhead, only to save to
"text file" before they pull down a menu to print. Others will use a
mail system to compose the document, mail it to self, then drag and
drop the mail message on the printer icon. Infatuation with the mouse
has led to bizarre and counter-intuitive canons: the typical word
processing package requires mouse movements for all operations except
entering text itself, a sort of writing by drawing. Old fashioned text
editors at least keep your fingers on the keyboard, but they are only
used by "techies" because the editing key-stroke sequences are baroque
and poorly documented.
Other examples abound for every major operating system and
application. To illustrate, we will pick on two of the most popular.
As late as 1995
configuring a modem on UNIX (the system invented by The Phone
Company) requires manually editing at least two obscure text files and
considerable esoteric knowledge to get it to communicate at speeds
faster than 2400 baud.
And it was standard operating procedure on MS DOS
(the system then running on 75% of the world's PCs) to constantly diddle
startup files so that applications could run in the 640K of
"conventional memory", even if you had 32 MB or more to spare. The
producers plead backward compatibility, but are we being productive
Tempted as some are to blame the user instead of the system design, or
at best responding with wrappers that treat users as morons, these
inefficient behaviors are not the result of user stupidity. They are a
function of learning a way to get from "a" to "b" in spite of being
intimidated by ominously thick manuals, being flummoxed by obscure
command-line syntaxes and meaningless icons, and being burnt by
mysterious error messages that read as so much technobabble. Faced by
the alternatives of expensive "support" contracts, long distance phone
calls, thick manuals of technical jargon, and lost time in the face of
production deadlines, most users default to coping with what they have
learned to work, inefficient as it may be.
Most have yet to fully realize that the system is the interface.
As software interface experts like Bill Buxton and Bruce Tognazzini
point out, the problem here is not simply ease of use - it's
productivity. Users will employ the best way they know to accomplish a
task, but the performance of the user-system ensemble is often far from
expert. While the producers of these systems claim to have "enterprise
solutions", most have yet to fully realize that
the system is the interface.
No amount of visual interface styling or homey metaphors is
going to fix a system that is fundamentally broken.
1.4 Customer Feedback and User Requirements
For all its rhetoric, the industry's supposed "customer focus" in the
design of software systems and products is basically a sham. The truth
is that almost nobody
listens to the user community. There is a
lot of schmoozing of CEOs and CIOs (the guys with the money), and
engineers like to talk shop with other engineers, but hard information
with heuristic value regarding user requirements is scarce.
"Listen to Your Users, but Ignore What They Say."
Nathaniel S. Borenstein in Programming As If People Mattered
Software companies typically have no ongoing market research
program that provides a steady stream of customer feedback or insight
about changing trends. Product requirement documents from marketing
are often too vague or too obvious to be of any real help to
engineering, and trip reports from customer site visits often say
nothing more than, "They like us." Too often customer research efforts
like Focus Groups ask the wrong questions, subtly biasing answers a
priori to suggest safe, boring, and ultimately inconsequential line
extensions of the status quo. Cutting edge software companies are
establishing usability labs, but these often concentrate on finding
glitches in current products (and sometimes in new prototypes), rather
than observing real users in real work situations to ferret out
"If you have to test something carefully to see the difference it
makes, then it is not making enough of a difference in the first
Nicholas Negroponte in Being Digital
There is more to
the total systems interface
than the look and feel of
a GUI clone; there is more to human factors than visual perception and
mouse-motion ergonomics. What about the psychological needs of
security and privacy, for example? What about the social human factors
involved in fostering effective teamwork? For that matter, what about
other sensory modalities like sound, touch and the kinesthetics of
We sometimes forget that there are more users than the "end user".
Considered throughout its life cycle and in all its modes of existence,
there are others who must deal with "the system". What about the sales
person demoing it? What about the CS personnel supporting it? What
about the distributor upgrading it? What about the OEM bundling it? A
well-designed software product would respond to the requirements of all
of these "users".
There is typically no formal or standard process to get the user
requirements into the software development process.
To be fair, quality improvement programs, recommendations from
marketing and sales personnel, analysis of bug reports and RFEs, and
the findings of usability labs and human factors analysts often yield
bits of design insight. Even so, there is typically no formal or
standard process to get the user requirements into the software
development process, either at the level of steering committees or of
routine engineering. Indeed, formal software engineering procedures
typically begin with steps for implementing ideas but say virtually
nothing about basing those ideas on hard customer or user data.
1.5 Extended User Requirements
The software industry can and must do much better. The survivors will
separate from the crowd by expanding the definition of "the users" and
their "human factors" and by employing design research methods aimed at
discovering what really makes them tick. This requires a software
design process that starts with insights about user requirements,
correlates them with other design considerations, then proceeds to
develop creative and effective design solutions.