Rapid Expert Design (R.E.D.)

26 Jan 2009 - 1:44am
5 years ago
118 replies
3326 reads
Jim Leftwich
2004

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
jleft at orbitnet.com
http://www.orbitnet.com
http://www.linkedin.com/in/jimwich
Director, IxDA / http://www.ixda.org

Comments

26 Jan 2009 - 8:53am
Dave Malouf
2005

Jim,

Thanx for taking the time to clearly explain what you see to be the
gist of the matter here. I very much appreciate the framework
breakdown you did here.

I do have to say that I now have more questions than ever. Even if
R.E.D. can only be learned through direct experience (something I do
not doubt) it still must have a set of instructions and definitions
that can be used to describe it, so that those of us interested in it
can understand better its value. If like you say it is not a
"discount" design approach, but rather a design approach to be
considered in parallel if not more valuable than UCD methods (let's
assume UCD is a catch-all here people).

Basically, how would a young designer learn that they would want to
have RED be their methods? how would they go about connecting to a
master (or student of a master) to apprentice with?

How can a designer practicing RED discuss with non-design peers the
processes and methods they are using so as to not make design feel
like a "black box"?

I think you alluded to a host of case studies, right? I know you & I
have spoken personally about some and you mentioned some in your IA
Summit 2005 presentation that you did way back, but where are there
others? And others not by you?

If Adaptive Path and Cooper are poster children for the UCD design
practice today (yes, I know there are many others), who would you
point to besides yourself of designers or studios worth looking at
connecting with to find out more about R.E.D?

Are there any internal corporate design studios today working from
the perspective of R.E.D.?

Is anyone else besides yourself using this term?

Would you consider maybe sitting at a lunch table at @interaction09
next week (Is it NEXT WEEK?!?!) with those of us interested to learn
more about RED?

Last question, is your abbreviation in any way tied to the one.org
RED campaign? (ONE.org > Stop poverty and disease around the world!)

InspiRED!

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

26 Jan 2009 - 5:32pm
Robert Hoekman, Jr.
2005

>
> I use instead the term, "Rapid Expert Design" or R.E.D.

Despite all this, one important detail is unclear to me.

You've described how R.E.D. can be learned, how it can be implemented, how
it affects product development, how much better a term it is than Genius
Design, and even what it is not. What you haven't done is describe
what it actually
is.

Is it simply a name for situations when a designer when s/he lacks resources
(time, money, people) and must operate as an island? Is it only practiced by
expert designers who can devise effective solutions without the research and
such that many would say is essential at the beginning of a project? Or is
it something else?

-r-

26 Jan 2009 - 7:42pm
Yury Frolov
2006

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
jleft at 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 ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

27 Jan 2009 - 4:11pm
Jim Leftwich
2004

In response to Dave Malouf's questions (Part 1 of 3):

Q:
Basically, how would a young designer learn that they would want to
have RED be their methods? how would they go about connecting to a
master (or student of a master) to apprentice with?

A:
Just in general terms, I've found that most regions where there is a
substantial development community will have individuals and small
groups engaged in design consulting. Consultants and consultancies
have what I'd suggest is the best environment for learning to
approach a wide range of interaction design projects. Of course
consultancies vary widely in their approach and range of
clientele/projects. I would seek out those that have the greatest
range of types of projects rather than those that do a lot of the
same kind. I'd also look for smaller consultancies. It's always
going to be a very individual, case-by-case situation with seeking
out mentors and opportunities for apprenticeship. It first begins
with the need to have a desire and willingness to take this path in
one's career. I'd be very up front about it certainly not being
the easiest path. But for those designers that seek diversity of
experience and the skills and experience to take on larger-scale
development projects with small, independent teams, it's possible to
find experienced designers to network with. Often working with other
designers begins first with simple networking and discussions of
approaches and experiences.

Becoming experienced at RED is a career trajectory much more than a
short-term path. I don't know what percentage of designers I'd
guess could realistically take this path - perhaps 5% - 10% (and that
would likely be more than are consciously pursuing it today). But I
do know that this small segment could have a large and valuable
impact. Again, I would make the distinction of separating these out
as those that are purposefully pursuing RED as the primary type of
design that they do and pursue. Maybe you could also see this as
similar to the difference between regular firefighters in municipal
departments and specialized firefighter groups that put out oil field
fires. Most of the companies that do those types of work have
generally developed their own methodologies and expertise over years
of simply doing the work. It's natural that there will be a lot of
personal expertise that will be difficult to reduce to a teachable
text. Or, more often, you'll find that those that are doing it,
don't often have the time to stop doing the work and devote time to
deconstructing their practice.

I myself had moved to Dallas in the mid-1980s and began to network
and seek out older designers to co-consult with. Over time,
opportunities emerge. Then it's up to the individual to take
advantage of those opportunities.

Q:
How can a designer practicing RED discuss with non-design peers the
processes and methods they are using so as to not make design feel
like a "black box"?

A:
In my own approach, I've always used extensive and detailed
development and specification documentation (very detailed wireframes
and flows, layouts, thumbnails detailing optional solutions, etc.). I
began compiling documentation of projects early on, and as time went
on, I was able to use past projects to more easily discuss current
in-progress projects.

I think you alluded to a host of case studies, right? I know you & I
have spoken personally about some and you mentioned some in your IA
Summit 2005 presentation that you did way back, but where are there
others? And others not by you?

I have my own archive of documented projects, many of which involved
other co-consultants and small teams. One designer whom I've worked
with and shared my own approach with, Soudy Khan of Vertical Product
Development in Palo Alto, has gone on to do a number of large-scale
design projects that also yielded pretty impressive documentation.
Bear in mind that these are like complex blueprints for development
purposes, and not the kind of simplified and boiled down thing you
might put online. Understanding and studying this work is
necessarily something that has to be done sitting down and poring
through the dense materials and documentation, along with contextual
discussions.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

27 Jan 2009 - 4:11pm
Jim Leftwich
2004

In response to Dave Malouf's questions (Part 2 of 3):

Q:
If Adaptive Path and Cooper are poster children for the UCD design
practice today (yes, I know there are many others), who would you
point to besides yourself of designers or studios worth looking at
connecting with to find out more about R.E.D?

A:
I know primarily about the work done by designers I've known and/or
worked with over the past twenty-five years. The designers I learned
the most from in the 1980s were Norm Cox and Alan Mandler. I've
known a number of engineers that were actually very good designers in
the domains in which they worked as well. Steve Doss of Jampaq,
who's designed and programmed some pretty nice mobile games that
have been popular. He and I worked together at Pacific Consultants
several years back, which was a 130-person consulting group (later
acquired and absorbed) on a number of complex projects ranging from
the U.S. Army's Land Warrior system to handheld medical devices. He
and I recently created the SeeqPod Mobile application for Windows
Mobile with this approach. Another veteran designer that comes to
mind is Peter Muller of Interform. Peter was one of Frogdesign's
earliest people where he was a V.P. Peter's very much an
accomplished generalist designer who's taken on all the aspects of
whole product development from I.D. to interaction and branding, and
would be an example of the kind of approach I've described. I would
expect that a lot of independent designers and small consulting groups
would resonate with the idea of building up experience towards
tackling diverse and complex design projects. First perhaps out of
necessity, but eventually because of the capabilities they've gained
over time.

Part of my reason for putting the idea of RED out there is to create
a seed around which a diversity of experiences and approaches can be
discussed. Not as flawed, unfortunate, or fallback approaches, but
as the way they practice design. This is not uncommon among
designers and architects, however it is often not widely discussed
and examined, due to the individuality of practices and effort
required to put these experiences in an examinable and discussable
form.

