[IxDA Discuss] ACD (was ...companies actually using UCD)

[Robert Reimann]

 I've kept out of the ACD discussion until now, but think there are some
important points to make regarding its relation to UCD methods, especially
Goal-Directed Design. If you read Don Norman's description of ACD carefully,

there are some very specific assumptions that are prerequisites for ACD
really
working. The most important is this: that the activity is very well
understood a priori.

Norman uses driving a car as an example. That activity is certainly well
understood by now, as Norman claims. But let's not forget that the way
it became understood was through a history of design issues that may have
cost
either lives or profits to auto companies (or both). Implicit in the auto
example
(and many of Norman's other examples) is that activities actually
*do* change: the difference is that they do so on an "evolutionary" time
scale
based on "natural selection" in the market over time.  The path to
good products using this method is littered with generations of partial
and complete design failures. The whole point of UCD and GDD (lest we
forget)
is to shortcut this slow, innefficient, and terribly costly process by
understanding what the product really needs to do *before* it gets built.

Many organizations don't understand the value of UCD/GDD because they
*don't believe* answers to questions about product use can really be
answered before a product exists. This is where IxD clients often need
the most education. Risk mitigation is thus a huge value of UCD methods,
but is perhaps more valuable in the world of physical products than in the
world
of web services, where updates and upgrades are often a constant, fluid
process.

For basic web transactions, it is arguable that we have a good understanding
of the main activities. But as soon as those transactions are assembled into
more complex and domain-specific contexts (e.g., an ERP purchasing app,
for example), that argument becomes strained.

 Norman also uses art and music as activity examples: people learn an
instrument or art
tool/technique, even though it is difficult to do. The same can be said for
mastering
a video game. These are interesting examples, but they really point to the
need to
understand the motivations behind the activity: the goals. This is key to
understanding
when an activity should be challenging vs. when it should be simple and
intuitive.

Understanding user goals gives you a shortcut around the long process of
tool
evolution, because even though technology changes and evolves all the time,
the human motivations that drives that evolution seldom do. Create a tool
that
achieves goals in the ways most appropriate to the context, and you have a
design success. Yes, there are disruptive technologies that change expand
the
range of possible goals and expectations... but they are the exception, not
the rule,
and even then, some thinking about what those goals might be is worthwhile.

Understanding goals also lets you know where to leave well enough alone:
where
people don't have an interest in making things faster or more efficient, but
instead
have other priorities. Goals, incidentally, also give you a window into
understanding
people *affected by* technology, who are not necessarily the actual users,
and
don't have activities directly associated with the technology affecting
them.

Norman states: "Great design, I contend, comes from breaking the rules, by
ignoring the generally accepted practices, by pushing forward with a clear
concept
of the end result, no matter what. This ego-centric, vision-directed design
results in
both great successes and great failures. If you want great rather than good,
this is
what you must do."

I would argue that understanding human goals in the context of products and
systems
provides the clear vision of the end result that Norman finds elusive, while
significantly
mitigating the risk of failure.  I believe that this understanding comes
from well-developed
user models that capture the essence of human behaviors and motivations
pertinent to the
design problem at hand.

Goal-directed design is all about design vision, but not the vision that
comes from
the designer's ego (which can be a well-intentioned path to trouble).
Instead, it
comes from designer *empathy* with the needs and goals of real people,
encapsulated
in distilled form by personas. Norman doesn't think personas (at least not
as he
characterizes them, which lack utility because they lack goals) are directly
pertinent to
design: I don't see how they *can't* be.

Norman says we listen too much to users, and that designers need to take
command and do what they understand to be best. When you literally ask a
user
what they want, and then try to deliver it verbatim, you are abdicating your

responsibility as a designer (here I believe Norman and I agree). You must
read between the lines to discover goals, do your due diligence to make sure

you have found "common" goals rather than the idiosyncratic quirks of the
individual, and base your design effort upon this knowledge, carrying it
through
to activities, tasks, and beyond. And that is the essence of goal-directed
design.

Robert.

-- 

Robert Reimann
President, IxDA

Manager, User Experience
Bose Corporation
Framingham, MA



On 6/30/06, Robert Hoekman, Jr. <rhoekmanjr at gmail.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Yup - great article, and concept. I haven't heard anyone talk about it at
> all, but I think it's phenomenal. It shares a lot with UCD, but strays on
> the point of creating personas and scenarios, instead saying we should
> design to support the activity itself. It helps me sleep at night.
>
> -r-
>
>
>
> On 6/30/06, Bret Hekking <bhekking at yahoo.com> wrote:
> >
> > [Please voluntarily trim replies to include only relevant quoted
> > material.]
> >
> > > Apple
> > >
> > >
> > > Didn't they get rid of their HCD team? I thought they were taking the
> > ACD
> > > approach discussed by Norman.
> >
> > ACD = Activity Centered Design
> > http://www.jnd.org/dn.mss/human-centered.html
> >
> > I'm sure I've browsed Norman's article before, but I'll have to read up,
> >
> > Thanks,
> > Bret
>