Design for Safety, An Excerpt

According to antiracist analyst Kim Crayton, “intention without plan is chaos.” We’ve discussed how our prejudices, beliefs, and carelessness toward marginalized and resilient parties lead to dangerous and irresponsible tech—but what, precisely, do we need to do to fix it? We need a strategy, not just the desire to make our technical safer.

This book will provide you with that plan of action. It covers how to persuade your stakeholders that this work is required, how to respond to criticism that there isn’t really room for more variety, and how to incorporate health principles into your design work to create healthy tech. ( Spoiler: we do, but diversity alone is not the antidote to fixing unethical, unsafe tech. )

The procedure for ensuring equitable security

When you are designing for health, your goals are to:

• Discover the abuse-abuse potential of your product.
• style ways to prevent the maltreatment, and
• offer assistance for harmed people to regain control and power.

The Process for Inclusive Safety is a tool to help you reach those goals ( Fig 5.1 ). It’s a method I developed in 2018 to better understand the different methods I used to create products that were designed with safety in mind. Whether you are creating an entirely new product or adding to an existing element, the Process can help you produce your product secure and diverse. The Process includes five main public areas of action:

• Conducting study
• Developing themes
• Pondering problems
• creating answers
• Testing for health

It is intended to be flexible, so teams might not want to utilize every stage in all circumstances. Use the parts that are related to your special function and environment, this is meant to be something you can put into your existing style process.

And if you’ve used it, if you have suggestions for improving it, or just want to give an example of how it helped your staff, please get in touch with me. It’s a dwelling report that I hope will continue to be a helpful and practical tool that technicians can use in their day-to-day job.

If you’re developing a product especially for a defenseless group or victims of some kind of stress, such as an application for victims of domestic violence, sexual abuse, or drug habit, make sure to read Chapter 7, which specifically addresses the issue and should be handled a little bit different. The guidelines below are for evaluating safety when designing a more basic product that will have a large customer base ( which, we now know from data, will include particular groups that should be protected from harm ). Chapter 7 concentrates on goods made specifically for those who are most vulnerable and those who have gone through trauma.

Step 1: Conduct research

A thorough analysis of how your technology might be used for abuse as well as specialized insights into the experiences of those who have witnessed and perpetrated that kind of abuse should be included in design research. At this stage, you and your team will investigate issues of interpersonal harm and abuse, and explore any other safety, security, or inclusivity issues that might be a concern for your product or service, like data security, racist algorithms, and harassment.

broad-based research

Your project should begin with broad, general research into similar products and issues around safety and ethical concerns that have already been reported. For instance, a team building a smart home device would be wise to comprehend the many ways that already-existing smart home devices have been misused as abuse tools. If your product will involve AI, seek to understand the potentials for racism and other issues that have been reported in existing AI products. Nearly all different types of technology have some sort of potential or actual harm that has been covered in academic writing or in the media. Google Scholar is a useful tool for finding these studies.

Survivors as a specific field of study

When possible and appropriate, include direct research ( surveys and interviews ) with people who are experts in the forms of harm you have uncovered. In order to have a better understanding of the subject and be better positioned to prevent retraumatize survivors, you should interview advocates working in the area of your research first. If you’ve uncovered possible domestic violence issues, for example, the experts you’ll want to speak with are survivors themselves, as well as workers at domestic violence hotlines, shelters, other related nonprofits, and lawyers.

It is crucial to pay people for their knowledge and lived experiences, especially when interviewing survivors of any kind of trauma. Don’t ask survivors to share their trauma for free, as this is exploitative. You should always make the offer in the first interview, even though some survivors might not want to be paid. An alternative to payment is to donate to an organization working against the type of violence that the interviewee experienced. In Chapter 6, we’ll discuss more about how to appropriately interview survivors.

Specific research: Abusers

Teams that design for safety are unlikely to be able to interview self-declared abusers or those who have broken laws like hacking. Don’t make this a goal, rather, try to get at this angle in your general research. Describe the ways that abusers or bad actors use technology to harm others, how they use it to silence others, and how they justify or explain the abuse.

Step 2: Create archetypes

