Smashing Podcast Episode 41 With Eva PenzeyMoog: Designing For Safety — Smashing Magazine

Safety Isn’t Just a Feature

In the latest Smashing Podcast episode, host Drew McLellan sits down with Eva PenzeyMoog, founder of The Inclusive Safety Project and author of the upcoming A Book Apart title Design for Safety. PenzeyMoog, who also works as Principal Designer at 8th Light, talks with McLellan about interpersonal safety—a concept far removed from the threat models most engineers are used to building against.

It’s not about protecting users from anonymous hackers or preventing data breaches. Instead, it’s about the ways people who know each other—romantic partners, parents and children, even employers and employees—weaponize everyday products to harm one another.

Before digging in, PenzeyMoog adds a trigger warning: the conversation touches on domestic violence, elder abuse, and child abuse.

Why the Happy Path Isn’t Enough

McLellan observes that design teams tend to optimize for the happy path—the scenario where users behave exactly as intended. Engineers plan for validation failures and server outages, but the industry rarely considers how malicious actors might use a product when they have a pre-existing, intimate relationship with the victim.

PenzeyMoog calls this the "domestic violence threat model." It’s a blind spot she sees all the time in her work. "People are very familiar with these various threat models—the anonymous person harassing you on Twitter, different entities trying to hack into a banking company’s data," she says. "But we call it the domestic violence threat model, which is super different."

That difference matters: the victim isn’t a faceless user wronged by a stranger. They’re often locked out of their own finances, tracked without consent, or surveilled inside their own home. And the tools that allow this are usually ones they happily used earlier in the relationship.

"The abuse doesn’t start on day one," PenzeyMoog reminds listeners. "It’s usually a really great relationship at first, and then they slowly introduce different forms of control."

Messaging Turns Into a Weapon

The design failures aren’t hard to find, PenzeyMoog says. Everyday assumptions about users having full control of their accounts conveniently overlook how often accounts are shared or coerced. She points to peer-to-peer payment apps like Venmo as a clear example: they require a message field alongside the payment, but abusers send one cent alongside a threatening message, and there’s no straightforward way for the recipient to block fund transfers without refusing cash.

"The users receiving those messages have no way to flag that," she says. "Why would you want to stop someone sending money from you?"

That scenario represents a broader issue: designers rarely stop to ask who else might be affected when an account—or its notification settings—ends up in the wrong hands.

Location Sharing and the Consent Problem

Location sharing services deserve particular scrutiny, PenzeyMoog says. Apple’s Find My is genuinely useful for parents wanting to keep tabs on kids. But once a partner has been granted access, there’s often no auditing or user alert to say who can see where you are. Google Maps sends users a periodic summary of distinct individuals who have access to their currents, which PenzeyMoog sees as useful—though 30 days is far too long between reminders of the kind of persistent consent problem this creates in an emotionally abusive setting.

"Just because you consented to something in the past doesn’t mean you consent to it now or in the future," PenzeyMoog explains. "But in tech, we are like, 'Well, they consented five years ago, so that consent is still valid.' That’s really not the case."

"Even if you’re not able to necessarily end the location sharing, there are definitely other things that we can do that will keep users safe while still conserving the core functionality of the feature," she says.

Modern Surveillance Is Invisible

Microphones, cameras, and smart doorbells have made covert surveillance commonplace. PenzeyMoog’s concerns go beyond the obvious cases of stalkers; she points to a wider problem of intimidation and control. Users in abusive environments often have no private place left in their own homes, which is especially destructive when one partner is trying to isolate the other from a support network.

The COVID-19 pandemic amplified all of this, PenzeyMoog says. With victims trapped at home, tech-facilitated abuse spiked as abusers gained more time to use connected devices as instruments of control.

Don’t Shift the Burden to Users

PenzeyMoog rejects the argument that product makers are just building tools and are not responsible for the ways users might misuse them. She’s blunt about the flaw in that reasoning: it demands an unrealistic level of technical literacy from people who are often not in a good position to think clearly at all.

"It’s easy for those of us who work in tech to say people just need to learn more about it… but you’re talking about dozens of products we’re putting the onus on people who are going through a dangerous situation to understand," she says. People who live under constant threat operate in survival mode, without full executive functioning to inspect every feature and imagine worst-case misuse. The burden lies with the people building the products, not with those enduring abuse.

Archetypes Built for Testing

PenzeyMoog’s book presents teammates with a practical tactic: build abuser and survivor archetypes. They’re personas with named goals—the abuser might seek out a previous partner’s exact location through Strava’s public exercise routes, while the survivor’s need is to keep that information unintentionally masked under settings they’d reasonably have assumed were private.

The main point is to test products against these goals. One of her examples involves Strava, which until recently had a privacy flaw where, even with all location data private, running met another user on nearby paths could tag you in their visibility even unknowingly. Such an example means run teams don’t have to divine every real act of abuse, just work against archetypal—"Black Mirror brainstorm" targets. Teams dream up the most extreme scenario, then dial it back into something realistic before writing solutions.

But you can’t catch everything, says PenzeyMoog. So wrap the design in ways for users to report future problems quickly, and react to them without blame.

How to Lead Within Your Own Team

PenzeyMoog shares advice for starting change within an in-house team or organization:

• Prepare explicit answers to stakeholders’ practical questions about time and cost.
• Frame design for safety as part of your overall design process, not an extra gate.
• Mentally prepare for awkward conversations about abuse and surveillance in engineering meetings.
• Enlist a supportive coworker in advance to validate a concern and buffer tension if the topic lands as confrontational.
• Solicit—and truly compensate—consultants with direct lived experience instead of relying on unpaid emotional labor from colleagues.

Outside of her professional focus, PenzeyMoog finished reading Living in Data by Jer Thorp. She says she had expected a typical rant about big tech and privacy, but found it more profound—a philosophical look at what it means to live as a person constantly generating data pollution. She says she recommends it highly.

Design for Safety is out now from A Book Apart. PenzeyMoog keeps an active personal site at evapenzeymoog.com linking to all her work, in addition to a resources hub at The Inclusive Safety Project’s website, where readers can find lists of related books, studies, and researchers. Eva PenzeyMoog can also be reached on Twitter at @epenzeymoog.

Hear the full conversation on the Smashing Podcast.