I further think that there may indeed be two valid ways of defining
and understanding the generalized rapid, non-structured / less
up-front research approach - One may indeed be more like what Dan is
describing - a reluctant fallback reality that the designer would
really rather have the opportunity to apply more involved research
and development processes to, but can't (for lack of time,
resources, etc.), and a second one (which is more what I'm
describing) which is purposefully pursuing the projects that can only
be effectively addressed (time and resource-wise) using the RED
approach. In the latter, the approach is not a fallback option, but
a specific approach where the designer is seeking to gain over time
the ability to provide the best, most thorough, and most successful
design in the shortest period of time and with the least cost to the
client/corporation possible. This approach, like the unique skills
and training of Special Forces soldiers, then is fundamentally
different from that of regular infantry. RED, in this way, is the
way of life, and capable of very successful outcomes (though often at
high personal effort costs on the part of the RED designers in terms
of hours/week and difficulty of the project). This is why RED is not
for everyone. Just as Alpine Climbing style (in the way Reinhold
Messner and Peter Haebler practiced it by climbing the world's
highest peaks without oxygen or fixed ropes) is not for every climber
that would rather have an army of Sherpas along with them, a series of
semi-permanent encampments, and aluminum ladders and fixed ropes
aiding them in reaching the summit. The point is that the Alpine
Climbing style is a valid approach on its own if practiced and
pursued competently, not a fallback style inferior to other methods.

Q:
Are there any internal corporate design studios today working from
the perspective of R.E.D.?

A:
We are all familiar with the anecdotes about Apple, though there's
few specifics out there (that I'm aware of) regarding their approach
and experience. I'm not personally that familiar with many internal
corporate design studios, other than those that have existed in
companies that I and my colleagues have consulted to. Most of those
didn't have the experience or structure to practice RED, though most
struck me as having the capability of doing so, if they were
differently structured and empowered. It's important to bear in
mind how powerfully the dogmatic messages of the design field over
the past twenty years have shaped the attitudes of designers
(particularly corporate and organizationally-oriented designers)
towards what's accepted as possible and what's not.

To paraphrase an old saying, "Free your mind and your design skills
will follow."

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

27 Jan 2009 - 4:12pm
Jim Leftwich
2004

In response to Dave Malouf's questions (Part 3 of 3):

Q:
Is anyone else besides yourself using this term?

A:
I created the term "Rapid Expert Design" (RED) in order to better
frame a particular kind of design philosophy and approach. I find it
more generic and free of potentially misleading connotations than
other terms I've used in the past, such as "Special Forces
Design."

Though I've intended for many years to eventually try to recap what
I've learned, it's been in response to what I've seen as
problematically framed terms and descriptions such as "genius
design" that have prompted me to begin this dialog. I would hope
that others add their experiences and perspectives.

Q:
Would you consider maybe sitting at a lunch table at @interaction09
next week (Is it NEXT WEEK?!?!) with those of us interested to learn
more about RED?

A:
Absolutely! One of the reasons I wanted to bring this up now is to
create a seed of discussion for next week's Interaction09 in
Vancouver. I'm very much looking forward to many enlivened and
excellent discussions with others throughout the conference. We had
spectacular discussions last year and I expect this year to be even
better.

In fact, I'd suggest to those independent designers and consultants
out there that would like to discuss these issues with many others in
the field, that coming to Interaction09 is definitely something
you'll want to do. I remember how I felt about conferences back
when I was a sole consultant, and often felt I couldn't justify the
expense and time. But Interaction09, like last year's conference,
is different. We're an association built on discussions and
dialogs, and these are among the most important activities at our
events.

Q:
Last question, is your abbreviation in any way tied to the one.org
RED campaign? (ONE.org Stop poverty and disease around the world!)

InspiRED!

A:
No, it just happened to be the acronym that popped up. I do like the
connotations of RED though - hot, urgent response, etc..

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

27 Jan 2009 - 5:36pm
Robert Reimann
2003

RED obviously exists and obviously works; look at any top designer and how
they work. But the key is in the word "expert". An expert is someone whose
knowledge base in a domain is so broad and deep, and who has had so much
practical experience in the domain that they have internalized sets of rules
so that they become second nature-- so that their solutions seem to come
from pure intuition. "Seem" being the operative word. I prefer "RED" to
"genius design" for just this reason: "Genius" implies innate talent that is
hard to define and to which impossible to chart a clear path. Expertise
comes with deep immersion and long experience in a domain (or several
domains), and many successful-- and even unsuccessful-- iterations.

Back in the 80's when Expert Systems were the hot property in AI research,
it was believed that by codifying the internal rules that experts had
accumulated, automated systems could be "taught" to provide a moderate to
high level of expertise. But one of the serious problems expert systems
architects encountered was that these internal rules had become so
internalized, that experts could no longer easily articulate them to
interviewers; they had become second nature, and processed at a pre-verbal
level in the experts' minds.

Therefore, I don't believe that RED is a method or a practice or philosophy
the typical sense. Rather, it is the natural result of becoming a master of
our profession. In the case of interaction design, a would posit that RED
requires not only an expertise in the techniques and methods of IxD and
associated disciplines, but probably also a level of experience in a cloud
of product/service domains AND a natural facility at quickly mapping new
domains to previous/analogous problem spaces. But to call it a method is I
believe false; to me it is the internalization of other methods and many
successes and failures at applying those methods over the course of time.

I do agree that it is in consulting that designers are more likely to obtain
the skills and experiences they need to be able to perform RED, since it is
only in consulting that so wide a variety of domains can be encountered in a
relatively short span of time, and where speed to high quality solution is
placed at such a high premium.

Robert.

Robert Reimann
IxDA Seattle

Associate Creative Director
frog design
Seattle, WA

On Tue, Jan 27, 2009 at 1:12 PM, Jim Leftwich <jleft at orbitnet.com> wrote:

> In response to Dave Malouf's questions (Part 3 of 3):
>
> Q:
> Is anyone else besides yourself using this term?
>
> A:
> I created the term "Rapid Expert Design" (RED) in order to better
> frame a particular kind of design philosophy and approach. I find it
> more generic and free of potentially misleading connotations than
> other terms I've used in the past, such as "Special Forces
> Design."
>
> Though I've intended for many years to eventually try to recap what
> I've learned, it's been in response to what I've seen as
> problematically framed terms and descriptions such as "genius
> design" that have prompted me to begin this dialog. I would hope
> that others add their experiences and perspectives.
>
> Q:
> Would you consider maybe sitting at a lunch table at @interaction09
> next week (Is it NEXT WEEK?!?!) with those of us interested to learn
> more about RED?
>
> A:
> Absolutely! One of the reasons I wanted to bring this up now is to
> create a seed of discussion for next week's Interaction09 in
> Vancouver. I'm very much looking forward to many enlivened and
> excellent discussions with others throughout the conference. We had
> spectacular discussions last year and I expect this year to be even
> better.
>
> In fact, I'd suggest to those independent designers and consultants
> out there that would like to discuss these issues with many others in
> the field, that coming to Interaction09 is definitely something
> you'll want to do. I remember how I felt about conferences back
> when I was a sole consultant, and often felt I couldn't justify the
> expense and time. But Interaction09, like last year's conference,
> is different. We're an association built on discussions and
> dialogs, and these are among the most important activities at our
> events.
>
> Q:
> Last question, is your abbreviation in any way tied to the one.org
> RED campaign? (ONE.org Stop poverty and disease around the world!)
>
> InspiRED!
>
> A:
> No, it just happened to be the acronym that popped up. I do like the
> connotations of RED though - hot, urgent response, etc..
>
>

27 Jan 2009 - 7:40pm
Jim Leftwich
2004

I concur wholeheartedly with many of your observations here, Robert.
That's why I most offten use the words "philosophy" and
"approach" much more than "method" (which implies a particular
methodology).

I also agree that many designers that work in this manner, and
successfully take on projects and challenges that require a great
deal of experience, judgement, and complex interrelated
decision-making (often across a wide range of products, systems, and
services) have indeed internalized much of their skills over time.

And that's why I suggested in my initial post that this approach to
design is crucially dependent upon apprenticeship and junior
teammember type working relationships. It's through these type of
side-by-side design-in-real-situations that these complex and dynamic
skillsets and judgement abilities are demonstrated, practiced,
discussed, iterated, and honed over time.

This is how most "expertise" in many fields is gained. A good
starting foundation is, of course, incredibly valuable. And any and
all means of obtaining insights, information, and knowledge about all
the stakeholding aspects of any project are always helpful.

However, there are also many patterns and known solution fields from
which new solutions to complex problems can be drawn and applied, and
this is where RED delivers success.

I should also underscore that while "expert" can refer to expertise
in particular domains (say for example 'mobile phone operating system
experience frameworks' or 'handheld medical equipment' or
'web-based commerce transaction systems', etc.), RED is first and
foremost about expertise in rapidly designing successful solutions to
a range of projects, problems, and challenges.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

27 Jan 2009 - 8:00pm
Robert Reimann
2003

Jim,

I think we totally agree on the apprenticeship model as a key approach to
training young designers. And I think we also agree on the use of design
patterns as a means of teaching/learning/building/sharing design knowledge.
In fact, design patterns can (and should) be seen as an effort to encode and
formalize the sort of situational design knowledge that is internalized by
design experts. Finally, I do take your point that the expertise you are
referring to is the ability to rapidly design successful solutions. I would
only add that this expertise is (inter)dependent on, if not expertise, then
at least a level of exposure to, a critical mass of related design and
problem domains.

Robert.

Robert Reimann
IxDA Seattle

Associate Creative Director
frog design
Seattle, WA

On Tue, Jan 27, 2009 at 4:40 PM, Jim Leftwich <jleft at orbitnet.com> wrote:

> I concur wholeheartedly with many of your observations here, Robert.
> That's why I most offten use the words "philosophy" and
> "approach" much more than "method" (which implies a particular
> methodology).
>
> I also agree that many designers that work in this manner, and
> successfully take on projects and challenges that require a great
> deal of experience, judgement, and complex interrelated
> decision-making (often across a wide range of products, systems, and
> services) have indeed internalized much of their skills over time.
>
> And that's why I suggested in my initial post that this approach to
> design is crucially dependent upon apprenticeship and junior
> teammember type working relationships. It's through these type of
> side-by-side design-in-real-situations that these complex and dynamic
> skillsets and judgement abilities are demonstrated, practiced,
> discussed, iterated, and honed over time.
>
> This is how most "expertise" in many fields is gained. A good
> starting foundation is, of course, incredibly valuable. And any and
> all means of obtaining insights, information, and knowledge about all
> the stakeholding aspects of any project are always helpful.
>
> However, there are also many patterns and known solution fields from
> which new solutions to complex problems can be drawn and applied, and
> this is where RED delivers success.
>
> I should also underscore that while "expert" can refer to expertise
> in particular domains (say for example 'mobile phone operating system
> experience frameworks' or 'handheld medical equipment' or
> 'web-based commerce transaction systems', etc.), RED is first and
> foremost about expertise in rapidly designing successful solutions to
> a range of projects, problems, and challenges.
>
>

27 Jan 2009 - 8:26pm
Robert Hoekman, Jr.
2005

So, if I was a person who practiced RED, would I get to say so without
sounding egotistical? It's not Genius Design, so I wouldn't be implying I'm
a genius, but I would still be saying I can design effective solutions
without following "the rules", which isn't all that dissimilar.
What if I could prove my designs were effective? Would that make it less
egotistical?

Incidentally, this whole idea was the subject of Blink (Gladwell).
Basically, if you spend enough time informing your gut, then your instincts
can be just as effective, if not more effective, than a boatload of
time-consuming research. I like the idea of putting a name to this (easier
to reference that way), but I'm also somehow sure it will just confuse
matters even more.

-r-

27 Jan 2009 - 9:23pm
Mark Schraad
2006

That is the whole key with research and decisions. The research, nor
the participants/users are making the decisions. You do the
diligence... all the research you can afford, can manage, or have
time for... but in the end, you, the designer must make the
decisions... and you must trust your gut. There is no way around that.

Mark

On Jan 27, 2009, at 8:26 PM, Robert Hoekman Jr wrote:

> Incidentally, this whole idea was the subject of Blink (Gladwell).
> Basically, if you spend enough time informing your gut, then your
> instincts
> can be just as effective, if not more effective, than a boatload of
> time-consuming research.

27 Jan 2009 - 9:42pm
Jim Leftwich
2004

Robert, my years of experience have pointed only to one thing as being
effective at both proving the effectivness of any designer (coming in
at the beginning), and that's proof of past exerience and outcomes.
This includes documentation of work and results in as much detail as
can be reviewed.

In this way it's completely removed from "claims" and simply
becomes a matter of "This is what I/we have done in similar,
related, and/or many different projects, conditions, and
timeframes." This will always speak volumes beyond any claims or
words that can be used. I don't think it's ever about the designer
- it's about the portfolio - the documentation and sample iterative
work showing what has been done before.

If some designers feel more comfortable making their case (to
whomever - engineers in their own company, clients, management, etc.)
by standing behind their research, then I would say RED practitioners
live and die by their work making the case.

This is why it requires a designer to build up this kind of
experience over time.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

27 Jan 2009 - 9:54pm
Jim Leftwich
2004

And Robert (Reimann), we are in complete agreement. It's all about
accumulated experience.

I would only add that part of that experience ihas to be in
exercising one's ability to make quick judgements and conceive
interrelated solutions. A designer has to learn to move (somewhat)
into the unknown in order to have confidence down the road to know
that some complex judgements made at the beginning of a complex RED
project have an extremely good chance of panning out very well at the
end.

Such long-range decision approaches may appear "black box,"
"ego-driven," or subjectively arbitrary to an uniformed outside
observer, but can actually be the kind of highly-informed expertise
that many types of people successfully use in many lines of work.

A RED designer or team must earn, over time, the respect of each
other, clients, engineers, and others in order to be able to
effectively carry out these types of projects. Part of this can be
accomplished through documenting projects and a larger part of it
(with teammembers, colleagues, and clients) must be earned by working
successfully together.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

27 Jan 2009 - 10:42pm
Dave Malouf
2005

This is particularly such a hard topic to discuss. There are many
nuances being outlined here that might be missing to the average
designer.

People should know that Jim is talking in terms of decades of
experience in his personal practice.

I also want to re-iterate when he says that only some 5% of designers
can really effectively practice like this.

These 2 elements provide for me a big question of "scale" for the
design community and path. What I mean is that there is more work for
designers than can be effectively supported by this design system (my
overall concern w/ Apprentice/Mentor models in general--personally I
think this is a personal and necessary parth to take, but only after
formal education; more below.)

1) It would seem a path steeped in deliberate education of foundation
of craft, theory and methods is still required before one can
apprentice at this level, to be able to deconstruct the unarticulated
practices of their "masters".

