How we created inclusive writing guidelines for Firefox
Prioritizing inclusion work as a small team, and what we learned in the process.
Our UX content design team recently relaunched our product content guidelines. In addition to building out more robust guidance on voice, tone, and mechanics, we also introduced new sections, including inclusive writing.
At the time, our content design team had just two people. We struggled to prioritize inclusion work while juggling project demands and string requests. If you’re in a similar cozy boat, here’s how we were able to get our inclusive writing guidelines done.
1. Set a deadline, even if it’s arbitrary
It’s hard to prioritize work that doesn’t have a deadline or isn’t a request from your product manager. You keep telling yourself you’ll eventually get to it… and you don’t.
So I set a deadline. That deadline applied to our entire new content guidelines, but this section had its own due date to track against. To hold myself accountable, I scheduled weekly check-ins to review drafts.
Spoiler: I didn’t hit my deadline. But, I made significant progress. When the deadline came and went, the draft was nearly done. This made it easier to bring the guidelines across the finish line.
2. Gather inspiration
Developing inclusive writing guidance from scratch felt overwhelming. Where would I even start? Fortunately, a lot of great work has already been done by other product content teams. I started by gathering inspiration.
There are dozens of inclusive writing resources, but not all focus exclusively on product content. These were good models to follow:
- 18F’s Inclusive language
- Adobe’s Inclusive UX Writing
- Atlassian’s Inclusive language
- Apple’s Writing Inclusively
- Shopify’s Accessible and inclusive language
- Intuit’s Accessibility and inclusion
I looked for common themes as well as how other organizations tackled content specific to their products. As a content designer, I also paid close attention to how to make writing guidelines digestible and easy to understand.
Based on my audit, I developed a rough outline:
- Clarify what we mean by ‘inclusive language’
- Include best practices for how to consider your own biases and write inclusively
- Provide specific writing guidance for your own product
- Develop a list of terms to avoid and why they’re problematic. Suggest alternate terms.
3. Align on your intended audience
Inclusivity has many facets, particularly when it comes to language. Inclusive writing could apply to job descriptions, internal communications, or marketing content. To start, our focus would be writing product content only.
Our audience was mainly Firefox content designers, but occasionally product designers, product managers, and engineers might reference these guidelines as well.
Having a clear audience was helpful when our accessibility team raised questions about visual and interaction design. We debated including color and contrast guidance. Ultimately, we decided to keep scope limited to writing for the product. At a later date, we could collaborate with product designers to draft more holistic accessibility guidance for the larger UX team.
4. Keep the stakes low for your first draft
This was our first attempt at capturing how to write inclusively for Firefox. I was worried about getting it wrong, but didn’t want that fear to stop me from even getting started.
So I let go of the expectation I’d write perfect, ready-to-ship guidance on the first try. I simply tried to get a “good start” on paper. Then I brought my draft to our internal weekly content team check-in. This felt like a safe space to bring unfinished work.
The thoughtful conversations and considerations my colleagues raised helped me move the work forward. Through multiple feedback loops, we worked collaboratively to tweak, edit, and revise.
5. Gather input from subject matter experts
I then sought feedback from our Diversity & Inclusion and Accessibility teams. Before asking them to weigh in, I wrote a simple half-page brief to clarify scope, deadlines, and the type of feedback we needed.
Our cross-functional peers helped identify confusing language and suggested further additions. With their input, I made significant revisions that made the guidelines even stronger.
6. Socialize, socialize, socialize
The work doesn’t stop once you hit publish. Documentation has a tendency to collect dust on the shelf unless you make sure people know it exists. Our particular strategy includes:
- Include on our internal wiki, with plans to publish it to our new design system later this year
- Seek placement in our internal company-wide newsletter
- Promote in internal Slack channels
- Look for opportunities to reference the guidelines in internal conversations and company meetings
7. Treat the guidelines as a living document
We take a continuous learning approach to inclusive work. I expect our inclusive writing guidance to evolve.
To encourage others to participate in this work, we will continue to be open to contributions and suggestions outside of our team, making updates as we go. We also intend to review the guidelines as a content team each quarter to see what changes we may need to make.
Wrapping up
My biggest learning from the process of creating new inclusive writing guidelines is this: Your impact can start small. It can even start as a messy Google Doc. But the more you bring other people in to contribute, the stronger the end result in a continuing journey of learning and evolution.
Acknowledgements
Thank you to the following individuals who contributed to the inclusive writing guidelines: Meridel Walkington, Leslie Gray, Asa Dotzler, Jainaba Seckan, Steven Potter, Kelsey Carson, Eitan Isaacson, Morgan Rae Reschenberg, Emily Wachowiak
