Seguimos então com a análise deste problema: como escolher entre duas interfaces que dão suporte à mesma tarefa? Para quem não está acompanhando, as interfaces em questão são mostradas nas figuras 1 e 2.
Figura 1, à esquerda. Interface com drag n´drop. O usuário arrasta um conceito para a área ao lado da tree, e o local (y) onde ele largou o conceito define o quanto o material está associado ao conceito.
Figura 2, à direita. Interface com HSlider. O usuário seleciona um item na Tree. Na tela ao lado, há uma HSlider, que o usuário usa para dizer o quanto o conceito se asssocia com o material. Na Tree se podem ser, ao lado dos conceitos que estão associados com o material, o quanto (%) o conceito se associa ao material.
Estas interfaces foram avaliadas utilizando um conjunto de heurísticas e o KLM. Estes são dois métodos que pertencem mais ao design que ao desenvolvimento, e que são usados para informar a escolha. No entanto, eles não consideram a complexidade da implementação, que é um fator determinante na escolha. Por este motivo, pedi para alguns colegas avaliarem as duas interfaces e dizerem o quanto uma interface é mais trabalhosa que a outra. Além disso, pedi que, se possível, comentassem cada uma das propostas.
Pedi que a todos os avaliadores que considerassem a implementação na mesma linguagem de programação (AS3, usando Flex). Todos têm pelo menos 2 anos de experiência com a linguagem, e todos são desenvolvedores reconhecidos (à exceção de um, todos são moderadores de listas com mais de 2000 membros). Eles avaliaram o seguinte cenário:
/*******************************************************
CENÁRIO
O projeto é uma materioteca, usada para auxiliar no processo de seleção de materiais. Será usada por designers, arquitetos e eventualmente, por engenheiros.
A tela em questão é para associar conceitos a um dado material que está sendo criado pelo administrador da materioteca (você :0). Estes conceitos são palavras, e são características abstratas do material. Pense que isso pode ser importante para um designer fazer sua escolha. Exemplos de conceitos podem ser: inovador, sensual, moderno, vibrante, vulgar, barato etc.
Você não irá criar conceitos, apenas usar os que estão disponíveis.
As implementações possíveis estão nos pngs anexos*
*******************************************************/
O resultado até agora é:
- Desenvolvedor 1 -> Interface A(Drag n´ Drop)=2 * Interface B (HSlider)
- Desenvolvedor 2 -> Interface A(Drag n´ Drop)=10 * Interface B (HSlider)
- Desenvolvedor 3 -> Interface A(Drag n´ Drop)=4 * Interface B (HSlider)
- Desenvolvedor 4 -> Interface A(Drag n´ Drop)=3 * Interface B (HSlider)
Além disso, alguns ainda enviaram comentários:
Desenvolvedor 1
- “Preferiria implementar a segunda forma, acho que é bem mais intuitiva para o usuario”.
- “[...] Ok… pode ser até mais dificil de implementar, mas a real importancia não é a dificuldade da implementação mas a experiencia do usuario em usar essa app”.
No email de resposta ainda haviam exemplos de interfaces que suportam a mesma tarefa, referidos pelo Desenvolvedor 1 como sendo de pior qualidade. Os dois exemplos estão mostrados abaixo.
—————————————————–
| Conceito A | <combo box de %> | Selecione o valor percentual de associação
—————————————————–
| Conceito B | <combo box de %> |
—————————————————–
| Conceito G | <combo box de %> |
—————————————————–
Ou pior ainda… :
——————————————————————
| Conceito A | <textInput / NumericStepper> | Digite o valor percentual de associação
——————————————————————
| Conceito B | <textInput / NumericStepper> |
——————————————————————
| Conceito G | <textInput / NumericStepper> |
——————————————————————
Desenvolvedor 3
- “Então, olhando as duas opções, a primeira usando um HSlider me parece muito ‘tradicional’, mais fácil de manipular mas mais difícil de analisar o todo. Gosto mais da segunda opção, apesar de mais complexa para o usuário final manipular”.
- “Obviamente que o usuário final não está tão acostumado com o drag and drop nos softwares como ele usa no sistema operacional, mas dá uma dimensão muito melhor, acredito até que ele acharia ruim essa opção em um primeiro momento, mas depois de começar usar se sentiria mais confortável em poder analisar todos os conceitos de determinado material de uma única vez.”
- Em uma conversa via MSN, este desenvolvedor sugeriu uma “solução intermediária”, na qual ao arrastar o conceito para o Canvas, uma janela é criada, com uma barra deslizante, usada para definir a associação ao conceito.
Desenvolvedor 4
- “Usaria o hslider/vslider em vez do cenário do canvas”.
- “Bem, colocaria os itens em ordem decrescente de %, facilitando assim ao usuário a associação visual.”**
- “Uma sugestão também é em vez de usar um slider, usar um itemRenderer que mostre um NumericStepper. Na minha opinião usaria o NumericStepper, porque daria menos trabalho sem perder a funcionalidade e agregando maior agilidade para o usuário. Usando NumericStepper como itemRenderer acredito que levaria menos tempo ainda que o slider, talvez 0.6x, além que área que deixaria de ser usada pelo slider poderia ser usada para outra coisa.”
Dois desenvolvedores manifestaram preferência pela interface com Drag n´Drop, um pela interface com HSlider e um não manifestou preferência. No entanto, todos afirmaram que a interface com Drag n´Drop é mais demorada.
Assim como as avaliações anteriores, estes pareceres não foram conclusivos em favor de nenhuma das opções, pois, mesmo que dois desenvolvedores tenham manifestado clara preferência pela interface com Drag n´Drop, é preciso avaliar se o tempo de implementação é um fator importante.
Cada vez mais acho que vou precisar de um protótipo para dar o veredicto :0)
Acompanhe!
PS: Se você também quer mandar sua estimativa e seus comentários, comente aqui ou mande por email. Vou incorporar no post.
* As imagens do início deste post, com descrições sobre detalhes da implementação e sugestões para os algoritmos.
** No HSlider
November 16th, 2009 at 8:27 am
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.
November 16th, 2009 at 10:17 am
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.
November 16th, 2009 at 10:24 am
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).