why the hate-on User-centered Design? (waspractice vs. discipline & roles vs. people

7 Oct 2008 - 5:41am
5 years ago
7 replies
863 reads
Peter Boersma
2003

Jonas wrote:
> What Andrei does, if I read him correctly, is to identify a few of
> the things that are considered fundamental in design practice and
> scholarship within the design field -- craft skills to do with
> sketching, shaping and assessing -- and translate them to our tools
> and materials.

Or, in short: User Centered *Design*, not Engineering.

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

Comments

7 Oct 2008 - 7:24am
White, Jeff
2007

Personally, I love UCD, even if we as a design community don't/can't agree
on what it really means. All it has meant in my career is this:

I can go to a project stakeholder, engineer, or executive, say the words
"User Centered Design" and they have somewhat of an idea of what that means.
Which more or less is that we'll end up w/ a better result if we get to know
the human beings actually using our products and design based on what we
find out, while still mixing that process with technological constraints and
business objectives. I've never had a stakeholder (or a designer) say:
"UCD?! No! That means we won't consider any other factors besides just what
the user needs!!" or "No! That means we can't sketch or prototype, or write
web standard front end code". Come on, people :)

The bottom line for me is that UCD, or at least the way it's understood by
the non-design community, makes products better most of the time, period. I
really don't care whether or not the definition of UCD includes sketching,
modeling or prototyping, or if the design community wants to get into
semantic debates about what it is and isn't.

Jeff

7 Oct 2008 - 11:11am
adamya ashk
2004

On 10/7/08, Jeff White <jwhite31 at gmail.com> wrote:
> Personally, I love UCD, even if we as a design community don't/can't agree
> on what it really means. All it has meant in my career is this:
>
> I can go to a project stakeholder, engineer, or executive, say the words
> "User Centered Design" and they have somewhat of an idea of what that means.
> Which more or less is that we'll end up w/ a better result if we get to know
> the human beings actually using our products and design based on what we
> find out, while still mixing that process with technological constraints and
> business objectives. I've never had a stakeholder (or a designer) say:
> "UCD?! No! That means we won't consider any other factors besides just what
> the user needs!!" or "No! That means we can't sketch or prototype, or write
> web standard front end code". Come on, people :)

Yes, yes, yes! Finally, there is light at the end of the tunnel...did
I say tunnel, I meant thread...yes thread. :-)

> The bottom line for me is that UCD, or at least the way it's understood by
> the non-design community, makes products better most of the time, period. I
> really don't care whether or not the definition of UCD includes sketching,
> modeling or prototyping, or if the design community wants to get into
> semantic debates about what it is and isn't.

Not just for you, this is the bottom line for many many of us. The
semantic debates points to just one thing, that perhaps the external
world has an instinctive grasp of UCD which we are not comfortable
with (?).

All I know is that as a body of professionals involved in the common
good, we have got to stop questioning our selves on what we do, how we
do it, what we call ourselves and what roads best lead to the goal.

-Adamya

7 Oct 2008 - 2:01pm
Robert Hoekman, Jr.
2005

>
> I've never had a stakeholder (or a designer) say:
> "UCD?! No! That means we won't consider any other factors besides just what
> the user needs!!" or "No! That means we can't sketch or prototype, or write
> web standard front end code". Come on, people :)

Fantastic point.

Following that logic, why do we bother naming things at all? Why not just
say we need to do "interaction design" to increase a product's chances of
success?

Do we really even need all these named approaches in the field of design?
I've never heard someone ask which approach I use. Not even my clients.

In the development world, the differences between Waterfall and Agile are
very clear and easy to spot and explain. In design, however, the differences
are very often significantly less clear, and I'm not sure anyone cares
anyway. All we really need is to be able to prove that interaction design
makes things better, and that we can do it within a reasonable cost and
time, and can repeat our success.

Come to think of it, didn't this whole problem start with Cooper? Wasn't he
the guy that coined the term "interaction designer", thereby creating a
split between the idea of an designer and the designer's approach and
toolset? (And if so, did he do it just to legitimize GDD?)

(Playing devil's advocate here, by the way. I don't know if I'm serious
about any of this thought process yet.)

-r-

7 Oct 2008 - 2:09pm
Robert Hoekman, Jr.
2005

>
> The bottom line for me is that UCD, or at least the way it's understood by
> the non-design community, makes products better most of the time, period.

(Continuing my last post ...)

UCD doesn't make things better. Designers do. I think that is what's
understood by people outside the design world. I doubt most people care what
we name our approach to design or even how we do it.

But Peter's point is very valid—that we need lines drawn between types of
design, at least to a degree. Industrial designers are very different than
graphic artists, for example, and graphic artists are very different than
interaction designers.

I know this: I've never marketed myself as an "Activity-Centered Designer".
I've marketed myself as an "interaction designer", a "user experience
designer", and a "software designer". The questions about what I do usually
stop after a basic explanation of that role.

-r-

7 Oct 2008 - 2:24pm
Dave Malouf
2005

