Não existe segredo: desenvolvedores e designers precisam colaborar entre si

Durante o desenvolvimento “Enterprisey” de aplicações web temos dois papéis realmente importantes dentro da equipe: o desenvolvedor e o [web] designer. Cada um possui suas atividades bem definidas durante o desenvolvimento do software, mas em algum momento será necessário que eles sentem juntos e colaborem para definir os detalhes da GUI.

Eles não irão colaborar entre si para definir a identidade visual da aplicação [não que não seja possível], mas sim para acertarem os detalhes “baixo nível” da interface ou mesmo como definir melhor a experiência do usuário. No final das contas, eles podem discutir sobre css, javascript, tags de marcação XHTML ou uma melhor disposição dos componentes visuais.

E isso é comum com qualquer tecnologia para web, seja ela PHP, RubyOnRails, .Net ou mesmo Java.

Mas o que eu realmente não entendo é porque muitos profissionais (desenvolvedores, gerentes, designers etc) encaram que desenvolvedor e designer não precisam -ou mesmo não deveriam- discutir sobre o design da interface da aplicação.

O que difere a comunicação entre um desenvolvedor e um analista de negócios que tentam definir ou acertar detalhes sobre o modelo de domínio da aplicação, e a comunicação entre um desenvolvedor (ou analista) e um designer que tentam acertar detalhes da interface com o usuário?

Nenhuma! Não há qualquer diferença, eles conversam e colaboram entre si com a mesma finalidade: terem software funcionando e que agregue valor ao cliente.

O que leva tantos profissionais a pensarem que desenvolvedor e designer são “peças” isoladas durante o desenvolvimento do software? Um modelo em cascata, talvez. Por estarem trabalhando num processo fabril de fábrica de software, talvez.

Não sei ao certo o motivo, mas sei que uma boa parte da culpa está na “balela” que algumas empresas-de-três-letrinhas tentam empurrar sobre seus clientes e/ou desenvolvedores que utilizam suas tecnologias/ferramentas. Um bom exemplo disso é a tecnologia JSF, na qual temos a descrição abaixo dada pela Sun:

Ease-of-use being the primary goal, the JavaServer Faces architecture clearly defines a separation between application logic and presentation while making it easy to connect the presentation layer to the application code. This design enables each member of a web application development team to focus on his or her piece of the development process, and it also provides a simple programming model to link the pieces together. For example, web page developers with no programming expertise can use JavaServer Faces UI component tags to link to application code from within a web page without writing any scripts.

Por mais bonito que isto pareça ser, eu tenho o dever de alertar aos mais desavisados: isso dificilmente irá funcionar durante o desenvolvimento com JSF – para falar a verdade, eu acho muito dificil que qualquer tecnologia hoje em dia consiga prover tamanha separação de responsabilidade (entre designer e desenvolvedor) de forma transparente e produtiva.

Qualquer desenvolvedor web que se preze possui, ao menos, os conhecimentos mínimos sobre XHTML, css e javascript para entender e manter algum código escrito por outra pessoa ou mesmo por um web designer. Se você é um desenvolvedor web e não possui qualquer conhecimento sobre o que eu disse acima então já está mais do que na hora de você aprender.

Não subestimando os designers, pois eu conheço alguns muito bons, mas se levássemos essa separação de responsabilidades ao pé da letra você acha mesmo que eles conseguiriam desenhar excelentes interfaces utilizando apenas as taglibs dos componentes ou conjuntos de componentes JSF?

Alias, você acha mesmo que um designer teria produtividade ou conseguiria expressar sua criatividade limitado apenas a algumas dezenas de tags, por mais ricos que sejam os componentes, visualmente falando? Isso pode piorar ainda mais se este designer for obrigado a utilizar algum editor -com o qual ele nunca trabalhou- apenas por causa do suporte a code-completion para as tags dos componentes.

JSF é uma boa tecnologia, e por mais que ela nos forneça centenas de componentes, frameworks para templating de páginas e estes componentes possuam um sistema de skinning ainda assim no final das contas teremos XHTML (css e javascript também) gerado. Sendo, de duas, uma: ou o designer deve ter conhecimento sobre o código gerado pelos componentes ou ele deve ter conhecimento de como trabalhar com o suporte a skinnking dos componentes.

Qualquer que seja a opção acima, o designer estará com mais responsabilidades do que o necessário. Por isso é tão importante a interação entre um designer e um desenvolvedor para solucionar problemas decorrentes da tecnologia adotada.

Eu falo tudo isso por experiência própria, pois há alguns meses eu tive uma razoável dificuldade para aplicar o css, definido no prótotipo do sistema, nos componentes JSF da aplicação, atividade esta que deveria ser relativamente simples. Sim, o conjunto de componentes que eu utilizei suportava skinning, mas quem disse que isso é suficiente quando o XHTML gerado por alguns componentes mais complexos é totalmente diferente do XHTML escrito pelo designer?

Foram vários dias adaptando o css da aplicação e, ao mesmo tempo, discutindo e redefinindo com os designers alguns pontos do css do prótotipo para que no final tivessemos o resultado ideal. E com certeza eu não teria sucesso nesta atividade se não fosse pelos dois grandes designers da equipe, Carlinhos e Anderson, que sentaram ao meu lado algumas longas horas durante a semana para me ajudar.

Certamente que há casos onde não podemos contar com um designer na equipe, como:

  • projetos em que a presença do designer é inexistente na equipe e algum desenvolvedor precisa assumir mais este papel;
  • o designer faz parte da equipe, mas por algum motivo ele sempre encontra-se impossibilitado de interagir com ela nos momentos de maior necessidade;
  • ou nos piores casos, o protótipo da aplicação foi criado por outra empresa.

Para cada situação é possível chegarmos a uma solução milhares de vezes melhor do que apenas ignorar o problema de que não há um designer na equipe – mas não é esta a questão do post.

Enfim, é muita ingenuidade (ou falta de conhecimento) destas pessoas que acreditam que desenvolvedores e designers [ou quaisquer membros da equipe] não precisam colaborar entre si para alcançar um resultado ideal que agrade o cliente.

