Case · Replataforma · Legaltech
Amplitude
sem labirinto.
Um escritório de advocacia full-service tinha 87 telas e 53 itens de menu — e um quarto da plataforma não era alcançável por nenhum caminho da interface. A proposta cabe a mesma capacidade em cerca de 40 telas e 29 itens, sem remover uma única função.
01 · Contexto
Um produto all-in-one que ninguém conseguia atravessar.
A plataforma fazia tudo que um escritório precisa. O problema nunca foi o que faltava — era encontrar.
O LegalDock é a plataforma de gestão do Plaça Advocacia: casos, prazos, clientes, documentos, funil comercial, financeiro, atendimento por WhatsApp e um portal próprio para quem é atendido. A amplitude é o argumento comercial do produto, e ela é real. O diagnóstico que originou este trabalho, porém, mediu o custo dela: 87 telas, 53 itens de menu, 21 rotas que existiam no código e não apareciam em lugar nenhum do menu, e quatro botões que abriam tela vazia sem erro nem aviso.
Havia ainda um ativo construído e invisível. O ciclo de IA com aprovação humana — fila por nível de risco, agentes versionados, custo por execução — já estava implementado em seis telas, todas dentro da área de administração do sistema. Nenhuma delas chegava ao advogado como produto. Era a promessa de valor da plataforma morando num endereço de manutenção.
02 · Desafio
"All-in-one" e "simples" puxam para lados opostos.
A pergunta que organiza o projeto inteiro: como manter a amplitude e reduzir a superfície? Cinco problemas estruturais responderam por quase toda a confusão medida.
Um quarto era invisível
21 rotas existiam no código e não tinham entrada no menu. Quem não conhecesse a URL não chegava lá — e quem conhecesse não sabia se aquilo era produto ou rascunho.
Dois financeiros sobre a mesma base
20 telas de Financeiro, com dois sistemas concorrentes lendo os mesmos dados e seis lugares diferentes reportando custo. Metade da área era inalcançável.
Três WhatsApps, um atendimento
Três interfaces de conversa, três balões de mensagem e três compositores de texto para a mesma tarefa — além de outras três escondidas em rotas de desenvolvimento.
Três nomes para o mesmo objeto
Processos, Matérias e Casos eram a mesma coisa do mundo real, em telas diferentes e com dados diferentes. Cliente aparecia como Cliente 360, Clientes e Clientes Asaas.
Estados que ensinam a desconfiar
O briefing gerado por IA dizia apenas "não foi possível gerar", sem motivo e sem ação. "Novo cliente" abria uma tela em branco — o pior estado possível, porque não parece erro nem sucesso.
Nenhum sistema de design
Seis componentes de upload, seis tabelas financeiras com colunas parecidas, dois sinos de notificação e nenhum seletor de data comum — os formulários usavam o campo nativo do navegador, que muda de aparência e de idioma por sistema operacional.
03 · Estratégia e mapeamento
Consolidar antes de desenhar.
Antes de qualquer tela nova, o trabalho foi de produto: medir a redundância, decidir o destino de cada rota órfã e reagrupar a navegação por trabalho, não por módulo. A tabela abaixo é o alvo que orientou tudo o que veio depois.
| Diagnóstico | Proposta | |
|---|---|---|
| Telas | 87 | ~40 |
| Itens de menu | 53 | 29 · 21 painel + 8 portal |
| Rotas fora do menu | 21 | 0 |
| Telas de Financeiro | 20 | 7 |
| Interfaces de WhatsApp | 3 (+3 ocultas) | 1 |
| Telas que listam clientes | 6 | 2 |
| Lugares que reportam custo | 6 | 1 |
| Componentes de upload | 6 | 1 |
| Botões sem destino | 4 | 0 |
A ordem de ataque saiu da relação entre esforço e impacto, e começou pelo que não dependia de decisão estratégica: corrigir os quatro caminhos quebrados, proteger as rotas de desenvolvimento e unificar a nomenclatura são correções, não escolhas. As decisões caras — consolidar o Financeiro, escolher uma interface de WhatsApp, unificar o conceito de cliente — vieram depois, cada uma com a alternativa descartada registrada por escrito.
04 · Decisões de design
Catorze decisões, cada uma com a alternativa descartada.
Toda escolha estrutural virou registro: contexto medido, decisão em uma frase, consequências — inclusive as ruins — e o motivo de cada alternativa recusada. Decisão revogada não é apagada: muda de status e aponta para quem a revogou. Foi o que aconteceu com os honorários.
- 01
O Dock substitui o menu lateral
A navegação era uma barra encostada na borda, idêntica à de qualquer painel administrativo. Virou uma peça flutuante em vidro com dois cortes: um trilho com os seis grupos como ícone e um painel de nomes que abre no grupo da rota atual. O trilho carrega grupos e não os 21 itens porque 21 alvos de 44px passam de 900px de altura — mais que a área útil de um notebook.
- 02
Espiar sem sair do lugar
Passar o ponteiro por outro grupo pré-visualiza o conteúdo dele sem navegar; tirar o ponteiro volta ao grupo atual. É o gesto que elimina o clique a mais que um menu de dois níveis cobra. As tooltips foram removidas: ficavam três abertas ao mesmo tempo, tapando justamente os ícones que nomeavam. O nome continua no DOM para leitor de tela.
- 03
O vidro é material, não efeito
Uma única classe, usada por apenas dois objetos — o Dock e o Oráculo. Card, tabela, painel e diálogo continuam opacos. Sem suporte a desfoque, ou com redução de transparência ativada no sistema, ela cai para superfície opaca: perde-se o efeito, não a leitura.
- 04
A IA é camada, não widget
O Oráculo flutua em toda rota das duas áreas e responde de qualquer tela. O que o separa de um chatbot é o formato da resposta: uma frase curta, os registros que ela resume — cada um clicável — e o caminho para abrir tudo. Parágrafo é o que um chat devolve; destino é o que um sistema devolve.
- 05
Consulta, não age — e fonte é obrigatória
O Oráculo não escreve nada. Quando a resposta lista registros, a fonte é obrigatória: é o que separa resposta de palpite para quem lê um assistente jurídico. Pergunta não reconhecida devolve recusa, não chute. E ele passa pelo mesmo filtro de permissões do Dock — responder "encontrei 4 processos com prazo amanhã" a quem não pode ver processos vaza a existência deles.
- 06
Permissão por ação, não por área
Dar acesso a "Financeiro" é grosso demais para um escritório onde o estagiário lança despesa e só o sócio aprova repasse. A autorização passou a ser por ação, e a camada de interface apenas esconde item de menu — nunca é a proteção, que é decidida no servidor.
- 07
Todo estado vazio responde três coisas
O que aconteceu, por quê e o que fazer agora. Um vazio de segundo nível — a lista existe, o filtro é que não achou — é um estado diferente de "não há registro", e dizer a mesma frase nos dois casos manda a pessoa procurar o que não existe.
- 08
Honorários mudou de casa, e o registro ficou
A primeira decisão colocou honorários dentro de Contratos. Quatro dias de uso do protótipo mostraram que honorário é evento de receita, não cláusula: virou aba de Receita & Cobrança. A decisão antiga permaneceu no registro, marcada como revogada e apontando para a que a substituiu.
05 · Da estratégia à experiência
Protótipo navegável, não tela estática.
A proposta não foi apresentada em telas soltas. Foi construída como produto que se abre no navegador e se atravessa de ponta a ponta.
A fase de design fechou com 35 telas construídas e 36 contratos de dado. Cada tela nasce com os quatro estados — dados, carregando, vazio e erro com repetição — e o protótipo expõe um seletor de estado visível, para que qualquer um deles possa ser demonstrado numa reunião sem simulação de falha. Toda string passa pela camada de tradução, em português e inglês, no mesmo commit.
A fronteira entre design e desenvolvimento é física, não combinada: nenhuma tela faz requisição, lê variável de ambiente ou chama ação de servidor — toda integração mora numa camada separada, e um verificador no CI reprova o pull request se a regra for quebrada. É o que permite que uma tela aprovada vire tela integrada em horas, em vez de virar retrabalho.
06 · Inteligência com dono
Quem aperta enviar?
O modelo inteiro de IA do produto cabe nessa pergunta. A resposta é um desenho de produto, não um recurso de modelo: o risco decide se o agente age sozinho ou se existe um passo humano obrigatório.
O risco decide o caminho
Risco zero envia sozinho. Risco um, dois ou três vai obrigatoriamente para a fila de aprovação, onde uma pessoa aprova ou recusa. A interface nunca envia sem passo humano acima de risco zero.
Parada é informação, não falha
Um agente de risco zero pode parar por conta própria quando o erro seria irreversível — por exemplo, ao identificar um prazo fatal. Quando isso acontece, a tela mostra o motivo da parada em vez de escondê-lo num log.
Rascunho não é mensagem
O que o agente produz vive na fila, nunca na conversa. Só depois da aprovação humana vira mensagem enviada, e ela carrega a marca de quem a gerou. Misturar os dois faria o cliente ler como enviado algo que ninguém conferiu.
O ciclo sai da administração
A decisão de maior impacto comercial e menor custo do diagnóstico: tirar a fila de aprovação da área de manutenção e desenhá-la como tela central do produto. O que já estava construído passou a ser o que o advogado vê.
07 · Em destaque
O que a consolidação liberou.
Reduzir superfície não foi cortar função. Foi juntar o que já existia espalhado e devolver cada capacidade num endereço só.
Financeiro em sete telas
As 20 telas viraram 7, com abas coerentes e os cadastros fora do menu principal. A regra prática que organizou a área: no máximo dois níveis dentro de uma tela — a terceira camada de abas simplesmente sumia da vista.
Um cálculo com consequência contábil
A classificação de risco dos casos define o que entra no resultado do escritório e o que fica de fora. "Possível" não é meio provável: não existe provisionar metade, e um número intermediário inventaria um grau que a norma não tem. A interface reflete os três graus, sem meio-termo.
Prazo fatal em cor e em texto
Irreversível ao perder, então nunca sinalizado só por cor — quem não distingue as cores precisa da mesma informação. E prazo fatal sem data não existe: se vier assim da origem, é defeito, e o contrato de dado recusa.
Atendimento em tela cheia
Conversar com um cliente não é consultar um painel: é o trabalho inteiro naquele momento. O atendimento virou espaço de trabalho, com a navegação saindo de cena — e passou de três interfaces concorrentes para uma.
Duas áreas, uma porta
O painel do escritório e o portal do cliente compartilham a entrada, e a área é resolvida depois da verificação — quem sabe a qual área um e-mail pertence é o cadastro, não a pessoa na porta.
Andaime com cara de andaime
Os atalhos de demonstração do login têm contorno tracejado, superfície afundada e um selo "Protótipo". Andaime com a mesma aparência do produto é andaime que alguém confunde com produto — e é assim que ele fica para sempre.
08 · Impacto e aprendizados
O que o protótipo permite testar.
Nenhum número aqui é resultado de produção. São hipóteses que o protótipo torna verificáveis antes de custar desenvolvimento.
A primeira hipótese é de alcance: se a mesma capacidade cabe em 29 itens de menu em vez de 53, um advogado autônomo — que não tem quem o treine — consegue atravessar a plataforma sozinho. Isso é testável com qualquer pessoa diante do protótipo, sem back-end, e era intestável enquanto a proposta fosse um documento.
A segunda é de valor percebido: promover o ciclo de IA de área de manutenção a tela central muda o que o produto parece ser na primeira sessão. O diagnóstico aponta essa como a mudança de maior impacto comercial e menor custo — a afirmação continua sendo uma hipótese do documento, e não um resultado medido.
O aprendizado mais útil foi sobre forma de registro. Catorze decisões escritas com a alternativa descartada mudaram a natureza das reuniões seguintes: em vez de reabrir a escolha, a conversa passou a ser sobre o que muda se o cliente preferir o contrário — que é a informação de que quem implementa realmente precisa.
09 · Conclusão
Reduzir superfície é trabalho de produto.
Nenhuma função foi removida. O que mudou foi quantos caminhos levam ao mesmo lugar, e quantos não levam a lugar nenhum.
A parte difícil deste projeto não foi desenhar o Dock nem o Oráculo. Foi decidir, uma a uma, o destino de 21 rotas órfãs, escolher uma palavra para cada conceito e aceitar que consolidar o Financeiro custava caro e precisava ser feito mesmo assim. Essas decisões não aparecem numa tela — aparecem na ausência de confusão.
O protótipo entregou o que uma apresentação de telas não entrega: a possibilidade de atravessar as duas áreas, bater nos estados de erro, abrir a fila de aprovação e discordar com o produto na frente. A fase de desenvolvimento começou com as telas já existindo, os contratos de dado já escritos e as decisões já registradas — que é a única forma de uma proposta sobreviver ao contato com a implementação.