https://pds.blog.parliament.uk/2017/04/26/what-we-talk-about-when-we-talk-about-user-needs/

What we talk about when we talk about user needs

Stickers showing why it's important to talk to users

User needs are mentioned a lot in PDS. They’re mentioned as the first principle of our Digital Strategy. They appear on our posters and they’re one of the most popular categories on this blog. We also encourage new starters to get a ‘start with user needs’ tattoo.

However, we don’t often explain what we mean by user needs. In this post, I explain my understanding of user needs, what starting with user needs means, and how PDS does this.

User needs defined

Government Digital Service (GDS) define user needs as ‘something a user needs from your service to get the right outcome’. For us, the user need is ‘what people want from Parliament’ so we’re building software and services to help meet these needs. We’re making sure that people can use Parliament’s website to contact their MP and MPs can ask oral questions in Parliament efficiently. We’re also improving the experience for people applying to work here, among other things.

User needs are behaviours the software needs to support. Members of the public using MPs' pages might ask, “Who is my MP and what issues can they help me with?”

Whether the service is considered a success should be measured against the user needs. This seems obvious but it’s very common in software development to build what we think users want, rather than what users actually need.

You can discover user needs by looking at people’s behaviour and those needs can always be traced back to real data representing real people. If challenged, a real user need can be proved.

In agile software development, user needs usually represent the big problems or ‘epics’. The software is trying to solve these large problems so that a product manager can then break them down into individual user stories and features.

The meaning of “start with user needs”

“Start with user needs” means understanding what people need from a service before you start building it. It means speaking to users or watching their behaviour, instead of relying on assumptions.

Understanding what to build before you start is important. Not only does it mean that you build the right thing, but it leads to your service being useful and helping people achieve their goals. Understanding user needs reduces the risk that the thing being built ends up ignored and unused.

In the private sector, starting with user needs leads to building successful products. For Parliament, it can have grander outcomes for democracy, by meeting Parliament’s strategy of ‘facilitating effective scrutiny and debate’ and ‘involving and inspiring the public’. It can also save money for taxpayers by reducing unnecessary calls to Parliament’s phone lines and enquiry services.

Finding user needs

Discovering user needs is simple. The first step should be speaking to the users themselves, not allowing Parliament to describe what it thinks users want.

Understanding what they’re trying to do and why they’re trying to do it will find out user needs. Then speaking to users about what they can’t currently do and why they need to do that will uncover more needs.

Other data sources will reveal more user needs. For example, Google Analytics will give an idea of what people are doing, or trying to do, on a website. Speaking to staff who answer customer enquiries will indicate users' intentions. These are user needs.

These activities will lead to a big list of user needs. A product manager can then prioritise these needs and define which ones to address first, leading to a plan for the project.

Challenges for PDS

There can often be obstacles to starting with user needs, some of which affect PDS. These are challenges we’re trying to overcome.

Before we were PDS, we were Parliamentary ICT (PICT). Being an IT department implies doing what is asked of you. Staff don’t want their IT helpdesk to challenge whether they need a printer, they just want someone to fix it. Previously Parliament would commission something and PICT would do it.

In contrast, PDS has the expertise and authority to challenge a brief, understand the user need, and alter the direction of a project. This process is improving but managing the change from a culture of ‘doing what we’re asked’ to ‘doing what users need’ is a shift that PDS is working through.

MPs are busy people and have limited time so a culture of ‘proxies’ also exists within PDS. Nominated experts represent the views of MPs, Lords and other difficult to access audiences within Parliament. Even though our experts have a lot of knowledge about Parliament, they’ll have an imperfect understanding of niche users' behaviours and opinions. Rather than relying on their opinions, their input should be validated through research with users.

Data quality is the final obstacle. Although Parliament produces a lot of data, some data isn't captured or it doesn’t accurately represent historical records. The Data and Search Team have put a lot of great work into improving the data that Parliament gathers and holds.

However Parliament’s data is unlikely to ever be complete and, left unchecked, there's a risk that the user needs are never addressed. PDS will need to find creative solutions for working around the data quality issues to make sure that we’re making useful services that meet user needs.

Despite these challenges, there’s been a huge shift within PDS to recognise that user research can help us understand and meet user needs. This makes it an exciting time to be in Parliament.

Read some more blog posts about how we've started with user needs

Leave a comment