There’s a fascinating post up on the the UK Government’s Digital Service blog. Leisa Reichelt talks about how they’ve incorporated user research into agile teams in some detail. There are some interesting principles at work. They’ve abandoned the idea of a central group of researchers working across all teams, and replaced it with user researchers integrated into each team. But the interesting approach, from a  service design perspective at least, is that they tie design very, very closely to repeated doses of user testing and interaction:

The ‘Two week rule’. We don’t design anything for more than two weeks without watching real end users interacting with it. This means that most teams are out in the field or in the research laboratory at least every fortnight, putting our design and content in front of potential end users.

Some of their methods for exploring and capturing research are elaborated on by the author in a comment on the post:

In short, we capture findings to post it notes during the user research sessions and then use those to do an affinity sort (you can see an example in the picture above), grouping similar things that we observed or heard people say or do together. Each of those groups then generates two things – a research finding that we capture into a research library (they’re the pink post it notes) and actions (the orange post it notes), that go into the project back log to be done in the next sprint or to be planned into future sprints.
Part of the reason that we do this using post it notes is that it helps make this process collaborative – we often have half a dozen people participating in the analysis sessions on the project I’m working on. We find this really helpful because it helps make sure that we all agree on what we actually saw in the study and what we think it means, and then we can quickly work together to decide what we need to do about it.

What’s most impressive about this approach – other than the fact they’re sharing their experiences so clearly – is that this is a huge organisation – a government, in fact – allowing a central part of its web operations to abandon the traditional, silo-ed approach to skills and project resourcing, to build something that is quick, agile and responsive, in every sense of the words. This is just not something that you associate with the cold, clammy hand of public bureaucracy.

If these approaches work for governments – what company couldn’t benefit from them?