Bridge × MEC: Jornada do Estudante e Pé-de-Meia

Estudantes de todo o Brasil dependem de um formulário para receber sua bolsa. Erre o auto-save por um campo e o estudante perde meses de progresso. Redesenhei esse formulário para nunca mais falhar silenciosamente.

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

Escopo de decisão: Autonomia nas decisões de design e arquitetura de informação do meu escopo. Para mudanças que afetavam múltiplas squads (como o fluxograma de navegação), conversei com os PMs antes de implementar. As descobertas da auditoria de acessibilidade foram compartilhadas com o time e viraram material de referência interno.

Timeline: 3 anos (Jul 2022 - Jul 2025). Os trabalhos mais densos (formulário de matrícula, Pé-de-Meia, acessibilidade) aconteceram em ciclos de 2-4 sprints com validação contínua via Firebase Analytics.

Resultado principal: Redesenho do formulário de matrícula com salvamento incremental, TCC com auditoria comparativa de acessibilidade (277 violações WCAG, 84 críticas) e contribuição para um Bold DS mais consistente entre app, web e operação interna.

O Laboratório Bridge (UFSC/CTC) conecta governo e cidadão por meio de tecnologia. O produto principal é a Jornada do Estudante (JE): app do MEC usado por estudantes em todo o Brasil.

O app serve como identidade estudantil digital, acompanhamento de matrícula, portal do programa Pé-de-Meia e hub de serviços do MEC. O sistema administrativo web permite que gestores do MEC e secretarias estaduais gerenciem credenciamento, notificações, banners, conteúdo e auditorias.

Para sair do desenho abstrato e entender a operação real do programa, cruzei Hotjar, Firebase, painéis do Metabase, tickets de suporte e entrevistas com stakeholders. Estruturei esse material em três personas-chave: Janaína (coordenação de projetos e acompanhamento transversal), Silmara (decisão executiva com urgência política) e Rafael (perfil operacional jovem, ideal para tarefas táticas com alta familiaridade digital). Esse recorte deixou claro que o ecossistema não precisava funcionar só para estudantes: precisava também comunicar status, risco e próximo passo para quem sustenta o programa por trás dos bastidores.

O fluxo de matrícula do programa Pé-de-Meia tinha taxa de completude preocupante. O público-alvo, estudantes de escola pública, usa celulares de entrada com conexões móveis instáveis. O PM trouxe dados do Firebase: 35% dos usuários abandonavam no meio do formulário.

Primeira tentativa (falha): Consolidei 6 etapas em uma página única. Lógica: menos telas = menos atrito. Resultado: a taxa de abandono subiu 15%. Sessões no Firebase Crashlytics mostraram que conexões caindo causavam perda de todo o progresso preenchido. Sobrecarga cognitiva + rede instável = pior cenário.

Segunda tentativa (sucesso): Stepper modular com 5 passos, cada um salvável independentemente no backend. Auto-save a cada campo. Se a conexão cair no passo 3, o usuário retoma do passo 3.

Medição qualitativa: A completude do formulário subiu de forma consistente nos relatórios do time de dados após o deploy do stepper com auto-save, em comparação com a linha de base anterior. O recorte numérico exato é de posse do Bridge e não foi publicado.

Aprendizado compartilhado: Usei o erro inicial como base para uma conversa com o squad de eng sobre degradação graciosa em conexões instáveis. O guia de autosave incremental que nasceu desse trabalho virou referência para formulários subsequentes no produto.

O módulo mais sensível do app: dados pessoais, fotos, dependentes. O desafio: um estudante de 14 anos no interior do Maranhão e um de 17 em São Paulo precisam completar o mesmo fluxo com a mesma clareza.

Mapeei 12 cenários com a PO do squad (Jaqueline Marques), desde o caminho feliz até edge cases que afetam centenas de milhares de usuários:

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

Em gov-tech de escala nacional, o que outras empresas chamam de "edge case" são centenas de milhares de pessoas reais. Cada estado precisa de uma tela.

