We recently presented at the Leeds Digital Festival and Digital Leaders events, talking about our roles and the work our user research and business analysis teams do in DWP Digital.
People at those events were interested to know how closely linked our roles are and how our teams work together.
And the link between our roles and teams is also something that some people within DWP are not always clear about, especially people not traditionally used to working with agile multi-disciplinary teams.
What do both roles do?
From our perspective there’s a natural affinity and close working between the roles. But what do we mean when we talk about user research and business analysis, and where’s the overlap?
A user researcher helps the service team learn about their users to create services that meet their needs. Typically, that is primary research with citizens or internal colleagues. The research methods will be tailored to the audience groups and insight required as well as the stages of the agile lifecycle.
A business analyst provides an analytical view on the current situation with the business area, along with an understanding of processes, pain points and volumes and an understanding of stakeholders.
The links between the roles
A user researcher often needs the business analyst’s work around the organisation’s aims and constraints in place, to conduct an effective gap analysis and plan research to surface insight around users’ needs and behaviours.
A business analyst looks to a user researcher to provide the emotional context, understanding and user insight around the process pain points they may have identified.
The best way to show this is to highlight a couple of examples of when our teams have worked together.
Collaborating on a private beta for customer computers
Work to understand and evaluate users’ experience of new customer computers being rolled out at five pilot Jobcentres showed just how closely our teams work together.
Our user research explored the extent to which these new devices were meeting the needs of both customers and colleagues in the Jobcentres, through observing and interviewing people using the computers in the pilot sites. But a business analyst would often accompany them on these visits.
This meant we were able to not only understand the users’ experiences, journeys and behaviours but also look into the processes undertaken by colleagues, as well as the extent to which the new devices were meeting business outcomes and success criteria.
This meant we had a wider, richer view of the impact and experience of the computers for users, and could identify areas where the user experience could be further improved before full national rollout.
Later on in discovery, we collaborated again on user research and worked collectively to bring our work together in a feature map which illustrated the needs, pain points, subsequent opportunity areas and finally potential solution ideas.
Working together on Tell Us Once
Tell Us Once is a cross-government service that lets a bereaved person or next of kin report the death of a relative once and then shares this information across other government departments.
We ran a discovery to look at whether the existing live service was meeting the user needs. The main focus of the business analyst was to speak to the stakeholders (including Passport Office, DVLA, HMRC, Local Authorities and other DWP teams) to understand the current processes from end to end.
The user researchers focused on identifying and understanding the users of the service and the needs of those user groups. The primary focus was to understand the journey of both the bereaved citizens (who often don’t differentiate between government departments) and the registrars that deliver the service, as well as hospices, charities and DWP colleagues.
The research aim was to understand the journey of a bereaved citizen, not only their interaction with Tell Us Once. The main areas of interest were what people and registrars had to do following a death, how they found out what to do, who helped them to do things, what problems they faced and the role of Tell Us Once within that.
There were situations where both the user researcher and business analyst would need to speak to the same person, but this provided really useful insights to both roles.
The culmination of both the user research and business analysis was fed back to the team and wider stakeholders and gave them the insight needed into the pain points in the process and the impacts of the current service on stakeholders.
Users unite both roles
It’s clear that on their own, user researchers and business analysts have an important role in agile teams.
Both roles bring critical thinking skills, apply evidence and try to understand why things are happening in order to provide the product owner and the wider service team with enough evidence to make a decision in terms of the direction of the service.
The extent to the collaboration between both roles depends on the nature of the project and the questions the team is trying to answer. But when business analysts and user researchers work closely together, it often leads to a better outcome for users.
Like this blog? Why not subscribe for more blogs like this? Sign up for email updates whenever new content is posted!
8 comments
Comment by Alan Helps posted on
Excellent summary of the subtle differences and cross over between the roles. I will certainly refer to, and make use if this distinction. Excellent job.
Comment by Adrian Murphy posted on
Valuable blog on benefits of research and analysis working together for the betterment of designing services and digital products for users.
Comment by Ali Price posted on
Super blog which highlights how the roles interact and play an important role in an agile team.
Comment by Frank Ray posted on
I personally don't agree with delineation you make that user researchers work "front of house" whilst the BA works "back of house".
A good BA when gathering system requirements doesn't just ask "what do you want?". They seek to understand environmental context, constraints around the intended user goals. How is that not UX?
Plus, is there a difference between public users and internal users / staff? Aren't these all just people who have needs, painpoints, emotions, and intended goals in mind? Why aren't they all just 'leveled' into 'a user'?
Comment by Euan Gillespie posted on
Hi Frank. Thanks for the comments. We’d advocate close working between the roles (BAs here routinely support URs on research visits for instance) rather than a “front of house”, “back of house” distinction, and would agree that ‘good’ work under both disciplines requires strong mutual understanding. We’d also expect teams to have a strong understanding of their users and the associated service interactions and impact irrespective of whether they were internal or external.
Comment by Dr Gyles Morrison posted on
As a Clinical UX Specialist, I find this blog post very disappointing and borderline depressing. The truth is, a good user researcher should be doing the work of a business analyst. How can you really conduct research to create a solution without understanding the business needs AND the user needs? The are both necessary. This post is just legitimising the different roles when they should be combined. I am not ignorant to the fact that it would require training for both professionals, But that is what is needed here, especially in healthcare.
Comment by Euan Gillespie posted on
Hi Gyles. Thanks for the comment and valid points. We’d certainly advocate a combined understanding of the business and user needs when designing services. When resourcing teams we often get queries about which roles are required and when. Some of the confusion can also be from the history of the roles, whether that’s a perception of BAs traditionally acting as a link between IT and business areas, specifying requirements, or an intertwining of the need for User Research with the GDS Service Standard. Hence trying to show it in practice with some practical examples of how the roles dovetail here, and highlighting that there might be some overlapping approaches and methods but that they are distinct specialisms. Can appreciate it may vary in different environments.
Comment by Dr Gyles Morrison posted on
I appreciate your response. I recognise that my comment was a bit strong before and you handled your response very diplomatically, so thank you.
It's surely not easy working on government projects, it certainly isn't in public or private healthcare.
Keep up the good work.