How we create and manage content on our website

A group crit ('critique') is a collaborative session where you invite several people with different perspectives to critique your work. It can help to:

• make sure we write and format content consistently across the site
• check facts and information
• check understanding and interpretation
• identify particular sections of content that need to be tested with users (for example, where we are not sure how users will interpret certain words or phrases)
• identify content 'patterns' or repeated formatting, language or styles across the site
• iterate our style guide
• engage diverse stakeholders in the content design process

Include people who can give you different perspectives or bring different experience to your content. This might include:

• subject experts - this could be someone you involved in pair writing
• policy or legal experts
• content designers
• UX designers
• developers
• service users
• service designers
• researchers - for example, the person who researched the user need you are trying to address

Who you involve can depend on:

• the user need you are trying to address
• the complexity of the content, for example, when you are trying to explain legal terms in a way that users can understand
• what you need help with
• availability of contributors to the crit

If you're involving several people, give them as much notice as you can. You should:

• send them an invite with a link to a shared document (your draft copy) or draft web page
• explain the purpose of the crit and send them the crit rules (see below)

If you update your copy before the meeting, try to send them the latest version in advance so they have time to read it.

Make sure everyone can see the document. Choose one person to type in comments or make suggestions. This might be you or someone else. Some people find it easier to focus on managing the crit while someone else takes notes.

Remind people of the rules. Explain that you will amend and update the document after the crit.

Start by reading through the user story and acceptance criteria. Check that everyone understands what these are.

Next, read through the copy line by line. Stop after each paragraph or section to invite comments. Give people time to have a discussion where there is a disagreement or where people need more clarity. Encourage people to agree on an amendment or suggestions before you record it. This means you only record the things you are going to iterate, rather than every single comment.

Keep an eye on the time. If people are having a long discussion about one point, it can be helpful to scroll back to the user need and remind everyone what to focus on.

Once you have read through the whole document, go back to the top and read the user story and acceptance criteria again. Ask everyone if they think you have met the criteria or not. If not, ask them to explain why.

Thank everyone for joining then explain what you will do next. This could be:

• making amendments and sending the content for peer review
• checking facts or questions raised with other subject experts
• reiterating the content, where user needs have not been met

These rules are adapted from the Content Crit rules by Sarah Winters.

In a crit, don’t talk about the person, only talk about the product or content you are critiquing. You are there to improve the product as a team.

Instead of:

‘Your second paragraph is too long and a list. Why didn’t you use bullets?’ (confrontational)

You could say:

‘Do we think bullets might work on page like this?’

You can use things like: ‘How does that directly fulfil the user need?’ Or ‘tell me about the language you used there, is that common for that audience?’ Always focus on the thing you are doing and the audience you are talking to. Not the person who wrote the piece.

Good, constructive criticism can be hard. Especially if there’s a lot of pressure on a team. You don’t want to offend anyone.

Saying things like ‘I don’t like that’ is unhelpful and unacceptable. A crit needs to be a safe environment for those talking and those listening. Opinions like that are not going to help your product and it won’t help your team trust each other.

For example, changing: ‘you always forget to cap that word’ to ‘our style says we cap that word’ gently reminds the author to check.

You’ll find questions help more than statements.

This leads on from rule 2. If you, as a team, are working together on something, there is no need for anyone to defend anything. You are all working on it - and learning - together.

As a content designer, you might explain how you chose your words or structure to give context.

For example, if you want to explain how you interpreted the user need. This can be helpful to check whether others share that interpretation. This is different than defending your choice of words because someone thinks they are 'wrong'.