Defining content design contribution: shared vs. specialized tasks

At Condé Nast, our content design team is privileged to have evolved well beyond the “seat at the table” level of design org maturity. However, that doesn’t solve every problem a small but mighty team may face within a more mature—and quite large—design org. We know we’ll almost always be too understaffed to support every project across our company anytime soon.

This is a classic dilemma that I’d argue almost every content design team (and especially content design teams of one) has faced. Over the past year, we refined a prioritization system that helped us do the soul searching necessary to think about how we actually contribute to projects, and how we’d like to in an ideal set-up.

We have a host of teams to support across Condé Nast’s Technology remit, as our company’s breadth spans 37 brands across 26 markets worldwide. We simply can’t cover them all, nor intend to. Facing this fact has made us much more acute and flexible in what we should actually be supporting.

So while we’ve come to terms with this fact of (work) life, it does however present a different challenge. We first need to decide what projects to support. Then, we need to help our teams understand when, why, and to what extent we can contribute to their initiatives.

When we partner with teams we haven’t worked with before, we also need to set a new baseline and a bit of an education in content design, as we don’t know who on the team has worked with a content designer in the past, and how that would compare to our company’s team.

I often find myself in a catch-22, balancing a caveat (my team doesn’t have much time) with a threat (include us in all meetings, communications, and decisions). This sometimes feels like I’m giving contradictory guidance to not only my team but to the product and design leads they’ll be supporting, and most especially to folks who haven’t worked with our discipline much before.

These conversations were so recurring, that I began to recognize my own generic disclaimers I gave:

• “Think of them as a product designer on your team.”

• “But they have a specialized skill set, don’t waste their time, they have other projects they’re stretched across.”

• “Be sure they’re included in all team meetings and feel confident contributing to the ways of working and squad culture.”

• “They only may have time to weave in and out of syncs and initiatives, and will dedicate time where it’s most needed: a naming workshop, wireframing workshop, UX copy edits late in the game.”

• “Include them!”

• “Stop bothering them!”

This was just as aggravating to our partners as it was to us, stuck with all the “buts” in between and a new existential dilemma on our hands: How did we want to contribute to projects? How could we actually have it all? How could we make others understand without confusing them further?

This challenge wasn’t a new one. During my time as a senior content designer on Vogue, I found myself often stretched across projects with no specific prioritization from Product.

We decided to craft our own way to prioritize, based on assumed level of effort and impact from a content design perspective.

Creating a tiered system

I crafted a simple tiering system to better order projects in my own mind, and to then explain how much time I had to my teammates. I adapted the system from a Jonathon Coleman talk on different levels of contribution based on impact. Thus, our “tiering system” was born.

Each biannual planning session, I sat down with the teams I supported to better understand projects on the roadmap. I took this list back to my manager, and we’d parse through the work—gauging as much as we could ahead of time how much work that would be, how much time it would take me, and most importantly, how much impact that project would have on the business.

We prioritized the projects that had the highest impact that could use significant content design contributions. Even if it meant dedicating more time, getting

embedded on that team. It would have a significant payoff in the long run. When stakeholders saw the benefit of a dedicated content designer, we received more requests for teams wanting “one of our own.” That enabled us to create headcount in certain instances.

We then presented my involvement back to each team to set expectations. We used a lexicon to help the system stick with teams. A 1 was “embedded”—I’m here for all intents and purposes all the time. A 2 was “supported”—I’m going to swoop in and out for key moments where my help is needed, such as a naming workshop, cracking progressive disclosure, etc. And lastly, and most rarely, was a 3 or “consulted”—something that came to us for a quick look or last-minute help.

We intentionally don’t host office hours at Condé, but we infrequently take on a few problems to solve when we can implement a quick fix, or provide some cursory and surface-level edits. We figure this is better than saying no to every team, especially those who we have decided we couldn’t support.

But this system still felt slightly reactive. The tiers also were a math that only made sense to us. We used a 1-2-3 system: projects that needed the most to least support.

What if we had a content design project we needed to work on independently? Or a significant milestone or initiative that fell within our own centralized team or in partnership with User Research? So we tacked on a Tier 0—a significant amount of focus spent on independent projects, untethered from project work.

This worked for a while, until a new, challenging question presented itself: Were we assigning the tier to the initiative as a whole or just one discrete piece of the project? Some initiatives would fill up the roadmap for a year. We wouldn’t need to be tied to them because of the design cycle’s natural ebb and flow.

But then how would we account for moments of highly applied contribution, such as naming workshops, brainstorming sessions, wireframing that tackled info architecture or something as significant as navigation? We were left with a shambolic system of our original numerals, labels we used as shorthand to remind our stakeholders what each number meant, and a lot more generic disclaimers.

Revamping the system

Last year, I had the opportunity to revamp the system, picking apart my own historic (and dusty) system to build it back up again. For a few weeks, I carved out time for a task force of a few content designers to discuss the nuances, rules, exceptions, and anecdotes that could help us define how we contributed to projects.

