Plataforma de Gestão de Formação Multi-Perfil
Os mesmos dados, quatro âmbitos, dois modos de pensar
A Cordilheira é uma plataforma de gestão de formação para dirigentes escutistas. Quatro níveis organizacionais trabalham sobre os mesmos dados, mas com necessidades e responsabilidades diferentes — do dirigente que acompanha o seu próprio percurso ao administrador nacional que supervisiona milhares de registos.
Foi no desenho dessa diferença que esteve o principal desafio do projeto: criar uma experiência coerente sem assumir que todos os utilizadores precisam de interpretar a informação da mesma forma.
Como Product Designer, desenhei o produto end-to-end, desde a arquitetura de informação e lógica de estados até à interface de alta fidelidade e documentação para implementação, em 2026.
Um sistema legível por quem o usa e por quem o constrói
A Cordilheira ficou documentada componente a componente, com cada filtro, indicador e CTA associado à regra de negócio que o governa.
Mais do que definir uma coleção de ecrãs, o projeto estabeleceu padrões para trabalhar com diferentes níveis de responsabilidade sobre os mesmos dados: progresso separado de elegibilidade, divulgação progressiva, estados estáveis, priorização na gestão e visualização agregada para leitura rápida.
O resultado é uma estrutura que permite acrescentar novos percursos, módulos e necessidades de gestão sem perder a lógica que mantém o produto compreensível.
O desafio seguinte não é mostrar mais informação, mas continuar a transformar complexidade em decisões claras.
Getting Started
A Cordilheira organiza a formação dos dirigentes escutistas num único sistema, permitindo que diferentes níveis da organização trabalhem sobre a mesma estrutura de dados.
Um dirigente acompanha o seu percurso e identifica o que precisa de fazer a seguir. Um responsável local acompanha a progressão de um conjunto de dirigentes. Num nível superior, o administrador precisa de identificar padrões, lacunas e pessoas que requerem atenção.
O produto tinha, portanto, de responder a duas necessidades distintas: agir sobre o próprio percurso e supervisionar o percurso de outros.
Desenhei a experiência de ponta a ponta — arquitetura de informação, modelo de estados, fluxos, interface de alta fidelidade e documentação de handoff — garantindo que estas diferentes necessidades partiam de uma estrutura de produto comum.
Context
A formação escutista organiza-se em diferentes percursos — Percurso de Educadores I a IV, Percurso de Gestores Locais e Percurso de Regresso ao Ativo — compostos por módulos de Tronco Comum e de Formação Específica.
Cada módulo pode ter várias edições, com cidade, datas, formato presencial ou online, vagas e preço.
A complexidade surge na relação entre estes elementos: um dirigente só pode avançar para determinados percursos depois de cumprir módulos-requisito, mas progresso e elegibilidade não são a mesma coisa.
Esta lógica precisava de estar presente na interface sem obrigar o utilizador a conhecer previamente as regras do sistema.
The Challenge
O desafio central era desenhar uma única experiência para diferentes níveis de responsabilidade sobre os mesmos dados.
Para o dirigente, a pergunta é operacional:
Onde estou e o que tenho de fazer a seguir?
Para quem gere formação, a pergunta é analítica:
Quem precisa da minha atenção e onde posso agir?
A mesma informação — progresso, módulos, requisitos e elegibilidade — precisava, por isso, de ser apresentada de formas diferentes consoante o contexto.
Havia ainda uma segunda camada de complexidade: a informação não era estática. Estados, requisitos e disponibilidade alteravam o que cada utilizador podia fazer.
O problema não era simplesmente mostrar mais ou menos informação. Era determinar que informação devia estar imediatamente disponível, que informação podia ser descoberta através de interação e que sinais ajudariam cada perfil a tomar a decisão certa.
Trade-offs
Num produto onde os mesmos dados servem diferentes níveis de responsabilidade, cada decisão implicou escolher o que otimizar para cada contexto.
Densidade visual vs. custo de interação
Alternativa: consolidar percursos e catálogo numa única vista com separadores.
Decisão: manter os dois painéis visíveis em simultâneo.
Trade-off: maior densidade visual.
Porquê: as duas tarefas são paralelas. O utilizador cruza frequentemente o percurso com os módulos disponíveis, pelo que separar as vistas aumentaria o custo de interação.
Detalhe imediato vs. capacidade de varrer
Alternativa: manter todos os percursos permanentemente expandidos.
Decisão: utilizar divulgação progressiva.
Trade-off: quem procura detalhe tem de realizar uma interação adicional.
Porquê: a tarefa dominante é compreender rapidamente o estado geral do percurso, não ler todo o seu conteúdo.
Flexibilidade do layout vs. orientação
Os cartões de percurso assumem diferentes estados e necessidades de informação.
Decisão: manter uma estrutura espacial estável entre estados — incluindo progresso, elegibilidade, chevron e créditos.
Trade-off: cada estado teve de funcionar dentro das mesmas restrições espaciais.
Porquê: a estabilidade reduz o esforço de reaprendizagem quando o estado do utilizador muda.
Neutralidade vs. utilidade na vista de gestão
Alternativa: apresentar uma lista neutra, ordenada apenas por nome ou outro critério administrativo.
Decisão: destacar a proximidade à elegibilidade no estado inicial.
Trade-off: a interface assume uma prioridade em vez de tratar todos os registos de forma equivalente.
Porquê: o objetivo da vista não é apenas consultar dirigentes, mas ajudar o gestor a decidir onde intervir.
Outros critérios, como ordem alfabética ou número de módulos, permanecem acessíveis através de filtros.
Visão global vs. detalhe operacional
Alternativa: obrigar o gestor a interpretar a situação através da lista de dirigentes.
Decisão: adicionar uma camada de visualização agregada.
Trade-off: introduzir uma representação adicional dos mesmos dados aumenta a complexidade da interface.
Porquê: a lista responde à pergunta “quem?”, enquanto os gráficos respondem primeiro a “o que está a acontecer?”. As duas camadas servem momentos diferentes da tomada de decisão.
My Role
Fui Product Designer end-to-end, responsável pela definição da arquitetura de informação, modelo de estados e experiência dos quatro perfis.
O meu trabalho passou por transformar regras de negócio em comportamentos de interface: o que cada perfil pode ver, quando pode agir, que informação deve ser prioritária e como os diferentes estados devem ser comunicados.
Também documentei o handoff componente a componente, incluindo filtros, indicadores, CTAs e respetivas regras de negócio, para reduzir ambiguidades durante a implementação.
A principal preocupação transversal foi manter uma estrutura de produto comum, sem forçar uma experiência comum onde as tarefas eram diferentes.
Research & Insights
A descoberta foi orientada sobretudo pela análise do domínio, das regras de formação e da relação entre os diferentes estados do sistema.
O briefing definia os dados que deveriam estar disponíveis, mas não determinava como deveriam ser organizados nem qual deveria ser a ação principal de cada perfil.
Foi a partir dessa análise que surgiram algumas das decisões estruturais do produto.
01 — É um problema de priorização, não de exibição
Uma lista com nome, estado e progresso responde à pergunta “o que existe?”, mas não necessariamente à pergunta “onde devo agir?”.
Ao identificar a tarefa real do gestor — perceber quem está próximo de atingir a elegibilidade e requer potencialmente acompanhamento — a vista deixou de ser pensada como um relatório.
Decisão: transformar a informação de progresso num mecanismo de priorização.
02 — Progresso e elegibilidade são coisas diferentes
Um dirigente pode ter completado grande parte de um percurso e continuar sem poder avançar por faltar um requisito específico.
Representar estas duas dimensões como um único indicador criaria uma interpretação errada.
Decisão: manter progresso e elegibilidade como sinais independentes. O estado APTO / NÃO APTO aparece junto à progressão e, quando existem requisitos em falta, a interface comunica também o número exato de módulos necessários.
03 — O mesmo dado precisa de diferentes níveis de resolução
O dirigente precisa de detalhe para agir sobre o seu percurso. O gestor precisa primeiro de uma visão agregada para identificar onde deve concentrar a atenção.
Isto levou a uma abordagem de divulgação progressiva: mostrar primeiro os sinais necessários à decisão e deixar o detalhe disponível através da interação.
Decisão: desenhar diferentes níveis de informação sem duplicar o modelo de dados.
04 — Uma vista de gestão precisa de responder antes da interação
Na gestão de centenas ou milhares de dirigentes, abrir cada registo individualmente seria demasiado dispendioso cognitivamente.
A informação mais relevante tinha de estar disponível através de uma leitura rápida.
Decisão: usar indicadores visuais, estados e, posteriormente, uma camada de visualização agregada para permitir ao gestor compreender a situação global antes de aprofundar.
Competitors
Olhei para produtos de compliance e gestão de risco, categorias que enfrentam um problema semelhante: um único sistema precisa de servir utilizadores com diferentes níveis de responsabilidade sobre os mesmos dados.
O padrão mais relevante não foi visual, mas estrutural: separar a experiência operacional de quem executa da experiência analítica de quem supervisiona, mantendo um modelo de dados comum.
Foi esse princípio que apliquei à Cordilheira.
The Solution
A solução assentou numa estrutura comum de produto, com diferentes níveis de informação e interação consoante o perfil.
Layout de dois painéis na vista do dirigente
O painel de percursos e o catálogo de módulos coexistem no mesmo ecrã, mas funcionam como zonas distintas.
Esta decisão evita obrigar o utilizador a navegar constantemente entre vistas quando precisa de cruzar o percurso com os módulos disponíveis.
A mudança de contexto acontece dentro da mesma vista, e não através de uma nova navegação.
Divulgação progressiva
Percursos e edições de módulos expandem-se apenas quando necessário.
A lógica foi simples: consultar é frequente; inscrever é uma ação específica.
Por isso, a interface privilegia a leitura e o scanning no estado inicial e reserva o detalhe para o momento em que o utilizador demonstra intenção.
Progresso separado de elegibilidade
O progresso comunica quanto já foi concluído. O estado APTO / NÃO APTO comunica se o utilizador já pode avançar.
São sinais diferentes porque respondem a perguntas diferentes.
Quando existem requisitos em falta, o sistema apresenta o número de módulos necessários e mantém o CTA de inscrição inativo até que as condições sejam cumpridas.
Vista de gestão como ferramenta de priorização
A lista de gestão foi desenhada para permitir identificar rapidamente quem requer atenção.
Cada linha combina nome, estado e uma representação visual da progressão. O nível colapsado privilegia a proximidade ao próximo percurso; o detalhe pode ser expandido quando é necessária uma análise mais profunda.
A informação mais importante para o gestor passa, assim, de “quem está aqui?” para “quem está mais perto de avançar?”
Visualização rápida da informação
Numa fase posterior, surgiu uma necessidade adicional: permitir aos gestores compreender rapidamente o estado global da formação sem depender da leitura da lista.
A solução foi introduzir uma camada de visualização agregada, com gráficos que resumem a distribuição dos dirigentes por diferentes dimensões de formação. A vista apresenta, por exemplo, a distribuição de créditos e a situação dos dirigentes nos diferentes percursos, permitindo comparar rapidamente proporções e identificar desequilíbrios.
A decisão não foi adicionar gráficos apenas para aumentar a quantidade de informação disponível. Foi criar uma primeira camada de leitura que permitisse responder rapidamente à pergunta “qual é o estado geral?” antes de passar para “quem, concretamente, precisa de atenção?”.
Isto criou uma hierarquia natural: visão global → identificação de padrões → filtragem → análise individual → ação.
Sinais antes da interação
Cada módulo comunica a disponibilidade de edições antes de o utilizador tentar interagir com ele. Isto evita que o utilizador descubra apenas depois de entrar que não existem opções disponíveis.
O CTA de inscrição vive ao nível da edição e não do módulo, porque a ação concreta é sempre uma inscrição numa edição específica, com data, formato e localização definidos.
Learnings
Este projeto reforçou uma distinção que considero fundamental em produtos de gestão:
Desenhar para dados não é o mesmo que desenhar para decisões.
O briefing podia pedir uma lista de dirigentes, mas o trabalho real do gestor era decidir onde concentrar a atenção e quem poderia beneficiar de intervenção.
Essa diferença alterou a forma como estruturei a informação: primeiro a decisão que o utilizador precisa de tomar, depois os dados necessários para a suportar.
Também aprendi que dashboards não devem ser avaliados pela quantidade de informação que conseguem mostrar, mas pela rapidez com que permitem detetar um padrão, formular uma pergunta e decidir onde aprofundar.
Shout-outs
Obrigada a quem acompanhou este projeto e me obrigou a justificar cada decisão.
Foi esse processo de revisão que ajudou a transformar um conjunto de ecrãs num sistema com regras, estados e diferentes níveis de leitura.
