The 3 existing ways of tagging things mainstream browse categories, policy areas, topics and subtopics means that tagging is complex and publishers aren’t clear what effect tagging has and where the document will appear.
We want to separate the process of tagging a document from the editing workflow so that a document’s tags can be edited without having to update the rest of the document.
We're moving towards a single taxonomy but we want to make it easier for publishers to tag documents to the correct topics. They need to be able to understand the context and consequences of tagging so they can make informed decisions to make content simpler to find and understand.
We did some user research to find out what we need to do.
What we learnt
Policy areas and policies
Publishers didn’t understand the difference between the ‘policy areas’ and ‘policies’ fields. Publishers used ’policy areas’ because it’s a mandatory field. No publishers knew that tagging to a policy area trigger an email to subscribers. Some publishers understood that content was organised by policy area, but were unsure how they would find policy areas in the publishing tool. Some publishers were also looking for policy areas in the policy field.
Some publishers weren’t sure why they should tag to a topic (a browse page for specialist users) or what would happen. Others were worried that tagging topics might make it harder for users to find relevant content as there might be too much information on the topic page.
Currently the topic taxonomy is limited in scope. Whilst we don’t have a wide enough taxonomy, it is hard for publishers to make the right decisions.
What we're trying out
In order to help provide some context when tagging, we tested listing suggested tags next to the topics interface.
We also tested a new tagging interface that lets publishers search and browse the topic taxonomy.
Both of these concepts worked well and are being iterated on.
Publishers weren’t sure why it’s important to tag, what the consequences are, and especially how tagging affects the document.
It's hard to see what might happen once it's published. But I don’t know what the topic will look like. Maybe looking at other content that sits on that page will help you decide whether to choose a different topic.
We also learnt that almost none of the publishers we talked to knew that users could subscribe to email alerts for policy areas and topics.
We tested a message that appeared when publishers tagged to a policy area or topic that warned that users subscribed to that tag would get emailed. The vast majority of publishers we tested with were unaware about the email alerts and there were extreme reactions to this.
I'd be really worried if our stuff was emailed out. It's really niche. It's not going to be what users want. All these things have an impact on reputation. We'd have pushed back against it if we'd known [that it meant people were emailed] and get another policy area put in there.
We also tested a way for publishers to preview any topic pages they had tagged to, showing what the new links would look like and providing publishers with a feedback field to explain why they had not tagged to a topic. We’re still collecting research on these iterations.
We will continue to research and iterate our changes to help users to understand the context and consequences of tagging.
We are working on our first iteration of the new tagging workflow, to split the tagging interface into a new tab, but first we need to validate our approach with further research using what we think is our first deployable version.
We plan to make changes through small iterations over the next few months.