While our work may not be as life and death as a surgical procedure, I
think we still want to know what we're doing. We need to have a language
that adequately describes our tools, techniques, and processes. That's
why I think defining these things are important.
Though our risks may not be life threatening, they are certainly real
risks and likely financial risks (which can have direct impact on our
employment status). Just wanted to point this out in case anyone thinks
their job is less important because they don't get to kill someone if
they screw up or don't care what their design approach is...
In the previous discussion of ACD versus UCD on this list, the focus has
been defined simply: Someone practicing ACD focuses on the activities of
the design, where someone practicing UCD focuses on the users.
First, the name of these two approaches doesn't help much in clarifying
their application. Because ADC doesn't have user in the name doesn't
mean it doesn't consider the user at all; it just focuses on the
activities of a user, rather than their ultimate goals and needs (which
is what UCD preaches). But I'm not going to get into that.
ACD focuses on the activities of users, UCD focuses on goals and
preferences of users. ACD focuses on user activities looking at them
(and talking about them) from the system perspective (mostly - there are
no absolutes); UCD looks at (and talks about) activities from the user
perspective (mostly - there are no absolutes). I had to type and read
this 5 times to make sure this made sense, but I think I am conveying
the difference as I see it.
Dan Saffer differentiates ACS and UCS in his Designing for Interaction
book very similarly/succinctly. His best point is that the PURPOSE of an
activity is not necessarily a user goal, meaning looking at a design
problem with a user goal in mind may be too esoteric and not necessarily
helpful (which is the pro argument for ACD).
I agree with that. He also says sometimes user goals and purpose of
activity can be the same. I also agree with that. To me these are
determining factors in terms of choosing a design approach.
How far removed from the ultimate user goal/ambition is the step/thing I
need to design? The more layers of abstraction between the atomic tasks
or set of tasks that represent an activity and the end goal for the
user, more helpful a UCD approach. The less abstract/more direct, more
helpful ACD.
<-- ACD usefulness grows
focus on ACTIVITY -------------------- focus on USER GOALS
UCD usefulness grows -->
If one asserts that UCD is a collection of activities that go beyond
ACD, looking at the goals, needs, and context of the user, beyond just
that of the underlying activities, then I would say that ACD is...
... just a lazy man's UCD.
I think I agree with that statement.
0) Unintended Design:
1) Self Design:
2) Genius Design:
3) Activity-Centered Design (ACD):
4) User-Centered Design (UCD):
0 > 1 > 2 > 3 > 4 = Time spent learning about user.
As you said, I don't think we can/could map success to this progression
(even knowing all approaches have successes). I.E: in genius design,
past experience may be a key success factor.
I do think that the complexity of the system (not sure that's the best
way to talk about it but...), meaning the 'distance' between the atomic
tasks a user has to perform and the ultimate goal they are trying to
accomplish, can help determine which is the best approach (and by best I
meant the most likely to be successful). In trying to predict what
approach would be most successful for a given situation in order to tell
a team how to tackle a project, I'd start by taking a pass at trying to
outline user end goals.
For example: Trying to design a cappuccino maker. Goal: Drink coffee
with x characteristics. It's a good, concrete, an fairly narrow *goal*
that is not far removed from the *activity* of making coffee itself. I'd
say, ACD would have better odds.
For example: Trying to design a way for people to feel confident about
their financial choices. It's a good, concrete, and fairly broad *goal*
that is possibly very removed from the *activities* involved in making
whatever financial choices are available to them. I'd say, UCD would
have better odds.
(An additional point: defining the problem you are trying to address is
so key in determining the design approach, that because many start with
fuzzy and unclear projects, they default to UCD because certain UCD
methods are really good at clarifying things and help frame the problem
you are trying to resolve).
My argument was that
UCD isn't the goal for teams -- instead, having a rich toolbox filled
with techniques and tricks (that the team knows when and how to use)
should be the goal.
In my head, being able to choose the approach, ACD or UCD, is part of
the idea of having a toolbox. If you start out as an ACD or UCD advocate
in the first place, you are already discarding the notion that there are
other things in the ubber-toolbox (and other ways to think about a
problem) that may better serve you.
So, (and I think we are in agreement), yes, UCD can be perceived as a
poorly executed dogmatic approach (and so can any other approach), if it
turns out it's not what you needed.
So, that's where I'm at with regard to ACD. It's a modern-day approach
to task analysis and design. It has its place, but isn't the only
solution. It can produce success when the design team only needs to
consider the underlying activities.
"design team only needs to consider the underlying activities" which I
read as "the problem space is pretty much defined and the atomic tasks a
user has to perform are not that far removed from a successful outcome.
To your point, how do you get to that? UCD *generally* offers good
methods for that, which is why I think many default to UCD.
Hope that made some sense...
PS: Where do you put Systems Design in your list Jared?
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [EMAIL PROTECTED]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
