Now, we're going to dive into the topic of teamwork and what you need to consider before you get started with your localization project. We'll also cover some aspects of UX writing and UX research to give you a taste of what to expect in this field.

As a translator, you have a tremendous impact on the quality of the experience that local users get. However, you're not the only one responsible for this outcome. The entire team plays a part, and it's essential to work together towards the same goal. As you'll see, communication is key.

You are the cultural bridge between the product team and local end-users. By flagging any cultural or language issues, you can improve the experience for your users and help the product team deliver better performance. But to enjoy your local expertise, the product team needs to communicate well throughout the project.

It's not uncommon for there to be a disconnect between the product team and the localizer. Sometimes, communication difficulties arise when a translation agency is in the middle. Other times, it's just challenging to find the right way to share information or keep in touch.

Sharing information and communicating well is critical to the success of a localization project. The user persona and needs, as well as the goals of the project, are all vital aspects of your work. You need to talk to the product team to get this information, and since every project is unique, your team won't always know in advance what you'll need. This back-and-forth is just part of the process.

Ideally, your client should create communication channels for you before a project starts. They should invite you to ask your questions and make sure everything is clear. In some cases, you might even have a Google Sheet where you can log your queries, and the product team will answer them as soon as possible.

Unfortunately, this doesn't always happen. The product team may not think it's necessary, or messages may get lost in translation. Sometimes, they assume you'll understand, but that's not always the case, and you're left with missing information.

Misunderstandings can lead to bad copy choices, resulting in an app that feels confusing or isn't as useful as it could be. For example, you might write copy that's not as fluent because you're worried the product team won't agree to the changes. Or perhaps you didn't have a way to ask, so you went with a boring, word-for-word translation.

To avoid these issues, it's crucial to have open communication from the start. Here are some tips to make sure your project goes well and that you write great localized copy:

• Establish communication channels with the product team and make sure they're clear.

• Ask questions, and don't assume anything.

• If something is unclear or missing, speak up. If you're not sure about a particular cultural issue, ask for feedback from a native speaker or other team members.

• Use empathy when writing copy, and put yourself in the user's shoes.

• Be open to feedback and willing to make changes as necessary.

By following these tips, you can work more effectively with your team and deliver high-quality localized content.

The people of UX

As we all know, creating a digital product is a joint effort that involves a lot of people working together. Even simple apps require months or even years of work, with numerous individuals working on various aspects. Before we dive deep into how to communicate and share information with product teams, let's have a quick look at the people who make up the UX teams.


The UX team comprises individuals who work hard to ensure that the products they create are usable and user-friendly. It's essential to remember that usable products can change lives, and creating such products is the primary goal of UX teams.


But where does it all start?

Step 1: The problem

Before you can even start building the app, you need to understand the problem you aim to solve and how to solve it. We talked about this in the previous lesson as well. The problem is what the product is aiming to solve, and all good products start with a problem and work their way to a solution. It's essential to start with a real problem to ensure that your app has a right to exist and that people are willing to use it.

The product manager plays a vital role in identifying the problem and making sure it aligns with the greater business goal. They also plan the project and work with everyone involved to ensure that they all collaborate and work together towards that mutual goal.

But even once the problem is more or less figured out, you still need to figure out how you're going to solve it. This is where UX researchers come in.

They learn as much as they can about the target audience for the product. They talk with these people and ask them questions to learn what they need. Sometimes, they also observe them when they perform certain actions.

The researcher's job is to understand the problem, so they find out everything they can about it. They talk to potential users and ask them lots of questions. For example, if the problem is that we need to drive somewhere but don't know the way, the researcher will ask all kinds of questions, like where you are when this happens, what else you need, what bothers you most at the moment, etc.

Using everything they learn, UX researchers can figure out the best way to help the users, the best solution. Usually, UX researchers have a strong understanding of human behavior and how people interact with technology. They work with this knowledge when they outline the general ways to solve the problem.

At this point, they would usually start collaborating with a UX designer. The UX designer takes those findings and data and suggested general solutions and drills down to create a more detailed solution, more like a list of features.

For example, Navigate to address is one feature, watching navigation history is another feature, save favorite address is another feature, and finally, sharing your location is another feature that the product has.

