Quando se trabalha construindo a experiência do usuário muito se fala de fazer wireframes. Eles, os wireframes, são os artefatos mais gerados por esse perfil de profissionais e é em boa parte aquilo que serve de guia para o desenvolvimento de aplicações e produtos. Entretanto, o que acontece é que muitas pessoas têm uma definição errada do que são os wireframes e como podemos utilizá-los.

Para mim, os wireframes atuam como uma forma de “dispositivo de pensamento” para a definição e exploração de um determinado problema. Para entender a utilidade dos wireframes é importante compreender a natureza do projeto. Eu uso os meus esboços e wireframes como meios para fazer movimentos exploratórios e avaliar as conseqüências desses movimentos.

Eu acho que é bastante comum para quem trabalha com experiência do usuário utilizar os wireframes para exibir o design como resolução de problemas. Para mim, o design através do uso de wireframes é uma busca em um espaço do problema de alternativas, é um processo de definição de problema, tanto quanto é um processo de resolução de problemas.

O processo de design poderia ser melhor descrito como passar de uma fase de divergência, por uma fase de transformação, para uma fase de convergência. Ao longo de cada fase, wireframes são apresentadas às partes interessadas para crítica e conversação.

Durante a fase divergente, as limitações e as possibilidades de situação de projeto são exploradas. Grande parte desta fase consiste em reunir informações e tentar entender e formular o problema de projeto e muitas vezes são informados pelos primeiros modelos conceituais que esbocei. Ao gerar um número de wireframes, posso explorar alternativas. Todas as ideias impossíveis e concebível são apresentados, testados e em muitos casos, atiradas para longe. Normalmente as visões iniciais são formadas durante esta fase.

Na fase de transformação, diminuímos o número de alternativas. Começamos a jogar fora idéias realmente ruins que eu poderia ter imaginado no início. É normalmente nesse ponto que eu volto e leio o documento de requisitos e tentar entender o ecossistema completo das necessidades dos stakeholders e de negócios, e tratar aqueles que estão no contexto do meu principal objetivo do projeto: uma solução elegante para a atividade principal do meu público-alvo.

É também neste momento que eu começo a lidar com as necessidades dos concorrentes. Também nesse momento começamos a envolver as partes interessadas, mas também trazer o designer gráfico, o líder de desenvolvimento, e o engenheiro de qualidade para que eles possam contribuir com o processo e dar mais idéias além de apontar falhas e limitações.

Finalmente, eu como designer, eu tenho que tomar a decisão de implementar o projeto em uma especificação. Durante a fase de “convergência”, eu crio dois ou três candidatos para consideração final. Eu uso anotações para embasar os wireframes durante os testes com partes interessadas e engenheiros de testes.

Resumidamente, enquanto wireframes são um produto bastante comum usado por profissionais de experiência do usuário para se comunicar design, é importante entendê-los, tanto quanto um processo de design como o resultado final, cada um com objetivos específicos. Ao classificarmos um wireframe como um processo em vez de um artefato, acredito que descobrimos que temos a oportunidade criar excelentes experiências para o usuário.

Existem também ferramentas específicas para a construção de wireframes mas essa é uma história a ser abordada em um outro post. 🙂

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Vimos anteriormente que o Design Centrado no Usuário (DCU) é uma das abordagens que podemos utilizar para criar nossas interfaces e, de uma forma mais completa, toda a experiência do usuário. Quando então definimos que o usuário é a pessoa mais importante no processo de criação, temos que levar em consideração que ele como ser humano é resultado de um construção de competências e experiências.

Além desses argumentos, um em especial que também faz parte da construção do usuário é a cultura. Definimos como cultura uma série de valores, metas, atitudes e práticas adotadas e compartilhadas por um país, sociedade ou grupo. Sabemos que a cultura define e caracteriza quem compartilha dela como, alguns gestos que sentimos e vivenciamos como por exemplo, quando estamos em uma viagem à outro país.

Até aí tudo bem, sabemos que algumas coisas são diferentes ou aparentam ser bem mais diferentes em outros lugares. Em algumas cidades do interior de países de primeiro mundo ainda podemos sair de casa sem precisar trancar as portas. Em países como nos Estados Unidos somos nós mesmos que devemos abastecer nossos carros e em seguida seguir para fazer o pagamento direto no caixa. Mas engana-se aquele que acha que é preciso ir tão longe para sentir essa diferença. Em um país com a dimensão como tão grande como o Brasil, são gritantes algumas diferenças entre como se vivem e o que se faz no norte e no sul.

Mas como esse tipo de cultura pode influenciar a criação de um produto ou interface. Há um tempo atrás eu tive a oportunidade de participar de um projeto em que a interface era controlada através de gestos de mão. Utilizavam-se alguns gestos pré-definidos para realizar operações em diversas aplicações. Surgiu-se então uma pergunta: “Quais gestos deveríamos usar para realizar cada operação?”. No estudo dos gestos, começamos a identificar que alguns gestos têm significados diferentes a depender da cultura. Tomemos por exemplo um gesto chamado de “V Sign” – ou como conhecemos aqui, o V da vitória – Ao realizar esse gesto com a palma da mão virada para quem o faz significa um insulto em países do Reino Unido.

Uma lenda sobre o porque desse gesto é considerado um insulto em tais países é a de que durante a batalha de Agincourt nas guerras de cem anos entre a França e a Inglaterra, os soldados franceses capturavam os arqueiros britânicos e cortavam os dedos indicadores e médios, impossibilitando-os de utilizarem os arcos. Passada a guerra, a rivalidade entre as duas nações perpetuou o gesto como uma forma de dizer “Veja, eu tenho meus dedos e você não”.

