Inclusivity
This page defines inclusivity as it relates to design practice and describes the Customer.io approach to designing inclusively.
Inclusivity
✅Inclusivity is a methodology that considers the full range of human diversity with respect to ability, language, culture, gender, age and other forms of human difference. How it's practiced depends on the business.
✅Inclusivity is good design practice, but it's not a given: it's not currently part of our process. We're a white, young design team.
An inclusive designer is someone...who recognizes and remedies mismatched interactions between people and their world. They seek out the expertise of people who navigate exclusionary designs.
🚫 It is not
Accessibility: Accessibility is focused on folks with disabilities. Inclusivity's focus is broader than that, but it always starts with accessibility.
Universality: Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.
Customer.io is inclusive, but not universal, and that's okay. Not everyone is our audience, but we can design inclusively for the people who are.
What does it mean for Customer.io?
Research & recognise diversity We first need to know our customer. How might their experience of Customer.io vary based upon variables like internet connectivity, geographic location, the education level of the user, language (including slang), their age, their attention span? For example, understanding how to design for lack of focus or lack of attention will guide us in how much information we can and should present at a given time. Recommendation: put together a group of customers whose experiences vary wildly in as many variables as possible.
Incremental improvements and flexible configurations Inclusivity's foundation is accessibility. We start there and then work our way outward with incremental improvements. For example: dark mode options, as well as toggles between detailed and simplified table views. One inclusive piece of design we already have is a choice between builders. We shouldn't overreach. There are some people for whom specialised applications are needed. For example, folks with screen readers: we would need to validate how many of our customers use screen readers, and if we can (and should) optimise Customer.io for them. Recommendation: Evaluate feature requests such as dark mode and table view configuration with inclusion in mind. Ascertain if we think "enhancements" might be inclusion opportunities.
Recognise exclusion and bias We need to test our designs before they're built to see if they're exclusionary. An example of this might be a testing phase (an "inclusion teardown") as part of our process where we specifically test and look for how a design is not inclusive. We may also ask for feedback from users here— and not those that are most easily accessed. Recommendation: A part of our design process that allows us to test for exclusionary practices.
Seek out expertise This is a good time to remember: "nothing about us without us” When we aren't certain, we can and should ask. From our research in (1), we can form an understanding of which customers we can ask for feedback — those who vary a great deal in role, geography, language skills, etc. This will be critical and useful and actionable if we ask for feedback with inclusion in mind. Recommendation: put together a group of customers whose experiences vary wildly in as many variables as possible.
Last updated