Oi, chamou?

Um bom design é multidisciplinar. O próprio ISO 9241-210 descreve os 6 princípios que garantem que um design é centrado no usuário:

• The design is based upon an explicit understanding of users, tasks and environments.
• Users are involved throughout design and development.
• The design is driven and refined by user-centred evaluation.
• The process is iterative.
• The design addresses the whole user experience.
• The design team includes multidisciplinary skills and perspectives.

O último item da lista ajuda a reforçar o argumento de que um bom design é multidisciplinar. Dificilmente você vai encontrar uma pessoa que cuide de todo o UX Design sozinho – a não ser que essa pessoa seja um gênio.

Este post aqui lista 7 diferentes especialidades do Design da Experência do Usuário. Veja abaixo:

• Gerenciamento
  “Design is so critical it should be on the agenda of every meeting in every single department” — Tom Peters.
  Em um time multidisciplinar, alguém precisa tomar a liderança, direcionar o time e gerenciar o trabalho. Normalmente essa é a pessoa que distribui e valida o trabalho entre os membros do time – e gerencia a relação com os outros stakeholders.
• Pesquisa
  “Supposing is good, but finding out is better” — Mark Twain.
  Alguém que forneça dados e insights para o restante do time – sobre o usuário, suas características, hábitos e necessidades. Também é a pessoa responsável pelas pesquisas de campo e testes de usabilidade.
  
• Arquitetura de Informação
  “Our understanding of the world is largely determined by our ability to organise information” — Louis Rosenfeld & Peter Morville.
  Esse papel a gente conhece bem. O time precisa de alguém com capacidade de organização de informação e que entenda o modelo mental do usuário, para que ele se reflita também no produto.
• Design de Interação
  “Design is not just what it looks like and feels like. Design is how it works” — Steve Jobs.
  Alguém que saiba desenhar a interação de forma que ela seja consistente, fácil e auto-explicativa. É a disciplina que entende de usabilidade e domina os padrões de interação, além de saber lidar com a multiplicidade de devices e plataformas onde a interação ocorre.
• Design Visual
  “The details are not the details. They make the design” — Charles Eames.
  A disciplina que requer um profissional que saiba balancear beleza e comunicação. Normalmente é alguém que domina tanto a direção de arte do produto que está sendo desenvolvido quanto o acabamento final dos pequenos detalhes da interface.
• Redação
  “I try to leave out the parts that people skip” — Elmore Leonard.
  Disciplina que sabe expressar ideias complexas em palavras simples e que sejam facilmente entendidas pelos usuários do produto. O profissional deve sabe escrever tanto longas páginas de texto quanto textos concisos que explicam a ideia sem fazer com que a experiência fique cansativa.
• Prototipagem
  “To pretend, I actually do the thing: I have therefore only pretended to pretend” — Jacques Derrida.
  Times multidisciplinares recorrem a um expert em prototipagem na hora de demonstrar como um sistema irá funcionar. Isso serve tanto para o estágio inicial do projeto (com protótipos de papel, de baixa fidelidade) quanto para o estágio que precede o desenvolvimento, onde o produto já está mais amadurecido e mais próximo do final.

É claro que isso é apenas uma possível configuração de um time multidisciplinar de UX. Existem N outras.

Em muitos casos, por falta de profissionais ou recursos, os profissionais acabam tomando conta de 2 dessas disciplinas listadas, às vezes 3. Isso quando não se trata de um time de UX de um designer só.

Mas não custa mirar o cenário ideal, certo?

“Rabiscoframe” é um nome abrasileirado para o wireframe feito com sketching. É uma ferramenta que ajuda bastante na hora de demonstrar suas ideias visualmente sem precisar abrir um software gráfico para isso – o que acaba tornando o processo mais rápido, na grande maioria das vezes.

O vídeo abaixo mostra como usar diferentes tipos de canetas na hora de criar o seu rabiscoframe e como cada tipo de caneta pode assumir uma função específica no sketch. Solta o play.

Leia também:

• A caneta dos sonhos para rabiscoframes
• Exemplos de sketches e rabiscoframes
• O valor do rabiscoframe

Essa é a proposta da nova ferramenta da testes chamada EyeQuant: um software que analisa determinada interface e prevê para onde o olho humano olharia, em que ordem e por quanto tempo.

Parecido com eyetracking, certo?

A diferença é que o software faz isso automaticamente, sem precisar de um olho humano para testar. Segundo os criadores da tecnologia, os resultados são 90% tão precisos quanto o de um eyetracking, por serem baseados em uma década de estudos neurocientíficos feitos com mais de 400 pessoas.

O resultado acaba sendo muito mais ágil e barato, já que não existem as etapas de recrutamento de usuários e nem as longas sessões de testes. O “conhecimento” sobre o comportamento do olho humano está todo armazenado no software.

Leia também: O que você precisa saber sobre eyetracking

Daí que eu fui lá no Corais.org e busquei pelo termo. Veja aí abaixo a descrição.

Diário de uso continuado

“O usuário testa o produto durante um determinado período e reporta suas experiências num diário, que pode ser em formato papel ou digital. O diário deve ter perguntas direcionadas para os aspectos que interessam à pesquisa, como por exemplo:

Você usou o produto hoje?
O que você fez com ele?
Houve algo que não conseguiu fazer com ele?
O que gostou?
O que não gostou?

Este método é útil quando se quer avaliar a curva de aprendizado do usuário, a relação do produto com o contexto de uso e sua relevância no dia-a-dia.

Caso o usuário utilize diariamente a Internet, é possível enviar o questionário do diário por email. Também é possível ligar ou enviar mensagens SMS para o usuário lembrando de preencher o diário.

