links for 18 September 2007 – taking the ‘a-ha’ out of research data analysis

Did you miss out on a dConstruct workshop? Don’t miss out again! :)

You might have read about the workshop I ran at dConstruct recently… it was fun for all and, even better, it appears that people found it valuable and are actually applying it in their day to day work – hooray!

Word on the street is that there may be enough people interested in running the workshop all over again in early December.

The dConstruct website says:

One of the biggest successes of dConstruct 2007 this year were the pre-event workshops. These workshops were small, intimate affairs, so were heavily oversubscribed and sold out quickly. As well as assuring people a place at the conference itself, the workshops provided a great opportunity for people to get the most value from our great line-up of speakers. The workshops were also an excellent way of meeting people and networking before the main event. In fact, one of the most common bits of feedback we got from dConstruct were people expressing an interest in attending the workshops next year.

The sessions themselves were both enlightening and extremely practical. They ranged from theoretical discussions around the benefits and implementation of tagging systems, through to hands on workshops on the creativity and principles of user experience design, replete with group exercises and lots and lots of sticky notes. The feedback was universally positive and everybody we spoke to had a great time.

These sessions were always intended to be one off events, closely tied to the main conference. However we’ve already had a number of people asking if we can run some of these sessions again. So rather than disappoint people, we thought we’d ask your opinion. Drop us an email if you’d like run one of the workshops again, at the start of December. If we get 10 or more people interested in a particular workshop, we’ll try to arrange a rerun.

So, if you’re keen to come workshop in early December – don’t be shy! Email the dConstruct guys and let them know. And, perhaps I’ll see you then!

Who is the customer in Agile UCD?

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 plan

That 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?

links for 11 September 2007 – Intimacy Issues