2) Jim alludes to the lifestyle that such a practice requires, which
I find really interesting in an age of people already struggling to
bring work/life balance to their universe. Is there an ethical
concern for suggesting such a practice.

To me RED is not a decision, or a career path or even a philosophy or
method, but a career milestone. The reason I feel compelled in this
direction is that the answers that Jim gave to my questions tells me
that there is no structure to the education of the practice and thus
it cannot be codified or otherwise repeated/handed down with
consistency. Even martial arts of the most ancient variety have
evolving patterns of education systems that from the POV of adjacent
generations has a pedogogy and practice that is consistent and
articulatable.

While it is interest to know about this practice, I'm not so sure I
see value in knowing about it? or even understanding it. Further b/c
it seems to exist outside the "norms" of practice (just
statistically speaking) it doesn't seem to communicate using
language that can engage the rest of the design community.

I'm not her to condemn the practice, but just question it as
something really parallel to user-centered design.

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

27 Jan 2009 - 10:56pm
Jared M. Spool
2003

On Jan 27, 2009, at 5:26 PM, Robert Hoekman Jr wrote:

> So, if I was a person who practiced RED, would I get to say so without
> sounding egotistical? It's not Genius Design, so I wouldn't be
> implying I'm
> a genius, but I would still be saying I can design effective solutions
> without following "the rules", which isn't all that dissimilar.
> What if I could prove my designs were effective? Would that make it
> less
> egotistical?

