Plataforma de Gestão Académica e IA Jurídica
Uma plataforma construída de raiz, quatro perfis, um único sistema
LexKey é uma plataforma de gestão académica e IA jurídica construída de raiz para o ensino superior do Direito. Combina gestão da atividade letiva, uma biblioteca jurídica baseada em legislação real e um assistente de IA com citações rastreáveis.
O desafio estava em fazer estas áreas funcionarem como um único sistema para quatro perfis com responsabilidades distintas: Administrador da plataforma, Responsável de Instituição, Professor e Aluno.
Como Product Designer na AppX, participei na definição do próprio produto — desde a estrutura funcional e prioridades até aos modelos de interação e trade-offs — e desenhei a experiência end-to-end dos quatro perfis. Entre maio e agosto de 2026, entreguei mais de 30 protótipos de alta fidelidade, num produto ainda em implementação.
Um sistema preparado para crescer com o produto
LexKey encontra-se atualmente em fase de implementação, pelo que o impacto quantitativo ainda não está disponível.
O objetivo do trabalho de design foi estabelecer uma base capaz de absorver novas funcionalidades e perfis sem fragmentar a experiência. Os padrões definidos — componentes partilhados, grupos de permissões reutilizáveis, fluxos especializados de avaliação, IA com validação humana e citações contextuais — permitem construir novas experiências a partir de uma linguagem comum.
O próximo desafio não é adicionar mais ecrãs, mas preservar as relações entre eles à medida que o produto cresce.
Getting Started
LexKey reúne três áreas que tradicionalmente funcionam de forma independente:
- Gestão académica: unidades curriculares, calendário, aulas, trabalhos, provas escritas e orais por videochamada, correção, inscrições e permissões.
- Biblioteca Jurídica: legislação real, estruturada por artigo, com pesquisa, destaque e anotação.
- IA Jurídica: assistência baseada em fontes, com citações que permitem verificar a origem da informação.
As três áreas partilham os mesmos utilizadores, dados e regras, mas são utilizadas de forma diferente consoante o perfil.
O meu papel foi transformar requisitos, regras de negócio e necessidades do domínio num modelo de produto coerente e preparado para crescer.
Context
O domínio jurídico introduz uma complexidade que não pode ser tratada como simples conteúdo.
A legislação tem versões, estados de vigência, remissões entre artigos, diferentes tipos de diploma e jurisdições. Na Biblioteca Jurídica, estas relações têm de permanecer claras enquanto o utilizador interage diretamente com legislação real.
Em paralelo, a plataforma tinha de suportar toda a rotina académica: professores a criar e avaliar provas, alunos a submeter trabalhos, aulas síncronas, controlo de acessos e diferentes níveis de administração.
A principal constraint era, por isso, sistémica: não bastava desenhar boas experiências isoladas; regras, objetos e estados tinham de permanecer coerentes entre áreas e perfis.
The Challenge
O desafio central era desenhar um único sistema com quatro experiências diferentes, sem transformar cada perfil num produto independente.
Os quatro perfis partilham objetos e regras, mas têm responsabilidades distintas. Uma aula criada pelo Professor tem de produzir uma experiência coerente para o Aluno; uma permissão configurada pelo Responsável tem de produzir consequências previsíveis noutras áreas.
Algumas tarefas também não podiam ser resolvidas através de padrões genéricos.
Uma prova escrita parte de um documento produzido pelo aluno; uma prova oral baseia-se numa interação e numa grelha de critérios. Tratá-las como variantes do mesmo fluxo simplificaria a estrutura, mas prejudicaria a adequação à tarefa.
O problema era, portanto:
Como definir um modelo de produto que permita experiências diferentes sem perder coerência entre elas?
Trade-offs
Simplicidade imediata vs. escalabilidade
Alternativa: configurar permissões individualmente, ecrã a ecrã.
Decisão: grupos de permissões reutilizáveis.
Trade-off: maior complexidade inicial.
Porquê: reduz repetição e permite escalar regras entre instituições, turmas e avaliações.
Consistência vs. especialização
Alternativa: um único fluxo de correção configurável.
Decisão: fluxos distintos para provas escritas e orais.
Trade-off: maior complexidade estrutural.
Porquê: as tarefas, evidências e modelos mentais são diferentes.
Rastreabilidade vs. legibilidade
Alternativa: fontes permanentemente visíveis.
Decisão: citações contextuais em modal.
Trade-off: a fonte deixa de estar imediatamente exposta.
Porquê: mantém a verificabilidade sem tornar a resposta visualmente pesada.
Automação vs. responsabilidade
Alternativa: automatizar parte da avaliação.
Decisão: IA como apoio à decisão.
Trade-off: menor automação.
Porquê: o docente mantém a responsabilidade sobre a avaliação.
Estes trade-offs definiram não apenas a interface, mas o comportamento e a estrutura do produto.
My Role
Fui Product Designer end-to-end e participei também na definição do próprio produto.
Product definition
Ajudei a definir perfis, prioridades funcionais, estruturas de informação e modelos de interação, traduzindo regras de negócio e requisitos jurídicos em comportamentos de produto.
Product design
Desenhei os principais fluxos dos quatro perfis e modelei estados, dependências e edge cases para garantir consistência entre contextos.
Delivery
Produzi mais de 30 protótipos de alta fidelidade e documentei decisões, estados, tokens e pendentes para suportar a implementação.
Uma das decisões de produto em que tive maior envolvimento foi o modelo de permissões.
Em vez de configurações individuais, ecrã a ecrã, propus grupos de permissões nomeados e reutilizáveis. A abordagem aumentava a complexidade inicial, mas reduzia configuração repetitiva e criava uma estrutura mais preparada para escalar.
Research & Insights
A descoberta foi orientada pela análise do domínio, exploração de referências e revisão contínua com especialistas jurídicos.
01 — A Biblioteca não é apenas uma fonte
Destaques, remissões e anotações pareciam inicialmente funcionalidades independentes. A análise das suas relações mostrou que dependiam do contexto da Biblioteca Jurídica e da própria estrutura da legislação.
Decisão: tratar a anotação como parte do modelo da Biblioteca, e não como uma funcionalidade genérica de qualquer fonte.
02 — Avaliação escrita e oral são tarefas diferentes
Uma prova escrita parte de um documento que pode ser anotado e avaliado diretamente. Uma prova oral parte de uma interação e de uma grelha de critérios.
Decisão: dois fluxos especializados, em vez de um único fluxo configurável.
03 — O modelo mental jurídico é estrutural
A organização do Direito é hierárquica, numerada e relacional. Uma lista plana de permissões não comunicava adequadamente estas relações.
Decisão: estruturar permissões através de grupos e dependências hierárquicas.
04 — O maior risco estava entre os perfis
Com quatro perfis a trabalhar sobre os mesmos objetos, consistência não significava apenas reutilizar componentes.
Uma aula criada pelo Professor tinha de ser reconhecível pelo Aluno; uma permissão configurada pelo Responsável tinha de produzir consequências previsíveis.
Decisão: tratar consistência como uma propriedade do sistema, e não apenas da interface.
Competitors
A Harvey.ai serviu como benchmark para uma questão específica: como estabelecer credibilidade numa experiência de IA jurídica através de respostas fundamentadas e ligação verificável às fontes.
LexKey tinha, contudo, uma necessidade mais abrangente: integrar IA numa plataforma académica onde a decisão final continua a pertencer ao docente.
A IA deve aumentar a capacidade de decisão do utilizador, não substituir a responsabilidade de quem decide.
The Solution
A solução assentou num conjunto de padrões partilhados, sem eliminar as especificidades de cada contexto.
Um sistema de design transversal
Criei uma linguagem visual partilhada entre os diferentes contextos, com componentes e padrões consistentes. O sistema permitiu manter uma experiência reconhecível entre perfis sem obrigar todas as tarefas a utilizar os mesmos padrões.
Permissões como sistema, não como configuração de ecrãs
As permissões foram estruturadas em grupos nomeados e reutilizáveis.
As dependências são refletidas na interface: quando uma funcionalidade principal é desativada, as opções dependentes são automaticamente desativadas e visualmente secundarizadas.
Correção especializada
Na prova escrita, o documento entregue pelo aluno ocupa o centro da experiência, permitindo anotação diretamente sobre o conteúdo.
Na prova oral, a interface centra-se numa grelha de critérios, adequada a uma avaliação baseada em desempenho e observação.
Cada fluxo representa um modelo de avaliação diferente.
Videochamada com controlo antes da entrada
As aulas síncronas começam numa sala de espera onde o utilizador pode verificar câmara e microfone antes de entrar.
O padrão, familiar de ferramentas como Zoom ou Google Meet, reduz incerteza e dá ao utilizador controlo antes de iniciar a aula.
IA com responsabilidade humana
A IA foi desenhada como suporte à decisão.
Pode sugerir uma avaliação fundamentada, mas o professor mantém o controlo: pode aceitar, ajustar ou rejeitar a sugestão.
IA propõe. Docente valida.
Citações sem sacrificar legibilidade
Optei por citações contextuais em modal, mantendo a rastreabilidade acessível sem comprometer a leitura da resposta.
Legislação como conteúdo estruturado
A Biblioteca Jurídica trabalha diretamente sobre legislação real, organizada por artigo, permitindo destacar e anotar o texto no próprio contexto em que está a ser consultado.
Learnings
O principal ponto que mudaria seria envolver docentes reais mais cedo.
Os juristas foram fundamentais para validar terminologia e regras, mas conhecimento especializado e comportamento de utilização são dimensões diferentes.
Conhecimento especializado é necessário para validar o modelo, mas não é suficiente para validar a experiência.
Também teria definido métricas de sucesso mais cedo. Perguntar desde o início “como vamos saber que esta solução funciona?” teria permitido transformar algumas decisões em hipóteses testáveis.
Um erro concreto reforçou esta aprendizagem. Implementei inicialmente elementos de anotação debaixo de todas as fontes, quando essa interação só fazia sentido dentro da Biblioteca Jurídica.
O erro foi corrigido e revelou um princípio que levo deste projeto: consistência não significa aplicar o mesmo padrão em todo o lado; significa aplicá-lo onde o modelo de produto o suporta.
Shout-outs
Obrigada à equipa da AppX pela colaboração e pelo rigor ao longo do projeto.
A revisão contínua com a equipa e com especialistas de domínio foi essencial para transformar requisitos complexos num sistema mais consistente, compreensível e preparado para implementação.
