Why we needed a content database — and you might too.
Here at Cuvva our content design function sits within the Experience team, alongside designers and researchers. (At the moment, I’m the only content designer — we’re currently hiring!)
But we have other content resource in our Marketing and COps (customer service) teams. We’re all writing different kinds of content like web support articles, web pages, app screens, push notifications, emails, Facebook ads and saved responses.
As the number of contenteers (as we call them) across the company has grown, so has the need for tools and processes to make sure that the way we speak is consistent.
The problem
We all use the same tone of voice in our writing, and we have regular content catch-ups and crits to make sure we’re well aligned. But I realised the majority of decisions that we made around content weren’t being recorded or shared. They lived inside people’s heads, which meant that unless that person worked on every single piece of content to do with that product or service, it was likely things would get missed. This was problematic for a number of reasons.
1 — Compliance.
As a regulated company we need to make sure that all communications with our customers are clear, fair and not misleading.
If a member of our compliance team gave one of us advice on our content, say on an app screen about a new feature, we’d make the changes to that piece of content then move on with our lives. When someone else came to write about this in an email, they weren’t aware of the specific decisions that had been made around that feature. Not an ideal way to work.
2 — Product considerations.
We’re building insurance products that don’t always look like the insurance products people are used to. This comes with content challenges — the language we use to describe our products and how they work is very important to make sure our users understand them.
Again, having one person holding onto these decisions without sharing them with the rest of the team can be problematic.
3 — User preference.
As a very user-focused company, research is extremely important to us at Cuvva. We run content specific testing like cloze testing to make sure that the language we use is optimised to meet these needs directly — making decisions at a granular level. For example, deciding to use the word ‘payment’ over ‘billing’.
All of these findings are recorded in the research database (shout out to the research team for being so on it). But by not recording these decisions in an accessible way for the content team to utilise, we’re likely missing opportunities to communicate effectively with our customers.
The solution
Sharing content decisions in meetings didn’t seem like the best use of that time — and could lead to the same problems. So we continued using those for updates and crits.
Instead, using Notion (we’re big fans), I built a content database. The database is a searchable tool that documents all content decisions. Any time we consciously decide to use one word over another — whether it’s because one word is a more accurate way of describing a product, or simply because users like it more, we record it there.
Not only does this act as a record of all the content decisions we make overtime, it provides as a functional tool for the rest of the team to inform their writing decisions — so we can be sure that we’re all using the same language to increase effectiveness, and not reinventing the wheel every time our fingers meet our keyboards.
How it works
I created a table that looks like this.
For each entry, you can see the product it relates to, as well as the specific section. You can use these to filter the table to narrow down your search. The table also includes which writer worked on it, and what date they last checked it (to be sure it’s still relevant and correct).
The decisions themselves sit in pages within the ‘content’ column. You can simply click into a page to find all the relevant information you’d need to write about that product or feature effectively.
When you click into one of the pages, you’ll find another table specifically for content decisions.
We document the language we’ve chosen to use, along with other important things like tags to indicate any considerations we made. This could be anything from compliance to research, and can be used to filter it down.
There’s a column for notes to give a quick explanation as to why we’ve made the decision. But for anyone looking for more detail, there’s also a column with links out to the full research write-up. And finally, to provide that all-important context, there’s a column for a link to the particular screen in Figma. This means writers can see where it appears in the flow, and how it’s been communicated in the context of the product.
The results
The impact has been more far reaching than I initially thought. Whilst our PR manager isn’t necessarily a writer, a huge part of her role is to nail the messaging about our brand. We’ve found there’s an application here for aligning messaging and finding the most effective way to communicate what we’re doing, and to make sure those communications are consistent even in the way we’re talked about in the media.
It’s also a great resource for non-writers. It gives designers and product managers the ability to pick the right wording when they just need a few lines here or there, saving us all time.
Finally, and probably most importantly, it means the content team across Cuvva are much better aligned. We’re all thinking much more deeply about the language we use, and how to best communicate with our users. What’s more, it’s made us think about where there might be gaps — where we haven’t yet decided the right way to speak about something, and where we can do more research to find out.
What solutions do you have in place for documenting these decisions? I’d love to hear!
And if this sounds as exciting to you as it does to me, good news! We’re hiring a content designer to join the Cuvva team. If you’re interested, check out the role — we’d love to hear from you.
