Rapid Expert Design (R.E.D.)
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
Get the feed
Comments
On Jan 28, 2009, at 2:55 PM, Jim Leftwich wrote:
> 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.
In my opinion, Jim, the reason why you're seeing these "caricatured
oversimplifications" is that we're all struggling here trying to
understand the essence of what you're talking about.
The people involved in this conversation: Peter, Robert, Marc, Todd,
Christian, David, and myself represent a substantial amount of
experience doing design with 100+ years between us. (Others involved
in the discussion, such as Yury and Jonas, probably also have a lot of
experience. I just don't know them as well.)
If we're not *getting* how this method is different from your
explanations, it might be because there's still some important,
critical piece that's missing from the discussion.
I've read through your comments multiple times and others have said
they've done the same. Yet, there's still confusion over how this is
more than just really-smart-and-experience-people-doing-good-work.
You, yourself, said it isn't as much a method as it is a "philosophy"
or "approach". Other than a label you've put on your own working
style, what is really the repeatable, scalable element here?
I'm just not getting how this is different than what we've already
got, just with the addition that you've thought about it a lot (which
is clear) and seem to have a way of transferring it to other designers.
In other words, is there a 'there' there?
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
I think Robert Hoekman's observation is generally correct. Many
situations where RED is useful, if not necessary in order to produce
the most thorough, integrated, and successful solution in the
shortest period of time or also possibly under additional
constraints, result in clients who are receptive to documented
successful RED pracitioners/teams. Not in every single case, but
often enough that it is not at all rare.
To some of these clients, it may indeed be a desire for, or look to
be "a waving of a magic wand."
To a RED designer or team, this is sadly never the case. RED, if
successful, is often hard and intense work. It should not be
confused for an easy shortcut to proper design.
In fact, many RED projects fill nearly all the hours with attention
to detailing and interrelational patterning, rather than an extended
period of gathering data and producing research reports. There are
many projects of the last decade where the implementable spec was due
within just one to two months, and the actual design work filled
nearly every hour of every teammember's time and attention.
But it's in this crucible that some extraordinary experiences are
gained. That's the payoff to the RED practitioners and teams.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
Jared Spool states: "In my opinion, Jim, the reason why you're
seeing these "caricatured oversimplifications" is that we're all
struggling here trying to understand the essence of what you're
talking about."
Well, I would say that any understanding and desire for dialog must
start first with some respect and restraint towards rhetorically
mischaracterizing what one may be struggling to understand. Peter
went so far as to actually label his caricatures as "Jim says..."
This doesn't strike me as a very productive way to proceed with an
effective discussion, and I'm sure our readers would rather not be
forced to wade through a lot of signal-free noise and thrash.
I've also stated that its in reviewing the documentation of RED
projects that the patterns and processes become apparent. RED is not
a "reduced practice." RED involves a process that's embodied in
the repeated activities and approaches taken by its practitioners,
which can be captured to varying degrees in documentation of those
projects' records. In the case of many of my own projects I began
documented them fairly well early on, in order to serve as the means
to better communicate to prospective clients exactly all that was
involved in a wide range of projects.
And this has worked. It was methodical, and it accrued over time. I
take great exception with the oversimplification, "just
really-smart-and-experience-people-doing-good-work" as within that
is a great deal of the complexity. I've flatly stated that this
complexity can only really be studied (after the fact) in
documentation of the development and outcomes.
It's unrealistic to expect that all of that vast set of issues be
laid out here for easy digestion in just a few days. In a text forum
no less!
My goal, which I stated earlier, is not to be drawn into a
frustrating and ineffective debate with naysayers, skeptics, or those
who strongly advocate other approaches to design. My goal, which has
already produced some significant results in the posts of others
here, is to begin a dialog about this general approach to design
primarily with others practicing in similar manners (of which
variation is expected).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
I feel an opportunity for a 'lunch and discuss' in Vancouver, don't you?
>
> It's unrealistic to expect that all of that vast set of issues be
> laid out here for easy digestion in just a few days. In a text forum
> no less!
>
>
You've still done pretty much everything but actually define R.E.D. If you
can't explain what it is (instead of what it is not) in a clear manner, it's
going to be very difficult to get anyone else to understand it, hence all
the confusion in this thread.
My goal, which I stated earlier, is not to be drawn into a
> frustrating and ineffective debate with naysayers, skeptics, or those
> who strongly advocate other approaches to design.
Boy, are you in the wrong place. On this list, one cannot have a dialog
without the inclusion of naysayers and skeptics. :)
For what it's worth, this debate might only be ineffective and frustrating
because few people here seem to understand what you're talking about despite
that we're all trying to.
Define R.E.D. and let's go from there.
-r-
Robert Hoekman states: "Boy, are you in the wrong place. On this
list, one cannot have a dialog without the inclusion of naysayers and
skeptics. : ) "
I think this dynamic is familiar to anyone that's participated in
online forums over the past two decades. My approach is not to
engage with baiting, but to dialog with those that pick up on at
least some aspect and engage in honest dialog (as opposed to simply
repeating demands for this or that - an old and tiresome debate
gambit).
I think it's only problematic with some of the respondents here,
perhaps yourself included. Others, including some that have emailed
me directly, do indeed connect with the subject, and that was
expected.
Perhaps if you're attending Interaction09 next week, you can join us
in a higher bandwidth discussion, perhaps with some examples. I'd
enjoy that opportunity in a more accomodating environment.
Until then however, I'm still happy to hear other anecdotes and
observations from practitioners working in situations similar to
what's been adequately described here.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
On Jan 28, 2009, at 3:04 PM, Jared Spool wrote:
Yet, there's still confusion over how this is more than just really-
smart-and-experience-people-doing-good-work. You, yourself, said it
isn't as much a method as it is a "philosophy" or "approach". Other
than a label you've put on your own working style, what is really the
repeatable, scalable element here?
.... In other words, is there a 'there' there?
---------------------
... But is there anything wrong with RED being 'just' an "approach"
or "mode of operation"? Like Special Ops tactics and tools (i am not
crazy about this analogy - but for the lack of a better one..) i
suspect certain RED practices can be codified and successfully
"scaled" into various project strategies ...
...What I am reading in Jim's comments is that he frames an
interesting design phenomenon (which spreads beyond narrow design
methodologies) that many people practice but that has not been
recognized or sufficiently discussed....
I think there is something 'there' since I believe most of us are
familiar with numerous cases when a work of "really-smart-and-
experience-people-doing-good-work" went nowhere - i.e. has not
resulted in great, good or even acceptable designs to be tested and
released ...
RED may not be always adequately implemented (by the engineering team
- see other threads on this list :) - or may be not even the most
ideal design solution possible- but at least there is always a
tangible result - a designed product or service ... not just a bunch
of UI consultants' reports that engineers do not know what to do with
-- no offense meant to people whose work is to produce those reports....
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 3:04 PM, Jared Spool wrote:
On Jan 28, 2009, at 2:55 PM, Jim Leftwich wrote:
> 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.
In my opinion, Jim, the reason why you're seeing these "caricatured
oversimplifications" is that we're all struggling here trying to
understand the essence of what you're talking about.
The people involved in this conversation: Peter, Robert, Marc, Todd,
Christian, David, and myself represent a substantial amount of
experience doing design with 100+ years between us. (Others involved
in the discussion, such as Yury and Jonas, probably also have a lot
of experience. I just don't know them as well.)
If we're not *getting* how this method is different from your
explanations, it might be because there's still some important,
critical piece that's missing from the discussion.
I've read through your comments multiple times and others have said
they've done the same. Yet, there's still confusion over how this is
more than just really-smart-and-experience-people-doing-good-work.
You, yourself, said it isn't as much a method as it is a "philosophy"
or "approach". Other than a label you've put on your own working
style, what is really the repeatable, scalable element here?
I'm just not getting how this is different than what we've already
got, just with the addition that you've thought about it a lot (which
is clear) and seem to have a way of transferring it to other designers.
In other words, is there a 'there' there?
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
________________________________________________________________
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
On Jan 28, 2009, at 6:04 PM, Jared Spool wrote:
> I've read through your comments multiple times and others have said
> they've done the same. Yet, there's still confusion over how this is
> more than just really-smart-and-experience-people-doing-good-work.
> You, yourself, said it isn't as much a method as it is a
> "philosophy" or "approach". Other than a label you've put on your
> own working style, what is really the repeatable, scalable element
> here?
This reminds me of that article Lou commented on from that Branding
guy who was clueless a few months back. Shows you how memorable his
branded version of whatever design process he had was, I can't even
remember the name or company or anything.
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.
On Jan 28, 2009, at 7:41 PM, Yury Frolov|Studio Asterisk* wrote:
> ... But is there anything wrong with RED being 'just' an "approach"
> or "mode of operation"? Like Special Ops tactics and tools (i am not
> crazy about this analogy - but for the lack of a better one..) i
> suspect certain RED practices can be codified and successfully
> "scaled" into various project strategies ...
Nothing wrong with that, if anyone understood what kind of tactics
were used and how they can actually implement them themselves. Problem
is, Jim hasn't, nor has anyone else, actually defined what RED is.
We haven't bought in, because we don't see the value, because we don't
understand, because it hasn't be defined.
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.
Despite repeated mention of examples and/or documentation about this
magical unicorn of a. . . thing/process/ideology/methodoolgy, Mr.
Leftwich has yet to provide a link to any of it. My kingdom for
useful examples, sir!
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
To address Gabby's question, a very small web-sized selection of bits
of my own projects can be found at my site:
http://www.orbitnet.com/
And though it's from 2005, a slideshow and accompanying set of
slides giving very high-level overviews of a selection of projects
can be found at:
Text:
http://orbitnet.com/iasummit2005/
Slides:
http://www.orbitnet.com/iasummit2005/iasummit2005.html
...though these examples were not aimed at laying out a reductionist
process, but rather distilling some lessons learned along the way
from each of these projects.
For some of the documentation samples included in those slides, it's
important to note that there are often hundreds of similar pages that
would've gone into the development, and many more that serve as part
of the implemenation documentation.
As for how clients are approached, many project begin by actually
doing a short but intense project to give an overview of the phases
that will comprise the project. The teams I've worked with (in
consulting roles) always create very detailed, often design-filled
proposals. We've even done first draft style guides to show the
approach we will take more fully in a project. I've seen a lot of
text-based design proposals, and I've also had a number of clients
from large consumer electronic corporations comment that they were
really convinced by both the past work we've shown and, in cases
where we did it, our proposal's quick overview designs.
Nobody I'm familiar with has ever simply asked a client to trust
them, without given them a great deal of confidence of what they've
done, and what they will do and deliver.
Ironically, I can hardly count the times I've been involved in
design projects that followed some former design consultancy that the
client was unhappy with, and I know that some of these involved large
teams and quite a bit of research and process. Apparently some of
these have difficulty in translating all of that research and process
into an actual implementable design. At least that's what I hear
from some clients.
And I actually did lay out the three primary activities that make up
the RED projects I and others have worked on:
I'll repeat them here again, as some evidently missed them:
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.
In proposals we describe in detail how these three activities will be
conducted (iteratively) and what the specific deliverables will be and
at what times.
We use past project documentation to give new clients a sense for the
form and depth of this work. It's not magic, nor mythical, nor
anything other than simply real work.
It's very much enough structure and process to give a client a sense
of how the development will proceed. And this design work is almost
always very closely coordinated with the client and in some cases
carried on collaboratively (we've experienced many variations on
both).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
@Dave and others asking for deeper analysis etc, a lot of this is reminding me of some things I read for my PhD last year, particularly around work integrated learning (WIL) particularly in the health (nursing for example) and education sectors
...and Donald Schön's stuff around how reflective practitioners learn through practice (the reflective practitioner, educating the reflective practitioner) - what Jim and others are (i think) describing as experience.
Late last year I started doing some interviews with IxD's around (amongst other things) 'what goes on in the studio' and how they communicate their knowledge and insight to one another while they work. I'd love to say that I have some answers, but the work so far is just beginning (it has to fit in with a full time academic job and other life). I hope to have some more cogent thoughts on this at the end of this year if anyone's interested.
I'd also be interested to follow up with people who have strong thoughts on this while in Vancouver next week.., so feel free to drop me a line if yr interested.
http://en.wikipedia.org/wiki/Donald_Schon is a good starting point re Schön and other related work...
oh - and I'll dig out the WIL etc refs and post too. it'll take me a few days though :
43C/110F here all week and there's soooo much to get through before flying to YVR in .. 5 days.. omg!
@Dave and others asking for deeper analysis etc, a lot of this is
reminding me of some things I read for my PhD last year, particularly
around work integrated learning (WIL) particularly in the health
(nursing for example) and education sectors
...and Donald Schön's stuff around how reflective practitioners
learn through practice (the reflective practitioner, educating the
reflective practitioner) - what Jim and others are (i think)
describing as experience.
Late last year I started doing some interviews with IxD's around
(amongst other things) 'what goes on in the studio' and how they
communicate their knowledge and insight to one another while they
work. I'd love to say that I have some answers, but the work so far
is just beginning (it has to fit in with a full time academic job and
other life). I hope to have some more cogent thoughts on this at the
end of this year if anyone's interested.
I'd also be interested to follow up with people who have strong
thoughts on this while in Vancouver next week.., so feel free to drop
me a line if yr interested.
http://en.wikipedia.org/wiki/Donald_Schon is a good starting point re
Schön and other related work...
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
oh - and I'll dig out the WIL etc refs and post too. it'll take me a
few days though :
43C/110F here all week and there's soooo much to get through before
flying to YVR in .. 5 days.. omg!
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
Jim,
In all due respect, I think people on this list are trying very hard to
elicit a definition of RED that can be considered within a thoughtful
discussion. As Dave Malouf said, you can't expect to put an idea out there
without taking a swipe or two, but that doesn't mean that this community has
a propensity for slamming anything that seems unorthdox. Quiet the
contrary. You clearly feel very passionate about your ideas, but, again, I
fail to see the tangible description of RED that can not only be judged
along side other established methodologies, but can be used as a starting
point for discussion. In fact, I went back and re-read Dan Saffer's
description of "Genius Design" and, whether you like the label or not, the
concept is clearly explained in about a page and a half of text. No
problem. I totally get what he means, regardless of the so-called label.
For an idea to take hold, we must have some overarching concept as a
starting point. Detailed discussions of past work should function as
"evidence in support of a concept" rather than prerequisite for discerning a
concept. In short, if we don't get it at "hello", it's not going evolve as
a productive conversation. To your point, it ends up being and endless Q&A
rather than a thoughtful debate. Rather than spending so much time
dissecting the "nature" of discussions on this list, your efforts would be
better served by putting on the old marketing hat and crafting a definition
of RED that might be used as a doorway into what you consider a more
productive conversation.
Cheers,
Cindy
>
> Rather than spending so much time dissecting the "nature" of discussions on
> this list, your efforts would be
> better served by putting on the old marketing hat and crafting a
> definition of RED that might be used as a doorway into what you consider a
> more productive conversation.
>
Cheers to that.
-r-
I think my most recent post is about as detailed as I can get to a
description of the components of the RED approach to design and
development.
It's not a reductionist set of processes, such as those promoted by
others, so those looking for something akin to how other
methodologies are described, but different, will not find it here.
The three activities described above, iteratively pursued within the
context of a design problem, yield the results. This is our
successful, and repeated process, even if it falls short of a formal
(or simple enough?) description/definition for some requests.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
On Jan 28, 2009, at 6:52 PM, Jim Leftwich wrote:
> 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.
Jim,
I'm really trying. But I'm not getting it.
This, to me, just seems like standard operating procedure for design
done without outside research. It'll work well when the experience of
the design team is such that the decisions they make are smart
decisions. It'll fail when the team makes decisions that they don't
realize cause problems down the road.
This is not unlike processes used by teams all over the world, many of
whom end up producing designs the users love. And many of whom end up
producing designs the users despise. (Think of almost any design from
a major company that frustrates the hell out of you and I'll bet you
their team used this approach.)
So, please help me understand how this is any different than what's
been done in technology design for the past 30+ years.
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
I don't think how I and my partners design is anything at all like
whatever the design that's been done (as you characterize broadly)
"in technology design for the past 30 years."
I doubt that all of those teams, including the unsuccessful ones you
mentioned, approached things from very diverse and experienced
backgrounds, with expertise in designing a wide range of development
factors successfully. I also doubt that those efforts have involved
teams producing pixel-perfect and behavioral-rule-perfect
specification blueprints, as we've done.
I don't think the approach and level of design and interactional
architecture I'm describing is found in the typical way technology
design has been practiced across all products, software, and systems.
I believe that the RED I'm describing is most often practiced by
consultants, and as you'd stated earlier, small teams.
I believe what you're alluding to is actually a lack of adequate
architectural design. The typical effort has been a cobbled-together
mash of engineering with a big of marketing icing smeared over the
top. Almost nothing could be further from the RED practice I'm
describing.
RED is much closer to how building architecture has been
traditionally approached. We design it, produce the blueprints, and
the engineers build it. Often it is very collaborative with
engineers.
And it's not as though there's no research. It's just that the
research is conducted very quickly, and also involves extensively
pulling from any already-known body of knowledge at the client or in
the organization.
Your claim of it will work well when... and it will fail when... can
just as easily be applied to any type of methodology and any
generic/symbolic designer.
What I believe, from what I've experienced first hand and what I've
observed, is that experienced and broad-based RED practitioners and
small teams are capable, designer-for-designer/team-for-tem, of
producing more and superior products, in more conditions, in tighter
timeframes, for less cost, than any other method. But that assumes
that the designers are both broadly talented and extensively
experienced.
The only way to determine whether or not this is true is to examine
the outcomes and the associated efforts that went into them. That's
why I contend that when all is said and done, it comes down to
examples of actual work, as in the design, implementation, and
results.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
This is the RED <http://www.red.com/cameras/> you should be talking about!
On Wed, Jan 28, 2009 at 11:38 PM, Jim Leftwich <jleft at orbitnet.com> wrote:
> I don't think how I and my partners design is anything at all like
> whatever the design that's been done (as you characterize broadly)
> "in technology design for the past 30 years."
>
> I doubt that all of those teams, including the unsuccessful ones you
> mentioned, approached things from very diverse and experienced
> backgrounds, with expertise in designing a wide range of development
> factors successfully. I also doubt that those efforts have involved
> teams producing pixel-perfect and behavioral-rule-perfect
> specification blueprints, as we've done.
>
> I don't think the approach and level of design and interactional
> architecture I'm describing is found in the typical way technology
> design has been practiced across all products, software, and systems.
> I believe that the RED I'm describing is most often practiced by
> consultants, and as you'd stated earlier, small teams.
>
> I believe what you're alluding to is actually a lack of adequate
> architectural design. The typical effort has been a cobbled-together
> mash of engineering with a big of marketing icing smeared over the
> top. Almost nothing could be further from the RED practice I'm
> describing.
>
> RED is much closer to how building architecture has been
> traditionally approached. We design it, produce the blueprints, and
> the engineers build it. Often it is very collaborative with
> engineers.
>
> And it's not as though there's no research. It's just that the
> research is conducted very quickly, and also involves extensively
> pulling from any already-known body of knowledge at the client or in
> the organization.
>
> Your claim of it will work well when... and it will fail when... can
> just as easily be applied to any type of methodology and any
> generic/symbolic designer.
>
> What I believe, from what I've experienced first hand and what I've
> observed, is that experienced and broad-based RED practitioners and
> small teams are capable, designer-for-designer/team-for-tem, of
> producing more and superior products, in more conditions, in tighter
> timeframes, for less cost, than any other method. But that assumes
> that the designers are both broadly talented and extensively
> experienced.
>
> The only way to determine whether or not this is true is to examine
> the outcomes and the associated efforts that went into them. That's
> why I contend that when all is said and done, it comes down to
> examples of actual work, as in the design, implementation, and
> results.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=37626
>
>
> ________________________________________________________________
> 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
>
When I read and think about this thread, I see two somewhat related
aspects being addressed.
--------
One is about the significance of _methodology_.
Can RED be specified, broken down into steps, compared with other
methods, etc.? I suppose it can, and Jim has offered a three-phase
structure, but the attempt doesn't really seem to be enough for some
of the other list members.
The heart of the matter, I believe, is whether methods carry
knowledge or not. If RED could be "specified" extensively as a
procedural method, would that enable other designers to perform at
the levels Jim is suggesting -- by following the specified method?
In my personal opinion, the answer is no. Methods (and tools) are
never better than the people using them. And the phases identified by
Jim certainly contain no particular secrets to successful design
outcomes. As I read Jim's discussion of RED, the key is the abilities
that the RED designer holds.
--------
Which leads on to the other aspect of the thread: the nature of
_design ability_.
What is it that distinguishes a good designer in terms of skills and
knowledge? This is a question that has been addressed extensively in
the academic field of design studies, and typical answers include
things like
- a repertoire of genre-relevant design ideas that can be matched
rapidly against new design situations;
- craft skills to bring the outcomes of such matching processes into
concrete existence ("sketching");
- the ability to judge possible design ideas by predicting how they
are likely to work, based on internalized and operationalized
elements from research, observation, previous work in similar use
situations, etc.
A natural follow-up question is then how design ability can be
developed. Referring to design studies again, a typical answer is by
reflective practice (roughly: apprentice/master learning augmented
with meta-levels of reflection on learning processes). Methods (and
tools) play important roles in learning, but do not substitute it:
they do not carry knowledge in themselves.
As might be inferred, this way of thinking entails that design
examples are key resources in building design ability. The strong
emphasis on inspirational collections, canons, portfolios and crits
that you will find in design schools is no coincidence -- the work
taking place in such settings is always primarily about concrete
examples, and the underlying agenda is to provide the raw materials
for students to build their own repertoires and judgment skills.
The work of Donald Schön was already mentioned, and I second it as a
very useful introduction to this kind of thinking about design
ability. I could add Nigel Cross ("Designerly ways of knowing") as
another useful introductory resource.
--------
I know that these observations do not contribute to a "definition" of
RED, and perhaps they don't help the discussion forward. But the
bottom line for me is the role of methodology vs. the role of ability
in our field. My reading is that Jim is talking mainly about ability
(which makes perfect sense to me from a design-theoretical point of
view), whereas much of the discussion in the thread seems to be based
in a different mindset, where methods are seen as carriers of
(practical) knowledge.
Jonas Löwgren
PS. I would happily add my 21 years to Jared's accumulated-design-
experience tally, although I have done most of it in academic
settings. Don't know if that counts.
Jonas, I really appreciate your ability for framing.
My class here at SCAD (Interaction Minors in the Industrial Design
Department) took a stab at re-reading Jim's 3 steps and here's what
we came up with.
It seems that what Jim is talking about is a fairly common discovery
> Design > Document framework that they recognize quite easily and
makes sense to them.
We have been in contrast (mentioned in the other thread) thinking
about frameworks for design noticed that the "rapid" nature of RED
(a seemingly growingly important aspect of RED that has not been
fully dealt with). But it seems that it is quite a definer here.
What we saw were the following components missing:
Time for an ideation period. At least, it is condensed dramatically
and not mentioned as an important articulated aspect of the process.
It seems that the "expert" part comes in here where "first" idea
out of the research phase (and it seems there is one) is what is used
for prototyping. And any iterating is about refining through
validation (something that Dan refers to directly in the "Genius
design" description).
the other piece that seems missing is the strategic. There isn't an
articulated framing of strategy, narrative and associated long term
tactics.
Our (and now my) new observation of RED fits along the "special
opps" line. Jim seems to be creating a "niche" market for his
consultancy/practice similar to the special opps. We can jump into
any hot zone and get the job done quickly and efficiently. If you
want proof, here is our body of work of success (the sell message).
You don't need to know what/how we do our work, and you don't want
to know, like velcro and the magic shammy.
What we mean by this is that it feels like "design". Plain and
simple and noted above, but it is framed and practiced in such a way
that makes it practical and focused on such niche problem areas.
Jim, is our reflection of our understanding improving? (more
positive?)
-- dave
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
My take on RED, given what I have read is that it is a really compelling
story for prospective and current clients. I am not trying at all to
minimize it, but that's what I get out of what has been described so far.
Having talked to a number of consultants and studio heads over the years,
clients do want to know that you have a process and that you can show proven
results from you past work. Incidentally, they are no where near as
interested in the details of the process as we are, or as we hope they are.
btw - Jim... I commend your focus on results. This is incredibly important
to clients and most programs for design accolades skip over this part in
favor of beauty pageants and cool factor ratings (mostly because it is
hard). As a profession, this is the best way to build credibility. While
metrics for design are really hard (if not impossible) right now, it is
something we should be striving for.
I know that there is much behind the RED concept beyond marketing. But this
is what I see now... and am looking forward to further discussions and
disclosures.
Mark
On Thu, Jan 29, 2009 at 10:54 AM, Dave Malouf <dave.ixd at gmail.com> wrote:
> Jonas, I really appreciate your ability for framing.
>
> My class here at SCAD (Interaction Minors in the Industrial Design
> Department) took a stab at re-reading Jim's 3 steps and here's what
> we came up with.
>
> It seems that what Jim is talking about is a fairly common discovery
> > Design > Document framework that they recognize quite easily and
> makes sense to them.
>
> We have been in contrast (mentioned in the other thread) thinking
> about frameworks for design noticed that the "rapid" nature of RED
> (a seemingly growingly important aspect of RED that has not been
> fully dealt with). But it seems that it is quite a definer here.
>
> What we saw were the following components missing:
> Time for an ideation period. At least, it is condensed dramatically
> and not mentioned as an important articulated aspect of the process.
> It seems that the "expert" part comes in here where "first" idea
> out of the research phase (and it seems there is one) is what is used
> for prototyping. And any iterating is about refining through
> validation (something that Dan refers to directly in the "Genius
> design" description).
>
> the other piece that seems missing is the strategic. There isn't an
> articulated framing of strategy, narrative and associated long term
> tactics.
>
> Our (and now my) new observation of RED fits along the "special
> opps" line. Jim seems to be creating a "niche" market for his
> consultancy/practice similar to the special opps. We can jump into
> any hot zone and get the job done quickly and efficiently. If you
> want proof, here is our body of work of success (the sell message).
> You don't need to know what/how we do our work, and you don't want
> to know, like velcro and the magic shammy.
>
> What we mean by this is that it feels like "design". Plain and
> simple and noted above, but it is framed and practiced in such a way
> that makes it practical and focused on such niche problem areas.
>
> Jim, is our reflection of our understanding improving? (more
> positive?)
>
> -- dave
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=37626
>
>
> ________________________________________________________________
> 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
>
>
> I think my most recent post is about as detailed as I can get to a
> description of the components of the RED approach to design and
> development.
>
Well, then it sounds like nothing more than a name for a situation rather
than a methodology, approach, philosophy, or process. And I just don't see
how that's helpful.
-r-
On Jan 28, 2009, at 11:38 PM, Jim Leftwich wrote:
> I doubt that all of those teams, including the unsuccessful ones you
> mentioned, approached things from very diverse and experienced
> backgrounds, with expertise in designing a wide range of development
> factors successfully. I also doubt that those efforts have involved
> teams producing pixel-perfect and behavioral-rule-perfect
> specification blueprints, as we've done.
Actually, pixel-perfect and behavioral-rule-perfect specifications of
crappy designs are created every day.
So, from what I read in what you've written, what separates the teams
that succeed from the teams that fail are the people, their diversity,
and their experience.
In fact, you could probably take the same group of intelligent,
diverse, experienced people, have them stand in a corner, wear pink
hats, chant 17th Century Romanian Love Poems, while typing on keyboard
with their toes, and still get better designs than many organizations
out there.
Good design starts with good designers. There's no getting around that.
> I believe what you're alluding to is actually a lack of adequate
> architectural design. The typical effort has been a cobbled-together
> mash of engineering with a big of marketing icing smeared over the
> top. Almost nothing could be further from the RED practice I'm
> describing.
Ok. But your description of the RED practice doesn't mandate adequate
architectural design. As far as I've determined, there's nothing in
your Philosophy/Approach/Method that ensures that's done, except the
expertise of the team doing it.
So, what is the contribution of the RED practice to ensuring this is
done?
> And it's not as though there's no research. It's just that the
> research is conducted very quickly, and also involves extensively
> pulling from any already-known body of knowledge at the client or in
> the organization.
Which is based on the assumption that that research information is (a)
readily available and (b) accurate. What does the RED practice do to
ensure there aren't holes, the information is easy to attain, and,
once collected, validates that it is in fact an accurate
representation of user needs, goals, and contexts?
> What I believe, from what I've experienced first hand and what I've
> observed, is that experienced and broad-based RED practitioners and
> small teams are capable, designer-for-designer/team-for-tem, of
> producing more and superior products, in more conditions, in tighter
> timeframes, for less cost, than any other method. But that assumes
> that the designers are both broadly talented and extensively
> experienced.
EXACTLY MY POINT! Woo hoo!
Take away the talented and extensively experienced part, and the
entire practice, as I understand it, falls apart.
Give those same talented and extensively experienced people another
way to work, and they'll still produce good stuff.
In Stone Soup (obligatory Wikipedia citation: http://is.gd/hH3C), the
stone isn't magic and doesn't really make soup. It justs gives the
villagers the perception that it does. The important lesson from that
fable is that the traveller doesn't actually believe in the stone's
magical abilities.
RED to me sounds like Stone Soup. I'm sure your clients really believe
you've created soup from a stone. And I believe you've created great
soup. But I'm not seeing what the stone's contribution is.
Looking forward to seeing the magic revealed in Vancouver. :)
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
On Jan 29, 2009, at 7:54 AM, Dave Malouf wrote:
Our (and now my) new observation of RED fits along the "special
opps" line. Jim seems to be creating a "niche" market for his
consultancy/practice similar to the special opps. ....
... What we mean by this is that it feels like "design".
----------------
Excuse me... but ... "niche"??? After meeting with hundreds of tech
companies (big and small) here in the Silicon Valley (and a few
across the globe) I know that this RED "approach/method/thingy" is
the only chance for these companies to get their products designed
competently, on time, on budget, fit the design phases into their
tight dev cycle and release the product ...
Interestingly, it seems like some people immediately get what Jim is
talking about and for others no amount of explanation makes any
sense. I suspect that since RED makes enormous impact on the business
side of things - particularly on the client side - the value (and the
very existence) of such a phenomenon will remain questionable for
designers who are not exposed to those kind of conversations ...
May be it is just "design" - but practiced in very specific manner
that keeps clients coming back for more ....
-----------------
Yury Frolov
Design Director, Studio Asterisk*
GUI Strategy | User Experience | Brand
415 374 7478 voice
702 446 7840 fax
www.studioasterisk.com
Yury, I've been reading your messages and it is great that "you get
it", but pppplease!!!!!
We are NOT talking about UX/Agile methods here that many in the
valley are moving towards and please don't put out overly dramatic
generalizations or sub-positions that have no basis in reality. MOST
design works in the Valley are still heavily invested in standard UX
methods if they have ANY design at all. There are few name-orgs that
are using RED as their sole or even primary mode of operating from
what I've seen.
Further, it is just really unclear what RED is beyond experienced
designers using their experience to short-cut the rest of the system.
A valid practice, but really far from a method that one can profess as
profound.
So I stand by my "niche" sentiment since there are so few people
who can even call themselves experienced enough for such a method.
With over 15 years of IxD work under my belt, i would only do
"genius" design when I had to, but would still always choose a
truer UCD process that employed context-based research over using
2ndary sources and my gut. And further as a designer, i find it hard
to not have a strong ideation and strategy setting part of the
framework and methods that I use regardless of ability to do
research.
-- dave
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
Dave, seems like we are talking past each other. I am NOT talking
about UX/Agile methods here either.
As to reality - my fellow team members and I must have been dreaming
shuffling through volumes of UI-related research, UI evaluations,
usability reports, UI improvement recommendations etc. that went
nowhere and gather dust in some cubicles... again - it's no like the
work was bad... it just .. err... did not work??? IMHO - due to
the nature of many tech SW firms they needed a complete, fast and
affordable process, not just bits and pieces of good work or volumes
of exhaustive research that arrive when all release dates are past
due...
I think that it's been already said enough that RED (at least in my
understanding) is not rejecting any established design methods be it
research, user interviews, persona creation etc., etc. RED team
approaches it all from a specific angle, like: what do we know about
this particular domain, problem, design challenge? how much research
is needed? do we really need to conduct 25 (50, 100?) interviews ,
would 12 enough? 8? 6? In what form these findings should be
presented to client? is it 100 page report? is it 1 page diagram? a
flash movie? In what format this particular client will be able to
understand presented information easier, share among themselves? Same
for persona creation - how deep, how detailed etc.... These are
expert judgement decisions made in a context of a particular client/
project guided by this single goal: to produce a final (acceptable-
good-great) implementable design - and i repeat - on time, on budget.
As to being dramatic - well, sorry... I am a bit passionate about all
this because it's hard to hear red-faced engineering and biz managers
slamming UI design practices as "not working", "we don't know what to
do with this paper" kind of comments year over year... May be they
are all niche managers from niche companies like McAfee and Applied
Materials?... don't know ...
On Jan 29, 2009, at 11:33 AM, Dave Malouf wrote:
Yury, I've been reading your messages and it is great that "you get
it", but pppplease!!!!!
We are NOT talking about UX/Agile methods here that many in the
valley are moving towards and please don't put out overly dramatic
generalizations or sub-positions that have no basis in reality. MOST
design works in the Valley are still heavily invested in standard UX
methods if they have ANY design at all. There are few name-orgs that
are using RED as their sole or even primary mode of operating from
what I've seen.
Further, it is just really unclear what RED is beyond experienced
designers using their experience to short-cut the rest of the system.
A valid practice, but really far from a method that one can profess as
profound.
So I stand by my "niche" sentiment since there are so few people
who can even call themselves experienced enough for such a method.
With over 15 years of IxD work under my belt, i would only do
"genius" design when I had to, but would still always choose a
truer UCD process that employed context-based research over using
2ndary sources and my gut. And further as a designer, i find it hard
to not have a strong ideation and strategy setting part of the
framework and methods that I use regardless of ability to do
research.
-- dave
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
________________________________________________________________
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
On Jan 29, 2009, at 4:04 PM, Yury Frolov|Studio Asterisk* wrote:
> As to being dramatic - well, sorry... I am a bit passionate about
> all this because it's hard to hear red-faced engineering and biz
> managers slamming UI design practices as "not working", "we don't
> know what to do with this paper" kind of comments year over year...
That doesn't sound like a problem with the methods, but rather the
implementation of the method and the artifacts.
To be frank, most of the artifacts I've seen produced are junk, crap,
they stink. If I have to spend 30 minutes explaining the sitemap to
you, then either the model is broken, or my artifact isn't designed
properly. Isn't the point of an artifact to add clarification and
traceability? If it's clouding things, then you should rethink it.
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.
Yea, I have to agree with Todd,
It sounds more like cultural problems and with execution issues. Of
course a closet filled with materials is an issue, and if you are
looking at 100's of data points, well then that is a HUGE execution
problem anyway for most projects.
Here's my concern with what you are saying Yury. It sounds like you
are resonating with what Jim says, b/c you are in pain of what
you've seen from the other side. But Jim is being quite specific
about the proper context for the methods he uses as well as for the
scale and scope of those methods. I feel you are putting "words in
his mouth" to his actual disadvantage without much experience with
what he's actually done or how's he done it.
The work environment you mention (been there, done that, change it)
is not uncommon, but also is not a given. 90% of applying UX in
tech-centric environments in evangelism and in these environments in
particular the real datapoints that are derived from observation of
users (pick a method) are even that much more important to maintain,
and consider and figure out how to bring along the biz/engineering
sides into the process instead of presenting to them from the
outside. It sounds like you just have a lot of work to do.
-- dave
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
Part 1 of 2:
First, I'd like to acknowledge the many exellent points made by
Jonas Löwgren above. His grasp on where I'm coming from here is
both astute, and also was a great help (along with reading the
responses of several others) in gaining a better insight as to where
there's a significant disconnect in our understandings of the
related issues.
RED is, indeed and primarily, focused *on* the skills and
experienced-gained judgement of its practitioners, and not on any
particular methodology (as many are employed in ad hoc and
overlapping manners, according to the potentially wide variance of
situation and project being pursued).
The biggest "aha" moment for me was when I finally saw comments
here to the effect of, "Well, it simply appears that you're just
talking about good design being done by competent designers"
Ha! It's *exactly* at this juncture where the perpendicular nature
of the two mindsets cross. "Just"
RED is primarily the philosophy, approach, and style of practice
(crucible) in which designers capable of working successfully in
complex projects in very rapid timeframes can be developed.
Any RED practitioners, and I would suggest that many (despite Dave's
assessment) designers practice some form of RED, and particularly
consultancies, would recognize that there is no trivial "just" in
becoming proficient in doing complex design and development rapidly.
I had stated early on that RED is not one of the traditional
reductionistic methodologies that attempt to take the designer
(individual and their capabilities) out of the equation.
This is also why RED will *never* be able to be taught in seminars
and described in simplistic terms in books, etc.. This is also why
RED resonates with people who are engaged in RED-like practices and
experiences, and seems to be completely opaque to those who are more
focused on non-personal methodologies and repeatable generalities.
The disagreement in this thread comes not from an argument within the
same frame or terms. The disagrement here is primarily between those
practitioners, like those of us engaged in RED, which have developed
actual real world project-based crucibles in which we, along with
team members, conduct our products and grow (individually and as
teams) in our ability to do the same.
If I could summarize this perpendicular paradigm clash, it would be
this:
Process-focused designers and designer observers focus on those
aspects of formalized process that, under conditions where they're
possible, provide tools and means for designers of a wide range of
types and skill levels to conduct structured practice. Furthermore
they recognize the importance of individual skill and ability, but
separate this from the methodologies they consider key.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
Part 2 of 2:
RED-focused designers focus primarily on gaining broad and general
judgement and design skills and experience allowing them to react and
create effective and successful solutions in a wide range of problem
spaces. They recognize and utilize a wide range of methodologies,
often in rapid and ad hoc manners, but are primarily focused on
improving their own, protege's, and teams' dynamic judgement,
skill, and implementation capabilities. Furthermore they recognize
the importance of methodologies, but separate this from the dynamic
judgement, skill, and implementation capabilities of designers that
they consider key.
The "methodology" here lies in the master/protege/team crucible
environment over time, of applying the three design activities I
previously listed, in order to develop and hone better and better
designers.
Designers and designer skills, judgement, and implementation
capabilities forged in the RED crucible produce over time the ability
to achieve more successful results (particularly for revolutionary
scale projects) in shorter timeframes and with less resources.
RED practice is not arbitrary. RED is practiced by many designers
who don't understand (yet) that this is what they're doing.
RED is not a fallback (as "genius design" is characterized by its
fans, so from here out I'll suggest these remain two separate
things). RED is a primary approach to doing design.
RED is successful primarily because the experiences gained in RED
projects (particularly among younger designers) provide opportunity
to grow as designers in ways not afforded by more structured and
constrained methods. Particularly those methods that downplay the
crucial role of individual talent, experience, and judgement or how
these can best be exercised and grown.
And this schism runs very deep within our field and community. This
is why we've got Dave yelling at Yury, instead of recognizing that
we've got a perpendicular paradigm clash at work here. It's why
others have been repeatedly trying to get their heads around what
I'm saying about RED, and missing the point because they're using a
different frame and reference than RED uses in order to try to
understand it.
We observe similar complete disconnects in dialogs between people of
different political persuasions and many other types of endeavors and
subject, where understanding begins with the participant's underlying
worldview.
RED practitioners are, at the very least, an unvocal and largely
undiscussed segment of the design world. Process-oriented inquiry
has some advantages in that it fits into books and seminars. RED
expertise and experience is very difficult because it must be forged
in real-world circumstances.
But it's a monumental mistake for our field to dismiss RED and RED
practitioners on the grounds that they're such a minority as to be
insignificant or not important to acknowledge.
RED practitioners have, do, and will continue to make significant and
crucial design and development contributions to development in a wide
range of fields. And by beginning now, through the study and dialog
of those who have practiced in this manner, to discuss this approach,
we can open up this possibility to many more practicing designers.
If it accomplishes nothing more in the short term other than to
provide a signal to the community that yes, what's commonly reduced
to "intuition," can indeed be a superior means of obtaining a
successful solution in many constrained situations. And that this
"intution" is not really that at all, but rather RED, and greatly
informed and accomplished through the crucible of experience.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
Jees... Dave,
I wrote about the RED context in my very first comment - please
revisit...
BTW - to avoid putting my words in anybody's mouth I try to add
"IMHO", " in my understanding" (as often as it's tolerable for
readers).. shall I add it to every sentence???
I believe Jim will correct me if need be...
You also seem to have quite a few assumptions about our experience. I
am talking of the experiences of small design firm that has been
around the Valley since 1997. Enough time to see patterns of client-
designer relationships and see outcomes of ours and somebody else's
project work.
When I talk about the frustrated VPs and CTOs -- they described their
previous experiences with some practitioners - after we started
working with them we've been successful enough to keep these clients
for years.
Can you please elaborate on "cultural problems "? Not sure am getting
it...
On Jan 29, 2009, at 1:52 PM, Dave Malouf wrote:
Yea, I have to agree with Todd,
It sounds more like cultural problems and with execution issues. Of
course a closet filled with materials is an issue, and if you are
looking at 100's of data points, well then that is a HUGE execution
problem anyway for most projects.
Here's my concern with what you are saying Yury. It sounds like you
are resonating with what Jim says, b/c you are in pain of what
you've seen from the other side. But Jim is being quite specific
about the proper context for the methods he uses as well as for the
scale and scope of those methods. I feel you are putting "words in
his mouth" to his actual disadvantage without much experience with
what he's actually done or how's he done it.
The work environment you mention (been there, done that, change it)
is not uncommon, but also is not a given. 90% of applying UX in
tech-centric environments in evangelism and in these environments in
particular the real datapoints that are derived from observation of
users (pick a method) are even that much more important to maintain,
and consider and figure out how to bring along the biz/engineering
sides into the process instead of presenting to them from the
outside. It sounds like you just have a lot of work to do.
-- dave
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
________________________________________________________________
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
Hi Jim,
If you have a second, I have a question about your experience of RED.
To what extent do you & your team utilize scenarios as a rapid
prototyping tool?
Question also extended to Yury and others who've practiced or do
practice the RED approach.
Cheers,
Liz
P.S. My bias is that scenarios are indispensible for RED even if
there's no good or direct user research to utilize.
P.P.S. For the record, I *much* prefer this term to Genius Design,
which is far too pejorative & pretentious sounding. Hey, maybe we can
get Dan Saffer to adjust the term in his upcoming revision of
"designing for interaction"! ;)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
Hi Yury, yup, I'm sorry for my assumptions. Your writing of the
biz/dev complaints sounded like from an innie perspective, and not
the fix-it man who comes in later.
The reason you were asked to come in was not b/c of the failings of
other methods, but b/c of the failings of the teams who executed
them. Your methods worked. GREAT! But that is probably b/c of You and
not necessarily comparative to the methods.
I have gone into many an org as an innie and gotten great results by
applying context-initiatived user-centered methodologies built on a
solid foundation of observation before design. Did it happen over
night? HELL NO! But I worked within the communication culture of
those organizations evangalizing and taking small steps before big
steps often on my own time and initiative, proving results, gaining
respect and understanding, teaching stakeholders and including them
along the way so that my methods were completely transparent and
eventually were points of collaboration.
So that was the basis for my reaction. I'm not saying you don't
kick-ass. I'm sure you do. But I was challenging your observation as
a manifestation of a broader and otherwise different problem than the
one you are stating to substantiate the value of your practice
overall.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
On Jan 29, 2009, at 2:24 PM, Jim Leftwich wrote:
> RED is, indeed and primarily, focused *on* the skills and
> experienced-gained judgement of its practitioners, and not on any
> particular methodology (as many are employed in ad hoc and
> overlapping manners, according to the potentially wide variance of
> situation and project being pursued).
As is Scientology and Amway. (And Christianity, Hinduism, Buddhism,
Judaism, Islamism, Trader Joesism, and Pythonism.)
Jim, I think I've got it now. It sounds like you've got religion.
That's great. It looks good on you.
I'm what our new President refers to as a "non-believer".
I respect your right to worship in a way that works for you.
I think that's where I come out in this discussion.
Jared
Jim, its funny that you wrote this now. When I was speaking to my
students today, I didn't use the same phrase you did, but I said I
was really having trouble with the conversation b/c there was
definitely a "you are from Mars, i am from Venus" dynamic going on
here.
your descriptions are getting clearer which is hopeful to the
conversation. I'm glad we are getting a chance to push you to try
and translate what you do, think so that it can be articulated among
the tribe.
I still find it very problematic that your rhetoric is basically
saying, "I can't tell you what the Matrix is, i can only show
you." For someone such as much from Venus, this is very difficult to
swallow, but I'm seeing more glimpses through the dense fog here
among the 2nd planet.
I did say some stuff that I didn't see responses to that I'd like
to understand more of.
1st, when I say "just", that isn't to devalue it, but to express a
simplification, or a sense of "Oh! this isn't as complicated as I
thought it is." But obviously, you responded by thinking that it is
indeed very complex, but still with no way of expressing that
complexity other than to say, a) it is complex; b) i can't explain
how; and c) only experience can guide you.
2nd I asked about the 3 phases and I tried to reflect that in my
understanding of them they sound like standard (is that better than
"just") design practice found at most every studio I've worked in
or had as a consultant, except there were 2 or three distinct
deliverables or action or thought processes missing. a) a distinct
iterative ideation process (usually filled with sketching, separate
from model prototypes in the Buxton sense of it); and b) a foundation
of articulated strategy which is bound in narrative (much like Liz is
alluding to with scenario development, but there are other methods to
developing narratives).
Again, in the midst of a pretty standard ID education system that
does teach thinking, judgetment, creativity skills over standard rote
methodologies, I get what you are saying. So the I'm left thinknig
that the rapid had specific requirements that envalue the expert, and
the expert needs a system around it to build a team with (thus the
apprenticeship model of education). lastly, in design scenarios where
the projects are longer (on end of months or years) these methods are
not quite as practical, but the standard (from my minds eye) design
practices still apply and can be easily expanded upon and even useful
for adding more observed experiences to use as a muscle tool for when
the rapid is required again. Or are you saying that rapid is always
in play and if it isn't rapid it is just plain wasteful and possibly
detrimental to the results/outcomes of the projects?
-- dave
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
Awe! Jared, that was a tad harsh, even for you. ;-)
As a zealot in my own right, I respect belief. And belief's can be
described, and any belief worth's it salt can be evangelized (i.e.
taught) in many ways.
-- dave
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
On Jan 29, 2009, at 7:18 PM, Dave Malouf wrote:
> Awe! Jared, that was a tad harsh, even for you. ;-)
All I can say is, it's been a long journey. :)
> As a zealot in my own right, I respect belief. And belief's can be
> described, and any belief worth's it salt can be evangelized (i.e.
> taught) in many ways.
I have nothing against belief or zealotry.
My point was more that Jim is asking me to accept his belief, on
faith, that there is something to RED that is different than the
standard way we design. And I'm not there yet.
The way he and Yuri describes it is tribal. You have to be in the
tribe. Not everyone is in the tribe. People not in the tribe don't
"get it."
To me, it's still smart-and-experienced-people-doing-good-work. Other
than that, I don't "get it."
So, I must not be in the tribe. I don't have the faith.
I have no problem with his tribe or faith. I'm just not there.
That's all I'm trying to say. Sorry if it sounded harsh.
Jared
[Sorry, Yury. Spelled your name wrong the first time.]
On Jan 29, 2009, at 7:18 PM, Dave Malouf wrote:
> Awe! Jared, that was a tad harsh, even for you. ;-)
All I can say is, it's been a long journey. :)
> As a zealot in my own right, I respect belief. And belief's can be
> described, and any belief worth's it salt can be evangelized (i.e.
> taught) in many ways.
I have nothing against belief or zealotry.
My point was more that Jim is asking me to accept his belief, on
faith, that there is something to RED that is different than the
standard way we design. And I'm not there yet.
The way he and Yury describes it is tribal. You have to be in the
tribe. Not everyone is in the tribe. People not in the tribe don't
"get it."
To me, it's still smart-and-experienced-people-doing-good-work. Other
than that, I don't "get it."
So, I must not be in the tribe. I don't have the faith.
I have no problem with his tribe or faith. I'm just not there.
That's all I'm trying to say. Sorry if it sounded harsh.
Jared
Liz, we absolutley make use of scenarios. We've done this in-depth
in projects where we were developing OS-level frameworks for mobile
phones (i.e.: not simply single apps, but OS frameworks for all
subsequent common interface elements and interactions for associated
apps). These include both types of users as well as types of tasks
or goals.
It varies from project to project how incorporate this into the
project beyond pantomiming in order to test our assumptions during
the development of interactional architecture, interrelationships,
archetypal elements, and flows. We have included these in
deliverables in order to contextually explain how certain needs will
be served, and sometimes it's just how we speed up our own thinking
and decision-making.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
(Duplicate post, created by browser hanging error)
I think everything I and my co-designers have done in our careers have
been about creating the very best and ambitiously successful products,
software, and systems in the shortest period of time and in the most
efficient way - as opposed to belief systems or dogma. Our methods
are not random, mysterious, secret, nor willy-nilly. There is
actually a great deal of consistency in our approach, use of design
tools, and thoroughness of deliverables and implementation success.
To downplay the designer and team skills involved in being able to
undertake these projects with a great deal of success, and the way in
which RED practice made this possible, is to miss the entire point.
We don't place our primary focus on terminology and process. We
focus on how effectively we can, though acquired skill, visualize the
dynamic elements, interrelationships, and associated interactions of
function and usage in the probems we're approaching. This isn't
done through reductionistic methodology. RED makes use of a range of
tools to augment designer understanding, insight, and patterned
problem solving.
If designers are happy and successful using the types of
methodologies that have gotten a lot of exposure and discussion, then
that's absolutely great. RED is it's own philsophy and practice,
not a reactionary response to other approaches.
In other words, there's no inherent conflict as far as I can see.
At least I'm not here to discuss issues with other approaches to
design. I'm here to describe how RED is practiced, and describe the
kinds of environments in which it's uniquely suited to produce
effective results in a wide variety of situations and circumstances
(big change needed or complex project, with little time and/or
constrained resources).
This covers an awful lot of real world situations in need of
excellent and effective design.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
On Jan 29, 2009, at 8:59 PM, Jim Leftwich wrote:
> To downplay the designer and team skills involved in being able to
> undertake these projects with a great deal of success, and the way in
> which RED practice made this possible, is to miss the entire point.
>
> We don't place our primary focus on terminology and process. We
> focus on how effectively we can, though acquired skill, visualize the
> dynamic elements, interrelationships, and associated interactions of
> function and usage in the probems we're approaching. This isn't
> done through reductionistic methodology. RED makes use of a range of
> tools to augment designer understanding, insight, and patterned
> problem solving.
Amen, Brother!
Roger that
On Thu, Jan 29, 2009 at 9:41 PM, Jared Spool <jspool at uie.com> wrote:
>
> On Jan 29, 2009, at 8:59 PM, Jim Leftwich wrote:
>
> To downplay the designer and team skills involved in being able to
>> undertake these projects with a great deal of success, and the way in
>> which RED practice made this possible, is to miss the entire point.
>>
>> We don't place our primary focus on terminology and process. We
>> focus on how effectively we can, though acquired skill, visualize the
>> dynamic elements, interrelationships, and associated interactions of
>> function and usage in the probems we're approaching. This isn't
>> done through reductionistic methodology. RED makes use of a range of
>> tools to augment designer understanding, insight, and patterned
>> problem solving.
>>
>
> Amen, Brother!
>
>
> ________________________________________________________________
> 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
>
Religions, tribes or mindsets -- either way, I think this discussion
is digging its way towards one of the deepest issues in interaction
design: Personal vs impersonal.
Traditional design disciplines have had some 100 years (or much
longer, if we consider architecture) to grow systems of practice and
education from the root assumption of design ability as something
personal. Hence portfolios, master/apprentice learning, criticism,
and so on.
Human-computer interaction, which forms the other main intellectual
tradition of interaction design, started out in the late 70s as a
scientific endeavor based in experimental psychology and engineering
science. Here, design is necessarily impersonal. The focus is on
acquiring general knowledge and communicating it in methods,
guidelines, etc.
Interaction design practitioners, scholars and teachers are feeling
the effects of this mongrel heritage every day. Yet it is not always
articulated as clearly as in the recent discussion on RED.
--------
Quite a bit of the discussion on RED seems to consist of HCI-type
questions being asked to a traditional-design-based approach. I am
not sure we can expect a lot of progress from that kind of
discussion. Indeed, some participants now seem to dismiss the thread
as a religious war.
However, there is at least one question I would like to ask Jim from
within a traditional-design perspective.
A general problem in developing design ability is the relative
inefficiency of the learning process. Apprenticing and peripheral
participation is the most common strategy and it generally takes a
long time to reach expert levels of experience and performance.
Does the RED approach contain any provisions for increasing the pace
of learning? Do you work systematically with product reviews and
criticism in your teams? Do you have procedures for debriefing and
knowledge sharing after project milestones and completions? How are
you working with conceptual tools for articulation of practical
knowing, such as patterns or experiential qualities?
I can't seem to find any references to learning and scaffolding of
expertise development in your posts so far.
Jonas Löwgren
Elizabeth,
As always the answer is - it depends...:) .. For lack of time I can
only broadly 'sketch' what happens with scenarios in the context of
our work - if we are calling 'scenario' the same thing...
Keep in mind that everything in our world is considered through a
tight lens of time-budget-expected/desired outcome... so here are a
few basic points:
- Often there are a bunch of "use-cases" delivered by the engineering
team during the Discovery phase(as ppt, printed pages etc).
- There is a quick review and analysis of these, we attempt to answer
questions like: are these cases accurate? are they really relevant?
Do they address what application and users are supposed to do? ... a
lot of decisions here are dictated by what we already know, or
learned from engineering team and from user interviews that often
run in parallel. When client has nothing, no scenarios , no
documented use cases -- we create all from scratch (there is a
positive and negative side to it)... we do it quickly and to a
necessary degree (based on Lead designer judgement)
- Based on that analysis there could be a quick preliminary clean-up,
compression (out of 10 use cases only 1-2 may be really important,
relevant) or there could be some important scenarios missing ... or
there could be a partial reframing of scenarios... Quick diagrams are
created, discussed with client to make sure that we are on the same page
- In the following Conceptualization phase there could be a complete
rethinking of scenarios, and new scenarios (flows) created..
- If new proposed flows are so radically different - then we may
create a very rough click-through and run very limited tests with users
Again - most of it decided on the fly and based on lead designer
judgement...
- After detailed wireframes are completed there is typically a quick
walk through with 2-3 users representing major user profiles/
personae ... this helps to quickly uncover small or secondary issues ...
hope this helps,
Yury Frolov
Design Director, Studio Asterisk*
GUI Strategy | User Experience | Brand
415 374 7478 voice
702 446 7840 fax
www.studioasterisk.com
On Jan 29, 2009, at 5:08 PM, Elizabeth Bacon wrote:
Hi Jim,
If you have a second, I have a question about your experience of RED.
To what extent do you & your team utilize scenarios as a rapid
prototyping tool?
Question also extended to Yury and others who've practiced or do
practice the RED approach.
Cheers,
Liz
P.S. My bias is that scenarios are indispensible for RED even if
there's no good or direct user research to utilize.
P.P.S. For the record, I *much* prefer this term to Genius Design,
which is far too pejorative & pretentious sounding. Hey, maybe we can
get Dan Saffer to adjust the term in his upcoming revision of
"designing for interaction"! ;)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
________________________________________________________________
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
Jonas Löwgren writes: "However, there is at least one question I
would like to ask Jim from within a traditional-design perspective.
A general problem in developing design ability is the relative
inefficiency of the learning process. Apprenticing and peripheral
participation is the most common strategy and it generally takes a
long time to reach expert levels of experience and performance.
Does the RED approach contain any provisions for increasing the pace
of learning? Do you work systematically with product reviews and
criticism in your teams? Do you have procedures for debriefing and
knowledge sharing after project milestones and completions? How are
you working with conceptual tools for articulation of practical
knowing, such as patterns or experiential qualities?
I can't seem to find any references to learning and scaffolding of
expertise development in your posts so far."
My responses to Jonas Löwgren (Part 1 of 2):
Jonas makes some very thoughtful observations and raises a number of
important questions. These are very helpful in delving deeper.
Q:
Does the RED approach contain any provisions for increasing the pace
of learning?
A:
In the same way that Marine Basic Training produces a lot of physical
and mental conditioning in a relatively short time frame, so do the
crucibles of RED consulting projects present young apprentice
designers with much larger demands than are found in typical
structured corporate settings. There are always, in the projects
I've been involved with and that I've observed, frequent group
review and brainstorming and whiteboarding. It's very important
that the thought processes of the seniors take place in front of and
in collaboration with the junior members (if a team setting). Often
projects will begin with the review (individually and as a group) of
an existing product, software, service, or system. Seniors usually
start out by establishing (from experience) some starting directions
and ideas, and using this as an opportunity to explain in depth past
similar experiences and designs. We will often as part of this
process bring out extensive past project documentation and show what
parts may be similar, what aspects may differ, and discuss in great
depth the lessons learned.
Dialog is constant with young designers. In our experience, some
young designers merely watch and take direction to begin with. As
time goes on, it's also common for particular talents and
capabilities to emerge, and those are reinforced and used as part of
how we divvy up the developmental responsibilities.
Junior teammembers are compelled to defend their ideas, and I believe
the best master designers are very respectful toward these, and seek
to draw them out and challenge them to both think bigger at times,
and other times focus in.
RED projects are like gyms. Designers that work on them are
exercised in their skills, and in broad-based consultancies, they're
exposed to a wide range of products, software, services, and systems.
So it's like cross-training. RED apprentices, junior designers,
associates, and seniors are always stretching and pushing. Because
the situations and environments that RED tackles require a lot be
accomplished in a short period of time. (Actually, over the past
twenty years, the average time frame of a design project has steadily
and dramatically shortened. However the complexity of the projects
has often grown larger. In other words, many projects seem nearly
impossible. This is where RED goes to work and succeeds - in our
documented experiences.)
It is my opinion and observation that designers who work with
experienced RED practitioners and teams grow faster and more broadly
and integrative in their skills and experiences than they might in
other, more constrained, structured, managed and process-oriented
design environments.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626
My responses to Jonas Löwgren (Part 2 of 2):
Q:
Do you work systematically with product reviews and criticism in your
teams?
A:
Yes, absolutely. We all constantly test and play with all manners of
things. We pass things around and take turns trying out things. And
we talk constantly about these things. Knowing about how things work
and behave is our lifeblood. We also keep abreast of a number of
industry and market trends and track a number of competitive fields.
We don't do this formally. We do this informally and constantly.
We also pay attention to our initial observations and first
impressions of things we analyze. Contrary to the often-repeated
warning that we're somehow not "regular people," we often discuss
the importance of being able to understand and empathize with the
non-expert lay user, and I believe it's possible for designers to
develop that empathy and ability. It really is possible to put
oneself in the shoes of a range of users. It's partly the lifelong
job of good designers to be astute observers of people, and pay
attention to them when they're using many kinds of things. A good
deal, and perhaps a huge majority of what makes all manners of things
easily usable are common, not specific. There are qualities that can
be imbued in any interactive design, whether a product, software,
service, or system that will benefit users. Easy to recognize and
learn patterns, minimal navigational load, and dozens of other things
we see again and again across many projects.
We have many years of experience in designing small devices and
systems, and playing with existing products along with our own which
we've had become real, have taught us a lot. We look for
opportunities to transmit this to our junior associates in as many
ways as we can.
We also do a lot of critiques of our iterative designs. We certainly
do walkthroughs of our designs periodically to keep everyone in synch.
This is necessary because there are times we'll go off and work on
certain portions of a project and we'll periodically come together
to integrate and reconcile our patterns and interrelationships for
consistency and simplification. Our goal is the most minimal and
fully functional elegance, with the fewest elemental archetypes and
interactions.
I've done this alone, and it simply takes longer. Multiple
designers can power through a lot of options and alternatives much
faster, if they're practiced at doing this and working productively
together. There are certain co-consultants I work with where we
speak in a dense shorthand, and can work through incredibly complex
problems and solution spaces quite quickly because we share a very
extensive language of concepts, models, and shared experiences.
Q:
Do you have procedures for debriefing and knowledge sharing after
project milestones and completions?
A:
Yes. We generally compile a lot of documentation from our projects.
This is then reviewable and can be compared to the same from other
projects. We also often have real production embodiments to work
with at certain milestones, so we pound on that pretty extensively,
and will often grab people nearby to do the same, noting their
feedback. More often than not, our designs work as we assumed they
would. We use feedback to tweak the results. I don't recall ever
having to start over, or make a drastic change of course. Our paper
design process leads to strong confidence of how things will work,
and we work close enough with engineers (either on our team or with
clients) to know that the behavior can be achieved as we intend
before we move forward.
Q:
How are you working with conceptual tools for articulation of
practical knowing, such as patterns or experiential qualities?
A:
We use a combination of the type of paper maps, flows, and
element-perfect (and later pixel perfect or CAD-perfect) specs along
with copious narrative descriptions and creative ad hoc use of
metaphors. Our discussions are actually very much like strings of
mixed metaphors, and this is a great aid in expressing complex and
interrelated concepts .
It's actually here where I think language is a very imporant skill
and talent for RED practitioners. Some of the best RED practitioners
I've known came from writing and film backgrounds, which is not
surprising. They understand flow and narrative, which are both
important components of effective interaction design.
Interaction design, unlike industrial design, graphic design, or
building architecture, is difficult if not impossible to "capture"
in an image or text description. The quality of any interaction
design (beyond what's in the minds of the designers), must be used
and discovered by others. We've found that some designers are much
better at grasping and growing in interaction design skill. There
are some young designers that after one project I know for certain
that there is a very valuable master designer within them, waiting to
evolve. Discovering this, is without a doubt, the most exciting and
satisfying discoveries I ever make. You just look at a designer and
watch their thought process and think to yourself - they've got it.
And yet they'll have to work hard to develop it. That's how RED
rolls.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37626