Jornada do Estudante: o app do MEC usado no Brasil inteiro

Escopo: UX/UI Designer num ecossistema com dezenas de colaboradores, trabalhando em paralelo em 4 arquivos Figma (app mobile em escala nacional, sistema administrativo web, Bold DS e styleguide do DSGov) e em pesquisa de acessibilidade. Colaborei com PMs, squads de engenharia e o MEC.

Autoridade de decisão: tinha autonomia nas decisões de design e de arquitetura de informação do meu escopo. Mudanças que afetavam várias squads, como o fluxograma de navegação, passavam antes por conversa com os PMs.

Período: jul 2022 a jul 2025. Os trabalhos mais densos (formulário de matrícula, Pé-de-Meia e acessibilidade) aconteceram em ciclos de 2 a 4 sprints, com acompanhamento contínuo no Firebase Analytics.

Entregas principais: o formulário de matrícula com salvamento por passo, telas dedicadas por estado de elegibilidade, o TCC com a auditoria comparativa de acessibilidade da documentação do Bold e do DSGov e a contribuição para um Bold DS mais consistente entre app, web e operação interna.

O fluxo de matrícula do programa Pé-de-Meia tinha uma taxa de completude preocupante. O público, estudantes de escola pública, usa celulares de entrada com conexão móvel instável. O PM trouxe dados do Firebase: 35% das pessoas abandonavam o formulário no meio.

Primeira tentativa (falhou): juntei as 6 etapas numa página única, na lógica de que menos telas dariam menos atrito. A taxa de abandono subiu 15%. Os dados do Firebase mostraram que a queda da conexão apagava todo o progresso preenchido. Carga cognitiva somada a rede instável: o pior cenário.

Segunda tentativa: stepper com 5 passos, cada um salvo de forma independente no servidor, e salvamento automático a cada campo. Se a conexão cai no passo 3, a pessoa retoma do passo 3.

Medição qualitativa: depois do deploy do stepper com salvamento automático, a completude do formulário subiu de forma consistente nos relatórios do time de dados, em comparação com a linha de base anterior. O número exato é do Bridge e não foi publicado.

Aprendizado compartilhado: usei o erro da primeira tentativa para abrir com o squad de engenharia uma conversa sobre degradação graciosa em conexão instável. O guia de salvamento incremental que saiu desse trabalho virou referência para os formulários seguintes do produto.

O problema: chegavam ao suporte chamados como "não entendo meu status de elegibilidade". Mapeei mais de 8 estados possíveis de elegibilidade, 6 deles com ambiguidade real (elegibilidade condicional por frequência escolar, matrícula ativa, dados cadastrais, várias matrículas ao mesmo tempo e parcelas com status diferentes).

Decisão que defendi: o PM considerava uma tela genérica com mensagens dinâmicas. Argumentei com os dados de suporte que, nessa escala, a ambiguidade não era tolerável, e propus telas dedicadas por estado, cada uma com texto e ação próprios: "elegível com pendências", "sem pendências", "erro no envio de dados", "informações não identificadas". Validei cada texto com o PM do MEC em testes de campo.

Além do app, desenhei materiais de comunicação, telas detalhadas de parcelas e uma versão web responsiva para acompanhar pelo navegador. Assim, a marca do MEC e do Pé-de-Meia ficou visível em todos os pontos de contato, sem trocar clareza por propaganda.

Resultado qualitativo: depois do deploy, o time de suporte relatou menos dúvidas sobre elegibilidade. Não houve teste A/B formal, mas o volume de chamados nessa categoria diminuiu.

O módulo mais sensível do app reúne dados pessoais, fotos e dependentes. Pessoas em contextos muito diferentes precisam completar o mesmo fluxo com clareza.

Mapeei 12 cenários com a PO do squad, do caminho esperado aos casos que exigem tratamento próprio:

• Estudante sem ou com dependentes (interfaces bifurcadas no mesmo fluxo)
• Informações nulas no INEP (campos vazios vindos do governo, que precisam de fallback visual claro)
• Card com 4 ou mais linhas de nome (nomes compostos longos são comuns)
• Nome preferencial e nome completo oculto (privacidade de menores, exigência legal)
• Troca e exclusão de foto com confirmação destrutiva
• 6 cenários de erro mapeados com ações de recuperação