Ao final do período, uma entrevista em profundidade é recomendada para compreender as anotações do usuário.”

Aprendeu? Agora agradeça o pessoal da UPA que fez a pesquisa e o pessoal da Faber Ludens que criou o Corais.org.

Leia também: Os entregáveis da Arquitetura de Informação

Agora é a vez da Lean Usability, a usabilidade com uns quilos a menos.

O conceito foi apresentado em NYC no ano passado e trata de uma metodologia mais simplificada de usabilidade, que é utilizada na Meetup (startup responsável pela ferramenta de organização de pequenos eventos www.meetup.com).

O pessoal da Meetup fez 3 experimentos diferentes com os testes de usabilidade:

• No primeiro, fizeram testes de usabilidade caseiros, recrutando pessoas em sites de classificados e conseguindo resultados mais rápidos a baixo custo. Uma pessoa acompanhava os testes e ficava responsável por anotar as descobertas, montar uma apresentação e mostrá-la para o time.
• No segundo, contrataram uma empresa terceira para realizar testes de usabilidade formais. O relatório no final do teste era completíssimo, mas demorava mais tempo e custava uma nota – o que acabava inviabilizando a frequência dos testes.
• No terceiro, eles acidentalmente descobriram o que depois batizaram de Lean Usability. Trata-se de deixar o usuário testar a versão beta do produto, desde que ele o faça sentado na mesma mesa que os desenvolvedores e que o moderador (como mostra o esquema abaixo).

O bacana dessa forma de testes, segundo eles, é que não se perdia tempo anotando todas as descobertas e organizando um relatório para ser compartilhado com o time. O time já estava ali, e assistia em tempo real a como o usuário interagia com a ferramenta. No fim da sessão, a discussão com o time já acontecia ali mesmo, naquela mesa, e as decisões eram tomadas no mesmo dia.

O pessoal da Meetup ainda organizou mais três variações deste mesmo tipo de teste: uma onde os desenvolvedores sentavam todos atrás do usuário (mas isso o deixava acuado), uma em que a tela do usuário era projetada em tempo real em uma sala separada (onde os desenvolvedores estavam), e outra onde os testes eram realizados com os clientes de uma cafeteria, em 10 minutos, em troca de um café especial.

Confira mais sobre Lean Usability na apresentação abaixo e veja mais alguns DOs and DON’Ts desse tipo de teste:

(Se você estiver lendo este post por RSS e a apresentação acima não abrir, veja-a no blog)

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)

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:

• No ano passado foram lançadas mais de 500 atualizações e melhorias para o algoritmo de buscas. Isso significa mais de uma melhoria por dia. É o que dizem por aí: no dia em que seu projeto vai ao ar, ele já está desatualizado. O exemplo do Google é a ilustração perfeita de que um produto deve ser constantemente atualizado para que continue satisfazendo os usuários com maestria.
• O levantamento de hipóteses de “coisas que precisam ser melhoradas” parte dos próprios engenheiros. Essas hipóteses são então investigadas e depois compartilhadas em um fórum, que decide se a mudança é relevante ou não. É interessante observar como grande parte do tempo do time é dedicado a “achar pêlo em ovo” – no bom sentido, é claro. O critério de qualidade é altíssimo e constante.
• As hipóteses depois são confirmadas através de experimentos com os próprios usuários do Google. Depois que a melhoria foi desenvolvida, eles direcionam uma pequena parcela de usuários para uma versão atualizada do buscador, que já conta com essa melhoria implementada. As métricas são então analisadas e, se os resultados forem satisfatórios, eles “viram a chave” e passam a disponibilizar a melhoria para todos os usuários. Alguma semelhança com os famosos testes A/B? No caso do Google, eles fazem mais de 20 mil desses por ano.

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:

• Lean UX: getting out of the deliverables business
• What is Lean UX?
• Case Study: Lean UX at work

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:

