Dívida de Design em Produtos de IA: Quando a Interface Define o Que o Usuário Acredita

A pesquisa da Forrester de 2025 revelou que 75% dos líderes de tecnologia esperam que a dívida técnica atinja severidade moderada ou alta até 2026, impulsionada pela complexidade da IA. Não existe pesquisa equivalente para dívida de design. Ninguém rastreia. Ninguém orça. Ninguém reporta ao conselho.

Essa ausência é a história.

Arin Bhowmick, Chief Design Officer da SAP (anteriormente IBM e Oracle), publicou um ensaio em março de 2026 argumentando que a dívida de design se tornou tão perigosa quanto a dívida técnica. Seu argumento carrega peso por onde ele se posiciona. Não é um designer reclamando de consistência de pixels. É um executivo C-level de uma das maiores empresas de software corporativo do mundo dizendo: temos um problema estrutural, e não estamos medindo.

O Que é Dívida de Design

Dívida técnica tem uma definição limpa. Você tomou um atalho no código. Sabe que o atalho existe. Pode estimar o custo para corrigi-lo. Dívida de design é mais turva. Acumula quando times tomam decisões de interface sob pressão, sem princípios ou sem propriedade. Padrões inconsistentes. Modelos de interação conflitantes. Navegação que fazia sentido para três funcionalidades, mas colapsa em trinta.

Já escrevemos sobre dívida cognitiva na engenharia: o custo invisível que se acumula quando times perdem a compreensão de seus próprios sistemas gerados por IA. Design tem sua própria versão, e é menos visível. Dívida cognitiva se esconde na cabeça dos engenheiros. Dívida de design se esconde na experiência dos usuários que não conseguem articular por que o produto parece errado.

A formulação de Bhowmick é precisa: a dívida de design “não se anuncia, mas fica ali, silenciosamente, por baixo de cada decisão de produto que você toma.” Dívida técnica se anuncia. Builds quebram. Testes falham. Performance degrada. Dívida de design é mais silenciosa. Usuários abandonam o produto. Adoção estagna. Tickets de suporte se multiplicam. As métricas se movem na direção errada, mas ninguém conecta isso ao peso acumulado de mil pequenos compromissos de interface.

Por Que Produtos de IA São Diferentes

Em software tradicional, dívida de design causa fricção. Em um produto de IA, dívida de design molda crença.

Essa é a observação mais afiada de Bhowmick. Quando um produto de IA apresenta uma recomendação, a interface determina se o usuário a trata como sugestão ou como diretriz. Quando um sistema de IA exibe um score de confiança, o tratamento visual determina se o usuário entende a incerteza ou a ignora. Quando uma ferramenta de IA automatiza uma decisão, o padrão de interação determina se o usuário mantém agência ou a entrega.

“Em um produto de IA, [decisões de design] moldam o que as pessoas acreditam,” escreve Bhowmick. Um indicador de confiança mal projetado não cria apenas uma UX ruim. Cria confiança descalibrada. Uma recomendação sem contexto não frustra apenas usuários avançados. Ensina a todos que outputs de IA chegam sem explicação e devem ser aceitos sem questionamento.

Isso é território de governança. Já argumentamos que design sem governança é decoração. O inverso também é verdadeiro: design sem governança em produtos de IA é desinformação ativa sobre o que o sistema sabe e o que não sabe.

A Síndrome do Sem Dono

Bhowmick identifica um padrão que chama de “síndrome do sem dono.” Em organizações construindo produtos de IA com múltiplos times, a dívida de design se acumula mais rápido nos espaços entre fronteiras de propriedade. Time A constrói a interface de entrada. Time B constrói a lógica de processamento. Time C constrói a exibição de saída. Ninguém é dono da experiência ponta a ponta.

Cada time otimiza localmente. O time de entrada cria um formulário limpo. O time de processamento constrói modelos confiáveis. O time de saída projeta visualizações claras. Mas as costuras entre esses componentes são onde a dívida de design se acumula. O formulário promete precisão que o modelo não consegue entregar. A visualização implica certeza que o processamento nunca reivindicou. O usuário interpreta essas contradições como o produto mentindo para ele.

Em software tradicional, problemas de costura causam confusão. Em software de IA, problemas de costura causam confiança descalibrada ou ceticismo injustificado. Ambos são falhas de governança.