:)

The problem with R.E.D. (or Genius Design, which I still prefer to
call it because I *like* the baggage the name comes with) is that you
can't tell if you've achieved it until you're done with the design.
Then you discover your experience paid off. Or you discovered that you
were completely arrogant and screwed over your team and client by
producing crap.

I like the name Genius Design because it means I'll never resort to
it. But I have met people in my travels who were capable of seeing and
solving problems without any research that took me years of research
to uncover. Those people are true geniuses in my mind.

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

27 Jan 2009 - 10:57pm
Robert Hoekman, Jr.
2005

>
> While it is interest to know about this practice, I'm not so sure I
> see value in knowing about it? or even understanding it. Further b/c
> it seems to exist outside the "norms" of practice (just
> statistically speaking) it doesn't seem to communicate using
> language that can engage the rest of the design community.

Are we sure that RED isn't just a fancy term for "talent"? ;)

Regardless, on any given day, or any given project, a vastly experienced
designer can be wrong a hundred times and an inexperienced designer can be
right a hundred times. Experience matters far less than judgment.

-r-

27 Jan 2009 - 11:05pm
Dave Malouf
2005

hmm? I think I'm still a believer in rigorous methods for making up for the
unpredictability of "talent" and "judgment".

-- dave

ps. I'm not saying that you, Robert, are being anti-methods, the thought was
just merely inspired by your comment below.

On Tue, Jan 27, 2009 at 10:57 PM, Robert Hoekman Jr <robert at rhjr.net> wrote:

> While it is interest to know about this practice, I'm not so sure I
>> see value in knowing about it? or even understanding it. Further b/c
>> it seems to exist outside the "norms" of practice (just
>> statistically speaking) it doesn't seem to communicate using
>> language that can engage the rest of the design community.
>
>
> Are we sure that RED isn't just a fancy term for "talent"? ;)
>
> Regardless, on any given day, or any given project, a vastly experienced
> designer can be wrong a hundred times and an inexperienced designer can be
> right a hundred times. Experience matters far less than judgment.
>
> -r-
>

--
Dave Malouf
http://davemalouf.com/
http://twitter.com/daveixd
http://scad.edu/industrialdesign
http://ixda.org/

28 Jan 2009 - 1:46am
Jared M. Spool
2003

On Jan 27, 2009, at 7:57 PM, Robert Hoekman Jr wrote:

> Are we sure that RED isn't just a fancy term for "talent"? ;)

In our work, talent is something that is naturally born. Anyone can
learn to hit a baseball, but a real talented player can hit it in a
way that non-talented players will never master.

The other attributes are skills, experience, and knowledge. Skills and
knowledge are learned. Experience is acquired.

The sum of these attributes are what make up our abilities.

I'm guessing that RED is about people at the high end of these scales,
but talent isn't the key factor.

> Regardless, on any given day, or any given project, a vastly
> experienced
> designer can be wrong a hundred times and an inexperienced designer
> can be
> right a hundred times. Experience matters far less than judgment.

"Good judgment comes from experience. Experience comes from bad
judgments."

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

28 Jan 2009 - 2:14am
Steve Baty
2009

RED seems to be characterising what would have, in mediaeval and
pre-industrial times, been called the Master Craftsman. Someone who, through
dint of many years of learning, experience, and practical application, has
become capable of producing work that is both highly suitable to the problem
space, but also have a high standard of quality and finish.

There were many more craftsmen than there were masters. The masters were
acknowledged by their peers, through acclimation rather than certification.
Perhaps informally, or perhaps formally through the agency of a craft guild.

Am I missing some nuance of the definition of RED?

Steve
--
Steve 'Doc' Baty | Principal | Meld Consulting | P: +61 417 061 292 | E:
stevebaty at meld.com.au | Twitter: docbaty | LinkedIn:
www.linkedin.com/in/stevebaty

Blog: http://docholdsfourth.blogspot.com
Contributor - UXMatters - www.uxmatters.com
UX Book Club: http://uxbookclub.org/ - Read, discuss, connect.

28 Jan 2009 - 2:22am
Jim Leftwich
2004

I'm in extremely strong disagreement with Jarod in a number of things
he states. I disagree with his statement that one does not know where
a RED design will end until after it's finished.

This is flatly untrue. It's a matter of experience. One has to
have confidence of where a design (which can indeed be both grasped
in the mind and in extensive blueprints) will be when implemented and
realized. This is simply a fact that's been borne out in many
designs by many designers.

He says he will never have to resort to RED. I'm at a bit of a loss
to respond to Jarod, as I'm not actually familiar with his body of
work. I would have to see Jarod's designs and understand the
outcomes, the scale and expense of effort that went into them, and
the domains that these took place in before commenting on his
approach to design and development.

I speak only from my own experience, and that of the many designers
I've worked with and our outcomes.

In response to Dave's comments, which seem to indicate he's decided
there's nothing here worth considering further, I believe he's
missing a great deal.

RED is very much teachable, just as martial arts are - in small
groups, and in actually doing it. One doesn't learn martial arts
from books. One learns by practicing dynamically with an experienced
practitioner or master.

It also likely took a long time for structured "schools" to emerge.
Our field is young. I would caution people like Dave to think twice
before being so outright dismissive. There is much evidence of
success to be found among the many projects out there that are
undertaken in rapid expert approaches.

I've seen young designers learn to develop these skills and broader
capabilities than they might otherwise have developed in narrower and
more structureed environments. I'm not surprised that many with much
invested in the field's dogma to issue negative judgements here, but
what it will really come down to is results.

I had only taken a guess at what percentage of designers might adopt
these types of approaches, when I suggested 5%. It could be more.
The important point is that there are designers out there capable of
working at much higher levels than they might be able to do in some
of the more rigid work structures and design methodologies, and those
designers should be aware that other alternatives exist and have
produced successful outcomes.

But I will say something about anytime you see something like 5% -
and that's that it would be very unwise to assume that all
percentages are equal. Only 5% of physicians are certain types of
specialists, but the field definitely benefits from their work and
expertise. We would never accept an attitude that discounts minority
vocations in favor of only those that somehow stretch across a much
wider (or lower common denominator) demographic in a field.

This simply doesn't make sense.

I'm willing to hold out RED, if only to provide a point around which
others that practice in this style can trade stories, experiences,
outcomes, strategies, and knowledge. To suggest that this is not
worthwhile, is, well, not some people's cup of tea or something.

To those that would outright suggest that, in light of this topic,
state clearly that they consciously prefer the term "genius design"
precisely because of "the baggage that it comes with," and
specifically after my discussion of the troubling framing that this
term presents, I can only assume that this is a thinly-veiled gesture
of open hostility.

I'm perfectly willing to debate. However, I'd insist it be done in
context of actual design work completed and not simply rhetorical
posturing.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

28 Jan 2009 - 3:01am
Jim Leftwich
2004

In response to the many great observations that Yury Frolov made, I
immediately recognize many of those same dynamics and challenges.

There are indeed circumstances and situations that are better suited
for RED approaches, and you outlined them nicely. I and my network
and colleagues have designed some projects from scratch though, and
I'd suggest that tthose projects just represent another type of
problem or domain, complete with unique needs, constraints, and
opportunities. It's sometimes quite nice to be able to design whole
new things from scratch in that it provides opportunities to achieve a
great deal of elegant functional and experience integration as well as
related aspects such as branding.

And I think Yury succeeded in identifying one of the most challenging
aspects, which is the longer term extension or buildout of a seed or
core design. He identified some of the tools that are used (Style
Guides, Templates, Pattern documentation, etc.), but it's true that
often a RED team moves on to a new project, and it's left to others
to take a design forward.

