Como redesenhei o InPeace Manager para funcionar na pressa e sem sinal

O InPeace Manager é o aplicativo usado por equipes de recepção e voluntários de igrejas para três tarefas presenciais: cadastrar visitantes, validar carteirinhas de membros e fazer o check-in de eventos. A escala varia bastante de cliente para cliente, indo de encontros menores até conferências para 3.000 pessoas ou mais, onde qualquer dúvida na tela forma fila na calçada em poucos minutos.

O aplicativo antigo já tinha leitor de QR Code e opção de baixar a lista de inscritos para usar sem internet. O problema estava na forma como essas funções apareciam na tela: ações importantes escondidas em gestos pouco óbvios, falta de avisos claros quando havia dados esperando sincronização e uma câmera que lia códigos sem parar, gerando incerteza se o ingresso anterior tinha sido validado.

Havia ainda um trade-off importante de produto: o time de backend estava sobrecarregado com outras demandas prioritárias da empresa e não conseguiria desenvolver nada novo para o InPeace Manager. Por causa dessa restrição, eu não podia propor mudanças que dependessem de novas regras no servidor. Toda a evolução precisava acontecer na camada de interface e no comportamento do próprio aplicativo, aproveitando melhor os dados que o sistema já entregava.

Antes de desenhar as novas telas, gravei e analisei o fluxo real de validação em quatro referências do mercado de eventos: Sympla, Eventbrite, Shotgun e E-Inscrição. O objetivo foi observar como ferramentas maduras lidam com leitura de câmera, busca rápida de participantes, indicação de progresso e operação sem internet.

Esse mapeamento ajudou a separar o que era essencial para um operador em pé na portaria e o que podia ser descartado sem exigir mudanças na estrutura de dados da InPeace.

Na versão antiga, as seções 'Principais dúvidas' e 'Converse com a gente' ocupavam cerca de 70% da tela inicial. Quem abria o aplicativo na hora do evento encontrava uma página de ajuda em vez de uma ferramenta de trabalho.

Além disso, os três botões de ação ('Inscrever pessoa', 'Validar eventos' e 'Validar membros') ficavam espremidos na metade superior da tela, uma região difícil de alcançar com o polegar usando apenas uma mão. Outro ponto crítico era o silêncio da tela inicial quando o aplicativo tinha validações feitas sem internet esperando para subir para o servidor.

Igrejas grandes costumam ter dezenas de eventos simultâneos no calendário. Na tela antiga, não existia barra de busca, obrigando o voluntário a rolar a lista inteira até achar o evento certo. Também não era possível baixar a lista de inscritos direto pelo card: era preciso abrir evento por evento para salvar os dados no aparelho.

Quando um evento tinha validações feitas sem internet ainda não sincronizadas, o card antigo mostrava apenas um pequeno ponto de exclamação vermelho ao lado do título. O ícone não explicava o que estava acontecendo e parecia um erro do aplicativo.

Na versão anterior, validar um participante manualmente pelo nome exigia arrastar o card para a esquerda. Esse gesto dependia de um aviso textual no topo ('Arraste para o lado esquerdo para validar') e gerava lentidão quando o voluntário estava em pé segurando o celular com uma mão.

Além disso, não havia filtros para separar quem já tinha entrado de quem ainda faltava chegar. Na parte inferior, dois botões grandes empilhados ('Fazer leitura do Qr code' e 'Atualizar/Baixar lista') roubavam espaço da listagem, enquanto o número total de presentes ficava escondido em outra tela, atrás de um ícone pequeno no canto superior direito.

Na câmera antiga, o painel branco na parte inferior era fixo e não atrapalhava a área de leitura do QR Code. O problema real era o comportamento contínuo do leitor: a câmera ficava lendo sem parar o tempo todo. Quando várias pessoas se aproximavam com o celular na mão, o aplicativo lia códigos vizinhos por acidente.

Isso criava uma situação pior quando o ingresso era válido: diferente da tela de 'Ingresso já utilizado' (que tinha um botão para continuar), o estado de 'Ingresso validado!' apenas mostrava o nome do participante no painel fixo da base e continuava com a câmera ativa. Se outro QR Code passasse na frente um segundo depois, o nome anterior sumia na hora e o voluntário ficava na dúvida se o primeiro ingresso tinha mesmo sido validado ou não.

O cadastro rápido de pessoas é usado no fim dos cultos para registrar visitantes. Na interface antiga, cada campo tinha apenas uma linha fina cinza embaixo do título, fazendo o formulário parecer uma lista de textos soltos em que não ficava claro onde tocar para digitar.

Também faltavam exemplos de preenchimento e formatação automática para telefone e data de nascimento, o que aumentava os erros de digitação quando o voluntário preenchia os dados conversando com o visitante.