Toda aplicação tem pelo menos duas interfaces. Uma aparece para quem usa. A outra é sentida por quem constrói, testa, publica e mantém o produto.

A primeira costuma receber o nome de experiência do usuário, ou UX. A segunda é a experiência do desenvolvedor, ou DX. Quando as duas são tratadas separadamente, a entrega acumula atrito: uma interface pode até parecer boa, mas se tornar lenta para evoluir, difícil de validar e arriscada de manter. Quando são projetadas como partes do mesmo sistema, qualidade deixa de ser uma etapa final e passa a orientar o trabalho inteiro.

Na Triarch Tech, pensamos assim: DX é a experiência interna que sustenta a UX entregue ao mundo.

DX não é apenas uma ferramenta mais rápida

O conceito acadêmico de Developer Experience é anterior à popularização dos portais internos e das plataformas de engenharia. Fagerholm e Münch (2012) definem DX a partir de como profissionais de desenvolvimento percebem e sentem suas atividades em um ambiente de trabalho. Isso inclui aspectos cognitivos, afetivos e motivacionais, além de ferramentas e processos.

Essa definição muda a pergunta. Em vez de observar apenas se o pipeline executou ou se a documentação existe, precisamos entender se a pessoa consegue formar um modelo mental do sistema, receber retorno em tempo útil e contribuir sem gastar energia decifrando obstáculos desnecessários.

O framework apresentado por Noda, Storey, Forsgren e Greiler (2023) organiza essa experiência em três dimensões úteis:

  1. Ciclos de feedback: quanto tempo leva para uma ação produzir uma resposta compreensível.
  2. Carga cognitiva: quanto conhecimento e esforço mental são exigidos para realizar uma tarefa.
  3. Estado de fluxo: quanto o ambiente permite foco e progresso contínuo, sem fragmentação constante.

Essas dimensões não são uma nova forma de vigiar produtividade. O trabalho que originou o framework recomenda combinar percepções humanas com indicadores do sistema. Na mesma direção, o modelo SPACE, de Forsgren e colaboradores (2021), mostra por que produtividade em software é multidimensional. Satisfação e bem-estar, desempenho, atividade, comunicação e colaboração, eficiência e fluxo precisam ser analisados em conjunto. Contar commits ou horas isoladamente não descreve o valor produzido e pode incentivar o comportamento errado.

A experiência também acontece entre pessoas

DX não termina no editor de código. Ela aparece na revisão que explica uma decisão, na clareza de prioridades, na circulação do conhecimento e na possibilidade de sinalizar um risco antes que ele alcance o usuário.

Um estudo apresentado no ICSE-SEIS 2025 por Wassouf-Jr, Fukuda e Fontão investigou a DX de pessoas LGBTQIAPN+ em equipes ágeis por meio de uma pesquisa de opinião com 40 participantes. O recorte populacional permitiu observar com nitidez fatores que importam para qualquer leitura séria da experiência de trabalho: confiança, comunicação e apoio adequado influenciam colaboração, satisfação e permanência. Retrospectivas, programação em par e reuniões diárias podem favorecer colaboração e reduzir vieses, mas somente quando adaptadas ao contexto e conduzidas em um ambiente de respeito.

Não usamos esse estudo para generalizar uma amostra específica para todas as equipes. A recomendação que extraímos é operacional: práticas colaborativas devem ser escolhidas e adaptadas às pessoas e ao contexto, não repetidas como cerimônias obrigatórias. Na Triarch, uma reunião precisa ter finalidade, contexto e resultado esperado. Quando uma decisão pode ser preparada de forma assíncrona, registramos antes e usamos o encontro para resolver divergências. Quando trabalhar em conjunto reduz risco ou espalha conhecimento, revisão e pareamento ganham prioridade.

UX não começa quando a tela fica pronta

Do lado de quem usa, também não basta medir se uma tarefa pode ser concluída. Hassenzahl e Tractinsky (2006) descrevem UX como um campo que considera, além do uso instrumental, emoções, motivações e o contexto em que a interação acontece. Em uma pesquisa com 275 profissionais e pesquisadores, Law e colaboradores (2009) encontraram amplo acordo de que UX é dinâmica, dependente do contexto e subjetiva.

Isso significa que a mesma funcionalidade pode gerar experiências diferentes conforme o momento, o repertório, a urgência e as consequências de um erro. Confirmar um pagamento, revisar um laudo e explorar uma hipótese com IA não exigem apenas layouts diferentes. Exigem níveis diferentes de explicação, prevenção, recuperação e controle.

