2014 – 15: What I’ve been up to at GDS

GOV.UK

I’ve been quiet (blogging wise) over the past year. It’s not because I’ve had nothing to share. Quite the opposite in fact.

I’ve been really busy doing two things:

  1. Working for Government Digital Service (GDS) – which is why my writing style is significantly more terse than it used to be. (I think that’s a good thing.)
  2. Hanging out with really brainy and out-the-box thinkers at BBC R&D, where I do stuff I can’t talk about and which is fantastically interesting.

But I can talk about GDS.

GDS: an empathy strategy

At GDS, my brief has been, and is, this: help people from across government develop empathy for their end users. I need to make it so easy for people to get to know their users, they can’t help themselves. I also need to make it easy for user researchers to help their team members get to know their users.

Sounds wooly, but, as with most strategies, the tactics are very practical.

It must said, Leisa Reichelt, Head of User Research for GDS, is the mastermind of the ’empathy strategy’. She is, as ever, fantastic to work with.

I delivered GDS’ first in-house user research lab

First off, I delivered an in-house GDS user research lab. As a result, I’ve become a bit of an expert in user research technology. The lab’s been a resounding success, I’m chuffed to say.

GDS in-house user research lab: viewing room

We built a lab not just to give researchers and participants a more comfortable space to be in – or because we had a hankering for fancy gadgets and crisp video clips, even if both are very nice – but rather to give project team members, senior managers, stakeholders (and anyone else we can get in the door) a space in which to get to know users first hand.

This year, I’m building a second lab

The first lab is fully booked – we could do with more space. Also, our first lab’s A/V rack has the technical capacity to support a second lab.

We’ve been given the budget and go ahead to build a second (much smaller) in-house lab for GDS. I should say, that’s if physical space is forthcoming.

Top tip: make very good friends with your building’s Estate Manager. Also, make friends with building security. I speak Hindi – our Nepalese security staff love me and it’s definitely been handy.

Labs: the fight for space is a common one

I now talk to people around the world about building research spaces. The most common blocker is getting the physical space. Yet, where space has been given, sentiments like this abound:

From a financial point of view, an in-house lab is much more cost effective than paying for external labs. In the case of GDS, by up to 25%. Boggles me that meeting rooms aren’t given up more readily.

Walking meetings FTW. Give meeting space over to research!

(Join the picket line.)

I’ve been researching user researchers

I’ve been user researching GDS user researchers. It’s all very meta. I’ve spent the past year surveying them, spending time with them and, on more formal occasions, interviewing them. Suffice to say, at this stage, I know a hellavulot about them.

The stuff I’m learning is helping me plan and deliver user research communications and tools, amongst them, a user research repository.

The aim of my work is to encourage a greater sense of community and improved ways of sharing and storing research stories. I tend not to talk about data these days. My focus isn’t on numbers and reports, it’s on stories. Stories about people – the people who use government stuff.

A user research repository: stories not data

User research labs are first and foremost an empathy tactic. The stuff a lab produces, namely its video, offers another opportunity to get people watching users, and, importantly, offers an excellent opportunity for research efficiency.

I’ve completed Discovery on delivering a GDS user research repository – though it’s highly arguable that there is such a thing as a ‘completed Discovery’. Soon, budget forthcoming, I hope to implement a pilot/Alpha.

Discovery has included:

  1. Learning all about our user researchers
  2. Looking at potential repository solutions
  3. Learning about broadcast and audio-visual technologies: formats, proxies, ingests et cetera et cetera
  4. Getting to know the ins and outs of Cabinet Office infosecurity and server requirements (our repository will be an OFFICIAL-SENSITIVE data store)
  5. Procurement and budget – a veritable soul bender

Some things I’ve learned:

  1. Easy and quick access and editing of video clips. Our researchers spend at least 4 hours a week sourcing and editing video clips for show-and-tells. Across a team of 20 researchers, that’s about 80 hours a week. By streamlining our video editing process, we’ll save at least 40 hours a week of research time across the team. Every researcher will have at least half a day more per week to spend more productively.
  2. Agile killed the video star. Outside of preparing clips for show-and-tells, our researchers rarely revisit videos. If you don’t know exactly what you’re looking for, video’s just too time consuming. Also, because sticky notes are written during research and analysis done the next morning, when memory is still fresh, referencing the session video is unnecessary. A brief research report is written up, with key learnings, quotes, hypotheses and actions, and the team moves on. The video becomes an ultra-heavy-weight record. It can’t sustain the journey in agile. It’s stored, because we know it’s valuable, but, outside of clips for show-and-tells, it’s rarely looked at again.
  3. Recycling research and context. Analysis of research is all about context. A researcher will plan their research around trying to find out about specific things. They may remain open to learning about other things, but, generally, a researcher will stick to their focus. Their research analysis and documentation will also focus on their context. If we only store written research reports, which typically present data relevant to the project context only, we’re potentially losing a lot of really good user-interaction data, or video of people doing stuff, which might be useful to someone in another context, even if years down the line.
  4. Making quantitative use of qualitative data. Imagine if you could search thousands of hours of user research video. Perhaps you could search, and see and hear for yourself, how a particular demographic engage with a particular topic or design pattern. You could, for instance, line up and review dozens or even hundreds of clips of people filling out a password field. By capturing all our video in one place and making it searchable and ‘light’, we should be able to make quantitative use of our qualitative data.

Building communities and keeping the conversation going

I’ve also been supporting the sharing of information and building of a cross-government user research community by running the editorial process for, and doing all the editing for, the GDS user research blog. I spend a good deal of my time reading about research methodology. I’ve learned a lot.

Then there’s also the work of overseeing the ‘content ethos’ of our user research week notes, which are shared across government once a week. (In fact, I really need to pay attention to those again, give them a bit of a brush up.)

And I’ve recently set up a cross-government and -industry user research technology email group and meetup, which we hope will get the conversation going, and lots of sharing happening, around user research lab technology, and other kinds of user research tech.

User research: what good looks like

In spending a year at GDS with some of the best user researchers around, I’ve become well-versed in what makes a really excellent user research team tick, and what good looks like when it comes to (agile) user research.

Along the way, I’ve also learned what really good agile looks and feels like. I’ve learned that you cannot run truly agile without a complete and working-together team: a user researcher, a developer, a designer, a content person etc. – they must all be there and working in sync.

Much to say, little time

I’ve learned a whole lot more than that, but for now, those are all the words I’ve got. It’ll do.

Here are many more words, which I wrote for various GDS blogs over the past year.

Things I wrote last year

Why white is not a lab’s best friend, Feb 2014

Our GDS user research lab is 6 months old, Dec 2014

Vertical campfires: our user research walls, Sep 2014

Desk chair and eye tracker combinations: valid concern or wild goose chase?, July 2014

Why we built an in-house user research lab, June 2014

One-way glass: what we’ve learned from our London lab friends, March 2014

The best colour for viewing room walls, April 2014

One comment

  1. Pingback: User Research Labs: designing, building and managing

Add your thoughts