2026 · Product Lead & Designer
Whspr
A crowdsourced urban intelligence platform for women navigating city spaces
Role
Product Lead & Designer
Team
Solo — product lead & designer
Research Methods
User Interviews, Secondary Research, Competitive Analysis
Platform
Mobile Web App
Duration
6 sprints
Hook
It started with something I kept doing without noticing. Every time I went somewhere new at night, I'd text three friends before leaving. “Is this bar okay to go to alone?” “What's the vibe there at night?” Yelp doesn't answer that. Neither does Google Maps. That knowledge lives in DMs and disappears the second the conversation ends.
81% of women have experienced harassment in a public space. 70% text or call someone to share their whereabouts when going out alone. That's not an edge case, that's baseline behavior for most women I know, myself included. So the question became simple: why doesn't anything capture the knowledge women already share with each other?
Safety apps exist. Citizen, for one. But research on apps like it (Chordia et al.) found they use deceptive design patterns that raise the salience of threat, alerting users to incidents that aren't even nearby. Users describe them as stressful and alarmist. That's not the same problem as mine. I didn't want to build something that makes the city feel scarier. I wanted to build something that makes the knowledge women already have findable.
That's Whspr.
My Role
I led the research, the product decisions, and the interaction design end to end: the interview study, the information architecture, the contribution flow, the trust and verification system, and the visual design system (dark UI, Signal Amber accent, DM Serif Display / DM Sans). I built the Claude Code prototype solo.
Research
Secondary research pointed to three things: perceived safety, not crime data, drives how women move through a city, and familiarity is the strongest predictor of it (Dubey, Ait Bihi Ouali, Ceccato). Fricker's epistemic injustice framework explains why that knowledge gets dismissed as anecdotal instead of trusted. And friction, done right, improves contribution quality instead of hurting it (Alter, Nissenbaum).
Interviews with women in NYC confirmed the behavior was already happening informally: warnings in group chats, not public reviews, because that felt exposing. Trust and anonymity were conditions for contributing, not nice-to-haves.
The Insight That Changed Everything
I went in thinking this was a safety problem. It's not, not only. It's a knowledge problem.
Women already do this work. They already track and share and warn each other. What's missing is infrastructure, somewhere for that knowledge to live that doesn't flatten it into a star rating or amplify it into fear.
That reframe changed the whole design direction. The question stopped being “how do I keep women safe” and became “how do I make sure this knowledge doesn't get lost, gatekept, or dismissed.”
[The gap diagram — existing safety apps vs. Whspr]
How Might We
How might we give women's place-based knowledge somewhere to live, without flattening it into a rating or a fear alert?
Design Decisions
Decision 1
No star ratings
Short, observational signals tagged with context instead. Five quick prompts before you can post, deliberately more than a rating takes. Contribution reads closer to testimony than a transaction.
Decision 2
Gender lives on the account, not the signal
Self-declared once at sign-up, shown automatically after. No mid-flow decisions, no settings-menu digging.
Decision 3
Trust is verified, not assumed
Browsing is open. Posting requires ID verification. Trust score factors in contributor history, corroboration across signals, behavior, not a blunt block.
Decision 4
Real data, not synthetic
Getting There & Back and Area Info pull from Mapbox. Real transit stops, real walk distances, not placeholders.
Decision 5
Day/Night toggle, not one blended score
A block that's well lit at 6pm and “grab a Lyft” at 1am is two pieces of information, not one average.
Signals older than six months fade out. Places with under four contributions show an “early data” flag instead of false confidence.
[Trust scoring diagram — account age, verification, location match]
[Day/Night mode side-by-side]
The Solution
Whspr: a crowdsourced urban intelligence platform for women navigating city spaces.
Search a place, see signals — short, observational, tagged with time and context
Getting There & Back — real walk to transit, well lit or not, busy or not
Area Info — what's open nearby right now
No scores. Just what someone who's actually been there noticed.
Onboarding
Search
Signals
Area Info
Submit a signal
Outcomes
Validated
The underlying behavior is real, every interview confirmed it, not one person questioned why this needed to exist. The verification-for-trust model landed well across conversations, one participant asked about it unprompted, meaning users understand authentication as part of what makes a signal worth reading.
Not yet done
Formal usability testing on the interface itself. The interviews validated the need, not the flow. That's the honest gap, and per Alison's note on Resy, the clear next step for a stronger outcomes section.
Still building
The moderation and corroboration layer is designed, not live. Trust scoring exists in the data model, not yet as active weighting logic.
What I'd Do Differently
Build the moderation layer for real. Corroboration between contributors should be the actual trust mechanism, right now it's designed, not live.
What This Taught Me
The knowledge people need already exists. Most of the time it's just sitting in the wrong place, unsearchable, undervalued, or split across a hundred private conversations. Good design doesn't invent that knowledge. It gives it somewhere to live.