I'd first say that I've seen a great variation in the detail,
utility, and ultimately effectiveness of Style Guides and
Architecture documentation. These are not always created equal. And
good patterns, guides, and templates both make it easier for later
designers to both extend a design with more freedom in certain
dimensions while more effectively retaining the core pattern
consistencies and relationships key to the core interaction patterns.

But I'd also point out that if a new core design moves the overall
functionality and patterns of usage to a new and improved level (in
the case of a revolution), then the subsequent evolution dynamics
aside, the product, system, or service can still be much better off.
As with all things, we would have to speak about specific cases and
the individual issues involved in order to go deeper.

But I'd argue that even other methods, when they deal in broad
generalities, are also similarly unable to prove their effectiveness.
It *always* comes down to the specifics of individual projects in the
end.

I do like the term "Design Cleanup Team" though. I've had
experiences in the past where after an initial project, there would
be follow on projects one or two years later. These were often an
opportunity to judge effectiveness of the initial work's extension
as well as an opportunity to provide further direction and guidance
of the overall design.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

28 Jan 2009 - 3:16am
Jonas Löwgren
2003

I have been following the RED thread with great interest and
pleasure, deciding not to step in this time -- but now I have to.

> Regardless, on any given day, or any given project, a vastly
> experienced
> designer can be wrong a hundred times and an inexperienced designer
> can be
> right a hundred times. Experience matters far less than judgment.

This comment is totally obscure to me.

In my view, judgment in a design situation is strongly informed by
experience.
- Experience from previous design work within the genre in question,
by the designer him/herself as well as by others.
- To some extent, experience also in adjacent genres (even though
cross-genre transfer is not always straightforward).
- Experience from observing related use situations, with their
particular mixes of domain expertise, stakeholder tradeoffs and
external forces.
- Experience with tools, techniques and materials to be used.
And so on.

Of course it *can* happen that a vastly experienced designer is wrong
a hundred times and an inexperienced designer is right a hundred
times on any given day. But it is highly unlikely. Chances are that
the vastly experienced designer is right far more often than the
inexperienced designer. And this, I believe, is one of the key
underpinnings of the whole RED notion.

Also note that the difference in judgment ability cannot be bridged
by systematic design methods. Methods may be useful tools for
coordination and learning, but the outcome of a method is never
better than the person using the method.

Jonas Löwgren

28 Jan 2009 - 7:07am
Todd Warfel
2003

On Jan 27, 2009, at 11:05 PM, Dave Malouf wrote:

> hmm? I think I'm still a believer in rigorous methods for making up
> for the
> unpredictability of "talent" and "judgment".

Actually, Robert's point about experienced and inexperienced designers
goes hand in hand with yours. Using great methods gives a Designer the
capability to produce great work, regardless of the amount of past
experience. It helps to teach the inexperienced how to do design and
gives them a more level playing field.

I took Robert's point to mean that experience isn't the only goose
that lays the golden egg.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

28 Jan 2009 - 7:10am
Todd Warfel
2003

So, is the emphasis here on the Rapid or on the Expert part?

Is it a RAPID Expert Designer or a Rapid EXPERT Designer? Is it rapid
design done by an expert, or quickly producing what could be defined
as an amazing expert design?

I guess I'm asking if Expert is being used as noun or adjective.

And frankly, I don't see what all the fuss is about.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

28 Jan 2009 - 7:51am
Mark Schraad
2006

That is exactly how I read it. RED = RGD = really good designer

On Jan 27, 2009, at 10:57 PM, Robert Hoekman Jr wrote:

> Are we sure that RED isn't just a fancy term for "talent"? ;)

28 Jan 2009 - 7:51am
Mark Schraad
2006

I completely agree. The conversations that spawned this were all
about methods, perspectives, tools, and how a designer approaches a
problem. RED does not seem to fit in any of those buckets. It is most
certainly an admirable level to aspire to, but I am not sure it does
much for aspiring designers or students.

On Jan 27, 2009, at 11:05 PM, Dave Malouf wrote:

> hmm? I think I'm still a believer in rigorous methods for making up
> for the
> unpredictability of "talent" and "judgment".

28 Jan 2009 - 7:56am
Mark Schraad
2006

Great quote... where/who is that from?

On Jan 28, 2009, at 1:46 AM, Jared Spool wrote:

> "Good judgment comes from experience. Experience comes from bad
> judgments."

28 Jan 2009 - 9:40am
Dave Malouf
2005

Jim, I'm not so much dismissing as begging for more. I haven't seen
enough in your explanation or others to take RED as anything other
than hubris, so here is what I'm missing: A framework. A
deconstruction of methods and practice. a codification that can be
compared and contrasted to other methods and practices. a set of
tools, deliverables, artifacts, semantics, and syntaxes that can be
used to guide.

If you want to be so bold as to use analogies of medicine, special
forces and martial arts (ok that one is mine, but you took the bait
so to speak), you need to couch it in the same terms. Yes, only 5% of
doctors are cardio parenatal surgeons, but that is not what you are
saying. You are saying only 5% (10%, whatever) are capable of doing a
method. Further, I can read 1 book and know exactly the steps and
stages necessary for becoming such a doctor. The same is true for
special forces and martial arts masters. They have codes, tools,
methods and a language filled with semantics and syntax for anyone to
follow with proper mentorship and effort.

So I'm not dismissing. I'm begging. I'm hungry for an alternative
to UCD methods to be quite honest. I see in Industrial design around
me a host of methods and practices that are not RED and not UCD and
not genius design. They are taught, explained and codified within the
liturgy (if you will) of the portfolio and critique. It is really just
called "design". If that is what is RED is, then of course, I won't
dismiss it, but you are some how putting RED next to UCD as something
special or contrasted from standard design practice.

Sorry to keep pushing, but if you are going to put yourself out
there, ya gotta take the swipes. I know I do ALL THE TIME!

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

28 Jan 2009 - 11:06am
Christian Crumlish
2006

doesn't research tend to show that, regardless of inborn aptitude, that
"talent" tends to correspond with incredible commitment to practice and
experience? (Malcolm Gladwell's 10,000 hours concept, etc.).
-xian-

On Tue, Jan 27, 2009 at 10:46 PM, Jared Spool <jspool at uie.com> wrote:

>
> On Jan 27, 2009, at 7:57 PM, Robert Hoekman Jr wrote:
>
> Are we sure that RED isn't just a fancy term for "talent"? ;)
>>
>
> In our work, talent is something that is naturally born. Anyone can learn
> to hit a baseball, but a real talented player can hit it in a way that
> non-talented players will never master.

--
Christian Crumlish
I'm writing a book so please forgive any lag
http://designingsocialinterfaces.com

28 Jan 2009 - 11:16am
Christian Crumlish
2006

I'm thinking about promoting a new methodology called R.A.D. (stands for
Really Awesome Design).
(i kid, <jleft>, i kid!)

-x-

On Wed, Jan 28, 2009 at 4:51 AM, mark schraad <mschraad at gmail.com> wrote:

> That is exactly how I read it. RED = RGD = really good designer

--
Christian Crumlish
I'm writing a book so please forgive any lag
http://designingsocialinterfaces.com

28 Jan 2009 - 11:24am
Robert Hoekman, Jr.
2005

>
> "Good judgment comes from experience. Experience comes from bad judgments."
>

But some people can attain great judgment through just a little experience,
while others can have a ton of experience and never attain great judgment.

Ooh! Gotta run—someone needs my help transferring $2.5 million from a
third-world country into my bank account.

-r-

28 Jan 2009 - 11:29am
Mark Schraad
2006

For the record, I was being serious and not flippant. I meant no
disrespect to Jim or to his presentation of RED. I know how these
posts can sometimes be seen as charged and misinterpreted.

When I read Jim's description (which I have done several times), I
think of nearly every great designer that I have had the pleasure of
working with. Nothing in that description seems unnatural or new to
me. Though I do not exactly understand how it fits into the
methodology framing that preceded its explanation, Robert's (Reimann)
comments make sense to me.

