PRODUCT DESIGN . CONCEPT
Siri Voice Passphrase
A voice passphrase that lets Siri handle simple hands-free tasks while the phone stays locked.
ROLE
Solo Designer
TOOLS
Figma
STATUS
Concept
ORIGIN
Personal pain point
THE PROBLEM
"You'll need to unlock your iPhone first."
“Hey Siri, call my friend.” “Hey Siri, navigate home.” Most of the time it works. Often enough, Siri responds instead with “You’ll need to unlock your iPhone first”. I hit this constantly, especially when driving.
A quick search turned up a handful of threads with people hitting the same wall, including a motorcyclist unable to get directions without pulling over to dig his phone out mid-ride. It wasn’t a wide validation pass, just enough to confirm this wasn’t only my own experience.
WHY IT HAPPENS
"Unlocking isn't caution for its own sake."
Before designing a fix, I wanted to know why the restriction exists, and my first assumption was wrong. iPhone Siri does have some voice recognition: “Hey Siri” is trained to your specific voice, so it wakes for you and filters out other people nearby. But Apple has never treated that as a security check, it’s tuned to cut down false triggers, not to verify identity for anything sensitive. Once Siri’s listening, unlocking is still the only real gate: the only verification strong enough for messages, contacts, and app data is Face ID.
That reframed the problem: not “give Siri a first voice-identity layer,” since it already has one, but “add a second, separately scoped voice check that doesn’t ask to be trusted any more than Apple’s own wake-word system is.”
Where Others Stand
Google authenticates the voice. Alexa never asks.
Google Assistant’s Voice Match trains on your specific voice and can authenticate personal requests while locked, on some Android versions, it can even unlock the phone entirely by voice. Google’s own documentation flags that as weaker than a PIN or biometric, but it’s still a more trusted use of voice than Apple’s: iPhone’s own “Hey Siri” recognition is personalized too, it just isn’t used for anything beyond deciding whether to wake up. Alexa skips the question altogether: smart speakers are shared household hardware with no lock screen to get through in the first place, not a comparable case.
That leaves a real gap between the two ends. Siri’s all-or-nothing gate is stricter than it needs to be for low-risk requests. Google’s full voice-unlock is looser than Apple would likely ever ship. Voice Passphrase sits deliberately in between: more capable than Siri’s current default, more conservative than Google’s, since it never unlocks the device itself.
THE IDEA
A passphrase that authenticates the action, not the person.
A spoken passphrase, set up once, that unlocks a small set of low-risk voice actions (calls, navigation, music) without ever unlocking the phone. Anything sensitive still requires a real unlock, same as today.
THE FLOW
Blocked, enabled, spoken, verified.
Locked out. The problem in one screen: a simple request, stopped cold.
Turning it on. Settings → Apple Intelligence & Siri → Siri Passphrase. One toggle, one setup step, nowhere it wouldn’t already be expected.
Setting the passphrase. Say it, repeat it to confirm, done. No onboarding screen required.
Using it. Locked phone, spoken passphrase, task completed. No unlock in sight.
Edge case: getting it wrong. One retry, then a hard fallback to the passcode: the same trust boundary that exists today, just given one low-stakes chance to avoid it.
The phone never unlocks.
The easy version of this feature quietly unlocks the phone once the passphrase checks out. I didn't build that. The passphrase only ever opens the door to tasks that were never sensitive to begin with, never the phone itself. That's the difference between a workaround and something Apple's own security model could actually accommodate.
not identity
Voice Spoofing, A Known Gap
Overheard, not unlocked.
A spoken passphrase can be overheard and repeated. That’s real, and it’s the reason the passphrase never unlocks the phone or touches anything sensitive. Worst case, someone plays your music or starts a navigation route, the same ceiling a shoulder-surfed passcode already has today, arguably a lower one. A production version would eventually need to move past matching the words and toward matching the voice itself, the same shift Face ID made from “enter the code” to “verify it’s actually you.” That’s real work, and out of scope for a concept piece.
The tradeoff also cuts the other way. Forcing a driver to unlock their phone to make a call isn’t the safe default, it’s its own risk. NHTSA recorded 3,208 deaths in 2024 in crashes involving a distracted driver, and a glance at a screen for as little as five seconds at highway speed covers the length of a football field with your eyes off the road. A feature that trades a small, scoped voice-confirmation gap for less phone-handling at that speed is a reasonable bet, not a reckless one.
REFLECTION
The instinct with a personal annoyance is to solve it the fastest way possible. Asking why the friction existed before deciding how to remove it changed what the solution was allowed to do, and made it something that could ship without contradicting the reason Face ID exists.