Have you read the Agile Manifesto lately? If you’re doing Agile work then hopefully you’ve come across it. I always find it a really good touchpoint to come back to when thinking about what *is* and *isn’t* Agile – much more useful than looking at how any one particular flavour of Agile or one companies interpretation of a flavour of agile can be!
At any rate, here’s a refresher. The Agile Manifesto says:
We are uncovering better ways of developingsoftware by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
Seems almost straightforward, doesn’t it :) Deceivingly so, of course. There’s all kinds of complexity wrapped up in that simple manifesto, some of which we touched on recently and which requires so much more exploration.
Add in the UCD (User Centred Design) aspects and the questions only multiply!
Let’s start with this really easy one – who is the ‘customer’ in Agile UCD?
I would hazard a guess that your response would depend on whether you’ve been doing more Agile or more UCD lately.
If you’ve been doing lots of Agile lately, your answer would quite likely be that the ‘customer’ is the person who is paying the bills. The company or department who has commissioned the work that you’re undertaking. And that, as such, they essentially get a seat at the table as the development goes on, to have their input as decisions are being made minute to minute, and to request changes as they see fit. With any luck, this person is actually a real decision maker within their organisation and their input won’t be completely over-ridden as soon as your work is presented to the wider client team.
If you’ve been doing lots of UCD lately, then your response will probably be quite different. You’ll probably be thinking that ‘customer’ means ‘end user’ – the people who will ultimately end up as the beneficiaries of all your hard work. The people who you’re observing in order to generate your design work and who’s needs and characteristics are influencing decisions about the product functionality.
They’re two very different types of customers, aren’t they. With very different demands and expectations and requirements of you as a designer or developer of a product.
So, what to do?
Well, frankly, in Agile UCD, you need *both* of these types of customers. A successful project takes into account both the business requirements and the user requirements and having direct input from both sources directly is incredibly valuable.
Is it really necessary and valuable to have a member of your ‘client’ (which is what we’ll call the people who pay the invoices you send for this work) as a part of your day to day project team? I don’t think so. I think that ‘clients’ should be highly involved at the beginning and end of each iteration/sprint and on call throughout this time, but I don’t think that either the project team or the client gets much out of them having a permanent seat on the development team. I’d much rather see the team being left to get the work done and the client doing whatever it is they do best – which is very rarely being part of a design or development team. (Hands up if you think I just committed some kind of Agile heresy?)
On the other hand, one of the key reasons for moving Agile to Agile UCD is to add in involvement from actual end users. Traditional flavours of Agile simply haven’t allowed for the type of observation that we do in UCD and that serves us so well as designers to be included in the Agile process. This is why we are seeking to building in scope for contextual research and usability testing activities as iterations occur – rather than just at the very beginning of the project and at the very end.
So, in fact, there are two ‘customers’ in Agile UCD – but perhaps we’re better calling them the ‘client’ and the ‘end user’. One of the challenges of working out how Agile UCD should work is to determine the best way to involve each of these parties in our cycles of work so that we get the best from them and they give us the information and insight we need to do the best work we can.
You’ve seen some of my ideas about how this might work… what are your thoughts, ideas and experiences?
I’ve long thought (long = way before Agile) this is a flaw in UCD thinking. Customers are *rarely* end users, except in consumer goods and services, which most UCD folks don’t work on. (Go to any usability event and you’ll find less than 20% of the attendees work with consumer goods and services.)
The deliverables of any UX work has to be for the funding clients and they have to clearly see the benefits to their bottom line. When users don’t pay for systems, this becomes a difficult argument to make.
As with many other flaws in UCD thinking, Agile doesn’t introduce new problems — it just amplifies the flaws that have been around forever.
— Jared
In my opinion, the customer generally has to be the client or business stakeholder, because they play an important role in prioritising user stories in the release plan / product backlog and so ultimately have to make the decision on whether the acceptance tests hav ebeen passed. Now, one of the acceptance tests might be for some usability measure. In which case, some appropriate user testing may be necessary. That’s where the end user can come into the equation.
That’s what I think anyway. I tussled with similar dilemmas when I first encountered Agile, but the power of client-customer control over priorities is one of the most empowering things about the methodology in my opinion – just as long as you have the right kind of influence on them.
And I agree that I don’t believe you need the customer throughout – but keeping them close to hand is often critical to efficient story completion.
I agree that the two types of “customer” need to be separated.
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”?
ok. so I’m getting the feeling that we’re all broadly in agreement here :)
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.
Peter B. wrote:
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:
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:
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.
Jared wrote:
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”?
way way back, before the coining of the term Agile, back when XP was discussed on the C2 wiki .. this particular issue was explained through the use of two terms: Gold Owner, and Goal Donor. Two different roles, and it’s the latter which is the customer.
http://www.c2.com/cgi/wiki?GoldOwner
It is OK to say that the client should sit at the table if you are designing a client. The problem is that any development done for shipped versus bespoke product has many clients. You can’t have one client as their needs are not necessarily the needs of the many.
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.
Karl wrote:
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.
Jared wrote:
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 can see many roles for agile thinking in a strategic process. The obvious one is the fast production of concept proofs, akin to what car designers do with clay models. Rendering ideas quickly always has advantages when exploring various strategies.
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.
Hmmm…maybe we are in agreement. It sounds like you are advocating agile be used to do a subprocess which quickly provides results which inform the overall strategic process. I think the question is whether agile processes can be applied at the strategic level. I don’t see it applying as a strategic process, only as a tactic for short-term goals.
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