It has been 18 months now since we officially started the project to build a new ONS website – the most consistent thing throughout our initial discovery, the alpha and now the latter days of the beta has been a commitment to the principle of being ‘user focused’.

Over the life of the project I have taken to [mis]using the term ‘user driven development’ for the approach we have endeavoured to take on. At every stage of the project we have had at least one user researcher dedicated to our work and have regularly undertaken the full spectrum of research activities from lab based usability testing through to unmoderated online card sorts via critical friend interviews and guerrilla testing.

From the start we followed the advice from GDS (nicely summed up in this blogpost from Leisa) about how to integrate user researchers and their findings and priorities with an agile development team and despite a few hiccups it pretty much worked well for us throughout the alpha. The whole concept of ‘user research is a team sport’ was really something we embraced and it had a lot to do with the success of that phase I think.

As the project became considerably more complex during the beta – as we moved from producing a prototype to something production ready with all the additional requirements that brings – it became less straightforward to integrate the insights from the user research as quickly into the development cycle as we’d like.

Now we have never let these difficulties from stopping us doing what we believe is the right thing – and being user focused really is how we define ourselves as a team – but we have finite capacity and are a small team. The juggling act between different priorities and compromises to ensure a constantly improving product (including the back-end) is getting to a ‘Britain’s Got Talent’ level. Pressing issues identified via user research still always get prioritised but the backlog of nice to haves/fix has grown (though if issues re-occur then of course they get re-evaluated.)

I recognised a lot of our challenges in this article by Chris Gray particularly the challenge of participant recruitment and getting support systems in place. We are lucky to have a really engaged audience and especially our online research activities are extremely well supported but participant recruitment for particular slots on particular days is often hard work and time consuming (Alison in the team has been a trooper with this recently!) Especially as the personas we need to recruit for our slightly more specialist perhaps than some other projects.

After a year of managing our participant volunteer list via an increasingly complex spreadsheet (we are ONS – we do things in Excel!) we have just started using a proper contact management / CRM tool which looks like it will make a real difference. The ability to add custom fields, tags and segment entries is going to be a godsend longterm.

The ‘Fieldwork Fridays’ approach that is mentioned in the previous article as being used at Google is probably closest to our model – we schedule research opportunities and then poor Jonathan (our user research lead) works out what is the most pressing research need at the time. We have started to supplement this with more online testing – including some Optimal Workshop products but also Usability Hub and Loop11 as we try to broaden our reach in the run up to the end of the project.

I also found this post about ‘Incremental UX’ interesting recently – again I recognise a lot of the problems it is trying to address and I think without really formally realising it we have been working in a quite similar way for a while now. Starting by providing the ‘minimal positive experience’ to our users as and when we change the UI or add features but always aware of the longer term aims and using the research to keep checking that those aims remain valid.

Like I said about working agile in a previous blogpost ‘user driven development’ might be the right thing but it definitely isn’t the easy thing.