Overview
MatchCraft, a search engine marketing platform, needed to continue expanding into international markets. Localization of our platform was inconsistent which made it difficult for users in international markets to use our SaaS platform. I redesigned a light weight tool that enabled our team to localize 100% of all terms in supported languages, enhancing the quality of our product in global markets.
My role
User research, prototyping, interaction design, oversee development
Team
Me (Lead designer)
Avinash (Engineer)
Ash (Software engineer)
PROBLEM
Users in global markets complained about the quality and completeness of localizations. Why were we doing such a bad job at localizations? How could we improve our ability to localize our SaaS platform?
CONSTRAINTS
-
Limited time and engineering resources
-
Tasked with delivering a lightweight tool
-
Challenging problem because localizing require 3 different roles to execute their parts.
Goals
Research methods
To understand why our team was struggling with localizations, I shadowed users, played the role of localizations manager, and interviewed stakeholders. I identified the following issues:
1. Our database of keys and localizations was littered with garbage.
There were duplicate keys and variations of similar keys. Engineers were concatenating strings. There were inconsistencies about which keys had localizations.
2. Localization experts were localizing terms without context.
Our localization experts often only had a list of terms to localize without being able to see what was in the platform.
3. Users were copying and pasting data from a spreadsheet one cell at a time, which was error prone and inefficient.
4. Insufficient quality control and coordination during localization
Localization involves coordination among many people: product managers, engineers, and localization experts. However, all of these people were working in a vacuum, with minimal coordination.
What is a localization?
A key has to match exactly with the text string visible in the UI.
The engineer has to wrap the text string in i18n attribute.
The key has to exist in the database and have a localization corresponding to the appropriate language.
User journey map (convert to map)
-
Product manager sends in wireframes/mockups to engineers.
-
Engineers manually types in strings in code (errors in mispelling, forgetting to implement i18n attribute)
-
Product manager compiles their own list of keys in the spreadsheet and sends to localization team. (terms don't match
-
Localization experts translate based on the list they have. (lacking context, reduced quality of localizations)
IMPACT ON BUSINESS
Customer sees a missing localization or poorly localized term in the UI. They send in a customer support ticket.
-
It can take hours to figure out why a key was not translated and coordinate the resolution (involves product manager, engineer, and localization consultant).
-
Users feel like second-class customers and may switch platforms.
SOLUTIONS
1. Updated process
-
After engineers have tagged i18n attributes for terms, they export the list.
-
Product manager uses this list to add contextual notes. Then adds it into the platform.
-
Localization experts download the list from the platform.
-
Then bulk upload into the platform.
2. Developed standards for keys and led database cleanup.
3. Introduced fall back languages.
4. Highlights of features.
Notes field
Bulk upload
Filters
Columns: Key requester
Outcomes
-
Support tickets related to missing localizations dropped to less than one per major release cycle.
-
Gave our sales team in international markets confidence when giving demos because platforms had complete localizations
Key lessons learned
-
important to engage all users in the process building internal tools
-
teasing out which are the core features to build to deliver immediate value under constrained resources (and not building every request or even things that might seem 'useful')
-
quality of data (keys and translations) not just interaction design was critical to the end user's experience
Overview
MatchCraft, a search engine marketing platform, needed to continue expanding into international markets. Localization of our platform was inconsistent which made it difficult for users in international markets to use our SaaS platform. I redesigned a light weight tool that enabled our team to localize 100% of all terms in supported languages, enhancing the quality of our product in global markets.
My role
User research, prototyping, interaction design, oversee development
Team
Me (Lead designer)
Avinash (Engineer)
Ash (Software engineer)
PROBLEM
Users in global markets complained about the quality and completeness of localizations. Why were we doing such a bad job at localizations? How could we improve our ability to localize our SaaS platform?
CONSTRAINTS
-
Limited time and engineering resources
-
Tasked with delivering a lightweight tool
-
Challenging problem because localizing require 3 different roles to execute their parts.
Goals
Research methods
To understand why our team was struggling with localizations, I shadowed users, played the role of localizations manager, and interviewed stakeholders. I identified the following issues:
1. Our database of keys and localizations was littered with garbage.
There were duplicate keys and variations of similar keys. Engineers were concatenating strings. There were inconsistencies about which keys had localizations.
2. Localization experts were localizing terms without context.
Our localization experts often only had a list of terms to localize without being able to see what was in the platform.
3. Users were copying and pasting data from a spreadsheet one cell at a time, which was error prone and inefficient.
4. Insufficient quality control and coordination during localization
Localization involves coordination among many people: product managers, engineers, and localization experts. However, all of these people were working in a vacuum, with minimal coordination.
What is a localization?
A key has to match exactly with the text string visible in the UI.
The engineer has to wrap the text string in i18n attribute.
The key has to exist in the database and have a localization corresponding to the appropriate language.
User journey map (convert to map)
-
Product manager sends in wireframes/mockups to engineers.
-
Engineers manually types in strings in code (errors in mispelling, forgetting to implement i18n attribute)
-
Product manager compiles their own list of keys in the spreadsheet and sends to localization team. (terms don't match
-
Localization experts translate based on the list they have. (lacking context, reduced quality of localizations)
IMPACT ON BUSINESS
Customer sees a missing localization or poorly localized term in the UI. They send in a customer support ticket.
-
It can take hours to figure out why a key was not translated and coordinate the resolution (involves product manager, engineer, and localization consultant).
-
Users feel like second-class customers and may switch platforms.
SOLUTIONS
1. Updated process
-
After engineers have tagged i18n attributes for terms, they export the list.
-
Product manager uses this list to add contextual notes. Then adds it into the platform.
-
Localization experts download the list from the platform.
-
Then bulk upload into the platform.
2. Developed standards for keys and led database cleanup.
3. Introduced fall back languages.
4. Highlights of features.
Notes field
Bulk upload
Filters
Columns: Key requester
Outcomes
-
Support tickets related to missing localizations dropped to less than one per major release cycle.
-
Gave our sales team in international markets confidence when giving demos because platforms had complete localizations
Key lessons learned
-
important to engage all users in the process building internal tools
-
teasing out which are the core features to build to deliver immediate value under constrained resources (and not building every request or even things that might seem 'useful')
-
quality of data (keys and translations) not just interaction design was critical to the end user's experience