Mark

On Jan 28, 2009, at 11:16 AM, Christian Crumlish wrote:

> I'm thinking about promoting a new methodology called R.A.D.
> (stands for Really Awesome Design).
>
> (i kid, <jleft>, i kid!)
>
> -x-
>
>
> On Wed, Jan 28, 2009 at 4:51 AM, mark schraad <mschraad at gmail.com>
> wrote:
> That is exactly how I read it. RED = RGD = really good designer
> --
> Christian Crumlish
> I'm writing a book so please forgive any lag
> http://designingsocialinterfaces.com

28 Jan 2009 - 11:30am
Robert Hoekman, Jr.
2005

>
> I'm in extremely strong disagreement with Jarod in a number of things
> he states. I disagree with his statement that one does not know where
> a RED design will end until after it's finished.
>
> This is flatly untrue. It's a matter of experience. One has to
> have confidence of where a design (which can indeed be both grasped
> in the mind and in extensive blueprints) will be when implemented and
> realized. This is simply a fact that's been borne out in many
> designs by many designers.

Confidence or not, experience or not, you can't actually know how something
will turn out until it's done.

He says he will never have to resort to RED. I'm at a bit of a loss
> to respond to Jarod, as I'm not actually familiar with his body of
> work. I would have to see Jarod's designs and understand the
> outcomes, the scale and expense of effort that went into them, and
> the domains that these took place in before commenting on his
> approach to design and development.

Jared isn't a designer—he's a researcher, and a widely respected one at
that. And one of the many things he's researched is how successful design
teams work. It would be far wiser for you to read his articles than dispute
his qualifications.

-r-

28 Jan 2009 - 11:37am
Robert Hoekman, Jr.
2005

>
> Regardless, on any given day, or any given project, a vastly experienced
>> designer can be wrong a hundred times and an inexperienced designer can be
>> right a hundred times. Experience matters far less than judgment.
>>
>
> This comment is totally obscure to me.
>
> In my view, judgment in a design situation is strongly informed by
> experience.

Someone with lots of experience might be in a better position to have good
judgment, but that doesn't s/he will exercise it.

Time magazine did a cover story once about the importance of the
"experience" argument in the presidential campaign. They cited studies where
very experienced nurses fared no better than less experienced nurses in
making life or death decisions, and often fared worse. They found that
experienced practitioners relied more on habit while less experienced
practitioners were more prone to examine all the information available
(albeit quickly).

As a result, either group was just as likely to kill a patient.

-r-

28 Jan 2009 - 12:58pm
Jared M. Spool
2003

Nobody who wins the 100m at the Olympics does it on their first race.
They've spent years practicing and preparing.

Similarly, most people who practice running every day will never
qualify for the Olympics.

To be top of your game, you've got to have a combination of talent,
experience, skills, and knowledge. I think that's at the crux of
Gladwell's 10k hours concept.

Jared

On Jan 28, 2009, at 8:06 AM, Christian Crumlish wrote:

> doesn't research tend to show that, regardless of inborn aptitude,
> that "talent" tends to correspond with incredible commitment to
> practice and experience? (Malcolm Gladwell's 10,000 hours concept,
> etc.).
>
> -xian-
>
> On Tue, Jan 27, 2009 at 10:46 PM, Jared Spool <jspool at uie.com> wrote:
>
> On Jan 27, 2009, at 7:57 PM, Robert Hoekman Jr wrote:
>
> Are we sure that RED isn't just a fancy term for "talent"? ;)
>
> In our work, talent is something that is naturally born. Anyone can
> learn to hit a baseball, but a real talented player can hit it in a
> way that non-talented players will never master.
>
> --
> Christian Crumlish
> I'm writing a book so please forgive any lag
> http://designingsocialinterfaces.com

28 Jan 2009 - 1:46pm
Jared M. Spool
2003

On Jan 27, 2009, at 11:22 PM, Jim Leftwich wrote:

> I'm in extremely strong disagreement with Jarod in a number of things
> he states.

I'm assuming you're talking about me (JarEd). There's another JarOd on
this list, who often has interesting things to say, but he hasn't
participated in this thread. I apologize if my assumption is incorrect.

> I disagree with his statement that one does not know where
> a RED design will end until after it's finished.
>
> This is flatly untrue. It's a matter of experience. One has to
> have confidence of where a design (which can indeed be both grasped
> in the mind and in extensive blueprints) will be when implemented and
> realized. This is simply a fact that's been borne out in many
> designs by many designers.

You can think of this as a two-by-two matrix. On the horizontal, you
have "Is not experienced" and "Is experienced". On there vertical you
have "Thinks is experienced" and "Doesn't think is experienced".

I believe you're focusing on the quadrant that is both "Is
experienced" and "thinks is experienced." People in this quadrant will
likely do an excellent job. Similarly, the people in "Is not
experienced" and "Doesn't think is experienced" will likely resort to
other means, such as activity-focused or user-focused research, to get
the information they need to make decisions.

It's the other two quadrants that produce issues. Those that fall into
"Is experienced" and "Doesn't think is experienced" will underperform
and spend resources on research that don't deliver new insights. Those
that fall into "Thinks is experienced" and "Is not experienced" will
blindly produce designs that are unlikely to succeed.

It is this latter quadrant that I think has the most risk. In this
case, you won't know which column you're in ("Is experienced" vs. "Is
not experienced") until you've had a way to validate the design. You
may "think" you know, but that's a completely different axis.

That was my original point. It is just rhetoric, but it's important
rhetoric as we try to broaden the field to that beyond just a few
folks who "get it" and make it into something that is scalable to the
demands that society seems to warrant it. That's where my interest in
this comes from.

> He says he will never have to resort to RED. I'm at a bit of a loss
> to respond to Jarod, as I'm not actually familiar with his body of
> work. I would have to see Jarod's designs and understand the
> outcomes, the scale and expense of effort that went into them, and
> the domains that these took place in before commenting on his
> approach to design and development.

What I actually said was:

> I like the name Genius Design because it means I'll never resort to
> it.

As Robert pointed out, I'm not a designer (though I do dabble in it
occasionally, often with poor results, thus increasing my respect for
those who are). I'm a researcher focused on design management (among
other things) and this denotation of decision styles (which is what I
refer to Genius/RED versus other type) is important, as it helps teams
understand when they do and don't need additional research to inform
their design.

You can learn more about the work I've been doing from this recent
article that describes the different design decision styles: http://is.gd/hywO

Hope that helps you understand where I was coming from.

JarEd

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

28 Jan 2009 - 1:46pm
Jim Leftwich
2004

To those, including Dave, clamoring for an in-depth presentation of
the structured approach (or as I'd put it, patterned approach) used
by designers doing work in this manner, I would first respond that
these do exist. Over many projects, and particularly documented
projects, there are a number of repeated steps and phases utilized.

RED projects share many aspects of the phases found in other more
formalized approaches to design, such as:

1) Initial information gathering, stakeholder interviews and
discussions, and review and analysis of existing bodies of
information and solutions/products/systems/services. In RED,
however, this is done very rapidly, and filtered through what's
already known, or been done previously, by the RED designer/team.

2) Rapid prototyping (this will vary among RED practitioners). My
team uses extensive paper prototyping, flows, layouts, and pattern
diagrams, iterating these to quickly explore interrelationships and
refine effective solutions.

