Where that ACD thing fits

10 Nov 2008 - 2:58pm
6 years ago
47 replies
3155 reads
Jared M. Spool
2003

So, I've spent much of the last month thinking about what Activity-
Centered Design (or ACD) might be and where it fits into other design
approaches. This long-winded email is an attempt to get these thoughts
out.

Before I start, the last time we went around on this, there was a
sentiment of "Who cares what we call it? My clients/co-workers don't
care what it is, as long as I produce great designs. Let's just agree
that what we do is a good thing, whether we label it ACD or UCD or
whatever."

While I agree that the outside world (that being the people who are
not UX professionals) don't necessarily need to know whether something
is called ACD or UCD, I think it's important that we're clear on what
each approach is and how it differs.

When most of go to a doctor with a serious ailment (say something
nasty like pancreatic cancer), we just want to know that the surgical
option our doctor chooses will work. We don't care whether it's a
Total Pancreatectomy, a Distal Pancreatectomy, or a Whipple Procedure.
If it makes the cancer go away and returns us to normal health, we're
happy with whatever it was.

However, I think we'd really want the surgical team to know which one
it was. The preparation, tools, anesthesia requirements, pre-op prep,
and post-op care all depend on the nature of the procedure. If the
entire team of doctors, technicians, and nurses are not on board with
exactly what procedure is happening, someone will do the wrong thing
and a life can be put in at risk. (Not 'a life'. Our life!)

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.

This is why I dislike the current term-of-art User-Centered Design (or
UCD). I'm betting that if you ask 10 UX professionals to define UCD in
depth (going beyond "designing with users in mind"), you'll get 15
different definitions. (This is something I've put on UIE's research
agenda to actually do, but we haven't gotten there yet. I'd really
like to see what happens.) There is no clear field-wide understanding
of what UCD is, which makes it very hard for us to compare notes and
discuss possible alternatives, like ACD.

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. Some have said that ACD minimizes the need of doing personas (a
'user-centered' activity) and just looks at the underlying activities
that are obvious to the design result. For example, if designing a
photo sharing site, one doesn't need to talk about whether the user is
college age or prefers taking pictures of flowers, as someone might be
inclined to fill out in the persona description. Instead, the
activities are uploading pictures, sharing pictures, downloading
various sizes, putting together a collection, etc. Look no further
than the activities and you'll have a full list of items to put on
your design plate.

At least, that's my understanding of ACD. I'm sure someone will point
out that I've gotten it all wrong, but that's where I'm starting from
here. (I look forward to the correction.)

So, given all this, here's where I think this ACD thing fits in:

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.

Now, I'm hoping that all the ACD advocates out there won't take this
the wrong way. Being lazy is pretty important. All the really good
innovations in our lives have come from a dedication to laziness. I
consider laziness, along with impatience and stubbornness, to be
critical traits of an innovation leader. So, I applaud anyone who is
creatively lazy, looking for ways reduce effort while producing more.

To this end, you can put UCD and ACD in a scale of design approaches,
which starts with:

0) Unintended Design: The design that results from teams that don't
pay any attention to design. This is the true rubber-band-and-spit
approach to creating things. Everything ends up with a design, but
not every design is intentional. Some very lucky teams end up with
successful unintended design, but the odds are against this.

1) Self Design: The design that results from teams that design purely
for themselves. (This happens more with single-person teams than
multiple-person teams.) This design approach has better odds of
success than Unintended Design, but not by much (unless the designer
is the only user, such as when a bachelor arranges the contents in
their kitchen cabinets). This design approach is only informed by the
team members own use of the design.

2) Genius Design: The design that results from teams that use their
experience at creating designs for others, without doing research.
This starts with Self Design, but extends to role playing and
consideration of users who are not quite like themselves. This design
approach is informed by previous experience the design team has with
similar work. (For example, a team that creates shopping cart systems
for many clients can reduce their research efforts with each
subsequent implementation, assuming the systems are pretty much the
same each time. Eventually, they could create very successful without
further research, since they'd basically "seen it all".)

3) Activity-Centered Design (ACD): The design that results from teams
that only research the activities. Because research is part of the
design process, it extends beyond Genius Design (which solely is based
on the team's experience). This is necessary when the activities are
new or foreign to the team. (For example, a team developing an
application for consolidating personal finances when they've never
thought about personal finances in any of their previous projects.)
Activity-based research techniques, such as workflow diagrams and task-
based usability tests would come in very handy to help inform the
teams using this approach.

4) User-Centered Design (UCD): The design that results from teams that
look beyond just the activities, to the goals, needs, and contexts of
the users. Because usage is all about activity, this approach needs to
have the activity at its core. (Early UCD definitions always included
an essential "task analysis" phase -- something that's disappeared
from the lexicon, but is still essential to this design. Task analysis
is, as far as I can tell, research about activities, and thus the core
research component of ACD.) This design approach is informed by
techniques such as field research (ethnographic techniques) and
persona creation, which help the team to see contextual items and goals.

All of these approaches are viable approaches and there are documented
successes for each (think 37Signals for Self Design and Apple for
Genius Design). However, since bad design is only retrospective
(nobody who produced a bad design thought they were doing so at the
time -- they only discovered it after the fact), the approaches are
really about increasing the probabilities of a successful design. In
each case, we're really talking about the how the experience of the
design team plays against the information needed for a successful
design. Teams that walk around with most of the information already
can get away with less new research.

This discussion started because people reacted to my "It's time we
consider retiring UCD" comment in my IA Summit Keynote [1]. There I
was referring to the dogmatic approach that too many UX professionals
take when they claim that if you actively practice Self Design or
Genius Design without research user needs, you're not doing UCD. (They
are right, but they make it sound like a bad thing.) 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 mind, the advocates of ACD are really reacting to a poorly
executed dogmatic approach to UCD. When they say, "we don't need
personas because who cares if our user is a high school student
considering an ivy league school", they are really reacting to poorly
constructed personas. [2] In a well-constructed persona description,
the team can tie every sentence to the design decisions behind it. If
they have a sentence about the student's college choices, there had
better be a design decision behind it.

(Recently, I had a client show me their persona descriptions that
talked about the car the family had and the family dog. My first
inclination was to suggest they take this information out. However,
their project was a home-improvement information site and providing
filters for pet-friendly improvement projects and easy-to-bring-home
materials was an obvious no-brainer out of this simple info.)

So, when I say the ACD advocates are being lazy, what I mean is they
are looking to avoid many of the dogmatic approaches that UCD
advocates push in their agendas. And that I'm totally in agreement.

However, it's important we don't throw the baby out with the bath
water. Research that tells us about the user's goals, their needs, and
their context, beyond those embodied completely in the base activity
can be important for many designs. Two people may use the same
functions, but from completely different contexts and for completely
different goals. The inputs, flows, and outputs might need to vary
dramatically or the design may need to be expanded to help both users,
even though the base activity is identical.

