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:
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:
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) 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:
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:
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.
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.
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.
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):
You will now have five lists, five different documents or five stacks of post-it notes.
After the exercise, ask yourself:
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.
First, ask yourself these questions:
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!