Robert,
Interaction Design was coined by Bill Verplank and Bill Moggridge and
has nothing to do with the research aspects of IxD. It was for them
the separation of form from behavior as they worked in a world of
electrical engineers, software engineers, mechanical engineers and
industrial designers.

IxD is not the first not all encompassing design discipline and I
hope it is not the last. Service design is a nice one too!

(but this is a tangent)

Back to the point you were making. I don't think "design" by
itself is a useful or practical term, but when I talk about what I
do, I often couch it in terms of product, or to be more exact
something tangible. I'm a software designer is usually what comes
out of my mouth when I'm out with my Wife's friends. They often get
it, but often add engineering to what they think I do.

this weekend I was with a group of people telling them about my
upcoming position at SCAD and they had blank looks. I told them, I'm
the person who says the "Send" button goes on the screen above AND
below your email and then what happens after you click it. They got
that. I said, "though, I"m not the person who says what color it
is, or necessarily its exact layout". They understood that
separation as well when explained.

These separations though ONLY exist in OUR world and are pretty
meaningless to lay people. I.e. a patient doesn't care that there is
a specialist in Ear, Nose & Throat until they need one. I don't know
I need an expert in Interaction/behavior until I need one.

But for us ... its all the difference in the world.

-- dave

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

7 Oct 2008 - 2:35pm
Chris Hunter
2007

On Tue, Oct 7, 2008 at 2:09 PM, Robert Hoekman Jr <robert at rhjr.net> wrote:

> >
> > The bottom line for me is that UCD, or at least the way it's understood
> by
> > the non-design community, makes products better most of the time, period.
>
>
> (Continuing my last post ...)
>
> UCD doesn't make things better. Designers do. I think that is what's
> understood by people outside the design world. I doubt most people care
> what
> we name our approach to design or even how we do it.

I agree whole-heartedly with you here.

> But Peter's point is very valid—that we need lines drawn between types of
> design, at least to a degree. Industrial designers are very different than
> graphic artists, for example, and graphic artists are very different than
> interaction designers.

But feel like we were reading different posts here. I read Peter M.'s post
as more distinguishing bad design (i.e. ignores the user as a constraint of
a design problem) from good (weighs the user's needs and other inputs and
creates an appropriate design). But that doesn't fundamentally change that
industrial, graphic and interaction designers all engage in the same basic
activities (quoting Andrei):

1) Define and understand the problem in relevant terms

2) Solve the problem elegantly

Personally, I'm going to embrace any tool that helps me in those two tasks.
But I'll also set any tool or process aside the minute I feel like it's
holding me back.

Chris Hunter

7 Oct 2008 - 7:53pm
Jarod Tang
2007

Hi Robert,

For e.g., "the elements of users experience", put the different design
into a hierarchy of different design ( strategy design, information
design, interaction design and visual design, etc). Which may scared
the product producer, "do i really need such kind of Ds?", and as
well, this also makes designer in wild, "how could i put so much Ds in
my tool box to make myself capable?". And i guess this is one of the
cause why so many guys cant agree with each other on how ixd should
be, or UX should be?

Maybe the answer is simple and straight, the goal is something to be
used in user's everyday life, and the aim is to make people get goals
easier, happier etc. And back from this goal and aim, all the related
Ds can be considered as a design problem solving method/tool-box which
is ready for designer's use. Or even better put them into some method
cards with smart questions ( as IDEO does) , to make this fun and
fruitful. Maybe forget the names, not very bad, cause only results
that counts.

For a design domain ( according to the Science of Artificial),

0.The goal/definition part
What's the problem the design seek to solve? I should/better address
the dirven problem the design domain target (better than name it by
major method or process).
>From this perspective, ACD is more target to the method (not so good),
UCD as well has a distance to the driven problem. [suggest first
clarify this problem, then maybe the better name follows].

1. The evaluation part
How to to say if the design solution/artifact is good or bad?
What's the criteria to for the evaluation ? [we can say it's good by
this, that or something else]
What's the pragmatic of evaluation by logic ? [ first what, then what]
2. The design solution searching
What';s the searching strategy ? [e.g. prototyping, existing product analyzing,]
How to arrange the searching steps? [ first what, then what. GDD or
similar things]
How to represent/sketch the solution? [ wireframe, screen layout, and
related stuffs]

On Wed, Oct 8, 2008 at 3:09 AM, Robert Hoekman Jr <robert at rhjr.net> wrote:
>>
>> The bottom line for me is that UCD, or at least the way it's understood by
>> the non-design community, makes products better most of the time, period.
>
>
> (Continuing my last post ...)
>
> UCD doesn't make things better. Designers do. I think that is what's
> understood by people outside the design world. I doubt most people care what
> we name our approach to design or even how we do it.
>
> But Peter's point is very valid—that we need lines drawn between types of
> design, at least to a degree. Industrial designers are very different than
> graphic artists, for example, and graphic artists are very different than
> interaction designers.
>
> I know this: I've never marketed myself as an "Activity-Centered Designer".
> I've marketed myself as an "interaction designer", a "user experience
> designer", and a "software designer". The questions about what I do usually
> stop after a basic explanation of that role.
>
> -r-
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
http://designforuse.blogspot.com/

Syndicate content Get the feed