Once they have that, they can start planning the user journey. They create a map that shows what the user needs to do, which looks a bit like a flowchart. Then, they start creating low-fidelity wireframes of all the screens required.

After the wireframes are created and reviewed by the team, the UX designer hands them off to the UI designer and the UX writer. The UI designer is responsible for the product's visual design, such as colors, typography, imagery, icons, and illustrations. They ensure that the product's design aligns with the brand and is easy to use, which impacts the product's usability and accessibility.

During the design phase, a lot can change from the wireframes, and the designer may need to make adjustments to improve usability or accessibility. For example, they may add or remove buttons, change the layout, or adjust the size and contrast of the text.

While the UI designer works on the visual design, the UX writer also starts working on the product's language. The UX writer is responsible for crafting the product's copy, such as button labels, menu options, and error messages. They ensure that the language is consistent with the brand's tone and voice, and that it is clear and easy to understand.

Ideally, the design and writing process should happen simultaneously, or even with writing before design. This way, the UX writer can cover all their bases, and the UI designer knows how much text they need to design for and where to place it. However, in some cases, the wireframes go to the designer first, and the UX writer is brought in later.

Overall, the design and writing process is crucial for creating a user-friendly and visually appealing product that aligns with the brand's values and voice.

UX writers come into the picture

Now, let's talk about the UX writer. The UX writer is responsible for writing the text that appears in the product. This includes everything from button labels and error messages to product descriptions and user guides.

The UX writer works closely with the UX designer and UI designer to ensure that the text fits seamlessly into the product design. They also work closely with the product manager to ensure that the text supports the overall product goals.

One of the key responsibilities of the UX writer is to make the product easy to understand and use. They use clear and concise language to guide users through the product and ensure that they understand what they need to do at each step.

The UX writer also plays an important role in ensuring that the product is inclusive and accessible. They work to avoid using language that could be confusing or offensive to different groups of users and ensure that the product meets accessibility guidelines.

Once the product design is complete, the development team takes over. The development team is responsible for building the product according to the design specifications. This involves writing code, integrating different features, and testing the product to ensure that it works as intended.

Throughout the development process, the product manager works with the development team to ensure that the product is being built according to the project plan and that it meets the overall product goals.

Once the product is built, it goes through a series of tests to ensure that it works as intended. This includes functional testing to ensure that all features work as intended, as well as user acceptance testing to ensure that the product meets the needs of its target audience.

And after the product has been tested and approved, it is ready for launch. The launch process involves creating marketing materials, training customer support staff, and making the product available to users.

Research continues

After the product is launched, the product team continues to monitor its performance and gather feedback from users. This feedback is used to improve the product and ensure that it continues to meet the needs of its users.

And what about localization?

There are different ways that localization comes into play in product design and development, and the critical role that localizers play in the process.

Research-stage localization

In some cases, localization comes into play early in the research stage, with localizers being brought into the conversation as the research is planned. This approach allows companies to conduct research that considers not just the original market, but also the target markets they plan to expand to.

By involving localizers at this stage, companies can gather insights from users across all target markets, enabling them to create products that cater to the needs of these diverse audiences. This model offers a comprehensive understanding of various markets and can significantly improve the final product's relevance and success.

Another option within research stage localization is to consult localization experts after completing the research in the original market. This model is a more cost-effective approach, as companies don't have to conduct research in the target markets themselves. Instead, they present their research findings to localization experts and ask for their input. These experts then act as cultural consultants, providing valuable insights into the target markets based on the collected data. This information helps companies design products that take into account the needs and preferences of different markets.

Despite its potential benefits, research stage localization is relatively rare. This is mainly due to the costs and time associated with involving localizers early in the development process. Preparing for and executing localization at this stage can be expensive, and having more people involved in the initial stages can slow down the overall process.

Many companies prefer to move quickly through the research stage to focus on design, development, and launching their product within a specified timeframe. Consequently, research stage localization is often overlooked in favor of faster, more cost-effective methods. But despite its challenges, research stage localization holds the potential to significantly enhance a product's success in various markets.

Localization after development

In this model, localizers are brought into the conversation only after the product has been developed and launched in the original language, usually English. Companies first create, deploy, and establish their products in their primary market, gathering user insights and solidifying their presence. Once they're ready to expand into new markets, they'll send their source strings to translators and request localized versions.

