Making users true development partners

Stacey Phillips, Delivery Manager at dxw digital discusses why end-user research is key to digital project success

The projects we work on at dxw can start at any point of a product or service’s lifecycle. Sometimes we’re building brand new services to meet a policy objective or regulation, replacing existing systems or iterating ones that have running for some time. Wherever the initial idea for work on a digital product or service comes from, we believe it will only be successful if its design is informed by well executed and thorough user research.

In this context, it is important to bear in mind that service design isn’t just about the front end. It is about the whole entity – what goes on behind the scenes as well as what the end-user sees. Putting a brilliantly designed service in front of a clunky and poorly thought out back-end system won’t fix inherent problems. The real solution is not to build those problems in the first place.


Keep users at the centre of development

No new project should be designed, and no existing service tweaked, without research with real users that establishes both the need and guides development. The first rounds of user research should be done before a single piece of code has been written.

Users shouldn’t be bookends in the development process, where the service is shaped by senior stakeholders and management and then put in front of a small group of people for testing weeks before it goes live. By taking this approach, you are not understanding users’ needs and whether the service or product you’re building is meeting them. You are mostly identifying pain points and bugs, which are more difficult to fix at this late stage of the project.

The right approach is to ensure that there is user input throughout the development of a product or service. In a truly agile development environment this shouldn’t add any time overhead, as user research, design and development work take place in parallel. For teams who aren’t used to working in an agile way and haven’t done user research before, it may be more challenging.

At dxw we carry out user research on all our projects every sprint. This means talking to users and testing prototype (or live services) with users every two weeks. By taking this approach, we can get regular feedback, validate our assumptions and make sure that we’re meeting their needs throughout the development process. This helps us avoid inadvertently doing things that users will find difficult or counter-intuitive, and which could be time consuming and expensive – or even impossible – to fix further down the line. In summary, we see users as true development partners, and we really do work together as a team.

User research doesn’t end once the service has gone live. It should be ongoing. Even the most user-focussed services and products can turn up unexpected issues once they are out in the wild and being used. Some of these issues or pain points might be easy to address, while others will require further research and testing until we’re meeting users’ needs.


What does good user research look like?

We believe that research, as it’s been done in the past, has often taken too much of a standardised approach. It’s involved doing in depth studies over a period of months, writing lengthy reports and sitting people in a room to talk about a set of pre-decided discussion points with a questionnaire thrown in for good measure. This approach doesn’t give us the outputs we need, it can be time-consuming, restrictive and also give us one-sided or biased findings. It tends to rely on the project team’s agenda rather than being driven by user needs.

Consider, for example, the development of a new digital service to replace processes that are currently manual. The published guidance on how do to these processes may well not be reflective of the real world. People always find workarounds for the parts of a process that are convoluted or impractical. Simply holding a few focus groups won’t give you the whole story. You won’t understand the context in which people are using the service or how they use the service. Users will also most likely tell you what they think they want, and you won’t understand what they need.

It’s important to bring in user researchers who can use a mix of techniques and skills to combine qualitative, quantitative and observational data into really useful, actionable findings. It’s important to bring in specialists who are impartial and have the skills and experience to carry out research. At dxw our researchers come from a range of backgrounds, including highly skilled social anthropologists and human factors engineers.


How much research is enough?

Assuming that an organisation has made the decision to embed user research throughout a project, and to bring in specialist skills, there is one further question to answer – how do you know when you’ve done enough research?

The definition of ‘enough’ can be elastic. It can change over time depending on how far the service has developed, whether it’s meeting user needs and how complex particular elements of it are. This is something the whole product team, including researchers, will be monitoring to assess performance and identify any unmet needs.

Successful user research isn’t about setting and meeting quotas, or about arbitrarily dropping research into a product development cycle. It is about placing user research on an equal footing with development, embedding it in the development process. It’s also important that researchers understand product development, and that designers and developers understand the importance and role of user research. Users should always be at the centre of any work being done to a product or service they use. We should be treating them as development partners.

Related reading