Como escrever uma descrição de aplicação clara e credível

A descrição costuma aparecer quando já ninguém quer escrever

A versão está pronta, as capturas quase exportadas e falta preencher um campo com milhares de caracteres. A solução mais rápida é copiar o texto do site, juntar uma lista de funcionalidades e acrescentar expressões de pesquisa. O espaço fica ocupado, mas a pessoa que abriu a ficha continua sem perceber se vale a pena instalar.

Quem chega à loja precisa de respostas simples: esta aplicação foi feita para uma situação como a minha? O que vou conseguir fazer? Há motivos concretos para acreditar na promessa? A descrição deve tornar essa decisão mais fácil e representar a versão que existe hoje, não a visão prevista para os próximos meses.

Este guia trata das palavras. Para construir a parte visual, consulte as nossas boas práticas para capturas de loja. A lista ASO para o lançamento liga o texto aos metadados, avaliações, medição e publicação.

Não há uma única descrição para todas as posições

Na Apple existem subtítulo, texto promocional e descrição completa. O texto promocional, até 170 caracteres, pode ser alterado sem enviar uma nova versão; a descrição completa, até 4 000 caracteres, é atualizada com uma versão. No Google Play há uma descrição curta, até 80 caracteres, e uma descrição completa, também até 4 000.

Os campos não devem repetir a mesma frase. O texto curto situa rapidamente a utilização e o benefício. As primeiras linhas da descrição confirmam a relevância. O restante conteúdo explica como funciona, mostra exemplos e esclarece condições.

Definir estas funções antes de escrever evita que todas as ideias disputem a primeira frase.

Comece por uma folha de factos do produto

Uma página em branco não é o melhor ponto de partida. Reúna primeiro o público, a ação central, o resultado esperado, os mercados e idiomas disponíveis, as integrações e as limitações que podem afetar a experiência.

Registe também o que a aplicação não faz. Pode não funcionar sem ligação, não estar disponível em todas as regiões ou depender de um serviço externo. Esta lista é tão importante como a lista de funcionalidades: impede que o entusiasmo da equipa transforme um plano futuro numa promessa atual.

Cada afirmação importante deve ter uma prova observável. Pode ser um ecrã, uma etapa do percurso, um estado final ou uma integração ativa. «Marque a consulta, receba um lembrete e altere o horário na aplicação» é verificável. «A melhor experiência para cuidar de si» não explica o produto nem oferece qualquer prova.

A promessa deve ligar pessoa, momento, resultado e prova

Uma abertura útil costuma reunir quatro peças: quem usa, em que situação, que resultado procura e que mecanismo o produto oferece. As quatro não têm de aparecer como uma fórmula rígida, mas o sentido deve estar completo.

Pense numa aplicação de entregas locais. «Tudo de que precisa, mais perto» pode soar agradável, mas deixa quase tudo por explicar. «Escolha lojas da sua zona, acompanhe a entrega e receba atualizações até a encomenda chegar» cria uma imagem concreta da utilização.

Ser específico não significa perder personalidade. É possível escrever com ritmo e proximidade. O problema começa quando adjetivos como «revolucionário», «inteligente» ou «completo» ocupam o lugar da explicação.

Uma descrição completa precisa de sequência

Um texto sólido conduz o leitor. Primeiro reconhece a situação e apresenta o resultado principal. Depois explica o mecanismo. Dois ou três exemplos mostram ações reais. Mais adiante, o texto identifica para quem a aplicação é adequada e esclarece requisitos ou limites. O final convida a experimentar sem criar uma urgência artificial.

As listas ajudam a comparar funcionalidades relacionadas, mas não devem substituir toda a narrativa. Ler apenas «perfis, mensagens, alertas, relatórios» não explica como essas peças trabalham juntas nem porque são relevantes.

*A promessa torna-se credível quando o percurso entre necessidade, ação e prova é fácil de seguir.*

As primeiras linhas têm de funcionar sem o resto

Dependendo do dispositivo e da origem da visita, a pessoa pode ver apenas um pequeno excerto. A abertura não deve precisar do parágrafo seguinte para ser compreendida. Começar com «Bem-vindo», repetir o nome completo da aplicação ou contar a história da empresa adia a informação mais importante.

Mostre só as primeiras duas linhas a alguém que não conhece o projeto. Se essa pessoa conseguir dizer o que a aplicação permite fazer e a quem se destina, o início está a cumprir o seu papel. Se disser apenas «parece uma plataforma digital», ainda falta precisão.

Parágrafos curtos facilitam a leitura num ecrã pequeno, mas não precisam de ter todos o mesmo tamanho. Uma frase direta pode ser seguida por uma explicação mais desenvolvida. Os subtítulos devem marcar mudanças reais de assunto, não interromper o texto a cada duas frases.

As pesquisas revelam linguagem, não uma quota de palavras-chave

O trabalho ASO ajuda a descobrir como as pessoas descrevem a sua necessidade. Em Portugal, por exemplo, «marcar uma consulta» pode ser mais natural do que uma expressão importada de outro mercado. A pesquisa serve para escolher palavras compreensíveis, não para repetir a mesma sequência em todos os parágrafos.

O Google Play desaconselha listas repetitivas ou irrelevantes de palavras-chave, e a Apple também pede que se evitem termos desnecessários. Mesmo sem considerar as regras, um texto forçado diminui a confiança no momento da instalação.

Use a expressão principal quando ela identifica o produto com exatidão. Depois explique ações e resultados com variação natural. Ler o texto em voz alta continua a ser um bom teste: se uma frase não seria usada numa conversa com um cliente, provavelmente também não pertence à ficha.

Apple e Google Play podem partilhar factos sem partilhar cada frase

O público, a proposta central e as funções verificadas devem manter-se consistentes. A redação pode mudar de acordo com o campo. O subtítulo e o texto promocional da Apple aparecem num contexto diferente da descrição curta do Google Play e obedecem a regras próprias.

Vale a pena manter uma base comum de factos aprovados e preparar versões específicas. Uma novidade atual pode surgir no texto promocional da Apple, que é fácil de atualizar. A descrição completa deve explicar o valor mais estável. No Google Play, a descrição curta tem de continuar clara junto dos restantes elementos da ficha.

Consulte as orientações atuais antes de publicar. Os limites de caracteres são apenas uma parte do trabalho; alegações de posição, promoções enganosas ou testemunhos sem origem também podem causar problemas.

Uma frase forte não pode ultrapassar a verdade

«Número um», «resultado garantido», «totalmente seguro» e «gratuito por tempo limitado» exigem provas e condições. Sem elas, são mais do que exageros de estilo: podem induzir em erro e contrariar as políticas das lojas.

Em saúde, educação, finanças ou tratamento de dados pessoais, escolha afirmações especialmente concretas. Em vez de prometer segurança absoluta, explique uma medida realmente implementada e encaminhe para a informação de privacidade. O texto não deve sugerir que uma funcionalidade tem valor clínico, legal ou financeiro que o produto não pode demonstrar.

A verificação deve usar a versão candidata à publicação. Uma funcionalidade planeada para a próxima atualização ainda não pode ser descrita no presente.

Localizar é escrever de novo com a mesma verdade

Uma tradução pode estar correta e continuar a parecer estrangeira. O português europeu tem vocabulário, tratamento e ritmo próprios. «Aplicação», «ecrã», «equipa» e «utilizador» não são pormenores cosméticos: fazem parte da naturalidade e da confiança.

O redator local deve receber os factos do produto e reconstruir o argumento. Depois confirma exemplos, formatos, unidades, disponibilidade e ligações. Conhecer o produto é indispensável, porque uma melhoria estilística pode alterar sem querer o significado de uma função.

Texto e capturas também devem ser revistos em conjunto. Se a descrição promete acompanhamento em tempo real e as primeiras imagens mostram apenas o catálogo, falta a prova visual que completa a história.

Três revisões evitam uma correção superficial

Na primeira passagem, confirme apenas a verdade: funções, mercados, integrações e condições. Na segunda, avalie compreensão e tom com alguém que não participou no projeto. Na terceira, verifique língua, limites, campos e políticas da loja.

Só depois deve cortar frases sem valor de decisão. «Pensada para si», «experiência intuitiva» e «tecnologia avançada» podem ter lugar quando são explicadas. Sem um facto próximo, apenas ocupam espaço e tornam o texto mais parecido com tantos outros.

Separar estas tarefas evita aperfeiçoar durante muito tempo um parágrafo que terá de ser removido por descrever uma função incompleta.

Medir sem atribuir tudo à descrição

A ficha inclui ícone, título, capturas, vídeo, avaliações e texto. Uma alteração na taxa de instalação pode resultar de vários elementos. Registe por isso a data, a loja, o idioma e o campo alterado. Compare impressões, visitas à ficha, conversão e qualidade das instalações num período semelhante.

Se alterar ao mesmo tempo ícone, imagens e todos os textos, estará a avaliar um conjunto novo. Isso pode ser útil, mas não mostra o efeito isolado da descrição. Para aprender mais, mude grupos coerentes e documente as hipóteses.

As avaliações e perguntas ao apoio ao cliente revelam problemas que os números não explicam. Quando várias pessoas esperam uma função inexistente, a promessa pode estar ambígua. Quando ninguém descobre uma função central, talvez esteja demasiado escondida no texto ou nas capturas.

Como trabalhamos o texto de loja na Appfyl

Não pedimos a um redator que deduza o produto apenas a partir de um ficheiro de design. Primeiro reunimos público, ação central, resultado, mercados, integrações, limites e os ecrãs que sustentam cada afirmação.

Depois criamos textos próprios para cada campo. O design confirma que as primeiras capturas continuam o mesmo argumento. Desenvolvimento e testes verificam os percursos prometidos na versão real. A revisão linguística final acontece quando os dados de exemplo e a disponibilidade estão estabilizados.

Se o produto ainda está a ser definido, o questionário de projeto da Appfyl ajuda a organizar funcionalidades, perfis de utilizador e dependências em perguntas simples. Essa base será útil para a aplicação, a descrição, as capturas e o lançamento.

Veja como a Appfyl transforma escopo em produtos lançados. Ver cases da Appfyl.

Perguntas frequentes