Content is a product discipline
Words? Words are hard. The only thing harder than words is taking them seriously. Let's talk about content, product and what needs to change.
Words? Words are hard.
One of my favourite blog posts on the internet of all time started with these words from the Slack blog. Even as you read this, you have a grasp of words they feel accessible. But words are hard.
The infrastructure problems of content teams
The only thing harder than words is taking them seriously. Many teams still have a lot of issues that stem from thinking of words as an afterthought.
Stretched thin
In modern software teams, we still find that a core team means dedicated designers, developers, sometimes an engineering manager, product managers, all aligned and thinking about a single problem at a time, all together. Except content. Content is trying to cover a lot of ground splitting time across 3, 4, 10...12 projects? Ouch.
No time for feedback
When you're stretched across several things there's no time to iterate, measure, or improve your work or yourself. Everything can feel last minute, rushed, and less than ideal. If you're one of the few people in the organisation context switching often, it looks like you don't care about quality the way the rest of the team does, when really you're too stretched to meaningfully act on feedback and customer response.
Losing velocity
Without dedicated writing support for thinking through information architecture and words, folks have a hard time understanding content design. Software velocity means moving in the right direction, together. Every team that has to stop moving together to play catch up, or reintroduce a problem to a content designer is losing velocity. The content designer can't build roots or add velocity because they're a roadblock by design.
Who are you again?
Everyone in your product team will have a slightly different definition of content strategy and their relationship with the content team. When people ask "What is content design," the answer inevitably varies because the support will look different to each team.
The Experience problems of content teams
Software teams continue to grow their efforts for quality, engineering, design and research, but many have left content in the dust.
Few designers understand this better than Jessica Collier, a former member of the design team at Evernote. “When no one truly owns the words that make the app work—when front-end engineers and designers and developers and product managers are all inserting language in their own particular style—that product’s voice becomes scattered and its narrative structure fragmented,” says Collier.
As digital products mature, giving time and attention to words, information and content continues to be one of the easiest ways to increase quality and decrease risk. However, in many teams, words never push into how we think strategically.
Experience quality has increased, content hasn't kept up
Experience is a competitive advantage for many companies, but design is not just what it looks like, design is how it works. The quality customers expect has gone up, but the dedication we give to content has gone down as we saddle designers with thinking about words.
A designer is not an octopus
User research. Product roadmaps. Information architecture. Customer journeys. Visual design. Interaction design. Design Systems. Figma. Trello. Miro. Notion. Slack, and so many more. We can only expect so much of a single person's role before the quality of their attention cannot meet the demand of their customer.
Waiting until the end is not content design
Having a dedicated attention span to focus on words can streamline interfaces, reduce support costs and increase customer satisfaction, but we still staff content teams like agencies. Many teams will work through a problem and wait until the end to "polish the words." This is forcing content to fit form, and it's where many product teams are. To quote Jeffery Zeldman: “Design in the absence of content is not design, it’s decoration.”
What we're doing next
Words are hard. The only thing harder than getting words right is putting off getting your words right. Humans have an inverse relationship to hard things, we like to avoid them. So agile software development teaches us to do hard things early and often to reduce the pain.
Why we're doing this
There are three main reasons we're making these changes. The first is that when you prioritise doing hard things more frequently you can break them down into manageable and sustainable work. If you make one small change at a time, it's easier to get each one right than waiting until you have a whole product's worth of content debt.
The second big reason is feedback. You can't fix what you don't understand. We realised our content team was stretched too thin across too many things to be effective. When you're working on complex things, feedback helps you steer and make better choices. So getting feedback often is preferable to waiting through long cycles.
The third big reason is practice. When you do things often, and with a team, the whole team can develop competence, and work together to improve quality. When you practice getting good at problems, you get better at them. The idea is to give content enough time and attention to infuse the way we do product development and design.
Single focus content designers
We are working with our product managers to determine the highest priority efforts and focus on those with content support.
Pros:
- Most of the infrastructure problems I identified above disappear.
- Content becomes a core product discipline and can experiment with a team rather than for or after them.
- Feedback loops get tighter
Cons:
- Oh, we need a lot of content designers.
- Not everyone gets a content designer.
Design System Content Team
A team within our design system org focused on strategic content needs across the business. The team will be responsible for a few things including:
- Conducting ongoing maintenance and cleanup: we still have a bunch of content and UX debt all over the product that needs cleaning up.
- Establishing and maintaining content standards and patterns across our products
- Offering ad-hoc tactical copywriting help for unsupported teams without a dedicated content strategist.
Pros:
- 18F is doing something similar with their Writing Lab.
- Instead of dumping new hires on a big high-pressure project, they can spend time getting to know the product with ad-hoc support.
- Product teams get time and attention to make improvements on new things. Having a dedicated team tackling older products means it actually happens and your product teams can pick up and own improvements in the future.
Cons:
- Unsupported project teams still don’t get strategic support.
- Prioritisation of legacy products can be hard and unclear
Further Reading
If like me you're thinking about content design in product, here's some reading that's helped me along. It takes a village. Because words? Words are hard.
- Shopify has witten about their approach to content design in product and gotten to a 1:1 ratio on many but not all projects.
- Stanley Wood’s “Design Doesn’t Scale” which has lots of great stuff on how design works at Spotify
- The Book Org Design for Design Orgs which focuses on how to build design teams
- Jonathan Colman has written a lot on the matter and given several talks. This one stands out for talking about how to maximise the impact of content design as a discipline. There's also this whole talk about how to hire a world class content team for hiring managers.
Software design is hard work, this is a guide to staying soft, humane, and resilient through the challenges software leaders face.
Subscribe to keep up with how to handle the soft side of hard work.