Design Engineering começa antes do código: o que aprendi construindo o designDivergente

Como minha experiência em Product Design orientou a construção de um produto digital, da arquitetura de conteúdo à publicação, com desenvolvimento assistido por inteligência artificial?

Em outubro de 2026, durante a configuração do Sanity Studio para o designDivergente, encontrei uma mensagem aparentemente simples:

No document types. Please define at least one document type in your schema.

O ambiente estava funcionando. Eu conseguia acessar o painel de administração, mas ainda não existia uma estrutura de conteúdo que permitisse publicar um artigo.

Era um problema técnico, mas também uma questão de design.

Para alguém que vem de Product Design, fazia sentido pensar em categorias, relações entre conteúdos, hierarquia da informação e necessidades de quem utilizaria o produto. A diferença é que, naquele momento, essas decisões precisavam deixar de existir apenas como conceitos e passar a funcionar dentro de uma arquitetura de software.

Essa experiência sintetiza uma parte importante do meu trabalho com Design Engineering: transformar decisões de design em comportamentos, componentes e sistemas que funcionam de verdade.

O desafio não era apenas construir um blog

O designDivergente nasceu como um projeto autoral para compartilhar reflexões sobre design, tecnologia e desenvolvimento de produtos digitais.

Do ponto de vista da interface, o escopo inicial parecia relativamente simples:

1. Página para listagem de artigos
2. Página para detalhes de um artigo

Mas duas páginas não representam toda a complexidade de um produto.

Era necessário considerar como os conteúdos seriam organizados, publicados, encontrados e apresentados. Também era importante que a infraestrutura permitisse evoluir o blog sem depender de alterações no código a cada nova publicação.

Pensei no projeto a partir de algumas perguntas:

• Como oferecer uma experiência de leitura clara e consistente?
• Como organizar conteúdos para facilitar a navegação e a descoberta?
• Como permitir que a publicação de novos artigos não dependa do desenvolvimento?
• Como manter padrões visuais e funcionais entre diferentes páginas?
• Como garantir que uma mudança no produto não comprometa o que já estava funcionando?

Essas perguntas envolvem experiência do usuário, arquitetura da informação, tecnologia e manutenção.

A intenção era construir algo desejável para quem lê, viável tecnicamente e sustentável para quem mantém.

Arquitetura da informação também é arquitetura de software

Uma das primeiras decisões foi separar a aplicação pública do sistema de gerenciamento de conteúdo. O projeto foi organizado em duas partes:

• web/, responsável pela aplicação em Next.js e React, e
• studio/, destinada ao Sanity Studio.

Escolhi o Sanity (abre em nova aba) como Headless CMS para o designDivergente, permitindo que o gerenciamento editorial funcionasse de forma independente da interface de leitura, desenvolvida com Next.js (abre em nova aba) e React (abre em nova aba).

A configuração inicial começou sem modelos de documentos definidos. Ao longo do desenvolvimento, a estrutura editorial evoluiu para contemplar posts, autores, categorias, tags e configurações do site.

Essa estrutura permitiu integrar o conteúdo gerenciado no Sanity à aplicação em Next.js, mantendo a organização editorial independente da apresentação.

Durante o desenvolvimento, também fiz ajustes na interface, como manter a categoria apenas no breadcrumb dos artigos, evitando informações repetidas e tornando a navegação mais clara.

Quando o design system encontra a implementação

Outra frente importante foi a reconstrução visual que resultou na versão 5.0.0 do designDivergente.

O trabalho partiu da análise da experiência existente e de referências de produtos digitais, com atenção à tipografia, à hierarquia visual, aos componentes e aos padrões de interação.

Utilizei o Untitled UI Free (abre em nova aba) como base de componentes e trabalhei com uma estrutura visual que pudesse ser reutilizada e mantida. A implementação envolveu Next.js, React, TypeScript, Tailwind CSS, estilos responsivos e suporte a temas claro e escuro.

Mas a escolha dessas tecnologias, isoladamente, não define a qualidade do produto. A questão era como transformar decisões visuais em regras consistentes.

Um componente precisa funcionar em diferentes contextos. Uma mudança de tema não pode comprometer a legibilidade. Um filtro deve comunicar corretamente seu estado. Um ajuste tipográfico não pode prejudicar a leitura em telas menores.

Durante as revisões, alguns problemas exigiram refinamentos, incluindo estados transitórios dos filtros, comportamento de componentes e inconsistências na apresentação de informações.

Essas situações reforçaram algo que já fazia parte da minha prática em Product Design: uma interface não pode ser avaliada apenas pela aparência de um estado estático.

É necessário observar como ela responde às ações das pessoas, como comunica mudanças e como se comporta diante de diferentes condições.

No Design Engineering, essa responsabilidade continua. A diferença é que agora ela se estende até a implementação.

Desenvolver com IA não elimina a necessidade de tomar decisões

O Claude Code (abre em nova aba) teve um papel central no desenvolvimento do designDivergente.

Utilizei a ferramenta como agente de implementação, responsável por executar tarefas de programação, integrar componentes e serviços, realizar alterações no código e apoiar as verificações técnicas.

Minha atuação esteve concentrada na definição de requisitos, nas decisões de produto e arquitetura, na seleção de referências, na orientação da implementação e na avaliação dos resultados. O processo não consistia simplesmente em solicitar uma página e aceitar a primeira resposta.