(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:

• Os entregáveis da Arquitetura de Informação
• O valor do rabiscoframe
• Exemplos de sketches e rabiscoframes

Fórmulas mágicas existem em todo mercado – e com User Experience não é muito diferente. Mas será que elas realmente funcionam?

A questão veio à tona recentemente quando pediram minha opinião sobre um novo projeto cujo briefing trazia os seguintes objetivos: melhorar a usabilidade do produto, reduzir a distância entre o produto e seus concorrentes, e diferenciar a empresa através de branding.

No dia seguinte li um artigo que (por coincidência ou recado dos deuses) falava justamente sobre essas fórmulas prontas de projetos web e porque muitas vezes elas não alcançam os resultados esperados.

São elas:

1. Reduzir a distância entre o produto e seus concorrentes

É o famoso benchmark: você navega nos sites concorrentes, anota quais são as funcionalidades disponíveis em cada um, cria aquela tabela comparativa linda entre todas as marcas e sugere que seu cliente desenvolva as ferramentas X, Y e Z para alcançar os concorrentes.

É a solução mais fácil e tentadora. O problema é que fazendo isso você está olhando apenas para o mercado – e deixando de olhar para o consumidor e de entender o que ele realmente quer ou precisa.

Funciona bem para os seus stakeholders, mas será que funciona para o usuário em 100% dos casos?

2. A pequena novidade

“Mas nenhum dos competidores do mercado imobiliário oferece um filtro de buscas onde você pode filtrar pela cor da parede”. Pois é. Nenhum. Algumas empresas confundem novidade com inovação. Introduzir uma ferramenta nova não vai atrair a atenção para o seu site e aumentar suas vendas se ela não for relevante para o consumidor.

A Apple não inventou o smartphone, nem apenas introduziu uma feature nova a eles. Ao lançar o iPhone ela desossou todos os smartphones que existiam no mercado.

Como diz o ditado: “Newer isn’t better. Better is better.”

3. Usabilidade, essa maravilha

Melhorar a usabilidade de um produto não é um objetivo de negócios, é um item indispensável para que ele sobreviva. Também não deveria ser um projeto à parte – e sim um processo constante dentro da metodologia da empresa.

Melhorias de usabilidade certamente vão trazer resultados positivos para o produto, mas não vão garantir seu sucesso.

Como diz o outro ditado: “Be useful first. Then be usable.”

4. O último grito da tecnologia

Não é porque existe uma tecnologia disponível que ela deve ser adicionada ao seu produto. Antes, considere se essa nova tecnologia realmente atende às necessidades e desejos de seus consumidores.

Muitas vezes novas tecnologias correm o risco de tornarem uma experiência mais demorada, mais confusa ou mais restritiva (já que não são todas as pessoas que têm acesso àquela nova tecnologia).

Como tuitou um dia desses a @RGA:

“OK, here’s the idea: First, we’ll seed interest with strategically placed QR codes. Then, we’ll all agree to pretend we live in Japan…“

E talvez seus consumidores estejam menos interessados na tecnologia e mais interessados nos benefícios que seu produto trará para eles.

5. Epifanias

As grandes ideias que vão transformar sua empresa, seu produto e todo o mercado. O tal do iPhone, por exemplo. As epifanias têm uma pequena chance de acontecerem e, quando acontecem, atraem todos os olhares do mercado para a sua empresa. Mas são bastante arriscadas.

A menos que sua empresa esteja disposta (leia-se “tenha infra-estrutura e culhões”) para bancar os riscos, essa estratégia não deve ser usada como única solução para os problemas da empresa.

—

Penso um pouco diferente do autor do artigo, especificamente em dois pontos:

• Essas estratégias comprovadamente funcionam, quando são bem planejadas e executadas. Mas elas nem sempre funcionam sozinhas. Melhorar a usabilidade, por exemplo, deveria ser um exercício constante – e não a solução para todos os problemas do universo.
• Essas estratégias não deveriam vir escritas no briefing, como no exemplo do início deste artigo. É um problema recorrente dos projetos de redesign: o redesenho não deveria fazer parte do briefing, e sim ser uma das soluções. Quando recebo um briefing que pede para “redesenhar o site X”, costumo sempre voltar um passo atrás e me perguntar se o site precisa mesmo ser redesenhado, e o porquê.

Bônus: piada com ursos polares.

A Iris Ferrera escreveu um ótimo artigo no Webinsider listando os entregáveis mais comuns na rotina de um arquiteto de informação. Gostei do jeito objetivo e descontraído com que ela descreveu os documentos – e resolvemos postar aqui também.

Não, não é uma lista definitiva. Nem aprofundada.

Mas é um ótimo checklist para ver qual o melhor tipo de entregável para cada etapa do projeto – e até para verificar se você não está se esquecendo de algum ou aproveitando pouco as vantagens oferecidas por eles.

Texto de Iris Ferrera, edições, grifos e links meus – e imagens do Google Images mesmo.

–

Durante a rotina de trabalho converso com muitas áreas em busca de “inspirações” para o projeto. E nesse papo percebo que o entendimento sobre arquitetura de informação aumentou e com ele veio a importância de protótipos na sua rotina de entregas.

Existe um valor surgindo de forma significativa sobre esta área (antes tão feia e má aos olhos de muitos), que coloca o arquiteto como um parceiro alinhado a todos os envolvidos para garantir uma entrega de sucesso.

Com este espaço ganho, agora é a vez de mostrar que o resultado de uma AI vai além de wireframes. Existem algumas metodologias (ou práticas) que podem ser inseridas na arquitetura, mas ainda estão esquecidas por vários fatores, inclusive entendimento.

Pensando nisso e também por alguns pedidos de alguns amigos e leitores, eu cataloguei alguns entregáveis que podemos gerar no estudo mais detalhado da arquitetura de um projeto com o intuito de deixar os wireframes bem mais alinhados com as necessidades do nosso cliente.

Nem tudo que estará listado precisa entrar no seu projeto, o que torna importante analisar bem a extensão, prioridades, público, mercado, tempo e expectativa do cliente.

Depois destas informações em mãos, alinhar com os modelos de métodos que mais tenham sentido. Lembrando que alguns terão custo de horas fora do ambiente de trabalho (cliente, laboratórios etc.).

Antes de começar, duas definições que devem iniciar o estudo como pequenos mantras:

Arquitetura de Informação é tornar o complexo claro.
WURMAN (1997)

Usabilidade é um conjunto de atributos que incidem sobre o esforço necessário para o uso, bem como sobre a avaliação individual de tal uso, por um indicou implícita ou conjunto de usuários.
Norma ISO 9241-11

Agora sim a lista, e eu coloco dividida em fases. Isto é apenas uma sugestão e reafirmo que cada projeto vai ter um grupo específico de entregáveis. Não adianta fazer tudo, gastar o dinheiro do seu cliente e no final se dar conta do “pleonasmo” dos insumos da Arquitetura de Informação que criou.

1ª FASE: CONCEPÇÃO

Após o “bater do martelo” (e algumas vezes antes mesmo disso acontecer), chega oficialmente a demanda para o arquiteto! Agora é hora de organizar as horas, analisar todo o material do cliente e propor para a equipe um conjunto de ações que irão culminar em uma entrega final muito mais embasada e consistente.

Esta é a fase da concepção e nela podemos envolver alguns dos seguintes passos (ou não, sinta-se à vontade para criar os seus):

Road Map

É um plano de ação, um roteiro, um passo-a-passo para o desenvolvimento de um projeto que precise de entregas faseadas, ajudando a coordenar e planejar os avanços. Além de deixar claras as datas, ajuda também a enxergar o conjunto de tecnologias que podem ser aplicadas para o projeto e o esforço necessário para cada etapa.

Benchmark

É a observação e estudo de produtos que tenham semelhança, em comportamento ou conteúdo, com o projeto que vamos desenvolver. É a análise dos pontos positivos e negativos que devem ser considerados no momento em que iremos criar o “jeitão” das telas e seus comportamentos.

Benefícios bacanas de um benchmark:

• Novo olhar sobre conceitos e padrões o que pode trazer novidades bem focadas e pertinentes com a proposta;
• Permite que o conhecimento sobre o mercado e sobre o cliente seja amplificado e consequentemente, do projeto também;
• Facilita a identificação das áreas críticas;
• Permite um olhar realista ao traçar objetivos.

Definição das Métricas de Sucesso

É uma lista do que vai ser usado para medir se o seu projeto/design/redesign atingiu os objetivos do cliente. Número de visitas? Número de seguidores no Twitter? Porcentagem de pessoas que compartilham seu conteúdo? Nessa hora vale uma boa conversa com o pessoal de Data Intelligence para definir quais métricas são importantes e possíveis de serem mensuradas. Sem essa métricas fica difícil calcular o retorno sobre investimento (ROI) do projeto.

Personas

Se a premissa é cada projeto ter um público-alvo, as personas são formatos de entender e enxergar melhor esse usuário. Pode ser uma descrição mais simples (como na imagem acima) ou detalhadíssima, com o intuito de personificar um usuário fictício dentro do público-alvo.

Esta pessoa de “mentirinha” ajuda no alinhamento das expectativas tanto do cliente quanto da equipe, sobre recursos e funcionalidades que devem estar contidas no projeto, priorização e avaliação do produto.

Criando sua pessoa, é bacana conter:

• Nome para facilitar a associação com pessoas reais;
• Características e razões para que o site seja importante para ele. Um histórico da persona, em relação às suas expectativas com o produto;
• Cenários para ambientar as condições em que a persona vai interagir com o site;
• Características de comportamento, quer emocionais, sociais ou culturais, que sejam comuns ao público representado pela persona, hábitos, linguagem e motivações.

Mais sobre personas >

Modelo conceitual

Normalmente é usado para representar uma visão macro de como um produto funciona do ponto de vista conceitual – sem a necessidade de entrar em detalhes sobre cada funcionalidade. Pode ser um gráfico, um parágrafo de texto ou um fluxograma – o importante é mostrar de forma simples como o produto irá funcionar. Geralmente é apresentado nas fases iniciais do projeto, para garantir o alinhamento entre as áreas.

Blueprint

Um daqueles entregáveis provindos do Service Design. Normalmente é um mapa que mostra todos os pontos de contato do seu serviço com o consumidor; e o que acontece com o usuário, com a interface e com o sistema em cada um deles.

Ecossistema

Quando um projeto é formado por diversas peças (um site, um aplicativo mobile, uma página no Facebook, um banner, um hotsite etc.), é um mapa detalhado de como esses diversos ambientes conversam entre si. Para onde você quer levar cada usuário e por quê? Qual o caminho que você espera que ele percorra?

Focus Group

É uma discussão entre um grupo geralmente pequeno sobre o produto que está sendo desenvolvido, que informa suas opiniões a respeito. No grupo existe um moderador, que direciona a conversa e garante que todos os assuntos sejam abordados. Os outros participantes são selecionados dentro do perfil do usuário do produto. O custo geralmente é baixo e pode trazer resultados interessantes focados diretamente no consumidor final.

Pesquisa Quantitativa

O famoso “responde essa pesquisa por favor”, que normalmente vem acompanhado de um link para um desses serviços de tabulação de resultados como o Survey Monkey ou o Google Docs. Ótimo para tirar uma dúvida, entender um pouco mais sobre o público-alvo ou levantar dados para justificar suas escolhas de design. O ponto negativo é que se a pesquisa não for bem elaborada, pode trazer resultados distorcidos da realidade. E se não for bem distribuído, o link pode acabar nas mãos de pessoas que não são necessariamente o público desejado. Revise oito vezes antes de enviar o link ou entregar o formulário impresso e, se possível, teste com um grupo menor antes de tornar a pesquisa pública.

Card Sorting

Esta é uma interessante técnica onde podemos entender um pouco do modelo mental do público do projeto. É normalmente usado para decidir qual a forma mais democrática de se agrupar conteúdos e qual o melhor nome a ser dado para cada um (taxonomia). Os usuários recebem um conjunto de pequenos cartões que devem ser organizados de um jeito que ele considere prático e simples, de acordo com seu próprio entendimento sobre o assunto.

Neste momento, onde pode acontecer (e deve!) uma conversa entre o usuário e o arquiteto de informação, é possível entender os motivos deste modelo de classificação. Depois de todas as escolhas, é feita uma análise dos agrupamentos mais recorrentes, que serão aplicados na tela/site em questão.

Mais sobre Card Sorting >

Inventário de Conteúdo

Um nome bastante autoritário mas no fundo trata-se de um cara legal. Quando no projeto, novo ou já existente, o conteúdo informativo é grande, se faz necessário ter um controle global destes textos que serão gerados para o site.

Consiste em um mapeamento de todas as páginas (previstas ou existentes) e do conteúdo de cada uma. Assim, conseguimos ver holisticamente todo o conteúdo, o que trará uma facilidade em organizar as informações (taxonomia, vocabulário controlado etc.), identificar conteúdo duplicado (muito comum em sites com grande volume de informações) e no futuro facilitar sua encontrabilidade.

Análise de Tarefas

É uma análise descritiva de como os usuários realizam tarefas utilizando o seu produto. Pode ser um passo-a-passo, uma tabela ou mesmo um documento de texto que contenha a narrativa das principais tarefas executadas. É muito útil na hora de definir quais tarefas são mais importantes e para avaliar se alguma delas está muito complicada para o usuário.

Mapa do Site

Organograma mostrando todas as páginas que o site irá conter. Este documento especifica as várias telas e mostra a relação hierárquica entre elas. Geralmente é produzido no início do projeto e refinado durante todas as etapas conforme as demandas posteriores.

Fluxograma

É um sitemap com QI acima da média onde é organizado o fluxo de informações. Desta forma é mais fácil compreender a transição das informações em cada tela. Fluxogramas são fundamentais para o olhar realista do projeto, pois além de se compreender os caminhos ainda permite encontrar fluxos mais objetivos para a visualização de determinadas seções ou telas.

Wireframes

A planta baixa do site, seu esqueleto. O resultado de pesquisas onde podem ser encontrados todos os elementos em cada tela e suas disposições e orientações. O intuito é mostrar a hierarquia das informações, das telas e o fluxo de navegação que irá existir.

O wireframe funciona melhor quando apresentado em tons de cinza, já que não há neste momento níveis de escalas ou posicionamento de elementos gráficos. O designer tem liberdade de criar um layout diferente do wireframe – desde que sejam respeitadas as organizações textuais e hierárquicas das telas.

Leia também: Como fazer wireframes do jeito certo >

Protótipos Navegáveis

São uma variação dos wireframes, mas com links entre as telas. Você pode clicar e navegar entre elas, como se estivesse navegando no produto final. Pode ser usado com diversos objetivos: desde ser exibido em um teste de usabilidade até fazer com que o público interno do projeto (desenvolvedores, gerentes de projeto, designers, cliente) visualizem mais facilmente como determinada peça vai funcionar. Hoje existem várias ferramentas que facilitam as construções desses protótipos, como o Flash Catalyst, o Microsoft SketchFlow ou o Axure.

Storyboards

Muitas vezes o produto que está sendo desenhado possui características audiovisuais muito específicas – muitas vezes incluindo ou se assemelhando a um filme. Nessa hora, muitos arquitetos preferem deixar de lado os wireframes e os protótipos navegáveis e rascunhar um storyboard da narrativa que está sendo criada. Funciona melhor tanto para quem está contando a história quanto para que o restante do time entenda (já que muitas vezes eles estão habituados a este formato, por terem trabalhado em produtoras ou agências de publicidade).

Mood Boards

Geralmente é um documento elaborado com ajuda do time de Cultural Insights, Planejamento e/ou Design, e procura reunir referências visuais do que se espera encontrar no seu site. Ajuda muito os designers a definirem qual linha visual devem seguir no projeto, baseado no universo de referências dos usuários.

2ª FASE: IMPLEMENTAÇÃO

Depois de feito o wireframe e aprovados os layouts, é a hora de testar antes de entregar para seu cliente. Abaixo a sugestão (sinta-se à vontade para discordar e criar seu próprio set) de entregáveis para esta fase:

Casos de uso, Documento de Especificação e Mensagens de Sistema

São o detalhamento de todos os cenários de uso e regras de funcionamento do sistema. Utilizados em projetos que possuem muitas variações de uso, esses documentos normalmente são escritos por um tecnólogo, que conta com a ajuda e validação do arquiteto de informação para levantar todas as situações possíveis. É importante prever soluções e mensagens (de sucesso ou de erro) para cada uma delas, para garantir que a conversa com o usuário seja consistente e eficaz independente do cenário em que ele se encontra.

Análise Heurística

É um conjunto de “boas práticas” de usabilidade que um site deve conter. Com eles podemos observar e analisar alguns pontos que ajudam a definir se o site está usável ou não. Alguns exemplos de itens que esta análise percorre:

• Visibilidade do estado do sistema;
• Correspondência entre o sistema e o mundo real;
• Controle e liberdade do usuário;
• Consistência e padronização;
• Prevenção de erros;
• Reconhecimento em vez de lembrança;
• Flexibilidade e eficiência de uso;
• Projeto estético e minimalista;
• Recuperação de erros;
• Ajuda e Documentação;
• Controle e liberdade do usuário.

Mais sobre análise heurística >

Teste de Usabilidade

São roteiros criados a partir dos fluxos existentes no protótipo ou produto, e testados com usuários reais para que possamos enxergar os pontos fortes e fracos do site, e ajustar para que a entrega esteja bem alinhada e com usabilidade eficiente.

Olhando as pessoas interagirem com o produto permite um olhar bastante claro e realista sobre as telas e sua forma de interação com o usuário, e o resultado destes testes ajuda na defesa de alguns conceitos envolvidos no projeto (quer seja pelo cliente ou equipe), desalinhados com o entendimento e necessidade do usuário.

Com os resultados em mãos, é hora de acertar os detalhes finais do produto. Ajustes e refações são comuns nessa etapa. O teste de usabilidade também pode ser feito mais no início ou mais no final do projeto, como medida constante de qualidade e adequação ao usuário final.

Leia também: Testes de usabilidade custam basicamente nada  >

Controle de Qualidade (QA)

É a hora de testar os mínimos detalhes. Verificar se todos os links funcionam, se o fluxo de dados está ocorrendo corretamente e se todos os diferentes cenários de uso foram implementados e estão funcionando. O controle de qualidade normalmente é feito por uma equipe especializada, com o auxílio e orientação do arquiteto de informação.

Análise de Acessibilidade

Consiste basicamente em uma análise para verificar o nível de acessos facilitados do produto. Se está disponível e acessível a qualquer hora, local, ambiente, dispositivo de acesso e por qualquer tipo de visitante/usuário.

Também pode apontar se os usuários podem acessá-lo de diferentes sistemas operacionais e principalmente se podem ser acessadas por todos, independente de capacidade motora, visual, auditiva, mental, econômica, social ou cultural.

Mais sobre acessibilidade >

Recomendações de SEO (Search Engine Optimization)

São as recomendações para que o produto web seja construído nos parâmetros necessários para ser mais facilmente encontrado pelos buscadores (Google, Bing etc.). A produção desse documento normalmente exige a ajuda de alguém com conhecimento específico no assunto, como um profissional de SEO ou um programador que entenda de otimização para buscas.

3ª FASE: MONITORAMENTO

Arestas aparadas depois da bateria de testes pré-entrega, projeto finalizado com louvores e agora é só festa e férias… #claroquenao! Agora é a fase de relatórios de melhorias, análises de comportamento e resumindo a ópera: o filho precisa de cuidados depois que nasceu!

Abaixo a sugestão de algumas práticas que podem ser legais de incluir no seu set de monitoramento:

Teste de Usabilidade

Já falamos dele lá em cima… scroll para você que passou por ele e não leu… Os testes de usabilidade podem e devem continuar sendo feitos mesmo depois que o produto já foi publicado. É a melhor forma de refinar a usabilidade e promover a implementação gradual de novas funcionalidades, sempre validando com usuários reais.

Testes A/B

São testes comparativos entre duas ou mais soluções para uma mesma tela ou tarefa. O modelo clássico funciona da seguinte forma: metade dos visitantes vêem a versão A da tela, metade vêem a versão B, durante um certo período de tempo. No final, mede-se e compara-se a performance de cada uma das versões – e a melhor delas é implementada para 100% dos visitantes. Testes A/B podem acontecer de forma sucessiva e constante, para que o produto evolua sempre.

Mais sobre testes A/B >

Eye Tracking

Última moda e grito da modernidade, o mapeamento do olhar do usuário sobre a interface auxilia na definição de pontos de interesse sobre conceito, layout, navegação e modelo de interação, com dados realistas para ajustar as informações da tela para que sejam mais atraentes ou fáceis de encontrar.

O entregável é um relatório que mostra quais pontos da tela foram mais olhados pelos usuários, em um modelo parecido com a imagem acima: um heatmap que mostra em cores quentes as áreas mais visualizadas da interface.

O custo de realização dos testes de eyetracking é mais alto do que os testes de usabilidade, pois são necessários equipamentos especiais para monitorar o movimento do olho do usuário.

Leia também: O que você precisa saber sobre eyetracking >

Análise de Métricas

É o olhar do arquiteto de informação sobre as métricas do projeto. Analisar os números de acesso, navegação e interação e encontrar soluções para melhora ou manutenção das telas. Se a taxa de rejeição de determinada tela está alta, talvez ela seja seu próximo alvo de melhorias de design e usabilidade.

Análise Quantitativa e Qualitativa (análise de interface)

Análise de interface qualitativa descobre o comportamento do usuário durante a navegação. Por exemplo: descobrir que todo usuário clica no logo quando quer voltar para a home ou que os usuários de uma determinada seção do site são predominantemente mulheres.

Já as análises quantitativas permitem, como no focus group, mensurar opiniões de grupos sobre o produto.

Os resultados não são apenas “este produto agrada” ou “este produto não me agrada”, mas sim os motivos dessas opiniões. Pode ser informação valiosa no desenvolvimento do projeto e depois de sua implantação.

Estes dados permitem redefinir as seções privilegiando as informações de acordo com o público ou definir premissas para um determinado projeto; onde antes só considerávamos os browsers e resoluções de tela, hoje podemos ir muito além, considerando também o perfil do usuário.

E o que mais for preciso…

Seja versátil. Adapte os seus entregáveis às necessidades de cada projeto. Evite redundâncias. Crie suas próprias variações dos documentos acima. Compartilhe-os com o time, na hora certa, e peça/aceite feedback sobre todos eles. Converse com os colegas de equipe, com gerentes, deixe que eles conheçam o arsenal de entregáveis que a AI pode produzir, insira em seus projetos e colha os louros de um resultado eficiente!

Moral da história: agora, como já diria capitão planeta, “O poder é de vocês!”.

Mas não se esqueça que com o entendimento vem o poder, e com o poder a responsabilidade. Portanto, juízo ao criar seu conjunto de entregas…

–

Bônus:

Faltou algum item na lista? Deixe um comentário com o título do item e a descrição, e vamos fazer essa lista ficar mais completa :)

Tiny URL pra você ter acesso rápido a este post quando estiver no meio de uma conversa com o gerente de projetos: http://tinyurl.com/entregaveis

Aimeudeuseagora?

Calma.

São duas discussões diferentes. A primeira é inteiramente semântica, e diz respeito ao argumento que diz que uma experiência não pode ser desenhada. O que se desenha é o recipiente que contém essa experiência. E uma experiência sofre influência de uma porção de fatores subjetivos que não podem ser controlados – apesar de muitas vezes serem manipulados pelo designer que a projetou. Mas discussões puramente semânticas não afetam o jeito que você trabalha, então vamos pular esse assunto.

A segunda é um post muito interessante de Whitney Hess, que traz um checklist para identificar se você realmente atua como UX Designer ou se carrega um título não tão legítimo assim.

A nomenclatura User Experience Designer não é muito clara, e a ausência de uma regulamentação mais forte ajuda a confundir o cargo com outros similares: Arquiteto de Informação, Especialista de Usabilidade, User Interface Designer – entre outros. Mas o User Experience Designer tem um papel um pouco mais amplo em um projeto, e vale a pena percorrer esse checklist para ver se não existe algo que possa ser melhorado na metodologia de sua equipe de UX.

Então vamos à lista (editada e adaptada do post original).

