Tom Chi  

Activity Centered Design

August 5th, 2005 by Tom Chi :: see related comic

I guess we would be remiss if we didn’t discuss Don Norman’s recent article on Activity Centered Design. Reading through it brought a few things to mind, but more than anything it had me thinking about the mechanisms by which our field evolves.

Although HCI/UCD/UX/etc has gained visibility and achieved significant diversification of roles, our discipline is still quite young. As recent as twenty years ago, very few pieces of software had any formal usability evaluation, and outside of very small circles there was no discussion. Since then, we’ve gone through several phases of learning and adaptation, and there’s no doubt that these efforts have grown the field and improved software usability. But regardless of how much we think we know, it is valuable to assess where we are. Do we know all there is to know about UX? Is there even an endpoint to reach?

It seems pretty clear to me that we are nowhere near the endpoint of our learning in usability and design. Given this, it makes sense to keep pushing, questioning, and exploring new (and in this case, reviving old) avenues of thought. So why has Norman’s article caused such a stir?

First off, people get uncomfortable with challenging UCD when there is still so much value that UCD can provide to the world. Much progress has been made in software usability, but we are still far from the point where all software is usable. Norman could rightly counter that usability may not be the right goal for all products. I agree that some interfaces require expertise to master, but even allowing for this, there are countless projects where usability *is* a productive goal and for which UCD continues to be a great tool.

Secondly, the industry is now mature enough that specialized roles have appeared. An approach that emphasizes the role of designer while marginalizing the usability specialist is naturally controversial because it threatens a role that many people have trained for and invested in. If the new approach ends up being wrong, not everyone will get the message, and lasting damage may be done.

Finally, people get fatigued by theoretical churn. Sometimes it’s from gurus changing their minds, other times it’s simply from the cacophony of differing opinions. Regardless, once the debate is settled, someone still needs to sit down and do the actual work. The translation of theoretical into practical takes a lot of time, and may be overly difficult (or not that meaningful).

A short example: if in ACD, the nature of the activity is defined by the tool, but the tool being created is a novel one… then both the tool and activity are loosely bounded variables which don’t serve as helpful design constraints. How would one then move toward resolution? Well the likely next step would be to figure out what human need could be served and then describe activities (or tools) that could serve that need. Now suddenly you have bits of UCD appearing again. Is this bad? Nope. If you make a better product by letting such ideas creep in, then it’s actually quite good. But if this ends up happening all the time it calls into question the usefulness of ACD as an organizing principle for design work.

Despite these objections, what Norman has done is ultimately helpful to field. There is little doubt that we will learn from these discussions, and the rapid evolution of our field will lead to many more, I’m sure. From the practical standpoint, we’ll walk away from the debate either adopting aspects of a new design approach, or simply having a clearer sense of why the old standby was so good in the first place. That can’t be bad.

19 Responses to “Activity Centered Design”
Chris McEvoy wrote:

I believe we are witnessing the “Return Of Design”.

xx Design, yy Design and zz Design all share an ever increasing overlap of interests. It doesn’t matter if it’s AC or DC. It’s all Design, and that means that we can get on with working with each other to produce widgets that really work.

“Design is being respected for its complexity, its multidisciplinary nature, and its ability to address serious business problems.”
Peter Merholz - 4 Aug 2005

Jay wrote:

Having missed the debate, I must be on all the wrong lists.

Is Don Norman saying anything new here? I can replace “Activity” with “Goal” and I don’t think I’ve changed his definitions very much, yet understanding users’ goals is already a part of UCD.

Take two of his examples: the harmony remote and the cell phone mentioned in the latest article. For the remote, he labels “watching a DVD” as an activity. It is also a goal. Harmony has reduced it to the minimum number of tasks and therefore simplified the interface. The cell phone supports the communication activity. I can also say it supports the goals of communicating.

I’d appreciate it if someone can better explain the subtlety here.

Bryan G wrote:

I’m a little confused by this entry as well. There are several lines in the article that make me wonder if Norman isn’t just trying to stir up a debate. For instance:

“Norman could rightly counter that usability may not be the right goal for all products.”

