Aplicativo ou portal para serviço público: como decidir antes de contratar

Na dúvida entre aplicativo ou portal para serviço público, o uso do cidadão decide. Quando o serviço é usado de vez em quando, um portal bom no celular costuma resolver. O aplicativo se justifica quando o uso é frequente, quando o órgão precisa avisar o cidadão ou quando o serviço tem de funcionar sem conexão.

O critério é o uso, não o formato que está na moda.

A pergunta que vem antes de contratar o aplicativo

A demanda chega assim: "precisamos de um app". Quase sempre, o que está por trás é outra necessidade: levar o serviço público no celular, para que o cidadão acesse, sem ir ao balcão e sem abrir um computador.

Essa necessidade pode ser atendida por um app do cidadão. Também pode ser atendida por um portal responsivo, que funcione bem na tela pequena. Os dois chegam ao celular, mas trazem trabalhos diferentes para o órgão.

Por isso a primeira conversa não é sobre tecnologia. É sobre como o cidadão vai usar o serviço.

Os três sinais de uso que decidem

Três perguntas ajudam a separar os casos:

• O cidadão volta com que frequência? Uma vez por ano, para renovar um cadastro, é um uso. Toda semana, para acompanhar algo, é outro.
• O órgão precisa avisar o cidadão sem esperar que ele entre? Lembrete de prazo, mudança de status ou convocação são exemplos.
• O serviço precisa funcionar sem conexão, ou usar um recurso do aparelho? Em área de sinal fraco, ou com uso contínuo da câmera, por exemplo.

Se a resposta às três for "não", há uma boa chance de o aplicativo não ser necessário. Se alguma for "sim", ela merece ser examinada com calma.

Serviço de uso eventual pede portal bom no celular

Pense num serviço que o cidadão usa de vez em quando: pedir uma certidão, consultar a situação de um protocolo, agendar um atendimento. Cada pessoa abre, resolve e vai embora.

Para esse uso, instalar algo no aparelho costuma ser um passo a mais, sem recompensa. O cidadão precisa ter espaço no celular, achar o aplicativo na loja e baixar, tudo para uma tarefa que dura poucos minutos. Um endereço que abre direto no navegador tira esse passo do caminho.

O que significa portal bom no celular

"Funciona no celular" não basta. Um portal bom na tela pequena tem quatro características:

• Layout responsivo. O conteúdo se reorganiza conforme a tela, sem obrigar o cidadão a dar zoom ou rolar para o lado.
• Leveza. A página abre em conexão comum de celular, sem esperar carregar o que não importa. O post sobre Core Web Vitals mostra como medir isso.
• Formulário usável com o polegar. Campos grandes, o teclado certo para cada dado (numérico para CPF, por exemplo) e botões que não ficam colados uns nos outros.
• Acessibilidade. Contraste, leitura por leitor de tela e navegação por teclado valem tanto no celular quanto no computador.

Esse é o trabalho de criação de sites: o portal pensado desde o começo para a tela pequena, e não só adaptado no fim.

O que o portal já entrega sem instalação

Sem instalar nada, o portal já cobre muita coisa do que se imagina para um aplicativo:

• Acesso por endereço. O cidadão chega por um link, por uma busca ou por um QR code impresso no balcão.
• Atualização sem loja. Uma correção ou uma mudança de regra vai ao ar e vale para todos de uma vez. Ninguém precisa atualizar o aplicativo no aparelho.
• Identificação já resolvida. O portal pode usar a conta gov.br para entrar, como explicamos em login gov.br em sistema público.

Quando o aplicativo se justifica

Há casos em que o aplicativo é a resposta certa. Eles têm em comum um uso que o portal não atende bem.

Uso frequente

Quando o cidadão, o servidor ou o agente de campo abre a ferramenta todo dia, o aplicativo ganha peso. O ícone na tela inicial, a abertura rápida e a sensação de ser "do aparelho" passam a contar.

Um exemplo hipotético: uma equipe de fiscalização que registra vistorias em campo durante toda a semana. Aqui o aplicativo faz sentido, porque o uso é diário e cada segundo na abertura se repete centenas de vezes.

Aviso ao cidadão

Se o órgão precisa avisar o cidadão no momento certo, a notificação importa. Convocação, prazo que vence, resultado liberado: o portal só informa quando a pessoa entra, e muita gente não volta por conta própria.

Notificação não é exclusividade do aplicativo, e ela também tem regras de uso em cada plataforma. Mas é um dos motivos mais comuns para o órgão querer um.

Uso sem conexão ou recurso do aparelho

Quando o serviço precisa funcionar em lugar sem sinal, ou depende de um recurso do aparelho como câmera, localização ou leitura de documento, o aplicativo costuma entregar mais controle.

Um exemplo hipotético: um agente que coleta dados em áreas rurais, sem conexão, e sincroniza quando volta ao sinal.

Há um meio-termo, o PWA, que é um site feito para se comportar como aplicativo. Ele cobre parte desses casos, com limites que variam por plataforma. A comparação completa está em PWA ou aplicativo nativo.

O que o aplicativo acrescenta ao trabalho do órgão

Esta é a parte que a demanda "façam um app" raramente menciona. Um aplicativo não é um portal com outro nome: ele traz tarefas que o portal não tem.

Duas lojas, duas regras

Para chegar a todos os cidadãos, o aplicativo precisa estar na loja do Android e na da Apple. Cada uma tem seu processo de publicação, sua revisão e suas regras, e elas mudam com o tempo.

Uma versão nova só chega ao cidadão depois de passar pela revisão da loja. Planejar uma atualização urgente, como a correção de um erro em período de prazo, passa a incluir esse tempo de espera.

Conta de desenvolvedor: de quem é e quem responde

Para publicar na loja, é preciso uma conta de desenvolvedor. E aí aparece uma pergunta que convém responder cedo: em nome de quem ela fica?

Se a conta estiver em nome de um terceiro, o aplicativo fica preso a ele. Se estiver no órgão, é o órgão que responde pela publicação e guarda os acessos. Decida isso no início, por escrito, e defina quem no órgão guarda as credenciais. Quando a pessoa que cuidava disso sai do cargo, o acesso não pode sair junto.

Em projetos de criação de aplicativos, essa conversa deve acontecer antes da primeira publicação, e não depois.

Versões que convivem

No portal, a mudança vale para todos assim que vai ao ar. No aplicativo, não. Cada pessoa atualiza quando quer, e por um tempo versões diferentes convivem.

O sistema por trás do aplicativo precisa continuar atendendo as versões antigas. Isso limita mudanças que seriam simples num portal e exige cuidado a cada alteração de regra.

Acessibilidade em duas plataformas

A acessibilidade do portal segue o eMAG e as diretrizes do WCAG. No aplicativo, ela precisa ser verificada em cada plataforma, porque iPhone e Android têm leitores de tela e convenções de navegação próprios.

Na prática, o teste de acessibilidade se repete em dois sistemas, com aparelhos reais, a cada mudança relevante.

Quem cuida disso no órgão

Nada disso é impeditivo. Mas o aplicativo é um produto que continua depois da entrega: precisa de alguém no órgão que decida prioridades, responda pelas contas e acompanhe as versões.

É um custo contínuo, e a manutenção é um plano contratado à parte, não algo que vem junto do desenvolvimento. Se esse dono ainda não existe, vale resolver isso antes de contratar.

Recebeu a demanda de fazer um aplicativo?

Antes de definir o formato, descreva o caso: quem é o cidadão, o que ele precisa resolver e com que frequência. Com isso na mesa, a conversa sobre aplicativo ou portal deixa de ser opinião e passa a ser critério.

Para levar à reunião, estas perguntas ajudam:

1. O cidadão usa o serviço uma vez por ano ou toda semana?
2. O órgão precisa avisá-lo antes que ele entre?
3. O serviço tem de funcionar sem conexão ou usar a câmera, a localização ou outro recurso?
4. Em nome de quem ficam as contas das lojas, e quem guarda os acessos?
5. Quem, dentro do órgão, vai responder pelo aplicativo depois da entrega?

Se quiser conversar sobre o seu caso, descreva-o pelo formulário de contato do site. Pode ser que a resposta seja um aplicativo. Pode ser que um portal bom no celular seja suficiente.