18 thoughts on “Não existe segredo: desenvolvedores e designers precisam colaborar entre si

  1. O grande problema é que muitas empresas acham que desenvolvedores são designers ou que deveriam ter tambem suas qualificações.
    Isso sempre aconteceu e nunca mudou.

    [s]

  2. JSF á uma das piores tecnologias que conheço para trabalhar esse lado de UI, é uma tencologia feita exclusivamente para Enterprisey Apps, chegou como Killer Tool/API/Framework e não vingou, essa é a verdade. Talves chegou tarde demais.
    O ponto que quero chegar é que o modelo component-based não funciona simplesmente nesse sentido e se você não tiver uma interação grande entre o designer e a equipe de desenvolvimento o processo será lentissimo.
    Algumas abordagens conseguimos sim isolar um pouco o trabalho do designer do desenvolvedor, ainda mais com frameworks ajax como JQuery [cm o JQuery UI e extensões], ExtJS, etc.

  3. JSF existe para aplicações Enterprisey e para se conseguir um design decente com a cara da empresa é necessário que desenvolvedor e designer sentem juntos, nisso tenho que concorda com você.

    Contudo, mesmo com frameworks como ExtJs o desenvolvedor e designer também precisarão colaborar entre si para acertar o design, mesmo que bem menos se compararmos ao JSF, pois ainda assim estes frameworks geram algum tipo de XHTML e css para renderizar os componentes visuais.

    Provavelmente o desenvolvedor (ou designer) deverá entender como trabalhar com o sistema de engine do ExtJs, caso contrário teremos sempre que utilizar o design padrão dele.

  4. @Bruno
    “Você conhece alguém que discorde disso?!?”

    É só o que vejo no nosso mercado. Empresas e profissionais menosprezando o trabalho (ou a necessidade) de designers na equipe.

  5. “o designer faz parte da equipe, mas por algum motivo ele sempre encontra-se impossibilitado de interagir com ela nos momentos de maior necessidade;”

    Na maioria das vezes isso é o que acontece.

    Sobre o comentário do Milfont, concordo plemamente, embora o JSF tenha sido a melhor tecnologia que eu já trabalhei. Lembro muito bem os problemas que tivemos no último projeto em que eu participei onde precisamos de um designer para refazer (pasme) todo o layout do sistema, pois o protótipo utilizado estava todo “quebrado” quando integramos com o JSF.

    A Pergunta que fica é: O que é mais fácil:
    – O Desenvolvedor comnhecer XHTML, CSS, JAVASCRIPT, etc,..??

    – O Designer começar a conhecer os componentes de determinado framework ou tecnologia (inclusive tenho que conhecer todos os principais existentes no mercado)?

    Quem dera fosse a segunda opção…

  6. Ótimo post Ponte.
    É realmente incrível como ainda existe essa separação, acho que deve ser por causa do efeito daquele papel de webmaster que existia a tempos atrás. Onde o webmaster era o desenvolvedor e design.
    Depois da “evolução” das plataformas ainda resta esse pensamento, e parece que algumas dessas pessoas ainda não se atualizaram.

    Agora uma coisa que você falou que achei muito bem colocada. Um programador WEB que não sabe as tecnologias WEB é realmente TRISTE. Se você desenvolve para WEB deve ter o mínimo de conhecimento nas tecnologias que a rodeiam: CSS, HTML, XHTML etc. Isso é o básico. Não precisa ser um design, mas precisa pelo menos conhecer a tecnologia.

    Já vários casos TRISTES e VERGONHOSOS de “profissionais” web que não sabiam a simples diferença de um para um .

    Esse post pode servir de aviso principalmente para quem está querendo entrar nessa área.

    Vou passar isso para os meus alunos…irá me poupar saliva 😉

    Abraços

  7. Putz O_o ele não coloca a tag HTML BR e nem a BR O-o putz….

    vamos lá novamente…

    “Já vi vários casos TRISTES e VERGONHOSOS de “profissionais” web que não sabiam a simples diferença de um TR(tag html) para um BR(tag html).”

  8. É a pura verdade, JSF é realmente um problema para os designers, no projeto que venho participando como desenvolvendor, havia um design na equipe que realmente não possuía muito tempo para interajir conosco, e aí que a produção ficou travada por umas 2, 3 semanas, até que eu peguei o que ele tinha desenhado, remontei e fiz tudo pensando já lá na frente, em como seria para transformar em JSF depois, em 3 dias estava tudo pronto. Eu vejo que o papel do designer se torna mais o de desenhar um esqueleto para o sistema, pois, a cara mesmo, completa do sistema, vai depender dos componentes utilizados e como eles serão estilizados, o que normalmente já é feito pelos desenvolvedores…

  9. Aqui onde trabalho existe até mais interação entre os programadores de interface e designers, do que com os de backend! hehe
    Mas já vi muuuito disso que tu fala acontecendo por aí!
    []s!

  10. Boa noite Raphael!

    Você saberia me dizer qual o motivo do erro abaixo:
    WARNING: phase(RESTORE_VIEW 1,com.sun.faces.context.FacesContextImpl@4134e0) threw exception: java.lang.NullPointerException null
    org.apache.myfaces.renderkit.html.util.AutoScrollPhaseListener.afterPhase(AutoScrollPhaseListener.java:52)
    com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:287)

    Onde utilizo o tomcat 6.0, JSF 1.2, RichFaces 3.0, Facelets, entre outros recursos….pois a página em questão é exibida normalmente, mas quando aciono um componente (SelectMeu) que está com o evento onchange = submit(); para que a página seja atualizada e os componentes não exibidos anteriormente sejam exibidos de acordo com a opção escolhida, ou seja, a primeira exibição é feita com sucesso mas a próxim da o erro citado acima.

    Você imagina o que pode ser?

    Obrigado cara!!!!

  11. Rs.. Você descreveu minha rotina de trabalho aqui na fábrica de software!

    Realmente é complicado vc ter um designer (formado em design mesmo) que tenha conhecimentos avançados de frameworks como richfaces, jsf e afins… o cara é bom fazendo layout e os código client-side (XHTML, CSS e javascripts mais simples).

    Mas tem como no meu caso, q “estou” designer aqui na fábrica. Tenho conhecimentos de usabilidade, interfaces, e tenho foco em desenvolvimento. Então fica muito mais fácil para os desenvolvedores daqui lidarem comigo. Um exemplo está sendo o projeto que a gente está fazendo q estamos testando o richfaces. Eu tô metendo a mão desde o layout do photoshop até as tags do rich, e tô me amarrando. Não tenho formação de designer, estou me formando na área de informática mesmo.

    A gente perde por não ter o cara sinistrão em designer mas ganha nessa conversa desenvolvedor x designer.

    Mas ai que tá, o cara q é designer de carteirinha vai querer se focar muito mais na parte visual… Enfim achar um cara q é fera em layout, photoshop, padrões web e ainda mandar bem nos frameworks do java… Tem q tirar o chapéu para ele.

    Mas ai, essa discussão tá muito legal. É o q acontece no dia-a-dia mesmo.

  12. Everyone wants cheap bait these days but the big problem is that
    cheap often means rubbish. The options within the area range from Myall Lakes houseboats, cottages, apartments,
    cabins and guests houses, lodges and hotels among many others.
    If you’re worried about your stored wine going bad in the heat of your boat, you need to
    invite me over.

    Check out my web page: Smart marine nz

Leave a Reply

Your email address will not be published. Required fields are marked *