Is he saying that the right goal for a product might be to have an usable product? Activity centered, goal centered, user centered, to me they are all the same thing. Methods can come and go, and people employ different tricks of the trade for doing their job. I know I have a unique approach compared to some of my coworkers, but in the end we all get the job done well.

Then we have this line:

“the industry is now mature enough that specialized roles have appeared. An approach that emphasizes the role of designer while marginalizing the usability specialist is naturally controversial because it threatens a role that many people have trained for and invested in.”

I don’t know how it’s done some places, but here the usability poeple play two roles. First, we are designers. Second, we are usability testers. As a fail safe you never test something you designed (avoids bias.) the entire point of user centered design is to always have the user in the foreground of your thoughts when doing every step of the software design lifecycle. Why would you design a product without considering the user? On that note, what is it that you are designing for the user? A product to allow them to complete a task as efficently and easily as possible. A task..a goal..oh an ACTIVITY. So how is user centered design different than activity based design?

If I am missing something someone please call me on it.

Tom Chi wrote:

I didn’t really discuss Norman’s article so much — mostly just the reaction to it. Perhaps its a little early to move into meta-commentary… apologies for that. Basically, ACD is different because it can produce things like a violin, which are not usable in the UCD/HCD sense.

If you were to usability test a violin, it would test horribly. It’s not well designed with regards to any particular persona, but rather it is designed for the activity of making a particular type of sound. Somehow, despite all this, violins are still used — because they afford their activity well. Norman lists other examples where people adapt to successfully use the tool instead of vice verse. I think this is the core difference he’s trying to highlight.

Jay wrote:

Sorry to jump into the debate instead of commenting on your points, Tom.

After reading Norman’s article I simply wonder if there’s something to comment on. The debate can also be framed as “Is usability important?” but we’ve had that discussion here before.

I do agree that debate and discussion are excellent and necessary for progress. Bring it on.

David Heller wrote:

items like violins aren’t designed, they were created, not not designed. I’m not so sure you can do planning and take the context and personas out of the equation. Activity, which in my mind is an element of the persona is not valid by itself. It is important, but not isolatable.

Let’s even take a violin for a moment. So the person created the first violin to create a specific sound. Was that it? While it is not usable, it does posses certain properties that ONLY a violin can do, and only a human being can made happen. It is not fretted, and thus easily allows the slide between tones, it uses a bow which allows for a suststain w/o having to hold your breath, and it is small to create the tone it is looking for.

Those items can exist in a host of shapes, but the time that it was created in and for whom they expected to own and use it also influenced the form used. There were other elements like giving feedback, how to tune it, etc. that are human based and not just form based. Meaning these are interaction points.

Lastly, if we were to design an instrument today that required the same rules as before (and be acoustic for the sake of this argument) how different would its shape be? Could be? Would applying UCD & ACD together produce something different? Does the violin have to be unusable?

My answer would be that we could create something very different today (not just b/c of technology) b/c we CAN think about UCD and ACD to me is just a subset of UCD.

Last point, let’s say we do make this new “violin”. If it is so easy to use, would we still cherish it? The craft of playing this complex instrument is what makes it soooo special, no? Again, usability is not an end in itself.

Bryan G wrote:

your last point makes me think of a great many unix elitists. Give them a tool that allows in the few clicks of *gasp* mouse to complete a task that takes 30 commands and they’ll boldly state, “it’s easier to just leave my hands on the keyboard.” I think you are absolutely right David, and I agree whole heartedly.

Robby Slaughter wrote:

Norman’s article and the ensuing debate is academically respectable, but is potentially a political disaster. The UX field is still struggling to get any traction—most everything isn’t designed using any coherent methodology or even an organized process. We need to focus on promoting the success stories of our very rational approach, which, as coarse as it may be, is orders of magnitude better than the old way of “just making it work.”

HCD, UCD, ACD—whatever. The most important fact still remains: there’s no substitute for observing actual users. Design is about giving up the hubris of “I know what’s best” and instead creating designs according to observed behaviors and stated expectations. The customer is (still) always right.

sloan wrote:

For a basis:

