▸ contents
SayHi started with a simple observation: translation apps were built for information retrieval, not for human connection. You looked up a word, you got a definition, you moved on. But real cross-language interaction—the kind where two people are actually trying to understand each other—required something closer to a conversation partner than a dictionary. That gap was the product.
Building It
The core design challenge was trust. A translation app only works if the people using it trust the output enough to hand their words to a stranger across a language barrier. Every design decision in SayHi ran through that question: does this make the exchange feel real and reliable, or does it introduce doubt?
Working with a small co-founding team, I owned the full design stack—from early concept sketches through brand, interaction design, and final production for iOS. We were designing for an audience that spanned languages, cultures, screen literacy levels, and use cases. A business traveler in Tokyo. A tourist in Rome. A family member staying in touch across an ocean. The interface had to work for all of them without knowing which one was holding the phone.
The things that drove early growth were mostly small: the right amount of voice feedback, clear visual distinction between what you said and what it translated to, conversation history that made a back-and-forth feel like a thread rather than a series of isolated lookups. We iterated based on what we were hearing from users and what we were seeing in the data, and we shipped fast.
Getting to #1
The app hit the top of the App Store’s Business category and the top of iPad charts.
The traction was real and the retention was better than expected—people were coming back to SayHi across multiple conversations, which meant they were using it in sustained relationships and not just one-off situations.
What made it hold was the speed of the translation loop. We optimized relentlessly for how fast you could get from voice input to hearing the translation out loud. That latency determined whether a conversation could flow naturally or whether it broke every few seconds into an awkward pause. Getting that right made everything else work.
Through the Acquisition
Amazon acquired SayHi in 2015. The transition from a small startup to a large platform company is its own design problem. The goals, the timelines, the approval layers, and the definition of done are all different. What had taken days could now take weeks. What had been one conversation now required alignment across multiple teams.
Some of that was friction worth accepting. We had resources we’d never had—real user research at scale, better infrastructure, ML support that changed what was technically possible. But the product instinct that had driven SayHi’s early success was harder to preserve. Startups move by feel; large organizations move by process. The skill was learning how to work with both.
Redesigning SayHi at Amazon Scale
After the acquisition, the immediate project was redesigning the app for cross-platform scale: iOS, Android, and tablet, with feature parity that respected the different interaction models on each.
One of the more interesting product problems during this period was the feedback overlay—a mechanism for letting users flag questionable translations directly within the conversation flow. The challenge was trust again: how do you let users correct the system without making them feel like they’re correcting each other? The final design threaded that carefully, keeping the feedback action low-profile and grounding it in improving future conversations rather than disputing the current one. That interaction mechanism was developed into a patent (US 11,093,110).
SayHi Learn: What Translation Doesn’t Do
The most interesting design exploration of the post-acquisition period was a question the product had always raised but never answered: translation helps people communicate, but does it help them understand?
SayHi Translate was already helping millions of users get words across a language barrier. But translation alone doesn’t build language fluency. Someone could use SayHi daily for years and still not learn a word of the language they were communicating in. We asked whether we could close that gap—whether real conversations could become raw material for genuine learning.
The concept was called SayHi Learn. The idea was a companion experience that surfaced just enough reflection after a conversation to make it useful for learning: highlighted key phrases with pronunciation and native-language examples, optional replay of translated interactions to reinforce memory, phrase cards and spaced repetition to motivate intentional review.
The design constraint that mattered most was consent. Real conversations are private. We weren’t going to use them for training or surface them to the system without the user explicitly opting in. The framing was “your learning journal”—content that belonged to you, with full transparency into what was saved and why.
I prototyped the early flows using Sketch and Flinto, then built more detailed interactions in HTML, CSS, and JavaScript to simulate live data and screen transitions. On Android, we built out key flows in native code to test animation and interaction fidelity.
It didn’t ship. Organizational focus shifted toward Alexa and core NLP infrastructure, and we didn’t have the resources to build and validate a data-safe, scalable version of the learning experience.
Reflection
Building SayHi from the ground up taught me something that’s been durable across every project since: the most important design decisions happen before you open a design tool. They’re decisions about who you’re designing for, what trust means in that context, and what the product is actually trying to do in someone’s life.
Everything else—the interactions, the visual design, the engineering choices—flows from getting those right. When they’re wrong, no amount of polish fixes the underlying problem. When they’re right, even rough execution can find its audience.
The acquisition didn’t change that. It added complexity, more stakeholders, longer timelines, more process. But the underlying question was always the same: what does this person actually need, and does what we’re building actually do that?
SayHi Learn is a useful example of what happens when the answer is clear but the conditions aren’t right. The design was sound. The timing wasn’t. Sometimes that’s the outcome. What matters is that you understood why.