Content design and technical writing: two crafts that craft great together

Looking out over the Blue Mountains in Australia

Close collaboration can result in big wins for everyone, especially the people who use your products.

Reality check

Your team and company culture might be highly regimented and outright suspicious of close collaboration (I certainly hope not). Or, completely open to change but with wildly unrealistic expectations. More likely you just want to build a better outcome for your team and the people who use your software.

Start by being honest with yourselves about:

· What you hope to achieve

· What you’re willing to commit in time and effort

· Who you will need to work with or influence

· How you hope to work together

Success most often depends on forming meaningful partnerships, defining responsibilities, and coordinating handoffs through execution. Each team will have to be willing to “give up” some control, take on some specific responsibilities, and be accountable for some outcomes.

Collaborative mindset

Depending on your organization’s culture, you might have to start by shifting the way you think about who does what and why. This isn’t about how you assign individual work so much as how each team thinks about their role in building the product.

You’ll need to change from this:

“We own this thing” and “This is our assignment”

To this:

“We’re accountable for this outcome” and “We’re responsible for these tasks”

This perception shift allows each team to contribute in different and meaningful ways while still maintaining consistency and oversight by the accountable craft.

The objective is to make decisions collaboratively. However, the accountable team has the final authority as they will be the ones explaining it to leadership if it all goes catastrophically wrong. Or, you know, just doesn’t meet quarterly goals.

For example, Content Design is accountable for the voice, tone, flow, and construction of UI text throughout a product. Technical Writers might be responsible for writing complex instructional text in that UI. Should it be necessary content design would have the final say in a decision in that scenario. Whereas Technical Writing might also be accountable for the API experience and content design might be responsible for the terminology, voice and tone, and flow of a section. Technical Writing would have the final say about how we present the API instruction, even in the UI.

There will always be variables and gray areas.

A pleasant human experience and successful user outcomes should be more important than who with what title did what.

This all sounds a bit much, thanks

I may have made this sound like a giant undertaking requiring consultants, months of planning, workshops, and so forth. I don’t think that’s the case, at least not in the very beginning. My consultant friends can be super useful along this journey, but you can get going quite well with a bit of determination and a few ideas.

Do what you do well

We have crafts for a reason, they focus the creative and solution part of the brain on domains of knowledge.

Technical Writing:

· Captures documentation defects and customer support tickets from the previous release and sorts them into categories

· Reviews the upcoming release documentation and talks to engineer leads and PMs to start anticipating effort

· Reviews documentation analytics (what’s being used, what’s not, why for both)

· Reviews support common problems (what’s being opened, why, can we help or is it an eng or design issue)

· And so on …

Content Design:

· Starts investigations for upcoming feature development

· Works with research to understand current user objectives and problems

· Reviews existing customer problems and start investigating

· Creates personas, journeys, and questions, questions, questions

· And so forth …

Gather and share — planning phase

The focus and domain knowledge each craft brings to the table become the building blocks to create the framework of a human experience. Now’s the time to come together and share what you’ve found and what you’re planning to do about it. For the meeting itself:

· Set the stage: each team shares summaries of their findings and relevant links to the source material

· Set the expectations by setting the outcome: “Everyone understands what problems we’re solving and how” is a good place to start

· Set up transition points: As each team presents, they note the dependencies, and hand-offs they have with the other craft. Those become action items for individuals — “when you finish a design, do a quick update with Tech Writing so they understand the rationale behind changes” “Check with Content Design when you update tooltips so we’re meeting overall user goals”

As you collaborate more your objective can rise and eventually become something aspirational “We have a clear plan for this experience across crafts.” But then I’m always pushing end-to-end thinking and design.

Stay connected — Designing and building phase

Now you’ve got a plan and you understand how your crafts are both dependent on each other and can benefit each other. Collaboration should avoid massive schedule disruption by focusing in-person time and sharing access to source material async.

Here are some of the things I’ve used to drive success:

· Choose a regular place and time to share your work, then make that work accessible to everyone

· Create an abbreviated journey covering the relevant touchpoints (context only, simpler is better)

· Have an agenda and stick to it — box time, focus topics, schedule creative sessions separately

· Focus the discussion on problems, findings, proposed solutions, and recommendations

· Identify the contacts for each craft

· Determine who’s accountable and who’s responsible for high-level objectives

Pro-tip for Designers: read the docs for a feature you’re designing; it will inform you how the system works by forcing you to see every step in its own context. Also, a great way to find experience gaps “wait, what happens next?”

Pro-tip for Technical Writers: ask to have a journey walkthrough, you’ll find aspects of the product you’d not considered and the ideas behind them.

The real trick is to build consistent communication that identifies and tracks progress on goals, objectives, timelines, and dependencies. Once you’ve got that you can share the best parts of each craft with each other and share people and responsibilities to create the best possible product and team experience.

Keep swimming

Like all things, it’s not as simple as blogs and conference talks would have you believe. It really comes down to understanding the value each craft does or can add to the experience framework. I’d implore people to think of each craft possessing specific tools and insights and most important of all: listen to each other.

No craft is better than another, we each bring value. When we recognize that value in each other, everyone, including the humans using our products, is better for having so done.