3) Produce implementable specifications that engineers can implement
in a high-fidelity manner (blueprints), rather than spend too much of
the limited time producing interactive prototypes and limited
documentation (that engineers must analyze and try to
reduce/reproduce as an implementation.

These phases and their embodiments and examples are *best and most
easily* discussed within the context of a review of real
documentation, rather than through a run down of a reductionist list.

My initial goal in this thread is not to attempt to do that here in a
stilted text-based forum. I don't believe that's feasible. My
primary goal has been to signal others in the community who
immediately and already resonate with the points I've made. These
are others who are already practicing working in similar fashions
that have already responded, and that's the best place to start what
must be a long-term dialog and exchange of observations and
experiences.

Seeing resonating responses such as Yury Frolov's indicates that
there are others whose experiences and approaches are similar. I'm
most interested, personally, in beginning a dialog along those lines,
than in getting bogged down in tedious Q/A with those not familiar
with this type of design work or those wishing to get wrapped around
the axle of semantics and abstract and problematic concepts as
"likely success ratios."

It's much more informative to discuss (over time) actual cases and
experiences with (relative) sucesses and failures.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

28 Jan 2009 - 2:25pm
Jim Leftwich
2004

Thanks Jared (and yes I got the spelling wrong in my post).

I understand and concur with the matrix you've presented, and where
the greatest risk lies.

That's essentially why I point out the importance of gaining RED
experience (when a designer is inexperienced) by working closely with
more experienced designers. I believe I even pre-emptively pointed
out the likelihood of failure if a designer bites off more than their
experience, judgement, and capabilities can chew.

And yet I'll point out again that it's important to reach at least
some point beyond ones' knowledge and experience in order to grow as
a designer. The key is dependent upon another form of judgement, and
that's how much of a risk of the unknown to take.

To elaborate just a bit on how a RED practitioner knows what the
outcome will be, I think it clearly lies in having an understanding
of how wireframes and flows will come to life dynamically. I and my
teammembers can visualize fairly complex interactions in our heads as
we pore over complex wireframes and flows. A lot of this comes from
experience and familiarity, part of it comes from innate capabilities
of being able to do so.

There was also an earlier mention of talent (I assume this means
innate) and its role in being a successful RED practitioner.

It's been my observation working with many designers and
collaborators over the years that there are definitely some that have
the innate abilities to grasp and successfully wrangle the types of
complex, dynamic, and interrelated architectures that comprise
interaction design. And some most definitely do not. This is
separate from the equally important *temperment* quality, which I
also think is necessary. RED can be intense, and that's one reason
it's not the type of work that every designer would care to pursue.

RED is often a lot like a high stakes game of chess, played on a
dynamic board and with and against multiple players/stakeholders. It
definitely helps to have a head and stomach for that sort of thing.
And yet there are many who relish these challenges and successfully
pursue them.

To clarify Todd's question, the "Expert" applies first to
expertise as a RED practitioner and secondly to expertise in
particular application domains. The ratio between the two will
likely vary between RED practitioners. Some may stay primarily
within a particular domain and have great domain expertise, while
others' expertise may be in generalist practice of RED across many
domains. And there are RED practitioners that fall in between.

Many are familiar with the term, "T-shaped" used to describe
practitioners who have broad generalist knowledge and experience
across a number of interdependent fields and roles and deeper
specialization in one area.

I've described a related type of designer - the "Broken
Comb-shaped" designer. Picture a comb with its teeth broken
partially out in some areas, completely out in other areas, and fully
intact in others. And then think about how all broken combs look a
little bit different from one another.

Experienced RED practitioners and generalist designers are often
broken combs-shaped.

They differ from actual broken combs however, in that rather than
pieces being broken off, they're actually growing them bit by bit
over their careers. ;^)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

28 Jan 2009 - 2:29pm
Gloria Petron
2007

In *Sources of Power: How People Make Decisions*, Gary Klein offers a case
study about a baby who almost died in a neonatal intensive care unit. There
were two nurses on duty: a shift leader with years of experience (I'll call
her Mary), and a trainee (Jill). One night while they were both on duty,
Jill noticed a subtle drop in a baby's temperature. She attributed the
change to coldness in the room, so she corrected the temperature in the
bassinet and forgot about it. A few minutes later, Mary looked at the same
baby, noted the temp change, but also noticed the baby's subtle color change
and reduced fussiness, which Jill had missed. From experience, Mary
recognized the signs of onset sepsis and started the emergency protocol that
would save the baby's life.

In the post review, Mary was angry at the Jill for missing the "obvious"
signs of trouble. Later, however, Mary realized her own mistake: the
underestimation of her own experience, leading to her over-expectation that
someone else could "get it" in a few weeks.

Was Mary not good at her job? Should Jill handle the NICU by herself? After
all, it costs less to staff 2 people, and Jill seems reasonably smart and
eager to learn.

Maybe the question isn't so much "who's a better risk, an experienced person
or an inexperienced person." Maybe the question is, "How does a person
measure the depth of their experience, and market it appropriately".

-Gloria

Time magazine did a cover story once about the importance of the
> "experience" argument in the presidential campaign. They cited studies
> where
> very experienced nurses fared no better than less experienced nurses in
> making life or death decisions, and often fared worse. They found that
> experienced practitioners relied more on habit while less experienced
> practitioners were more prone to examine all the information available
> (albeit quickly).
>
> As a result, either group was just as likely to kill a patient.
>
> -r-
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

28 Jan 2009 - 3:26pm
Jim Leftwich
2004

Gloria asks the question, "How does a person measure the depth of
their experience, and market it appropriately".

I would say that for RED practitioners this is almost always measured
in terms of past experience and outcomes.

Has the designer/team worked in this domain/specific situation
before?

Have past projects produced insights that can now inform current and
future projects? (as has been an often observed result in my own
experiences and those I'm familiar with)

And the way confidence is most effectively transmitted to new
clients, teammembers, colleagues, and management is through
documentation of those past projects. This is documentation of both
the development and implementation process as well as the various
aspects of the project's outcome (user/customer satisfaction,
business success, etc.).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

28 Jan 2009 - 3:28pm
Yury Frolov
2006

Todd Zaki Warfel: So, is the emphasis here on the Rapid or on the
Expert part? ....
And frankly, I don't see what all the fuss is about.
----------------

Good question:) ... I think In the course of the RED project the
emphasis changes constantly between "Rapid", "Expert" and even
"Design" :)

As Jim mentioned it's more about the "approach" or .. "mode of
operation" rather than about any established design philosophy or
methodology (UCD, genius etc). These methods may (or may not) be
included into any particular project mix - and - UCD and Genius
principles may alternate during the same project. It also involves
active work with client, understanding their biz drivers,
capabilities, hidden desires and internal organizational politics -
that's when those extracurricular public speaking and business/
financial-oriented classes start paying off ... :)

And "all the fuzz" i believe is because this approach helps produce
relatively quickly complete and tangible product designs that can go
to market and make a real difference for clients and users in the
environment where budgets are limited - but not necessarily low :),
resources are constrained and time is critical.

It seems like one aspect is missing in this discussion. I'd argue
that typical RED project involves a small TEAM of experts who address
various aspects of design challenge and may include a lead designer,
researcher, usability specialist, technologist, visual designer etc.
etc. As any experienced cook can modify a known recipe on the fly -
based on available ingredients - and still produce good meal,
similarly - experienced design lead can achieve good and even great
results in very "limited" circumstances working with small team of
experts applying their expertise on as needed basis...

Yury Frolov
Design Director, Studio Asterisk*

GUI Strategy | User Experience | Brand

415 374 7478 voice
702 446 7840 fax

www.studioasterisk.com

On Jan 28, 2009, at 4:10 AM, Todd Zaki Warfel wrote:

So, is the emphasis here on the Rapid or on the Expert part?

Is it a RAPID Expert Designer or a Rapid EXPERT Designer? Is it rapid
design done by an expert, or quickly producing what could be defined
as an amazing expert design?

I guess I'm asking if Expert is being used as noun or adjective.

And frankly, I don't see what all the fuss is about.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.

28 Jan 2009 - 4:03pm
Jared M. Spool
2003

On Jan 28, 2009, at 12:28 PM, Yury Frolov|Studio Asterisk* wrote:

> It seems like one aspect is missing in this discussion. I'd argue
> that typical RED project involves a small TEAM of experts who
> address various aspects of design challenge and may include a lead
> designer, researcher, usability specialist, technologist, visual
> designer etc. etc.

