The story in 30s
The problem. Entromy runs enterprise surveys across 62+ languages for private equity and enterprise clients, often launching 4 to 10+ languages simultaneously for companies with 1,000+ employees and assessments reaching 1,500+ participants. Translation happened entirely outside the product: export to Excel, translate in Google Translate, paste back into semicolon-separated cells, one language at a time.
What I did. The first version I designed with the PM was fully flexible: side-by-side question editing, per-question overrides, and a full translation history. Engineering estimated that build, and it wasn't viable for the timeline we had. So I went back to research to find the minimum workflow that would still solve the real problem: sitting in on client calls, analyzing customer support call patterns, mapping the customer journey with our internal team, and running a competitive analysis across Qualtrics, Leapsome, Culture Amp, and SurveyMonkey. Triangulating what clients said, what support tickets showed, and what competitors offered pointed to one workflow: a centralized, user-triggered, in-platform translation system, shipped across three releases sequenced by frequency and complexity. Communications first, survey questions second, self-registration questions last.
What changed. Setup time for multilingual clients dropped by roughly 40 to 50%, the same share Customer Success estimated was previously lost to the manual process. A late change to the English source used to invalidate every existing translation without warning. That risk is gone.
The thinking: the smallest workflow that still works
The original design, side-by-side editing, per-question history, full manual control, was the version I wanted to build. Engineering's estimate made clear it wasn't shippable in the timeline available, so the real design problem became: what's the smallest workflow that still removes the pain clients were describing? To answer that, I triangulated three sources instead of guessing: client calls where I heard the process firsthand, patterns in customer support tickets, and a customer journey mapping session with our internal team to locate where the friction actually sat. I paired that with a competitive analysis of Qualtrics, Leapsome, Culture Amp, and SurveyMonkey to see how comparable platforms handled the same problem. That triangulation is what let me cut scope with confidence instead of by guesswork, dropping per-question editing, translation history, and side-by-side comparison, and keeping one lean action: select languages, trigger auto-translate, override everything in bulk.
- → Destructive beats safe-looking. A non-destructive approach seemed safer, but it let translations look complete while quietly going stale whenever English changed. Overwriting on every run keeps one honest rule.
- → One source of structural truth. Letting structure diverge by language breaks language-independent logic like conditional branching, and turns a one-to-many translation model into an unmanageable many-to-many one.
- → Centralized, not "magic." Per-question, inline AI actions would have increased AI cost and created unclear overwrite logic, so translation triggers from one place instead of scattering across every field.
- → All-or-nothing, on purpose. Rare translation failures are handled close to all-or-nothing with clear messaging, rather than building complex partial-recovery logic clients hadn't asked for yet.
Solution overview
Shipped in three releases, one pattern reused across all of them:
- → Communications first, to prove the pattern. A language selector, a single auto-translate action that translates every field into every enabled language at once, inline manual editing per language, and a warning icon when a language is missing translations.
- → Survey questions: same pattern, more structure. The same pattern extended to handle multi-select answer options, with structural edits locked to English.
- → Self-registration: the pattern, minus the bottleneck. The same pattern again, removing the rigid Excel format and the engineer dependency entirely.
- → A trigger, not a blanket warning. A targeted re-translate alert fires only when the English source actually changes, instead of leaving stale content unflagged.
Results
- → Eliminated an estimated 40 to 50% of survey setup time for multilingual clients
- → Removed developer dependency for self-registration translations entirely
- → Communications that used to take hours of copy-paste now take one click, plus optional manual refinement
- → Adoption was positive among large clients running high-scale, multi-region assessments (specific adoption figures limited by NDA)
Reflection
- 1 The first design isn't always the shippable one, and that's fine. The side-by-side, fully flexible version was the right idea in the abstract, but going back to research after engineering's estimate, rather than trying to defend the original scope, is what got us to a workflow that actually shipped and actually worked.
- 2 Triangulation turns scope cuts into decisions, not guesses. Client calls, support ticket patterns, internal journey mapping, and competitive analysis all pointed in the same direction, which is what made it safe to drop history, per-question editing, and side-by-side comparison instead of just the easiest things to cut.
- 3 Explainable beats clever. AI features in this kind of enterprise workflow succeed by being explainable and predictable, not clever. Users didn't want more automation. They wanted to know exactly what would change, when, and why.