Reconhece Card

Contexto

O Reconhece Card é o cartão de benefícios de uma plataforma de campanhas de incentivo. Quem usa não é o cliente que contrata: é o colaborador da empresa cliente, que recebe premiações e precisa consultar saldo, pagar boletos, recarregar celular e transferir valores entre cartões físicos e virtuais.

Isso muda o desenho do problema. A pessoa não escolheu esse app, não tem familiaridade prévia com ele, e o nível de letramento digital varia muito dentro da mesma empresa. Qualquer atrito vira uma ligação para o SAC — que é custo direto para o negócio.

Desafio

Três problemas apareceram já no levantamento inicial, antes de qualquer teste:

• O SAC era acionado com frequência para concluir transferências. Uma tarefa que deveria ser autônoma dependia de atendimento humano.
• O formulário de primeiro acesso coletava dados não essenciais, alongando o cadastro e criando evasão antes mesmo do primeiro uso.
• O aplicativo estava fora de conformidade com o design system que estava sendo construído em paralelo para a plataforma.

Meu papel

Conduzi a construção do aplicativo de ponta a ponta, do recrutamento dos participantes até a entrega para o time de desenvolvimento. Na prática:

• Recrutamento e pesquisa com usuários
• Análise da jornada as-is
• Levantamento do inventário de conteúdo
• Construção da arquitetura de informação
• UI Design e prototipação de alta fidelidade
• Handoff e documentação para front e back-end

Pesquisa

Recrutei 15 participantes entre os usuários mais ativos da base real — não um painel externo. Isso importa: essas pessoas já tinham conhecimento acumulado do produto, então o que elas ainda erravam era problema de interface, não de familiaridade.

Duas dores dominaram as entrevistas e definiram as duas frentes de redesenho:

Primeiro acesso

O cadastro antigo era um chat que perguntava tudo. Em um login que depende de um banco de dados já existente, quase nada disso precisava ser perguntado de novo.

Eram quinze campos antes de qualquer uso do app — incluindo o CEP, perguntado duas vezes, e dados que a empresa já tinha no cadastro.

A decisão foi inverter a lógica: em vez de coletar, confirmar. O usuário informa nome, e-mail corporativo e CPF; o sistema valida por código enviado ao e-mail corporativo; e a única coisa realmente nova que ele cria é a senha do aplicativo. O QUI! Number, que antes vinha no meio do formulário, saiu do caminho crítico.

Sobraram cinco telas: identificação em três campos, código de seis dígitos, criação da senha — com aviso de que essa não é a senha do cartão — e confirmação.

Transferência entre cartões

O QUI! Number é o identificador usado para receber transferências. O problema é que ele convivia na mesma tela com o número do cartão, com o mesmo peso tipográfico e sem nenhuma pista de onde encontrá-lo. As pessoas digitavam um no lugar do outro, a transferência falhava, e a saída era ligar para o SAC.

A correção não foi só visual. Separei os dois números por hierarquia, rótulo descritivo e local de origem: cada campo diz o que espera, um modal mostra onde o QUI! Number fica no verso do cartão físico, e há um botão de copiar dedicado para cada um dos dois números — eliminando a transcrição manual, que era onde o erro nascia.

O modal responde o que faltava: “o QUI! Number contém 16 dígitos, localizados na parte de trás do cartão ao lado do QR Code”. O campo virou QUI! Number do cartão destino, e cada número ganhou seu próprio botão de copiar.

Interface e acessibilidade

Toda a interface foi reconstruída sobre o design system que eu estava estruturando em paralelo para a plataforma — o que resolveu o terceiro problema do levantamento inicial e fez com que app e painel administrativo passassem a falar a mesma língua.

As diretrizes WCAG guiaram contraste, hierarquia tipográfica e áreas de toque. Considerando o público — pessoas de perfis muito diferentes usando dispositivos muito diferentes —, isso não era refinamento: era condição para o app funcionar. O tema escuro entrou pelo mesmo motivo.

A mesma lógica valeu para a posição das ações: o botão de confirmar fica sempre junto do formulário e da área do teclado, nunca depois de uma rolagem. Num app operado com uma mão só, cada rolagem entre o último campo e o botão é uma chance a mais de o usuário abandonar a tarefa no fim dela.

O estado de carregamento virou um padrão com quatro variações, e não uma tela só. Em modal, o app escurece o fundo e mantém o contexto visível; em tela cheia, assume a marca; em carregamentos longos, ganha uma barra de progresso — porque sem ela a espera não tem fim previsível e o usuário toca de novo, ou desiste. O tema escuro tem sua própria versão.

Resultados

Os mesmos 15 participantes voltaram para o teste de validação final, com as tarefas que tinham falhado na primeira rodada:

A queda de 87% nos erros é o número que mais importa para o negócio: era exatamente ele que alimentava o volume de ligações para o SAC.

Stack e ferramentas

Pesquisa

Maze · Google Meet · Octopus

Design

Figma · Pacote Adobe

Entrega

Design System · Design Tokens · Zeplin

Método

Jornada as-is · Inventário de conteúdo · Arquitetura da Informação · WCAG