As tarefas eram orientadas por contexto, restrições e critérios de aceitação. Depois da execução, os resultados eram analisados para identificar problemas e determinar os ajustes necessários. Essa dinâmica trouxe uma mudança importante para minha prática.

Antes, muitas decisões de design terminavam em especificações destinadas à implementação. Neste projeto, precisei acompanhar suas consequências no produto funcional.

Quando um componente apresentava um comportamento inesperado, não bastava apontar a diferença visual. Era necessário descrever o problema, compreender seu contexto, orientar a correção e verificar se a mudança não comprometia outras partes da aplicação.

A IA tornou a implementação tecnicamente acessível dentro desse processo, mas não substituiu a necessidade de julgamento. Também considero importante diferenciar as responsabilidades: a ferramenta executou parte significativa da programação.

Isso não significa que escrevi manualmente todo o código ou que o projeto, sozinho, comprove proficiência em desenvolvimento sem assistência.

O que a experiência demonstra é minha capacidade de utilizar conhecimentos de produto e design para conduzir decisões técnicas, orientar um agente de implementação e acompanhar a qualidade do software produzido. A velocidade de implementação só tem valor quando existe capacidade de avaliar o que está sendo entregue.

O conteúdo precisava funcionar além da interface

A integração entre Sanity e Next.js representou outra etapa importante.

O conteúdo gerenciado no Sanity precisava ser consultado, interpretado e apresentado corretamente pelo front-end.

Essa integração envolveu consultas GROQ (linguagem utilizada para buscar e filtrar os conteúdos armazenados no Sanity); tratamento de Portable Text (formato que estrutura textos ricos, como parágrafos, títulos, links e imagens); e uso de dados estruturados para alimentar os componentes da aplicação, garantindo que cada informação fosse apresentada corretamente na interface.

Na prática, o fluxo passou a conectar o trabalho editorial à experiência pública de leitura:

O aspecto interessante dessa arquitetura é que o conteúdo deixa de depender diretamente da estrutura visual de uma página. Um artigo pode ser criado e atualizado no ambiente editorial, enquanto a aplicação fica responsável por apresentá-lo seguindo os componentes e as regras de interface.

Essa separação facilita a manutenção e estabelece uma base para a evolução do produto. Ela também exige pensar em duas experiências diferentes:

1. Quem publica
2. Quem lê

Um bom sistema editorial precisa atender às duas.

Publicar não significa apenas colocar o site no ar

A reconstrução do designDivergente também exigiu cuidados que vão além da interface. O desenvolvimento foi organizado em fases, com escopos definidos, critérios de aceitação e revisões antes de cada avanço.

Esse processo incluiu preservar a versão anterior, acompanhar a implementação, avaliar os resultados dos testes e controlar a publicação da V5.0.0.

Foi uma parte importante da experiência com Design Engineering, porque ampliou minha responsabilidade para além das decisões visuais e funcionais. Passei a acompanhar também as condições necessárias para que essas decisões chegassem ao produto publicado com qualidade e segurança.

A organização desse processo, da auditoria inicial ao deploy, merece uma análise própria, especialmente pelo papel que as especificações, a IA e os critérios de aprovação tiveram no desenvolvimento.

O que mudou na minha forma de pensar design

O principal aprendizado do Design Divergente não foi descobrir que um designer pode utilizar inteligência artificial para construir um site. Foi compreender, na prática, como conhecimentos de Product Design podem orientar diferentes camadas da engenharia de um produto.

• Arquitetura da informação passou a dialogar diretamente com modelos de dados.
• Design systems passaram a exigir decisões sobre componentes implementados, estados e manutenção.
• As especificações de interface passaram a incluir critérios que precisavam ser testados no software.
• E a entrega deixou de ser apenas uma interface aprovada para incluir versionamento, integração, validação e publicação.

Isso não significa que as disciplinas se tornaram equivalentes ou que a experiência em design substitui conhecimentos aprofundados de engenharia. Significa que existe um espaço de atuação em que compreender as duas perspectivas ajuda a tomar decisões melhores.

Minha experiência anterior em Product Design não ficou para trás nessa transição. Ela foi o ponto de partida para lidar com os problemas do projeto. Conhecimentos sobre usuários, conteúdo, hierarquia, consistência e comportamento de interfaces continuaram relevantes. O desafio foi conectá-los às restrições e possibilidades da implementação.

Design Engineering é sobre continuidade

Existe uma diferença entre desenhar uma solução e acompanhar sua transformação em um produto funcional. Ao construir o designDivergente, trabalhei justamente nesse intervalo.

Parti de uma intenção de produto, defini a estrutura da experiência, acompanhei a implementação assistida por IA, revisei comportamentos, validei integrações e participei da entrega em produção.

O resultado foi o designDivergente, um blog publicado com infraestrutura editorial própria, interface baseada em componentes e uma base técnica preparada para evolução. Mais do que um projeto de interface, essa experiência se tornou uma forma de investigar minha própria atuação profissional.

Continuo trazendo o olhar de Product Design para os problemas que enfrento. Mas agora também me interessa assumir responsabilidade pelo que acontece depois da decisão de design:

• Como ela é implementada?
• Como funciona?
• Como é testada?
• Como se mantém ao longo do tempo?

Para mim, é nesse encontro entre intenção, experiência e implementação que o Design Engineering ganha significado. O objetivo não é simplesmente aproximar designers do código. É reduzir a distância entre aquilo que projetamos e aquilo que as pessoas realmente utilizam.