Categories
Accessibility Content

How to create accessible and inclusive product content guidelines

View the original post

Side profiles of a diverse group of people against a graphic background in pink and blue with a star shape in the middle.
Illustration by Alek Mackie.

Four takeaways for starting small to effect change through language

At this year’s Button conference, we announced the launch of accessible and inclusive content guidelines in Polaris. Since launching two weeks ago, the guidelines have amassed over 1200 views, and are one of the top-viewed Polaris pages.

This has been an important project. We want to better represent and design for our users, and having these guidelines in Polaris can empower us to make our product better for everyone. Polaris is Shopify’s design system and language. It helps us create great experiences with a set of shared design practices.

Ultimately, Shopify’s mission is to make commerce better for everyone. Designing product for everyone includes users from historically-excluded communities.

I’ll share how and why we made these guidelines, and my takeaways for effecting change.

Why we did this

We’re not our users. ‘We’re not our users’ refers to the false-consensus effect. This is the tendency to assume that others share our beliefs and behave like we would in a given situation. But we’re also quite literally not representative of the people we design for. In the tech industry we have known and serious gaps in our cultural defaults. Tech employees are overwhelmingly young, white, cis-men from North America.

We need better representation and inclusion in tech. And, our content and design should reflect our international and diverse user base. For instance, 15% of the world’s people have disabilities. Our users come from different cultures, ethnicities, lived experiences, and speak different languages. Our users also come from historically-excluded communities, and have intersectional identities. Language has power, and we need to be aware of how our language can harm and exclude our users.

Language has power, and we need to be aware of how our language can harm and exclude our users.

What inspired us

Often, I’d come across questions like the following:

  • I’m trying to avoid blacklist but can’t think of an alternative. Does anyone know a good word to use instead?
  • Is it okay to say accounts are disabled?
  • Do you have a link to the terms to avoid spreadsheet?

We did have some guidelines, and an internal spreadsheet with ‘terms to avoid’, but there wasn’t a comprehensive, official resource.

When I came across these questions, I’d always think ‘I’d love for a resource like this to exist at Shopify’. Over time, I had a collection of sources, mainly external, that I would check when writing content. If I wasn’t sure, I’d ask around, or Google, but it wasn’t an efficient process.

I started to think that if everyone did the same, this was an inefficient use of time. More than that, it could lead to an inconsistent or non-inclusive experience for our merchants. Also, having our own guidelines sets an expectation that content should always be inclusive and accessible.

I didn’t know what I could contribute, but I knew I wanted to get involved somehow and learn more. There were some discussions around past and future initiatives, but nothing was in-flight. So I decided to move forward, and see what came of it, and off we went!

A timeline for change

We made the guidelines during Hack Days, a 3-day quarterly event for learning and experimentation. Anyone can create a project, and share it for others to join. I did so, and by the end of Hack Days, we had drafted guidelines, a word list, and we’d also done a quick audit.

I was really happy with what we accomplished since, on day 1, we were still researching and exploring what we wanted to build.

Real talk, though: this wasn’t really a 3-day project. It’s been a 6-month one. In May, I started exploring and planning the project, and Hack Days was in June. Since then, we’ve been editing, getting feedback, and editing some more. Finally, during our next Hack Days later in the year we got the guidelines into pull request in a final push to publish in October.

All in all, it’s been about 2–3 weeks’ of work. Making time is a tricky thing. It’s important to recognize that this work can be difficult and time-consuming. It’s often “side of desk” despite how important and impactful it is. For me, it helps to be moving towards something that fills me up with energy, and that I feel passionate about. Being able to speak to the incredible value and the business case also helps to make this work a priority.

It’s important to recognize that this work can be difficult and time-consuming. It’s often “side of desk” despite how important and impactful it is.

We also hope that this is just the beginning — our goal was to publish a first version as a starting point.

So, how did we do it?

Part of what allowed us to get the bulk of the work done within Hack Days was having a focused and clear scope. We had three priorities: anti-racist, ungendered, and anti-ableist content. We prioritized based on where we felt we could have the biggest impact to prevent and reduce harm. Also, we focused on where we, as a group, felt we had something to contribute based on our experience and knowledge. There’s more that we’d love to add in the future, but we wanted to get something of value out sooner than later.

We balanced conceptual guidance with tactical advice to make the guidelines easy to use. We wanted to answers questions like ‘I know to avoid this phrasing, but what’s a good alternative?’.

🎉 All that work resulted in the launch of our Accessible and inclusive language guidelines. I couldn’t be more excited to share these, and I hope you’ll take some time to read our guidelines and share any feedback with us!

If you’re looking to create something similar at your organization, or to effect change, here’s my advice and actionable takeaways from this project:

1. Assemble engaged people

I started this project in my first month as a content designer. If your organization’s culture allows for it, try not to let factors like tenure prevent you from effecting change.

I knew that this wasn’t something I could or should do on my own, but I could act as a facilitator to the work. Gathering engaged and knowledgeable people was the only way forward. Ideally, we’d have folks with experience in accessibility, product content, and development. I also didn’t want to proceed without people from the groups we wanted to represent. The focus for our content came as a natural result of the group that formed.

I did start by voluntelling people that I knew would be great additions to the project. Then, I posted the project in our Hack Days app. I also sent out messages in various content design, UX, and Hack Days-focused channels.

I wrote up a quick brief about the project with a collection of related resources. I created a Slack channel, and project docs that anyone could access and contribute to. We had a shared Google Drive folder, a working doc, and Slack notes pinned to the channel, so it was easy for people to hop in.

I wanted the project vision to be a group effort but having something to start with helps facilitate engagement. People are more likely to join and give you input once they have something to conceptualize.

2. Ask for forgiveness, not permission

‘Ask for forgiveness, not permission’ is a good principle for driving change forward. As Shopify is such a large company, it‘s easy to expect “the business” to have the responsibility to create change. We, as individual contributors, are Shopify, and should feel empowered to initiate changes that we want to see.

We, as individual contributors, are Shopify, and should feel empowered to initiate changes that we want to see.

Starting out, I tried not to think too hard about doing things the right way rather than jumping in. I picked and chose what process was going to help get shit done.

I also aligned the right stakeholders to my cause early. Having leadership buy-in, and influential people on your project can help in a few ways. First, you get the benefit of their sage advice and experience. Also, this can help drive other buy-in, and help you navigate the org chart, approvals, and avoid awkward ‘gotcha’ moments.

I knew that we could face obstacles with a sensitive project of this nature. This is why scope was very important, as well as getting buy-in. We’ve been lucky in having backing and support. If you’re doing similar work, I hope you’re as lucky in finding buy-in and a support network, too.

Overall, we had 15–20 people involved with the project. I’m still blown away and incredibly grateful that so many people were engaged with this work, and brought so much care, intentionality, and knowledge.

3. Involve communities you want to serve, and find allies

We had a cross-functional team from many disciplines — UX, engineering, support, and more. We also had people with disabilities, BIPOC, and LGBTQIA2+ members. To effect change, you need a diverse group with different perspectives, experiences, and expertise. You also want to find your allies, but above all, involve the communities you want to serve.

We took a pragmatic, tightly-scoped approach to feedback. We didn’t seek feedback from the entire company, or involve huge stakeholder groups for our V1. We only wanted feedback from the groups we wanted to represent.

Asking for feedback required awareness and care. We didn’t want to burden our colleagues, so we only asked for volunteer contribution.

There’s a careful balancing act. I believe allies should carry the load but you need diverse stakeholders. You want to follow diverse recruitment best practices, but also not ask too much of your stakeholders.

I believe allies should carry the load but you need diverse stakeholders. You want to follow diverse recruitment best practices, but also not ask too much of your stakeholders.

4. Iteration is your friend

This is just a start. We’ll continue to share our guidelines and seek feedback, and iterate. Our hope is that both this page and our understanding continues to grow and evolve over time! Just because we used one word for a long time, doesn’t mean that we should keep using it. We want to constantly evolve and learn.

If you have any feedback on the guidelines, please get in touch! Comment below, or connect with me on Linkedin.

Most importantly, take care of yourself and others in this work. It can be difficult, triggering, and heavy — and often those involved are the ones who experience the most harm. Take breaks, be aware of how you’re feeling, and practice self-care in whatever ways work for you. I encourage you to ask for help, and lean on your team and support network if you’re lucky enough to have one like I do.

I hope this blog post inspires you to start something small that could effect change wherever you’re working. As Margaret Mead said: “Never doubt that a small group of thoughtful citizens can change the world. Indeed, it is the only thing that ever has”.

Never doubt that a small group of thoughtful citizens can change the world. Indeed, it is the only thing that ever has.

Huge thanks and appreciation for the small group of thoughtful citizens on this project: Lora Rowan, Dani Ng-See-Quan, Jane Foley, Richard Harlow, Rachel Kattapuram, Nicole Mackin, Winter LaMon, Teri Hason, Stevie Douglas, Florence McCambridge, Clay Delk, Sarah Foster, Diana Oum, and Jack Horton. I also want to recognize the support from: JJ Galipeau, Devon Persing, Scott Vinkle, and Jen Shaw!


How to create accessible and inclusive product content guidelines was originally published in Shopify UX on Medium, where people are continuing the conversation by highlighting and responding to this story.