This post was inspired by a message I received from a fellow founder a while back about localizing his product.
When kickstarting a product, we understandably wrap ourselves up in research, design and development, hands messy from all things product work not worrying just yet about the slew of miscellaneous tasks needed to be accomplished. We push out betas, receive endless feedback from folks that come from all over the world and implement it as we prep the product for launch. In doing so, we seamlessly place our product in countless countries—from America and Germany to Spain and Japan. Four very different cultures.
In doing so, all too often companies high-five each other on launch day and beyond, following the expected peaks and valleys, only to watch as the product’s engagement drastically dips in the countries not native to the language it was released in. That’s no coincidence.
Having respect for users
The company:user relationship is a I scratch your back you scratch mine— except you should be scratching their back significantly more. Our users give us their time and money—and if we’re lucky, their love and trust. We enter their market and smack our product in their app store making it clear that we want to be present in their country. But as a company, entering a country, looking to profit, without an understanding of the culture and in turn language, is irresponsible. And sends a clear message to users about how you view both.
Which languages to localize for
Realistically though, not every country needs to be localized and you’d be silly to do so depending on the stage you’re at. It’s easy to check the box on the app store that puts you in every one the platform allows, but that doesn’t even mean you have users there. Pick the countries and spend resources wisely localizing where you already have a large community of engaged users or expect to have so you can grow sustainably in that market.
Cut corners only when it benefits the user. When it comes to localization, we had a strategy in place for Liberio and seeing it work really well, I figured it’s worth sharing. For starters, I’m an American and my co-founder is German and we were a German based company. By default and from the start, it gave us the one-up that many companies don’t have—an advantage to get localization happening from the beginning of the product’s existence in both countries with stark differences in people. Have someone on your team that speaks the language of one of your most active groups? Take advantage.
Patience, young padawon. User bases drastically change after the first 6 months after launch. With Liberio, we started off with America, UK, Spain, Germany, and some others dominating (I always take the top 5. 6 for the pitch deck to keep it balanced. #designerproblems). So we immediately thought “OH! We have English and German covered ✅ But we need to localize in Spanish!”. However, we decided to be patient, and thankfully we did. As we continued to grow and hit our target markets, Russia and South Korea became extremely prominent in usage numbers — which we totally didn’t think to localize for in the beginning.
Be patient, hang tight and pay attention to who is engaging with the product after you really get things rolling and zone in on your targets.
“Translate my product?! I only speak dothraki!”
Good question, Mother of Dragons.
There are quite a few routes you can take, but it all depends on the resources you have at hand.
- Google Translate
- Directly hire someone
- Crowdsourcing
I prefer option 3, as it is the most reliable and you have someone or multiple people contributing. Though there are a number of solid products out there for it, we used Get Localization after putting out a blog post calling for users to apply to help translate particular languages. They were beyond excited. I really enjoyed working with the people actually using the product to translate it. Not only do I get to interact with them and learn more about their culture and language, but they get to have a direct impact on the product — aside from feedback, of course.
These long sentences are breaking the UI
Yes, some languages end up being very long after translation. Shorten them. Design your product with localization in mind. I’m an advocate for shortening a string before changing an entire UI. Copy is crucial but can be worded a number of ways to get the same message across. Changing the UI based on language hiccups is a last design resort simply because the UI is in place because of the experience it provides. You can’t always change a design which is calculated and implemented with the intent to solve the problem at hand.
As humans, we can communicate in a variety of ways. But operating without language is arguably one of the most frustrating tasks. At the end of the day, the goal is to provide your engaged and loyal users with the same experience—regardless of their ability to use your product in your team’s first-language.
What are your thoughts on localization? How did you go about it for your product? If you liked this post, please give it a 💙 and share! Let’s chat more about it on Twitter and if you want more posts like this, sign up for my newsletter. I send out one email per week, if that. But definitely one per month. 👋🏼