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: [EMAIL PROTECTED] p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [EMAIL PROTECTED]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