I'm not sure that's true. In the studies we've done of folks employing
Genius Design (still stickin' with the label!), it's almost always
been solo designers. If you rank them in terms of success criteria (we
have dozens -- too much to go into here), the solo designers come out
at the top. When we've looked at the Genius Design folks working in
teams, we found the teams were small (2-3 people) and there almost
always was a strong leader with a dominant personality.

From this very early data (we're still collecting and refining our
results), this tells us that Genius Design succeeds best in instances
where you have a very experienced, skilled individual making the
design decisions.

Once the team starts to get multiple experts, they naturally will not
agree on important decisions. At that point, they'll require new
research to resolve conflicts and further inform the design decisions.
This moves them into a different classification of decision style.

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

28 Jan 2009 - 4:55pm
Jim Leftwich
2004

Jared Spool states: "Once the team starts to get multiple experts,
they naturally will not agree on important decisions."

That certainly doesn't match the experiences I've observed, in both
cases of multiple interaction experts or in cases where there was one
or more interaction design experts and an engineering expert.

Collaboration and working through the possible solutions (either at
the macro or micro scale of the project), generally always allows
these to be worked out effectively and successfully.

I consider this all to be part of the overall RED practice.

And again, nobody I've ever worked with has referred to themselves
as an inherent "genius," but has simply visualized and iteratively
developed their solution or proposal that became part of or altered
the larger solution.

Any team will naturally have more experienced and less experienced
members. Personalities and styles, however, can vary a great deal.
I've seen many younger designers coneive brilliant and insightful
solutions, and a good and effective RED team will always immediately
recognize and incorporate this.

None of the RED efforts I've been part of have been dictatorships
(among the RED team). There are, at times, issues that can be in
contention, but with communication and effort at working through
options, these are resolvable in successful ways that add value to
the effort.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

28 Jan 2009 - 5:01pm
Yury Frolov
2006

On Jan 28, 2009, at 1:03 PM, Jared Spool wrote:
I'm not sure that's true. In the studies we've done of folks
employing Genius Design (still stickin' with the label!), it's almost
always been solo designers.

-------------
Jared, I don't think we disagree. Many cooks in one kitchen - not
good. I emphasized on "small TEAM" - i should have emphasized on
"SMALL" as well. Lead designer is the one who eventually makes design
decisions - he/she takes all expert inputs and synthesizes it all in
a final design (or series of design prototypes). Some SW products
domains are so complex that working solo is practically impossible...
unless one specializes in some narrow domain (like enterprise network
management, etc.) for a long time. Plus - building prototypes,
creating visual designs typically involve other experts as well - so
it ends up being a team anyway...

... and ... I am not sure if one can equate R.E.D and Genius design...
IMHO - R.E.D is more about the mode of operation. RED team may apply
a mixture of different principles be it UCD or Genius or ... BMCD (as
in Biz-Management Centered Design - :) ) - as project challenges
require ... the trick is in finding workable solution and balance
between the needs of Users, Business Management and Geniuses .... :)

Yury Frolov
Design Director, Studio Asterisk*

GUI Strategy | User Experience | Brand

415 374 7478 voice
702 446 7840 fax

www.studioasterisk.com

On Jan 28, 2009, at 1:03 PM, Jared Spool wrote:

On Jan 28, 2009, at 12:28 PM, Yury Frolov|Studio Asterisk* wrote:

> It seems like one aspect is missing in this discussion. I'd argue
> that typical RED project involves a small TEAM of experts who
> address various aspects of design challenge and may include a lead
> designer, researcher, usability specialist, technologist, visual
> designer etc. etc.

I'm not sure that's true. In the studies we've done of folks
employing Genius Design (still stickin' with the label!), it's almost
always been solo designers. If you rank them in terms of success
criteria (we have dozens -- too much to go into here), the solo
designers come out at the top. When we've looked at the Genius Design
folks working in teams, we found the teams were small (2-3 people)
and there almost always was a strong leader with a dominant personality.

From this very early data (we're still collecting and refining our
results), this tells us that Genius Design succeeds best in instances
where you have a very experienced, skilled individual making the
design decisions.

Once the team starts to get multiple experts, they naturally will not
agree on important decisions. At that point, they'll require new
research to resolve conflicts and further inform the design
decisions. This moves them into a different classification of
decision style.

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

28 Jan 2009 - 5:20pm
Jim Leftwich
2004

The term "genius" is so problematically loaded, that it will never
function to effectively describe what is occurring in the situations
it purports to label.

It is, rather, a sort of "throw up one's hands" effort at slapping
a label on a complex reality. It also carries a high propensity to be
perceived pejoratively, and thus the underlying reality being
completely misunderstood.

It is, in this way, a term that invites more argumentation over the
term itself, than a proper focus on the complex dynamics it purports
to label.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

28 Jan 2009 - 5:23pm
Peter Boersma
2003

My summary of this thread, so far:

JarEd wants to know Jim's answer to the client's question:
"what are you going to do for me, and how?"

Jim's short answer: "Trust me, I'm experienced!"

Jim's medium-length answer: "My team and I will listen, leaf through existing documentation, do some minimal research, (paper)prototype, discuss documents, and document for implementation. We've done that before, and it worked then so it will work for you too."

My guess is that most clients won't take that for an answer and want to know more about how and when they can contribute, what they can expect in between project start and final delivery, and approximately when they can start buying advertising space for their new product.

If Jim maintains that the long answer is that he will show the client more case studies of successful past projects, I am afraid he is going to sound like a broken record, not a broken comb... ;-)

An finally, if RED = talent + skills + experience + knowledge + client trust but no fixed process, then I'm done listening.

PetEr
--
Peter Boersma | Senior Interaction Designer | Info.nl
http://www.peterboersma.com/blog | http://www.info.nl

28 Jan 2009 - 5:42pm
Jared M. Spool
2003

On Jan 28, 2009, at 2:20 PM, Jim Leftwich wrote:

> The term "genius" is [...] a sort of "throw up one's hands" effort
> at slapping
> a label on a complex reality.

Or maybe, just maybe, the term "R.E.D." is an attempt to add
complexity to something that is inherently simple.

Just sayin'.

Jared

28 Jan 2009 - 5:49pm
Robert Hoekman, Jr.
2005

>
> Jim's medium-length answer: "My team and I will listen, leaf through
> existing documentation, do some minimal research, (paper)prototype, discuss
> documents, and document for implementation. We've done that before, and it
> worked then so it will work for you too."
>
> My guess is that most clients won't take that for an answer and want to
> know more about how and when they can contribute, what they can expect in
> between project start and final delivery, and approximately when they can
> start buying advertising space for their new product.

Clients accept this answer all the time, usually without even asking for it.
They come to consultants with no budget, no time, and no resources, and
expect designers to wave their magic wands and come up with the right
solutions. The designers who can do that successfully also typically know
how to collaborate with the client, set expectations, and appropriately
schedule the project despite all the limitations.

There are also loads of successful products/apps/sites/etc out there that
were designed without an ounce of project-specific research or a
documentable process.

-r-

28 Jan 2009 - 5:55pm
Jim Leftwich
2004

Peter Boersma puts forward another caricatured oversimplification of
what actually occurs. It's difficult to respond to it without being
drawn into unproductive and uninteresting argumentation, so I'll just
let his comment stand for what it is.

None of the projects of which I'm familiar with would've gotten
underway if what Peter claims was true. Clients really are
interested in seeing past experience and documentation of process and
outcomes.

And to respond to Jared's comment, no RED is not simply an attempt
to add complexity to an inherently simple approach to design. RED is
inherently complex when practiced sucessfully.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626

28 Jan 2009 - 5:57pm
Andrei Herasimchuk
2004

On Jan 28, 2009, at 1:03 PM, Jared Spool wrote:

> Once the team starts to get multiple experts, they naturally will
> not agree on important decisions. At that point, they'll require new
> research to resolve conflicts and further inform the design
> decisions. This moves them into a different classification of
> decision style.

Sounds like the Dallas Cowboys.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

Syndicate content Get the feed