In this approach, localizers have no involvement in the design process and only provide translations at the final stages. It's not ideal, as it neglects the impact of localization on various design aspects of the product, such as structure, layout, flow, and functionalities. By bringing localizers into the process so late, companies miss out on valuable insights and opportunities to improve the overall user experience in different markets.

This method has been a prevalent approach in the past because it's cheaper and faster. With fewer people involved throughout the process, it allows for quicker progress and less discussion, which can be more enjoyable for product teams. However, this method's popularity is gradually waning as companies increasingly recognize the significant impact localizers can have on a product's success when involved earlier in the process.

Design Stage Localization

In design-stage localization, localizers are brought into the process after the research stage but before the actual development work begins. This approach enables localizers to have an impact on crucial aspects of the product, such as layout, design, and flow, while still allowing companies to move swiftly through the research stage.

Design stage localization strikes a valuable compromise, which may be why this approach has become increasingly popular. It balances the need for speed in the research stage with the benefits of localization expertise during the design process.

In this method, localization experts may be consulted at various points during the design stage. They can be involved when:

Wireframes are being created, helping to determine which copy goes where in the layout.

UI design decisions are made, contributing to choices about colors, visuals, and other design elements.

The writing stage occurs, collaborating with UX writers to create fluent versions of the copy in the target language.

This involvement provides localizers with the ability to suggest changes, such as adjusting the space allotted for text or repositioning copy to accommodate different languages. With localizers' input during the design stage, there is plenty of room for adjustments and changes to accommodate the needs of various target markets. This adaptability makes design stage localization an attractive compromise for many companies.

Localization Without Source

In localization without source, there is no single source copy created by UX writers, that localizers then translate. Instead, multiple versions of UX copy are produced simultaneously in different languages. The person in charge of the project, such as the UI designer, UX designer, or product manager, provides guidelines and requirements for the messages and their placement in the product. Writers in all languages then develop their own solutions to these requirements.

Localization without source offers a number of advantages. It provides flexibility, freedom, and empowerment to writers in different languages, as they are not constrained by a source copy. This approach can lead to more natural and fluent translations, as each writer crafts copy that feels native and original to their language.


While localization without source can lead to more fluent and natural translations, it also presents challenges in terms of quality control and time management:

Lengthy discussions: With each localizer pulling in their own direction, the process can become time-consuming and complicated.

No single source of truth: Without a source copy to serve as a reference, maintaining consistency and quality across all translations becomes more challenging.

Quality control: Ensuring that each linguist's copy aligns with the brand, accurately conveys the intended meaning, and remains culturally appropriate can be difficult without a source copy to use as a guide.

It's essential for companies to weigh the advantages and drawbacks of this approach to determine if it's the right fit for their localization needs. By understanding the pros and cons of this approach, companies can make informed decisions about the best localization strategy for their products.

Choosing the best localization approach

So, which localization approach is the best one? There's no one-size-fits-all answer to this question. It depends on the specific product, the target audience, and the company's goals and resources.

However, working with localizers from the beginning of the design process is generally considered the most effective approach. This allows for the greatest impact on the design, and ensures that the final product is tailored to meet the needs of local users.

The role of localizers in UX

When you localize content for a software or an app, you're part of the UX and product team. You play a critical role in ensuring that the final product is clear, intuitive, and usable for local users.

The relationship between product teams and localizers is a new one. Many product teams are only starting to learn about localization, while others have been localizing for some time but are not used to collaborating with localization experts directly.

As a localizer, it's your responsibility to make sure that you have all the information you need to create high-quality localized copy. If the product team doesn't provide this information on their own, you'll need to ask for it.

Foundations for collaboration

When it comes to creating successful localized products, the collaboration between product and localization teams is essential. However, these teams may not have a history of working closely together. To foster a healthy and productive working relationship, both sides need to develop effective communication and collaboration strategies.

To establish a good relationship with product teams, localizers need to first create the conditions that can support a healthy working relationship. Without these foundations, it's unlikely that any meaningful collaboration will take place. The success of future joint projects depends on the creation of these conditions.

There are several key factors that contribute to a successful working relationship, applicable not only to localization but to any industry. These elements are crucial when it comes to collaborating with product teams and creating top-notch localized products:

1. Trust

