Resumo
O Forge é uma plataforma em que times montam, num editor visual, os fluxos que recebem documentos e extraem os dados deles. Esses dados viram insumo para dashboards, análises e material interno.
Fui o product designer do produto, ao lado de três desenvolvedores. Desenhei o design system sobre a base do SDK, os componentes do editor e os temas claro e escuro.
Hoje o Forge atende uma grande rede de hospitais, nas áreas de logística e compras.
- Papel
- Product Designer
- Time
- Daniel Carnelossi, Luiz Favaro e Caio Vallio
- Duração
- 6 meses, em andamento
- Entregas
- Design system sobre a base do SDK
- Componentes do editor de workflows
- Tema claro e escuro
Problema
A base técnica existia. A experiência era genérica.
O Forge é construído sobre um SDK de workflow builder. A base técnica existia, mas a experiência ainda era a de uma ferramenta genérica.
Uma ferramenta sem identidade
O editor funcionava, mas ainda não tinha uma linguagem própria da Intus.
O produto vive em código
As decisões de design precisavam caber no que o SDK permite customizar.
Oportunidade
Dar ao editor uma linguagem própria, sem desenhar telas que o código não sustenta.
Em vez de telas, um sistema
A base é o design system do próprio SDK, customizado para a Intus e aplicado diretamente sobre o código.
Um editor previsível
Os mesmos estados em todos os nós, para o editor responder igual em qualquer ponto do fluxo.
Para quem
Quem monta o fluxo e quem usa o dado
Times montam os fluxos no editor visual. A partir da extração, os dados chegam a quem decide, na forma que a empresa precisar: dashboards, análises e material interno.
Pesquisa
Questionar o problema antes do produto
Comecei listando os problemas de quem lida com volume de documentos e, para cada um, uma solução possível e as perguntas em aberto. Isso se organizou em seis temas: configurabilidade, funcionalidade, compartilhamento, personalização, métricas e integração.
Depois analisei oito produtos próximos, do Brasil e de fora, com os mesmos critérios, registrando o que seguir e o que evitar. Por fim, mapeei os setores onde o Forge poderia atuar.
Decisões de design
Do token ao editor
Tokens antes de telas
Tokens primitivos e semânticos sustentam os dois temas. Qual tema fica ativo depende do cliente e do ambiente de implantação.
O nó como unidade
Cada etapa do workflow é um nó: início, etapa, decisão e agente de IA. Todos foram desenhados com os mesmos estados: padrão, hover, selecionado, alerta e desabilitado.
O editor por inteiro
Barra superior, paleta de componentes, painel de propriedades e canvas. A estrutura do editor também virou componente, para manter a consistência conforme o produto cresce.
Resultado final
Da fila de revisão à resposta da IA
Desfecho
Uma rede de hospitais usando o fluxo
A rede tinha problemas de organização e de controle da duração dos contratos, que geravam uma perda milionária por ano. As análises feitas no Forge corrigiram esses problemas.
O fluxo agora é mais automático, e os analistas da rede estão sendo treinados na ferramenta para mapear novos fluxos por conta própria. Nesse cliente, só o tema claro está ativo.
Telas e dados deste case são fictícios, recriados para preservar a confidencialidade do cliente.
Reflexões
O que eu faria diferente
Trabalhar sobre um SDK mudou a ordem do meu processo: primeiro entender o que o código sustenta, depois desenhar. Duas decisões eu tomaria de outro jeito.
Começaria por um tema só
Desenhei os temas claro e escuro ao mesmo tempo, e a rede de hospitais usa só o claro. Hoje fecharia um tema com o cliente em produção e abriria o segundo quando alguém precisasse dele.
Levaria o editor antes a quem monta os fluxos
Os analistas da rede estão aprendendo a mapear fluxos agora, com o produto pronto. Hoje colocaria o editor na mão deles nas primeiras versões dos nós, para ajustar o que confunde antes de virar treinamento.