---
title: The FDAs Overdose App Development Contest
description: What the FDA's overdose app contest reveals about designing for stress, cognitive load and behaviour change in genuinely high-stakes situations.
image: https://weareaffective.com/hubfs/learning-centre-images/the-fdas-overdose-app-development-contest.webp
---

[Skip to content](https://weareaffective.com/learning-centre/the-fdas-overdose-app-development-contest-1#main-content)

[![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com)

- [Home](https://weareaffective.com)
- About Us 
  
    - [Our Story](https://weareaffective.com/about)
    - [How We Work](https://weareaffective.com/how-we-work)
- Our Services 
  
    - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy)
    - [App Design](https://weareaffective.com/app-design-agency)
    - [App UX Design](https://weareaffective.com/app-ux-design)
    - [App UI Design](https://weareaffective.com/app-ui-design)
    - [App Technical Architecture](https://weareaffective.com/app-architecture)
    - [Existing App Audits](https://weareaffective.com/app-audit)
- [Case Studies](https://weareaffective.com/case-studies)
- [Pricing](https://weareaffective.com/pricing)
- [Learning Centre](https://weareaffective.com/learning-centre)

- [Get Started](https://weareaffective.com/get-started)

Expert Guide Series

# The FDAs Overdose App Development Contest

 Table of Contents

The FDA ran a public contest asking developers to build an app that could help prevent opioid overdose deaths. The brief was, on the surface, straightforward: create something that a bystander could use in a real overdose situation to get help fast and administer naloxone correctly. But the more you sit with that brief, the more demanding it becomes. The app had to work at the worst possible moment, in the hands of a person who was almost certainly panicking, possibly with shaking hands, almost certainly without any prior training on what to do.

That is a radically different design problem from building a fitness tracker or a loyalty card app. The stakes are binary. Either the interface produces the right behaviour in time, or it does not, and the cost of failure is irreversible.

## Cognitive Load and the Stressed User Problem

Cognitive load is the amount of mental effort a person is using at any given moment. When someone is calm and focused, they can hold multiple pieces of information in working memory, weigh options, and make considered choices. When someone is stressed, that capacity drops sharply, which is a core consideration in [user psychology in app design](https://weareaffective.com/user-psychology-app-design). They can follow one clear instruction. They struggle to evaluate competing options. They lose information they were holding a moment ago.

An interface designed without accounting for that shift will work in testing, where the tester is calm and already understands the product, and fail in the field, where the user is not.

We encountered this directly on a pitch we ran for a BMW fleet management product. The existing app asked drivers who had just had an accident to photograph vehicle damage and fill in forms. The interface simply said "upload your photos" and presented a series of fields. The completion rate was poor, and the team could not understand why. The answer was straightforward: the instruction assumed that a person who had just been in an accident could calmly decide which angles to photograph, remember what information was needed, and work through a form methodically. None of those assumptions held under the stress of an actual accident.

The FDA overdose app faced the same structural problem at higher intensity. Any feature that required the user to hold information in memory, make a comparative judgement, or navigate away from the primary task was a feature working against the user at the moment they needed the product most.

Map out the emotional state of your user at each screen, not just their informational needs. A user who is calm on the home screen and anxious at checkout needs different things from the interface at each of those points.

## When the Interface Asks Too Much at the Wrong Moment

There is a particular kind of interface failure that does not show up in usability testing: the [feature that works perfectly for a user](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) who is paying attention, and fails the moment that user is distracted, rushed, or frightened. The failure mode is invisible in normal conditions because normal conditions are not where it bites.

In the meditation app we examined in depth, the visual design was doing something genuinely well. The breathing animations and soft gradients were slowing users down before they had even read a word. The interface was producing a calming effect through its behaviour, not through its copy. That is strong emotional design: the product's function creates the desired state rather than describing it.

But the same app then asked users to select a goal before they had done anything. Pick from sleep, stress, or focus. That prompt assumes the user is in a settled, reflective state where self-categorisation feels natural. The reality is that most people open a meditation app for the first time precisely because they are anxious and need immediate relief. Asking them to make a decision first adds friction at exactly the wrong moment.

For an overdose response app, the equivalent error would be presenting a menu of scenarios, or asking the user to confirm what type of naloxone they have, before beginning the guidance. A person in that situation needs the first step on the screen immediately. Anything that sits between them and that first step is an obstacle the interface should not be creating.

Before finalising any screen in a high-stress flow, ask what a user who is frightened and in a hurry would do with it. If the answer involves any reading, decision-making, or navigation, the screen needs to be simpler.

## Premature Decision Points and the Anxiety Trap

Decision points are friction. That is a description of how decision-making works. Every time a product asks a user to choose, it pauses them, draws on their attention, and requires them to compare options before they can move forward. In a calm, exploratory context, that friction is often fine. A user choosing a subscription tier or picking a workout type is in a frame of mind where deliberation is expected and welcome.

In an anxious state, that same friction amplifies the anxiety. A person who is already stressed and is then asked to make a decision before they can get to help will feel more, not less, overwhelmed. This is the anxiety trap: the interface meant to assist becomes the thing the user has to work through to get to the assistance.

In our meditation app teardown, the goal-selection screen was a clear case of a premature decision point. Asking someone to choose a goal in that state of mind adds a decision, and decision is friction, which increases anxiety rather than giving them relief. The app's visual design was earning trust and creating calm. The premature goal-selection screen was then spending both of those things immediately.

An overdose response app with a triage screen at the front, asking the user to confirm the situation before starting guidance, would make the same error at far higher cost. Decision points belong where the user has the cognitive capacity to use them and where the product cannot reasonably proceed without the information. Anywhere else, they are design debt the user pays with attention they cannot afford to spend.

## Safety, Trust, and the Limits of Clever Features

There is a temptation in product development to solve trust through features: a lock icon here, a privacy badge there, a reassuring message about data security. These things are not worthless, but they are also not where [trust is really built](https://weareaffective.com/learning-centre/how-do-i-build-trust-with-users-when-theyre-making-such-big-decisions). Trust is built through consistent, predictable behaviour. A product that does what it says, asks only for what it needs, and never surprises the user in a negative way earns trust through accumulated experience.

For an overdose response app, the trust question takes a specific form. A bystander using the app for the first time in a crisis has no accumulated experience with the product. They are extending provisional trust to something they have never used before, in a moment when they need it to be right. There is no second chance to repair a broken first impression.

This is why the decision we made on the fitness social app carries a lesson beyond that specific project. When we discovered the security risk embedded in live location sharing, the tempting response would have been to add a warning screen, tell users about the risk, and let them decide. Instead, we changed the architecture of the feature so the risk did not exist in the first place. The interface did not need to ask users to manage a problem; the design had already removed it.

For an overdose app, clever features like customisation options, social sharing, or gamified learning for naloxone use in non-emergency moments are fine in principle. But they cannot come at the cost of the one thing the product has to do flawlessly: guide a panicking person through a life-saving procedure in under two minutes.

## What the FDA Brief Implicitly Required That Most App Briefs Never Mention

A typical commercial app brief describes the user persona in terms of demographics and goals. It lists the features the product needs. It might include a note about tone of voice or visual style. What it almost never includes is a detailed account of the emotional state the user will be in at each point in the journey, what [cognitive capacity they are likely to have](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one), and what the cost of a poor decision at each step actually is.

The FDA brief, by the nature of the problem it was addressing, made all of those things unavoidable. You cannot design an overdose response app without confronting the emotional state of the user. You cannot write a flow for that app without considering what happens to a person's decision-making under acute stress. And you cannot evaluate features without a clear view of what failure costs.

Most commercial briefs sidestep all three. The user arrives as a persona with preferences, not as a person in a specific emotional state with a specific cognitive capacity. Features are evaluated against functionality and business goals, not against whether they serve the user in the state they are actually in when they need the product. And the cost of poor design is measured in churn or conversion rates, not in the concrete outcome the product was supposed to produce.

The gap between those two standards is substantial: the difference between designing for the ideal user and designing for the actual one.

## Why Commercial App Briefs Consistently Underprescribe Psychological Rigour

Commercial app development operates under pressures that push against psychological depth. Timelines are tight. Stakeholders want features. The brief is often written by someone who knows the business problem well but has not been trained to think about emotional states, cognitive load, or the gap between intended and actual user behaviour.

The result is briefs that are thorough about what the product should do and thin about how the user will actually experience doing it. The functional spec is detailed. The psychological spec barely exists.

This matters because the two are not separable. A feature list describes what the product can do. The psychological brief describes whether anyone will actually use it in the way it was intended. According to [NCBI research into health and wellbeing apps](https://pmc.ncbi.nlm.nih.gov/articles/PMC6231882/), 82% of apps assessed used the behaviour change technique of providing information about the behaviour-health link. Providing information is the easy part. Building an interface that ensures a stressed user can act on that information under real conditions is where the brief needs to go further.

On the grassroots football app we worked on, the client compared each feature to best-in-class single-purpose competitors and kept insisting the booking flow needed to be more intuitive. We pushed back, but ultimately complied. The changes made no meaningful difference, because the real problem was not the booking flow. The client was trying to do too many things in one product. Despite genuine effort to create something cohesive and emotionally grounded, the result was overly complex, too verbose, and not suited to the audience or its core purpose. A brief that had addressed the psychological experience of the user rather than just the feature set would have surfaced that problem earlier.

## What a Psychologically Rigorous Brief Actually Looks Like

A [brief that takes psychology seriously](https://weareaffective.com/learning-centre/why-most-business-apps-fail-and-how-your-digital-business-can-avoid-the-same-fat) starts with the user's actual emotional state at each point in the journey, not a generalised persona description. It names the conditions under which the product will be used and what those conditions do to the user's capacity to process information and make decisions.

It distinguishes between moments where the user has full cognitive capacity and moments where they do not. It specifies what the product must never do in low-capacity moments, such as presenting decision points, demanding data entry, or introducing unfamiliar interface patterns. And it defines what success looks like in behavioural terms, not just in usage metrics.

A rigorous brief also addresses the question of trust explicitly. Using the framework we apply to trust moments, it maps out every point where the product is asking something of the user, whether that is data, attention, time, or action, and assesses the realistic level of trust required for that ask. High-stakes ask moments get extra design attention. Low-stakes ones do not need to carry that weight.

| Brief element | Standard brief | Psychologically rigorous brief |
| --- | --- | --- |
| User description | Demographics and goals | Emotional state and cognitive capacity at each screen |
| Feature evaluation | Functionality and business fit | Effect on user under real use conditions |
| Success definition | Usage metrics and conversion rates | Behavioural outcomes in realistic conditions |
| Trust mapping | Absent or handled by copy | Explicit, with stakes assessed per ask moment |
| Failure cost | Churn or low engagement | Concrete outcome the product failed to produce |

Write a parallel brief alongside your standard feature spec. For each key moment in the user journey, describe the emotional state the user is likely to be in, what they have the capacity to do, and what the cost of a poor experience at that point is. Then evaluate every feature against that description.

## Conclusion

The FDA overdose app contest was unusual because it made the stakes of bad design inescapable. You could not write a brief for that product and pretend the user would arrive calm, attentive, and ready to explore. The design team had to confront the actual human being who would use the app, in the actual state they would be in, and build something that worked for that person rather than for a more convenient version of them.

That is the standard we think all product design should aspire to, even when the consequences of failure are less immediately visible. An app that fails a stressed user in a commercial context does not produce a death. But it does produce abandonment, eroded trust, and a product that does not do what it was built to do. The mechanism is the same. Only the cost is different.

Designing for the actual user means building an accurate picture of the emotional state they arrive in at each point in the journey, then making design decisions that serve that person rather than the idealised one. It means writing briefs that treat psychological rigour as a requirement, not an optional layer. And it means evaluating features against what they do to a real user under real conditions, not just against what they add to a feature list.

The FDA brief forced that discipline by making the failure mode obvious. Most commercial briefs do not. The gap between the two is where we do our work, and it is a gap worth closing before it closes on your users.

[Let's talk about the psychological rigour in your next brief](https://weareaffective.com/get-started)

## Frequently Asked Questions

What was the FDA's overdose app contest actually asking developers to build?

The FDA asked developers to create an app that a bystander could use during a real opioid overdose to get help quickly and administer naloxone correctly. The core challenge was designing something that would work reliably in the hands of a panicking, untrained person under extreme stress.

What is cognitive load and why does it matter for app design?

Cognitive load refers to the amount of mental effort a person is using at any given moment. Under stress, a person's ability to hold information in working memory, weigh options, or follow complex instructions drops sharply, which means an app that works well in calm testing conditions can fail completely in real-world use.

Why do so many apps fail in high-stress situations even when they pass usability testing?

Usability testing is typically conducted by calm, focused testers who already understand the product, which means stress-related failure modes simply do not appear. An interface that requires the user to hold information in memory or navigate competing options will fall apart the moment that user is frightened or rushing.

How does the BMW fleet management example illustrate the stressed user problem?

The app asked drivers who had just been in an accident to photograph vehicle damage and complete forms, assuming they could calmly decide on angles and work through fields methodically. In reality, none of those assumptions held under the stress of an actual accident, which is why completion rates were poor.

What does good emotional design look like in practice?

Good emotional design produces the desired emotional state through the product's behaviour rather than through written instructions. The meditation app described in the article is a useful example, where breathing animations and soft gradients created a calming effect before the user had read a single word.

What is the practical takeaway for designers who want to account for user stress?

Designers should map out the emotional state of the user at each screen, not just their informational needs, because a calm user and an anxious user require very different things from the same interface. Any feature that demands memory, comparison, or navigation away from the primary task should be reconsidered for high-stress moments.

Why is asking users to set a goal or categorise themselves early in an app often a poor design choice?

Prompts that ask users to select a goal or self-categorise assume they are in a settled, reflective state, which many users simply are not when they first open an app. Placing that kind of decision before the user has experienced any value from the product adds friction at the worst possible moment.

What makes the FDA overdose app brief so much harder than a typical consumer app?

The stakes are binary. Either the interface produces the correct behaviour in time or it does not, and the cost of getting it wrong is irreversible. That is a fundamentally different design problem from a fitness tracker or a loyalty card app, where a confused user can simply try again.

## Related Articles

[![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com)

20-22 Wenlock Road  
London, N1 7GU  
United Kingdom

+44 20 4572 8062  
[hello@weareaffective.com](mailto:hello@weareaffective.com)

<https://linkedin.com/company/weareaffective> <https://instagram.com/weareaffective> <https://facebook.com/weareaffective>

Services

[App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit)

Legal

[Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70)

Case studies

[TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift)

About us

[Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work)

Guides

[Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth)

 Copyright © 2026, weareaffective.com. All rights reserved.