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:
- the new MP pages
- a way of petitioning Hybrid Bills
- a guide to how Parliament works
- the new search for Parliament
- new ways of finding Parliament’s reports
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.
Comment by Bita posted on
Very clearly explained and useful to know. Thank you!