Por que a disciplina que deveria humanizar o software escolheu colocar seu melhor trabalho a serviço de quem já tinha escolha e deixou para trás os milhões de pessoas que não tinham nenhuma.
Existe uma crença implícita que estrutura a maioria das discussões sobre UX: a de que bons produtos são aqueles usados por escolha. Você escolhe o aplicativo de meditação que vai no seu celular. Você decide qual plataforma de streaming assinar. Você abandona o app de banco que te irrita e migra para outro. Essa liberdade de escolha é o que coloca pressão sobre empresas de consumo para investirem em experiência — porque o custo de um produto ruim é imediato: o usuário some.
Em B2B, essa lógica não existe
O usuário de um ERP corporativo não escolheu aquele software. O analista financeiro que passa oito horas por dia dentro de uma interface de reconciliação contábil não foi consultado quando o CFO assinou o contrato. O técnico de campo que usa um sistema de gestão de ordens de serviço no celular não teve nenhuma participação na avaliação de fornecedores. Eles são, nas palavras mais diretas possíveis, cativos — e durante décadas, os fabricantes de software B2B souberam disso e agiram em conformidade. O resultado é uma paisagem de produtos que funcionam tecnicamente, atendem aos requisitos do contrato, e torturam silenciosamente as pessoas que precisam operá-los todos os dias.
O comprador e o usuário não são pessoas diferentes
Nenhuma análise séria sobre UX em produtos B2B pode começar sem enfrentar o problema central: a separação estrutural entre quem decide a compra e quem sofre as consequências. Em B2C, essa separação raramente existe. Em B2B, ela é a regra, e sua influência sobre como o produto é concebido, vendido e evoluído é total.
Quando uma empresa avalia um software de gestão de projetos ou um sistema de CRM, as pessoas que conduzem o processo de seleção são, em geral, gerentes, diretores ou times de TI e procurement. Eles têm critérios objetivos: preço, conformidade regulatória, integrações com o stack existente, suporte contratual, SLA. O que eles raramente avaliam com rigor é a experiência cotidiana das pessoas que vão operar o sistema — em parte porque esses usuários frequentemente não têm voz nesse processo, e em parte porque os fornecedores aprenderam há muito tempo que não precisam vender para eles. Precisam vender para os compradores.
Isso criou uma indústria de software orientada a demonstrações. O produto precisa parecer poderoso e completo numa apresentação de quarenta minutos para um comitê executivo. Não precisa ser eficiente na décima hora de uso de uma segunda-feira. O design, quando existe, serve ao pitch — não ao trabalho. Isso explica a proliferação de dashboards visualmente elaborados que não dizem nada acionável, de módulos de configuração que expõem toda a complexidade do sistema ao usuário final, de fluxos de aprovação que levam seis cliques onde dois resolveriam. Ninguém no processo de venda vai usar o produto diariamente, então ninguém no processo de venda sofre com essas decisões.
A Falácia do “Usuário Profissional”
Um dos argumentos mais persistentes usados para justificar interfaces ruins em produtos B2B é a ideia de que usuários corporativos são profissionais, e profissionais podem — e devem — aprender ferramentas complexas. Seguindo essa lógica, exigir treinamento extenso, tolerar curvas de aprendizado íngremes e aceitar interfaces densas seria apenas o custo natural de usar software poderoso. É um argumento conveniente. É também fundamentalmente equivocado.
A complexidade de uma tarefa não justifica a complexidade de uma interface. Um cirurgião executa procedimentos extraordinariamente complexos, mas os instrumentos cirúrgicos são modelados para ergonomia, clareza e redução de erro — não para refletir a complexidade biológica do corpo humano. Um piloto de aeronave comercial opera sistemas de altíssima complexidade, mas a filosofia central do cockpit moderno é precisamente a de reduzir carga cognitiva, não amplificá-la. A complexidade do domínio nunca foi argumento para interfaces ruins — foi o pretexto que a indústria de software B2B usou para evitar o trabalho duro de simplificar o que é difícil de simplificar.
Há também outra dimensão que esse argumento ignora: a rotatividade. As empresas imaginam usuários experientes e treinados, mas a realidade operacional é que sistemas B2B são constantemente usados por pessoas novas no cargo, por colaboradores que migraram de outra área, por terceiros e parceiros com acesso limitado. O software que “qualquer profissional treinado consegue usar” torna-se um pesadelo de onboarding repetido indefinidamente, com custos reais de produtividade que ninguém mede porque ninguém os atribui ao design do produto.
O que acontece com pessoas que não podem sair
Existe uma literatura rica em psicologia organizacional sobre o conceito de learned helplessness aplicado ao ambiente de trabalho — a ideia de que, diante de condições que não podemos controlar, eventualmente paramos de tentar mudá-las e simplesmente nos adaptamos. Softwares B2B ruins criam exatamente esse efeito em escala.
O analista que desenvolveu um ritual de copiar dados para o Excel porque o relatório nativo do sistema não serve tem, provavelmente, feito isso por dois anos e já nem questiona mais. Ele simplesmente faz. O operador de call center que aprendeu que o sistema “trava” se você abrir duas abas ao mesmo tempo não reporta isso como bug — ele apenas não abre duas abas. O gerente de logística que imprime o relatório para remarcar as colunas na mão porque o sistema não permite reordenação decidiu que isso é normal. Essas workarounds invisíveis são o verdadeiro custo de UX ruim em B2B — e como são absorvidas individualmente, como rituais privados de adaptação, nunca aparecem em nenhum dashboard de performance.
O problema vai além da ineficiência. Há evidências consistentes de que ambientes de trabalho com alta carga cognitiva desnecessária — gerada por interfaces ruins, fluxos contraditórios, inconsistências visuais e terminologia opaca — contribuem para o aumento de fadiga, erros operacionais e, em última instância, burnout. Quando discutimos UX em produtos B2B, não estamos discutindo apenas conversão ou satisfação do usuário num sentido abstrato. Estamos discutindo as condições de trabalho de pessoas reais que passam a maior parte de suas horas produtivas dentro de sistemas sobre os quais têm zero controle. Isso é, ou deveria ser, uma questão ética além de uma questão de negócio.
Por que o mercado está mudando
Há forças reais que começaram a pressionar o mercado B2B por design melhor, e seria desonesto ignorá-las. A principal delas é geracional: à medida que millennials e a geração Z avançam para posições de liderança, passam a influenciar decisões de compra de software — e essas gerações cresceram com interfaces de consumo de altíssima qualidade. Eles não aceitam com a mesma passividade que seus antecessores a distinção entre “software profissional” e “software usável”. Isso está mudando expectativas nas avaliações, e empresas como Notion, Figma, Linear e Stripe demonstraram que é possível construir produtos B2B que as pessoas genuinamente querem usar.
A segunda força é a competição horizontal. Em muitas categorias B2B, o mercado se fragmentou o suficiente para que haja alternativas reais — e a facilidade de uso tornou-se um diferencial competitivo legítimo. Quando uma PME avalia softwares de gestão financeira e tem cinco opções funcionalmente equivalentes, a experiência do produto passa a importar de um jeito que não importava quando havia dois players dominantes com décadas de lock-in. O surgimento de uma camada de produtos B2B “product-led” — onde o produto se vende por si mesmo, com trials self-service e onboarding sem vendas — tornou a experiência do usuário a primeira linha de conversão. Não há demonstração de vendas para compensar uma interface confusa quando o prospect está sozinho explorando o produto às dez da noite.
Mas o progresso é desigual e, frequentemente, superficial. O que acontece com frequência é que empresas B2B investem em UX no produto de marketing — o dashboard de boas-vindas, o fluxo de trial, as telas que aparecem nas capturas de tela do site — e continuam negligenciando as telas usadas diariamente por quem já é cliente. É um design orientado à aquisição, não à retenção nem ao trabalho real. O produto parece bem na demo, o cliente assina, e o designer nunca precisou pensar nas telas de configuração de permissões ou no módulo de importação de dados em massa.
Os padrões que caracterizam design B2B ruim
Identificar os sintomas recorrentes é útil não como exercício de crítica, mas como mapa do trabalho que precisa ser feito. Quem trabalha com design de produtos B2B reconhecerá a maioria desses padrões:
- Arquitetura de informação orientada ao banco de dados, não ao fluxo de trabalho. O menu reflete as tabelas do sistema, não as tarefas do usuário. O resultado é que para completar uma ação simples — como criar um pedido com desconto especial — o usuário precisa navegar por três módulos diferentes que, no modelo mental do desenvolvedor, são entidades separadas.
- Formulários que nunca terminam. Campos obrigatórios que poderiam ter defaults inteligentes. Campos que existem para cobrir edge cases usados por 0,3% dos usuários, mas estão presentes em todos os fluxos. Validações que só aparecem depois do submit, forçando o usuário a reconstruir o contexto do erro.
- Terminologia herdada do backend. Usuários são expostos a nomes de variáveis, códigos de sistema, e jargão técnico que nenhum ser humano usaria espontaneamente. O problema não é apenas estético — é que esses termos criam barreiras reais de compreensão e tornam o produto inacessível para qualquer pessoa que não passou por treinamento específico.
- Ausência de estados de erro úteis. A mensagem de erro existe, mas não diz o que o usuário deve fazer. O sistema falhou, mas não oferece nenhuma rota de recuperação. Isso é particularmente destrutivo em contextos de alto stress operacional, onde erros acontecem sob pressão.
Tabelas infinitas sem contexto. O padrão mais onipresente do software B2B: uma tabela com quinze colunas, paginação, filtros que ninguém sabe como resetar, e zero indicação de qual item exige atenção imediata. É a ausência de qualquer hierarquia de relevância — todos os dados tratados como igualmente importantes, o que é a mesma coisa que nenhum dado ser importante.
Design B2B bem feito
Quando o design B2B funciona, ele não funciona por ter seguido um conjunto diferente de princípios de UX — os princípios são os mesmos. Ele funciona porque alguém teve disposição para fazer o trabalho que é genuinamente difícil nesse contexto: entender em profundidade o domínio, observar o trabalho real acontecendo, e resistir à pressão de expor toda a complexidade do sistema como se isso fosse uma virtude.
O trabalho começa com pesquisa que vai além de entrevistas genéricas de descoberta. Entender um produto B2B exige imersão no domínio — aprender o vocabulário do setor, entender as restrições regulatórias, mapear as dependências entre papéis diferentes na organização, e distinguir o que é complexidade essencial (que precisa existir) da complexidade acidental (que existe porque ninguém teve tempo de simplificar). Um designer que nunca fez reconciliação financeira terá dificuldade real para simplificar um fluxo de conciliação bancária. Isso não significa que precisa ser counter — significa que precisa aprender o suficiente sobre o domínio para saber onde a complexidade é inevitável e onde é preguiça de abstração.
Há também uma habilidade específica que produtos B2B demandam e que raramente aparece em currículos de design: a capacidade de projetar para múltiplos níveis de expertise simultâneos. O mesmo sistema será usado por alguém no primeiro dia e por alguém no quinto ano. Projetar para o novato cria fricção para o expert. Projetar para o expert abandona o novato. As soluções para isso — atalhos contextuais, configurabilidade sensata, progressive disclosure inteligente — são mais difíceis de implementar do que parecem em teoria, especialmente quando os times de desenvolvimento trabalham sob pressão constante por novas features.
O problema que nenhum designer sozinho resolve
Seria cômodo terminar com uma lista de boas práticas e a implicação de que designers mais capacitados e empoderados resolveriam o problema. Mas a degradação de UX em produtos B2B não é primariamente um problema de capacidade técnica. É um problema estrutural enraizado em como o mercado incentiva o desenvolvimento de software corporativo.
Enquanto os ciclos de venda forem longos o suficiente para que o produto precise impressionar em demos mas não precise performar bem em produção durante anos; enquanto os contratos incluírem lock-ins que tornam a migração custosa demais para justificar; enquanto os usuários finais não tiverem voz nos processos de renovação e avaliação; enquanto métricas de sucesso de produto forem definidas em termos de módulos entregues e não de eficiência do trabalho — o incentivo estrutural vai continuar favorecendo complexidade sobre clareza, completude sobre coesão, e feature parity sobre experiência coerente.
Isso não é fatalismo. É o diagnóstico necessário antes de qualquer prescrição séria. Designers que entram em times B2B sem compreender esse contexto tendem a se frustrar rapidamente — produzem trabalho bom que é sistematicamente deprioritizado, ou descobrem que o espaço de decisão disponível para eles exclui exatamente as partes do produto que mais precisam de atenção. A advocacia por UX em contextos B2B é tanto um exercício político quanto técnico. Requer a construção de casos de negócio em linguagem que compradores e executivos entendam — redução de erro, tempo de onboarding, custo de suporte, churn — porque “o produto poderia ser mais agradável de usar” raramente move orçamentos corporativos.
Por onde começar
Não existe uma resposta única para esse conjunto de problemas, mas existe uma sequência de prioridades que tem se mostrado mais eficaz do que a abordagem comum de redesign holístico ou reescrita completa de interfaces.
O ponto de entrada mais produtivo é, quase sempre, os fluxos de alta frequência. Em qualquer produto B2B, há um pequeno conjunto de ações que representam a maioria absoluta do uso diário — e essas ações raramente recebem atenção proporcional à sua importância. Um fluxo de criação de pedido que é executado duzentas vezes por dia merece mais investimento de design do que um dashboard executivo que o CEO abre uma vez por semana. Mapear frequência de uso real — não percebida, real — é o primeiro instrumento de priorização disponível para qualquer time.
O segundo movimento é a redução agressiva de carga cognitiva nos pontos de maior pressão. Identificar onde os erros acontecem com mais frequência, onde o suporte recebe mais chamados, onde os usuários desenvolveram workarounds consistentes — esses são os lugares onde o design pode gerar impacto mensurável e rápido, que por sua vez gera o capital político necessário para projetos maiores.
O terceiro, e talvez o mais negligenciado, é o investimento em sistemas de design consistentes e vocabulário controlado. Produtos B2B crescem por acreção — módulos adicionados ao longo de anos por times diferentes, às vezes adquiridos via M&A, cada um com seu próprio padrão visual e terminologia. A incoerência resultante não é apenas esteticamente desagradável; ela aumenta genuinamente o tempo de aprendizado, cria ambiguidade operacional e aumenta a probabilidade de erro. Um sistema de design bem implementado não é um projeto de vaidade — é infraestrutura de redução de fricção com retorno mensurável.
O mercado B2B representa uma fatia enorme da economia de software — e uma concentração desproporcional de horas humanas gastas em interações com produtos digitais. Médicos em sistemas hospitalares. Operadores de logística em plataformas de rastreamento. Analistas em ferramentas de compliance. Profissionais de RH em sistemas de folha de pagamento. Essas pessoas merecem produtos que respeitem seu tempo, sua inteligência e a complexidade real do trabalho que executam — e não um design que foi otimizado para o slide da demonstração de vendas.
A boa notícia é que o ponto de partida, nesse mercado, ainda é muito baixo. Não é preciso fazer milagres para fazer diferença. É preciso, sobretudo, decidir que as pessoas que usam o produto todos os dias importam tanto quanto — ou mais do que — as pessoas que assinam o contrato.
