Como escalar internacionalmente: design de produto global

A maioria das empresas que lançam produtos internacionais que se adaptam automaticamente a vários mercados nacionais tende a se concentrar principalmente na tradução adequada do idioma. No entanto, uma série de outros componentes essenciais não devem ser esquecidos ao construir produtos globais.

Um ótimo exemplo é o lançamento do sistema operacional móvel iOS6 da Apple em 2012. Uma das principais inovações que os fãs da Apple ficaram tão animados foi o anúncio do novo aplicativo Apple Maps, recém-criado internamente na Apple, incluindo a estreia mundial do 3D Maps. No entanto, poucos dias após o lançamento, o aplicativo Apple Maps foi considerado um fracasso público, com grandes problemas nos resultados de pesquisa e na tradução de local (por exemplo, Berlim se tornou Schoneiche bei Berlin; pesquisar Londres no Reino Unido resultou em Londres, Ontário, Canadá; e a Irlanda de repente tinha um novo aeroporto). O lançamento de produtos em mais de 100 países ao mesmo tempo é um grande empreendimento, e algumas falhas podem ocorrer, mas os executivos da Apple que declararam o aplicativo pronto para ser lançado ignoraram alguns aprendizados principais.

A arquitetura do produto é importante

O principal requisito para o design global do produto é estabelecer as bases da arquitetura do produto que sejam facilmente adaptáveis ​​a diferentes países. É crucial garantir que todos os componentes do texto (os chamados “strings”) sejam estruturados de forma que sejam fáceis de extrair para tradução e reintegração. Criar uma matriz de recursos capaz que mostre quais recursos aparecem quando também é uma etapa essencial. Ele precisa lidar com mais informações contextuais – como localização, região do telefone ou idioma do telefone – do que um produto puramente local faria. Ativar o conjunto de recursos do produto para se adaptar ao local detectado do usuário não deve ser uma reflexão tardia. Como países diferentes tendem a ter níveis diferentes de tráfego celular, as equipes de produto precisam decidir qual parte da lógica da arquitetura deve estar no servidor e qual parte residirá no dispositivo do usuário. Alguns produtos também podem exigir um modo offline, que é um subconjunto dos recursos disponíveis quando o telefone ou dispositivo não está conectado à rede. Ao levar em consideração todos esses componentes, o produto estará pronto para escalar, seja para dois ou 50 países.

Desempenho e arquitetura de servidor são mais duas questões-chave que precisam ser abordadas antecipadamente. Garantir que um produto tenha desempenho adequado 24 horas por dia, 7 dias por semana em países em todo o mundo requer uma arquitetura de servidor com um nível adequado de nós de servidor e capacidade de balanceamento de carga. Com base na quantidade de tráfego, as equipes de produto precisam decidir se precisam de nós de servidor nos EUA, América Latina, Europa ou Ásia, pois é mais ideal ter nós mais próximos de regiões com alto tráfego para garantir uma real- tempo de resposta. Com base em curvas de uso por hora otimizadas, a carga de tráfego pode ser equilibrada em um espectro de 24 horas – por exemplo, os principais servidores da Costa Oeste podem ser descarregados movendo o tráfego para a Costa Leste quando o uso no Leste cair.

Matriz de região x idioma

Para aplicativos móveis, a melhor maneira de detectar o país de um usuário e onde seu telefone foi emitido é confiar na configuração regional escolhida pelo usuário ou padrão pronta para uso. Isso também pode ser combinado com a configuração de idioma para criar uma matriz complexa de regiões e países com suporte, em vez de idiomas. Por exemplo, isso permitiria que um cidadão chinês que mora nos EUA e comprou um telefone americano tivesse o telefone e o aplicativo exibindo o idioma mandarim. Outra decisão que a equipe de produto precisa tomar são as configurações padrão quando um idioma ou país não é suportado. Por exemplo, se o software não suportar o idioma finlandês na Finlândia, o padrão deve ser o inglês. Isso permite que o produto ofereça preferências e personalização.

Complexificando a Matriz de Recursos

Uma matriz de recursos padrão oferecerá suporte a vários cenários padrão. Por exemplo, se o usuário já estiver logado, ele deve poder ir diretamente para a página inicial, não ser confrontado pela página de login. No entanto, construir produtos internacionais significa aumentar a complexidade além dos recursos que estão interagindo entre si. Um bom exemplo é o recurso Facebook Dating, que foi testado pela primeira vez na Colômbia, mas não estava disponível para usuários dos EUA por algum tempo. Nesse caso, se o software detectar o país do usuário como Colômbia, ele deverá mostrar o estado de login do usuário e o recurso Facebook Dating. No entanto, se o usuário estiver nos EUA, o estado de login deve estar visível, mas não o recurso de namoro.

Da mesma forma, no exemplo do Apple Maps, o recurso de pesquisa não deve mostrar o que parece ser o primeiro resultado lógico, mas levar em consideração a localização do usuário. Em ordem alfabética, “Londres, Canadá” vem antes de “Londres, Reino Unido”, mas se o usuário estiver no Reino Unido e digitar “Londres” como palavra-chave, o local no Canadá deverá aparecer como a segunda opção, não a primeira.

