Comments on: Escolhendo a melhor interface: tempo de desenvolvimento http://www.gabriela.trindade.nom.br/2009/11/escolhendo-a-melhor-interface-tempo-de-desenvolvimento/ Thu, 22 Jul 2010 00:55:12 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Gabriela http://www.gabriela.trindade.nom.br/2009/11/escolhendo-a-melhor-interface-tempo-de-desenvolvimento/comment-page-1/#comment-1163 Gabriela Mon, 16 Nov 2009 13:24:17 +0000 http://www.gabriela.trindade.nom.br/?p=709#comment-1163 Ah, e para falar em divisão de equipes (dev + designers), aqui vai um artigo (atualizado!) do Nielsen. http://www.useit.com/alertbox/agile-user-experience.html Sabe porque o Nielsen faz tanto sucesso? Porque ele mede! Já ouviu designer e programador falar de usabilidade? É só papo... Medir que é bom, nada... Gostem ou não, o Nielsen fala sobre o que ele mede. Se for o caso, temos que contestar a forma como ele mediu (o que não está nos aletrboxes, e sim nos diversos artigos que ele publica em congressos científicos). Ah, e para falar em divisão de equipes (dev + designers), aqui vai um artigo (atualizado!) do Nielsen.
http://www.useit.com/alertbox/agile-user-experience.html
Sabe porque o Nielsen faz tanto sucesso? Porque ele mede! Já ouviu designer e programador falar de usabilidade? É só papo… Medir que é bom, nada… Gostem ou não, o Nielsen fala sobre o que ele mede. Se for o caso, temos que contestar a forma como ele mediu (o que não está nos aletrboxes, e sim nos diversos artigos que ele publica em congressos científicos).

]]> By: Gabriela http://www.gabriela.trindade.nom.br/2009/11/escolhendo-a-melhor-interface-tempo-de-desenvolvimento/comment-page-1/#comment-1162 Gabriela Mon, 16 Nov 2009 13:17:08 +0000 http://www.gabriela.trindade.nom.br/?p=709#comment-1162 Realmente, a idéia de especificar tudo antes e entregar o tal pdf de 44 pgs não tem se mostrado eficiente. E, se os designers estão agindo assim, talvez seja mesmo por alguma questão de "reserva de mercado", uma atitude que, no fim das contas, não vai nos levar a lugar algum. Conhecer o ambiente no qual será implementado o aplicativo certamente dá uma visão mais nítida ao desenvolvedor coisa que - infelizmente - não podemos pedir dos nossos designers generalistas. Vendo a coisa "de dentro" (pois eu sou uma das pessoas que forma designers), percebo que os livros que estão sendo lidos são os mesmos da época do surgimento do mouse. Também percebo a aceitação da idéia de que o conhecimento do designer não engloba a técnica (daí a falta de conhecimento específico) nem a análise (daí a dificuldade em compreender os problemas). O designer tem apneas a função de sintetizar sua percepção numa solução, e é "dever" dos engenheiros implementar esta idéia. É uma idéia romântica porque, como sabemos, não é assim que funciona em indúsria alguma. Só que é mais fácil formar designers assim, e depois deixar que eles mesmos "sintam" na carne os problemas da vida real. Não é só com os programadores que temos "bronca". É com os engenheiros de material, de produção, com todo mundo! Não é a toa que fazem piada da gente... Olhando a coisa de dentro, como tenho tido oportunidade de olhar, percebo que falta mesmo um pouco especialização para a gente... Não acho que seja possível ser um designer competente sem conhecer a tua área muito a fundo, porque design é uma das coisas mais difíceis de ser feita. Sério. Já pensou o que significa ter que antever todos os desdobramente de um problema que tu não conhece? QUe diabos de emprego é esse? Pois é justamente o que um designer faz. E foi isso que o cara que te deu as 44 pgs tentou fazer. Passaram milhares de coisas na cabeça dele enquanto ele desenhava, ele tomou milhares de decisões para chegar na solução que ele te entregou. Mas - talvez - a falta de conhecimento da tarefa e da plataforma impediram que ele entendesse que não seria possível especificar tudo de uma vez só. E eu acho que era isso que eu estava tentando mostrar - para os designers e para os programadores - que é um balanço extremamente delicado de conseguir. Até onde vale a pena investir em design? Onde estão os limites de atuação entre os dois profissionais? Antes de entrarmos no campinho, a coisa era mais fácil. Agora nós abrimos um mundo de possibilidades novas - e percebo que vocês têm aceitado bem estas idéias - só que junto com isso vieram problemas novos, para os quais nunca teremos uma resposta pronta (duvido que vamos conseguir design patterns pra UX, ainda que estejam tentando). De qualquer forma, acho que o mercado para nós vem evoluindo, e que estamos - todos nós - amadurecendo. Realmente, a idéia de especificar tudo antes e entregar o tal pdf de 44 pgs não tem se mostrado eficiente. E, se os designers estão agindo assim, talvez seja mesmo por alguma questão de “reserva de mercado”, uma atitude que, no fim das contas, não vai nos levar a lugar algum.
Conhecer o ambiente no qual será implementado o aplicativo certamente dá uma visão mais nítida ao desenvolvedor coisa que – infelizmente – não podemos pedir dos nossos designers generalistas.
Vendo a coisa “de dentro” (pois eu sou uma das pessoas que forma designers), percebo que os livros que estão sendo lidos são os mesmos da época do surgimento do mouse. Também percebo a aceitação da idéia de que o conhecimento do designer não engloba a técnica (daí a falta de conhecimento específico) nem a análise (daí a dificuldade em compreender os problemas). O designer tem apneas a função de sintetizar sua percepção numa solução, e é “dever” dos engenheiros implementar esta idéia. É uma idéia romântica porque, como sabemos, não é assim que funciona em indúsria alguma. Só que é mais fácil formar designers assim, e depois deixar que eles mesmos “sintam” na carne os problemas da vida real.
Não é só com os programadores que temos “bronca”. É com os engenheiros de material, de produção, com todo mundo! Não é a toa que fazem piada da gente… Olhando a coisa de dentro, como tenho tido oportunidade de olhar, percebo que falta mesmo um pouco especialização para a gente… Não acho que seja possível ser um designer competente sem conhecer a tua área muito a fundo, porque design é uma das coisas mais difíceis de ser feita. Sério. Já pensou o que significa ter que antever todos os desdobramente de um problema que tu não conhece? QUe diabos de emprego é esse? Pois é justamente o que um designer faz. E foi isso que o cara que te deu as 44 pgs tentou fazer. Passaram milhares de coisas na cabeça dele enquanto ele desenhava, ele tomou milhares de decisões para chegar na solução que ele te entregou.
Mas – talvez – a falta de conhecimento da tarefa e da plataforma impediram que ele entendesse que não seria possível especificar tudo de uma vez só.
E eu acho que era isso que eu estava tentando mostrar – para os designers e para os programadores – que é um balanço extremamente delicado de conseguir. Até onde vale a pena investir em design? Onde estão os limites de atuação entre os dois profissionais?
Antes de entrarmos no campinho, a coisa era mais fácil. Agora nós abrimos um mundo de possibilidades novas – e percebo que vocês têm aceitado bem estas idéias – só que junto com isso vieram problemas novos, para os quais nunca teremos uma resposta pronta (duvido que vamos conseguir design patterns pra UX, ainda que estejam tentando).
De qualquer forma, acho que o mercado para nós vem evoluindo, e que estamos – todos nós – amadurecendo.

]]> By: Beck Novaes http://www.gabriela.trindade.nom.br/2009/11/escolhendo-a-melhor-interface-tempo-de-desenvolvimento/comment-page-1/#comment-1161 Beck Novaes Mon, 16 Nov 2009 11:27:22 +0000 http://www.gabriela.trindade.nom.br/?p=709#comment-1161 Vou pensar em voz alta enquanto escrevo este comentário. Eu, particularmente, peso a complexidade versus o valor agregado. Em outras palavras eu não me importo com coisas complexas desde que eu veja um valor agregado grande. Um problema que eu vejo nestas definições de Interface pelos Arquitetos de Informação/Designers de Interação é que muitas vezes isto é feito num processo em cascata. Eles definem no início e os programadores têm que implementar. Acontece que eu acredito que é impossível chegar a uma boa solução sem considerar a tecnologia. Vou dar um exemplo para deixar claro o que eu quero falar. Estou trabalhando num projeto com onde o Arquiteto de Informação da nossa empresa parceira em Nova York nos enviou um PDF com 44 páginas de wireframe. Os wireframes eram muito bem detalhados, explicados e num primeiro contato parecia ser realmente um excelente trabalho. E como geralmente ocorre, aquilo estava "definido" e deveria ser feito daquele jeito. Mas quando começamos a implementação percebemos um monte de falhas que eram implicações do nosso melhor entendimento do problema que evoluia na medida em que desenvolvíamos o projeto. Com certeza o profissional de UX não teria como prever aqueles problemas. Seja por falta de melhor entendimento do problema no inicio do projeto (o que é normal) ou por falta de conhecimento do modo de funcionamento da tecnologia que seria usada para implementar a interface, o fato é que no final das contas o profissional de UX focava em detalhes pequenos de grande complexidade e que não agregavam tanto valor. E sempre que precisa encontrar boas soluções para problemas complexos foi onde os desenvolvedores criaram coisas realmente boas, basicamente por conhecer melhor a tecnologia e saber que aquelas coisas eram fáceis e agregavam muito. Nos últimos dias tenho pensado se não seria possível o profissional de UX atual mais como um consultor, que ajuda o técnico encontrar melhor solução. Na minha realidade não parece que funciona o profissional de UX definir com o pouco conhecimento do problema (no início) e o pouco conhecimento da tecnologia. Enfim, acredito que sem conhecer a tecnologia o profissional de UX não tem o universo de restrições necessários para levá-lo a melhor solução. Por isso, atuando como um consultor do técnico que conhece estas restrições talvez possamos ter o melhor dos dois mundos. Além disso o Arquiteto de Informação/Designer de Interação parece como todo profissional parece que tem alguns dogmas que podem prejudicar o desenvolvimento. O número de cliques é um deles. Nos wireframes que vi percebi que para reduzir o número de cliques a complexidade aumentava, o software ficava até mais confuso, a interface ficava mais inconsistente e mais feia. Mas, não, tinha que ter o menor número de cliques possível. Outra coisa que atrapalha muito é confundir papel com hierarquia. Eu sou a favor da dialética. Não é porque você é profissional de UX que a sua palavra tem que ser lei. Muitas vezes o desenvolvedor tem boas idéias de UX e isto tem que ser colocado na balança. Vejo muito profissional de UX contra-argumentar com uma idéia boa só porque leu alguma coisa num livro do Jakob Nielsen. Como geralmente isso dá a impressão que este cara "conhece mais" ele pode levar vantagem numa argumentação. Bem... fui falando o que veio à cabeça. Desculpe as idéias um tanto desconexas mas espero ter contribuído de alguma forma. Vou pensar em voz alta enquanto escrevo este comentário.

Eu, particularmente, peso a complexidade versus o valor agregado. Em outras palavras eu não me importo com coisas complexas desde que eu veja um valor agregado grande.

Um problema que eu vejo nestas definições de Interface pelos Arquitetos de Informação/Designers de Interação é que muitas vezes isto é feito num processo em cascata. Eles definem no início e os programadores têm que implementar. Acontece que eu acredito que é impossível chegar a uma boa solução sem considerar a tecnologia. Vou dar um exemplo para deixar claro o que eu quero falar.

Estou trabalhando num projeto com onde o Arquiteto de Informação da nossa empresa parceira em Nova York nos enviou um PDF com 44 páginas de wireframe. Os wireframes eram muito bem detalhados, explicados e num primeiro contato parecia ser realmente um excelente trabalho. E como geralmente ocorre, aquilo estava “definido” e deveria ser feito daquele jeito. Mas quando começamos a implementação percebemos um monte de falhas que eram implicações do nosso melhor entendimento do problema que evoluia na medida em que desenvolvíamos o projeto. Com certeza o profissional de UX não teria como prever aqueles problemas. Seja por falta de melhor entendimento do problema no inicio do projeto (o que é normal) ou por falta de conhecimento do modo de funcionamento da tecnologia que seria usada para implementar a interface, o fato é que no final das contas o profissional de UX focava em detalhes pequenos de grande complexidade e que não agregavam tanto valor. E sempre que precisa encontrar boas soluções para problemas complexos foi onde os desenvolvedores criaram coisas realmente boas, basicamente por conhecer melhor a tecnologia e saber que aquelas coisas eram fáceis e agregavam muito.