Você não é um User Experience Designer se…

• …você não fala com os usuários. Se você desenha baseado somente em sua própria intuição, sem entender, pesquisar ou entrevistar os usuários reais do produto que você está desenhando, então você não é um User Experience Designer. Você é um Yourself Designer. Mas você não pode desenhar apenas pensando em você mesmo, né?

• …você não consegue identificar o seu público. Se quando alguém te pergunta quem é o público do seu site, você responde “todo mundo”, ou se dá uma resposta genérica como “mulheres de 30 a 40 anos”, você está tratando seu usuário com a mesma profundidade com a qual Rebecca Black escreve a letra de suas músicas. Melhor dar uma pausa e começar a listar as necessidades desses usuários e as motivações que os fazem utilizar o seu site.

• …você não define o problema antes de tentar resolvê-lo. Se o seu chefe pede para você redesenhar um site sem te contar qual é o problema que você precisa resolver, alguma coisa está errada. Na maioria das vezes, entender o problema muda radicalmente a solução proposta.

• …você não conhece os objetivos do usuário. Mesmo que você conheça o problema, ainda é preciso definir o porquê dessas pessoas utilizarem o seu produto. O que você está ajudando essas pessoas a fazerem?

• …você trabalha dentro de uma bolha. O User Experience Designer quase nunca trabalha sozinho. Você precisa conversar com o gerente de projetos, com o planejador, com o designer e com o programador – bem antes de colocar a mão na massa. E claro, receber feedback dos usuários.

