2025
Product Designer @ netLex, pela Atomsix
Uma plataforma jurídica mostrava a estrutura da ferramenta. O redesign passou a mostrar o trabalho de cada área.
Jurídico, Comercial e RH usam a mesma base sem virar três produtos, e a IA recomenda a próxima ação em cada etapa do contrato.
Meu papel
Product Designer na Atomsix. Discovery, arquitetura de informação, onboarding, gestão do contrato com ações recomendadas pela IA e as telas finais.
A netLex é uma plataforma de gestão jurídica e de contratos. Departamentos jurídicos, comerciais e de RH usam o produto para documentos, workflows, consultas, procurações e atas. O projeto foi um redesign do web app: discovery, benchmark, sitemap e quatro iterações de interface até a versão final.
Se você ler só uma parte
O produto se organizava por pastas, abas e listas. A jornada de cada área não aparecia, e o contrato era um documento cru, sem responsável, prazo nem próximo passo.
O que eu fiz foi reorganizar o produto pelo trabalho de cada área: Spaces com home própria, um onboarding que monta essa home e uma ação recomendada pela IA para guiar a tomada de decisão no contrato.
O resultado é uma base só para áreas diferentes, com vencimentos e gargalos visíveis desde a home e um contrato que mostra em que etapa está e qual é a próxima ação.
O problema
A interface falava a língua da ferramenta, e não a de quem usa.
- A navegação seguia a estrutura do sistema: pastas, abas genéricas e documentos em lista.
- O detalhe do contrato era o documento cru, sem responsáveis, prazos nem próximo passo.
- Jurídico, Comercial e Compras têm jornadas diferentes, e o produto tratava todos igual.
- Vencimentos, SLAs e gargalos ficavam escondidos dentro das listas.
A tentação era redesenhar tela por tela. O que o produto precisava primeiro era entender o trabalho de cada área.
Por onde comecei
01.
O que cada área precisa ver quando abre o produto?
02.
Como atender áreas diferentes sem criar três produtos?
03.
Como guiar a decisão de quem não sabe qual ação tomar em cada etapa do contrato?
04.
Como o produto aprende quem é o usuário sem um cadastro cansativo?
O que eu fiz no discovery
Mapeei o trabalho de cada área antes de mexer na interface.
Escrevi os jobs to be done e as jornadas de três áreas, cada uma com etapas, ações e resultado esperado. O Jurídico vai da revisão interna à aprovação, assinatura, armazenamento, monitoramento e relatórios. O Comercial vai da criação à negociação externa e ao pós-assinatura. Compras acompanha contratos, vencimentos e alertas. Cada jornada virou um fluxo proposto, do login até a ação.
Usei o benchmark para separar o que é estrutura do que é caso de uso.
O Monday e o Asana mostraram como um mesmo produto organiza workflows diferentes por caso de uso. O Ironclad foi a referência direta de gestão de contratos jurídicos, com repositório e dashboard. Daí saiu a decisão de arquitetura: módulos comuns para todos, e Spaces por área por cima deles.
Transformei os achados em insights por módulo.
Para cada parte do produto, escrevi o que mudar. A home passa a mostrar o status que importa para cada área: Compras vê o que vai vencer, o Jurídico o que está em revisão, o Comercial o que está perto de fechar. Os filtros por perfil vão para o primeiro plano. E o documento ganha um painel de próximo passo.
O que eu fiz no produto
Desenhei um onboarding que monta o produto para cada pessoa.
Em vez de um cadastro genérico, o onboarding pergunta cinco coisas: o cargo, o departamento, os principais casos de uso, como a empresa chama os tipos de documento e quais indicadores a pessoa acompanha. A taxonomia já vem com sugestões, e dá para pular uma etapa e voltar depois. No fim, o produto configura a home daquele Space com os indicadores escolhidos.
Organizei o produto em Spaces por área.
Cada área tem seu Space, com home própria, sobre módulos comuns: Workflow, Documentos, Contatos, Intel e Configurações. Os Spaces abrem como abas de navegador, e quando as abas estouram a largura, aparece uma busca para achar as escondidas. Na home, as métricas mostram o que vence hoje e o SLA, com a variação contra o mês anterior.
Escrevi as regras do grid da home.
Para a mesma home servir a áreas diferentes sem quebrar, defini regras para cada bloco. A linha de ações tem de um a quatro itens e não pode ser ocultada. As métricas usam três ou quatro colunas, com um ou dois números grandes, e também não podem ser ocultadas. Contatos, documentos e atividades usam uma ou duas colunas e podem ser escondidos. As regras ficaram em post-its no próprio Figma, ao lado das telas.
Fiz a lista de documentos mostrar onde cada um está.
O repositório ganhou uma árvore de pastas, busca pelo conteúdo do documento e, em cada linha, o autor, a pasta e a etapa do workflow. Antes, a lista era genérica. Agora ela responde em que pé está cada documento sem precisar abrir.
Coloquei a IA para recomendar a próxima ação em cada etapa do contrato.
Foi comentado que o usuário não sabia qual ação deveria tomar naquela etapa do contrato. A gestão do contrato ficou mais enxuta: um stepper com as etapas, de elaboração a negociação, aprovação financeira e assinatura, as abas do contrato e o botão Ações Recomendadas, em que a IA sugere o próximo passo da etapa atual para guiar a tomada de decisão. As ferramentas ficam numa barra flutuante. Foram três rodadas de layout até chegar aqui, e o painel continuou abrindo à direita, como no produto atual, para não quebrar o hábito de quem já usava.
O que mudou
O produto passou a se organizar pelo trabalho de cada área, e não pela estrutura da ferramenta.
A mesma base atende Jurídico, Comercial e RH. O onboarding configura a home de cada perfil. A lista de documentos mostra a etapa de cada um. E, no contrato, a IA recomenda a próxima ação de cada etapa.