As heurísticas clássicas de Nielsen e Molich (1990) continuam úteis para avaliar visibilidade do estado, consistência, prevenção de erros e correspondência com o mundo real. Em produtos atuais, ampliamos essa leitura para cenários AI-first, nos quais o sistema também precisa comunicar incerteza, origem, limite e possibilidade de supervisão humana.

Da evidência à prática

Não adotamos um único artigo como manual. Estudos diferentes respondem partes diferentes da experiência, e cada recomendação precisa ser confrontada com o contexto do produto e da equipe.

  • Fagerholm e Münch ampliam o objeto de DX. Aplicamos essa recomendação observando ferramentas, processos, compreensão, motivação e relações de trabalho, não apenas velocidade de build.
  • O framework DevEx propõe ciclos de feedback, carga cognitiva e fluxo. Aplicamos essas dimensões ao organizar ambiente local, documentação, automações e limites de arquitetura.
  • O modelo SPACE alerta contra uma métrica isolada de produtividade. Aplicamos uma leitura equilibrada entre resultado, qualidade, colaboração, satisfação e capacidade de manter o fluxo.
  • Hassenzahl, Tractinsky, Law e colaboradores situam UX além da conclusão de tarefas. Aplicamos pesquisa contextual, arquitetura de informação e avaliação das consequências emocionais e práticas de cada interação.
  • Nielsen e Molich oferecem uma inspeção sistemática da interface. Aplicamos revisão heurística para encontrar problemas de visibilidade, consistência, prevenção e recuperação antes de publicar.
  • Wassouf-Jr, Fukuda e Fontão mostram que a mesma prática ágil pode produzir experiências distintas conforme o contexto. Aplicamos cerimônias e modos de colaboração de forma intencional, com finalidade e resultado esperados.

Essa combinação evita dois extremos: aplicar uma prática apenas porque está em alta ou tratar experiência como uma preferência sem critério. A literatura orienta hipóteses. A observação do contexto, os testes e o retorno das pessoas verificam se elas funcionam aqui.

O atrito interno sempre encontra uma saída

Existe uma relação prática entre as duas experiências:

Quando compreender, alterar e validar o software exige esforço excessivo, esse custo reaparece para o usuário em forma de inconsistência, demora, falhas e decisões pouco explicadas.

Uma regra de negócio espalhada por vários pontos aumenta a carga cognitiva da equipe e a chance de comportamentos divergentes na interface. Um ambiente local imprevisível alonga o ciclo entre hipótese e teste. Uma revisão hostil esconde dúvidas que deveriam virar decisões de arquitetura. Uma telemetria incompreensível torna a recuperação lenta justamente quando a pessoa usuária mais precisa do produto.

Por isso, não tratamos DX como benefício interno e UX como acabamento externo. As duas são propriedades de um mesmo sistema sociotécnico.

Como projetamos para quem desenvolve e para quem usa

Nosso processo trabalha com duas jornadas desde o diagnóstico. Uma acompanha a pessoa que precisa compreender, decidir e agir no produto. A outra acompanha a equipe que precisa construir, testar, operar e evoluir essa experiência.

1. Tornamos decisões encontráveis

Arquitetura, limites de escopo, critérios de aceite e riscos relevantes são registrados perto do trabalho. O objetivo não é produzir documentação em volume. É reduzir o tempo gasto redescobrindo por que algo existe e qual compromisso não pode ser quebrado.

Para quem usa, o mesmo princípio aparece em linguagem clara, hierarquia de informação e estados que explicam o que aconteceu e qual é o próximo passo.

2. Encurtamos o caminho entre mudança e aprendizado

Automação de formato, tipos, testes, build, preview e validações de acessibilidade devolve respostas antes da publicação. Revisões pequenas e frequentes diminuem o custo de corrigir uma direção.

Na experiência externa, protótipos, fluxos navegáveis e validações contextuais antecipam dúvidas que seriam caras depois. Não esperamos a interface ficar visualmente pronta para descobrir se ela é compreensível.

3. Reduzimos carga cognitiva sem esconder o sistema

Convenções, componentes reutilizáveis, tokens visuais, limites de módulos e comandos previsíveis ajudam a equipe a concentrar energia no problema real. Automação deve remover repetição, não apagar a compreensão sobre o que acontece.

Para o usuário, aplicamos divulgação progressiva: mostramos primeiro o necessário para decidir e mantemos detalhes acessíveis quando o contexto exige. Simplicidade não significa omissão.

