More than Words: Being an Interdisciplinary Content Strategist
People make their way to content strategy in all kinds of ways. That’s partly because it’s a relatively new discipline, which means people have few preconceived ideas of how content strategists are supposed to work. By experimenting with my own workflow, I’ve found that getting comfortable with design and prototyping tools and learning my way around coding environments has not only helped me be a more effective content strategist, but has also made me a more well-rounded UX practitioner and collaborator.
I remember installing the design software Sketch for the first time: I’d offered to take a small, content-oriented project off an overworked designer’s plate. To save time, rather than frame the problem in a slide deck or document, she sent me her Sketch files for a new component so I could make the changes myself. I spent the afternoon fiddling with Sketch — trying to draw arrows, figuring out how to edit and resize text layers, exporting artboards to share with others. Writing words in the mockups themselves felt new and exciting—like the rudiments of actual, tangible progress in how I worked. I was hooked.
For me, the most satisfying way to practice content-first design has been to work directly within the designs.
As a content strategist at Facebook, I’m tasked with maintaining the conceptual frameworks and voice— simple, straightforward and human — we use to talk to our community so that we create experiences that are clear, consistent and compassionate. Everything from the tone we use to the ways we write, demonstrate, and share our work helps to create experiences that are more thoughtful, more human and better for the people using them.
I have a lot of autonomy over how I do that work, though. And over time, I’ve found that some of the best methods for creating content and showing others the value of content strategy are in the tools and processes of designers and engineers, not in text files. I’ll share more about what it means to be an interdisciplinary content strategist, show why it’s worth the effort, and offer some guidance for getting started.
Learn to design and prototype ideas on your own
Like most content strategists, when starting a new project, my go-to for a long time was a document or spreadsheet. I’d create nicely organized tables, import screenshots and label my columns just so. I got a lot of satisfaction from making these finely tuned documents and still do.
But when these documents were my only deliverable, I spent more time giving feedback and catching up to design and engineering work than actually helping build products. I felt stuck in a reactive posture. This led to a lot of redundant effort too. Designs inevitably changed, rendering my content out of date. While I tried to demonstrate rigor and strategic thinking in these documents, it often felt like I was showing my work for its own sake, rather than providing something others might find useful.
Nowadays, instead of starting in a text document, I begin most projects by using the same components and design tools as the designers on my team. When a designer shows me something they’re working on in Sketch, my first request is for them to share their artboards with me. When they build a prototype in Framer or Origami, I ask for the files so I can see how they did it. Over time, gaining proficiency in these tools has helped me iterate on existing design work far more effectively.
While I tried to demonstrate rigor and strategic thinking in these documents, it often felt like I was showing my work for its own sake, rather than providing something others might find useful.
For example, on a recent project, I learned we could add a new piece of functionality that I’d assumed we wouldn’t have time to implement. After talking with the designer on my team about the right solution, I made changes to the designs and prototype myself. This saved both of us time: she could focus on higher-order problems, and I didn’t need to wait for her to mock up the change and address discrepancies between the content and designs. I took care of it at the source.
Lately, I’ve started designing and prototyping basic product flows from scratch, addressing the problems I want to solve from the start. Becoming more self-reliant and learning to bring ideas to life on my own has helped me build richer relationships with designers, too; we operate more cross-functionally, and we understand each other better. The designers on my team place more trust in my opinions about product design, and I find their feedback on content more useful as well.
For me, the most satisfying way to practice content-first design has been to work directly within the designs. I still write and maintain text documents, which often work better for quick, smaller content projects, or when I need to show multiple options at once. But when I have an idea I feel especially excited about, designing and prototyping it myself has been far more effective at getting buy-in and garnering interest than any document, proposal or brainstorm I’ve ever put together.
Update content yourself and get involved in code reviews
Most product content strategists rely on code — and the engineers who write it — for our work to see the light of day. So it’s worth understanding the coding (and code deployment) process, and even more important to become part of it. For me, working in code is all about owning my writing from concept to draft to publication. Being able to update content on my own is empowering, and it’s become an essential part of how I work.
I’d argue that true product literacy requires some form of code literacy. And code is, after all, just another kind of language—every content strategist’s natural medium. But if updating your own content or otherwise working directly in code sounds daunting, I’d suggest you start by gaining literacy in how engineers on your team work — the tools they use and how they iterate on and publish their code. If your team uses the software development platform GitHub, for example, consider learning how to create and merge your own pull requests. Learning new skills for their own sake is usually worthwhile, but learning skills that give you a more holistic perspective of your work is even more valuable. They help make you a more well-rounded collaborator and, because learning how your teammates work is a kind of empathy, you’ll build rapport in the process. Plus, if you know how engineers on your team work, you can insert yourself into their workflow and make their lives easier by removing steps from how they deploy your content. Fewer opportunities for confusion are always better.
True product literacy requires some form of code literacy. And code is, after all, just another kind of language — every content strategist’s natural medium.
I ask every engineer I work with to include me in their code reviews. Inserting yourself in the code review process helps ensure you’re a part of the conversation until the very end and that your team ships the text you specified. Lots of polishing and finessing tend to happen during implementation, and being in the thick of this process means you’ll find and address issues you’d otherwise miss. I’ve caught typos, found better phrasings at the last minute and prevented translation issues. Engineers appreciate that you’re helping to ship a better experience, too. If you want to dip your toe into developer environments or ship your own code, getting involved in your team’s existing code review process is a great place to start.
Make the case
It takes time to learn these skills, and it can feel daunting to change something fundamental about the way you work. It also helps to have a team that’s open to you taking a less traditional approach. If you’re having trouble getting your team on board, start by looking for small ways you can change how you work right now, rather than making an elaborate case to change a team-wide process.
If people are accustomed to you sharing documents with them, start incorporating visual examples of your changes in those documents. Build prototypes and link to them. Ask your team for suggestions on how you provide work to them, or how you can help them be more efficient.
If engineers aren’t tagging you in their code reviews, follow them in whatever coding environment they use and look for natural ways to join the conversation. Subscribe to their work streams so you can see what they’re up to. Depending on which coding environment you use, it may be possible to add a rule that automatically subscribes you to code reviews that involve specific engineers or content changes. After a while, engineers on your team will get used to you being around, and will start involving you without anyone feeling like they’ve had to learn and adopt a new process.
If you’re trying your hand at updating code and need someone to teach you, or need to make a case for getting the right permissions, try framing it as a way to save engineering time. When you’re fixing typos and tweaking error messages, engineers can focus on tougher problems—and you’re helping fix bugs in the process.
I don’t want to diminish the difficulty of changing hearts and minds. The good news, though, is that content strategy is so new, few people have a preconceived idea of how you’re “supposed” to work—you get to decide. So if you’re spending most of your time creating perfectly honed spreadsheets and documents, I’d suggest you put them aside for a while, and try using the same tools and processes as the designers and engineers on your team. Learn to speak their language. You won’t be disappointed.