(My canonical example for this is the workstation used by a Pediatric
ICU nurse. While the base activity, say ordering a CBC lab, is
uniform, the goals -- the criticality of the infant's condition -- and
the context -- whether the nurse is long-time experienced in the ICU
or doing a short rotation -- can influence the design results
dramatically. In this instance, ACD will likely produce an inferior
design to UCD, as I've defined them above.)

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.

Unfortunately, I think they only way to guarantee success is to do UCD-
class activities to determine that goals, needs, and context aren't
going to change the design outcome. That makes it risky.

Hope this helps,

Jared

[1] IA Summit 2008 Keynote: Journey to the Center of Design
http://tinyurl.com/5kasbm
(Listen to the audio or the slides won't make sense.)

[2] Crappy vs. Robust Personas: http://tinyurl.com/2hpxzr

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

Comments

10 Nov 2008 - 8:24pm
Steve Baty
2009

Jared,

I see the choice between using ACD or UCD as being determined by whether or
not the system (product, service etc) under design substantively and
meaningfully addresses the needs of an homogeneous or heterogeneous
community of users. In the case of the former - homogeneous - collection of
users, with respect to the system, ACD is an appropriate choice; in the case
of the latter, it seems to me that UCD would be the more appropriate choice.

This may be an over-simplification of the choice on my part, and an
arbitrary dichotomy, but this is how I see the use of each design approach
playing out in practice.

Best regards
Steve
--
Steve 'Doc' Baty | Principal Consultant | Meld Consulting | P: +61 417 061
292 | E: stevebaty at meld.com.au | Twitter: docbaty

Blog: http://docholdsfourth.blogspot.com
Contributor - UXMatters - www.uxmatters.com

10 Nov 2008 - 8:30pm
Adrian Howard
2005

On 10 Nov 2008, at 20:58, Jared Spool wrote:
[snip]
> 3) Activity-Centered Design (ACD): The design that results from
> teams that only research the activities. Because research is part of
> the design process, it extends beyond Genius Design (which solely is
> based on the team's experience). This is necessary when the
> activities are new or foreign to the team. (For example, a team
> developing an application for consolidating personal finances when
> they've never thought about personal finances in any of their
> previous projects.) Activity-based research techniques, such as
> workflow diagrams and task-based usability tests would come in very
> handy to help inform the teams using this approach.
>
> 4) User-Centered Design (UCD): The design that results from teams
> that look beyond just the activities, to the goals, needs, and
> contexts of the users. Because usage is all about activity, this
> approach needs to have the activity at its core. (Early UCD
> definitions always included an essential "task analysis" phase --
> something that's disappeared from the lexicon, but is still
> essential to this design. Task analysis is, as far as I can tell,
> research about activities, and thus the core research component of
> ACD.) This design approach is informed by techniques such as field
> research (ethnographic techniques) and persona creation, which help
> the team to see contextual items and goals.
[snip]

That's the thing that's always confused me about the UCD vs ACD
discussions - I can't understand how you can separate activities/tasks
from the understanding of the user context/goals.

There always seems to be a little loop that I go around. Looking at
the activities/tasks helps get deeper into the user/context.
Understanding the users/context helps me get deeper into the
activities/tasks.

You find that one group of users is actually a couple of distinct
archetypes. Then you see that a particular goal is subtly different
for each of those two groups - and suddenly you have two different
goals with different tasks. Which lets you dig into the users
behaviour more. Repeat.

I can't see how you can be activity-centred without being user
centred. I can't see how you can be user-centred without being
activity-centred. I'd love it if somebody who has a better
understanding of ACD could explain to this particular bear of little
brain.

Cheers,

Adrian

(BTW - I _love_ the fact that "genius design" is the label for the
middle of the scale :-)

10 Nov 2008 - 8:51pm
livlab
2003

> 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?

10 Nov 2008 - 9:33pm
Jeff Stevenson
2007

Thanks, Jared. This really helps me to understand better where you
were coming from in your IA Summit keynote.

To me, the difference between UCD and ACD is mostly about WHEN, in
the timeline of a project, you start doing your research. Let me give
an example.

Let's say my client is a financial institution. They come to me
saying, "We really want to target people who are setting up their
first bank account. We're not sure how to make ourselves stand out,
so what do you recommend?." At that stage in the process, I would
definitely want to do UCD. I want to know what types of personas are
creating their first bank account. What are their unmet needs? What
do they want to do online with their bank account? What keywords are
they searching for when they research bank accounts online? etc. I
would begin with UCD.

But consider another scenario. Let's say the same financial
institution comes to me and says "I want to create an online tool
for people to check their balance, transfer money, and order more
checks." In that case, I could just begin designing a solution that
met those requirements. I wouldn't technically need to know more
information about my users to execute on that request. The
requirements have already been defined, so I would begin with ACD.

The problem is that the tool I build may or may not solve anyone's
real problem. I haven't gotten to the important questions, which
are:
- Why does the bank want to build this tool? (What is their business
objective?)
- What functions do the users want to be able to do?
- Which functions are most important?
- What would help this tool to stand out relative to the bank's
competitors?

And that's the nice thing about UCD. It puts us in the mindset that
we are solving problems, not simply executing on a set of
requirements. ACD seems to imply that the requirements are already
known. And while someone may have a set of requirements in mind, they
may not be the right ones.

So would it be reasonable to say that ACD is the logical continuation
of UCD? That is, after we understand our users' needs and wants, we
can then define which activities the users need to perform, and then
design a solution that enables those activities?

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

11 Nov 2008 - 7:57am
Paul Eisen
2007

Outstanding post, Jared. I particularly applaud your characterization
of personas, their role in guiding UCD (and distinguishing it from
ACD), and the need to focus on qualities that actually impact design.
That for me is the key to crafting a set of personas - to create as
FEW personas as is necessary to encompass all of the substantive
design-relevant qualities of the target population.

Paul

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

11 Nov 2008 - 2:01am
Adrian Howard
2005

On 11 Nov 2008, at 02:51, Livia Labate wrote:
[snip]
> 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 -->

Ah - this actually makes sense to me. ACD & UCD as different ends of a
spectrum - rather than different things.

Thank you.

Adrian

11 Nov 2008 - 8:19am
Jarod Tang
2007

> That's the thing that's always confused me about the UCD vs ACD discussions
> - I can't understand how you can separate activities/tasks from the
> understanding of the user context/goals.
>
> There always seems to be a little loop that I go around. Looking at the
> activities/tasks helps get deeper into the user/context. Understanding the
> users/context helps me get deeper into the activities/tasks.

This is a great question," I can't understand how you can separate
activities/tasks from the understanding of the user context/goals."
By it's nature, there's no so called UCD without activity analyze, and
no ACD without taking into account user's goal, context and
experience. Because the activity is a sequence of action by people for
archiving some goal ( consciously or subconsciously ) in a specific
context.
User experience is not designed but enabled by a (interaction and
related) design (we can say design for good user experience, logic
"for"), while activity lay at foundation components of interaction
design (we can say design based on people's related activity analyze,,
logic "by" ). UCD and ACD has no conflicts or at different level,
but they are just facets of one cube.
For self design and genius design, I really find it's funny, it could
be called a design method, cause they just describe the designer and
end user's role relationship, in both case, you cant avoid the points
1) design for better experience (logic "for") 2) based on activity
analyze ( logic "by" )

Thanks for the great question again.

Regards,
Jarod ( not Jared :) )

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

11 Nov 2008 - 8:30am
Jared M. Spool
2003

On Nov 11, 2008, at 3:01 AM, Adrian Howard wrote:

> On 11 Nov 2008, at 02:51, Livia Labate wrote:
> [snip]
>> 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 -->
>
> Ah - this actually makes sense to me. ACD & UCD as different ends of
> a spectrum - rather than different things.

I don't see that. You can't design with a focus on user goals without
thinking about activity. So, in my mind, they are not different ends
of the spectrum. ACD ignores goals, needs, and context, whereas UCD
does not. It's a superset / subset relationship.

Jared

11 Nov 2008 - 8:31am
Mark Schraad
2006

