Início Sobre Contacto
Lisbon, Portugal English →
Case study · Plataforma B2B

Aptoide Connect

O sistema funcionava. Os developers é que não o viam funcionar. Eu resolvi a segunda parte.

PapelLead Product Designer (ponta a ponta)
ÂmbitoResearch · Estratégia de UX · Fluxos · UI · Protótipos
Equipa1 Designer · 4 Engenheiros · 1 Analista de Dados
Ao vivo — connect.aptoide.com ↗
Aptoide Connect — dashboard redesenhado

O dashboard redesenhado responde a uma pergunta antes de tudo: o que está a acontecer agora. Apps ao vivo, pendentes e bloqueadas — visíveis num relance.

250M+
Utilizadores nos ecossistemas parceiros
20+
Lojas integradas num sistema único
$60M+
Em volume anual de transações
Contexto do produto

Um APK. Vinte lojas. Zero visibilidade.

A Aptoide gere uma rede de lojas white-label para OEMs e operadores regionais. O Connect é a camada dos developers: uma submissão de APK chega a 20+ lojas parceiras, cada uma com o seu pipeline de aprovação, requisitos de metadados e filtros por país.

A economia é boa: até 90% de partilha de receita contra os 70% da Google Play. Quase ninguém a recebia, porque a interface nunca a mostrava. As apps pareciam presas quando não estavam. Os números de receita estavam certos e ninguém acreditava neles. A maioria dos developers desistia antes da primeira app ir ao ar.

O meu trabalho: fazer a plataforma explicar-se, para os developers agirem sem abrir um ticket de suporte.
O que encontrámos

"Submeti há três semanas. Ainda não sei se está ao vivo."

Abordagem

Um princípio: o sistema deve explicar-se a si próprio.

Cada decisão passou pelo mesmo teste: isto torna o sistema mais fácil ou mais difícil de ler? Se um ecrã precisava de legenda para se perceber, chumbava.

01 · Onboarding

Lançar primeiro, configurar depois.

O fluxo antigo exigia configuração completa antes de se poder submeter fosse o que fosse. Cortámos para um só objetivo: pôr a primeira app ao vivo. Tudo o resto passou para depois, onde pertence. A primeira submissão demora agora menos de 15 minutos.

Ecrã de login
Ecrã de registo
02 · Submissão

Onde a complexidade atinge o pico.

A versão antiga punha tudo numa página. Os developers ou avançavam por instinto ou paravam.

Trade-off: quem chega de novo vê menos opções à partida. Os utilizadores avançados continuam a chegar a tudo — mas o primeiro passo já não faz perguntas que ainda não se sabem responder.
Fluxo de submissão de apps

O estado pós-submissão elimina a incerteza do "será que funcionou?" que gerava a maioria dos tickets.

03 · Distribuição, analytics e monetização

De códigos de estado a decisões.

A mesma ideia, aplicada aos três ecrãs onde os developers vivem depois do lançamento.

Distribuição

Uma tabela de 40 linhas de códigos passou a três estados — ao vivo, pendente, bloqueada — mais uma vista de "falhas" que lista cada canal em falta com uma razão acionável. A maior parte dos ganhos de cobertura veio de tornar visíveis problemas que já existiam.

Analytics

Tabelas cruas substituídas por métricas ligadas a decisões, movimento direcional e insights automáticos ("Downloads na Alemanha subiram 34%"). O uso passou de 20% para 60% dos utilizadores ativos no primeiro trimestre.

Monetização

90% de partilha de receita, mostrada onde importa — intervalos de ganhos nos momentos de distribuição, apresentados como estimativas, nunca garantias. Adesão subiu 28%, a mais alta desde o lançamento.

Analytics — downloads e vendas de uma app

Analytics reconstruído à volta de decisões — downloads, vendas e movimento por país de uma app, numa só vista.

15× RPD
Evony

Receita por download vs. Google Play, sustentada durante 9 meses.

10× RPD
Infinite Magicraid

Receita por download através da rede de lojas parceiras.

+24%
Lords Mobile

Crescimento de receita só pela expansão da distribuição.

Insight central

O problema não era a distribuição. Era os developers não verem o sistema a funcionar.

Impacto do design

Seis meses após o lançamento.

+40%
Submissões de apps
3×
Cobertura de distribuição por app
20→60%
Uso do analytics
−55%
Tickets de suporte (primeiros 90 dias)
+28%
Adesão à monetização
<15 min
Até à primeira submissão
Aprendizagens

O que este projeto me ensinou.

Defaults inteligentes precisam de explicação.

Os developers ou aceitavam as pré-seleções às cegas ou mudavam tudo. A lógica por trás de um default faz parte do design.

Nomear o problema foi metade do trabalho.

Assim que lhe chamámos um problema de legibilidade, todas as decisões ficaram mais fáceis de julgar.

Em B2B, a confiança vem antes da compreensão.

Se os developers não acreditam nos dados, não agem sobre eles. A credibilidade tem de ser desenhada.

Balanço final: a plataforma já era capaz. O melhor trabalho aqui não acrescentou nada de novo. Tornou óbvio o que já existia.

Projeto seguinte
AppCoins Wallet →