O problema: Uma parte significativa dos chamados do helpdesk era "não entendo meu status de elegibilidade". Mapeei 8+ estados possíveis de elegibilidade, 6 com ambiguidade real (elegibilidade condicional por frequência escolar, matrícula ativa, dados cadastrais, múltiplas matrículas simultâneas, 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: ambiguidade nessa escala não é tolerável. Propus telas dedicadas por estado, cada uma com copy específica e ação clara: "elegível com pendências", "sem pendências", "erro no envio de dados", "informações não identificadas". Validei cada copy com o PM do MEC via field testing.

Além da experiência dentro do app, desenhei materiais de comunicação, telas detalhadas de parcelas e uma superfície web responsiva para acompanhamento pelo navegador. Isso ajudou a manter a marca do MEC e do Pé-de-Meia visível em todos os pontos de contato, sem trocar clareza por propaganda.

Resultado qualitativo: Após o deploy, o time de suporte reportou redução perceptível nas dúvidas sobre elegibilidade. Não houve A/B test formal, mas o padrão de tickets na categoria diminuiu.

12+ módulos para gestores do MEC e secretarias estaduais. Junto com o tech lead, adotamos um padrão consistente: lista com filtros, formulário de criação/edição, indicadores de status por cor, trilha de navegação e paginação. Aplicamos o mesmo padrão em todos os módulos; gestores que aprendem um já sabem usar todos.

O NPS embutido (modal com escala de emoji + texto livre) foi minha proposta ao PM para coletar feedback in-app dos gestores públicos. Dados coletados alimentavam a priorização de backlog.

Também desenhei do zero a porta de entrada da versão web do ecossistema Jornada do Estudante: login, experiência responsiva no navegador e superfícies de acompanhamento do Pé-de-Meia fora do app. O objetivo era ampliar acesso sem perder coerência com DSGov, com a identidade do MEC e com o restante do produto. Quando o stakeholder é o Ministério da Educação, consistência visual é requisito institucional, não detalhe estético.

Meu TCC em Ciência da Computação (nota 10, UFSC) foi uma auditoria comparativa de acessibilidade entre o Bold DS e o DSGov. Não foi um exercício acadêmico isolado; as descobertas impactaram diretamente o produto.

Metodologia: Testei com 6 ferramentas (Lighthouse, Axe Core, WAVE, JAWS, NVDA, VoiceOver) em 15 componentes de cada DS (análise comparativa: Bold DS vs. DSGov). Encontrei 277 violações WCAG (categorização: 84 críticas, 193 moderadas), desde contraste insuficiente até problemas de navegação por teclado em janelas sobrepostas. Essas restrições forçaram uma hierarquia visual mais clara e estados mais explícitos, o que acabou beneficiando a compreensão para todos os usuários, independentemente de deficiências.

Impacto: Apresentei os resultados ao supervisor do Bridge e ao time de DS. Parte das violações críticas encontradas no Bold foi priorizada para correção em sprints seguintes. As descobertas no DSGov viraram material de referência interna. O TCC foi publicado e virou referência para decisões de acessibilidade no laboratório.

O Bold é o DS open-source mantido no Bridge, com componentes documentados, regras de quando NÃO usar, playground interativo e guia de estados.

Compartilhamento: O TCC não foi um exercício isolado: as descobertas viraram conversa com o time de design e eng sobre padrões WCAG.

O DSGov é o DS do governo federal, obrigatório para gov-tech. Criei um styleguide adaptado porque os componentes oficiais tinham inconsistências entre documentação e implementação. O styleguide cobre: cores (primary blue scale, backgrounds, grey scale, feedback), tipografia com escala para grids de 8 e 12 colunas, e componentes customizados dentro das regras do DS.

Também criei o fluxograma de navegação completo do app: Login → Onboarding → Home (8 seções: Perfil, Jornada, Documentos, Pé-de-Meia, Notificações, Serviços, Avaliar Apps, Configurações). Com várias squads trabalhando em paralelo no ecossistema Bridge, esse mapa visual virou um artefato de alinhamento consultado por PMs e devs antes de iniciar features.