The information in this blogpost may now be out of date. See the current GOV.UK content and publishing guidance.
One of the main ways suggestions for content amendments or additions gets fed into our team is through our online request-handling system, Zendesk. Departments often have complex queries that can be challenging to interpret and translate into GOV.UK style.
From our point of view, the clearer the request raised ('Zen ticket'), the faster and easier changes can be made. The more obtuse and policy-speak orientated, the less likely we’ll be able to action it the first time around.
When choosing what zen tickets will get into a sprint, we have to weigh them up against all the other work we have to get done including planned project work. We look at them and ask several questions to determine priority:
-
is there a deadline (eg, is a policy change going to affect content starting on a certain day or is a new service going to be launched)
-
is the content factually incorrect without the change
-
is it editorial
-
how old is the zen ticket
The problem we have as content designers is dissecting factual inaccuracy from editorial judgements or policy led arguments. This is where both departments and content editors can get bogged down.
With that in mind, Zendesk requests can be structured so they are easy to understand and so can be solved much faster.
Be precise
Pick out the exact phrase or word that is problematic. Don’t leave it up to us to guess what page or sentence you are referring to - point it out.
Be specific
The most important thing for us is the reason why it needs to change. Is there a change in policy? Is it factually incorrect? Is there a new service? Is the service closing down? It's the why that is important to us.
Think of the user
We concentrate on the user need and so the detail of policy changes isn’t always the best way to describe the changes suggested. The most important question for us is does the policy change the user journey in any way? Think of all the possible questions that could be asked about how that change can affect content and let us know up front - that way we don’t have to ask.
Be thorough the first time
Nothing is more aggravating than getting zen tickets every week on the same piece of content. What would help content editors would be for departments to curate the content on their end as well. If a change request is submitted, find out if there are more before submitting the ticket. That way, we can have all the changes the first time, do them and not worry about it again for awhile.
Plain English
Think of the GDS style when making a request. If the explanations given are plain English, the easier it is for us to make the amends. Otherwise, we have to interpret what it could mean and go back to the department to see if the plain English explanation matches the policy explanation.
Sometimes the most important thing that can be done by departments is saying no internally as well. Empowering digital colleagues to understand the process, style and how GDS works can save us the most amount of time by not getting Zendesk requests in the first place. These are the requests that won’t be done because it's out of scope, it’s been rejected before or if it's an editorial change only. Saving us from that means we can get to the important stuff faster, improve the content and also make us happier content designers.
[By the way, you can find the request form here - although note that it's only accessible to users within government]
1 comment
Comment by Graham posted on
I would like to know what is the preferred format to send you changes on mainstream pages?