Trust is one of the building blocks of any successful working relationship, especially between localization and product teams. However, gaining that trust can be quite a challenge, considering the language barriers and differing areas of expertise. One of the primary hurdles in building trust with product teams is proving the quality of your work. For localization professionals, the majority of the copy is in a language that the product team doesn't understand. This inherent language barrier makes it difficult to demonstrate your skills and gain the trust of the product team.

Don't worry, though! With patience and a creative approach, it's definitely achievable. Despite the challenges, there are several ways to show your expertise and knowledge that go beyond simply displaying well-written copy.

For example, the way you communicate with the product team can go a long way in showcasing your understanding of their work. Be mindful of how you phrase emails, ask questions, and discuss user experience, UX copy, and strategy. Demonstrating a grasp of their domain through effective communication helps to establish trust.

Trust takes time to develop, so don't expect the product team to immediately embrace your suggestions or opinions. Be patient and continue to put in the effort to demonstrate your expertise. Over time, as you prove your value, the team will become more receptive to your input. And once you've gained the trust of the product team, they will be more inclined to consider your expertise, making future collaboration smoother and more efficient.

2. Time

To effectively build trust, localization teams need to work with the same product team consistently and over time. This doesn't mean you need to be the only localizer or that they need to be the only team you're working with, but still — maintaining an ongoing relationship is crucial. If the product team frequently switches providers, it's difficult to build a lasting relationship, which can impact the quality of the localized copy.

If you're a localization manager in an LSP or a freelance translator, you can still build trust and a strong working relationship, as long as there's consistent collaboration. That being said, you might not always have control over whether a product team works with you consistently. Don't let this discourage you if you're unable to build trust when working with a team sporadically. Instead, focus on the partnerships where you can create that lasting relationship.

And if you're in a position to provide feedback to the product team, such as being a localization manager at a product company, recommend working with the same linguists consistently. A permanent relationship significantly impacts the final results and contributes to more successful localized products.

3. Respect

Building a good working relationship and effective communication between localization and product teams hinges on mutual respect. As localization professionals, we must respect the product team's time by meeting deadlines and being reliable.

Additionally, it's crucial to respect their knowledge and the effort they've put into the product. Instead of focusing on criticism, provide constructive feedback that highlights areas of improvement. Ensure your feedback is helpful and within your domain of expertise. Be specific and focus on actionable suggestions rather than pointing out problems without offering solutions. This approach will make your input more valuable and beneficial to the product team.

On their end, the product team should also respect the localization team's work. Strive to be reliable, knowledgeable, and provide valuable insights to demonstrate your expertise. Confidence is key in earning their respect, so be assertive when sharing your suggestions.

Confidence may come naturally for some, while others need to develop it through positive feedback and experience. If you're not feeling confident, it's okay to "fake it till you make it." Over time, you'll become more comfortable in your role, and your confidence will grow, leading to stronger relationships with the product team.

Communicating with product teams

Good communication is essential for effective localization. If the localization team and the product team or clients are not on the same page, the localization process can be slow and expensive. Therefore, it's important to know the best ways to communicate with clients or product teams before you start the localization process.

Option 1: Spreadsheets

The first and oldest way to communicate with clients or product teams is to use a spreadsheet. This is a common practice in the localization industry, regardless of UX. Usually, a Google Sheet or an online Excel sheet is used. The spreadsheet is used to transfer questions and answers between the translators and the clients. The sheet consists of columns for language, source text, suggested translation, query, and then a column for the product team to put their answers in.

Spreadsheets like Google Sheet files are great because they're free, and since everyone knows how to use them, there's usually no learning curve. They're super easy to share, and the files are saved into the cloud, so you can refer back to them easily if you have a similar project in the future. In my opinion, this makes them a great way to share feedback and ask short, simple questions. But they do have some disadvantages.

First, they're disconnected from the actual copy you're localizing. Therefore, you have to go back to the text, then back to the file to reply, and that could get very frustrating. And when people are frustrated, they don't have the patience to sit down and reply calmly to all your questions. So that's not ideal. Plus, they can get messy fast - with so many lines and languages. They're great for replying to a question once, but they're not really good for longer conversations and discussions.

Option 2: Using the product team's tools

Some teams prefer that you use their own tools, and that's also okay - go with what's easier for them. And you can add screenshots or any additional information you need, to make sure everyone is on the same page when you discuss things. That's a very important capability.