In true content design fashion, there’s only one thing that cracked the code. After going down numerous rabbit holes and existential crises, we needed to take a step back from the drawing board (and a deep breath). We started with something more simple: Explain what we’re trying to convey in as simplest terms as possible. How could we explain our roles and how we’d like to be included like it was a product we were trying to launch? How could we define what we even do?

When we took this more simplistic approach, where we landed felt more solid. We realized we were trying to tidy everything up into black and white, where content design is full of grey areas. We realized there’s no reason not to have it both ways. We can have it all, we just needed to explain it better. 

First off, we’ve already established that content designers do much more than UX copy. We:

• Act as user advocates, balancing business and user needs.

• Serve as the common thread between Product, Editorial, Marketing, and Support that creates a credible, recognizable voice.

• Create systems of language to scale a product’s terminology, and systems of documentation to scale the writer’s impact.

But how can we define what a content designer does beyond UX copy, without just falling back on “also product design” or “UX thinking”, especially with our product design partners that could use a more nuanced understanding?

Here’s the framework I landed on: A content designer’s contribution is a specifically dialed mix of UX design thinking and digital content strategy, depending on a project or team’s needs.

This means content designers contribute to initiatives in two ways:

1. Shared tasks

2. Specialized tasks

Shared tasks are when content designers contribute their unique craft perspective to foundational UX design work in tandem with product designers:

• Shaping user flows

• Crafting the info architecture

• Wireframing

• Low-fidelity designs

• Planning workshops

• QA

This means the process is shared between co-owners, that content designers are also responsible for the work-in-progress in all of its early stages.

In contrast, specialized tasks are when content designers contribute specific tasks and techniques from their discipline’s toolkit to foundational UX design work and beyond:

• Crafting tone of voice

• Testing reading comprehension

• Naming things

• Storyboarding

• Evaluating against content heuristics

• Content guidelines for Marketing, Editorial, or the Design System

Here’s an example of what this breakdown looks like, based on tasks:

To hammer this framework home, I pulled recent examples from each content designer on staff. These are features and projects that each team would be familiar with, and could easily recall and identify the shared and specialized tasks that occurred.

Fortunately, this framework seemed immediately clear to my closest working partners. It was easier to create simple comparisons and contrasts. “Here’s where we act like product designers, here’s where we’re different.” It created simplicity. Bulleted lists could be used. Two columned charts were deployed. It empowered us to have it both ways, and made the clearest argument possible as to why we’re included in all the steps of the projects when we can be: Content design is design, per Michael Metts and Andy Welfle. This was the physical (ok, digital) embodiment of this concept in its most clarified form: We do product design work and we do a specialized subset of it, too.

Once we had this working mental model, we could apply it much more accurately to our tiered system, creating immediate clarity.

When a project involved both shared and specialized tasks, the content designer was embedded on the team. That meant that they had capacity to contribute not just their specialized skill set, but their content design-specific perspective to the project. This was the ideal set-up we aim for each time.

When it can’t be met, or when we take on additional work as capacity allows, it would fall under supported contributions. This now meant projects where we were brought in like the SWAT team to be responsible for or contribute our highly specialized content skill set. This could be to help name features we didn’t work on from the beginning, or to provide guidance (and liaise with Legal) on inclusive language and accessibility on a form that needed to ask for gender pronouns. We might not have all the context or ability to retroactively impact the project at hand, but could contribute at key, critical moments in its development.

“Specialized tasks” also helped define that contribution, avoiding the pitfalls of being asked to copy edit. Specialized tasks require craft experience and specific techniques; UX copy or editing previously written UX copy didn’t fall into this category.

We’ve kept our “Consulted” option for when we do have time to dabble in UX copy or help a team out that needs some editing or guidance. Because of the structure, we don’t find this takes up anywhere near the majority of our team’s bandwidth, at most 10%. It also often builds rapport with teams that aren’t familiar with our discipline, that realize they need much more support going forward—which in turn helps us make a case for headcount. 

Nothing is perfect

I’ll add one more generic disclaimer: This isn’t a perfect system. We still get hung up on how to define the size of a project, and what that means for milestones within our domain, and milestones we just contribute to. At the end of the day, we’ve decided to settle on that murkiness and wrestle with it internally as a team, as most content designers understand that they’ll need to sit in that discomfort.

However, our partners and stakeholders don’t need to. We’ve taken the same approach here we’d like to take on any project: Our users don’t need to understand the complexities, the technicalities, the exceptions. They just need to use (partner with) our team to the best of their ability, so we can do our best work possible.

If we streamline the system, craft clear communication, and simplify the concept enough to get them to take the best possible action (understand how and when to involve us) then we’ve already met our goal. If we’ve solved a piece of the existential crisis of what it means and looks like to be a content designer every day, then that’s just the icing on top