Every team I’ve worked with thinks of localization the same way. You design the product, you send strings to a translator, and then you ship. Translation is the last step. Almost an afterthought.
That mental model is why localization often fails.
By the time a translator sees your content, hundreds of design decisions have already been made. The button width. The layout direction. The date format. The icon. The tone of the error message. The length of the field label. None of those were flagged as localization decisions, but every single one of them is.
Design assumptions are what break your UI.
I’ve shipped products in 8 languages, including Arabic, Japanese, and German. The failures we had weren’t translation failures. They were design failures that translation exposed. The strings were fine. The product wasn’t ready for what those strings would look like in context.
The difference between teams that handle this well and teams that don’t isn’t the quality of their translators. It’s whether designers are involved in localization from the start, or only brought in when something is broken.
That means asking, in design reviews: does this layout assume left to right reading? Does this icon mean the same thing in every market we’re targeting? Is this field label going to be 3× longer in German? Is this string going to make grammatical sense once it’s translated out of the sentence structure we designed around?
Those decisions shouldn’t be handed to a developer or a PM to figure out. Design owns them.
Localization is a constraint you design within, the same way you design within screen size or loading time. It doesn’t live at the end of your process.
If your team treats it like a translation handoff, you’ll keep fixing the same problems after every launch.
What’s a localization failure you’ve seen that was clearly a design problem in disguise?