Another way of looking at it is this: Are you looking to drive
behavior or accommodate it? WIth functionality that is new you may
have more liberty in directing the tasks and activities. For improving
functionality that already exists, you may want to lean towards
integrating that pre-existing behavior. In this later situation, user
research becomes critical.

On Tue, Nov 11, 2008 at 3:01 AM, Adrian Howard <adrianh at quietstars.com> wrote:
>
> On 11 Nov 2008, at 02:51, Livia Labate wrote:
> [snip]
>>
>> 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 -->
>
> Ah - this actually makes sense to me. ACD & UCD as different ends of a
> spectrum - rather than different things.
>
> Thank you.
>
> Adrian
> ________________________________________________________________
> 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
>

11 Nov 2008 - 11:21am
livlab
2003

>>> <-- ACD usefulness grows
>>> focus on ACTIVITY -------------------- focus on USER GOALS
>>> UCD usefulness grows -->
>>
> I don't see that. You can't design with a focus on user goals without
> thinking about activity. So, in my mind, they are not different ends of
> the spectrum. ACD ignores goals, needs, and context, whereas UCD does
> not. It's a superset / subset relationship.

Yup, you're right. It doesn't work thinking about it as a spectrum.

12 Nov 2008 - 1:48pm
Adrian Howard
2005

On 11 Nov 2008, at 14:30, Jared Spool wrote:

> On Nov 11, 2008, at 3:01 AM, Adrian Howard wrote:
>
>> On 11 Nov 2008, at 02:51, Livia Labate wrote:
>> [snip]
>>> 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 -->
>>
>> Ah - this actually makes sense to me. ACD & UCD as different ends
>> of a spectrum - rather than different things.
>
> I don't see that. You can't design with a focus on user goals
> without thinking about activity. So, in my mind, they are not
> different ends of the spectrum. ACD ignores goals, needs, and
> context, whereas UCD does not. It's a superset / subset relationship.
[snip]

I guess this leads back to my question of not really getting how ACD
can ignore goals/needs/context - coz I don't see how you can think
about activities without having some concept, however minimal, of the
end users goals, needs and context.

It briefly made sense to me as:
* ACD = uses activity as the driver for design (supported by user
models when necessary)
* UCD = uses the user as the driver for design (supported by activity
models when necessary)

But you're right - it's subset/superset.

So... I still don't get ACD... can somebody point me to some
background reading that might clarify it for me?

Cheers,

Adrian

11 Nov 2008 - 4:38am
Anonymous

Jared your points reflect a conversation we often have here at
Clearleft. We say we do UCD, but ask ourselves do we really do ACD? I
reckon the answer is both. Or more particularly we do ACD with a UCD
wrapper. That is to say we do user research and personas, but only
enough to give useful context for the subsequent ACD.

So the research and persona development is activity-focused. It's
used to determine the activities that need to be designed and
provides the settings in which that activity might occur.

In your example of a photo sharing site, one activity would almost
certainly be to upload a photo. Our research and personas would
indicate whether users would be happy uploading one photo at a time
or whether there should be a batch (instead or as well). It may even
identify that uploading is not viable for the majority of users, and
that an alternative solution would need to be developed.

The point is that the UCD is limited to informing the ACD, thus
avoiding dogmatic processes and freeing us to be able to choose the
most appropriate tools to the job at hand.

[Expanded upon at http://clagnut.com/blog/2208/]

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

11 Nov 2008 - 10:47am
ScottL
2008

I would argue that ACD is more part of the evolution of UCD. Design is
about framing problems, and ACD is more of an evolving perspective of
UCD to frame design problems.

I would agree with following view point made
On 11 Nov 2008, at 02:51, Livia Labate wrote: [snip]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).[trim]

Fundamentally for me ACD for me draws on the principles framework set
out in Activity theory and so for this reason I would argue that it is
much more that a modern day task analysis to design. At its core
activities consist of the tools people use, the subject the people
themselves and the material object that can be tangible or totally
intangible.

There are also several interesting point made by Josha Porter on the
blog post - http://bokardo.com/archives/activity-centered-design/.

A particularly interesting point from the blog post is a point raised
by Don Norman in the article %u2018Human-Centered Design Considered
Harmful%u2019. Norman says:
%u201CMany of the systems that have passed through HCD design
phases and usability reviews are superb at the level of the static,
individual display, but fail to support the sequential requirements
of the underlying tasks and activities. The HCD methods tend to miss
this aspect of behavior: Activity-centered methods focus upon
it.%u201D

To this I would ask how much of ACD and USD methods differentiate and
overlap in design practice?

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

11 Nov 2008 - 8:12am
James Page
2008

Jared,
Great post.

I think one important difference of ACD vs UCD is that ACD has a strong
paradigm behind it. ACD comes out of Activity Theory. This should make ACD
more concrete than a UCD approach, which seams to have little of a core.

In your email you quote the following "Who cares what we call it? My
clients/co-workers don't care what it is, as long as I produce great
designs. Let's just agree that what we do is a good thing, whether we label
it ACD or UCD or whatever."

For example another approach in another industry is Agile. Just look at the
adoption... Part of the brilliance was giving a set
of practices a foundation. Most of the rules where being used already, when
the Agile Manifesto was created.

The manifesto gave agile, as Imre Lakatos (to the centre of Philosophy),
would say a core, or if you are Kuhn fan (to the left of Philosophy
) believer a paradigm. UCD lacks the core, or paradigm and therefore if you
are believe in either, Kuhn or Lakatos, or Herb Simon, UCD will be
challenged in building up a centre of knowledge, that can be expanded upon.

Just to clear up the view that ACD does not use User Research.
My business partner, Sabrina Mach explained in another email discussion,
that ACD can use it:-

For example the difference between pure ethnography and activity theory or
> distributed cogition is that ethnography is completely unstructured.
> Ethnographers start observation without any preconception, they simply
> observes and do not judge. The advantage of Activity theory on the other
> hand allows the observer to structure their observations. It focuses on the
> individual in terms of their sociality of work, members of the system,
> working division of labour, and artefacts.
>

This paper explains distributed cognition and Activity theory quiet well.

http://www.research.ibm.com/SocialComputing/Papers/CAH1.pdf
<http://www.research.ibm.com/SocialComputing/Papers/CAH1.pdf>

So in the end it depends what the aim of a study is... if you want to gather
requirements and understand behavior, AT and DCog are probably quiet good...
if you want to be able to predict how well something will work you are
better of with a method that allows more quantitative assessment.

What is reduced in using ACD is what is used to inform the design.

This ambirgurity in what is UCD in turn creates a risk for the client. If
one can not define the approach how can we compare which method is best? So
your categorization is very useful. But would it be good idea to further
refine it by looking at the stage of processes. Research, Idea generation,
Testing, Launch, and Refinement?

For example if we take your "genius" and "ACD" example where does Morita and
the Walkman fit in. He spent allot of time thinking about the Activity of
the device, after coming up with original idea. Does it need a record
button. Size: It needs to fit into a suit pocket without ruining the cut of
a jacket.

In his book "Made in Japan" that Sony differed from the American style of
design by getting to a working prototype fast, and then testing where he
said the Americans believe in doing mock ups and simulations.

James

On Tue, Nov 11, 2008 at 3:33 AM, Jeff Stevenson
<jeff.a.stevenson at gmail.com>wrote:

> Thanks, Jared. This really helps me to understand better where you
> were coming from in your IA Summit keynote.
>
> To me, the difference between UCD and ACD is mostly about WHEN, in
> the timeline of a project, you start doing your research. Let me give
> an example.
>
> Let's say my client is a financial institution. They come to me
> saying, "We really want to target people who are setting up their
> first bank account. We're not sure how to make ourselves stand out,
> so what do you recommend?." At that stage in the process, I would
> definitely want to do UCD. I want to know what types of personas are
> creating their first bank account. What are their unmet needs? What
> do they want to do online with their bank account? What keywords are
> they searching for when they research bank accounts online? etc. I
> would begin with UCD.
>
> But consider another scenario. Let's say the same financial
> institution comes to me and says "I want to create an online tool
> for people to check their balance, transfer money, and order more
> checks." In that case, I could just begin designing a solution that
> met those requirements. I wouldn't technically need to know more
> information about my users to execute on that request. The
> requirements have already been defined, so I would begin with ACD.
>
> The problem is that the tool I build may or may not solve anyone's
> real problem. I haven't gotten to the important questions, which
> are:
> - Why does the bank want to build this tool? (What is their business
> objective?)
> - What functions do the users want to be able to do?
> - Which functions are most important?
> - What would help this tool to stand out relative to the bank's
> competitors?
>
> And that's the nice thing about UCD. It puts us in the mindset that
> we are solving problems, not simply executing on a set of
> requirements. ACD seems to imply that the requirements are already
> known. And while someone may have a set of requirements in mind, they
> may not be the right ones.
>
> So would it be reasonable to say that ACD is the logical continuation
> of UCD? That is, after we understand our users' needs and wants, we
> can then define which activities the users need to perform, and then
> design a solution that enables those activities?
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=35466
>
>
> ________________________________________________________________
> 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
>

11 Nov 2008 - 9:32am
James Page
2008

>
> ACD ignores goals, needs, and context, whereas UCD does not. It's a
> superset / subset relationship.
>

Just to clear up Activity Theory does not ignore this.
For example you start off by observing users. From this observation you
break down the groups into praxis (people doing the same thing), and then
you break the individuals behaviour into activities, of which you break down
further into actions, which are further subdivided into operations.
The activities, actions, and operations are what then informs the design.
Dependent on your users the activities, actions, and operations may be
different for different users.

Take your nurses example. The experienced nurse may have
different activities, actions, and operations then the Trainee nurse, even
though they operate in the same praxis.

On the other hand with UCD you again start by observing users, and then from
this observation you create "Personas", which then informs your design.

So the difference between the two approaches is the output used to inform
design.

James

On Tue, Nov 11, 2008 at 2:31 PM, mark schraad <mschraad at gmail.com> wrote:

> Another way of looking at it is this: Are you looking to drive
> behavior or accommodate it? WIth functionality that is new you may
> have more liberty in directing the tasks and activities. For improving
> functionality that already exists, you may want to lean towards
> integrating that pre-existing behavior. In this later situation, user
> research becomes critical.
>
>
>
> On Tue, Nov 11, 2008 at 3:01 AM, Adrian Howard <adrianh at quietstars.com>
> wrote:
> >
> > On 11 Nov 2008, at 02:51, Livia Labate wrote:
> > [snip]
> >>
> >> 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 -->
> >
> > Ah - this actually makes sense to me. ACD & UCD as different ends of a
> > spectrum - rather than different things.
> >
> > Thank you.
> >
> > Adrian
> > ________________________________________________________________
> > 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
> >
> ________________________________________________________________
> 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
>

11 Nov 2008 - 7:50pm
Mike Long
2007

We (my design team) do not see any separation between UCD and ACD.
They are NOT mutually exclusive in any of the products we design.
When we incorporate ACD (more specifically, Activity Theory
Framework) in our practice we introduce many opportunities to
discover new tools and features for our Users.

Check out this diagram from a conference session I recently conducted
regarding Activity Modeling:

http://openscreens.com/articles/activity-modeling-for-kanban-pull-systems/attachment/activitymodeling_ux_kaizenconf-copy

Let me know if you have any suggestions or questions.

Cheers!

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

12 Nov 2008 - 2:37pm
James Page
2008

>
> coz I don't see how you can think about activities without having some
> concept, however minimal, of the end users goals, needs and context.

Activity Theory breaks everything down into activities, actions,
and operations are what then informs the design. Activity Theory very much
takes the user in :-

In AT, the perspective of the individual is at the center of everything. AT
> focuses
>
on the cognitive process of an individual situated in a social, cultural,
> historical,
>
and artifactual world.

>From http://www.research.ibm.com/<http://www.research.ibm.com/SocialComputing/Papers/CAH1.pdf>
So <http://www.research.ibm.com/SocialComputing/Papers/CAH1.pdf>
cialComputing/Papers/CAH1.<http://www.research.ibm.com/SocialComputing/Papers/CAH1.pdf>
pdf <http://www.research.ibm.com/SocialComputing/Papers/CAH1.pdf>

Hope this helps
James

On Wed, Nov 12, 2008 at 7:48 PM, Adrian Howard <adrianh at quietstars.com>wrote:

>
> On 11 Nov 2008, at 14:30, Jared Spool wrote:
>
> On Nov 11, 2008, at 3:01 AM, Adrian Howard wrote:
>>
>> On 11 Nov 2008, at 02:51, Livia Labate wrote:
>>> [snip]
>>>
>>>> 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 -->
>>>>
>>>
>>> Ah - this actually makes sense to me. ACD & UCD as different ends of a
>>> spectrum - rather than different things.
>>>
>>
>> I don't see that. You can't design with a focus on user goals without
>> thinking about activity. So, in my mind, they are not different ends of the
>> spectrum. ACD ignores goals, needs, and context, whereas UCD does not. It's
>> a superset / subset relationship.
>>
> [snip]
>
> I guess this leads back to my question of not really getting how ACD can
> ignore goals/needs/context - coz I don't see how you can think about
> activities without having some concept, however minimal, of the end users
> goals, needs and context.
>
> It briefly made sense to me as:
> * ACD = uses activity as the driver for design (supported by user models
> when necessary)
> * UCD = uses the user as the driver for design (supported by activity
> models when necessary)
>
> But you're right - it's subset/superset.
>
> So... I still don't get ACD... can somebody point me to some background
> reading that might clarify it for me?
>
> Cheers,
>
> Adrian
>
> ________________________________________________________________
> 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
>

12 Nov 2008 - 5:41pm
James Page
2008

Richard,
How do you combine Persona's and Activity Theory?

I don't see how the two are compatible. AT looks at activities through real
behaviour.

If you add Personas you are adding a multitude of parameters in the middle.

James

On Tue, Nov 11, 2008 at 10:38 AM, Richard Rutter <rich at clearleft.com> wrote:

> Jared your points reflect a conversation we often have here at
> Clearleft. We say we do UCD, but ask ourselves do we really do ACD? I
> reckon the answer is both. Or more particularly we do ACD with a UCD
> wrapper. That is to say we do user research and personas, but only
> enough to give useful context for the subsequent ACD.
>
> So the research and persona development is activity-focused. It's
> used to determine the activities that need to be designed and
> provides the settings in which that activity might occur.
>
> In your example of a photo sharing site, one activity would almost
> certainly be to upload a photo. Our research and personas would
> indicate whether users would be happy uploading one photo at a time
> or whether there should be a batch (instead or as well). It may even
> identify that uploading is not viable for the majority of users, and
> that an alternative solution would need to be developed.
>
> The point is that the UCD is limited to informing the ACD, thus
> avoiding dogmatic processes and freeing us to be able to choose the
> most appropriate tools to the job at hand.
>
> [Expanded upon at http://clagnut.com/blog/2208/]
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=35466
>
>
> ________________________________________________________________
> 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
>

12 Nov 2008 - 7:07pm
Jarod Tang
2007

Hi James,

> How do you combine Persona's and Activity Theory?
How do you separate human activity from human ? Persona just reflects
human ( human with motivation and goals in specific context), and
activities reflects what/how they do, isnt it?

As previous discussing from other thread, you can say not all guys
advocating activity centered design appreciate ActivityTheory (because
it's dry and not so practical until now). Instead designers use the
situated scenario (some guys calls it HIS/HER version of use case )
for many years, which can be regard as activity enabled design.

If you looks through the practice, you''ll find designers combine
persona and scenario (activity) frequently and naturally.

Regards,
Jarod

On Thu, Nov 13, 2008 at 7:41 AM, James Page <jamespage at gmail.com> wrote:
> Richard,
> How do you combine Persona's and Activity Theory?
>
> I don't see how the two are compatible. AT looks at activities through real
> behaviour.
>
> If you add Personas you are adding a multitude of parameters in the middle.
>
> James
>
>
> On Tue, Nov 11, 2008 at 10:38 AM, Richard Rutter <rich at clearleft.com> wrote:
>
>> Jared your points reflect a conversation we often have here at
>> Clearleft. We say we do UCD, but ask ourselves do we really do ACD? I
>> reckon the answer is both. Or more particularly we do ACD with a UCD
>> wrapper. That is to say we do user research and personas, but only
>> enough to give useful context for the subsequent ACD.
>>
>> So the research and persona development is activity-focused. It's
>> used to determine the activities that need to be designed and
>> provides the settings in which that activity might occur.
>>
>> In your example of a photo sharing site, one activity would almost
>> certainly be to upload a photo. Our research and personas would
>> indicate whether users would be happy uploading one photo at a time
>> or whether there should be a batch (instead or as well). It may even
>> identify that uploading is not viable for the majority of users, and
>> that an alternative solution would need to be developed.
>>
>> The point is that the UCD is limited to informing the ACD, thus
>> avoiding dogmatic processes and freeing us to be able to choose the
>> most appropriate tools to the job at hand.
>>
>> [Expanded upon at http://clagnut.com/blog/2208/]
>>
>>
>> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
>> Posted from the new ixda.org
>> http://www.ixda.org/discuss?post=35466
>>
>>
>> ________________________________________________________________
>> 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
>>
> ________________________________________________________________
> 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/

12 Nov 2008 - 7:10pm
Anonymous

UX designers may not be able to provide a singular definition of UCD,
but I'm not sure that 10 doctors treating cancer would be able to
come up with a singular approach to treatment, either. I think it
depends on the problem and context (patient and cancer type, stage,
funds, etc.), just as for it would for a UX professional.

Furthermore, there's probably a difference in the type of doctor
who's asked to treat the cancer. I've been thinking lately that
some of the difficulties in defining terms in the UX profession has
more to do with the type of the professional being asked the
question, than with the terms in the question itself. If you asked 10
psychologists what's the best treatment for depression, you'd
probably get 15 different answers too, because the question doesn't
take into account which psychologists are cognitive psychologists or
child psychologists, and which are family counselors or university
researchers.

In a similar way as UCD vs ACD, for some psychological treatments,
such as addiction, an immediate solution to the problem is to break
the addiction. If you're addicted to using X, stop doing X. This
will treat the behavior, an activity-centered approach to addiction,
but it probably won't help the patient for long. And, if you asked a
psychologist what's the best way to break a person's addiction to X,
there will probably be different responses to the best treatment
option.

Then again, the UX problems are not as complex as human psychology,
and if the APA has the DSM...??

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

12 Nov 2008 - 7:56pm
Dave Malouf
2005

Oy! I'm just going to ignore that Doc thing.

To answer Adrian,
If I were to design Flickr from an ACD POV I only care about the
activities of uploading, tagging, sharing, viewing, mapping, etc.
I really don't care whether primary persona A's goal for sharing is
to become the next Annie Leibovitch or not.

If I were designing it from a UCD perspective, I do care, or that the
person is elderly and needs large print, or any other demographic type
information.

personally, I think ACD = backwards IxD. It is going back to that
nasty realm of usability-based IxD where aesthetics, emotion and
story telling (can't tell a good story w/o good characters) are core
elements of good IxD.

So I'm less concerned with is ACD X or Y, but rather, should I care.

-- dave

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

12 Nov 2008 - 8:20pm
Jarod Tang
2007

Hi Dave,

Your answer inspires.
Maybe, more proper is back from the result, by asking what leads to
the good design instead of UCD or ACD? I do like the IxD , in which
the design is for good user experience, and by analyzing user's
activity.

regards,
Jarod

On Thu, Nov 13, 2008 at 9:56 AM, David Malouf <dave at ixda.org> wrote:
> Oy! I'm just going to ignore that Doc thing.
>
> To answer Adrian,
> If I were to design Flickr from an ACD POV I only care about the
> activities of uploading, tagging, sharing, viewing, mapping, etc.
> I really don't care whether primary persona A's goal for sharing is
> to become the next Annie Leibovitch or not.
>
> If I were designing it from a UCD perspective, I do care, or that the
> person is elderly and needs large print, or any other demographic type
> information.
>
> personally, I think ACD = backwards IxD. It is going back to that
> nasty realm of usability-based IxD where aesthetics, emotion and
> story telling (can't tell a good story w/o good characters) are core
> elements of good IxD.
>
> So I'm less concerned with is ACD X or Y, but rather, should I care.
>
> -- dave
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=35466
>
>
> ________________________________________________________________
> 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/

13 Nov 2008 - 4:49am
James Page
2008

Jarod,

> Persona just reflects human ( human with motivation and goals in specific
> context), and activities reflects what/how they do, isnt it?

The point I am trying to make is that Activity Theory output is the activity
and actions of individuals.

The Persona acts as a stereotype between real users and the designer.

There may be a problem with Activity Theory been dry. One can see from
this discussion that people don't understand it. But the advantage that it
has got is that it has got a theory. And it is based on the behaviour
of individuals.

Activity Theory has allot of problems, and don't think it is ideal, but at
least it does have a theory to back it self up with.

James

On Thu, Nov 13, 2008 at 2:20 AM, Jarod Tang <jarod.tang at gmail.com> wrote:

> Hi Dave,
>
> Your answer inspires.
> Maybe, more proper is back from the result, by asking what leads to
> the good design instead of UCD or ACD? I do like the IxD , in which
> the design is for good user experience, and by analyzing user's
> activity.
>
> regards,
> Jarod
>
> On Thu, Nov 13, 2008 at 9:56 AM, David Malouf <dave at ixda.org> wrote:
> > Oy! I'm just going to ignore that Doc thing.
> >
> > To answer Adrian,
> > If I were to design Flickr from an ACD POV I only care about the
> > activities of uploading, tagging, sharing, viewing, mapping, etc.
> > I really don't care whether primary persona A's goal for sharing is
> > to become the next Annie Leibovitch or not.
> >
> > If I were designing it from a UCD perspective, I do care, or that the
> > person is elderly and needs large print, or any other demographic type
> > information.
> >
> > personally, I think ACD = backwards IxD. It is going back to that
> > nasty realm of usability-based IxD where aesthetics, emotion and
> > story telling (can't tell a good story w/o good characters) are core
> > elements of good IxD.
> >
> > So I'm less concerned with is ACD X or Y, but rather, should I care.
> >
> > -- dave
> >
> >
> > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> > Posted from the new ixda.org
> > http://www.ixda.org/discuss?post=35466
> >
> >
> > ________________________________________________________________
> > 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/
> ________________________________________________________________
> 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
>

13 Nov 2008 - 4:57am
Jared M. Spool
2003

On Nov 13, 2008, at 5:49 AM, James Page wrote:

> The point I am trying to make is that Activity Theory output is the
> activity
> and actions of individuals.
>
> The Persona acts as a stereotype between real users and the designer.
>
> There may be a problem with Activity Theory been dry. One can see from
> this discussion that people don't understand it. But the advantage
> that it
> has got is that it has got a theory. And it is based on the behaviour
> of individuals.
>
> Activity Theory has allot of problems, and don't think it is ideal,
> but at
> least it does have a theory to back it self up with.

And how is activity theory incompatible with persona creation and
dissemination?

(the other) Jared

13 Nov 2008 - 5:13am
Jared M. Spool
2003

On Nov 12, 2008, at 5:56 PM, David Malouf wrote:

> If I were designing it from a UCD perspective, I do care, or that the
> person is elderly and needs large print, or any other demographic type
> information.

Just for the record, properly done UCD wouldn't care about
demographics. It would care about behaviors.

It doesn't matter what age someone is. If they need large print to
complete their objective, they need large print, independent of age
(or income group, geographic location political persuasion, gender
preference, dental history, dislike of sushi, . . .)

Jared

13 Nov 2008 - 11:26am
Jackson Fox
2006

James,

This thread has brought me close to the conclusion that Activity
Theory (AT) and Activity Centered Design (ACD) have nothing to do
with each other except for a vocabulary overlap.

AT is user-centered in that activities cannot be understood outside
of the social context in which they occur. Jared's definition of ACD
(which many seem to agree with) states that ACD does the opposite --
focuses on activity outside of social context.

In order to reconcile the two ideas, we need to amend Jared's
definition:

"The design that results from teams that only research the
activities."

To something like:

"The design that results from teams that research activities, the
tools that are used in those activities, and the context in which
they occur."

Jackson Fox
UX Designer @ Viget Labs

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

13 Nov 2008 - 11:39am
Damon Dimmick
2008

I suspect that ACD could be considered a modular component of UCD, a
component that could be exercised on its own, but which really should be
incorporated into a larger UCD process.

ACD should be a part of the design process, closely related to
functional design, one that -might- be sufficient on its own if a
designer is pressed for time or if a project has a very limited set of
functionalities.

In a way, ACD jumps from Requirements to Functions without focusing on
the intermediary step of thinking about how and why users would wish to
fulfill the goals that require said functions.

Jared, I like your scale metaphor. It's a continuum of design, which is
precisely how the real world functions.

In the company I work for, we often have to decide up front how much
design time and research time we can allocate. Although we don't have a
formal scale the likes of which you have proposed, I see in this scale a
very strong parallel to our projected design-depth results. Short term
projects tend to fall back on self and genius design, longer term
projects include ACD and UCD. The very best, robust projects, almost
always extend deeply into UCD (but include initial ACD steps).

I think the scale metaphor is very valuable. ACD also seems to be
closely related to Requirements Gathering and Functional Specifications
Implementation, so I think that it is precisely correct to put it as the
step before (or beneath) UCD on a scale. Many designs end a functional
implementations when really they could seriously benefit from a deeper
UCD approach.

Kudos,
Damon
Slinging my UX in Providence

13 Nov 2008 - 5:41am
Anonymous

Guys,

I created this simple diagram to illustrate my understanding of the
differences between ACD vs UCD.

http://flickr.com/photos/neuno/3027380216/sizes/o/

Please feel free to take it apart.

Regards
ShahW

13 Nov 2008 - 2:29pm
Dave Malouf
2005

Yes, you are right demographics by themselves is not important, but rather
the generalizations which are real around those demographics that we use.
BUT the demographics are necessary for gaining insights (and often even
creating) those generalizations.

I'm not saying that you are saying this Jared, but I just want to add that
"Market Research" IS an important data contributor for design research.
They've been doing this longer and with some pretty descent results, so
there is definitely a lot of cross-pollination that can go on between market
and user research. Demographic studies is a great tool for user researchers
to tie their own data studies into.

Regardless, I think my main and more important point is that activity
centered design feels soul-less to me. It's motivation as I've heard people
describe it here and other places is discount UCD (getting to the point
quickly). And like all things discount, you get what you pay for.

That being said, sometimes ya got no choice b/c you can only afford the
discount version of things and something is always better than nothing. But
I think that's why for me ACD is a part of a greater whole of UCD that you
can pick and choose from depending on the total context of the design
environment.

--dave

On Thu, Nov 13, 2008 at 6:13 AM, Jared Spool <jspool at uie.com> wrote:

>
> On Nov 12, 2008, at 5:56 PM, David Malouf wrote:
>
> If I were designing it from a UCD perspective, I do care, or that the
>> person is elderly and needs large print, or any other demographic type
>> information.
>>
>
> Just for the record, properly done UCD wouldn't care about demographics. It
> would care about behaviors.
>
> It doesn't matter what age someone is. If they need large print to complete
> their objective, they need large print, independent of age (or income group,
> geographic location political persuasion, gender preference, dental history,
> dislike of sushi, . . .)
>
> Jared
>

--
David Malouf
http://synapticburn.com/
http://ixda.org/
http://motorola.com/

13 Nov 2008 - 2:38pm
Peter Merholz
2004

>
> Regardless, I think my main and more important point is that activity
> centered design feels soul-less to me. It's motivation as I've heard
> people
> describe it here and other places is discount UCD (getting to the
> point
> quickly).

I would argue that UCD, as typically practiced, is soulless, too, as
it focuses on tasks and goals, and thus has a reductive understanding
of humans. UCD tends to treat people as robots whose goal is to
maximize productivity, to relentlessly accomplish a goal.

One thing that reassures me is the increasing embrace of
anthropological and sociological methods, which takes us beyond tasks
and goals, and towards behavior, motivation, context and culture. This
more holistic appreciation of people ought to provide insights that
allow for superior products and services.

--peter

13 Nov 2008 - 3:12pm
Jared M. Spool
2003

On Nov 13, 2008, at 3:38 PM, Peter Merholz wrote:

>>
>> Regardless, I think my main and more important point is that activity
>> centered design feels soul-less to me. It's motivation as I've
>> heard people
>> describe it here and other places is discount UCD (getting to the
>> point
>> quickly).
>
> I would argue that UCD, as typically practiced, is soulless, too, as
> it focuses on tasks and goals, and thus has a reductive
> understanding of humans. UCD tends to treat people as robots whose
> goal is to maximize productivity, to relentlessly accomplish a goal.
>
> One thing that reassures me is the increasing embrace of
> anthropological and sociological methods, which takes us beyond
> tasks and goals, and towards behavior, motivation, context and
> culture. This more holistic appreciation of people ought to provide
> insights that allow for superior products and services.

Ptthh. (Is there a better online way to represent a raspberry?)

Bad UCD is soulless.

Good user research embraces the anthro and socio methods you're
talking about.

This is the problem of our terminology. We regularly lump bad work,
whether it be bad interaction design, bad visual design, and bad user
research, into the underlying titles because we don't have good
descriptions of what this work looks like when it's done well. (And
like most professional activities, it's done well far less than it's
done poorly.)

Let's try to be careful in where we're discounting entire areas of
practice to ensure that we're not just condemning when it's done
poorly in a broad generalization. Then we can all get along.

Jared

13 Nov 2008 - 5:11pm
Anonymous

< Ptthh. (Is there a better online way to represent a raspberry?)

"Pfffttt"

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

13 Nov 2008 - 11:02pm
Dante Murphy
2006

Some good points have been made, and they compeeled me to do some retrospective analysis of my own design career to gain clarity on the issue. I can't pretend that I've ever consciously done ACD; like a recent commenter said, to me this is little more than basic SDLC design driven by functional requirements. And for this reason I can easily recall hundreds of times I've done ACD, whether through ignorance or compromise. In deference to those who see value in ACD, I can also recall some times that I have done ACD where I don't think UCD would have added enough value to be worth the incremental effort.

Some examples:
Adding a sort utility to a query result. It wasn't really worthwhile to get into the mind of the user...it seemed like a good idea because the activity itself had apparent value (is this really an example of "genius design"?), and the cost of implementation was relatively low.

Designing a customization/monogramming process for a clothing retailer. The client said that their customers wanted to monogram, and I went along with an designed a system that attempted to meet the needs of "the user" without ever knowing, or particularly caring, who that was. As long as it seemed like "the user" could complete the task without confusion or rage, I considered the design a success.

Now both examples could potentially havee benefitted from UCD...the first example to validate the need for a sort, and to uncover any other related unmet needs, and the second to improve the engagement of the utility to promote upsell and loyalty. But not for free...good UCD, the only kind worth practicing, takes time and money.

I also tried to think of a time I did UCD that didn't include some measure of ACD, and all I came up with was one real and one hypothetical example.

The hypothetical first:
"Designing" the music that plays in on of those hip clothing boutiques that caters to people half my age. I know that it's there to supercede activity and create mood and atmosphere...one that is likely to drive a grumpy old man like me across the aisle to Brooks Brothers, where it's nice and quiet. One that makes it impossible for hand-holding post-adolescents to talk to each other, so the only remaining form of social communication is to shop (or text...could ubicomp beat the blaring soundtracks?). The idea is to make the store like a nightclub...enabling and driving to specific activities, but the design of the environment is activity-independent.

And a real case:
Ages ago my colleagues and I designed a "pitch book" similar in execution to the Google Chrome comic. The primary driving force behind the design of our book was to create an impressions and to entertain while informing, but we weren't looking for any specific activity in the context of our artifact. I'm sure that many designers here have worked on projects where the engagement was the goal, and a good knowledge of the audience, in my case marketing managers and brand managers.

But most of the time I agree that ACD is either a subset of UCD, or a stepping stone in a larger methodology.

And if you're still reading, I wonder what YOU think.

Dante

14 Nov 2008 - 2:56am
Andy Polaine
2008

allison wrote:

> "Pfffttt"

I believe that's the official Calvin and Hobbes version.

14 Nov 2008 - 12:14pm
Josh Seiden
2003

Jared,

I think that the characterization of ACD as a subset of UCD is
something that proponents of ACD would disagree with. Rather than
think of these schools of thought as existing on a continuum, it
seems to me that they exist as parallel "systems" that seek to
provide a framework with which to design.

Quoting Larry Constantine (who has been writing about this recently):

"Activity theory further characterizes human activity as
hierarchical. ... activity can be understood at three levels of
analysis: activity, action, and operation. Activity consists of
collections of actions directed toward goals that contribute to or
are related to the purpose of the activity. Actions in turn comprise
operations, conscious or non-conscious, adapted to emerging
conditions in service of the goals of the actions. "

This discussion can be found in Larry's paper on the subject here:

http://foruse.com/articles/activitymodeling.htm

In this paper, I see at attempt to describe a rigorous system for
modeling and understanding user activity in the context of goals,
intentions, social context and all of the other higher-order
constructs that we say makes "good UCD" good. To me this places ACD
not on a continuum with UCD, but rather next to it--and simply working
to accomplish the same thing, but from a different perspective.

I'm wondering if you've seen Larry's work on this? If so, do you
come to a different conclusion than I did?

JS

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

14 Nov 2008 - 12:57pm
Robert Hoekman, Jr.
2005

>
> I'm wondering if you've seen Larry's work on this? If so, do you
> come to a different conclusion than I did?
>

There's an article on Jared's own site from Larry.

http://www.uie.com/articles/designing_web_applications_for_use/

-r-

14 Nov 2008 - 1:43pm
Josh Seiden
2003

Right, and in that article, in the context of advocating for ACD,
Larry writes, "The first and most important thing to understand is
why people engage in activities. All human activity is purposeful."

So I'm wondering why Jared framed ACD as ignoring the "goals,
needs, and contexts of the users."

JS

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

14 Nov 2008 - 8:09pm
Dave Malouf
2005

In using Larry Constantine's view of ACD, I don't find any
discernible difference of value between ACD and UCD. It is neither
parallel or contained within one vs. the other.

It just seems like a specific way of reframing that which already
existed as UCD for the previous 30 years. What was previous called
"tasks" are now being called "activities". And the total tool kit
of UCD that has been created over the last 30 years is just as used in
part or in whole by the practitioner as before.

Basically, why?

-- dave

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

14 Nov 2008 - 9:24pm
Josh Seiden
2003

Dave,

The why is contained in the first article that I cited. Larry's work
is concerned with modeling systems--ways to represent the working
knowledge during design process steps--language. I read in that
article an attempt to create a robust and repeatable way to model the
problem space in a design project.

So I agree--it's not about value distinctions, but about a quest for
more precise language.

At least, that's how I read it--not trying to put words in anyone's
mouth.

JS
JS

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

15 Nov 2008 - 4:09am
James Page
2008

>
> And how is activity theory incompatible with persona creation and
> dissemination?

The challenge here is that you are using something that is fictional to
convey something that is based on real data. That is not to say that
Activity Theory is answer, and I agree that AT maybe should be part of the
Tool set.

When you use a Persona you are adding Fictional information to help bring to
life boring dry data. I will take Jared's example of the nurses workstation.
Let us image that we carried out observations of 32 nurses (n=32). We took
the data and to help us convey this information to the rest of the team we
create 5 Personas (p=5).

To further use some of Jared examples lets us imagine that 3 of them have
poor eyesight, 6 of them are training nurses, 10 them have many
years experience, 10 of them are on short teem rotation, and 3 of them have
a family dog. We combine the data from different real nurses, into Personas,
to make it easier to understand, and convey the information to the rest of
the team.

So we create a Persona who has poor eyesight, and is a training nurse. We
create another one who has a family dog and is on short term rotation. We
are challenged because none of real nurses actually have both poor eyesight
and are training nurse, and none of them are on short term rotation and have
a dog.

None of 5 Personas represent any of the 32 real participants.
We effectively thrown away all our data away. Instead of the 5
personas representing 30 nurses, what we end up with is 5 personas and
30 nurses. We effectively end up with a fictional brief.

There may be an argument that you could use a Throw Away Persona, as Norman
suggests..... A one time example, as I have used here.

Jared argues to reduce the amount of information for each persona, I guess
to get around this issue. Why not go all the way and then just label each of
the subject with a name? Throw out the fake and not the real data.

Activity Theory is describing behaviour that is happening at the point
of research. Like Ethnography it is not a predictive method. While I from
what I can understand people are using Personas as a way
of predicating behaviour.

Personally I don't think AT is the answer, but UCD needs some philosophy.
Both Art and Science has Theory to help.

All the best

James

On Thu, Nov 13, 2008 at 10:57 AM, Jared Spool <jspool at uie.com> wrote:

>
> On Nov 13, 2008, at 5:49 AM, James Page wrote:
>
> The point I am trying to make is that Activity Theory output is the
>> activity
>> and actions of individuals.
>>
>> The Persona acts as a stereotype between real users and the designer.
>>
>> There may be a problem with Activity Theory been dry. One can see from
>> this discussion that people don't understand it. But the advantage that it
>> has got is that it has got a theory. And it is based on the behaviour
>> of individuals.
>>
>> Activity Theory has allot of problems, and don't think it is ideal, but at
>> least it does have a theory to back it self up with.
>>
>
> And how is activity theory incompatible with persona creation and
> dissemination?
>
> (the other) Jared
>
>
>

15 Nov 2008 - 4:34am
James Page
2008

>
> So I'm wondering why Jared framed ACD as ignoring the "goals, needs, and
> contexts of the users."

Because from what I have heard is Jared is neither Swedish, nor has
background in Marxist Theory, either of these qualifications is
really important to fully comprehend Activity Theory. :-)

I think what Jared is trying to say is that AT is not predictive
of behaviour, but rather describes it, but I may be wrong.

James

Activity Theory
On Fri, Nov 14, 2008 at 7:43 PM, Joshua Seiden <joshseiden at gmail.com> wrote:

> Right, and in that article, in the context of advocating for ACD,
> Larry writes, "The first and most important thing to understand is
> why people engage in activities. All human activity is purposeful."
>
> So I'm wondering why Jared framed ACD as ignoring the "goals,
> needs, and contexts of the users."
>
> JS
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=35466
>
>
> ________________________________________________________________
> 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
>

15 Nov 2008 - 9:18am
Josh Seiden
2003

James,

I think that you are mis-characterizing personas. A persona is simply
a model. It can be a good model or a bad model.

When you write: "None of 5 Personas represent any of the 32 real
participants. We effectively thrown away all our data away."

This is simply an example of a bad persona set. In a good persona
set, no data is thrown away. Instead, all data is represented, but in
a manner that organizes it in a useful way.

JS

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

15 Nov 2008 - 9:35am
Jarod Tang
2007

Hi Joshua,

> In this paper, I see at attempt to describe a rigorous system for
> modeling and understanding user activity in the context of goals,
> intentions, social context and all of the other higher-order
> constructs that we say makes "good UCD" good. To me this places ACD
> not on a continuum with UCD, but rather next to it--and simply working
> to accomplish the same thing, but from a different perspective.

I Larry's paper, seems he integrated activity modeling with his usage
centered design, which dosen't mean he come up with ACD, isnt it? (but
from the other link, it seems he address the meaning of ACD),
And UCD more like a claim for the goal, that we should design to meet
user's needs and motivation; while ACD more like a advocate, that
activity (analyze or similliar stuff) should be at the foundation of
design practices. If so, there are not in parallel, aren't they? And
ACD could be one way of UCD?

Regards,
Jarod ( not jared)

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

15 Nov 2008 - 10:38am
James Page
2008

>
> Josh,
>

It can be a good model or a bad model.

Most theories would argue that a good model needs testing. How do you test
your Persona's? Testing means that you need to measure the output of your
model, and compare it to the real world. I really do not see how you can do
this with Personas.

How can I be certain that the model has no confirmation bias in it?

> This is simply an example of a bad persona set

How do you know if it is a bad persona set? What test can I do see if it is
a good one, or a bad one?

John von Neumann
said, 'with four parameters I can fit an elephant and with five I can
make him wiggle his trunk.'"
See http://mahalanobis.twoday.net/stories/264091/

Instead, all data is represented, but in a manner that organizes it in a
> useful way.

It may help the conversation if you try to building a Persona from the
example originally given by Jared.

James

On Sat, Nov 15, 2008 at 3:18 PM, Josh Seiden <joshseiden at gmail.com> wrote:

> James,
>
> I think that you are mis-characterizing personas. A persona is simply
> a model. It can be a good model or a bad model.
>
> When you write: "None of 5 Personas represent any of the 32 real
> participants. We effectively thrown away all our data away."
>
> This is simply an example of a bad persona set. In a good persona
> set, no data is thrown away. Instead, all data is represented, but in
> a manner that organizes it in a useful way.
>
> JS
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=35466
>
>
> ________________________________________________________________
> 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
>

15 Nov 2008 - 1:37pm
Josh Seiden
2003

Jarod-- just to be clear, I'm not making any claims about Larry's
work, other than to say that in his definition of ACD, he accounts
for goals and other higher-order concepts. This seems to contradict
what Jared posted about at the beginning of this thread: that ACD did
not account for these things. So I'm just asking Jared (not Jarod :-)
to clarify.

James-- I know that you've created a bad persona set by definition.
If the persona set ignores or discards the data, it's not what most
serious practitioners call a persona. It's what most serious
practitioners call a bad persona.

I'm also hesitant to get into a long discussion of personas here.
That's another thread.

JS

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

15 Nov 2008 - 7:40pm
Jarod Tang
2007

Hi Josh,

On Sun, Nov 16, 2008 at 3:37 AM, Josh Seiden <joshseiden at gmail.com> wrote:
> Jarod-- just to be clear, I'm not making any claims about Larry's
> work, other than to say that in his definition of ACD, he accounts
> for goals and other higher-order concepts. This seems to contradict
> what Jared posted about at the beginning of this thread: that ACD did
> not account for these things. So I'm just asking Jared (not Jarod :-)
> to clarify.
>
Sorry for miss-interpretation of your intention. And I agree, that
Jared's ACD definition contradict with normal Activity Theory's
activity definition. more links may as
1. http://www.amazon.com/Acting-Technology-Activity-Theory-Interaction/dp/0262112981
2. http://www.amazon.com/o/ASIN/1558608087/181-0321423-0466727?SubscriptionId=1100889MK2XY9PSTV5G2

Both clearly define activity holds user's motivation, context, and
tool mediators.

Regards,
Jarod
--
http://designforuse.blogspot.com/

15 Nov 2008 - 7:25am
George Neill
2008

I'm not sure I agree with Jared's surgical analogy. A medical or
surgical professional will always endeavour to prescribe the most
appropriate treatment for any particular condition, and those
treatments are (generally) pretty well defined by the larger surgical
community. So it's not like the surgeon has a choice. Stepping
outside of the accepted option is likely to lead him into some pretty
deep water and, in all likelihood (in the US at least), to litigation.

As UX professionals, on the other hand, we have a free choice to make
about which methodology to follow, and in our interpretation of what
that methodolgy actually means in practice.

To design an immersive and intuitive experience within the context of
Rich Internet Applications (which is what Adobe Consulting are all
about), I'd argue that we need to understand our users AND the
activities they perform (or will be able to perform once we've
worked our magic). So I don't see UCD and ACD being mutually
exclusive; rather I think the latter is a component of the former.
Which i think is what Jared is saying when he describes ACD as a lazy
man's UCD.

Now, the importance of laziness as a valuable human trait to be
observed and leveraged in the search for innovative solutions is an
idea I've been kicking around for some time. In fact, it's kinda
spooky seeing Jared talk about it here, as it forms the basis of my
presentation next week at MAX 2008. ("Lazy Innovation". Monday 17
November, Moscone Centre, San Francisco at 11:30am for those who are
interested in attending. Hope you'll forgive the shameless plug
here.) Much of what Jared has written above chimes perfectly with
what I'll be saying, so it's good to know in advance that I
haven't completely lost my mind.

I don't want to pre-empt the talk by going into too much detail now,
but I'll post my thoughts on the subject here once I've got the
event out of the way. Hopefully it'll be of interest to followers of
this thread.

George Neill
Lead Experience Architect, EMEA
Adobe Consulting

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

Syndicate content Get the feed