Portanto, a matriz de resultados da pesquisa precisa ser ponderada por critérios como a região do usuário, determinada a partir das configurações do telefone, endereço IP do computador ou localização atual do usuário, reconhecida pelo aplicativo. A matriz de recursos também deve suportar a tomada de decisões precisa e automatizada com base no contexto, como o país base do usuário, a localização atual e as preferências de idioma.

Diferenças culturais na interação de recursos

Aspectos culturais também têm impacto na interação de recursos. Por exemplo, um usuário dos EUA digitaria o caractere “&” para se referir a uma interseção ao pesquisar um endereço, enquanto esse caractere não é comumente usado em outros países. Os mexicanos procuram um endereço usando abreviações, por exemplo, “Col. del Parque” para “Colonia del Parque”, pois os endereços mexicanos costumam ser longos. Os ícones também são um tropo cultural único e podem levar a muitos mal-entendidos. Um dos aplicativos em que trabalhei tinha o ícone britânico de uma farmácia, e meus usuários franceses estavam perguntando por que exibimos garrafas de leite por todo o mapa. Embora possamos tomar como garantidos os símbolos “comumente entendidos”, não devemos, pois a comunicação visual é afetada por normas culturais e linguísticas.

Isso também pode ser aplicado ao teste A/B, uma técnica que envolve iterações de determinados componentes do produto para identificar qual deles impulsiona o comportamento do usuário mais bem-sucedido. O teste A/B para cores de botões pode ser influenciado pela percepção cultural. Embora a percepção do verde como “vá” e do vermelho como “pare” seja amplamente internacional, ainda há uma diferença significativa nas percepções culturais dos significados das cores. Por exemplo, em vários países, a cor do luto pode ser preto ou branco, o que gerará reações opostas nos usuários se você usar a cor incorreta.

Localização, não apenas tradução

Os exemplos acima ilustram a diferença entre localização e tradução. A localização leva em consideração uma série de componentes culturais que impactam o design visual e as interações de recursos, indo muito além da simples tradução de textos ou avisos de áudio. Para citar alguns, eles incluem diversidade de moedas, sistemas de medição (métrico versus imperial ou Celsius versus Fahrenheit) e formatação (os formatos de data são diferentes nos EUA e na Europa), bem como uma variação de caracteres textuais e orientação ao design (em árabe lê-se da direita para a esquerda, e isso tem muito impacto na ergonomia de uma página).

Especialistas em localização analisam o texto no contexto de onde o texto está situado no produto, o significado contextual e como certos idiomas tratam determinados contextos; eles também levarão em conta gírias ou conotações inapropriadas e a nuance cultural geral. Um produto localizado é adaptado não apenas linguisticamente, mas também culturalmente.

Configurando a equipe de controle de qualidade para ter sucesso

Quando um produto atinge o estágio de teste, uma equipe de produto deve considerar testes locais e centralizados. Embora vários cenários possam ser testados de forma automática e centralizada a partir da sede, alguns recursos principais se beneficiariam do teste no local. Dirigir nas estradas de um país lhe dará informações valiosas sobre a versão do software de mapas locais; o mesmo se aplica ao teste de um aplicativo do festival com a rede celular local em vez de wifi. Os testes em campo são mais caros devido aos recursos humanos necessários e às despesas de viagem correspondentes. Normalmente, as equipes de produto encontram compensações entre riscos de qualidade e segurança, por um lado, e custos incorridos devido a testes aprofundados, por outro.

Um plano de teste detalhado é essencial para garantir que os testes apropriados sejam realizados. Consiste em uma série de componentes, incluindo:

• Principais cenários de uso em cada país
• Cargas de tráfego de pico
• Especificidades locais, como Wi-Fi versus uso de celular
• Nível de largura de banda da internet
• Tipos de dispositivos usados

Esse plano deve ser preparado e discutido com bastante antecedência para garantir que cubra todos os principais recursos e cenários do produto com base no plano de implantação do país assim que o produto for lançado.

Marketing baseado em localização

Em um mundo globalizado, ter uma marca e posicionamento de produto únicos com algumas customizações locais é o caminho mais eficiente. Isso significa ter uma mensagem de marketing central, que também ajuda todas as equipes de produtos locais a se concentrarem nos benefícios exclusivos do produto. No entanto, é recomendável adaptar as campanhas de marketing local para cada país, a fim de repercutir fortemente com os usuários locais e aumentar o ajuste ao mercado.

Quando as equipes de produto participam do plano de entrada no mercado e do planejamento orçamentário para localização, elas também precisam considerar as iterações de marketing local para todas as mensagens do produto e materiais de marketing. Isso significa que as equipes precisam investir tempo consultando as equipes de marketing locais, concordando com as versões localizadas e tendo todos os ativos de marketing prontos antes da data de lançamento.

Desafiador, mas satisfatório

Como vimos, quando as equipes estão construindo um produto global, os principais itens que você precisa abordar como gerente de produto são o impacto na arquitetura do produto e na matriz de recursos, planos de entrada no mercado adaptados e localização. Esse processo pode ser desafiador e satisfatório – considerando o escopo do mercado e a complexidade do gerenciamento, você ganhará uma experiência incrível como líder de produto.