Case study
Can This Hurt Me?
A shipped AI-assisted safety product whose most important job was knowing when not to say yes.
Independent project · 2025–2026
Role
Product design, UX, AI-assisted development, product strategy, creative direction
Timeline
2025–2026
Scope
Product strategy, interaction design, AI output governance, voice and copy, App Store launch
Outcome
Live on the App Store
The challenge
People encounter unknown mushrooms and want a quick answer. The dangerous version of that problem is an AI that sounds confident about something where confidence itself causes harm. Some toxic mushrooms closely resemble edible ones. Symptoms can be delayed 6–24 hours, and by the time they appear, significant damage may already be done. Most consumer-facing AI products are optimized to answer. This one had to be designed to hesitate — to surface uncertainty, communicate risk, and stop short of the one thing users most want: permission.
The work was to build an AI-assisted safety product whose most important job is knowing when not to say yes.
Early research mapped mushroom hunting as both culture and public-health risk: part field guide, part folk practice, part romance, part emergency warning.
What I started with
A concept with real stakes and no prior template. There are mushroom identification apps. There are AI wrappers that return plausible-sounding answers. There is no established design language for a product that refuses to be either.
Early research mapped mushroom hunting as both culture and public-health risk: part field guide, part folk practice, part romance, part emergency warning. That tension shaped the product's central question: how do you help without manufacturing confidence?
The project began with the sharper name "Can This Kill Me?" but evolved into "Can This Hurt Me?" — not only for practical reasons, but because it was a more honest scope. The app was never only about lethal risk. Harm can mean toxicity, psychoactive effects, allergic reactions, gastrointestinal distress, or the false confidence that leads someone to make a dangerous decision. The new name reflected that.
The space between "this might be dangerous" and "do not eat this" is not a UI pattern anyone has solved. Every structural decision had to be reasoned from the safety posture up, not borrowed from convention.
My role
I owned the product end to end: concept, safety architecture, interaction design, voice and copy, visual system, AI output governance, and App Store launch. I treated the collaboration itself as a design system: AI expanded the implementation surface, while product judgment, safety posture, and final decisions stayed human-led. Field use shaped the accessibility baseline throughout — large targets, clear hierarchy, semantic structure, visible focus states, and color that never carried meaning alone. The product you can find in the App Store today reflects those decisions, not the tools that helped execute them.
Key decisions
Decision
Treat the AI model as a signal source, not a final authority.
Reasoning
An AI can look at a mushroom photo and produce a convincing answer. That can be useful, but it is not enough to show directly to a user. A confident-sounding guess can still be wrong, and in this context, being wrong can get someone hurt.
So the app treats the AI’s response as one input, not the final answer. Before anything reaches the results screen, the app checks what photos were provided, how uncertain the answer is, whether dangerous lookalikes are possible, and what level of caution is appropriate.
Only then does the app decide what the user should see: a limited assessment, a caution, a “do not eat” warning, or an emergency path. That is where “the model guesses; the app governs” becomes more than a principle. It becomes the product.
Tradeoff
It meant building a product that sometimes gives users less certainty than they came for: a limited assessment, a warning, a Poison Control path, or no confident answer at all. That can feel less satisfying than a clean identification. But in this context, restraint is not a limitation. It is what makes the product trustworthy.
Decision
Separate “we can’t say this is safe” from “stop — this may be dangerous.”
Reasoning
The app needed more nuance than a blanket warning. Saying “never eat wild mushrooms” would be safe, but it would also be too blunt to be useful. If every result sounds equally dangerous, users stop hearing the difference.
So the product uses a graduated safety posture. When there is not enough certainty, the app refuses to give permission. When there are stronger risk signals — dangerous lookalikes, toxicity concerns, or a potentially deadly match — the app shifts from caution to a clear warning.
That distinction shaped the language, color, and hierarchy of each result. The goal was not to make risk feel dramatic. It was to make each level of caution feel clear, honest, and proportionate.
Tradeoff
This is harder than using one universal warning. Each tier has to feel different without ever feeling permissive. The product has to stay useful while refusing to become reassuring in the wrong moment.
Decision
Use design restraint as safety infrastructure.
Reasoning
A mushroom safety app does not need to feel impressive. It needs to be hard to misread.
Every screen was designed to reduce the chance that a user would walk away with false confidence. The interface keeps the most important information close to the top: emergency help, the risk summary, the eating guidance, uncertainty, and lookalikes. Details are available, but they do not compete with the safety message.
The same restraint shaped the scan flow. Requiring specific photo angles makes the user slow down and understand that mushroom assessment is not a one-photo magic trick. The product does not pretend to know more than the inputs allow.
Tradeoff
A richer, more expressive interface might have felt more capable. This one is deliberately quieter. The goal was not to impress the user. It was to keep the product clear, serious, and difficult to misinterpret.
Product states
A few shipped screens showing how the safety architecture appears in the actual product.
These representative product states show the MVP flow in practice: entry, evidence capture, assessment, emergency escalation, and support. The interface is designed to keep the user inside strict safety boundaries while still making the experience feel usable, calm, and direct.
The goal was not to make the app feel authoritative by pretending it can know more than it can. The goal was to make uncertainty visible, require better evidence where possible, and repeatedly prevent the most dangerous interpretation of the result: “this is safe to eat.”
Outcome
The app is live in the App Store. More importantly, it now behaves like a safety product instead of a novelty identification tool.
The final product requires multiple photos before assessment, separates visual candidates from eating permission, gives users clear uncertainty language, keeps Poison Control visible, and refuses to turn AI confidence into a green light. It does not claim to identify mushrooms definitively. It helps users understand what may be risky, what remains unknown, and when they need human expertise or emergency help.
This changed the center of gravity of the product. The key design problem was not “How do we make mushroom identification easier?” It was “How do we prevent a plausible answer from becoming a dangerous one?”
The result is a shipped MVP with a stricter safety architecture, clearer boundaries, and a product direction that can now be improved through testing, expert review, and better photo-analysis robustness.
What shipped is not just a mushroom identifier. It helps surface likely candidates when possible, but never turns a possible match into permission. The model guesses. The app governs.