Para preservar a confidencialidade (NDA), a identidade e dados reais foram alterados ou omitidos.
Visão geral
Estávamos reestruturando a visão do aluno na versão web. O app é o acesso diário de boa parte dos alunos à rotina acadêmica, então, para seguir o conceito de plataforma, ele precisava acompanhar.
A página inicial era um grid de cards e atalhos. A navegação global vivia dentro de um menu no header. Funcionava, mas não conversava com o que construímos na web.
Bom reforçar que a navbar não era uma pauta oficial. Mas ao olhar para a refatoração do dashboard, ficou claro que reorganizar os cards sem definir a navegação seria resolver metade do problema. Então propus o caminho completo.
Mesmo seguindo por esse caminho, decidi conter o escopo, então não mexi na estrutura do dashboard. Poderia ter proposto já refazer essa seção inteira, mas trazer um redesign nessa entrega aumentaria o risco e precisaria de mais etapas de validação. Limitei a mudança à navbar e à seção de Ajustes. Uma decisão estrutural de cada vez.
Meu papel e ações
Só que antes de alterar qualquer estrutura, fui ao Microsoft Clarity para analisar informações gerais da sessões para tentar entender volume e padrão de interação.
Decidi analisar o mapa de calor a partir daquele momento da demanda. Escolhi uma janela de dois meses para reduzir o risco de sazonalidade do calendário acadêmico, já que o comportamento do aluno pode variar ao longo do semestre. Queria encontrar um padrão, não um pico.
A intenção era entender onde as pessoas tocam e responder à pergunta "Quais seções as pessoas acessam com mais frequência?".
Percebemos que "Aulas" e "Avaliações" concentravam a maior parte das interações.
Essas evidências definiram o que deveria ser priorizado na Navbar.
Estudei os padrões de mercado de forma leve, sem um benchmark extenso. O Clarity já apontava a direção, e aprofundar referência seria retardar uma decisão que os dados já sustentavam. Escolhi onde valia gastar tempo.
Como o escopo da demanda estava mais aberto, decidi antecipar e testar alguns cenários.
Simulei zoom, testei em outros idiomas, explorei como os componentes se comportavam em tablet vertical e horizontal, estressei diferentes situações para contemplarmos os principais cenários e gaps. Custou tempo e poderia parecer excesso de zelo. Fiz com a intenção de que a robustez compensaria.
O app tem uma ótima nota nas lojas (Apple Store e Play Store). Não podia receber uma mudança estrutural frágil.
A única decisão que precisou de validação mais específica com os devs e o PO foi o fluxo. Quando a navbar ficaria fixa e quando ela sumiria. Esse comportamento tinha que ser coerente em toda a jornada.
Ajustamos alguns detalhes juntos e fechamos o fluxo antes de finalizar.
Já o restante, foi entregue revisado e atualizado.
Resultado
A navbar está no ar;
A seção de Ajustes também, absorvendo tudo que estava no menu hambúrguer e adicionando o que faltava com hierarquia;
A reação e os feedbacks dos usuários estão sendo observados e mapeados;
A hipótese que estamos validando: se a navbar funcionar como ponto de entrada mais eficiente, os cards do dashboard vão perder cliques; O Clarity e o Firebase evidenciarão esse comportamento.
Aprendizados
Aprendi que:
Iniciativas sem escopo definido pedem mais rigor, não menos. Por isso ter levantado as informações foi importante para a ideia fazer mais sentido dentro do nosso contexto;
Boas entregas são feitas de escolhas sobre o que não fazer. Conter o escopo do dashboard, manter o benchmark enxuto e investir onde o risco era maior foram decisões tão importantes quanto a navbar em si;
Antecipar cenários leva mais tempo de início, no entanto garante uma entrega mais robusta e alinhada com os objetivos, evitando então possíveis retrabalho.