Observações ainda mais sutis podem ser observadas em culturas orientais. Algumas cores estão associadas à sensações e momentos diferentes. Um exemplo disso é que o luto é muitas vezes vivenciado em tecidos e cores brancas ao invés do preto tradicional do ocidente. Isso é em parte da percepção de que a morte não é o fim negro e escuro mais sim um momento de passagem e transcedência e com isso, a paz.

Essas nuances devem ser estudadas, capturadas e interpretadas de forma a adaptarmos nossos produtos ao uso correto por parte dessas culturas. Isso significa que cores, orientação do texto, símbolos, convenções métricas e tudo mais devem ser levadas em consideração nessa definição. E vocês, o que mais conseguem lembrar?

Olá mais uma vez. Hoje resolvi falar um pouco sobre um dos maiores dilemas para todos aqueles que querem mudar o mundo mas precisam de alguém para financiar essa mudança. Sim, somos nós, heróis de TI, que com muito esforço utilizamos muitas vezes de recursos que não existem, tempo que nunca é suficiente  e trabalhos que não são sempre reconhecidos.

Um dos maiores dilemas entretanto, é quando nos deparamos com a seguinte situação: Após uma série de estudos, definições e várias sessões de brainstorm, a equipe decidiu adotar a solução A. Entretanto, por algum motivo (que normalmente nem chega ao time) o cliente – que é quem está pagando – decidiu que para todos os envolvidos (usuários finais incluídos) é melhor que seja adotada a solução B. Soou familiar? Como procedemos nesses casos? Por que isso acontece?

Vou tentar responder de trás para frente.

Antigamente, o desenvolvimento de software tinha o foco muito diferente do que temos hoje em dia. Na época em que se alguém quisesse usar um software de planilha eletrônica tinha que recorrer ao Lotus 1-2-3 e, consequentemente, não havia a concorrência que temos hoje, o usuário era por muitas vezes refém de uma situação em que ou ele aprendia a utilizar aquela ferramenta (normalmente lendo um manual extenso e altamente técnico) ou “fazia na mão”. Isso acontecia principalmente porque quem projetava os sistemas eram pessoas que estavam naquele meio comumente (desenvolvedores de software). O que isso quer dizer? Quer dizer exatamente que se o usuário final não tivesse as mesmas habilidades de um programador, não conseguiria usar de forma satisfatória. Isso acontecia porque esse tipo de abordagem – em que o cliente está em foco e o sistema é desenvolvido baseado nos requisitos e desejos do mesmo – se baseia em premissas como:

• Ênfase no funcionamento do sistema
• Especialistas (desenvolvedores, designers, testers) trabalhando de forma isolada
• Não há validação do usuário até o primeiro release
• Visão de qualidade no produto (ex. número de bugs)

Diferentemente, temos hoje uma abordagem em que o sistema é projetado baseado nos interesses dos usuários que irão utilizar o produto que está sendo desenvolvido. Analogamente, temos então que o design centrado no usuário tem como premissas:

• Ênfase na interação com o usuário
• Equipes multidisciplinares trabalhando conjuntamente
• Validação por parte dos usuários antes mesmo de escrever a primeira linha de código
• Visão de qualidade baseada na satisfação do usuário

Vemos então que esse tipo de abordagem – a do design centrado no usuário – tem como foco trazer o usuário para dentro do processo. Mas e quando os usuários querem uma coisa diferente do que o cliente quer? Bom, nesse caso o mais prudente é tentar convencer o cliente da importância e do impacto que é ter um projeto que está alinhado com o desejo dos usuários finais. Um produto que não atende as expectativas não vai ser vendido (ou baixado) e não vai gerar lucros e/ou visibilidade. Contudo, nem sempre o cliente vai querer ceder e é aí que entra toda a experiência do profissional para saber lidar com a situação. Não se preocupe se não conseguir, nem todos querem mudar o mundo. Alguns simplesmente não podem fazê-lo.

Se tudo isso soou familiar, não se preocupe. Isso é sinal de que você está no mundo real.

Olá pessoal, a partir de hoje estarei com vocês aqui no BdB pra falar um pouco sobre usabilidade e outros tópicos relacionados com design. Como primeiro tópico, resolvi abordar minha percepção do que é usabilidade.

Hoje, mais do que nunca, usabilidade é uma palavra recorrente em vários dicionários. Para todos nós que estamos diariamente no universo de TI é ainda mais evidente notar o quanto o crescente uso dessa palavra causa, por muitas vezes, mais confusão do que benefícios. Mas afinal, o que é usabilidade?

Por definição da própria Wikipédia, podemos definir usabilidade, entre outras coisas, como a facilidade de uso de “algo” por um ser humano. Normalmente associamos esse “algo” a um objeto, ferramenta ou, no nosso caso, um software. Mas, engana-se quem pensa que usabilidade – seu estudo e também sua melhoria – se restringe a esses itens. De fato, usabilidade também pode ser aplicada em elementos como um manual técnico ou objetos mecânicos portas, carros e muitos outros.

Além disso, um conceito que normalmente fica mal-entendido é que usabilidade faz parte de um conceito mais amplo dentro do design, que é o conceito de experiência do usuário. UX (de User eXperience) é um conceito um pouco mais amplo do que a própria usabilidade. Enquanto o primeiro se concentra apenas em aspectos técnicos como legibilidade, facilidade de uso e muitas coisas, o segundo – a experiência do usuário – tende a ser mais subjetiva, englobando diversas disciplinas como cognição, acessibilidade, arquitetura da informação e a própria usabilidade.

Bom, a partir dos próximos posts vamos começar a entrar um pouco em cada uma das áreas que formam a UX e descobrir o quanto e como elas podem afetar nossos produtos. Até breve!