Great comment James, thank you!
I believe that in roughly 90% of our client work we practice similar
approach (R.E.D) and often use the similar analogy (Navy Seals vs
Regular Army troops) when discussing upcoming projects with clients....
A few footnotes:
- Following above mentioned analogy - UI Special Ops troops succeed
when wisely "deployed" in appropriate circumstances. There are
several parameters we observed in our practice that make certain
projects better candidates for R.E.D. and you mentioned a few already:
1. Product (or Service) to Market requirement - client management
must be focused on rolling product out relatively fast (not internal
IT project with looooooong time horizon).
2. Product is complex, requires a non-trivial domain knowledge and
requires fundamental (and relatively fast) re-conceptualization
3. Product already went through multiple release cycles, accumulated
(often) overwhelming number of features and internal development team
can't resolve UI conflicts through additional iterations, and / or ....
4. Through multi-company roll-up or acquisitions multiple SW products
must be brought under one umbrella and should eventually represent a
consistent family of products. Thus RED team may take on some
organizational challenges working with multiple development teams
(often spread across the globe)...
5. There are some special cases - like conceptualization of new
products but am not sure if R (Rapid) is always applicable here..
- There is one serious challenge with RED approach we are still
attempting to resolve:
1. Seems like RED team is usually able to resolve big fundamental
issues, establish new UI structure and sometimes even move the entire
product paradigm to a new level.
RED teams may be NOT as good in addressing secondary or tertiary
issues typically leaving them for developers to deal with (based on
style-guides etc.). By those I mean some secondary screens, help
systems, detailed technical writing, messaging etc.... Therefore the
final product maybe light years ahead (comparing to previous
releases) but there could multiple (very annoying) quirks diminishing
the overall experience... It always brings up a question of creating
a "DCT" ( as in Design Clean-up Team) but in practice for various
reasons it does not happen very often ...
Still working on it :) ...
Yury Frolov
Design Director, Studio Asterisk*
GUI Strategy | User Experience | Brand
415 374 7478 voice
702 446 7840 fax
www.studioasterisk.com
On Jan 25, 2009, at 10:44 PM, James Leftwich, IDSA wrote:
Discussions of approaches and methodologies of design are among our
field's most perennial and cherished. In the past few years we've
seen a number of attempts to create a taxonomy of approaches to and
philosophies of interaction design. I've had some interesting and in-
depth discussions with Dan Saffer regarding the category he defined
in his book as "genius design" and here I'll lay out my reasoning for
why a) labels matter a great deal, and b) why this term is
particularly ill-suited and counter-productive for the approach it
attempts to label.
First, the idea of "framing" must be raised. Framing refers to a
schema of interpretation, and is embodied in a collection of
stereotypes that then become the basis for how the framed issue or
subject is understood and responded or reacted to. Linguist George
Lakoff has written a great deal on the social theory concept of
framing and how it's affected our national political discourse. I
suggest that that people not already familiar with framing begin by
reading up on it, as my primary objection to the term "genius design"
is one of objectionable framing which I reject.
See: http://www.rockridgeinstitute.org/projects/strategic/
simple_framing/
I use instead the term, "Rapid Expert Design" or R.E.D. It is a
method I've learned, first through substantial side-by-side
apprenticeships with older, more experienced designers beginning
twenty-five years ago, and one that I continue share with my
consulting network and work colleagues and have myself passed on to
younger designers working with me or as part of our teams.
I'll begin by addressing the framing problems resulting from the term
"genius design.” Next I'll address some of the key differences
inherent in why I believe some people have less problems with the
term and conclude with why I and others believe Rapid Expert Design
better describes the approach we use.
I see the primary problem with the term, "Genius Design" is that it's
impossible to believe that it's an approach that many people would
aspire to. In other words, it's already *at least* something that
one would perhaps *resort* to if no other method were available.
This is an important and negative framing right at the start.
Secondary framing problems of the label "genius design" are:
1) Young designers may simply think, "Well, hey, I'm not a genius,
or don't/won't consider myself to be one, so I guess this approach
isn't for me."
2) Even experienced designers are likely to cringe at the term, and
would be loathe to self-label their philosophy and practice as
"genius design." It is not an aspirational term, and seems unlikely
that it ever could be.
Now I agree with a great deal of what Dan Saffer has to say about
what he characterizes (I make this distinction of his
characterization of the approach) as "genius design." He
acknowledges that much design, and much successful design, is done
this way. He says that much of his work is done this way, and he
alludes to the realities of design practice that all designers face.
In *my reading* however, and I'm willing to reconsider if he objects,
I detect an air of this approach being more of a fallback and
unfortunate reality, rather than a core philosophy and approach that
can be studied, practiced, and continually improved throughout a
designer's career. The section of his book on "genius design" is the
last and shortest of all the philosophies/approaches he describes,
and though he mentions the Apple iPod, there's really very little
about this approach explored in any depth.
I believe that the framing of Rapid Expert Design as "genius design"
has led directly to the kind of reactions to the term we've seen here
on the IxDA list. Namely it's an approach asking to be ridiculed,
dismissed, or attacked.
Rapid Expert Design is not a fallback approach or philosophy for me,
nor my long-time team and network of collaborators. Nor is it ego-
driven. I actually find the "ego-driven" label gambit to be an even
more problematic and pejorative framing of what R.E.D. really
represents. Some respondents in threads have claimed that the term
"ego-driven" led to defensiveness on the parts of some. I believe
that they mistook legitimate criticism of the semantics and framing
for defensiveness. No designer who's practicing intensive and
successful Rapid Expert Design is doing it to feed an ego. To call
it ego-driven would be like comparing a Special Forces soldier to one
in the regular infantry and claiming the Special Forces soldier was
simply more ego-driven. You can see it's not a very effective way,
nor the most accurate way to describe the actual differences or need
for both. And this difference between Special Forces and regular
infantry is one of many ways to see how R.E.D. compares to other
approaches to design.
Rapid Expert Design is a valid and largely missing and under-examined
approach to interactive product development (as well as re-
development, improvement, turnarounds, etc.), and this is why how
it’s framed is crucial to an adequate understanding of it.
Why is Rapid Expert Design needed?
It's needed because we live in a world with a nearly uncountable
number of undesigned and unaddressed user interface and functional
problems and inadequacies. There are also many companies that have
run products and services through many incremental, feature-loading
stages to the point of inefficiencies, inadequacies, or simple
obsolescence and yet have no effective means to move quickly to a
new, improved model or generation. I often describe this as normal
hive activities and the need for periodic swarming to establish a new
hive. Most corporations have a great deal of departmental and
political difficulty re-inventing themselves. Many languish or
perish for the inability to make this leap.
Rapid Expert Designers can be effectively employed to help catalyze
and effect such a new generation development. This can be done as a
hothouse or skunkworks and handed off (the fastest way), or it can
take the form of a team coming in a working with inside groups. The
latter can also be effective, but it often requires a much larger
incoming consulting group, is often much more expensive, can take
significantly longer, and can have more complicated political
ramifications. There are simply some situations where too many cooks
in the kitchen really can spoil the broth. This is definitely the
case with a corporation that needs to develop an OS-level revolution
in one to two years time, or a small corporation that needs to
produce a complex product in less than a year. It requires
generalist experts that can analyze the technology, known needs, and
production capabilities within a particular calendar timeframe and
then apply and balance a wide range of skills and previous
experiences and knowledge to produce a successful outcome.
Development efforts that require a lot of up-front research and
process-oriented approaches can be successful, though they can also
eat up a lot of resources and time and many companies can ill-afford
either. Very few interactive products and designs we live/suffer
with today stem from singular or whole visions and architectural
guidance. They are, instead, the result of big corporate
hierarchical organizations, highly compromised consensus necessities,
rearview mirror-driven sensibilities, timid incrementalism,
disempowered designer problems, and a whole host of other threats and
obstacles. Today's most inspired and beloved products, systems, and
services either require enormous and expensive development regimes or
are the result of very well crystallized vision and whole integration
across many interrelated aspects by small expert groups.
How can Rapid Expert Design be learned?
This is where the catch is, and why it's so important to start with
an acknowledgement of the validity of the approach and realization of
how Rapid Expert Designers are trained and exercised. The only way
to become proficient at the R.E.D. approach is through apprenticing
and gradually using the approach on projects of increasing scale and
complexity. A young designer that ambitiously bites off an entire
consumer product may indeed fail. However, it's important that they
begin learning (along with more experienced designers) how to
approach things in this manner, in smaller steps, so that they can
eventually become more proficient at R.E.D.
Much as Mortimer Adler described the three phases of education: 1)
Rote (can be taught to many simultaneously) 2) Coaching (which is
optimized at no more than 7 students per coach to allows them to put
what was learned by rote into dynamic practice) and 3) Synthesis
(where the student then begins to branch out and synthesize new
skills and solutions. The bottleneck is the Coaching phase, in that
it must be done in a close side-by-side fashion. This is why
apprenticeship and side-by-side working and transmittal of dynamic
judgment and knowledge are so important. Rapid Expert Design cannot
be learned from a book, nor is it effectively learned in a corporate
management hierarchical structure.
But most importantly, R.E.D. needs to be understood and its
documented case studies examined in order to understand it more
fully. It can be used successfully on a much wider scale than it has
been. I would suggest that most designers practicing R.E.D. spend
the overwhelming majority of their careers going from one project to
the next, picking up experience and taking on challenges, and don't
spend that much time trying to formalize their approaches. I know
that this is the case with myself and my colleagues. We don't
believe we can effectively collapse what we do dynamically into a
book. We do, however, extensively document our projects. So for
those of you out there that wish to study a number of successful
R.E.D. projects and outcomes in great and necessary depth, the
evidence of Rapid Expert Design's legitimacy and repeated success is
there and will continue to grow.
Ultimately all philosophies, methodologies, and practitioners will be
judged by the resulting work, its breadth and diversity, and its
success with all stakeholders. And just to be abundantly clear, all
successful interaction design is user-centered. Even that created
through the Rapid Expert Design philosophy and approach.
- Jim
James Leftwich, IDSA
CXO
SeeqPod, Inc.
6475 Christie Avenue, Ste. 475
Emeryville, CA 94608
http://www.seeqpod.com
http://www.seeqpod.com/mobile
Orbit Interaction
Palo Alto, California USA
jl...@orbitnet.com
http://www.orbitnet.com
http://www.linkedin.com/in/jimwich
Director, IxDA / http://www.ixda.org
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... disc...@ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... disc...@ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
