“Precisamos de um app” pode significar várias coisas: um software que se abre por um link, algo que se instala no celular, ou os dois. Antes de decidir, quero entender a tarefa e onde as pessoas vão fazê-la. Isso dá uma base melhor para escolher como entregar o produto.
Uma cliente que agenda de vez em quando a partir de um resultado de busca tem necessidades diferentes de um técnico de campo que registra informações o dia todo. Use essas situações para decidir o que importa e depois teste os recursos de que o produto depende.
Comece pela tarefa e pelo caminho até ela
Descreva como alguém encontra o produto pela primeira vez, com que frequência volta e que dispositivo usa. Um gerente de contas revisando um relatório longo talvez prefira o notebook. Um técnico tirando fotos em uma obra precisa de um fluxo pensado para o celular. Uma mesma empresa pode ter os dois públicos.
Como as pessoas vão encontrar e abrir o produto: um resultado de busca, um convite, um QR code ou uma loja de apps?
A tarefa é ocasional, diária ou parte de uma sessão de trabalho contínua?
O que precisa funcionar quando a conexão está fraca ou não existe?
Quais recursos do dispositivo são essenciais para concluir a tarefa?
Quando um web app é um bom ponto de partida
Um web app roda no navegador e pode ser compartilhado por um link. Ele serve bem para portais de clientes, sistemas de agendamento, painéis e muitos outros fluxos. O design responsivo adapta a interface a diferentes tamanhos de tela, mas ainda precisamos testar as tarefas reais nessas telas.
Por exemplo, um portal de fornecedores pode permitir que os clientes façam pedidos pelo celular enquanto a equipe cuida deles no computador. Uma única aplicação web pode atender os dois grupos, com telas e permissões diferentes. Uma página na loja de apps precisaria de um benefício específico para justificar entrar na primeira versão.
O que um web app instalável pode oferecer
Um progressive web app, ou PWA, usa tecnologias da web e pode oferecer uma experiência de app instalado nos dispositivos compatíveis. Funcionamento offline, notificações e outros recursos exigem implementação cuidadosa e testes de compatibilidade. Um ícone na tela inicial não faz nada funcionar offline.
Para entender melhor essa abordagem, veja aintrodução do MDN aos progressive web apps. No seu projeto, eu testaria os recursos necessários nos dispositivos e navegadores que seus clientes usam e definiria uma alternativa para o que não estiver disponível.
Quando um app mobile merece escopo próprio
Um app mobile pode fazer sentido quando o fluxo depende de uma integração mais profunda com o dispositivo, de uma experiência instalada ou de um canal de distribuição específico. Anote essas necessidades com precisão. “Usa a câmera” é amplo demais; o que precisamos avaliar é o processo de captura, as permissões e os dispositivos compatíveis.
Uma ferramenta de vistoria pode precisar guardar um rascunho do relatório no aparelho durante uma visita e enviar as fotos depois. A decisão deve incluir como os rascunhos sobrevivem a interrupções, como funciona a sincronização e o que acontece quando duas pessoas editam o mesmo registro. São decisões de produto, e mesmo um app instalado precisa que elas sejam tomadas.
Publicar nas lojas também exige preparo: contas, páginas da loja, requisitos de revisão e um processo para manter as versões publicadas. Devemos considerar esse trabalho ao comparar as opções. A aprovação e os prazos continuam sujeitos à revisão de cada loja.
Código compartilhado ainda precisa ser testado em cada plataforma
Algumas abordagens compartilham código entre plataformas ou estendem um produto web existente. Isso pode ajudar a reaproveitar trabalho, mas o quanto depende da aplicação e dos requisitos. Eu revisaria o código existente antes de prometer que um web app pode simplesmente virar um app mobile.
O servidor e o banco de dados podem atender tanto a interface web quanto a mobile. Mesmo assim, cada interface precisa de navegação, tratamento de entrada, permissões e testes adequados. O objetivo é um produto coerente nos dispositivos que as pessoas realmente usam.
Escolha a próxima versão com base em evidências
Você pode começar com um canal e adicionar outro quando houver um motivo claro. Se a dúvida é um recurso do dispositivo, teste esse recurso cedo. Se a dúvida é se os clientes precisam do fluxo, teste o fluxo com usuários representativos antes de ampliar a distribuição.
Nossos principais usuários e seus dispositivos são: …
A tarefa mais importante deles é: …
Eles chegam ao produto por: …
Os recursos que precisamos verificar são: …
Adicionaríamos outra plataforma quando: …
Envie esse contexto junto com obriefing do seu projeto. Posso ajudar a comparar as opções com o trabalho que você precisa e a planejar uma primeira versão útil.