1. Involve the content team early
This may seem obvious, but when the testing programme started, content designers were only aware of new programme requirements when the solution had already been decided and half signed off.
It didn’t help that services needed to be created at speed and we had all been thrown together with little understanding of each other’s ways of working.
Six months on, when we were working in a more user centred way and resourced with a team of excellent product managers, things were much better. I was invited to initial discussions when new requirements came in, which meant the content team could have a say in suggestions worth exploring, and those to rule out based on insight we had so far.
But this early involvement did not happen every time. Even a year on, we are still sometimes asked to approve pre-written copy sent to us at the very last minute.
It’s awkward asking everyone to rewind so we can design a solution based around user needs, rather than what stakeholders feel we need to convey. It’s frustrating also to the delivery lead who thought we were almost there, and the team who got us to this point, whose work we might not be able to take forward.
Content leads can be proactive in ensuring this situation does not happen. When you’re first starting on a project, identify who all the project leads are and make sure you’re on the invite list for all the key meetings.
2. Beware of content as the ‘quick fix’
There were some tricky times when the content team was consulted within hours of an ‘urgent incident’ so we could resolve it that same day. We were never missed off those invites!
I remember one time in May 2020, when the launch of the NHS COVID-19 contact tracing app was suddenly delayed. We had 2 screens in the registration service for testing that asked the user if they had this app, and if so, asked them to enter their app reference code. These screens were now not appropriate, given the app was not yet available, but could not be removed at such short notice.
I was asked to approve the only feasible solution: a screen that instructed the user who had selected ‘Yes, I have the app’, to go back and select ‘No I do not have the app’ to be able to go forward again. This oddity would not exist for long, but I was concerned that ‘copy changes only’ might set a precedent for resolving issues in what was perceived to be the most efficient way.
Sometimes a content hotfix was needed as a sticking-plaster until we could deploy something better. But I wondered if, with the constant deluge of new requirements, we’d end up never revisiting that content. Also, because of all the new business priorities, a new design proposal to improve the front-end service might never get a look in.
We should at least log design debt and have ringfenced time to systematically address it. This way, we avoid hotfixes bedding in and we do not scale up inadequate solutions.
3. Put in place a senior-level content lead
It worked well to have a team of user-centred design (UCD) leads who met regularly. The team comprised people who headed up interaction design, service design, user research and content.
I wondered why content was not always represented at this senior level on other programmes. Here’s why it needs to be:
We (the UCD leadership team) have been collectively devising a strategy to ultimately improve the experience for users of the COVID-19 testing journeys.
One problem has been that too many people try to use the ‘get a PCR test’ service (mainly for people with symptoms) when they actually need a rapid test (for people with no symptoms). Users do not understand the difference between the 2 test types and they don’t know where to go.
A content lead’s input has been key to resolving this - not just to work on signposting and wording to explain the tests, but to get agreement and alignment across comms, marketing, and the various other teams and publishers on how we refer to them.
It’s also about contributing more generally as a user-centred designer, to solve broader pain points like ‘digital journeys are too long and repetitive’. This might involve, for example, testing a new design pattern that shows the user how far they are into the journey or lobbying for developer time to improve these existing issues.
The person in this role, just like other UCD leads, would be thinking outside their ‘content design’ box and using their initiative to collaborate with other specialists and senior stakeholders to drive forward big-impact improvements. Being across all the content means they’re well placed to do this – they have that high level understanding of all the services.
Let’s recognise the need for a content lead at a senior level. Programmes need more than just a talented wordsmith in charge of approving content.
4. Co-ordinate across organisations
You can imagine how many different government sites and tools publish content on COVID-19. With all the new requirements flooding in every week, it was hard to stay joined up.
A new testing policy would be communicated to the COVID-19 testing team, and we’d go at top speed to update all the content in the online services – for example, when self-isolation changed from 14 days to 10 days. But the other impacted organisations were sometimes forgotten about until the last hour.
By the time the request trickled through to, say, NHS.UK or GOV.UK, they did not always have the resource to make major changes at such short notice.
If you know what’s coming up, you can plan for it and deprioritise to free up resource if necessary. This is impossible to do if you’re not sighted on the roadmap or business priorities, or given a heads up as soon as the requirement comes in.
On a complex project like COVID-19 testing, there’s a need for a central person who can:
- impact assess across all government websites when a new requirement comes in
- engage with all parties
- coordinate the solution and timing of all the updates (“press publish when our release goes live”)
Ultimately, there should be someone who ensures we have content alignment across organisations at any one time.
5. Consider from the start how we build and manage a UK-wide service
Designing a UK-wide service can be incredibly complicated. It needs to meet all the varying requirements of the devolved nations without coming across as ‘England led’.
However, it’s hard explaining to our service users that the policy or process is different if you live in, say, Northern Ireland. It can also be difficult to meet the wording preferences of the country representatives, and consulting with them or keeping them in the loop with every change.
It requires a team of highly organised people with diplomacy and patience. It’s also an important consideration for UCD. Content should be relevant to users and personalised whenever possible. For example, we might need to direct Scotland residents to GOV.SCOT , or (who knows) allow them to switch to Scotland-specific content at the toggle of a button.
But when we do not have a content management system (CMS) and are dependent on releases, we also have to be realistic. Creating a whole Scotland-specific branch of the test booking journey, for instance, would probably not be feasible as it would be too many screens to maintain. If we were to create a dynamic screen that’s different depending on whether it’s England or Scotland it might be 2 variables too many when we already have 6 different versions to accommodate.
Yet ‘catch-all’ content can be baffling for users. Check out this brainteaser:
Next month, I’m leaving the COVID-19 testing programme. I’m currently working on a solution to this challenge, so look out for a further blog on this before I go and do email me with any thoughts or ideas (email@example.com).