Núcleo de User Experience

Esboçando Idéias

Posted on: setembro 8, 2009

post_150

Quantas vezes você já teve que fazer ou refazer dezenas de entregas de wireframes  por causa de ajustes só pensados depois? E se você passou por isso, com certeza pensou em algum momento que o esforço envolvido foi grande demais em proporção ao imaginado no início do projeto. Ainda, você pode ter lido sobre (ou trabalhado com) ‘protótipos de papel’ (chamados neste post de ‘esboços’, simplesmente), mas ficou sem saber ao certo como eles se integram e complementam a criação de wireframes.

É aí que entra Bill Buxton e mesmo que seu livro seja voltado prioritariamente a designers de produto, traz algumas idéias – e desafios – para os AI’s e especialistas em UX. Bill Buxton é músico de formação e tem uma carreira de mais de 30 anos em pesquisa sobre os aspectos humanos da tecnologia. É hoje o principal pesquisador do Microsoft Research (centro de pesquisa da Microsoft). Seu último livro, ‘Sketching user experiences’ (‘Esboçando as experiências do usuário’, em tradução livre) de 2007, é uma tentativa de analisar diversos aspectos do design em busca da atividade comum a todo tipo de designer, independentemente da área em que atuem e através desta investigação e demonstração de casos, definir o que seja o “pensar design”. E o argumento de Buxton é que esta atividade é esboçar. Buxton deixa clara a necessidade de esboçar, esboçar e esboçar novamente. A etapa mais arquetípica de um processo de design, traria também economia à organização já que “o custo de planejar – e replanejar – antes de dar sinal verde a um projeto é ínfimo, se comparado ao de um produto mal pensado ou com defeito.”

Buxton sugere que ideação e prototipação sejam processos diferentes. Durante a ideação o objetivo é fazer surgir o maior número possível de idéias encadeadas, enquanto que na prototipação o objetivo é limitar as idéias às melhores. Ok, mas e como deixar claras as diferenças entre essas fases para todos do time? Pode ser uma tarefa bem difícil argumentar a necessidade de um período longo de pesquisa e ideação (em que só sejam produzidos “rabiscos”) para um grupo de colegas em que a maioria não é designer, especialmente se já os seus primeiros wireframes tiverem um nível de fidelidade tal que sugiram um trabalho ‘acabado’ mesmo que tenham sido produzidos apenas para que os demais possam visualizar suas primeiras ideias.

Assim, o livro acaba por nos oferecer um possível caminho da ideação à prototipação, diferenciando as intenções de cada tipo de material produzido, conforme o esquema abaixo:

Do Esboço              ao Protótipo
Evocar                        Ensinar
Sugerir                        Descrever
Explorar                     Refinar
Questionar                 Responder
Propor                         Testar
Provocar                    Resolver
Tentar                         Especificar
Tolerar                       Retratar

“Todos podem contribuir com o design  – e isso evidentemente inclui o usuário do produto final – mas nem todos são designers.”

Para isso serve a fase de ideação: para que ideias possam ser livremente propostas e visualizadas, de forma rápida e barata. Claro que há muito mais nesta fase do que os esboços em si, inclusive o exercício da capacidade de contar histórias e atuar nelas de forma livre a fim de explicar alguma experiência de forma contextualizada ou mesmo a de criar brincadeiras entre todos para ilustrar um ponto. Os esboços seriam válidos na medida em que se mantenham: rápidos, baratos, fáceis de jogar fora e refazer, variados, fluidos, com o mínimo de detalhes e abertos a diversas interpretações. No entanto, o autor lembra que “sem um verdadeiro espírito de time a coisa não anda. É preciso que áreas distintas sejam complementares e todas contribuam criativamente para o projeto.” Somente depois de esses esboços serem colaborativamente discutidos entre todos os envolvidos é que entra a habilidade que só o designer terá, a de saber filtrar todas as contribuições dadas, e esboçar soluções que ofereçam a melhor experiência para o usuário final.

Atualizado em 08/09/2009

Capa do livroSketching User Experiences

Capa do livro'Sketching User Experiences'

Sketching User Experiences: getting the design right and the right design.
William Buxton
Focal Press / Morgan Kaufmann
ISBN – 13: 978-0-12-374037-3

fonte da imagem: http://wireframes.linowski.ca/2009/07/hybrid-stickyframes/

3 Respostas to "Esboçando Idéias"

Eu tb curto chamar os rabiscos de protótipo de baixa fidelidade, este termo eu aprendi na pós-graduação.😛

É interessante a linha argumentativa do Buxton, e até, quem sou para discordar. Porém, ela não se aplica à realidade de todos. E não sei o q vc acha (gostaria de saber :D) mas para mim, essas fases compartimentadas cabem mais em um time de design de interação do que em um time de AI + DI (q é a realidade de 99% dos profissionais brazucas, em que as atividades de ambos se misturam).

Muitas vezes, as sketches são os únicos documentos de prototipação que o projeto terá. Protótipos de baixíssima fidelidade, porém, protótipos.

Em empresas que fazem uso de metodologias ágeis, os rabiscos também servem como documentação e, em muitos casos, o protótipo de alta fidelidade será a versão em HTML final do projeto (já com o design) e os ajustes serão feitos ali. (E cá entre nós, em quase todos os projetos, mesmo os que fazem uso de documentação complexa, o protótipo real mesmo só se dá com o produto quase finalizado, e ai entra o trabalho de um bom time de QA. E não quer dizer que o projeto teve erros de planejamento e de AI, é a natureza do projeto e do ambiente web).

Estou tendo a oportunidade de implementar com meu time dois projetos fazendo uso de sketches e, em muitos casos, são a melhor saída, sobretudo em casos em que o prazo manda ou em projetos com equipes MUITO multidisciplinares.

No projeto que atuo hoje, não tivemos o “tempo” necessário para sketches antes de iniciar a criação de wireframes. Por ser uma empresa de grande porte, documentação super complexa, especificações funcionais enormes, estamos utilizando do Scrum para constantes alterações nos wireframes.

Muitas vezes, como é o meu caso citado, por ser um projeto longo e de prazo apertado (2 anos de desenvolvimento), trabalhamos junto com a equipe de analistas de requisitos para adequar os wireframes quase que em tempo real. Isso dá muito retrabalho, sem contar que é super cansativo.

Fica dica: analistas de requisitos + AI + wireframes não funcionam ao mesmo tempo! Vamos caminhar conforme dita o processo, se possível!

Eu trabalho em uma grande multinacional, e os projetos aqui independentes dos prazos serem sempre apertados ou não, tem muuuuita documentação. É regra, e temos muitos formulários a preencher, mas não existem nenhuma documentação com relação a AI e UX. O que é uma pena.

Nos meus projetos sempre tento realizar (wireframe, fluxos, mapa) na documentação funcional, e o ganho em aprovação da proposta, menos indice de refação, é muito significativo.

Gerentes!!! Acordem para a necessidade de especialistas em Arquitetura de Informação e Usabilidade para seus projetos de TI.rs.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

NUX no Flickr

Participantes EBAI 2009

Carol e Guilhermo

Maria Ercília

EBAI 2009

EBAI 2009

EBAI 2009

Mais fotos

Twitter: Siga-nux

%d blogueiros gostam disto: