Processo valida arquitetura de produto antes do desenvolvimento

O problema e o processo

Em um artigo no Mind the Product, Andrii Zabluda, Product Designer da Kinertic, descreve o processo interno que moldou o Trade Flow Builder, módulo da plataforma de relatórios e insights comerciais para commodities diferenciadas por emissões. O módulo permite mapear como um produto percorre uma cadeia de suprimentos multinível e calcula a intensidade de carbono em cada etapa. O contexto de negócio é concreto: empresas de óleo, gás e metais precisam contabilizar a intensidade de carbono para atender regulações emergentes como o EU Methane Regulation (EUMR) e o Carbon Border Adjustment Mechanism (CBAM), e modelar a cadeia permite antecipar custos regulatórios e construir fluxos mais competitivos.

Como startup em estágio inicial sem base de usuários ativa, a Kinertic trata o processo de produto como disciplina própria: um erro de arquitetura em módulo central pode custar semanas de trabalho desviado, e a proteção é a estrutura da decisão, não a intuição.

Fast-Ideation e pre-reads

O processo interno, chamado Fast-Ideation, exige que toda decisão relevante de produto passe por três filtros antes de entrar no backlog: expertise de domínio, viabilidade técnica e cenário de market fit - com os responsáveis por cada filtro presentes na discussão. Antes da primeira sessão de ideação de um novo módulo, o CTO e o Product Manager preparam um pre-read: um documento de uma a duas páginas em Notion com cenários de negócio, conhecimento de domínio e restrições técnicas, compartilhado dias antes da reunião. O efeito mais visível é no segundo nível: uma discussão que exigiria três reuniões passa a acontecer em uma, porque o alinhamento de contexto já ocorreu. O pre-read não é feito para toda reunião - apenas a primeira de cada módulo - e depois vive como artefato atualizado; ele fornece base informacional, não propõe solução.

O papel do designer é duplo: levar conceitos lo-fi (esboços em FigJam ou Excalidraw, deliberadamente pouco detalhados, para a discussão focar na lógica estrutural) e traduzir os resultados em especificações que consideram os esquemas de dados da engenharia. Único designer em um time majoritariamente de engenharia, Zabluda descreve a especificação como um blueprint de trabalho, não uma proposta visual.

O prototype descartado

A primeira versão do Trade Flow Builder era um híbrido: mapa com os ativos disponíveis (refinarias, portos, terminais, aeroportos), uma barra lateral deslizante para configurar o fluxo de comércio e uma tabela resumo abaixo. A escolha parecia razoável - o contexto logístico vive no mapa, e o padrão lateral era familiar de produtos como Google Maps.

A fricção apareceu ao percorrer cenários em detalhe. Nas referências, a barra lateral servia como resumo de dados; no caso da Kinertic, ela deveria ser um espaço de configuração profunda de uma estrutura multinível, com múltiplos trechos logísticos (modo de transporte, tipo de produto, combustível) por fluxo. Dentro de um painel vertical estreito, sem representação visual do todo, o usuário perdia o rastro dos segmentos. Além disso, colocar mapa, tabela e configurador na mesma tela conflitava duas tarefas distintas - monitorar ativos e modelar estrutura - aumentando a carga cognitiva e reduzindo a eficiência de ambas.

Pelos três filtros do Fast-Ideation, essa conclusão chegou antes de qualquer engenharia, o que segundo o autor provavelmente poupou duas a três semanas de desenvolvimento na arquitetura errada. A resposta não foi revisar a barra lateral, mas mudar a arquitetura do recurso.

Do domínio à árvore

A estrutura do canvas veio do domínio, não da interface. Trabalhando com stakeholders, o time chegou ao conceito de crude slate: a mistura de tipos de petróleo bruto que uma refinaria processa em proporções fixas, da qual o produto final herda uma pegada média ponderada. Essa lógica de consolidação se repete na cadeia - um aeroporto abastecido por várias refinarias gera nova consolidação. Conclusão: um fluxo de comércio não é uma linha, mas uma estrutura em árvore com relações muitos-para-um; representá-lo como sequência linear o distorce.

No canvas final, ativos viram nós, trechos logísticos viram conexões, e a configuração de um elemento individual abre na barra lateral - no papel que ela realmente comporta. A base técnica é React Flow, escolhida por gerenciar a posição dos nós a partir da estrutura de dados, garantindo consistência visual e um modelo de estado gerenciável. Como consequência não planejada, a representação em árvore permite ver diretamente como a mistura de lotes afeta a intensidade de emissões do produto final - transformando o módulo em ferramenta de conformidade com EUMR e CBAM sem feature separada.

Lições e ressalvas

O princípio central: tanto a arquitetura da interface quanto a do processo devem seguir a estrutura do domínio, não ser impostas de cima. Práticas como pre-reads e validação lo-fi não são modelos universais - funcionam quando se encaixam na tarefa. Em produtos DeepTech B2B, o papel do designer se estende ao pensamento em sistemas: alinhar modelo de domínio, modelo de dados e modelo de interação em um artefato coerente, antes da primeira linha de código.

O autor faz uma ressalva honesta: não havia usuários reais para validar, e o rigor do processo interno substituía o loop de feedback externo. O ganho principal do pre-read foi reduzir o atrito entre engenharia, designer e time fundador; a migração para o canvas foi bem recebida internamente porque melhorou a experiência de construir fluxos manualmente.