A day in the life of – GDS user researcher
One of the joys of working in product management, business analysis or user research is the variety! No day is the same and the mix of activities constantly changes. Welcome to the ‘day in the life’ series where we profile different roles and what they are up to in an average today. Continuing today with a day in the life of a GDS user researcher.
There are many types of user researcher and user research looks different in different sectors. In this article, I am focusing on a user researcher working on a government service. A government service will generally follow GDS – or government digital standard. This means the activities they undertake all work to contribute to progressing through the GDS stage gates.
9am – review incoming feedback from the beta service
Our government service is currently in the private beta phase. This means we have a few select counties using the product whilst we test it and take feedback. We still have a few major features to release before we want to move to public beta. As part of the service, the user is prompted to take a feedback survey at set points in their journey.
I log into our survey tool and see how many have come in in the past day. We try and incorporate feedback as quickly as we can. I scan through all the new responses. The majority confirm some hypotheses which we are already working on. However, there are a couple of responses which are new things to think about. I jot them down to take forward in testing. A couple also look like they could be bugs. I forward them onto my business analyst for him to triage.
10.30am – joining the stand up to hear what’s going on
I try and join the stand up 3 times a week to see what is going on with the development team. We try and keep user research insights very close to what is being developed. They are working on things which we prototyped and researched a few weeks ago so it’s great to see them coming to life. I outline the research which is going on this week and ask if there are any observers. As part of GDS, I try and make sure everyone in the team observes some research at least once within every sprint. It helps connect our dev team directly to our users.
11am – time to start a GDS user researcher interview
We have 3 user research interviews today but I’m splitting them with another researcher. I am currently doing some controlled research in a controlled UX lab rather than out in the field. We have compiled a prototype which has some new features in it. I explain to the user the goal of the service and the structure of the session. I then watch the user work their way through the product and ask questions on what they are experiencing.
It is always tricky to interview different types of people, especially if they don’t regularly share their feedback! I work to make the user feel comfortable and get lots of insights. I fight the urge to instruct them how to do things. It’s always essential to understand what it looks like to new eyes! We record the interview so I can look back over any of the areas where I see they struggled.
12.30pm – compiling notes and observations
One of the business analysts on my team was helping to take notes through the session. I go out and run through their notes, emphasizing where I felt there were some good insights. We highlight the most important things and ones which may change how we implement a feature. It’s clear one part of the journey just isn’t working well. I put in some time with the wider design team to get back to the drawing board.
After a very busy morning, I run out to grab some lunch before heading home to spend the rest of my afternoon at my laptop. I’m often out and about but with local restrictions, it’s easier to go home than to the office.
2pm – releasing top of the mind thoughts to the team from a GDS user researcher
As a GDS user researcher, one of the key principles is to share feedback and user observations as regularly as possible. We have a shared Teams channel which all team members belong to. I write up some of the important insights into quick and easy bite size pieces and share it in the Team. This helps others understand where ideas are coming from. I reply to a couple of responses which has sparked some discussions about other areas of the product.
3pm – writing up user needs and discussion with my product owner
We keep an overall log of user needs which we can reference in our user stories as we go. In regards to the new features, I sit and write up their key user needs. These user needs will really help my product owner make decisions. It helps her keep the users in mind. If a decision directly conflicts a user need then it’s probably something which should be looked at again.
I ring my Product Owner and have a discussion about the testing and new feature design. She wants us to slightly change some of the flow in order to help fit in with a different service in the department. I make some notes as to what needs to change to make sure we get the feedback she needs.
4.30pm – tweaking the discussion guide for tomorrows session
Based on the discussion with my product owner, I decide to tweak the discussion guide I’m using. The discussion guide structures the user research interview and prompts the right questions to ask as we move through. I change a few of the questions and add some new sections in. I ping it off to the other user researcher for their thoughts.
Finally by the end of the day I check the calendar for tomorrow. I’m off on some field research tomorrow too so I plan my route there. No two days are ever the same as a user researcher and I can’t wait to learn more tomorrow! 7
Share this post: