Sim, você tem toda razão e quase todo mundo não entende isso. Jocosamente, eu diria que quanto mais experiente a pessoa é, menos ela entende de UX de backend, afinal ela quer colocar todas as belezinhas que aprendeu, pôr no currículo e dizer que é um super sênior, mas na verdade é o oposto — pelo menos alguns deles beiram a idiotia.

Eu já não tenho como quantificar mais os problemas que tive em sites e apps, e eu desisti da operação, compra... Muitas vezes fui no presencial, no concorrente, porque o software feito é um lixo. Sim, ele pode até parecer bonitinho, mas o predicado dele é lixo e dificulta muito ou impossibilita o uso. Em geral, quando você reclama, eles dizem que não há problema algum, eu é que não sei usar.

Então tá bom, um programador extremamente experiente em 40 anos, que estudou bem UX, sabe até dizer como aquilo foi programado, não sabe usar. Só leigos que conseguem usar. Bem, muitas vezes minha mãe, de mais de 80 anos, também não consegue, e posso citar uma enorme demografia que não há qualquer meio de usar ou precisa de muito esforço.

Minhas críticas ao desenvolvimento de software atual vêm muito daí. Se não estivesse me atrapalhando, provavelmente eu nem falaria nada. Não é algo pontual, é um erro muito disseminado, e acontece o que eu repito muito: se você treinar o erro, é ele que fará para sempre. E se você se torna experiente fazendo errado, uma hora chegará sua vez de ensinar outra pessoa errado.

Boa parte do problema é frontend. Mas uma parte considerável, que eu não sei medir, é backend. Na verdade, eu diria que quase a totalidade é uma junção das duas coisas.

Isso vem da ideia que se vende hoje de fazer tudo de forma complexa sem necessidade, muitas vezes tentando passar a ideia de que aquela forma é a melhor ou única forma de fazer isso. E aí é claro que eu levo, porque é impossível eu estar certo e ela estar errada, ainda mais se ela tem a validação de muitos, ou até mesmo da maioria, que foi aprendendo errado com outro. Não é difícil. Tem um assunto que 93% acredita ser verdade mesmo sem ter qualquer prova daquilo — pelo contrário. Nem vou falar o que é porque não cabe aqui, traria muita discussão que não levará a lugar algum, serei mais atacado e não vai mudar minha vida, até porque respeito as crenças das pessoas até que me causem um problema real.

Essas crenças, validações, ensino do erro, falta de criticidade por parte das pessoas, falta de vontade de aprender além da receita de bolo que passaram para ela, entre outros motivos — mas principalmente porque erram em como fazem o backend, reforço: porque complicam o que é simples, usam tecnologia errada porque é o que está na moda; e usam argumentos falaciosos — fazem as pessoas criar esses monstrengos que sequer são testados de verdade.

Raras as vezes o SAC me respondeu que iriam ver o que acontece, e virtualmente zero consertaram, a não ser que era erro de dados e não de software.

É claro que UX envolve muitas coisas relacionadas ao usuário. Não é só sobre o que ele vê e interage, que normalmente é chamado apenas de UI — que é só uma parte da UX.

Performance é UX. Não só UX, é até SEO. Já vi site que se dava bem porque fez diferente de todo mundo, tinha uma performance incrível, estava sempre entre os primeiros resultados da busca. E depois de uma mudança de diretoria, mandaram fazer a receita de bolo que os outros faziam, aumentando o custo, complicando a manutenção e dando pior performance — que desagradou os usuários e piorou imensamente o SEO deles, tornando-os quase irrelevantes. E cada vez mais demorando para fazer melhorias, porque é tudo mais complexo (os maldosos dirão que é ótimo a demora, porque só são pioras agora).

Nem entrei na questão das falhas desnecessárias no backend, geralmente por falha na coleta de requisitos, no planejamento, na programação (até por falta de capacidade), na falta de testes, de uso real (dog food), em usar tecnologias complexas que mais atrapalham que ajudam ou técnicas ruins de gerência do projeto. Além, é claro, de pagarem e tratarem mal programadores, ficando só com os ruins — que, mesmo sabendo que não dão conta disso, aceitam porque têm Stack Overflow, IA, então eles pegam. Também não falarei do que está acima do programador: diretrizes erradas, prazos malucos, etc.

Nem sempre eu digo que é bom estudar psicologia para melhorar a UX, mas certamente é um diferencial — eu estudei. Em muitas equipes, deveria haver um especialista em UX apenas para dizer o que está errado para o gerente e programador e o que fazer. Pena que quase todos os especialistas em UX não entendem nada disso. Foram para essa área porque não conseguiam programar, e programar é mais difícil de enganar que fazer UX.

Eu digo para as pessoas estudarem psicologia, sociologia, filosofia — ou até reforçar a comunicação e expressão e matemática — por outros motivos. Digo para, mesmo os mais "equilibrados mentalmente", fazerem terapia para melhorar um pouco, mesmo que temporariamente. Aí vem outro problema: a maioria dos profissionais são ruins, são pessoas com problema que foram estudar por causa deles, não para melhorar a vida de outras pessoas, e é complicado escolher qual é a melhor linha para cada um. (Alguns dizem que psicanálise nem é ciência — não exige diploma, como quase 100% da nossa área, e sabemos que isso ajuda a ter muita gente ruim — mas a maioria tem, o que não invalida ela como alguma ajuda de autoconhecimento que faz uma diferença enorme na vida como um todo, até profissional. Mas pode ser TCC, porque a gente aprende cada vez mais a ter atitudes erradas, ou diversas outras formas, como Gestalt). É mais para ajuda pessoal, mas ajudará a trabalhar em equipe, entender o usuário, etc.

Um exemplo de uma consultoria que dei para uma empresa que queria maior performance, e como eles sabiam que teriam grande volume (dica: eles tinham bem menos volume, como quase todo mundo tem — este é um dos erros mais comuns que programadores cometem), por isso usaram arquitetura de microsserviços. Eu só falei uma coisa: "tirem essa arquitetura, refaçam como monólito". A performance que eles queriam veio, e a UX ficou absurdamente melhor.

Como bônus final: um dos sites mais conhecidos ficou mais rápido quando eles tiraram o cache. Isso porque eles sempre disseram que só fazem algo depois de medir se vale a pena.

Lições:

a) Medir nem sempre resolve
b) A maioria do que vê funcionários de empresas falando que fizeram e foi ótimo é mentira
c) O que dizem que é o certo, muitas vezes não é
d) Se você tiver validação de muitas pessoas que fizeram ou dizem ter feito, você fará o errado

Não vou falar que o programador não pensa na UX do seu colega ou de si próprio — é outro assunto.

bom dia, sr.

descreverei um fluxo.

cenário: MIL clientes atrasaram pagamento do dia 15 de uma provedora de internet. vão pagar dia 16, quando receberem lembrete meio dia.

fluxo:
cliente digita cpf para checar 2a via de boleto;
cliente termina de digitar, ele vai mover o mouse ou o dedo para clicar no botão "Consultar";
valida se cpf é válido ou não e já acusa;
por debaixo dos panos, o front-end envia uma requisição ao backend nestjs enquanto o cliente move o mouse;
o backend coloca a requisição numa fila bullmq usando redis na mesma rede docker;
a requisição exige sincronamente e sequencialmente consultar o cpf do cliente em uma API de um ERP com gateway de pagamento para provedores de internet. a api retorna o id do cliente. após o id do cliente ser retornado, requisitam-se todas as faturas do cliente dos últimos 12 e dos próximos 12 meses (não há filtro);
filtram-se os campos dia_pagamento=null para dia_vencimento > Date.now(), por exemplo, descobrem-se portanto as faturas atrasadas/vencidas;
filtram-se dados sensíveis como endereço, nome completo exposto (se não estiver no boleto ou a depender de outras regras de negócio), nome de celular, usuário de rede PPoE e outros dados de configuração de ponto de acesso de internet, plano detalhado, etc;
retornam-se da fatura os dados sobre qr code pix, pix copia cola, linha digital boleto, link pdf boleto (pode trancar a depender da regra de negócio), nome cliente com siglas, etc);
dessa forma, cada cliente da fila será processado em lote, e cada requisição à api externa não faz depender do próximo nem do prévio cliente, apenas o próprio cliente "João" esperaria a dele mesmo, e não da "Maria";
o processamento em lote, respeitando o rate limit da API externa, permite atender a mais clientes em paralelo, cada um em sua fila;
guardam-se esses dados de faturas para cada cpf em um cache Keyv com redis como store, pois o mesmo cliente pode fazer a mesma requisição novamente à toa no mesmo dia para aquela mesma fatura (tempo de cache depende da regra de negócio);
cada fatura filtrada retorna resposta ao requerente inicial separadamente;
nestjs inicia com mais instâncias, proporcionalmente ao número de vCPUs;

agora o cliente colocou o mouse em do botão, ele clica em "Consultar".
caso 01: instantaneamente, como um passe de mágica, o componente visual do frontend renderiza-se com aquilo que ele precisa ver;
caso 02: em horário de pico, o tempo de resposta pelo menos não vai passar de 01s. talvez, 100ms, 500ms.

terminei isso acima ontem. quando comecei?

cenário ideal overkill: adicionar funcionalidade de rotina de madrugada -> varrer a api do ERP externo e buscar pelos dados mais recentes dos clientes -> agenda fila de escrita em banco local assincronamente e agenda o próximo item deste fluxo -> se não pagou fatura há X dias (regra de negócio, lei, CDC, etc), então envia mensageria webpush/email/zap -> roda novamente a mesma rotina com leitura em banco de dados local em horários ideais ou dias escolhido pelo cliente (algum frontend? msg de zap com bot? contrato? lei? CDC? etc).

este seria um cenário de backend que pensa no UX, certo?

Concordo 100%. Claro que muitas vezes problemas de performance podem estar relacionados ao front, mas pela minha experiência, normalmente isso é culpa do back. E normalmente culpa da forma que a aplicação puxa dados do banco ou de dependências com API's externas.

Hoje em dia, vejo UX muito como um diferencial estratégico da empresa. Muitas vezes um app faz menos coisas que outro, mas é mais bonito e tem uma experiência de uso menos frustrante/massante, e esse segundo acaba cativando mais os usuários.

Uma coisa que lembro de ter lido na biografia do Steve Jobs, era que ele foi alguem extremamente perfeccionista. Queria que o mac fosse bonito inclusive por dentro. Os engenheiros rebatiam dizendo "Mas por que tem que ser bonito por dentro se nenhum usuario vai ver?" Mas, na cabeça do Jobs, isso fazia parte da experiência Apple. Acho que isso se conecta com a UX por parte do back, de que alguns devs back negligenciam otimizações simples que davam pra ser feitas, que fariam uma diferença grande na performance.

Depende muito. Na maior parte das vezes abrir um site e ficar carregando lentamente nem sempre é o backend o problema. Pode ser até um problema fora do escopo do projeto envolvendo DNS. O mesmo a conexão do usuário. Mesmo o Front-end que não sabe lidar com cache adequadamente, session storage etc...

UX é um conceito que faz mais sentido para front-end do meu ponto de vista. Mas pode ser que eu esteja preso num paradigma.

Cores, organização, tipografia, essas coisas que UX geralmente trabalha em cima. O usuário que um feedback para o que tá acontecendo. E na maior parte das vezes uma pagina de load já é o suficiente.

Se a pagina de load fica mais de 2 segundos ou algo do tipo, o problema não é de UX e sim que arquitetura por parte do backend ou como esses valores estão sendo manipulados pelo o Front-end.