Breaking Down Silos

I was chatting with a former colleague, a content designer, about opportunities to get involved with various events.

The conversation developed and we got on to the idea of bringing together content designers and developers so they can learn more about what each other does. She said she’d spoken to a few content designers, who had all expressed an interest in understanding more about how developers work.

Bringing teams together and breaking down silos is something we’ve been thinking about a lot at Affinity recently. 

Our marketing apprentice, Brooke, has been exploring the topic, particularly around content design working best when not siloed.

It’s well-documented that silos create issues because they isolate data, information and teams. This creates barriers that stop collaboration, efficiency and innovation.

As I work to bring more content design projects into Affinity, I’m keen to explore how we break those barriers for good.

In order to sensecheck our own process, and to think about how moving from “hand-offs” to “partnerships” is a vital component, I spoke with practitioners from Content Club, former content design colleagues, and our own development team at Affinity. 

Here is what they say has worked for them…

Getting the Rhythm Right

Collaboration isn’t just about being in the same room; it’s about a shared operational rhythm. One of the most effective shifts you can make is moving content tasks out of separate documents and onto the sprint board. When a developer can see a content ticket sitting alongside a feature build, the work becomes a primary requirement rather than an “offline” process.

But visibility is only half the battle. We also need rituals that actually mean something. Inviting developers into content crits to contribute brings a fresh, logical perspective that often catches structural issues before they’re ever coded. 

For more complex features, a weekly “UCD/Tech sync” is invaluable. It gives everyone the breathing room to align on the “why” behind the build and iron out the “what-ifs” early.

The “Coding Content Designer”

It’s not about content designers needing to be secret coders. It’s about technical empathy. You don’t need to write the script, but you do need to understand the craft.

While tools like Markdown have their place, a foundational grasp of HTML and CSS is often far more valuable to a developer. It allows designers to structure content in a way that respects how the web actually works. It’s also about being transparent with your logic. Whether it’s through detailed Figma annotations or a quick video walkthrough to explain a complex decision, providing a “source of truth” stops the mid-sprint guesswork that leads to rework.

Owning the Finish Line

If you want to truly break down a silo, you have to share the responsibility for the final build. This means content designers need to be active in the QA and testing phases.

When you sense-check the final output in a staging environment, it signals a fundamental shift in mindset in creating an equal partnership responsible for shipping a high-quality, functional product or service that meets user needs.

The Affinity View

Mark Hudson, senior developer at Affinity, said:

“Involving a content designer early enables me to know, from the start, what I need to consider when designing the technical architecture. I have clear, content-driven journeys to work from, and the decisions I make can all be made based on clear user requirements. 

“If content comes in after the build’s already established, there’s always rework once the content starts to go in, and it can even lead to technical debt straight away, with a backlog of improvements to work through. 

“Also, content designers often have the best understanding of the audience, so they can be really good at helping with things like user guidance, notifications and error messages. Otherwise, these things all typically come as afterthoughts, and can really impair the overall user experience.”

Making This Happen

There’s always been a conversation in content design around being invited earlier. 

We know from experience that our team really benefits when there’s early, and regular conversations between content designers, user researchers, service designers, and developers.

And if they benefit, then the client benefits, as do the end users.