Content crits: what they are and how to run them
A crit is a critique.
I use them in content design to:
- help the team write and edit consistently,
- create or iterate a style guide,
- build a team,
- improve the product.
I learned about crits at art school where I studied design. I had the half-shaved head and batik-printed dungarees (yup, really).
The whole class sat around and commented on one student’s work. 28 of us discussing someone’s creative, expressive, masterpiece they’d been working on solidly for a fortnight.
Sounds pretty much like hell, doesn’t it?
That depends on the way you run it.
Crits help the team
When you talk about the product, you share what you have learned to make the product better. Sometimes, that learning can take place with just a couple of people. I find it more efficient if the whole team see and understand the same thing at the same time.
For example, if you have a sub-editor function, those sub-editors often speak with the author on a one-to-one basis. If that author is the only one that learns from that interaction, you are improving the product but you don’t widely share that learning.
Maybe your subs hold weekly sessions talking with the content team about common errors they’ve seen in the past week etc. That’s a wider audience but it may not give room for a good discussion, because the time has already passed. The work you are talking about has probably been published.
At GDS, I saw a poster in a meeting room that said: ‘rules of the retrospective: everyone did the best job they could with the information they had at the time.’
I love that. That’s exactly what a crit should be.
When we write, we do the best we can. There are few people who leap out of bed in the morning shouting: “I know! I am going to be mediocre and a bit crap today! Just for laffs!”
Even fewer start the day with: “I know! I am going to be a complete arse to all my colleagues today!”
When constructively criticising, we need to remember there’s a human on the other end of our comment. They are probably not trying to get it wrong just to annoy us.
How to set up a crit
I have the team sit around a big screen. I invite the designers and devs too. They look at content from a different angle. I have found brilliant ideas come from conversations with all the disciplines – not just one.
The author puts the content on screen and tells everyone what user need they are trying to fulfill. The author can take notes or a nominated person can, so the author can concentrate just on the comments.
Then the team either read it, or if the content has been shared before, start making comments. This is when the rules of the crit kick in.
Sarah’s rules of the crit
Everyone will have different rules. These are mine.
Rule 1: talk about the product, not the person
In a crit, you don’t talk about the person, you only talk about the product.
This has to be your foundation. You are not there to demonise someone. You are only there to improve your product – as a team.
So, 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?’ (supportive)
You are talking to the team about making the page better – not asking the person why they didn’t do something. Also, you don’t know if that person used bullets and it didn’t work. Try and make the point a discussion for the team.
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.
Rule 2: be honest, but be kind. Use constructive criticism only
Good, constructive criticism can be hard. Especially if there’s a lot of pressure on a team. You don’t want to offend anyone. Especially the person who is your friend, new, a bit huffy, been there for 20 years or whatever.
Saying things like ‘that’s crap’ or ‘I don’t like that’ etc 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.
When you keep that firmly in mind, you end up changing your vocabulary and the way you speak.
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.
Rule 3: No-one needs to defend a position
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.
We all forget stuff. We all work under pressure. You are still a team.
Other crit considerations
Some teams have set times for crits, others set them up when there’s something to look at. If I am starting a new team, I will set specific times and the whole team has to be there. Everyone is gently encouraged to speak.
Crits are uncomfortable for some people. You may find it takes a bit of practice for the discomfort to disappear but starting out in a structured way can help define the culture and start the habit it will become.
When it’s a habit, you’ll find your team often work faster because you are sharing the same learning at the same time. You don’t have to have structured sessions on style or feedback sessions because you are doing that while doing your daily work.
I’d also recommend the person running the team allows all the others to speak before they do. This gives you, as a manager, a chance to see who needs what. This could include their professional development and how you can help the team as a whole.
It also removes that ‘top-down’ approach. If you are always telling others what to do, you’ll never have a team who own and love that product. They won’t care about it as much. So you will end up with an inferior product.
By keeping quiet, your team will understand they are respected. Nothing builds a team faster than respect.