Eis a newsletter #45

Quando eu escrevi o artigo O Fim da Profissão Front-end alguns anos atrás. Fui fortemente criticado pela "comunidade" de devs front-end. Conheci diversos impropérios que eu nunca imaginei existir. Esse artigo é de 2017, mas de lá pra cá, absolutamente NADA mudou sobre como o relacionamento de back-end, front-end e designers se dá. Mas o principal problema, na minha opinião, é a relação entre front-end e designer.

Eu nunca entendi, inclusive quando eu era front-end, por que os designers deveriam e tinham tanta dependência de desenvolvedores front-end. Os designers tinham um comportamento bastante recluso, com certeza. Não era tão colaborativos quanto a imagem pregava. Havia de verdade um muro entre times de design e desenvolvimento. Isso mudou bastante nos últimos anos, as tem exposto uma verdade inconveniente: designers entregam e geram mais resultados se estiverem mais próximos de onde as pessoas que usam o produto percebem o valor que esse produto/serviço oferece.

A principal responsabilidade dos designers de produto, na minha humilde opinião, é melhorar e evoluir ao máximo a jornada de experiência de uso das pessoas no produto/serviço. Eles fazem isso não apenas com pesquisas, entrevistas, frameworks e métodos de descoberta, mas principalmente por meio da manipulação e monitoramento do ambiente que o usuário está inserido. Hoje, o que acontece é que, qualquer alteração simples, seja de interface, fluxo ou marcação de eventos de comportamento, deve ser feito pelo front-end.

O design system não resolve essa relação, ela pode facilitar ter uma coerência visual além de técnica, implementando padrões que fazem sentido para as duas especialidades, mas ainda assim, o design system é estático. Minha proposta aqui é que os designers tenham mais controle
da mudança de comportamento do usuário ao utilizar a interface do produto, e que isso não fique na mão do front-end.

Mudança de interface UI
Mudança de monitoramento de comportamento do usuário
Definição e deploy de novos padrões do design system
Testes A/B de interface e fluxos
Recrutamento e Pesquisas de usuários diretamente pelo produto
Monitoramento e análise de dados de comportamento de uso do usuário

A relação entre designer e front-end ainda é aquele waterfall que todo mundo conhece, que gera burocracia, ineficiência, descontentamento, encadeamento e overlap de responsabilidades. O mesmo que aconteceu com a relação entre back-ends e front-ends, deve acontecer com designers e front-ends. Uma evolução de alçadas deve acontecer.

Antes, muitos anos atrás (quase duas décadas) o front-end preparava um código "estático", onde os back-ends conectavam esse código com as informações e regras de negócio vindas do servidor. Essa relação gerava uma série de problemas técnicos e de relacionamento entre as partes. Com o passar do tempo, os back-ends não lidavam mais com a interface, servindo para os front-ends serviços que deveriam ser conectados por eles diretamente na interface, separando claramente as responsabilidades entre as duas especialidades. Back-end NUNCA devem ter contato com interface. Não faz sentido. Veja bem, essa divisão de alçadas foi um marco incrível, pois os back-ends poderiam agora se focar no que realmente era o seu trabalho, consequentemente a responsabilidade do front-end evoluiu (ou pelo menos deveria ter evoluído).

O que os fronts e designers deveriam estar fazendo então?
Eu acho que toda a parte de user interface é de responsabilidade dos designers, incluindo responsabilidades adjacentes, por exemplo, implementar data points para controlar e monitorar comportamentos do usuário na interface. Isso quer dizer que front-ends devem se preocupar com outra coisa. Três exemplos:

Performance. Ainda, o que mais pesa, é a parte de front-end. E é também o momento onde há a percepção de qualidade de estabilidade do sistema.
Regras de negócio que devem acontecer no front-end. Algumas regras de negócio acontecem sim no back, mas muitas outras, que dependem do comportamento do usuário, devem acontecer no front.
Criação, manutenção e monitoramento de APIs (sim, o back-end disponibiliza as bases de dados e toda a arquitetura, o front-end que deve criar os serviços que serão usados. Quem nunca ficou no meio de uma briga de backs e fronts para discutir como o formato do JSON deveria ser?)

Não acho que isso seja fácil de conseguir hoje. Talvez falte conversa, disposição, vontade de mudar. Talvez seja só medo mesmo.

Relacionados

Dados reais no design

Sobre o cenário das ferramentas de front-end

Outros:

Eis a Newsletter

[eis] #45 - Designer e front-end, uma…