But these tools are still not ideal. They're still disconnected from the copy you're localizing. And you can't save the issues you log for future reference. The team will have access to them, but since it's linked to their systems, you won't necessarily have access to those bugs in the future. And if another localizer does a project for the same language, they won't have access to bugs that you raised.

Option 3: Using design tools

Other times, the team will ask you to use their own design tool. So instead of a bug-logging tool, they'll ask you to use a design tool, like Figma or XD.

A lot of the same advantages you get for bug logging tools, are also available with design tools. The team is already there, you get faster replies. And you can usually have longer conversations there, with everything easily displayed in a thread. But you get the added benefit of having a lot of the visual context right alongside your discussion. You don't need to copy screenshots into the software, and you'll have access to more than just the one screen you're working on. You can go back and look at the entire user journey. And not only that - questions are also linked to the context. So if the team redesigns a specific screen they'll still have access to the comments you made on it.

That being said, these design tools are not meant for copy management. While they're great for asking questions about design elements, they may not have the necessary features to help you manage your localization questions. Additionally, design tools can have a learning curve, which may be challenging if you're not familiar with them. Finally, design tools require access, and not all teams have the necessary permissions to grant access to everyone.

Option 4: Using the CAT/localization tool

A final option is using a translation management system to ask questions about localized copy. Some would say this is best option because it keeps the entire discussion right there beside the copy.

Using a translation management system to ask localization questions has many advantages. First, if the localization tool has context capabilities, you should have all the context you need, which means you can really have a focused conversation about the best choices. Second, you can see how the localized copy looks in layout, which is an amazing feature to have. Third, you can see discussions made about the same string in other languages, which can be very valuable. Finally, all discussions are linked directly to the strings, so you can always look back on old discussions and learn from them.

You should know, though, that not all of these features are always available. Some localization tools are more advanced than others. But some will not have visual context or a way to look back on comments.

The major downside of using a localization tool for communication is that this is obviously less convenient for the product team. They have to add a new tool to their workflow, and monitor it to make sure you get your answers. Not all teams are willing to do that, or maybe they are, but it'll take you longer to get answers.

Communication is the end - these are just the means

Asking questions is crucial to localization, but many linguists are afraid to ask questions because they feel like they're bothering the product team with "stupid questions." However, asking questions is essential to ensure that you understand the project's goals and requirements, and it shows the product team that you're taking the project seriously.

The communication tool you're choosing doesn't matter as much as asking the questions. Don't be shy about asking questions or flagging issues, but be respectful and constructive in your feedback. Active communication channels help you stay up-to-date on the project's progress, ensure that everyone is on the same page, and help you deliver better results.

So just make sure you're using the tool your team prefers, whether it's Google Sheets, their project management tool, a design tool, a bug logging tool, or the translation software. Then, work to make your questions valuable:

• Ask questions the right way. Start by explaining anything that the product team might not understand, and provide examples if needed. If you're offering alternative translations, include a back translation to help the product team understand your suggestions.

• Be clear and concise when phrasing your question. Avoid using jargon or technical language that the team may not understand.

• Always use a language that everyone in the project can understand, usually English. Avoid leaving comments or having discussions in a language that other people involved in the project may not be able to read. Even though it may be more convenient to discuss things in your native language, it can make it harder for other people to follow the discussion and learn from your questions. Using a common language will help everyone on the team learn from your questions and save the product team from having to answer them again.

Remember, asking questions is about getting answers, not about showing off your knowledge or trying to impress the team. Be flexible and recommend the best option in your opinion, but let the team make the final decision.

The same thing applies when you need to flag issues. If you see something that you feel won't work well in your local market, use the same communication channels to let the product team know.

However, in that case, make sure you also explain why you think it won't work well, and provide clear examples. The product team may not take your feedback seriously unless it makes sense to them, and they understand why you're concerned.

When flagging issues, it's essential to be respectful and constructive in your feedback. Avoid being overly critical or negative, and offer suggestions on how to improve the content. Remember that your product team has much more than content to consider. There are also budgets, deadlines, and company policies, and C-suite preferences, to name just a few. So defer to their expertise on what's possible and what isn't. And even if you disagree with the direction they're going in, try and be supportive. It'll make your working relationship much smoother, which is important for future collaboration.