When developing a service as a content designer, you’ll need to work with other people to make it successful.
A project team is often made up of various roles. In my past public-sector projects, I’ve worked alongside:
- product managers
- delivery managers
- developers
- testers
- business analysts
- service designers
- product designers
I’ve also been lucky enough to have other content designers on my team, too.
But the more people on the team, the harder relationships can be to manage. And when you join a new project, it can take time to find the best way to communicate and collaborate.
When I start a new project, or when I’m struggling to find my teamwork rhythm, here’s what I do.
Set realistic expectations
Most projects will have a delivery manager to keep work on track and support the team.
But a delivery manager is not a content designer. They won’t know all the steps involved to get a piece of content done. So, be realistic and firm with what you can achieve in a set timeframe.
When I first started out, being firm made me uneasy, but I quickly realised that if I’m not realistic with my delivery manager, I’ll get more stressed. They’ll often get more stressed. The quality of my work will suffer. It impacts the process and the outcome.
I’m doing nobody any favours by holding back.
I like to break down the tasks needed to complete a big piece of work, like creating content for a new digital service.
I can then pass this information to my delivery manager, along with rough estimates on how long each task will take.
Do this early on and you’ll make life easier for yourself.
Of course, sometimes deadlines won’t budge, and you just need to bang something out. In this situation, I make it clear that the quality will probably be lower. As long as the team are aware of this, and understand the risks, that’s fine.
Learn how your product designer works
I like to understand what tools and processes the product designer uses to build prototypes. Early in our collaboration, I set up a call to discuss how we both work best, and how we can make this happen together.
I prefer to work visually, even when writing content. So, I like to develop content within the prototype. I do this instead of passing over words stored in a Word document or Confluence page.
But each to their own. Find a balance of what works for you and your product design colleague in the context of your particular project.
Chat with the developers
If you need to hand over content to developers to go into code, find out what format works best for them. This will influence how you structure your content reference.
When I’m planning this conversation, I set up some content reference examples. Having something visual means that they can point out what does and doesn’t make their life easier.
It’s like getting user feedback. Speak to the users of the content reference and find out what they need.
This will help to reduce errors down the line, saving everyone time.
Whenever I’ve done this, my team members have been grateful. I really recommend it.
Set up a solid content reference
Once you know what the content reference needs, it’s time to set it up.
How enjoyable you’ll find this really depends on your personality. I love organisation and structure. I’d probably enjoy organising a dusty filing cabinet all day. So, this is a part of my role that I relish.
My most recent content reference set up included:
- a screenshot of what the screen should look like
- a table with the content tags separate to the content
- all iterations on one page, with the newest version always at the top
- a note on what’s changed from the last version and why
- the date and iteration number for each version
Yours will look different depending on what your developers need from it.
I update mine every time we test a new version of the content.
It’s especially useful when it comes to a service assessment because all of the reasons for changes are documented for you to refer back to. It’s amazing how quickly you forget why you made a change, even if it made total sense at the time.
Find out or create the sign off process
Companies with well-defined user centred design practices often have a content sign off process already in place.
Working in a consultancy, I know that some of my colleagues have had to create their own processes. This is usually when a client has very few or no content designers working for them.
If you don’t have one, speak to your team and your stakeholders. Find out who needs to approve the content and at what stage of development they should be brought in.
It’s also great to have another content designer review your work as a final check before go-live. They may spot spelling mistakes, structural issues, or punctuation errors that you’ve missed because you’ve spent too long looking at it.
Your sign off process is a must-have because:
- everyone is on the same page with what content is being included
- any major issues are picked up before the content goes live
- responsibility is shared with subject matter experts, product owners and stakeholders
Document your process
I like to document everything I do. Who’s signed off what content version. The feedback they gave. When they gave it. And so on.
I collect all my content iterations into a folder on a shared workspace, which are reviewed for sign off.
I have a table with all the content I’m working on. I have a status column, so that my team can easily see where I’m at with it from a quick glance. My content iteration documents are all in one space and labelled clearly.
I’m not saying you need to do all of this – I am aware that I’m unusually keen on documentation! But having your work organised in a shared workspace, however works best for you, means it’s available to your team if they need it.
Whatever your process is, make sure your team are aware of it. Share your content space with them.
Involve the team in your work
Some of my most enjoyable experiences working in content have been when I’ve pulled my team together for a content-related call.
For example, I ran a very colourful service-naming workshop with my team that went down well. I explained the process of coming up with service names. I taught them about best practice for naming a service. They enjoyed it, and it was great to give them an insight into how we work.
If you work openly with your team, you’ll bring more awareness on what your role is and why it’s so crucial.
Change when change is needed
It takes time to find a productive way to work with your team. Sometimes, you just need to test out different options until you discover what works.
If you’re having a difficult time communicating or collaborating, have a chat with whoever is involved. Explore some new ways of working.
Set boundaries if something really doesn’t work for you. For example, being on calls all day is a no from me, if it can be avoided.
But be open to trying something else.
My previous teams have used our sprint retrospective calls to brainstorm on how to improve.
Great teams build great services. Once you find your teamwork rhythm, lots of the hard work is already done.
Learn more about content design
If you’re a content design who wants to pick up some tips, or someone from outside the practice keen to learn more, check out these links:
