Wikimedia Product/Inclusive Product Development/Principles

Background

In August 2021, the working group carefully crafted a proposed list of Product Development Principles and reached out to the Product and Technology departments for input on how to redraft and narrow down the set of principles that would help guide our work. The survey had over 80 responses across Technology and Product.

Selected Principles and Explanation

Based on the survey feedback received, the principles the group have landed on are:

1. Diverse teams are necessary, but not sufficient.
2. Create a culture of inclusivity.
3. Equal is not always equitable.
4. Learn from many perspectives and experiences.
5. Be intentional about who and why.
6. Build with, not for.

The explanation for these principles are:

First we ensure our teams are diverse and that the diversity is celebrated and enriched through inclusion. Then we remember there are nuances to what we are working towards i.e. equity, not equality. To do this we must learn from many perspectives and experiences while being intentional about who and why them. All this allows a team to build with, not for.

Contents of Survey

The survey leading to this outcome asked respondents what their organization function was (e.g. Engineering, Product, Analytics, Design) and had an optional response about what department they belonged to. Following that, respondents were asked to rate the following set of principles on a scale of In favor/Neutral/Not in favor, with multiple choices possible (e.g. respondents could check both "In favor" and "Neutral" if they were somewhere in between):

1. Be detailed, and flexible.
2. Create a culture of inclusivity.
3. Communication is a partnership.
4. Everyone is different.
5. Build with, not for.
6. Be intentional about who and why.
7. Team diversity supports product diversity.
8. Needs and preferences change with context.
9. Diverse teams are necessary, not sufficient.
10. Learn from many voices.
11. Equal is not always equitable.
12. Decisions need reflections.
13. Risk nothing, change nothing.
14. Designing for a minority also benefits the majority.
15. Be entrepreneurial.
16. Embrace change.
17. Naming exclusion unlocks the potential of inclusion.

Respondents were then given the same set of principles except "Needs and preferences change with context" with a more detailed explanation of the meaning of the principle, and again asked to rate each principle on a scale of In favor/Neutral/Not in favor. The order of most of the principles was changed from the first round.

1. Be detailed, and flexible: Be clear, intentional, and detailed about who you are (and are not) building for, what their needs are and why you chose that audience. Also balance remaining flexible enough to accommodate for necessary adjustments as you learn more evidence-based information about your target users needs and the team’s capabilities.
2. Decisions need reflections: Whether it is code that was pushed, a feature that was cut, a user that was excluded, or words that were said, decisions should lead to reflection. By reflecting on the decisions we make, we evaluate the positive and negative implications of said decision. That reflection should inform what, if any, steps should be taken to make adjustments based on what we’ve learned.
3. Communication is a partnership: At all points of the software development process, have a two-way communication with members of our community, aspiring community members, and relevant teams at the Wikimedia Foundation. Communication should be tailored to the audience you’re engaging, expand beyond the loudest voice, start from a place of empathy, and occur often enough to inform your work. Constantly and consistently interrogate how your team can reduce barriers of entry for all to participate. Determine ways to simplify highly technical processes and reduce jargon so that anyone can learn and engage with your team at any point in your process.
4. Everyone is different: We all have differences in needs and preferences. As fellow human beings we have a responsibility to make everyone feel accepted, welcome and included.
5. Diverse teams are necessary, not sufficient: While having a diverse team is important for supporting product diversity, there are limits to what one individual can provide in representing a myriad of intersections. For that reason, it is important to leverage available data, tools and resources to equitably include more diverse experiences beyond the perspectives in the team. Engaging user research, Community Ambassadors, and other external resources like accessibility experts must be a built-in part of your development process to avoid unconscious gaps.
6. Create a culture of inclusivity: We can’t build inclusive products if we’re not practicing inclusivity. This is not just about onboarding, we must be inclusive in every aspect of team formation, team relationships and rituals.
7. Equal is not always equitable: Increasing access to products, so they are available to more users does not mean that more users will be able or willing to use those products. To make the products equitable, they need to be be modified or redesigned to accommodate the unique needs and preferences of historically underrepresented users.
8. Team diversity supports product diversity: Be intentional about ensuring your team and groups you partner with represent a breadth of backgrounds, perspectives and experiences. The more diverse the team the greater the opportunity to create products that are more sensitive to the needs of more people. Leverage resources from T&C to reduce barriers during the hiring process that could deter future culture adds, and create a culture of belonging.
9. Be intentional about who and why: Be clear, intentional and specific about who you are (and are not) building for... what their needs are and why you chose that audience. Balance remaining flexible enough to accommodate for necessary adjustments as evidence-based learning bring clarity about target users' needs and the team's capabilities.
10. Build with, not for: To build with we must forge a win-win partnership with the target community, and practice listening deeply for their ideas, needs and preferences. We must understand the product we envision in the context of a life lived. We must constantly and consistently interrogate how our teams can reduce barriers to entry for all to participate, and we must reduce jargon to that anyone can learn and engage in the process of product development.
11. Learn from many voices: It is important to leverage all available data, tools and resources to equitably include more diverse experiences beyond the perspectives in the team. To avoid unconscious gaps, engage User Research, Community Ambassadors and other external resources like accessibility experts as a built-in part of your product development process.
12. Risk nothing, change nothing: Be bold, be brave, be willing to take chances.  Taking a risk often makes us uncomfortable. It's natural to go the other way. But comfort leads to complacency, complacency leads to stagnation, which is the exact opposite of change. The only other option to taking a risk is not taking any. And without taking one at all, there is no progress. That is precisely the biggest risk of all.
13. Designing for a minority also benefits the majority: Products designed for underrepresented users often have additional features or functionality useful and appealing to majority users. For example, Closed Captioning was popular among people for whom English was a second language, for watching shows in which the dialog was spoken very quickly or with accents, mumbling or background noise.
14. Be entrepreneurial: With the Foundation being a tech nonprofit, sometimes we have to think outside of the box and be scrappy.  Build-in time to experiment and prototype new ideas, test hypotheses, and leverage comparative analyses of industry innovations. Learn from the work of other teams and departments. We should always be learning and sharing what we’ve learned.
15. Embrace change: Learn continuously, and pivot.
16. Naming exclusion unlocks the potential of inclusion: Just as questions are necessary to find answers and problems are necessary to find solutions, naming exclusion is necessary to identify opportunities to make products more inclusive. When looking for ways to make products more inclusive, look at how the product is currently exclusive to underrepresented groups or individuals.

The final part of the survey was a text field where respondents could leave feedback.