• …você faz decisões de design baseado em suas próprias referências pessoais. Toda decisão deve ser baseada em algum argumento racional – seja ele obtido através de pesquisa ou não. Mas se quando alguém pergunta por que você reposicionou algum elemento e sua resposta contém as palavras “prefiro”, “acho” ou “gosto”, então você não é um User Experience Designer.

• …você não considera os objetivos de negócios. Definir os Key Performance Indicators é um dos estágios iniciais do processo. Aumentar as taxas de conversão em 10%? Aumentar o tempo de navegação em 30 segundos? Aumentar a média de page views por usuário de 1,1 para 1,3? Criar formas de medir a taxa de retorno? Fazer as pessoas tuitarem? Algum objetivo o projeto tem que ter. E conversar com o Gerente de Projetos e com o Analista de Métricas vai ajudar bastante a definir e mensurar esses objetivos.

• …você não usa métodos. Entrevistas com usuários, testes de usabilidade, personas, cenários, card sorting, diagrama de afinidades, rabiscoframes, wireframes, fluxos, diagrama de telas, protótipos, testes A/B e muito mais. Se você não utiliza a maioria desses métodos – ou se pelo menos não estabelece um critério claro na hora de decidir utilizar um ou outro – então você não é um User Experience Designer.

• …você não pensa nas exceções. Se você trabalha sempre com os melhores cenários, você está sendo otimista demais para um UX Designer. As notícias do seu site não vão ter foto o tempo todo. As galerias multimídia não terão 30 fotos para compor o seu grid. Não é todo usuário que tem caixas de som ou fones de ouvido. Não é todo celular que roda javascript. Não é todo mundo que começa a navegar pela homepage. Se você não consegue prever esses cenários, então você não é um User Experience Designer.

