At the end of last year, I began working with the developers on NHS.UK Beta who are supporting the implementation of a new publishing platform for NHS Digital. We asked the content designers to describe their publishing workflow. We then got them to complete tasks to do with publishing, editing and approving content on the new platform, identifying key user needs that any publishing platform would need to support.
One of the most interesting discussions followed my presentation of this research at our show and tell. It was around approaching an internal systems project in a user-centred way and recognising the staff who would be using the publishing platform as ‘users’. I spoke to Emily, our then comms lead, about this.
E: You said that it’s hard to recognise your colleagues as ‘users’.
T: Yes – recognising your colleagues as ‘users’, to listen to their needs and approach an internal project in a user-centred way.
E: Why is it important to do this?
T: If you want to deliver user-centred public services, you need to be user-centred in the way you work and organise yourself. The two things – the end citizen-facing product or service and the means by which we arrive at that end product or service – are not mutually exclusive. For example, the usability of a publishing platform will influence how well content is tagged and linked to other, relevant pieces of content. When you consider the volume of content on a site like NHS Choices, then the quality of the user experience of tagging on the publishing tool is likely to have a measurable impact on how well that content is found.
Tools that don’t meet user needs will also have an impact on productivity and pace of delivery. We have some ambitious targets, so we should be doing all we can to make sure the content designers have tools that help them do their jobs as well as possible.
E: We talked a lot in the early days about user need and system need, and that arguably NHS Choices and other digital services within the NHS have been largely driven by system need. What differentiated our project was that it was user-focussed. Whenever we’ve defined that group of users, we’ve never said ‘us’.
T: If we’re developing or delivering a publishing platform, it has users, and they have needs that are different to the system or business needs. For example, there are needs driven by the fact the support contract for the current CMS will expire, so we need something in place before then. Those are business needs.
User needs are different, because even though they work within the same organisation, the users are people who are actually using the publishing platform. As a user researcher, I need to make sure I’ve identified the users of the system or service. Here, it will be those people whose job is to write, publish, edit and review content.
E: How different does it feel when you’re doing user research with staff? Are you emotionally invested in a platform or not?
T: A user researcher’s job is to be agnostic, and to listen to their users. Our job is also to listen to the needs of our team and to make sure we’re researching the stuff that will help them the most. If we can’t strike that balance between doing research and feeding back in a constructive way, then something has gone wrong. It’s about occupying that middle position where you bridge the gap between your team and your users, whoever they are.
And it was a powerful experience for myself and the developers to dedicate this time to speaking to the content designers and understanding their process. It’s already had an impact in our wider team when discussing the content workflow during sprint planning, as the research has created more empathy.
E: Something like this takes time, which is a criticism levelled at user research by all sorts of people. How do you do this in a way that means that we get to the CMS we need within the timeframe?
T: There are so many, proven examples, that if you don’t take the time to understand and meet user needs, the time and the expense of fixing things later far outweighs the time and expense of listening to users at the beginning.
And we’re agile in our approach. We ran 30 min sessions, we did the research and analysis in one day. The developers watched the sessions and did the analysis with me, so had a clear understanding of the changes we’d agreed and the rationale. We turned these changes round in less than 2 days.
E: What are your next steps?
T: We need to do more user research.
We need research that’s grounded in what people are actually doing when they create, publish and edit content. If you focus on this level of detail then you uncover the things people might not think to articulate, but that can have a massive impact on their workflow or process.
By doing this, we can understand where the publishing platform sits within the wider landscape. The users will be shifting between other channels, they’ll be using email, they’ll be talking to people. We want to understand the conversations they have, what happens when they talk to the clinician, when they’re trying to sign-off content. That’s where the real opportunities in digital transformation are – understanding the full, end-to-end, cross-channel thing, the full context of use, and then seeing where can digital help. That’s really exciting.
Not only was it really fun working with colleagues, it also feels like a really constructive thing for the team. We’ve just reorganised, so we have two teams coming together. Doing this piece of work feels so important in terms of facilitating that. Making an organisational change requires more than just a rebranding exercise. When you’re involving colleagues, listening to them and making changes based on what they say, I can’t think of a more powerful way of facilitating the cultural and organisational change that’s needed.