A tad dramatic but the idea for this blog came from a recent experience on a project where I found myself deep in the madness of an alpha searching for a content comrade. I eventually found my feet but it got me thinking about all the other content designers out there who have found themselves in the same position. 

Here’s some things I’ve learned on the ground and now pass on to all my fellow content chums.

Work on those relationships (yes, with everyone)

You’re most likely the only content spokesperson on the team and it doesn’t help that you’ve joined the project too late. You’ve now got the nerve-racking task of reaching out and introducing yourself. I see you friend and most importantly, I’ve been you. 

This doesn’t have to be so daunting and there are some ways to get to know the rest of the team: 

• Book a coffee chat with the developers

One thing I’ve picked up on when working with devs, is they’re actually curious – and thankfully interested – in learning about what a content designer does. This is the perfect time to not only advocate your discipline, but form a dev buddy for life who you can work closely with. 

• Schedule weekly review sessions with the designers

Sure you can send your feedback via comments on Figma, GitHub, Miro or all three (nightmare), but you can build a relationship much more quickly when you deliver your feedback face-to-face. Having weekly meetings also keeps you in the loop and gives you the opportunity to constantly give content feedback. 

Crash the party

It might feel that way when you’re constantly asking for invites to meetings that you weren’t originally invited to, but it’s crucial that you make sure you’re in the ‘room’ when decisions are being made. These key meetings are the opportunities to speak up if a decision impacts content negatively and prove you’re a stakeholder in this project.

Once you’ve made some time to chat to team members individually, your presence in these meetings won’t be so strange. The team will know why you’re there and what you’re bringing to the project.

Build trust and explain the rationale behind content design

This is a tough one. How do you explain the reasoning behind your content decisions without coming across as defensive? You start by sharing your thought process.

Continue to get the team invested in your content by asking for feedback to improve the quality. It’s also a great way to encourage the team to be collaborative. There can be huge UX improvements when we collaborate early and often with other disciplines.

When you find yourself having to give feedback – which can also be tricky – your comments should come across as more curiosity than criticism. For instance try phrasing your questions like these:

• I don’t think I have the full context here, could you explain the decision a bit more?

• I’m curious, what was the rationale behind going with this design?

It’s not always a words problem

At some stage, you’ll find yourself submerged in content requests which may have happened because you’ve (understandably) said yes to every request that’s come your way. The danger here is through that rash acceptance, you might end up taking on work that isn’t actually a content issue. 

Ring any bells? Remain calm – there’s still a way out.

If you find yourself staring at the content request unsure of what you actually need to do, you might automatically assume it’s an issue on your side. That’s not necessarily the case. Ask yourself:

• Could it be a deeper design problem? 

• Do you have the full context to help with the content issue?

• Does this request require you to reach out to a business analyst or subject matter expert to get more information?

There’s nothing wrong with going back to the team when you’re unsure. Be brave, lone wolf. 🐺

The key thing to remember is you’re all working towards the same goal. You just need to do the best job you can with the information you’re presented with at the time.

Got any content design stories worth sharing? Tweet us.