Num serviço público de escala nacional, um caso pouco frequente ainda é uma pessoa real tentando acessar um serviço. Cada estado precisa de uma resposta compreensível.

O Laboratório Bridge (UFSC/CTC) conecta governo e cidadão por meio de tecnologia. O produto principal é a Jornada do Estudante, app do MEC usado por estudantes em todo o Brasil: identidade estudantil digital, acompanhamento de matrícula, portal do programa Pé-de-Meia e acesso a serviços do MEC. O sistema administrativo web permite que gestores do MEC e das secretarias estaduais cuidem de credenciamento, notificações, banners, conteúdo e auditorias.

Para entender a operação real do programa, cruzei Hotjar, Firebase, painéis do Metabase, chamados de suporte e entrevistas com as pessoas envolvidas. Organizei esse material em três perfis de trabalho: coordenação de projetos e acompanhamento transversal, decisão executiva sob urgência política e operação cotidiana do programa. Ficou claro que o ecossistema precisava comunicar status, risco e próximo passo também para quem sustenta o programa nos bastidores, não só para estudantes.

Mais de 12 módulos, um padrão. Junto com o tech lead, adotamos um padrão para os módulos dos gestores: lista com filtros, formulário de criação e edição, indicadores de status por cor, trilha de navegação e paginação. Quem aprende um módulo já sabe usar os outros.

A pesquisa de satisfação dentro do sistema (escala de emoji e texto livre) foi proposta minha ao PM para ouvir os gestores públicos. As respostas alimentavam a priorização do backlog.

Também desenhei do zero a entrada da versão web da Jornada do Estudante: login, experiência responsiva no navegador e acompanhamento do Pé-de-Meia fora do app. O objetivo era ampliar o acesso sem perder coerência com o DSGov, com a identidade do MEC e com o restante do produto. Num produto do Ministério da Educação, a consistência visual também atende a requisitos institucionais.

Meu TCC em Ciências da Computação (UFSC, nota 10) foi uma auditoria comparativa de acessibilidade da documentação de dois design systems: o Bold e o DSGov, do governo federal.

Metodologia: apliquei o mesmo procedimento à documentação pública dos dois sistemas, com as mesmas etapas: três ferramentas automatizadas (Lighthouse, axe-core e WAVE), inspeção heurística guiada pelas práticas WAI-ARIA e checklist eMAG. Encontrei 277 violações WCAG dos níveis A e AA na documentação, 202 no DSGov e 75 no Bold. No total, foram 75 críticas, 187 sérias, 12 moderadas e 3 leves.

Limites: a auditoria cobre os portais de documentação e seus exemplos, não o app Jornada do Estudante nem o código distribuído dos componentes. Ela não incluiu teste com usuários nem leitor de tela.

Impacto: apresentei os resultados ao supervisor do Bridge e ao time de DS. Parte das violações críticas do Bold foi priorizada para correção nas sprints seguintes, e as descobertas sobre o DSGov viraram material de referência interno.

O Bold é o DS open source mantido no Bridge, com componentes documentados, regras de quando não usar cada um, playground interativo e guia de estados.

Método, dados e limites estão na página do estudo, Acessibilidade por padrão. A monografia está no repositório da UFSC ↗ (Abre em nova aba), e os dados, no Zenodo ↗ (Abre em nova aba).

O DSGov é o design system oficial do governo federal. Criei um styleguide adaptado porque os componentes oficiais tinham inconsistências entre documentação e implementação. Ele cobre cores (escala de azul primário, fundos, escala de cinza e feedback), tipografia com escala para grids de 8 e 12 colunas e componentes customizados dentro das regras do DSGov.

Na camada de código, trabalhei com os devs em HTML semântico, ARIA e controle de foco em JavaScript. As correções do DSGov passaram nos cenários testados sem alteração visual da especificação.

Também criei o fluxograma de navegação completo do app: login, onboarding e home com 8 seções (Perfil, Jornada, Documentos, Pé-de-Meia, Notificações, Serviços, Avaliar Apps e Configurações). Com várias squads trabalhando em paralelo no ecossistema Bridge, esse mapa virou um artefato de alinhamento que PMs e devs consultavam antes de começar uma funcionalidade.