$npx -y skills add Owl-Listener/inclusive-design-skills --skill voice-interactionDesign voice interactions and speech interfaces that work for people with diverse speech patterns, accents, and communication styles. Use when designing voice commands, voice search, dictation, voice assistants, or any interface that accepts speech input. Triggers on: voice, spee
| 1 | # Voice Interaction Design |
| 2 | |
| 3 | Design voice interfaces that work for the full range of human speech — |
| 4 | including accents, speech disabilities, non-native speakers, and people |
| 5 | in noisy or quiet environments. |
| 6 | |
| 7 | ## Who This Is For |
| 8 | |
| 9 | - People with motor disabilities who use voice as primary input |
| 10 | - People who stutter, have dysarthria, or other speech differences |
| 11 | - Non-native speakers with varied accents |
| 12 | - People in environments where typing is impractical |
| 13 | - Anyone who prefers voice to typing for certain tasks |
| 14 | |
| 15 | ## Core Principles |
| 16 | |
| 17 | ### Voice Should Never Be the Only Option |
| 18 | - Every voice interaction must have a text/touch/keyboard alternative |
| 19 | - Voice is an accelerator, not a gatekeeper |
| 20 | - Don't require voice for identity verification or critical actions |
| 21 | unless an alternative exists |
| 22 | |
| 23 | ### Design for Speech Variation |
| 24 | - Support varied pacing — don't cut off slow speakers |
| 25 | - Allow generous silence before timing out |
| 26 | - Don't penalise repetition, filler words, or self-correction |
| 27 | - Support multiple phrasings for the same intent |
| 28 | ("go back", "previous page", "take me back", "undo") |
| 29 | |
| 30 | ### Feedback Must Be Clear |
| 31 | - Confirm what the system heard (visual transcript) |
| 32 | - Make it easy to correct misrecognition |
| 33 | - Show when the system is listening vs. processing vs. waiting |
| 34 | - Never execute a destructive action on voice alone without |
| 35 | confirmation |
| 36 | |
| 37 | ## Design Patterns |
| 38 | |
| 39 | ### Flexible Recognition |
| 40 | - Accept multiple ways to say the same command |
| 41 | - Don't require exact phrasing — intent matters more than syntax |
| 42 | - Support "did you mean?" clarification for ambiguous input |
| 43 | - Allow users to spell out words the system doesn't recognise |
| 44 | |
| 45 | ### Graceful Failure |
| 46 | - When recognition fails: show what was heard and offer correction |
| 47 | - Never respond with just "I didn't understand" — offer alternatives |
| 48 | - Provide a "type instead" option at every failure point |
| 49 | - After repeated failures: proactively suggest switching to text input |
| 50 | |
| 51 | ### Privacy and Control |
| 52 | - Clear visual/audio indicator when microphone is active |
| 53 | - Easy one-action mute/stop listening |
| 54 | - Don't record or transmit audio without explicit consent |
| 55 | - Allow users to review and delete voice data |
| 56 | |
| 57 | ## Assessment Questions |
| 58 | |
| 59 | 1. Can every voice-activated feature also be completed without voice? |
| 60 | 2. Does the system handle varied speech patterns without frustration? |
| 61 | 3. Is there clear feedback showing what the system heard? |
| 62 | 4. Can users easily correct misrecognition? |
| 63 | 5. Is it obvious when the system is listening? |