Hi, I’m Jude Eccles, a user researcher at DWP based in Stockport.
I’ve worked on digital projects for three years.
In my role I’m used to working in relatively short design sprints, and tight deadlines are common when organising research sessions, for example.
In my team we’re always looking to innovate and iterate the way we work so I was excited when we decided to experiment with running a week-long design sprint - an idea first used by the Google Ventures Team.
Keeping user needs at the heart
The reason we wanted to do this was to identify, build and test different options to solve a problem, and push ourselves as a team to work in a different way.
However, my excitement was balanced with some reservations. By working within a week-long design sprint, I wondered how we could ensure user needs were fed into a user-centric designed prototype that could be effectively tested in such a short timescale?
User research is a team sport
Everyone who works in digital projects has heard the phase “User research is a team sport”. Well, during the design sprint and since, this has never rung more true on our team.
In a digital team, the user researcher is a specialist one often described by others as the one where you, “go out and talk to people” or “test to see if something works” with little understanding of the preparation and thought process that underpins any research session - the how, why, when and who with. This week-long design sprint experiment gave the team the chance to see and get involved in everything we do as user researchers.
Actively involving everyone in the team
With our day jobs on hold during the sprint everybody was actively involved in focusing on the user research I shared with them. There was definitely an energy in the room. This sparked conversations helping us to collectively understand the issues, processes, insights and needs which ultimately fed into the building of prototypes.
The week was split into four elements: mapping the problem, identifying and designing solutions, building prototypes and finally testing them with real users.
Once the prototype was built there wasn’t the usual handover of ‘the thing’ for user research to test but a genuine willingness within the team to see this through and with the support and some quick training sessions from the user researchers everyone played a valuable part from observing, role playing, note taking and analysis.
What we learned
After the design sprint there was a definite shift in the team dynamics - we all understood how and why users interacted with the service and how this had influenced our next iteration as well as an appreciation of each other role.
We met some challenges along the way including: getting enough users to come and test at such short notice proved tricky, bringing everybody up to the same level of knowledge was time consuming and not always easy for everybody to understand, and finally we tried to build and test one too many prototypes which was too much of a stretch for us as a whole team.
Despite these challenges, we still achieved what we set out to do. But for me, the positive side affects of the whole process continue to ripple through the team and the way we work.
As a result of the design sprint everyone has an appreciation of what the user research role is and has actively sort to get themselves involved in coming out and doing research. This is just the start and we will to continue to foster the enthusiasm within the team for getting involved in user research.
1 comment
Comment by Emilene posted on
This sounds like a really great way to get the team working together towards one goal. Thanks for sharing this Jude.