User research: how does that make me feel?
Hi, I’m Tom Thornton and I’m the Digital Product Lead for the Digital Development Team (DDT) here at the City of York Council. The team develop web apps for the authority, with my role acting as the conduit between the team and the business by understanding what the business want and writing stories for the developers.
I’ve recently been leading on a project with FutureGov to help skill share some of the user research principles that are the keystone to any of their projects. I’ll be sharing some of my thoughts and experiences of user research through a series of blogs, of which this is the first.
The digital development team have been practising agile (scrum to be precise) for over a year now. It’s really helped us to focus on our development processes by offering some structure to how we scope and manage our development work. The only problem was that as good it was for our developers, it didn’t really offer much support for me as a Digital Product Lead. I’d often find myself as piggy in the middle between the business product owner and developers, trying to balance all of the users’ requirements with how the service works, whilst answering enough questions to keep the development of a product moving. User stories tried to offer some qualitative information on how a user would use a particular feature, but looking back, without getting out of the building (actually speaking to users), it never really helped us visualise it.
User research has the answers (and questions!)
We’ve been learning user research with FutureGov for just over 6 months now, and what’s great about the process is how it has given us much more structure when scoping work – just like what scrum does with development. User research takes much more of a scientific view of understanding a situation by evaluating qualitative and quantitative data collected through ethnographic research techniques and then synthesises this information. It all sounds very complicated, but I like to think of it as being a detective. Imagine yourself cross examining user interviews or user shadowing sessions, looking for clues or common themes and then coming up with insights based on your investigations.
For me these insights are invaluable because by researching in to how a user works, I get to see the qualitative information I didn’t get to see before – like user’s feelings about a problem, the hacks and workarounds they’ve developed themselves, or opinions and thoughts on an existing system. Hearing quotes directly from users is powerful stuff, especially when I’m writing user stories, speaking to developers or updating project sponsors. By getting out of the building and actually speaking to users, not just service managers, means that not only do I get to see how a service thinks users work, I also see how users want to work.
Keep with the iterative spirit
User research and scrum aren’t mutually exclusive – user research lends itself perfectly to agile, too. You can run in iterative sprints, just like scrum does, so that your design team is working to the same iterative cycles as your developers.
What became immediately obvious with the adoption of user research is that what we’d been lacking with our user persons and stores was empathy with users – something that scrum can’t do alone!
In my following blog posts I’ll go in to detail on the biggest things I have learn in this process of embracing user research and Lean UX.