Skip to main content

Why user researchers work in multidisciplinary teams

Multidisciplinary product team in a meeting

As I’ve mentioned before, PDS does a lot of stuff. As well as the six product teams that are working on a new website for Parliament, there are lots of other teams in PDS. They’re building software for people in Parliament to do their job, purchasing software from outside to improve productivity, and commissioning bespoke development work for different parts of Parliament.

These projects need an understanding of who our users are, what their needs are, and what problems the project needs to address to be successful. However there are only six user researchers in our team at the moment so we can't support all the initiatives at Parliament.

This means we have to prioritise what teams we work with. We’ve decided to focus our time on supporting multidisciplinary product teams currently working on the new Parliament website. In this post I’ll explain what a multidisciplinary product team looks like in Parliament, and why the researchers are supporting them.

Working towards one goal

Multidisciplinary teams work towards one goal and are made up of people representing each skillset required to build software or a service. In Parliament, our teams might be front and back end developers, product managers, interaction and content designers, user researchers, performance analysts, a delivery manager, and Parliament’s data and search team.

Each team has a single product they’re responsible for delivering, such as:

Understanding a product and taking ownership

There are many advantages to building things in teams like this. It can bring together experts who understand the requirements of a product. They represent not only the user needs but also business and technological constraints.

Teams also feel ownership over the quality of the product, and are able to make changes. They have everyone they need to be able to make the changes they feel necessary to make sure the product is good, which leads to better quality software or a better service.

Making the biggest impact

Working as user researchers in these kind of teams is hard. It’s much easier to work in a ‘consultancy’ model, waiting for a team to ask for research help then running the research that’s been requested. This avoids having to convince people they should be running research or making sure that what’s learned from research is addressed in future iterations.

However the consultancy model reduces the impact that researchers can have. Teams are often hesitant to ask for research assistance until later in development. By this time many assumptions are ‘baked in’ and can no longer be changed. It also reduces the researcher’s ownership over the product, and their duty of advocating for the product to meet the user need. Ultimately it means products are less effective.

So we’ve decided to focus on supporting multidisciplinary teams in PDS as they represent some of the most public facing digital projects Parliament has, and makes sure the impact of the research team is significant.

Focusing on our core work

It also means the Digital Service is focusing on our core work and the goal of the House of Commons to involve and inspire the public.

By being a member of the product team, researchers can be embedded throughout the lifecycle of these products. This includes the discovery phase where researchers are finding out who the users are and what their goals are. As well as during alpha when researchers can help prove or disprove hypotheses about how we meet user needs, and during beta where we can verify that the services being built are being experienced as intended.

It also means that we can make sure our colleagues are thinking carefully about users in the pursuit of building better things.

Read more posts about user research in Parliament. 

Sharing and comments

Share this page