Gosto Como Camada de Governança

Joshua Leigh, escrevendo na mesma semana que Bhowmick, publicou um argumento complementar sobre gosto. Sua tese: conforme a IA remove fricção de produção, a capacidade de produzir deixa de ser o diferencial. Julgamento é.

Leigh cita Brian Eno: “Quando você remove todas as restrições das pessoas, elas se comportarão de forma especialmente inspirada. Isso não parece ser verdade.” A IA pode gerar interfaces, layouts, variações de componentes e padrões de interação em velocidade. Sem gosto, essa velocidade produz mais dívida de design, não menos. Cada tela gerada por IA que vai para produção sem julgamento contextual adiciona mais uma camada de inconsistência ao produto.

Gosto, na formulação de Leigh, não é preferência estética. É julgamento contextual. Saber o que deixar de fora. Saber qual padrão encaixa neste momento para este usuário neste fluxo. Susan Sontag chamou de “uma lógica sem provas.” Essa lógica funciona como governança. É o filtro humano que decide quais outputs de IA são apropriados e quais são tecnicamente corretos, mas experiencialmente errados.

Exploramos como sistemas de design se tornaram infraestrutura de governança quando a Figma abriu seu canvas para agentes de IA. Sistemas de design restringem o que agentes podem construir. Gosto restringe o que humanos devem aprovar. Juntos, formam uma camada de governança que nem documentos de política nem verificações automatizadas conseguem substituir.

O Problema da Medição

Bhowmick referencia o framework debt.design de Alicja Suska e o conceito de “reciprocal awareness” de Austin Knight como pontos de partida para medir dívida de design. São contribuições úteis. Mas o problema de medição é mais fundamental do que qualquer framework individual pode resolver.

Dívida técnica tem proxies: tempos de build, cobertura de testes, atualidade de dependências, scores de complexidade de código. Dívida de design não tem proxies padronizados. Pesquisas de satisfação do usuário são indicadores atrasados. Testes de usabilidade são caros e intermitentes. Avaliações heurísticas dependem da expertise do avaliador.

Para produtos de IA especificamente, a métrica ausente é precisão de crença. O entendimento do usuário sobre o que a IA está fazendo corresponde ao que a IA realmente está fazendo? Quando há um desencontro, existe dívida de design. A interface está contando uma história diferente da do sistema.

Nenhuma organização que conhecemos mede isso sistematicamente. Esse é o déficit revelado pela Forrester: dívida técnica recebe pesquisa, classificação de severidade e conversa no conselho. Dívida de design em produtos de IA não recebe nada, apesar de moldar algo muito mais consequente que performance de sistema. Molda o que as pessoas acreditam que máquinas conseguem fazer.

O Que Muda

Três coisas decorrem de tratar dívida de design como uma preocupação de governança, e não como uma preocupação estética.

Primeiro, dívida de design pertence à mesma cadência de revisão que dívida técnica. Trimestral, no mínimo. Se seu time de engenharia reporta níveis de dívida para a liderança, seu time de design deve reportar o mesmo. Métricas diferentes, mesma estrutura de responsabilização.

Segundo, produtos de IA precisam de propriedade explícita da camada de crença. Não apenas da interface de entrada, da camada de processamento e da exibição de saída. Alguém é dono da pergunta: este produto representa com precisão suas próprias capacidades e limitações? Essa é uma questão de design com consequências de governança.

Terceiro, gosto não pode ser automatizado. Sistemas de design restringem os blocos de construção. Verificações automatizadas capturam inconsistências. Mas o julgamento sobre se a interface de um produto de IA representa com precisão suas capacidades para seus usuários exige avaliação humana. Você pode escalar produção com IA. Não pode escalar julgamento.

Fontes

Bhowmick, Arin. “Design Debt Is Now as Dangerous as Technical Debt.” Março 2026.
Leigh, Joshua. “Taste Is Not a Feature.” Março 2026.
Forrester. “Technology Debt Survey.” 2025.
Suska, Alicja. Framework debt.design.
Knight, Austin. Conceito de “reciprocal awareness.”

Victorino Group ajuda organizações a construir governança em produtos de IA antes que a dívida de design se transforme em falhas de confiança do usuário: contato@victorino.com.br | www.victorino.com.br