TapOut: Social Stress Monitor

The target audience includes people who experience social or sensory overload in demanding environments. It may be relevant to some neurodivergent users, but we did not design it as a diagnostic tool for a specific condition.

We had three days to create a credible concept. Our team consisted of three collaborators; my focus was the UX strategy, flows, prototyping, surveys, and testing. The experience had to communicate clearly in seconds because its critical use case is a moment when attention may already be limited.

The sensing model was speculative. Heart rate, environmental noise, sleep, location, and other possible inputs have major limitations and privacy implications. TapOut cannot diagnose stress or guarantee a person’s safety. The product would need consent, sensible defaults, explainable signals, and accessible manual controls before any real-world development.

The team used a small sample of 16 early responses to evaluate the direction and clarity of TapOut’s interactions. My work covered user-flow decisions, prototype testing, and interpretation of feedback.

Feedback suggested the concept was understandable and identified notification behavior as an important problem to solve. These findings should not be described as a representative measure of demand or as proof of efficacy. We did not clinically validate sensing accuracy, false-positive rates, or whether TapOut reduces overwhelm in real settings.

If a specific percentage is used in a later version of this case study, it should be copied from the original survey results with the question wording and response count—not inferred from the total sample.

Possible context inputs included wearable heart-rate patterns and device/environment signals. None of those signals can tell us exactly what a person feels. Noise, sleep, location, and biometric data also raise consent and privacy questions.

The concept needs clear permissions, transparent monitoring status, manual overrides, and understandable options to pause or disable sensing. A false alarm should never become a reason for the system to keep pressuring someone.

The first concept overestimated what the sensing system could know and underestimated how much a notification might disrupt someone. Our early feedback made that clear.

The revised check-in has a clear hierarchy: the person can dismiss, postpone, or act. The monitoring controls are visible, the system does not continue prompting just because its estimate disagrees, and exit support can be reached manually.

This remains a prototype. The next iteration would need to test how often to check in, whether the wording feels respectful, and how the experience works when the user is not looking at their phone.

The first concept overestimated what the sensing system could know and underestimated how much a notification might disrupt someone. Our early feedback made that clear.

The revised check-in has a clear hierarchy: the person can dismiss, postpone, or act. The monitoring controls are visible, the system does not continue prompting just because its estimate disagrees, and exit support can be reached manually.

This remains a prototype. The next iteration would need to test how often to check in, whether the wording feels respectful, and how the experience works when the user is not looking at their phone.

The first concept overestimated what the sensing system could know and underestimated how much a notification might disrupt someone. Our early feedback made that clear.

The revised check-in has a clear hierarchy: the person can dismiss, postpone, or act. The monitoring controls are visible, the system does not continue prompting just because its estimate disagrees, and exit support can be reached manually.

This remains a prototype. The next iteration would need to test how often to check in, whether the wording feels respectful, and how the experience works when the user is not looking at their phone.