Pesquisa etnográfica de docentes durante o uso do sistema de Gestão Acadêmica - Escola 3.0
Contexto
A MStech Tecnologia S.A. desenvolveu um sistema chamado de Gestão Acadêmica para escolas públicas municipais do Rio de Janeiro/RJ, Bauru/SP e outros municípios. A plataforma administrava processos administrativos, como documentação e gestão de vagas, além de auxiliar professores no planejamento de aulas, registro de faltas e controle de conteúdo.
O sistema foi implantado na rede municipal do Rio de Janeiro no final de 2010. Porém, a pesquisa etnográfica só foi realizada no final de 2011 e apenas na cidade do Rio de Janeiro, pois foi o primeiro município a fornecer feedbacks sobre a utilização.
A MStech utilizava o modelo em cascata de desenvolvimento e não as metodologias ágeis. Por isso, as sugestões de mudança de layout passavam por rodadas de aprovação antes das telas ou dos fluxos serem alterados. Naquele período a empresa tinha apenas 2 designers para todos os projetos e sistemas. Por consequência, o fluxo de navegação, as interações e o layout das telas eram criados pelos desenvolvedores, sem o acompanhamento de um designer.
O Problema
As escolas reclamaram à Secretaria Municipal de Educação sobre as dificuldades de uso do sistema, que por sua vez, encaminhou o problema à MStech. Mesmo as secretarias das escolas com maior adesão ao sistema, enfrentavam dificuldades semelhantes aos dos professores.
Para essa situação, os testes tradicionais de usabilidade, avaliações heurísticas e testes de acessibilidade não explicavam essa baixa adesão. Eu precisava entender os motivos reais desse comportamento e como o contexto diário e a interface do sistema influenciavam o uso pelos professores.
Na época, a empresa apenas monitorava indicadores técnicos, como tempo de processamento de demandas e desempenho do sistema. Não havia indicadores ligados ao uso das pessoas.
Metodologia e Minha Atuação
O gerente de projeto da época solicitou uma pesquisa para entender os motivos do baixo uso do sistema, e eu propus uma pesquisa etnográfica. Ao todo, conversei com 12 professores, 2 diretoras e 2 secretárias.
Antes de ir a campo, criei um roteiro de entrevista semiestruturado. As perguntas cobriam os pontos de dor, as telas mais usadas e a percepção deles sobre o sistema.
Em duas escolas, gravei vídeo das entrevistas. Na terceira, gravei apenas áudio. Para isso, pedi a assinatura de um termo de uso de imagem e voz. Esse documento não existia na empresa — eu criei o modelo usado na pesquisa.
Descobertas
O sistema falhava em atender à realidade cotidiana das escolas. Identifiquei um cenário de fricção grave entre a ferramenta e a rotina dos professores:
- Contexto tecnológico: a administração usava computadores desktop. Os professores usavam netbooks em sala de aula, com telas de 8 ou 10 polegadas e resolução de até 800 x 600 pixels. O sistema não estava otimizado para esse tipo de tela.
- Curva de aprendizado: os problemas no uso do sistema não eram uniformes. Professores acostumados ao sistema desktop antigo se adaptaram com facilidade. Os demais tinham mais dificuldade para migrar para a plataforma web.
- Fluxo de trabalho: o fluxo não era fluido nem centralizado. Isso desestimulava o planejamento pedagógico antecipado e constante, e gerava retrabalho ou acúmulo de tarefas.
- Barreiras estruturais: existiam problemas nos equipamentos disponíveis e na conexão de internet das escolas, que muitas vezes não funcionava. Por isso, muitos professores usavam o próprio celular ou levavam o trabalho para casa, para conseguir acessar o sistema e preencher os dados.
Em uma das escolas, encontrei uma professora que registrava tudo em papel e só depois passava os dados para o sistema. Para ela, esse processo manual era mais rápido do que usar a ferramenta diretamente. Esse comportamento mostrou o tamanho do problema enfrentado pelos professores.
Resultados e Entregas
Criei um relatório detalhado com o resumo de tudo o que vi e ouvi em campo, sem atribuir opiniões às pessoas entrevistadas. Apresentei o relatório diretamente ao gerente do projeto e à gestão da equipe de desenvolvimento, já que não existia time de produto. Detalhei os comportamentos observados e as limitações técnicas de equipamento e infraestrutura.
Como não havia um designer dedicado, sugeri mudanças de telas com base nas descobertas da pesquisa, usando wireframes.
Organizei as sugestões em dois grupos:
- Ajustes de layout: 5 itens para mudança imediata na interface que melhorariam a usabilidade.
- Reestruturação: 14 itens, envolvendo a criação de novas telas, melhorias de fluxo e ajustes em regras de negócio ligadas ao banco de dados e ao cruzamento de informações.
Após a pesquisa, eu não atuei mais no projeto. Por isso, não sei se as mudanças sugeridas foram implementadas.
O que faria diferente hoje
Esse projeto foi um marco na minha carreira. Na época, os estudos de Experiência do Usuário (UX) e Arquitetura de Informação ainda eram recentes no mercado. A empresa usava avaliações heurísticas e de acessibilidade, mas não tinha um processo maduro de UX.
Até eu sair da empresa, a metodologia ágil não havia sido adotada. Os testes de acessibilidade, as avaliações heurísticas e os testes de usabilidade aconteciam sempre depois do lançamento do sistema, ou na fase final de entrega, pouco antes do lançamento. A pesquisa nunca foi integrada à definição de requisitos.
O maior aprendizado foi perceber o volume de retrabalho gerado pela falta de pesquisa e de análise de contexto no início do projeto.
Com relação à execução da pesquisa, eu faria a codificação dos dados coletados em campo. Isso tornaria a análise mais replicável e mais fácil de retomar.
Também aplicaria, além do roteiro de entrevista, uma técnica de mensuração como o SUS (System Usability Scale). Isso me daria um comparativo numérico e mais um argumento sobre o problema enfrentado pelos professores.
Uma limitação desta pesquisa foi não conseguir quantificar o impacto das mudanças sugeridas nem o reaproveitamento das descobertas pela equipe.