The user test participant was standing in the front door, holding her wrist. She was about 10 minutes late for the test and we had been getting concerned. We had a tight schedule of user tests to get through that day — six participants in total, with another six the following day — we couldn’t afford to run late.
About 5 minutes after the test was supposed to begin we had phoned her; perhaps she couldn’t make it or she’d be caught in traffic. But she didn’t answer. We called the recruitment agency and they couldn’t get through either.
We were preparing to write off the test when she arrived; “I’m so sorry,” she said, “I fell on the way in.” She explained that as she was walking to the studio she had tripped over a loose paving stone.
She was also very heavily pregnant. So, naturally, she was quite shaken by this.
We invited her in and offered to call a doctor, but she insisted she was okay, and she wanted to go ahead with the test.
We threw out the prepared test and asked her if she wanted to report the broken pavement to our client — a local civic council. For 30 minutes we observed her navigate, and search the site for the right page. When she eventually got the submission form, the structure, content and questions asked were so detailed and confusing that she was unable to submit her report.
At the same time as we were conducing these user tests we had an active survey on the client’s site. The survey had been live for about a week and had already collected over 200 responses. By the time we took the survey down (after about three weeks) hundreds of people who submitted their feedback; but one stuck out and has stuck with me ever since.
In the optional verbatim field one person wrote a harrowing story,
“I was homeless for years, I got into a relationship and we started renting. Now my landlord’s bankrupt and I can’t find accommodation. I don’t know what to do.”
We needed to understand how this person come to submit this story to the survey. Using the site’s analytics we were able to see how they navigated the site, what pages they visited and what terms they searched. What we discovered hit us hard — we could tell from the analytics that they had visited the right page, they had visited the page that contained the information that they could have used to get support.
But they spent fewer than 2 second on that page, and visited half a dozen more, seemingly still looking for help.
I’ve thought about this project, and these people ever since; and the power that I had as a designer to help make their circumstances better or worse; and specifically the responsibility I had as a Content Designer. These people, and many more, suffered because of poor Content Design.
When this local council asked us review their recently redesigned website we did the usual design tasks. We conducted the usual research activities — user testing, stakeholder interviews, site analytics, survey, we interviewed call centre staff and those involved in the earlier redesign. They were on a long journey of improving their digital services, and were eager to help them.
From this research, and especially these two candidates, we came to one conclusion — for this site to be a success we needed to focus on the content.
Yes, the IA needed to be improved, as did the interactions and visual design; and the underlying technology that supported the site needed optimising. But we knew that if we didn’t put content to the fore then people, like our survey respondent and user test participant would continue to suffer.
But this wasn’t what the client had signed up for. They wanted a new site, not new content.
Equally, it wasn’t practical to bring a copywriter into rewrite all the site content. There simply was too much content to write and this content was constantly changing.
A traditional approach of redesigning the site, and migrating over the existing content was not good enough. We knew from the research that people didn’t understand the content and, worse, couldn’t easily action it.
We needed to address the content as our primary concern. This didn’t mean that we’d ignore the IA or interactions; instead, we would design the content and the IA together and build the interactions around these.
But to do this, and to do this at scale we needed to redesign how we, or rather, how the client was to create content. For this to work at the scale needed, we had to empower the client to create and manage user-focused content. We needed to give the client the processes to create content over the long term that would meet customers’ needs, and was easy to create and manage. We needed to rely on Service Design to do this.
One of the big problems that agency UX teams face over internal UX teams is their focus on short-termism. This is a natural byproduct of how agency UX teams are designed – their work is booked months in advance, and they often have an eye on the next project. This can often lead to design work that isn’t set up for long term success.
We wanted to overcome this, and to do this by empowering the client to produce their own copy.
Content as a service
But to do this we needed to move the client away from thinking of content as a product (something that’s produced as a once-off) towards thinking of content as a service (something that’s constantly optimised).
So we leaned on our Service Design skills and designed a capability-building content workshop.
With this workshop we wanted to do two things,
- Produce a first draft of improved, and client-written, content for the new site.
- Train the client’s digital department in this methodology, so they could run this same workshop with other departments after our engagement with them had stopped.
To do this we decided to use a single department as an example. We chose the department responsible for housing policy; partially because we wanted to help people like the person who submitted that survey response, but also because we felt that there was an acute need for improved content in this section of the site.
The workshop worked like this; we invited 25 member of the housing department into our studio and we took them through the research we had conducted. We did this to help them build empathy for their users, but also to show them the power that their words could have to make others’ lives easier or more difficult.
We then split them into five groups of five and asked each group to list as many services that the housing department provided. When each group was finished we asked each group to present their list of services.
From this we established that the department provided about half a dozen individual services.
Next, we gave each group an individual persona, and a corresponding user journey. We asked the groups to list the different types of users who have availed of their services in the past.
We then asked them to complete job stories for each of these users for each of the seven services. So, this looked something like this,
When _____, I want to _____, so I can _____.
Our participants created nearly three dozen statements. Which they presented to the wider group and we narrowed down into about 10 individual statements.
Finally, we assigned two stories to each group and asked them to produce a series of bullet-pointed lists for each of the following questions,
- What is this service?
- Who is eligible?
- How do I access it?
- What else do I need to know?
From this we got our first draft of content for the housing section of the site. We then asked an individual member of the housing department to review each of the drafts for consistency and grammar.
Overcoming Content Politics
But this was only half the battle. Content in any organisation is highly political (how many times have you witnessed clients’ departments arguing over whose content should be more prominent on their homepage?)
We needed a way to overcome this, and empower the client’s web department to manage their content over the long term.
To do this we turned to the assets that came out of the research phase. We established the personas and user journey maps as filters through which new content requests would be viewed. If any department wanted content to go live on the site they needed to ensure that the content met the needs of at least one persona. If they couldn’t justify this, it wasn’t going live.
We designed a five-step Content Lifecycle, which dictated how content was to be created, managed, and removed/archived on the site.
- Content Need Realisation
If a department in the organisation realised (or decided) it needed content to be placed on the site they would submit a request to the web department explaining what content was to go where, and why.
- Persona & user story alignment
The web department would review this request against the existing personas and user journey maps, and decided if this case was valid. In some instances, such as policy changes, they may be obliged to place content live, however in any case the request would be filtered through the personas to ensure that any resulting content was focused on specific customer needs.
- Content Plan
The requesting department would submit a content plan (e.g. who was writing the content, who was responsible for it, when should it be published, when it should be removed/archived).
- Content Creation
The requesting department would then be provided with the persona and write the content. The web department would help them with this, if needed.
- Publication & Management
The content would then be published. All content would be reviewed by its owner every six months. If content needed to be removed it would be either deleted or archived.
This process largely worked. We were able to produce user-focused content quickly and economically.
But there are things, I believe, we could have done better.
- We focused on only one department. While this was largely a budgetary decision, I believe that if we had repeated the process with one or two more departments we could have identified ways to improve the process. While also handing more control over to the client’s web department in the process
- We should have invited participants from other departments into the workshop. Even if they were just there to observe I believe that they would have become powerful evangelists for the process and would have helped us promote the work across the organisation
But above all, we were able to prove to the client, and to ourselves that Content can and, when needed, should lead design projects. When content is treated as a design challenge, we can create content that supports the customer experience in an instrumental way.
Whatever form of designer you are, Product, UX, Interaction, Service, you are designing with content already. And with that you have the power to make people’s lives easier or more difficult. But as a designer when you consider content as part of the design process, you can fundamentally improve people’s lives.
And as a designer you are the best person to design how content works for your clients.