Designing for Cognitive Overload: UX When Your User Might Be Concussed
In high-performance sport, your user might have just taken a 45 mph impact to the head. They're dizzy, their vision is blurred, and your interface is asking them to make a decision.
This session is drawn directly from a real design challenge I've been working through at ORB Innovations, where I design the mobile experience for a smart mouthguard worn by combat and contact sport athletes. The core tension: building an app that monitors athletes for concussion risk when the person using it is potentially the least reliable narrator of their own physical state.
For product and design practitioners, this one gets into the kind of decisions that rarely make it into case studies: what do you strip away when a dashboard becomes dangerous? How do you communicate uncertainty without triggering panic? How do you design trust into a system when the sensors and the athlete are telling you completely different things?
I'll walk through the specific design decisions we made when traditional UX patterns collapsed: removing familiar conventions, rethinking information hierarchy under stress, and building for the messy reality of Bluetooth latency, sensor drift, and the ethical tightrope of false positives versus missed brain injuries.
We'll explore what I call the Visceral Interface framework using colour, haptics, and radically simplified decision trees to bypass cognitive load rather than manage it. And I'll share what actually happened when we tested with concussed athletes. Spoiler: most of what we thought would work - didn't.
Participants will leave with:
- A practical framework for designing when users are cognitively or physically compromised
- Strategies for communicating uncertain, real-time data in life-critical contexts
- Concrete patterns for bridging the trust gap between sensor readings and human intuition
- A new way of thinking about how hardware constraints, latency, accuracy, and drift should shape interface decisions, not fight them
This talk is grounded in real product work, with real tradeoffs and real failure. It's what happens when 'user-centered design' meets a user who can't remember their own name.
