There’s been a bit of a stink (hoopla, fuss, ado) about activity-centered design (or ACD) recently, and it’s been claimed superior to human-centered design (HCD). I figured I’d head to the seminal book and see if I could end up better informed. Here is my review of Activity-Centered Design by Geri Gay & Helene Hembrooke (MIT Press, 2004)
This book was not exactly the activity-centered design manifesto I was expecting, although the first few chapters were ok, and reinforced some of the principles in which we believe at MAYA. The quick Activity Theory overview was helpful, although the whole first chapter felt laden with academic/formalistic/obfuscated prose. (This was true at the end of the book as well. Who says things like “interpreting mediating cognitive process,” “syncretic co-presence,” or “conceptualization of the interplay?”) I especially liked the spiral chart in figure 1.5, even though it is nothing new or even specific to ACD — it’s a representation of the classic design cycle that includes repeated iterations through requirements, design, implementation, and evaluation.
Ultimately, the case studies in chapters 3+ were interesting but felt tangential.They weren’t strongly tied back to ACD, seemed to take the place in the book of (missing) in-depth discussion on ACD, and included too much detail about the technical aspects of the projects. It felt like two disconnected books — a short 1-2 chapter introduction to activity-centered design (which is not a great departure from accepted iterative spiral design processes), followed by a number of case studies on designing and building collaborative and ubiquitous computing systems.
I don’t have any objection to activity-centered design. But then again, I don’t have any objection to human-centered design, user-centered design or usability either, and human-centered design is not “harmful,” as has been claimed. Whatever you want to call it, the tenets of good design are the same: active involvement of users, iteration of design solutions, and interdisciplinary design. The best place yet I’ve seen this documented is ISO 13407, even if few people have read that standard: it’s concise, correct, and just general enough to be widely applicable. But this principle exists everywhere good design is espoused: I’ve seen the spiral in several disparate places including Yacht Design According to Perry, Systems Engineering texts, and now Gay and Hembrooke’s ACD book.
If you want to build usable systems, ignore the semantics; forget about what to call the design process. Put together an interdisciplinary team, involve the users, build something, test it, and cycle what you learn back into the design process, again and again.