WhisperPad: testing my way to the right default
A Mac speech-to-text app built on Whisper. Six rapid usability sessions killed a feature before it became the default, and an App Store rejection turned into two builds and an approval.
With live transcription on, people slowed down to read their own words and lost their train of thought.
The product
WhisperPad is speech-to-text for the Mac, running Whisper locally. Double-press Control, talk, double-press again, and the text lands wherever your cursor is. Nothing leaves the machine. It’s live with paying users, nine releases in, with an auto-update channel that moves the installed base onto current builds.
Six sessions, one feature cut
I ran RITE (Rapid Iterative Testing and Evaluation) with six participants in roughly fifteen-minute sessions, fixing problems between sessions as soon as the fix was obvious.
One participant asked to see the transcription happening, so I built live transcription. The next participant started reading their own words from a second earlier, slowed down to match them, and lost their train of thought. Live transcription was a bad answer to a real gap: people needed to know the app was listening. A simple listening indicator closed that gap and tested noticeably better.
Testing didn’t converge on one default. Some people liked the indicator, others preferred silent mode. My rule is that a feature only becomes the default when I’m certain it helps, so the rest ship as options.
The App Store rejection
Apple rejected an update under guideline 2.4.5 over how WhisperPad pastes text. I split it into two builds: the Mac App Store version puts text on the clipboard, and the direct version keeps auto-paste. Later Apple called, reviewed the case again, and approved the original behavior.
A bug found by customers
After launch, three users hit a silent microphone failure. Logs one of them collected led me to the cause: the direct build had shipped without its microphone entitlement. The fix was out the door an hour and twenty minutes after I sat down.