Use your research’s findings to create abuser and survivor archetypes once you’ve finished conducting your research. Archetypes are not personas, as they’re not based on real people that you interviewed and surveyed. Instead, they are based on your investigation into potential safety problems, much like when we design for accessibility: we don’t need to have identified any blind or deaf people in our interview pool to come up with a design that is representative of them. Instead, we base those designs on existing research into what this group needs. Personas typically represent actual users and contain a lot of information, whereas archetypes are more diverse and can be more generalized.

The abuser archetype is someone who will look at the product as a tool to perform harm ( Fig 5.2 ). They may be attempting to harm someone they don’t know by using surveillance or anonymous harassment, or they may be attempting to control, monitor, abuse, or otherwise torment someone they know.

Someone who is being abused with the product is the survivor archetype. There are various situations to consider in terms of the archetype’s understanding of the abuse and how to put an end to it: Do they need proof of abuse they already suspect is happening, or are they unaware they’ve been targeted in the first place and need to be alerted ( Fig 5.3 )?

To capture a range of experiences, you might want to create several survivor archetypes. They may know that the abuse is happening but not be able to stop it, like when an abuser locks them out of IoT devices, or they know it’s happening but don’t know how, such as when a stalker keeps figuring out their location ( Fig 5.4). Include as many of these scenarios in your survivor archetype as you need to. You’ll use these later on when you design solutions to help your survivor archetypes achieve their goals of preventing and ending abuse.

It may be useful for you to create persona-like artifacts for your archetypes, such as the three examples shown. Focus on their objectives rather than the demographic details we frequently see in personas. The goals of the abuser will be to carry out the specific abuse you’ve identified, while the goals of the survivor will be to prevent abuse, understand that abuse is happening, make ongoing abuse stop, or regain control over the technology that’s being used for abuse. Later, you’ll think about how to help the survivor’s goals and prevent the abuser’s goals.

And while the “abuser/survivor” model fits most cases, it doesn’t fit all, so modify it as you need to. For instance, if you found a security flaw, such as the ability for someone to hack into a home camera system and talk to kids, the malicious hacker would receive the abuser archetype and the child’s parents would receive the survivor archetype.

Step 3: Brainstorm problems

Brainstorm novel abuse cases and safety concerns after creating archetypes. ” Novel” means things not found in your research, you’re trying to identify completely new safety issues that are unique to your product or service. This step is intended to eliminate any potential risks that your product might have. You aren’t worrying about how to prevent the harm yet—that comes in the next step.

What other abuses could your product be used for besides what you’ve already discovered through your research? I recommend setting aside at least a few hours with your team for this process.

Try conducting a Black Mirror brainstorming session if you want to start somewhere. This exercise is based on the show Black Mirror, which features stories about the dark possibilities of technology. Try to figure out the most outrageous, horrible, and out-of-control ways your product could harm you in a show episode. When I’ve led Black Mirror brainstorms, participants usually end up having a good deal of fun ( which I think is great—it’s okay to have fun when designing for safety! ). I suggest that you time-box a Black Mirror brainstorm for the first half an hour, then dial it back, and then consider more realistic ways of harm the remaining half.

After you’ve identified as many opportunities for abuse as possible, you may still not feel confident that you’ve uncovered every potential form of harm. When you’re doing this kind of work, a healthy amount of anxiety is normal. It’s common for teams designing for safety to worry,” Have we really identified every possible harm? What if something is missing? If you’ve spent at least four hours coming up with ways your product could be used for harm and have run out of ideas, go to the next step.

It’s impossible to say 100 % assurance that you’ve done everything right, but instead of aiming for 100 % assurance, acknowledge that you’ve taken this step and have done everything you can, and pledge to keep putting safety first in the future. Once your product is released, your users may identify new issues that you missed, aim to receive that feedback graciously and course-correct quickly.

4: Create solutions

At this point, you should have a list of ways your product can be used for harm as well as survivor and abuser archetypes describing opposing user goals. Next, it’s time to figure out how to design in accordance with the objectives of the abuser and the survivors ‘ objectives. This step is a good one to insert alongside existing parts of your design process where you’re proposing solutions for the various problems your research uncovered.

Questions to yourself should you ask yourself to protect your archetypes and to support them

• Can you design your product in such a way that the identified harm cannot happen in the first place? If not, what barriers can you place to stop the harm from occurring?
• How can you make the victim aware that abuse is happening through your product?
• How can you assist the victim in understanding what they need to do to stop the problem?
• Can you identify any types of user activity that would indicate some form of harm or abuse? Could your product provide support for the user?

