Activity-centered design – some thoughts

Activity-centered design (ACD) is a concept that appears to have its roots in activity theory, mostly of the Scandinavian flavour. It asks designers to focus on (wait for it… ) the activities that people are carrying out, and that a system should support.

It is a high-level view of tasks and goals and clearly does not focus on “the user” as an individual unit. Instead, it gives us a framework in which to consider what people do, or what we want them to be able to do, in a more-or-less general sense. This can be a very attractive perspective to take in situations where the user-base is very diverse, the goals are varied, but the broad activities are less numerous and easier to define.

Activity theory itself addresses the psychology of working and learning. It has influenced, and subsequently been influenced by, human-computer interaction research.

Doodle to illustrate zooming in on users and their activities

Human-centered design considered harmful? Eeek!

A few years ago, when I realised that working on usability and the user experience of things like software and websites could be a real job (who knew?!), I did a lot of reading. I began to consume as much information as I could.

I often used to read posts on the OK/Cancel blog (now defunct, as far as I know). I came across one from 2005 on “Activity Centered Design“, written by Tom Chi (he of Google Glass prototyping fame), and it really got me thinking… particularly when I read the essay by Don Norman that it referred to – “Human-centered design considered harmful” (see also Norman’s follow-up clarification).

The idea of focusing on an activity, its actors and its goals, made perfect sense to me. It reminded me of switching the lenses on your camera, from wide-angle, to mid-range, to macro. In some ways the activity-centered level is more “wide-angle” than the human- (or user-) centered level.

This doesn’t necessarily pit ACD against HCD (or UCD as it is more often called). They are just different lenses. So, I read and bookmarked some great articles… and then forgot all about it.

Going with the flow

Well, not entirely.The concept of considering users’ activities was something I found myself coming back to again and again.

When I gave a talk on UX design for search a couple of years ago, I tried to emphasise the idea of search engines being a tool that fits into a wider overall “flow” of activity (so think about the context), heading towards some kind of objective and outcome.

During the last 3 years, I’ve worked in a scientific institute where complexity is often the norm, as is having a wide variety of users. In these situations, I’ve often found that working to understand common or frequent activities, and aiming to support those, is often the most effective way to come up with successful design solutions.

Stop designing for “users”

In any case, ACD recently popped back onto my radar following a tweet from Will Myddelton (@myddelton):

Screengrab of a tweet from @myddleton

Will Myddleton (@myddleton)’s tweet about activity-centered design

The article that Will linked to, entitled Stop Designing for “Users”,  really brought me back to thinking about this activity-centred perspective. The author, Mike Long, essentially promotes the idea that we should try to see the “big picture” of a system and how people interact with it; that it may be better to look for common activities, and design to support those, than to zoom in too much, and focus our design efforts on satisfying the needs of individuals.

OK – that makes sense but Long also strongly cautions against using that UX design stalwart, the persona. Again, I understand his argument here but I wouldn’t go so far as to dismiss personas out-of-hand.

Of course, badly-conceived personas can be worse than useless, and over-reliance certainly can, I think, lead to feature bloat and dead-ends. I’ve had mixed experiences of using them in projects but they can be a great way to encapsulate and communicate something about users… people… when you need to “zoom in” to a certain level during a project.

Practically, though, I feel like I need to play around a bit more with the simplified activity diagrams that Long uses in the post (the originals, synthesised by Finnish academic, Yrjö Engeström, are rather more complicated), and see how they can inform my work, and that of my colleagues.

Activity diagram

An example of an activity diagram that I am playing around with at the moment. For the moment, I haven’t included the “Community” category. Heavily adapted from Yrjö Engetröm’s similar diagrams

Are activity diagrams to activities, what personas are to users?

In an abstract way, these activity diagrams are rather like an activity persona, if you’ll forgive the mixed whatevers. They give us a way to look at who is involved in an activity; their goal; the tools they use; rules and rituals; the community or context of the activity; and the “division of labour” – who does what in achieving the goal of this activity.

The activity-centered lens

Having started thinking about this topic again, I began to consider how people I respect in the field of design talk about what they do.

I went back and re-read Don Norman’s essays on the topic. I tried to find out more about how people in the HCI or UXD / IxD communities are trying to apply activity-centered design practically. There isn’t a great deal! (see suggested reading at the end of this post).

I got hold of a copy of the paper “Taskonomy: a practical approach to knowledge structures“, which is an excellent read. Referenced by Don Norman, the authors stress that there is a place for taskonomy and taxonomy in the same place i.e. presenting things “as they are”, hierarchically, and supporting activities by grouping information tools accordingly. This caught my attention, especially when one thinks about how important grouping is as a route to simplification.

In a recent Intercom blog post, Des Traynor interviewed software designer, Ryan Singer (37 Signals), about practices and processes. Ryan’s comments about typical UX design methods and deliverables intrigued me. Sure, there is a lot of discussion of “getting out of the deliverables business” in the UX world, but I thought that both Ryan and Des’ comments about focusing on what users actually want to do were key: goal-orientated activities and context.

Then there’s Gerry McGovern and what he has to say about supporting top tasks. He was also interviewed recently, on the Content Marketing Experience blog, where he reiterated that “the task is the focus“. When I read that, I substituted the word “task” for “activity”. Interesting.

Activity focus / task focus / user focus

Now, perhaps tasks are made up of activities; perhaps activities are made up of tasks. But if we assume the latter (as I am inclined to do) then we can see that something as familiar as task analysis could fit right in the middle of an activity diagram as a middle layer; the middle lens on the figurative camera I mentioned earlier.

I’m not interested in trying to redefine UX design practices, nor wave my “I am an activity-centered design believer!” flag. It’s just another tool… another lens for us to use when approaching design problems. You’re free to switch the lenses around and get the best picture you can.

Suggested reading

So if you’re still interested, here are a few things on the topic of activity theory and activity-centered design that I enjoyed reading.