I don’t know how many times this comes up, but it comes down to the only aboslute is that there are no absolutes.

Different approaches to the same problem is always a good thing. Just as different perspectives are always valuable to a debate or an concept. The idea that there is ONE silver bullet way to approach a particular problem is silly.

Stray wrote:

First, let us note I’m outside teh usability sphere. I’m software engierr that has spent far, far too much time working with eCommerce Apps.

that being said, reading artical only re-enforced a privately held concept. The idea of evolutionary usability design. Tall order, I’m sure, and I am unaware of any antecedents. We dealing with the web, notabley site that seel goods or information it becomes readily apparent the users tend not to invest in troublesome interfaces. If casual user hits a site they focus on what brought them to a site: wether it be a new monitor or their favored comic that have little interst in learning a complex application. After a few visits they begin to chafe under beginner usuability requirements and look to focus and work with more advanced structures. The same is true of game design. A user wishes to have good experience at all times. If the design is shifted to far to the user, the appliction functionality suffers. If it is shifted to far to the application requirements, the user suffers.

Norman’s stance comes out aginst user centered design and reminds deisngers to consider the application int the process.

From my reflection, the best design is one that allows or shifts to the users level of experience. One that evols witht eh user.

Hence, an application that “hand holds” the user at the first few visits and becomes more efficient for the application is the ideal sphere. Wizards attempt this but usually fail based on the users learning curve, resulting in a frustrated intermediate user that never becomes and advance user.

From an engineering stand point, this calls for an adaptive design that combine user centric methodology with functionality based enhancements. Literally, an application that detects the user’s learning curve and adapts to it as the user progresses.

The hard part comes in when factoring in business deadlines and rules…

Two cents, from a disassociated view point.

(please forgive any ignorance of pre-established methodologies and theories.)

Joe wrote:

Here’s why the article prodded me: We are adding yet another jargon level that is perhaps interesting to UX types but wholly un-sellable, either to external clients or internal management. Sorry, but precisely _because_ the field is nascent, we need to hone our touchstones, abandoning them if and only if they prove unuseful, unworkable, and, :wink: , unusable.

To quote my own post on another blog, another reason I’m perturbed by the article is Don’s insistence that users adapt to their technology. In his article’s section “Tools Define the Activity: People Really Do Adapt to Technology,” I hoped he would have then admitted being wrong. In “Things That Make Us Smart” he writes, “‘People Propose, Science Studies, Technology Conforms’ My person-centered motto for the 21st century.” I guess he was wrong. Have I been wrong to read and be inspired by him? Will another 10 years find that ACD is just so much B.S.?

Tom Chi wrote:

Jargon is definitely no good for spreading the word about HCI. Like a lot of other things, that sort of discussion is meaningful between practitioners, and not so good for clients. It’s like when magicians meet, they want to get super specific about the “Kleinberg interlocking-ring trick variation 3″. It’s a lively discussion between the magicians, but not helpful for the audience at all.

Similarly, it is important that HCI practitioners have this discussion, but not necessarily relevant for us to relay the debate to a client until we’ve come to some sort of consensus. To your point, I too am worried about the assertion that people should adapt to technology. While Norman points to a long history of this, one of the promises of HCD is that we have the responsibility to design technology to best suite human needs.

Deej wrote:

Whilst I’m concerned about the political implications of Norman’s article, I can’t help feeling that the man had a decent point in there somewhere. Any readers of his earlier books will know he has a habit of having great points to make, but failing to make them concisely. I freely admit however, that I couldn’t do anywhere near as well!

My interpretation was that the main drive of this article was to bring attention back to something that every HCI professional already knows - that humans *interact* with their tools, and it’s this interaction that should be the focus. If we place too much emphasis on the design of the tool, we’re not looking at the whole picture.

I don’t believe we should be forcing humans to unnecessarily conform to the technology they use, but I do think it’s too easy to dwell on tweaking the design of a tool and the needs of the user, rather than objectively evaluating the success of the interaction as a whole.