In some products, it’s possible to proactively recognize that harm is happening. For instance, a pregnancy app might be modified to allow users to report being assault victims, which could result in an offer to receive resources from local and national organizations. This sort of proactiveness is not always possible, but it’s worth taking a half hour to discuss if any type of user activity would indicate some form of harm or abuse, and how your product could assist the user in receiving help in a safe manner.

Nonetheless, be careful when doing anything that could harm a user if their devices are being monitored. If you do offer some kind of proactive help, always make it voluntary, and think through other safety issues, such as the need to keep the user in-app in case an abuser is checking their search history. In the next chapter, we’ll walk through a good illustration of this.

Step 5: Test for safety

The final step is to evaluate your prototypes from the perspective of your archetypes, who wants to harm the product and the victim of the harm who needs to regain control over the technology. Just like any other kind of product testing, at this point you’ll aim to rigorously test out your safety solutions so that you can identify gaps and correct them, validate that your designs will help keep your users safe, and feel more confident releasing your product into the world.

Safety testing should be performed in addition to usability testing. If you’re at a company that doesn’t do usability testing, you might be able to use safety testing to cleverly perform both, a user who goes through your design attempting to weaponize the product against someone else can also be encouraged to point out interactions or other elements of the design that don’t make sense to them.

If your final prototype or the finished product has already been released, you’ll want to conduct safety testing on both. There’s nothing wrong with testing an existing product that wasn’t designed with safety goals in mind from the onset —”retrofitting” it for safety is a good thing to do.

Although it might not make sense for you to test for both an abuser and a survivor, keep in mind that testing for safety involves both. Alternatively, if you made multiple survivor archetypes to capture multiple scenarios, you’ll want to test from the perspective of each one.

You as the designer are most likely too closely connected to the product and its design at this point, just like other types of usability testing, and you know the product too well. Instead of doing it yourself, set up testing as you would with other usability testing: find someone who is not familiar with the product and its design, set the scene, give them a task, encourage them to think out loud, and observe how they attempt to complete it.

Abuse testing

The goal of this testing is to understand how easy it is for someone to weaponize your product for harm. You want to make it impossible, or at least difficult, for them to accomplish their goal, in contrast to usability testing. Reference the goals in the abuser archetype you created earlier, and use your product in an attempt to achieve them.

For instance, we can imagine that the abuser archetype would have the goal of determining the location of his ex-girlfriend right now in a fitness app with GPS-enabled location features. With this goal in mind, you’d try everything possible to figure out the location of another user who has their privacy settings enabled. You might try to follow her running routes, view any information she has on her profile, view any information she has made private, and check out the profiles of any other users who are connected to her account, such as her followers.

If by the end of this you’ve managed to uncover some of her location data, despite her having set her profile to private, you know now that your product enables stalking. Returning to step 4 and figuring out how to stop this from occurring is your next step. You may need to repeat the process of designing solutions and testing them more than once.

testing for a Survivor

testing for a Survivor involves identifying how to give information and power to the survivor. It might not always make sense based on the product or context. Thwarting the attempt of an abuser archetype to stalk someone also satisfies the goal of the survivor archetype to not be stalked, so separate testing wouldn’t be needed from the survivor’s perspective.

There are times, however, when it makes sense. For example, for a smart thermostat, a survivor archetype’s goals would be to understand who or what is making the temperature change when they aren’t doing it themselves. If you couldn’t find the information in step 4, you would need to do it again by looking for the thermostat’s history log and looking for usernames, actions, and times.

Another goal might be regaining control of the thermostat once the survivor realizes the abuser is remotely changing its settings. Are there any instructions that explain how to remove a user and change the password, and are they simple to find? For your test, you would need to try to figure out how to do this. This might again reveal that more work is needed to make it clear to the user how they can regain control of the device or account.

Stress testing

To make your product more inclusive and compassionate, consider adding stress testing. Eric Meyer and Sara Wachter-Boettcher’s Design for Real Life inspired this idea. The authors pointed out that personas typically center people who are having a good day—but real users are often anxious, stressed out, having a bad day, or even experiencing tragedy. These are known as” stress cases,” and analyzing your products to see if they respond to specific stressors can reveal areas where your design lacks compassion. Design for Real Life has more details about what it looks like to incorporate stress cases into your design as well as many other great tactics for compassionate design.