• …você só pensa no wireframe. Se você só pensa no que o usuário vê em seu site, aplicativo ou quiosque – mas não pensa em como o usuário vai chegar lá, o que ele vai fazer depois, qual sentimento você quer provocar ou quanto tempo você espera que ele permaneça ali – você é um User Interface Designer, e não um User Experience Designer. Tem uma diferença aí.

É claro que se você participa em qualquer etapa do processo de criação de um produto (como Visual Designer, Programador, Redator), você está afetando diretamente a experiência do usuário. E para isso você deveria entender quem é esse usuário, quais são suas necessidades, referências e objetivos ao utilizar o tal produto.

Mas se você, UX Designer, não é a pessoa responsável por disseminar esse conhecimento por toda a equipe, então talvez existem coisas que você possa melhorar no seu processo de trabalho.

Talvez a lista de Whitney Hess pegue um pouco pesado em alguns pontos. Para muita coisa não existe certo ou errado. Mas existe uma série de referências bacanas de metodologias que funcionam e que trazem bons resultados. Então não custa dar uma olhada, filtrar e tentar aplicar uma coisa ou outra no seu dia-a-dia.

O que é o Fiat Mio?

O Fiat Mio é uma iniciativa da Fiat Brasil e da AgênciaClick para se pensar sobre o futuro dos carros. A Fiat abriu um espaço colaborativo para que as pessoas enviassem ideias e, juntos com a montadora, definissem como seria o carro ideal para suas necessidades.

Foi a primeira vez que uma empresa decidiu abrir o processo de criação de um carro, segredo tradicionalmente guardado a sete chaves pelas outras montadoras. E as ideias foram todas publicadas sob a licença Creative Commons, que permite que qualquer pessoa ou montadora possa ter acesso a elas.

Se é uma quebra de paradigmas para o mercado de automóveis, imagine para o de publicidade digital.

Presenças evolutivas

Rodas que giram 90º? Assento ejetor? Chip 3G dentro do carro?

No início o projeto precisava de um site onde as pessoas pudessem enviar suas ideias sobre o carro do futuro. A participação do público foi tão grande que logo esse pequeno site se transformou em um portal, o fiatmio.cc.

