READING TIME 90 - 120 minutes
- All Levels
- 6 Exercises to aid conceptualization and determine viability: Mapping out the Ecosystem, Why & Who, Checking Assumptions, Building on Assumptions, Are We The Best to Solve this Problem?
- Sticky-notes/post-its, writing tool + paper or text file
Before launching a project, you should take steps to understand the environment into which you are intervening, the community with whom you are working, and the position of your project with respect to the two. To begin cultivating this understanding, consider the following questions:
- What is the problem I intend to address?
- What form will my project take, and how exactly does my project solve the problem?
- Have other attempts been made to solve the problem, and, if so, how is my project different from those preceding attempts?
- Who are the users? Are there any risks associated with their engagement with the project? Could their circumstances change in the future, leading to eventual exposure to risks?
- Am I the right person to be completing this project?
Ecosystem mapping is one way of approaching these questions. The term ecosystem mapping comes from the world of user experience design and service design, and it refers to mapping “all the key roles that have an influence on the user, organization, and service environment. The ecosystem map is built by first displaying all the entities, and then connecting them based on the type of value they exchange.”
Ecosystem mapping: landscape of projects
We suggest that you begin the process of ecosystem mapping by examining the landscape of public-interest technology projects in your focus area:
- Identify activists, researchers, policy makers, and technologists with similar concerns, and develop an understanding of their various projects.
- Consider which problems they are working to solve, which communities they are actively serving, and, most importantly, which problems and communities remain underserved. Your project should be oriented toward these lesser-attended areas.
- Identify the sphere in which you plan to work, familiarize yourself with similar projects that have preceded your own. Examine these precedents, determine their unique contributions, and appreciate their successes and mistakes.
A critical evaluation of this work will ensure that your project represents a genuinely-novel solution to the problem at hand, and it will prove useful when you make decisions about the project’s shape and form during the design phase. Beyond these pragmatic concerns, there is also an ethical obligation to acknowledge and celebrate the work of those who came before you.
Ecosystem mapping: the community
Those who are new to human rights activism should know that it often takes years to earn the confidence of the communities with whom you plan to work. The long but invaluable process of creating foundational relationships with a community begins by building trust with its members.
Previous academics and researchers have reminded us of the many pitfalls of design ideation, particularly when we over-insert ourselves into the problem or create solutions that aren’t needed.
To understand principles of co-design, we look to the Tech for Justice Project (T4SJ[1]) and Kelly Ann McKercher’s Beyond Sticky Notes. In their 2018 report, “#MoreThanCode”, T4SJ presents the following recommendations which are central to co-design:
"Adopt Co-design Methods
This means spending time with a community partner, in their space, learning about needs, and working together through all stages of design. Usually, no new tech development is necessary to address the most pressing issues. Codesign methods have a growing practitioner base, but they could be better documented.
Center the Community’s Needs over Tools
Community needs and priorities must drive research, design, and development. Technology is most useful when priorities are set by those who are not technologists. Be humble and respect community knowledge. Process and solution should be driven by the community; do not make community members token participants.
Avoid Parachuting Technologists into Communities
In general, parachuting is a failed model. Don’t do it. Stop parachuting technologists into organizations or focusing on isolated “social good” technology projects, devoid of context, when the real need is capacity building. We are not saying “never bring someone in from outside a community.” We do think that it is worthwhile to develop better models for sharing local knowledge with national groups and for national groups to share their perspectives with local groups in such a way that all parties can benefit.
Stop Reinventing the Wheel
Well-meaning technologists often reinvent the wheel, without researching existing solutions. Designers, developers, and project leads, no matter what sector they are in, should begin projects by researching existing projects and organizations. This also stems from competitive, rather than collaborative, mindsets (“ours will be better, so we’ll just compete”). It is important to work together to develop shared tools and platforms, instead of only competing for scarce technology resources."
Turning to McKercher’s Beyond Sticky Notes, four key principles of co-design include:
- Share power – Acknowledge and address differences in power, and share power in “research, decision-making, design, delivery and evaluation”
- Prioritize relationships – Earn the trust of communities to facilitate stronger connections which leads to better co-design
- Use participatory means – Move communities from participants to partners by providing many way for people to partake in design e.g. visual, oral, kinesthetic approaches
- Build capacity – Play the role of coach rather than expert and be open to both teaching and learning
We dive deeper into co-design in Phase 2, Chapter 5.
This is where working with your community is key. Even if we are co-designing and creating tools and services alongside community members, we still have to consider the possibility that our projects may unintentionally harm the groups they are intended to help. They may not be secure, failing to adequately protect user data; they may be inaccessible, excluding groups for whom the resource is operationally unavailable; or they may be unsafe, creating opportunities for bad actors to exploit the system and its users. We could even place other vulnerable communities at risk by failing to recognize the implications of our work outside of our immediate sphere.
How to Ensure Community Safety?
Let’s first acknowledge that this is a hard problem to solve and that we might never completely address all of the potential risks. However limited our forecasts, it is possible to anticipate the ways that individuals might be harmed by a new resource. This occurs through robust research, ideation, testing, and iteration, which we will cover in Phase 1. Progressing through these stages thoughtfully and carefully can improve the safety, the functionality, and the value of our projects.
Ecosystem mapping challenges you to identify what is being done in your space, who is doing what, who might be left out of products or solutions, as well as identifying and distinguishing between the gaps you can (e.g. usability, content) and cannot (e.g. regulation, legislation) immediately fix. First, read NDI’s Co/Act guide for ecosystem mapping. It highlights how ecosystem mapping is the first step towards a human-centered design process and can be a pillar for how you position and differentiate your product throughout the design process.
In a document or on notes write out the following:
What are the boundaries or edges of our ecosystem?
What are the limits of the problem and project? For example, if you wanted to map an ecosystem around privacy-focused texting apps, you might ask: Who uses them? On what platforms or devices? How old are the users? How do users find the apps?
What is the issue you’re solving?
What pain points are being addressed and for whom? Is there an existing ecosystem surrounding this problem? If so, do you have access to those stakeholders? Draw on intersectional and global perspectives to broaden your thinking. The “problems” faced by users vary across country, region, and culture; few are universal.
Where does this ecosystem exist?
Is it software or hardware? What devices are involved? How does your problem relate to problems in the offline world? Remember that online life is connected to offline life. Problems native to the online world often spill over into the offline world. For example, harassment can start online but have offline ramifications like as seen with doxxing, when someone shares an address, phone number, or other personal details about someone they encourage online users to harass offline.
What are the actions that happen in the ecosystem or in your problem statement?
List all of them out, from the large-scale (or macro) to the small-scale (or micro). For example, if we look at the Slack communications platform, the ability to form a new channel is a macro choice: it concerns the structures within which users communicate. Meanwhile, the specific actions taken by users within these structures could be considered micro choices. For instance, can a user block an individual? Can they mute an individual? Can they mute notifications from a specific channel? Or can they only turn mute global notifications, or all notifications related to Slack? Thinking through every point of interaction is key. All these decisions need to be identified and anticipated. Remember, a bug is a feature until you fix it.
Part One: Why Are We Doing This?
In an interview with Fast Company’s Tricia Wang, Jahan Mantin, a co-founder of Project Inkblot, explains that she begins design sessions by having her clients ask, “Who the hell are we?” According to Jahan, this provocation allows her clients to realize the “different lenses our identities propel us to bring to the table because for better or worse our identities influence who we design for.”
In this exercise, following Jahan’s lead, let’s ask ourselves: “Who are we and why are we doing this?” This is a time for you to reflect on your motives; to explore your wants, desires, and hopes for the project; and to contemplate how the community can benefit from your work.
Start by answering the following questions:
- Why are we doing this?
- What are we bringing to the table?
- What can we do to help in this problem area?
- What are our assumptions and blind spots?
- What kind of knowledge and perspectives do we need to accomplish this project as equitably as possible?
- Do we have a tie or deep connection to the subject matter we are exploring?
- How are we meaningfully working with the community and not creating or furthering extractive practices?
- Does the community have the knowledge or tools to use our solution?
- Are we able to communicate clearly across cultures/languages?
Part Two: Who Do We Need to Talk to?
Use this prompt to recognize the people outside of your collaboration who need to be consulted, considered, and cited.
- List out the other researchers, activists, and individuals in this subject area with whom you are familiar, or list the research that already exists in this area.
- Next, highlight the gaps. Who are the missing people you need to find, cite, and contact? For example, you may write down:
- “We need to find a trusted local community member who has specific knowledge of this problem area”
- “We could benefit from more on-the-ground user testing”
- “We should find community partners in X region”
Your product will have many users! If you have an idea of your ideal user’s identity, this is the time to start considering how the project will change when users have different experiences or backgrounds. You should do this again in the Personas chapter (Phase 2, Chapter 6), but it can be valuable to check your own assumptions and biases before you start a project.
Start by thinking about one of your users. Change at least one part of their identity – their gender, sexuality, race, class, age, location, etc. Consider how their needs change when you transform the user. Think of their reasons for using this software from their different perspectives.
Let’s say we envision our principal user to be someone facing online harassment. Perhaps this user is a female journalist in the US who uses major social media platforms and faces gender-based violence online. We could change our user to be a female journalist in Egypt. She also uses major social media platforms and faces online, gender-based violence, but she also confronts attempts by state agencies to censor her work. We could then make another change. What happens if this journalist is also facing domestic violence?
This two-part exercise builds on the material you generated during earlier exercises.
Part One:
On a piece of paper, a digital document, or a post-it note, create five different kinds of users with very different backgrounds. How does each shift in identity complicate your problem statement or question? How does your product change for these new users? What risks and challenges do they encounter?
It is okay to make lightweight personas to help expand and challenge your initial questions or problem statement, however, final personas should be grounded by research on real people and their needs.
Part Two:
List all of the different issues facing your five users from part one. For each user, create a document and list (we like to use a series of post-its):
- Potential harms the users will face
- Tools and software they are using
- Problems they may face
- Other experiences specific to that user
You will now have five lists, five different documents or five stacks of post-it notes.
After the exercise, ask yourself:
- How are these users different?
- How will your project, research, or problem statement account for all of these different kinds of real world experiences?
- Does your project, research, or problem statement need to change? How will you change it?
- Did this exercise challenge your assumptions?
Remember, these are just preliminary steps and considerations to take into account, you will be doing the deeper research, persona development, and ideation in Phase 2.
In a document, list the primary needs of the community with whom you are working. That is, ask what problems they need solved. Narrow these problems down to those that you feel capable of addressing.
Ask yourself:
- Have you ensured whether this is the “right” problem to solve?
- Is your problem statement equitable? Does it consider marginalized communities? Does it support them?
- Do you have the community members’ trust? Will they consent to engage with the project and contribute to the research?
- Is the topic something in which stakeholders are invested? Is it something for which they are actively seeking support?
- Have you ensured that the community with whom you are working is the primary stakeholder or beneficiary?
- Can you work freely with them to address their problem without being constrained by financial, political, or social influences?
- Do you understand their culture? Do you speak the language of community members?
- Do they face risks by collaborating with you?
- What are your assumptions about the community’s threat model?
SUGGESTED READING:
First, ask yourself these questions:
- I have done a comprehensive environmental scan of the problem and the community spaces I am addressing.
- I have created an ecosystem map that includes everyone involved in this project and everyone affected by its introduction.
- I have the full support and trust of the community with whom I am working.
- I have created targeted questions for the different stakeholders and contexts within the ecosystem I am problem-solving for (e.g. when creating personas, you won’t ask the researcher the same questions that you ask the community organizer).
- I am in contact with a number of different NGOs and CSOs (civil society organizations) who work in this area.
- I have looked at how this problem affects many different communities across regions and cultures.
- I have ensured that my problem or hypothesis is not already well-documented or well-researched by communities outside of the Global North.
If you answered ‘no’ to 3 or more, you may not be the right person for this job, and you will need to find someone closer to the community to fill this role. If you’ve answered at least 5 of these with “yes”, you are ready to start working with your community!