Nos últimos dias tenho pensado se não seria possível o profissional de UX atual mais como um consultor, que ajuda o técnico encontrar melhor solução. Na minha realidade não parece que funciona o profissional de UX definir com o pouco conhecimento do problema (no início) e o pouco conhecimento da tecnologia. Enfim, acredito que sem conhecer a tecnologia o profissional de UX não tem o universo de restrições necessários para levá-lo a melhor solução. Por isso, atuando como um consultor do técnico que conhece estas restrições talvez possamos ter o melhor dos dois mundos.

Além disso o Arquiteto de Informação/Designer de Interação parece como todo profissional parece que tem alguns dogmas que podem prejudicar o desenvolvimento. O número de cliques é um deles. Nos wireframes que vi percebi que para reduzir o número de cliques a complexidade aumentava, o software ficava até mais confuso, a interface ficava mais inconsistente e mais feia. Mas, não, tinha que ter o menor número de cliques possível.

Outra coisa que atrapalha muito é confundir papel com hierarquia. Eu sou a favor da dialética. Não é porque você é profissional de UX que a sua palavra tem que ser lei. Muitas vezes o desenvolvedor tem boas idéias de UX e isto tem que ser colocado na balança. Vejo muito profissional de UX contra-argumentar com uma idéia boa só porque leu alguma coisa num livro do Jakob Nielsen. Como geralmente isso dá a impressão que este cara “conhece mais” ele pode levar vantagem numa argumentação.

Bem… fui falando o que veio à cabeça. Desculpe as idéias um tanto desconexas mas espero ter contribuído de alguma forma.

]]>