A brain signal is a probability, and requires user oversight.
Cadence reads brain activity with EEG sensors worn against the scalp inside a soft cap. Nothing is implanted and no surgery is involved.
The challenge is to help someone compose and speak a sentence using one slow and sometimes unreliable signal. Cadence highlights available letters and commands one at a time, and the user produces a brain signal when the option they want is highlighted.
The result is an interactive prototype that responds differently depending on how confident the system is that a selection was intentional.
Cadence is an independent design exploration focused on trust, agency, and error recovery in brain-computer interface communication. It is designed to be efficient, cautious, and respectful of the person behind every selection.
This is the working prototype. The blue SELECT bar is the switch: tap it, click it, or press the spacebar to choose whatever is highlighted.
The hardware
Something a person would actually wear.
An EEG cap is only useful if someone is willing to put it on every morning. So the sensors are hidden inside something that looks like a hat rather than a medical device, in a range of styles, colors and textures.
Accessory concept for wearable EEG technology
The problem
Balancing the technology with a user’s autonomy
Most communication interfaces assume every selection is deliberate. With a brain-generated signal, an accidental input could add the wrong letter, trigger a command, or erase a message that took several minutes to compose.
Asking users to confirm every action would reduce errors, but it would also make communication much slower and more tiring.
The design approach
Confirm the uncertain, not the obvious.
I designed an adaptive confirmation system. It keeps the interface efficient when the signal is clear and cautious when it is uncertain.
01
Clear signal
When the signal is strong, the choice goes straight through. Someone the system is reading accurately is never slowed down.
02
Uncertain signal
When the signal is weak, the system asks once before anything is added or changed.
03
Clear always asks
Clear stays on the keyboard, so a message that came out wrong can always be discarded. Selecting it never wipes anything on its own: it raises a confirmation that opens on Cancel.
Protecting the user’s work
Accurate translation is the goal. Loss of autonomy is the risk.
My first prototype required confirmation for both Speak and Clear. Testing the interaction revealed that confirming Speak added unnecessary effort. Speaking the message is the goal of the experience.
Clear is different. An accidental selection could erase several minutes of work, so it always requires confirmation.
Accessibility
I reviewed the interface against WCAG 2.2 AA and found six color-contrast issues. The most serious was the Confirm button, the one control a person leans on when the system is unsure.
6contrast issues found
2.3:1Confirm button contrast, before the fix
6.6:1Confirm button contrast, after the fix
Contrast was the part I could measure. These are the parts that decide whether the interface is usable at all.
01
Timing is set by the user
How long the highlight rests on each key is a setting, not a fixed speed. It can be slowed down or sped up to match the person using it, which the accessibility guidelines require rather than suggest.
1.2 seconds per step
02
It speaks while it scans
Every row and key is announced aloud as the highlight reaches it, including Cancel and Confirm, so the interface can be driven without watching it.
“row: I, you, the, please”
“clear”
“Cancel”
03
It announces every change
The screen reader says “Low-confidence signal. Please confirm.” instead of naming a button. Every label is written as a sentence, and the interface speaks up on its own whenever something changes.
Scanning keyboard. A highlight steps through each row, then each key.
Low-confidence signal. Please confirm.
Your message: I would like some water
04
Nothing is small
Every key is 64 pixels tall and the switch is 72. The guidelines ask for 24, so nothing here is anywhere near the smallest a target is allowed to be.
24smallest allowed44recommended64Cadence
I documented the approved values in the design system.
