Designing a voice interface people actually talk to
A three-word address is easy to say and surprisingly hard for a machine to hear. Building and localising the what3words Alexa skill meant designing a content model for a product with no screen, no undo, and no room to explain itself.
The situation
what3words divided the world into three-metre squares and gave each one a unique combination of three words. The whole pitch is that it's sayable — you can read your address down a phone line to a delivery driver, or shout it to a mountain rescue team, in a way you simply cannot do with latitude and longitude.
Which raises an obvious question: if the format is designed to be spoken, why were people still typing it? I led product and UX for voice products and third-party integrations, which meant building the experiences that let someone navigate somewhere, or order a ride, by saying three words out loud to a speaker — on Alexa and Google Home.
Why voice is the hardest place to put this product
On a screen, a three-word address is trivially easy to verify. You see it. You read it back. If the autocomplete gets it wrong, you notice instantly, because the wrong word is sitting right there in front of you.
Voice removes every one of those safety nets. There's no screen to glance at, no cursor to correct, no way to scan back over what you just said. And the failure mode is unusually punishing: a three-word address that's almost right isn't nearly right, it's somewhere else entirely. Get one word wrong and you haven't got a slightly imprecise location — you've got a completely different three-metre square, possibly on another continent.
That reframed the whole problem for me. This wasn't a UX writing job about making a skill sound friendly. It was a content architecture problem: how do you design a spoken exchange where the cost of a misheard word is catastrophic, and the only tool you have to catch it is more words?
Designing the content model
Every voice interaction in the skill came down to a small number of repeated decisions, and my job was to make those decisions once, properly, rather than let them get made ad hoc per flow:
- How the skill asks. The prompt has to teach the format while asking for it — someone who's never used the product needs to understand what shape of answer is expected, without a tutorial.
- How the skill confirms. Reading the address back is the only verification mechanism that exists. That confirmation step carries almost all of the reliability of the product.
- How the skill recovers. What it says when it didn't catch a word, caught a word that doesn't exist, or caught three words that resolve to somewhere implausible.
- How the skill hands off. Navigation and ride-ordering both end by passing the location somewhere else, and the content has to make it obvious what's about to happen before it happens.
Designing, testing and optimising that model — rather than writing individual lines — is what made it possible to extend the same experience to a second platform and into other languages without rebuilding the logic each time.
A worked example: ordering a taxi
Here's how the content model plays out in a full flow — booking a ride from one three-word address to another. Every line is doing a specific job, and the annotations explain which.
And when it goes wrong
Recovery is most of the design, so it gets the same treatment: never make the user repeat everything, and never make them guess what went wrong.
Five languages, and why that isn't translation
Launching in five languages made every one of the problems above harder, because the underlying word lists differ per language. A three-word address isn't translated between languages — each language has its own set of words for the same square. So the localised skill isn't a translated version of the English one. It's a different set of speech inputs entirely, with different homophone clashes, different word lengths, different rhythms when read aloud.
This is the same argument I ended up making across everything I did at what3words, and later at Klarna: you cannot hand a translator the English strings and expect the experience to survive the journey. Voice just makes the consequence louder. A confirmation prompt that reads back smoothly in English can be almost unusable in another language if you translate its structure rather than rebuild it.
Built with local experts, not for them
The same principle I'd proved on the store listings applied here, harder. We worked with local language experts in each market to shape the voice interface rather than translating the English flow — because in voice, the things that break are things only a native speaker notices.
What the skill asks, and how, has to change per language. Confirmation phrasing that scans smoothly in English can be clumsy or oddly formal elsewhere. The natural pause between three spoken words differs. Which words clash as homophones is entirely language-specific, and it's the single biggest determinant of whether recognition works. None of that is discoverable by translating strings.
What I took from it
Voice was the clearest lesson I've had in the thing I keep arguing about publicly: that content design is systems work, not sentence work. There is no visual design to hide behind in a voice interface. There's no illustration to carry the tone, no layout to establish hierarchy, no button label doing quiet work in the corner. The content is the interface. Every decision about what gets said, in what order, and what happens when it goes wrong, is the product.
It also gave me the sharpest possible version of an argument I'd make repeatedly afterwards — that the moments worth designing hardest are the failure states. In a voice product, the error handling isn't an edge case you clean up before launch. It's most of the design.