I’m a self-proclaimed fan of ACD (Activity Centred Design) or as Constantine calls it, Usage Centred Design, as opposed to pure User Centred Design. In most recent times this has been called ‘Jobs to Be Done’. There are several discussions around this subject on our USiT Blog and the IxD list . The prevailing opinion seems to be that pure UCD is a bit outmoded.
As we look at sites which have fragmented, or ill-defined, audience profiles it’s hard to find commonalities in behaviours or attitudes. However, common activities, goals or tasks can be teased out, regardless of archetype. Designing for these activities or usages gets us closer to a better design solution, perhaps, than attempting to design for several different user archetypes.
Furthermore, there can be little doubt that there are some negative connotations to being seen as purely the ‘User Advocate’ in a real-life business environment. Our job is to design successful, usable and elegant solutions. Yes, we must fight for the optimal design solution, which by necessity must include the needs of our users, but we must also create designs which achieve business goals, are eminently findable and are technically feasible. Sometimes these factors oppose each other, and it’s our job to achieve a successful balance.
I think this discussion might just run and run, and does seem to be splitting the community.
There’s no point to the ACD vs. UCD argument because if you look back at the original formulations by Nielsen and others, you see that ACD is nothing new, but a _part_ of UCD. Norman and Draper’s User Centered System Design (1986) has an entire section dedicated to activities. UCD or usability engineering (what’s the difference?) has always included analysis of the activity or task to inform design.
The “user†in UCD refers to the fact that we are concerned with user performance and satisfaction, not that we are strictly concerned with user attributes. If you have been ignoring the task, then you’ve been doing UCD with one arm tied behind your back.
(BTW, there are _three_ arms of data for usability engineering; the third is the environment. Have you been ignoring that too? Will someone “discover†environment-centered design in a few years?)
The only UCD I see as getting outmoded is bad UCD that seems to have evolved relatively recently. This includes designing apps and sites based solely on general user demographics and attitudes, personas not based on research of real users, an obsessions with specific research technologies like eye-tracking heat maps, excessive attention to deliverables other than actual design decisions, and rigid adherence to an inefficient and bureaucratic usability “process.†It seems to me this is the sort of stuff that is being shaken out of the current controversy.
Well, good riddance.
There is no doubt that good design incorporates attention to both the user and the activity. But there are some distinctions in the methodologies. Robert Hoekman Jr on the IxD list summarises these quite well:
http://www.ixda.org/discuss.php?post=33980
1. UCD = persona descriptions; ACD = activity analysis (focused on users, objects, and the activities themselves)
2. UCD = research focused on user goals, aimed at a niche audience; ACD = focused on how people perform activities, abstracted to a wider audience
3. UCD = involves talking to users in (almost?) every case; ACD = designer can sometimes/often become a SME on the activity with very little or no outside research
4. UCD = users are unreliable, unstable, and often unpredictable; ACD = activities are relatively stable, by comparison
I think discussions around these points are healthy and stimulating, helping us to re-examine what we do, and how we do it. I look forward to seeing how this one ends up.
As to the point you make about “The only UCD I see as getting outmoded is bad UCD that seems to have evolved relatively recentlyâ€. I wouldn’t say bad UCD is a recent development; there has always been good and bad design regardless of what we term it.
Nice article. Thanks. 🙂 Eugene
“Designing for these activities or usages gets us closer to a better design solution, perhaps, than attempting to design for several different user archetypes.”
Very true. Thanks for the post.