On activity- and user-centred design

Over on the IXDA mailing list, Jared Spool opened a discussion on Where that ACD thing fits in which he wonders what Activity-Centred Design (ACD) might be and where it fits into other design approaches.

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.

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.

In this context, Jared considers laziness to be a good thing, applauding ‘anyone who is creatively lazy, looking for ways reduce effort while producing more.’

Jared’s points reflect a conversation we occasionally have here at Clearleft. We say we do User-Centred Design (UCD), but ask ourselves if we really do ACD? I think the answer is both. Or more particularly we do ACD with a UCD wrapper. That is to say we do user research, develop personas, and other typical UCD activities, but only enough to give useful context for the subsequent activity design.

This implies 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, thus directing the design of the activity.

Jared cites an example of a photo sharing site. One activity for such a site would almost certainly be to upload a photo. Research and persona development could indicate whether users would be happy uploading one photo at a time or whether there should be a batch upload (instead or as well). It may even identify that uploading is not viable for the majority of users, and that an offline solution would need to be developed.

If one thinks about ACD and UCD in an Agile UX situation, the emphasis is certainly on the activity, and thus ACD would seem to take precedence. Agile developers need an interaction & interface design to do their development – inherently this means designing the activity identified in the user story being built. That said I’m firmly of the belief that UCD must take a key, if reduced, role in the Agile process, informing the user stories and ACD.

The point is that we do practise UCD, but it is limited to informing the activity design, thus avoiding dogmatic processes and freeing us to choose the most appropriate tools for the job at hand.

And why is this seemingly inward looking discussion of any importance? Like Jared, I think it’s important that we’re clear on what each approach is and how it differs. We want to know what we’re doing and we need to have a language that adequately describes our tools, techniques, and processes.


Donna Spencer has put together a handy tool and thought process for working out how much user research to do for a given project.