As to documents…It doesn’t matter what the model is, the design process will be lacking if there isn’t good user data. It is not a fault of the waterfall process that user data is not collected or used properly. Agile’s style doesn’t guarantee that the user’s involvment is translated into good design…only that some user is at the table. It could be the wrong user, there may not be enough user/business views or any number of other failures not related to the “agile process.”

I find that while we may not pursue Task Flows, Concept Models and User Scenarios to beautiful completion that it is through working with on them with the various parties that a shared language and vision of the user is created. They are useful because they are structured >designtools

As for useless documents, I think many are produced at the start of a project. It isn’t so much the documents are useless as the thinking behind them is. When authors are just guessing on requirements or ideal functionality, instead of using data collected by talking to and watching real users, the resulting documents are unlikely to have any value in producing a design that meets the users’ needs.

I think agile processes can have a role in strategic definitions, but I think they’re structure and objectives will vary from when they are used in a refinement mode.

Let me put it another way: Waterfall (the only serious alternative to agile at this point) isn’t any better at strategic definitions, except that you get more time to do things while everyone else is screwing around writing useless documents.

What role would you see agile process in strategic decisions? And what kind of documents (or which documents particularly) do you think are useless?

I discussed this with a VP of Engineering and he said that the Agile process is best used once the strategic work has been done to work on individual features for which the business and design goals have already been defined.

I’m not sure I buy this — yet.

I think agile processes can have a role in strategic definitions, but I think they’re structure and objectives will vary from when they are used in a refinement mode.

Let me put it another way: Waterfall (the only serious alternative to agile at this point) isn’t any better at strategic definitions, except that you get more time to do things while everyone else is screwing around writing useless documents.

Similarly there is an inherent flaw in thinking that you can bring -a- user to the table since they will have a unique and often skewed view of the products needs.

The value that non-agile UCD brings to process is that it provides tools to create client and user-classes which represent the best, least skewed vision of what the product needs to do to be successful.

This highlights the major failing of assuming that Agile can encompass UCD in a meaningful manner. Agile doesn’t respect abstract, reflective, or modeled processes or group consensus of the user or client-base.

I discussed this with a VP of Engineering and he said that the Agile process is best used once the strategic work has been done to work on individual features for which the business and design goals have already been defined.

http://www.c2.com/cgi/wiki?GoldOwner

How about “…we have come to value researched information about the users and their needs over mis-perceptions propagated by mis-informed teams and clients”?

Well now, that’s not very Agile is it? Waaay too much documentation! Explaining that sentence will take us a whole stand-up meeting! I bet it won’t fit on a card! ;-)
(I must say I appreciate the “mis-informed teams” aspect.)

Oh, and who’s the “official” in “Officially”?

As to Jared’s comment that “deliverables of any UX work has to be for the funding clients” that would imply that a prototype created for a usability test would not be a deliverable (but an artefact?) but the usability test report/recommendations would be?

Officially, all UX deliverables are for the funding clients, including the prototype. If the funding client doesn’t see the value in the prototype, it was done poorly and the UX folk will reduce the chances of ever producing another one.

He also asked:

What would an extra line in the Agile Manifesto look like to make it Agile UCD? “…we have come to value *end-user evaluation* over client prejudice”?

How about “…we have come to value researched information about the users and their needs over mis-perceptions propagated by mis-informed teams and clients”?

Lisa inquired:

I’m still waiting for someone to step in and tell me why they think the client has to be at the table all the time…

In some situations, there are business requirements, real-world constraints, and other needs that only the client would be aware of. This happens when the IT department is sufficiently insulated from the operating activities of the organization. In severe situations, it may make sense to allocate a client representative in the war room to ensure this aspect of the information is factored into design decisions.

The main reason for all these different viewpoints is to ensure informed decisions during the iterative design process. (The iterations themselves are basically scientific-method-style hypothesis checking to ensure all the information has been accounted for.) The contribution of different viewpoints is to accelerate the informing process, in my opinion.

I think that part of the power of this ‘agile UCD’ method is that it does potentially create more balance between the two representative parties – the business ‘client’ and the end user. I agree that quite often UCD methods are skewed too far towards the user… but having said that, far more designs suffer from too heavy influence of the ‘client’ and not enough knowledge of or respect for the ‘end user’ than do from being too-UCD’d :)

I think that another potential advantage of Agile UCD is that there is much less by way of ‘UX deliverables’ or artifacts and much more actual working software/web stuff more quickly produced – the challenge is how to get UX people to work (relatively) comfortably and appropriately in that kind of environment!

I’m still waiting for someone to step in and tell me why they think the client has to be at the table all the time… there are *definitely* a lot of companies out there who play that way and who insist their agencies do too.

Clients representatives rarely need to be at the table at all times, unless they can provide one super-expert on all business aspects of the problem to be solved. But weekly reviews? Yes, please! Reviews at the beginning and end of iterations? Definitely! And access to several experts on *some* business aspects? Always!

UCD allows designers to take in the wishes and demands of end users in many different ways. This is one of the reasons that demanding that end-users get a seat at the table won’t do. But reserving a seat for a user researcher/evaluator who knows the end-users intimately (no matter how she got that knowledge) and can evaluate designs against their wishes and demands (no matter how she does that), might be a way forward.
As to Jared’s comment that “deliverables of any UX work has to be for the funding clients” that would imply that a prototype created for a usability test would not be a deliverable (but an artefact?) but the usability test report/recommendations would be?

What would an extra line in the Agile Manifesto look like to make it Agile UCD? “…we have come to value *end-user evaluation* over client prejudice”?