I don’t see a deeply meaningful distinction: to me it’s like the Italians arguing with the Spanish about Serrano versus Parma ham. They both taste almost the same as long as they’re well made.

I would shorten your axiom to : ‘keep it as simple as possible’, or ‘make it no more complex than it needs to be’. This has been a valuable design principle since humans made the first stone tools. My ancestors hunting spear did not have a toothpick attachment.

Certainly we should also think of user behaviour in terms of a sequence of steps, rather than getting stuck on thinking about things on the ‘page level’. But also, we shouldn’t become so obsessed with activity-flow that we create a rabbit warren.

This all becomes more complex on multi-function sites that serve more traditional companies that offer a wide range of products and services to different audiences, rather than the single-proposition sites you list.

Features as affordances that make an activity easier…will think more on that. Interesting…

When I was at New City Media, we’d start projects off with a KJ of stakeholders and ask the question “What would someone coming to [website] expect to either find or do?” I can’t remember who to credit for that question, but it nearly always elicited great responses from the participants – lots of verbs. (and despite trying, I’ve had a hard time coming up with a better question)

Sometimes the post-its would be specific, like “buy tickets,” sometimes they might be more general like “find out what sort of research is going on at the university.” I’ve even seen something as nebulous (but fun) as “see cool stuff” go on to get a majority of votes from the session.

Items like “see cool stuff” don’t tell you how to create a “feature” of the site. But they do provide guidance as to what sort of activities that users would like to “do,” it starts the dialog which turns into a framework or an architecture for activity.

So I think that features are outgrowths of activity – they’re like an affordance that makes the activity easier. Maybe I’m stating the obvious, but designing for features doesn’t make as much sense as designing for activity.

Now, there are lots of bad ways to design an activity, and that’s where user-centered techniques can help smooth out the rough spots. But starting with activity has never steered me wrong.

maybe something like, goal driven, scenario/activity Centered, prototyping&Testing iterated process makes some sense here.

Josh,

I think it’s important to clarify that I refer not only to how good are your team members, but also what it is they’re good at. Depending on their skillsets you might find it more appropriate to choose one methodology over another. Or at least to emphasise those tasks in which your team has the greatest strength.

I wonder whether those projects used as poster-children for each of the different methodologies were the result of making a choice that best matched the project requirements & team members rather than the superiority of the methodology itself.

Steve