This weekend I went to BarCamp and it was great. Always good to catch up with fellow campers and hear what’s on their minds.
What was on my mind this weekend was DIY User Research – you can see my slides above. This took me a little out of my comfort zone as I resolved not to say ‘it depends’ but to make some overall recommendations as to how almost anyone can afford the time and budget to do a little research, and the best ways to spend that time or budget.
This has been based on the experiences I’ve had recently doing User Research for start up companies who have very small amounts of time and money, but who desperately need the kind of research that I’ve recommended. The techniques I’ve suggested here have worked very well so far, although I hasten to add that I’ve undertaken the research work myself.
This is not to say that you can’t *really* do it yourself… if you use the right techniques you will get a LOT of value from DIY research… but an experienced researcher is, of course, worth their weight in gold :)
I was very happy to have the opportunity to hop up and share my thoughts on Ambient Intimacy at the Future of Web Apps conference in London yesterday. The slides are above.
This is a bit of a move on from the talk I presented earlier in the year at Reboot – a little lighter on the ‘theory’ and a little more emphasis on the practical impacts of designing for Ambient Intimacy.
There are still vast untouched areas on this topic that deserve a lot more attention (and perhaps we’ll give them some in the near future) – in particular, ideas around privacy and ‘containing’ ambient intimacy need to be addressed in much greater depth.
I’d be really interested to hear your throughs on this or anything you can glean from the slides above. (I’m really going to have to do one of those audio slideshare things soon… everything will make much more sense, I’m sure).
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!
I had the opportunity to present a talk on the power of iterative methodologies over waterfall at dConstruct last week (a.k.a Waterfall Bad, Washing Machine Good). This is an extended re-mix of a talk that I gave very briefly at the IA Summit earlier this year (I also presented a similar talk at UX Week recently).
I will put my slides up as soon as I can get the file size low enough to get them loaded on SlideShare – will need to get in and optimise those post-it note photos I’m afraid! In the meanwhile, here’s the slide that most people have expressed interest in!
Not to make any excuses, but this is a really tricky talk to give. To get to the meaty bit – the bit where the UCD and the Agile come together, requires a base understanding that Waterfall methodologies (or sequential methodologies) suck, and that iterative and incremental and collaborative/cross-disciplinary methodologies are the way forward. It also requires that you have a working knowledge of Agile.
Lots of people assume that everyone has both of these things, but I can assure you they don’t. If everyone *knew* this, then there’d *be* no waterfall shops out there, right?!
Nonetheless, the most interesting part of this talk is getting down to tin tacks on HOW we can give Agile more UCD flavour – to actually integrated UX activities into a sustainable agile pattern. And this can be pretty tough.
I have to say that while I’m 100% committed to the overall idea of Agile UCD being the methodology of choice, I’m more or less committed to some of the assertions I made in my talk… (is this naughty? I just wanted to take a position for the sake of conversation, and I had plenty of those post-talk!)
For example – one of the things I said was that I think that Agile cycles (or sprints or whatever you call them where you are) need to be longer than 2 weeks. That it takes that much time to fit UX activities into a cycle. I *think* I believe that this is true, if you’re going to do solid UX work in an Agile environment as well as be there in a ‘paired’ environment getting the functionality built. More than one person suggested to me later that perhaps the same end could be achieved by just doing less in a two week sprint. Perhaps.
I don’t think there are any clear rules on this yet… at the end of the day, what I *do* want from this discussion is for UX practitioners to feel comfortable engaging in the discussion about how long a cycle should be with the rest of the Agile team and to not back away from the discussion when rebuffed with a simple ‘well, that’s the rules’, or ‘that’s just the way Agile works’ argument. Again – if your team doesn’t do this then consider yourself fortunate. There are lots of designers out there trying to eek their way into an established Agile environment who come up against this kind of resistance all the time.
There was another series of questions that I got from LOTS of people – and a very valid and important questions they are too…. I’m not sure I have the best responses so I’d love to get feedback from you on what you’d do and say.
The questions are around how do we sell Agile UCD to our organisation and to our clients? How do we manage the fact that this agile approach takes away the security blanket of knowing what you’ll get and when you’ll get it that Waterfall apparently provides.
When I was talking with people about this at dConstruct, I found myself saying these two things repeatedly, and it seemed to elicit nods and smiles and general agreement/enthusiasm.
The first is that whilst in waterfall you might know what you’re getting at the beginning – you have no reason for confidence that you are getting the *right* thing at the end of the process. And, in Waterfall, there’s no real mechanism for changing your mind or learning from the project itself as you go. You can very easily end up with the wrong thing, and then spend a whole bunch of time and money changing everything around so that it’s right – and you’re changing things at the most difficult (read: most expensive) time to be changing things!
So, what this means is that the ‘security’ that Waterfall appears to offer is really, in many cases, false. And although the budget for the project may be fixed at ‘x’ – no one knows what work will be required once the project is completed to get it into it’s correct state. Or the cost to the business of not having got the project as good as it could have been.
The second point is that we can ‘charge out’ Agile in a very different way to Waterfall. Although it would be nice, your client doesn’t *need* to commit to months and months of development work in an Agile environment. They don’t need to commit to the full budget. In fact, they *could* potentially just commit from cycle to cycle. Your company/department can calculate the cost of a cycle, then with the client, negotiate what work will be undertaken in that cycle… rinse, repeat etc.
Of course, this is not really the ideal way to be running a business and you’d hope that, over time, as your clients got more and more clued to the benefits of working Agile rather than Waterfall, they’d be more willing to make longer commitments to the project, making your cash flow a little less precarious!
Fact is though, you do need clients who are clued into the benefits of Agile and Agile UCD for their projects. If they don’t get what’s in it for them (and there is plenty!) then there’s no way you’ll sell them on it. So, knowing those reasons yourself and then educating your clients is a big part of the process.
It’s not easy though, and we’re not going to be in a state where we can be all happily Agile UCDing tomorrow, next week or even next month.
It is, however, without a doubt the ideal way to run your projects. It’s going to require a lot of thought, a lot of work, a lot of trying things out, and a lot of educating our clients and other people in our organisations.
I think it’s going to be worth the effort!
In the meanwhile, lets start sharing ideas and experiences.
How would *you* answer these questions? What questions do you have? What’s been your experience with Agile and Agile UCD?
My name is Leisa Reichelt. I am the Head of User Research at the Government Digital Service in the Cabinet Office.
I lead a team of great researchers who work in agile, multidisciplinary digital teams to help continuously connect the people who design products with the people who will use them and support experimentation and ongoing learning in product design.
If you're interested in working with me or would like to talk more please email me