Ali foram centralizadas todas as ideias e discussões a respeito deste carro do futuro. Depois surgiram episódios em vídeo mostrando os bastidores do projeto, newsletters para os participantes, tradução para vários idiomas, perfil no Twitter, Facebook Connect, entre outras novidades. O site foi evoluindo aos poucos e se transformando em uma espécie de comunidade – que reunia leigos, estudantes de engenharia e design ou simplesmente apaixonados por carros.

Uma das características de um projeto tão extenso e tão inédito (não existia benchmark para quase nada, acreditem) é que as presenças iam se transformando com o tempo.

Nesse processo, o uso dos rabiscoframes foi fundamental. Pequenas decisões foram tomadas através de desenhos no papel, muitas vezes pulando o estágio de Visual Design e indo direto para o time de Desenvolvimento. Foram páginas e mais páginas do meu caderno e do caderno do Diego, cheias de telas que deram certo ou que foram abandonadas depois. Sem dó.

Um carro recheado de interfaces

Quando se fala em um carro para o futuro, fala-se em abandonar os painéis analógicos que existem hoje e pensar em soluções 100% digitais de interface entre o motorista e o carro.

Foi aí que a montadora recorreu ao expertise da AgênciaClick em desenvolver interfaces digitais, já que os engenheiros poderiam ter uma visão muito viciada do painel do carro. Foi um trabalho a quatro mãos: a agência levando seus conhecimentos em arquitetura de informação e usabilidade e a montadora somando sua experiência em ergonomia e engenharia de carros.

Abaixo algumas fotos dessa etapa do trabalho:

Passo 1 – Conhecer o interior do carro

Passo 2 – Medir as interfaces

Passo 3 – Distribuir as informações

Passo 4 – Desenhar os wireframes das interfaces

Passo 5 – Testar no protótipo de argila

No fim dessa etapa, tínhamos protótipos navegáveis de quase todas as interfaces do carro: a tela touch do volante, o pad de navegação do passageiro, as informações projetadas no parabrisas e até as interações entre o carro e o celular do dono.

Ok, agora vamos fazer um filme

Estande da Fiat no Salão do Automóvel 2010.

Em novembro ocorreu em São Paulo o Salão Internacional do Automóvel 2010, o evento ideal para apresentar a novidade aos fãs de carros. As pessoas que enviaram ideias para o Fiat Mio foram convidadas a visitarem o estande da Fiat no Salão e a conhecerem o carro que haviam ajudado a criar.

Totem apresenta um Raio-X com as tecnologias do carro.

Como o carro possui tecnologias que não existem nos dias atuais, produzimos um filme para mostrar às pessoas como este carro funciona e como se relaciona com seu cotidiano.

Nas gravações do filme, os atores usaram os próprios wireframes para saber onde tocar, para onde olhar e quais movimentos deviam fazer com as mãos.

O papel do User Experience Design

Site, iPad, Mobile, Vídeos, Blog, Totens, Raio-X, Teasers, Motion, Mala Direta, E-mail Marketing, Estande, Volante, Parabrisa. Manter a coerência e a unidade em todas essas presenças não foi um trabalho de uma pessoa só. Seria humanamente impossível.

"Creating great user experiences takes a multidisciplinary team that shares ownership of UX" http://bit.ly/dTM1Cr—
Arq. de Informação (@blogdeai) November 30, 2010

Vi essa citação esses dias e logo me veio à cabeça o trabalho feito em Fiat Mio. O User Experience Design nunca foi o trabalho de um único profissional ou um único grupo. Não neste projeto.

Ao invés de centralizar o projeto todo, o UX Designer tinha uma função evangelizadora. Em determinado ponto do projeto, o pensamento de UX já estava espalhado pela equipe. Cada um dos envolvidos no projeto tinha em mente a experiência de marca que deveria ser passada e a experiência do usuário a ser percorrida por todos esses ambientes.

Desde o motion designer até o programador front-end, todos estavam cientes da função e dos objetivos de cada uma das peças produzidas – e tinham noção de que uma boa experiência era condição primordial para a existência do projeto.

No fim, esse pensamento integrado gerava um processo muito menos estressante e muito mais agradável. Como tem que ser, não é?

Bônus: mais fotos dos bastidores.

Se você tiver algum exemplo que possa compartilhar, mande aqui nos comentários ou pelo twitter, citando o @blogdeai. Depois faço um update com as novas imagens :)

Quer saber mais sobre sketching?

• Artigo: O valor do rabiscoframe
• Artigo: Sketch First, Wireframe Later
• Ferramentas: Tools for Skecthing User Experiences
• Templates: A Collection of Printable Sketch Templates
• Exemplos: User Experience Sketches
• Exemplos: 18 Great Examples of Sketched UI
• Grupo no Flickr: Rabiscoframes

(se você está lendo este post por RSS e o vídeo não abrir, assista-o no blog)

“O sketchboard é uma técnica de baixa fidelidade que torna possível avaliar uma série de conceitos de interação, envolvendo toda a equipe – do gerente de projetos aos parceiros de tecnologia. O sketchboard rapidamente demonstra as várias soluções possíveis e destaca a melhor delas para documentar e construir em cima.”

Apesar do nome pretencioso, o vídeo dá uma boa noção de algumas etapas do trabalho do arquiteto de informação. É claro que não existe “jeito certo de fazer wireframes”, já que cada projeto demanda métodos diferentes de desenvolvimento e que existem inúmeras variáveis envolvidas. Mas mesmo assim, vale o play:

(se você está lendo este post por RSS e o vídeo não abrir, assista-o no blog)

O autor do vídeo é o mesmo autor de Prototyping: a Practitioner’s Guide.