The Value of Visual Design
in Software Development
Kimberley Peter
IBM | kpeter@ca.ibm.com
value they can bring, or lack of
funding to expand the team to
include them.
Given the taste we have
developed for more thoughtfully
and elegantly designed user
interfaces in both consumer and
business segments, is it a good
idea for software companies to
exclude visual design from their
project teams?
[ 1] Baecker, R.
“Themes in the Early
History of HCI -
Some Unanswered
Questions.” interactions
15, no. 2 (2007): 22-25.
January + February 2009
[ 2] Monson, P., C.
Pampino, M. Gothe,
N. Yuce, K. Nizami,
K. Patel, and B. M.
Smith. “Collaborative
Application Lifecycle
Management with
Rational Products,” IBM
Redbooks® (draft),
June 2008.
The question of whether or
not visual design has value in
software might seem moot. For
decades now, graphical user
interfaces have been the dominant paradigm [ 1]. We revere
the visual fruits of Apple; we
delight in the graphical levity of
the pervasive Web 2.0 look; and
we get a visceral tickle out of
the many visual and interactive
effects of the Microsoft Vista,
Linux Ubuntu, and Mac OS X
operating systems. We like to be
delighted and engaged visually.
And why not? Whether our use
of computer software is business
or personal, we spend a lot of
time with machines and the soft
stuff that helps us get things
done. The time spent might as
well be pleasant.
This sentiment is appreciated in mainstream software,
yet things have been a little
different in the world of software development for programming and business tools, where
user delight and the virtues of
visual elegance have not been so
widely or confidently embraced.
Things appear to be changing,
and exposure to design is a significant part of this change.
Dearth of Designers /
Dearth of Design
Each day I work with people
whom I consider sophisti-
cated users. These are the
ones who make software for
software developers and the
related technical and nontechnical disciplines that
use Collaborative Application
Lifecycle Management tools
[ 2]. As a team we create both
desktop and Web-based applications. Increasingly, we use the
tools we build. We are also collectively exposed to a great deal
of software, both mainstream
products and the tools we use
to do our work. This exposure
helps to inform our expectations of our own products, as
we increasingly expect them to
do more and look great. As we
have sophisticated and diversified audiences, we want the
tools we build to offer more
than the same old integrated
development environment (IDE)
interfaces of years running. We
also need to be competitive. To
do that, attention to product
interface design and its level of
quality are essential.
Transformation is wanted,
expected, and happening. It’s
a good time to be a visual
designer.
Still, I do hear of designers
struggling in their organizations
to make a difference, to exercise
their capabilities beyond the
usual graphical requirements.
Additionally, there are software projects in which no
visual designers are involved at
all. Part of this may be lack of
awareness or recognition of the
Toolkits and Prêt-à-Porter UI
I observe in my daily work that
the availability of toolkits can
have an influence on whether or
not a visual designer is involved
in a project, or to what degree.
Toolkits provide varying degrees
of ready-to-use function often
replete with the code that renders the UI, what I will call
prêt-à-porter, or ready to wear. This is
beneficial if you are a developer
because coding from scratch
can be much harder; it takes
more time, and it can be highly
experimental until a suitable
and desirable solution is determined.
But do we want our software
to look the same as numerous
others using these prêt-à-porter
toolkits, particularly those of
other companies?
Consider Eclipse, an open
source IDE and framework that
provides the tools to create Rich
Client Platform (RCP) applications as wide-ranging in purpose
as Soccermaster RCP for track-
