usabilidade
Se você está curioso por algumas estatisticas sobre o ano de 2013, aqui está, basta clicar na figura abaixo e seguir o link 😉
Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)
Pedacinho de texto das estatisticas:
The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.
No post passado comentei um pouco sobre wireframes e como abordá-los como processos e não apenas como artefatos. No final do artigo, mencionei que existem algumas ferramentas que normalmente são utilizadas pelos profissionais de UX. Antes de falar um pouco sobre ferramentas, vamos relembrar um pouco sobre o que é prototipação.
A fase de prototipação é aquela em que construímos um ou mais modelos para avaliar (no caso do design centrado no usuário, junto ao usuário) se a solução que desenvolvemos ainda é valida do ponto de vista de tecnologia, negócios e dos próprios usuários. Esses protótipos podem ter várias fidelidades, a depender basicamente do que queremos comunicar com aquele wireframe e o tempo disponível.
Se queremos comunicar apenas a ideia geral por trás da solução, podemos utilizar wireframes de baixa fidelidade. Eles representam um estágio inicial no desenvolvimento do produto e carecem propositalmente de detalhes mais profundos. Por outro lado, quando queremos contemplar mecanismos e informações mais detalhadas normalmente utilizamos wireframes de alta fidelidade.
Uma das principais ferramentas para o desenvolvimento do primeiro tipo citado – os wireframes de baixa fidelidade – é o Balsamiq. Essa ferramenta é bem simples e fácil de ser utilizada e pode gerar wireframes de maneira rápida apenas arrastando os componentes diretamente da barra. Por outro lado, desenvolver interações nesses wireframes é praticamente impossível, visto que o único mecanismo para tal é a troca de páginas. A simplicidade da ferramenta se reflete no seu preço de US$79.
Existem muitas ferramentas que seguem a linha do Balsamiq mas que têm um ou outro recurso a mais ou a menos. Algumas também utilizadas e que têm esse diferencial são: Mockingbird (planos a partir de US$9/mês), iPlotz (planos a partir de US$15/mês), MockFlow (US$59/ano) e ForeUI (US$150).
Quando se fala de prototipação em alto nível, temos também várias ferramentas. Entre elas uma merece destaque, o Axure RP. Atualmente ela se apresenta como talvez a mais usada e completa. Podendo gerar mais do que wireframes estáticos, o Axure RP chega a versão 6.5 com a possibilidade de inserir interações complexas com o uso até de variáveis e rotinas em javascript. Tal flexibilidade e poder tem o seu preço. Nesse caso, o preço é de US$549.
Independente da ferramenta, prototipação é algo trabalhoso. Em alguns casos, o bom e velho lápis e papel ainda vai ser o jeito mais fácil de comunicar aos stakeholders qual é a melhor solução para eles, em outros, quando não houver escolha e algo formal deve ser entregue, resta escolher a melhor ferramenta.
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.
Quando recebi o convite para começar a escrever no BdB fiquei muito feliz por dois motivos. Primeiramente, sempre tive vontade de escrever sobre o meu trabalho na área de UX. Compartilhar um espaço junto com as feras que aqui escrevem só tornou esse desejo ainda mais prazeroso. Em segundo lugar, escrever uma coluna de UX num blog com colunas em testes representou (e ainda representa) um desafio interessante tanto do ponto de vista de designer como de colunista.
Antes de mais nada, gostaria de contar um pouco minha trajetória. Trabalhei um pouco mais de três anos com testes de software em projetos para a Motorola. Na época UX e outras siglas bonitas não eram tão conhecidas (pelo menos aqui no Brasil) e o grande boom tinha ocorrido justamente na área de testes. Hoje, a nova moda é falar de arquitetura de informação, usabilidade, acessibilidade e mais um monte de “ades” que permeiam os blogs, revistas e conversas de TI. É verdade que uma área – testes, no caso – não tem a mesma abordagem da outra – UX – mas, até que ponto as duas são diferentes ou iguais entre si?
A princípio elas não se encontram seja quando falamos de disciplinas, métodos ou técnicas mas, se começarmos a pensar, vemos que ambas existem para melhorar a qualidade e entregar um produto final melhor. Ainda mais, quando falamos de User Acceptance Testing estamos na verdade mesclando elementos das duas áreas. Na abordagem do UAT temos um ou mais indivíduos validam o sistema com requisitos do usuário que como podemos imaginar, não necessariamente coincidem com os requisitos do sistema. Normalmente eles avaliam aspectos não-funcionais que podem ser muitas vezes desconhecidos por parte dos testadores. O UAT normalmente funciona como uma verificação final em um ambiente e com condições mais próximas do que os usuários finais utilizarão e por isso, é colocado como uma das fases finais do processo de testes. É importante ter em mente que esse tipo de testes foca mais em detalhes e do que em erros mais graves (erros esses que devem ser capturados em fases anteriores de testes).
Em resumo, é importante termos em mente de que normalmente uma atividade que aparentemente não tem correlação com uma outra área pode influenciar não somente o jeito de se trabalhar, como também o tipo de artefato que geramos ou técnicas que utilizamos. As vezes, podemos aprender mais com alguém que aparentemente não tem nada a compartilhar conosco do que nosso colega da mesa ao lado.
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:
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:
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.
Recentemente, numa sexta-feira 13 (sim, bem pertinente), a google lançou mais uma novidade para o seu sistema operacional, o Android Ice Cream Sandwich (4.0). Dessa vez, entretanto, a surpresa fica por conta de um guia de estilos para promover novas interações e o novo “look and feel” da versão nova.
A ideia geral por trás desse guia de estilos é tentar unificar a plataforma no que se diz respeito à interface. Além disso, existe uma preocupação por parte do google de tentar criar padrões visuais mais fortes e consistentes. Isso, entretanto não é novidade para, por exemplo, a Apple que sempre teve guias de design bem atrelados à plataforma.
Uma coisa bem interessante sobre o guia é que ele tentou focar não somente nos desenvolvedores da plataforma mas também nos usuários, com dicas, padrões e e documentos que vão auxiliar em todo o processo, da criação à implementação. A primeira versão do portal pode ser encontrada em Android Design e já contém algumas coisas bem interessantes.
O guía é dividido em seções como Estilo, onde encontramos linhas gerais sobre interface como detalhes sobre cores, feedback, ícones e até tipografia e padrão de escrita. Já em Padrões, conseguimos identificar toda a parte de interação da plataforma, como estrutura da aplicação, gestos, compatibilidade e conceitos de interação. Por fim, temos os Blocos, onde podemos identificar os componentes e seus tipos e sub-tipos.
A consulta ao site é uma coisa bem válida para todos que estão começando a desenvolver, bem como para aqueles que já têm experiência com a plataforma. Lembrando que a ideia é que esse guia seja atualizado com novidades da plataforma. É, parece que agora, ninguém mais tem desculpa para desenvolver aplicações feias.
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!
Bytes don't Bite! 