4. Criamos espaço para contribuição efetiva

Revisão técnica deve melhorar a decisão e compartilhar conhecimento, não testar autoridade. Perguntas, alertas e discordâncias precisam encontrar um canal claro. Retrospectivas só têm valor quando produzem mudanças observáveis e quando todas as pessoas podem participar com respeito.

Esse cuidado chega ao produto em textos que não culpam quem usa, erros que oferecem recuperação e alternativas acessíveis para diferentes modos de interação.

5. Projetamos IA e privacidade como comportamento, não como selo

Em experiências com IA, registramos finalidade, entradas, saídas, limites, possibilidade de revisão e caminho de fallback. A equipe precisa saber como avaliar o comportamento do sistema; a pessoa usuária precisa entender quando há automação e quando manter o controle.

Em produtos que tratam dados pessoais ou sensíveis, minimização, acesso, rastreabilidade, retenção e resposta a incidentes entram na arquitetura e na experiência. Isso reduz ambiguidade para quem desenvolve e exposição desnecessária para quem usa.

Uma definição de pronto com dois lados

Antes de considerar uma entrega concluída, procuramos responder dois conjuntos de perguntas.

Para a experiência de uso:

  • A pessoa entende onde está e o que pode fazer?
  • O sistema comunica progresso, resultado, limite e erro?
  • Existe prevenção e recuperação quando algo não sai como esperado?
  • A interação continua utilizável com teclado, tecnologias assistivas e movimento reduzido?
  • Em recursos de IA, a automação é identificável e supervisionável?

Para a experiência de desenvolvimento:

  • Uma pessoa da equipe consegue compreender por que a solução foi construída assim?
  • A mudança pode ser testada e revisada sem um ritual oculto?
  • O feedback chega cedo o suficiente para orientar a decisão?
  • A arquitetura limita o impacto da alteração?
  • O processo permite questionar riscos técnicos, éticos e de privacidade de forma clara?

Uma resposta negativa não significa que tudo precisa parar. Ela torna a dívida visível e permite decidir conscientemente o que será resolvido, quando e por quê.

Excelência é diminuir a distância entre intenção e experiência

DX bem cuidada não serve apenas para fazer a equipe escrever código mais rápido. Ela cria condições para aprender, colaborar e alterar o produto com confiança. UX bem cuidada não serve apenas para deixar a interface agradável. Ela ajuda pessoas a compreender situações, tomar decisões e se recuperar de erros.

Na Triarch Tech, projetar as duas experiências é uma escolha de engenharia. Quanto menor a distância entre a intenção de quem constrói e a compreensão de quem usa, mais sustentável, confiável e humano o software pode se tornar.

Referências

  1. Fagerholm, F.; Münch, J. Developer Experience: Concept and Definition. International Conference on Software and System Process, 2012, p. 73-77. DOI: 10.1109/ICSSP.2012.6225984.
  2. Noda, A.; Storey, M.-A.; Forsgren, N.; Greiler, M. DevEx: What Actually Drives Productivity? Communications of the ACM, v. 66, n. 11, 2023, p. 42-51. DOI: 10.1145/3610285.
  3. Forsgren, N.; Storey, M.-A.; Maddila, C.; Zimmermann, T.; Houck, B.; Butler, J. The SPACE of Developer Productivity: There's more to it than you think. ACM Queue, v. 19, n. 1, 2021, p. 20-48. DOI: 10.1145/3454122.3454124.
  4. Wassouf-Jr, E.; Fukuda, P.; Fontão, A. Investigating the Developer Experience of LGBTQIAPN+ People in Agile Teams. 47th IEEE/ACM International Conference on Software Engineering: Software Engineering in Society, 2025, p. 43-54. DOI: 10.1109/ICSE-SEIS66351.2025.00010.
  5. Hassenzahl, M.; Tractinsky, N. User Experience: A Research Agenda. Behaviour & Information Technology, v. 25, n. 2, 2006, p. 91-97. DOI: 10.1080/01449290500330331.
  6. Law, E. L.-C.; Roto, V.; Hassenzahl, M.; Vermeeren, A. P. O. S.; Kort, J. Understanding, Scoping and Defining User Experience: A Survey Approach. CHI Conference on Human Factors in Computing Systems, 2009, p. 719-728. DOI: 10.1145/1518701.1518813.
  7. Nielsen, J.; Molich, R. Heuristic Evaluation of User Interfaces. CHI Conference on Human Factors in Computing Systems, 1990, p. 249-256. DOI: 10.1145/97243.97281.