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
- 3 Easy Steps for Working with Realistic Data in Sketch Using JSON
- Designing with Data
- Prototype with real data in Framer, from JSON to multi-device and internet of things
- Adobe XD: Designing with Real Data
Sobre o cenário das ferramentas de front-end
- front-end.directory
- Using front-end build tools
- A Collection Of Best Front End Frameworks
- GitHub: Front-end JavaScript frameworks
- Front-End Tooling Trends for 2017
- Updated List: The 67 Very Best Front End Web Developer Tools
- The most popular JavaScript front-end tools
- Top 10 Templating Engines for JavaScript To Improve and Simplify Your Workflow 2017
- Automating Front-end Workflow
- Javascript State of the Union 2015, parte 3
- Slides – Javascript State of the Union 2015
- The State of Front-End Tooling 2016 – Results
- Front-end Roles and Responsibilities
Outros:
- The future of front-end development is design
- The Future of Web Development: Coding as a Service
- I welcome every designer trying # FramerX to the @reactjs community.
- Framer
- # ThinkToCode ecosystem, part 2. Just pick your target code.
- The Design Tool Dilemma
- 3 Easy Steps for Working with Realistic Data in Sketch Using JSON
- Designing with Data
- Prototype with real data in Framer, from JSON to multi-device and internet of things
- Adobe XD: Designing with Real Data
- The end of Code
- Darpa Pliny - The $11M Tool That Could Help Computers Write Their Own Code
- Can computers write their own algorithms?
- Why can’t there be a program that writes code for us?
- The (probable) end of the front-end profession as you know it
- A.I. is Progressing Faster Than You Think!
- React Sketch.app: render React components to Sketch
- React Sketch.app: github
- You design, we put it on the web.
- Uizard
- Pix2Code - This app uses artificial intelligence to turn design mockups into source code
- Pix2Code - This Startup Uses Machine Learning To Turn UI Designs Into Raw Code
- Pix2Code - Startup uses AI to create programs from simple screenshots
- Soon We Won’t Program Computers. We’ll Train Them Like Dogs
- Wix Code - Create advanced web applications without coding
- Supernova.io
- Code beautiful UI with Flutter and Material Design - Google I/O ‘18
- With Sketch 43, Design IS Code & Code IS Design
- Can computers write their own algorithms?
- Sketch 43 will change the way we work and think
- Será o fim da profissão frontend ou mais uma grande evolução? · Issue #490 · frontendbr/forum
- Why can’t there be a program that writes code for us?
- The $11M Tool That Could Help Computers Write Their Own Code | WIRED
- The Future of Web Development: Coding as a Service
- Dan Abramov on Twitter
- Soon We Won’t Program Computers. We’ll Train Them Like Dogs | WIRED