I don’t believe Norman particularly meant to contradict his previous writings, but provoke a shift of attention, that perhaps the more evangelical members of the community need. The majority of HCI professionals have needed to become forceful to get their trade recognised within an organisation, but it’s all too easy to end up dwelling on usability above all else. A tool can always be more usable, but when is it usable enough to support its reason for being - its activity and/or business objectives?

DrFred wrote:

So, this kind of gets a question I was thinking about recently.

Are HCI and Human Factors making people dumb? There is such a push to make things so extremely easy for people and make the process thoughtless.

If we take things to the extreme when designing things, we would end up with a world where you have to use very little though, if any to interact with objects and computers.

This was somewhat triggered by his comment about musical instruments. They are horrible usability examples, yet they are still respected. People spend hours and hours trying to play them skillfully. What if people designed instruments that made it a lot easier and required less practice and thought. Isn’t that just making people think less and not allow for proper problem solving and persistant characteristic traits to develop?

I think an example would be stuff such as the program Fruity Loops for making electronic music. It used to be somewhat of an exclusive art, but once this program became popular, any joe could just download it, and with a few clicks have an electronic song that took very little thought. This ends up cluttering the world with millions of banal audio tracks. On the flip side, it does make it easier for those musical artists who have great ideas and creativity, but did not have the equipment or knowledge about how to make electronic music in more complicated ways.

Robby Slaughter wrote:

DrFred, I think the story of “human factors” IS the story of progress, not dumbing down. Example from the past: the printing press made it orders of magnitude easier for people to read and share ideas. You now have to be rich, or highly skilled in calligraphy and incredibly patient to write a book.

Example from the future: Cars that drive themselves. If we invent them, less people wil die needlessly in accidents, and they will have more time to pursue interests or relax while being transported.

Maybe this has been been bad for penmanship and reduces the training ground for NASCAR, but I think it’s all better for society. Success with HCI/HF is defined as making everybody happy. This might sound trite, but, how can you go wrong with that?

Magnus Ahltorp wrote:

I would divide design into two types, “specific” and “non-specific”. Most professional design work, I would guess, is “specific”. You have a certain customer you work for, a certain group of users you design for. The important thing here is that you expect to be paid for that specific work, and you really have to see to the specific needs of that specific group.

In the “non-specific” case, you are not dependent on a specific thing “making it”. You might be an amateur, but you can also be a professional designer that designs a lot of different things without thinking of a specific target group. I think it’s really here the great designs emerge, since “specific” designers cannot be daring enough.

K.O. wrote:

This reminds me of Paul Dourish’s embodied interaction, where he places much emphasis on the interactions than the objects. I feel that it boils down to the need for us to acknowledge that the technology (including well-designed products) is as much a social actor as the user himself/herself in the entire ecology.

Max wrote:

“If you were to usability test a violin, it would test horribly.”

Exactly which users and which goals/activities were you thinking of testing?

I’ve just listened to the “transcript” of a test subject using this “violin” technology, and it seemed to work pretty well :-)

Ann wrote:

Great comments above have allowed me to see some of the usefulness of Norman’s article and to give him more of a break than I was initally going to (it just seemed like an attempt to return to the “good old days” and to grab some spotlight in the meantime). One major problem I had with his writing was his support for humans adapting to technology as they always have had to and did successfully.

Of course, this is true, but is it helpful in the debate about UCD? The violin is, in fact, highly usable in a very particular context for a very particular user. I don’t think UCD is intended to make every technology accessible to every single human being for goodness sake. Further, as Norman illuminates, the violin gained its usability through many iterations of use AND adaption (by both the users and the designers/builders). But that took a long time and a lot of expertise in a wide range of disciplines and industries.

As I see it, a major point of UCD is to improve (streamline, clarify, focus, etc.) that design, adaptation, and evolution process so that technologies can do their very best for their purpose that’s possible, as soon as possible. At its best, UCD (in whatever form that makes the user central in the design process) is the way that technologies can reach their potentials for improving life on earth.

Whether or not a remote control or cell phone has the best possible usability is one level of importance; whether or not a HUD on a commercial airliner or a medical decision-support UI are usable is a far greater issue. I think we can all agree that if UCD can more quickly and efficiently help improve life-critical UIs, it’s all to the good.

Leave a Reply

OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?