Leah Buley conta um pouco da rotina, sucessos e frustrações de quem não tem outros UX Designers por perto para compartilhar soluções e discutir ideias durante o dia.
A palestra é de 2008 e vale muito a pena ouvir. Principalmente para quem não está acostumado e ser o único representante da área de UX na empresa onde trabalha, que é o meu caso.
(Se você estiver lendo este post por RSS e a apresentação acima não abrir, veja-a no blog)
Um curta-metragem que fala sobre Design Strategy já ganha milhares de pontos só por ser um curta-metragem que fala sobre Design Strategy. Mas além disso, o vídeo abaixo traz ótimas entrevistas e um ótimo roteiro. Vale o play :)
(Se você estiver lendo este post por RSS e o vídeo acima não abrir, assista-o no blog)
Algumas das citações no filme:
2:27 – “I became more and more convinced that the real challenge lay less in the technical problem, but often the real challenge was in trying to solve the human problem. It’s about understanding their needs, their aspirations and then meeting them in some way. So, we are serving them.”
3:53 – “I think a good design strategy is actionable. You look at it and you know what to do next. And sometimes things that are called strategy actually end with the insights instead of the ideas. And you don’t know what to do with them. You read it and you say ‘that’s really interesting, I understand my customer so much better now… now what?’”
4:40 – “It’s not just a job, for any of us.”
4:56 – “And that’s why it’s so difficult for us to do anything. We try to come up with something that you cannot think of today, but tomorrow is obvious.”
Ou “Alguns Fundamentos de Testes de Usabilidade”, para quem preferir.
A apresentação abaixo mostra conceitos básicos sobre testes de usabilidade, suas variações e particularidades e o que é necessário para realizá-los. Vale a pena dar uma conferida e compartilhar com seus colegas de profissão :)
(Se você estiver lendo este post por RSS e a apresentação acima não abrir, veja-a no blog)
O Google lançou em seu canal oficial um vídeo que mostra como são implementadas as melhorias no algoritmo de seu buscador.
As ideias do que precisa ser melhorado nascem a partir de hipóteses dos engenheiros. Cada hipótese é investigada pelo engenheiro e depois discutida com todo o grupo.
(Se você estiver lendo este post por RSS e o vídeo acima não abrir, assista-o no blog)
Algumas notas sobre esse processo:
Da metade para o final do vídeo, eles mostram um exemplo real que foi implementado há pouco tempo no buscador.
Muita gente conhece o “Did you mean”, a ferramenta que sugere a grafia correta da palavra caso você a tenha digitado incorretamente no campo de busca.
O problema é que se você digita um nome de remédio, por exemplo, e não clica na sugestão que o “Did you mean” te oferece, você pode acabar comprando o remédio errado. Ou entrando em páginas que possuem a grafia incorreta e que tendem a ser menos confiáveis.
Daí que eles testaram uma ferramenta chamada “Full Page Replacement”. Ao contrário do “Did you mean”, ela já oferece os resultados com a grafia correta – e te dá a opção de buscar pela grafia desconhecida, se quiser.
Como eles garantem que a autocorreção funciona? Para cada usuário que precisa corrigir o autocorretor, eles se asseguram que 50 outros usuários não precisem. Isso tudo acompanhando as estatísticas em tempo real do comportamento dos usuários.
Depois de muita observação e análise de dados, eles perceberam que a porcentagem de casos em que o “Full Page Replacement” não ajudava era mínima. E então eles lançaram a funcionalidade para todos os usuários.
“When you align Google’s interest with the user’s interest as we have aligned, good things happen.”, diz um dos engenheiros no fim do vídeo.
Acho que isso serve para qualquer empresa, né? :)
Um vídeo que explica brevemente como é o processo de trabalho nas empresas do Silicon Valley e apresenta o conceito de Gamestorming – uma série de boas práticas e ferramentas usadas por o que eles chamam de “empresas mais inovadoras do mundo”.
(Se você estiver lendo este post por RSS e o vídeo acima não abrir, assista-o no blog)
Muitos post-its, quadros-brancos, papéis, canetinhas e people moving things around.
Tirando a linguagem meio “vendedora demais” do final do vídeo, vale como inspiração para desburocratizar o processo de trabalho e focar mais nas discussões entre as pessoas do que na digitalização das ideias.
Para saber mais sobre Gamestorming: http://www.gogamestorm.com/
“Lean User Experience is a cross-functional, principle-driven process characterized by rituals that predispose teams to high-quality, high-velocity user experience outcomes.” (fonte)
Legal.
A tal Lean UX, ou “UX magra” (se traduzido ao pé da letra), é uma forma um pouco diferente de trabalhar os documentos da área de UX de forma que o dia-a-dia do profissional fique mais livre do excesso de entregáveis.
Tradicionalmente, o User Experience Design (e suas variáveis Design de Interação, User Interface Design, Arquitetura de Informação etc.) é uma disciplina baseada em entregáveis. Wireframes, sitemaps, fluxos, taxonomia e mais uma lista enorme de entregáveis.
O problema é que, algumas vezes, o profissional de UX fica preso demais a esses entregáveis, e o esforço de mantê-los atualizados e consistentes acaba tomando um tempo precioso do seu dia. Um tempo que poderia ser usado para fazer o que o profissional de UX faz melhor: pensar no projeto e em todas as suas variáveis.
Como funciona a Lean UX?
Independente dos entregáveis, o importante é validar o mais rápido possível (internamente e com usuários)
O objetivo é ter um protótipo para validar internamente e testar externamente o quanto antes. Se isso vai exigir sitemap, fluxograma, wireframes ou apenas meia hora sentado ao lado de um desenvolvedor, isso é o UX Designer quem decide e combina com a equipe.
Essa aqui é uma variação caso o seu projeto tenha muitos stakeholders. Valide com o cliente antes, em ciclos, com o mínimo de documentação possível. Depois parta para o protótipo.
Para quem trabalha com metodologia Agile, esse conceito não é novidade nenhuma.
“What’s most important to recognize here is that Lean UX is focused strictly on the design phase of the software development process. Whatever your organization’s chosen methodology (waterfall, Agile, etc.), these concepts can be applied to your design tasks.” (fonte)
Parece lindo. E na prática?
O segredo para economizar tempo é manter a quantidade de entregáveis reduzida e criá-los de forma que sejam facilmente editáveis.
Ao invés de perder horas detalhando um fluxo, desenhe rapidamente num quadro branco e chame todo mundo para olhar o fluxo e conversar sobre ele.
Ao invés de criar um wireframe completo, desenhe a tela principal e converse com o time sobre como deve funcionar cada uma das features.
E o mais importante: colete o feedback de todos. Do tecnólogo, do visual designer, do gerente de projetos. Você vai perceber que é muito mais fácil fazer mudanças quando o produto ainda está no “plano das ideias”.
Tudo isso com um único objetivo – colocar um protótipo na frente dos usuários o quanto antes. Como diz Jakob (o Nielsen), cinco participantes já são suficientes para descobrir os principais furos na experiência de uso de um produto. Se você testa e corrige logo, terá mais chances de testar uma segunda versão, e uma terceira, e uma quarta. São os tais ciclos de iteração.
Qual a chance de “Lean UX” ser apenas um desses termos da moda?
50/50. Se é uma moda ou não, o importante é o que se aprende quando se estuda um pouco a respeito dessa “metodologia mais magra”.
Não é um truque, uma revolução, tampouco o fim do mundo. Lean UX funciona mais como um lembrete de que talvez seja hora de rever a quantidade e a qualidade dos entregáveis que você está produzindo.
“Deliverables for maintenance don’t make sense anymore.”
Salvo algumas exceções, claro.
Se você quiser ler mais a respeito de Lean UX, recomendo:
Para terminar, aí vai mais uma citação sobre Lean UX:
“Lean UX is an evolution, not a revolution. UX designers need to evolve and stay relevant as the practice evolves. Lean UX gets designers out of the deliverables business and back into the experience design business. This is where we excel and do our best work. Let’s become experts at delivering great results through these experiences and forgo the hefty spec documents. It won’t be an easy road. Culture and tradition will push back, yet the ultimate return on this investment will be more rewarding work and more successful businesses.” (fonte)
Bônus: take a step back and look at your work.
A complexidade dos dispositivos móveis aumentou notavelmente nos últimos anos; novos aparelhos, sistemas operacionais e features afetaram a usabilidade das interfaces gráficas e físicas dos aparelhos celulares e tablets.
Amid Moradganjeh, em seu projeto de mestrado intitulado “Rimino” (pelo Umea Institute of Design), procurou estudar as oportunidades de um modelo ideal de Sistema Operacional para dispositivos móveis.
O objetivo do projeto não é desenhar um Sistema Operacional completo, mas sim considerar as necessidades de hardware e software e entender em linhas gerais como seria um modelo ideal de dispositivo móvel para os próximos dois ou três anos.
O site do projeto é completíssimo e explica em detalhes o processo, as inspirações, a metodologia, as ideias e os resultados – informação demais para resumir aqui.
Mas deixo um aperitivo de algumas das belíssimas imagens publicadas no site e recomendo a leitura:
Este slideshow necessita de JavaScript.
(Se você estiver lendo este post por RSS e o slideshow acima não abrir, veja-o no blog)
Update: encontrei também um vídeo do projeto. Confira abaixo.
Enough said: rimino.com – a human touch on mobile experience
(Se você estiver lendo este post por RSS e o vídeo não abrir, assista-o no blog)
Um vídeo com teste de usabilidade, protótipos de papel e crianças. Dá pra não gostar?
Brincadeiras à parte, bem legais as dicas que o autor do vídeo dá em alguns momentos.
Para quem ainda tem receio de fazer testes com protótipos de papel: funcionam muito bem, especialmente quando o projeto ainda está em sua fase inicial. Tem gente que prefere imprimir os wireframes, tem gente que prefere fazer rabiscoframes com lápis e canetinha – em todos os casos esse tipo de teste é uma solução bastante rápida e acessível.
Talvez você queira ler também:
