6 perguntas que devem ser respondidas por quem quer transformar seu produto em aplicativo
Todos já ouvimos sobre a importância de ‘ser mobile’. Reflexo do fato de que passamos cada vez mais tempo conectados e o celular está no topo da lista abocanhando 3,7 horas do nosso dia (dados: 2020 State of mobile - AppAnnie).
O que não podemos esquecer é que ser mobile não é apenas ter um app, mas sim entender como essa plataforma se diferencia da web, quais são seus desafios peculiares no seu contexto de negócio e como é possível utilizá-la para gerar mais valor para as pessoas usuárias.
Depois de ter passado por duas experiências de criação de plataformas mobiles em mercados diferentes (uma delas em andamento aqui no Jusbrasil), quero dividir alguns insights que acho que podem ajudar quem vai passar por essa jornada.
#1 - como a tela do celular pode servir ao meu produto?
Ser mobile não é ter um app ou produto disponível em diversos devices, e sim sobre formas simplificadas de consumir e publicar informação.
Devices mudam o tempo todo: todo mês tem coisa nova, o Android não vai matar o IOS (e vice-versa) e o telefone e o tablet estão cada vez mais próximos de uma coisa só. A chave então é a tela e o que ela proporciona.
É verdade que para muitas pessoas a tela do dispositivo móvel é a mais utilizada. Mas isso não faz esses dispositivos unicamente importantes. Temos muitos exemplos de negócios disruptivos que evoluem e percebem que é necessário servir seu usuário também com uma interface web: Spotify, Uber e WhatsApp são bons exemplos. Sim, a interface web também torna o produto mobile! O segredo está em compreender que o Job de uma mesma pessoa usuária vai ser necessariamente diferente nas duas telas: ninguém leva o mac pra praia e eu não estou escrevendo esse texto no celular.
#2 - em qual contexto minha pessoa usuária vai sacar o dispositivo móvel para usar meu produto?
Devemos considerar que o contexto da pessoa usuária no mobile é único e fundamentalmente diferente do contexto do usuário web. Vamos às principais diferenças:
Mobile users são task-oriented. Isto é, quando a pessoa destrava o Smartphone, ela quer atingir um objetivo específico e de forma rápida. Talvez achar um restaurante próximo porque está com fome, comprar a entrada da sessão de cinema que já vai começar, verificar o significado de uma palavra nova ou mesmo se distrair enquanto espera numa fila. Qualquer que seja o use case aqui, todos têm uma coisa em comum: atingir um objetivo claro. Note que na web, acessamos o Google ou o site do cinema dentro de uma perspectiva muito mais exploratória.
Mobile users facilmente perdem o engajamento. Enquanto os usuários web estão em um ambiente controlado (trabalho ou casa), os usuários do mobile o utilizam entre uma tarefa e outra do seu dia. Isso significa que eles podem ser distrair facilmente. O time de produto mobile precisa ajudar o usuário a finalizar seu job o mais rápido possível com o mínimo de fricção. Isso significa: reduzir o número de steps e clicks rumo à conversão / solução do problema.
Está ficando cada vez menos frequente, mas já vimos por aí muitos cases de produtos web que, para garantir sua presença mobile no mercado, criam um app e o enchem com todas as features disponíveis na web. O problema é que esse método não endereça o objetivo principal do usuário mobile: resolver rapidamente seu job. Na verdade, essa estratégia só piora a situação já que usuário vai se frustrar diante de uma UI lotada de coisas numa tela pequena e com uma velocidade de processamento inadequada.
#3 - a UX/UI do meu app está adequada ao novo contexto que o meu produto adquire no dispositivo móvel?
Como já mencionado, o produto na tela mobile deve ser direto ao ponto e leve. Diante disso, precisamos de atenção redobrada com a UI e UX. Vale se aprofundar e entender os conceitos dos guidelines de design para mobile. Tanto o guideline do Android quanto do IOS são boas referências para as melhores práticas. Sugiro segui-las.
Aqui um resumão do que está escrito lá + experiência + boas práticas de mercado:
- Navegação concentrada no polegar
- Espaço de clique adequado (esqueça links e botões pequenos)
- Editar os textos que irão compor o app é mandatório. Estamos diante de um tamanho de tela reduzido, não é possível replicar o formato do conteúdo de um site e obter o mesmo resultado. É preciso reduzir, reorganizar.
- A intuição do usuário é ditada por grandes players como Instagram e Google. Copiar é ser esperto!
- Considerar como o a UX/UI vai se comportar em diferentes tamanhos de tela.
- Reduzir necessidade de digitação e sempre definir o melhor teclado quando houver necessidade de digitar
- Os Layouts devem incluir animações e esquemas de transição de telas
#4 - o meu roadmap permite releases curtas e constantes?
MVP please! Errar rápido no mobile é ainda mais crítico!
Enquanto o bounce de um usuário que veio do Google pode ser revertido em uma nova busca, recuperar um usuário que fez download de um app e o desinstalou frustrado com a experiência é mais difícil e custoso. Afinal, por quais motivos ele vai tentar novamente? Seja lá o que não estiver gerando os resultados esperados, precisamos identificar e ajustar muito rápido!
Ao trabalharmos com grandes releases, fica difícil correlacionar o comportamento do usuário devido a influência de uma diversidade de fatores. Atualizações pequenas e semanais são mais bem-vindas, sempre que possíveis. Essa técnica é conhecida como release train schedules.
De acordo com dados da Apptimize, os top 100 apps da App Store fazem 3x mais releases do que os demais. Esses ciclos curtos permitem reações rápidas às mudanças no mercado, mitigam incertezas das features e otimizam a interação com os usuários.
Gosto de uma fala antiga do Wasem Daher, do Dropbox, que ilustra bem os dilemas de acreditar ou não no poder de um MVP:
“Smart people really like to over-complicate the problem because you can see four steps ahead. So it’s very tempting to say: “Oh let me go build that final version. But when you do that…you don’t get something that actually increases your user’s metrics.”
#5 (forte recomendação) - o time escolhido possui o know-how necessário para desenvolver de forma contínua com testes E2E automatizados e usar feature flag nos releases mais complexos?
Acostume-se! App e Play Store podem ser pedrinhas no sapato pois geram restrições importantes que devem ser conhecidas pelo time.
A principal delas? Toda nova versão deve ser aprovada e isso pode levar dias. O maior impacto dessa fricção é numa eventual necessidade de corrigir bugs, ou seja, não existe hotfix em aplicativos (essa não é uma verdade absoluta, conseguimos fazer hotfix usando remote config, o que é bem mais complexo do que qualquer correção pontual na web). Qualquer correção precisa ser submetida para aprovação e em seguida a atualização deve ser baixada pelo usuário para que de fato o problema seja resolvido.
Por isso, é preciso atenção sobrenatural com a qualidade do código que submetemos para aprovação e obsessão com duas máximas: habilitar testes e2e automatizados e evitar regras de negócio no client.
Ok, mas bugs sempre vão existir, certo? Certo. Por isso precisamos conhecer a Feature flagging, a melhor amiga dos times de produto mobile! \o/
Feature flag é a magia que nos ajuda quando não podemos evitar regras de negócio no front ou precisamos reverter versões que não deram tão certo. Trata-se de uma técnica de desenvolvimento usada para ‘ligar ou desligar features da aplicação’. Com isso conseguimos ter um certo controle sobre as releases e desligar eventuais features cujo resultado não siga como esperado. O Facebook AMA e foi pioneiro nessa técnica. Mais info sobre feature flagging aqui.
#6 - como os usuários pesquisam nas lojas pela solução que estou oferecendo?
Tchau SEO e bem-vindo ASO: os principais caminhos que levam ao download de aplicativos são: buscas nas stores ou indicação/recomendação de família e amigos.
Usamos ASO (App Store Optimization) para otimizar o título, keywords e descrição do app a fim de atingir a audiência correta, ou melhor, garantir que a busca dela nas lojas a leve até nós.
Os manuais de boas práticas para ASO e as ferramentas de mercado que nos ajudam nisso são inúmeros. Listei abaixo alguns conteúdos recomendados.
Para estudar:
https://moz.com/blog/app-store-seo-the-inbound-marketers-guide-to-mobile
https://neilpatel.com/blog/app-store-optimization/
https://www.tune.com/blog/have-you-changed-your-app-title-yet/
https://medium.com/@kaleefam54/app-store-optimization-aso-tips-for-2020-626dceb3343e
https://www.slideshare.net/maorgad/10-killer-app-store-marketing-tips
Ferramentas de mercado:
https://app.apptweak.com/applications/
Para abordar o tema Recomendação vamos precisar nos aprofundar num conceito que pertence a um outro momento de um produto mobile: o Growth. E isso é um tema para outro artigo! 😉
Enfim… ser mobile é muito mais que desenvolver um app
Tente responder, pelo menos, estas 6 perguntas antes de investir na transformação de um produto / feature num app ou até mesmo ao considerar esse canal sua porta de entrada para o mercado!
