Núcleo de User Experience

Posts Tagged ‘ia

No dia 29 de janeiro, o NUX lançou a pergunta: E o que os campuseiros sabem sobre Arquitetura de Informação ? Aproveitando o clima tecnológico da semana da Campus Party, o Nux quis saber quão conhecida está nossa área (AI, UX e afins) entre o pessoal de tecnologia (muitos deles desenvolvedores web, inclusive…).

Um pouco sobre quem respondeu a pesquisa

Perfil dos participantes

Perfil dos participantes

Infográfico de Silas Augusto


Sobre usabilidade

Apenas 6,67% não soube responder o que é usabilidade. Com o restante houve quase um consenso quanto ao o que é isso afinal… Em quase todas as definições enviadas lemos: facilidade de uso de uma interface (física ou não) e uma forma de melhorar a produtividade.

No longínquo 2005, a Amyris Fernandez (especialista em usabilidade) fez uma abordagem bem legal sobre o tema no WebInsider. Apesar de antigo, o conteúdo ainda é muito relevante. A Wikipédia também reúne um conteúdo interessante, citando a famosa ISO 9241-11: “pela definição da International Organization for Standardization, usabilidade é a medida pela qual um produto pode ser usado por usuários específicos para alcançar objetivos específicos com efetividade, eficiência e satisfação em um contexto de uso específico”.

Mas, a grande questão é: fica a cargo de quem aplicar a usabilidade nos projetos? E é nesse quesito que as opiniões divergem…

O que o pessoal respondeu

Respostas dos participantes

Respostas dos participantes

Infográfico de Silas Augusto

Centrado no usuário. Esse foi o mais próximo que chegamos…

Concluímos então que o problema está em ligar a teoria a prática. Ok! Sabe-se o que é usabilidade, mas e aí? Quem faz isso acontecer? Como faz isso?

Primeiro, algumas respostas básicas:
Não, não somos designers
Não, não somos nós que definimos cor, tamanho e tipo da letra
Não somos nós que criamos um ícone XYZ
Não, não somos um ‘webmaster’ (o famigerado ser mitológico que fazia TUDO nos primórdios da web)
Não temos que saber minúcias da implementação de infraestrutura e relacionados
Também não precisamos codificar

Sim, somos nós que planejamos a navegação, a hierarquia da informação, rótulos, design patterns
Nós que vamos a campo conhecer o usuário, seus hábitos, seus anseios…
Também representamos aquela vozinha inconsciente que, de tempos em tempos, fazem as pessoas envolvidas nos projetos lembrarem que láááááááá no final vai ter uma pessoa (sim, parece estranho, mas é a realidade, meu caro) usando isso que estão desenvolvendo agora.

E o mais importante… Não, não estamos competindo com ninguém! Cada um tem seu papel no processo criativo, cada um tem seu momento. O nosso é facilitar o diálogo, permitir a comunicação, envolver desenvolvimento e criação desde o início com seus inputs sempre ricos. Criar o melhor produto, revolucionar…

Para nossos amigos tecnólogos, uma boa definição de um Arquiteto de Informação seria: um analista de sistemas que vê o mundo com olhos de designer, que levanta os requisitos do sistema do ponto de vista do usuário e não da tecnologia disponível. Não se pensa uma solução porque ela é mais fácil de implantar, porque é a mais barata, por que está na moda ou é a mais bonita, mas porque é a que gera melhor experiência para o usuário.

Na definição da Wikipédia temos algo semelhante a isso:

…Não por acaso, a Arquitetura de Informações guarda muitas semelhanças com aquela sua ancestral (Arquitetura tradicional). A principal delas é a característica de ser centrada no ser humano: como a informação só pode existir em “comunidades de sentido”, a Arquitetura de Informações trata primeiramente de pessoas, buscando assegurar-lhes conforto e, somente depois, de tecnologia.

Bom, é isso… Esperamos ter elucidado um pouco essa questão! E você o que acha?

Abs!

Outros posts sobre o papel do AI

Anúncios

É isso aí, Peter Morville com um bando de amigos e empresas associadas ao IXDA estão promovendo algo que nós aqui do Brasil também questionamos muito:

Afinal, o que é AI? Por que é tão importante? Qual o real significado de Arquitetura de Informação para você?

A fim de chegar a uma “definição definitiva” essa galera resolveu dar prêmios às melhores definições, seja em 140 caracteres, vídeo, foto, texto ou mesmo diagramas. Entre os prêmios estão livros autografados, cursos on-line, inscrições para os próximos eventos e bufunfa, minha gente – sim! Mil doletas para a melhor definição, $500 para o vídeo mais criativo e outros $500 para o melhor diagrama.

Para participar basta enviar seu material (limite de 3 propostas) no grupo do flickr “Explain IA” com a tag “explainia” até dia 11 de Fevereiro de 2010. O bacana é que a promoção tem validade para os arquitetos do mundo inteiro!

Mais detalhes acessem o grupo no flickr:
http://flickr.com/groups/explainia/

Abaixo uma amostra divertida do que a galera anda produzindo, corram!

Explain IA

post_150

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

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

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

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

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

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

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

Atualizado em 08/09/2009

Capa do livroSketching User Experiences

Capa do livro'Sketching User Experiences'

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

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

design-pattern

Uau, Benchmark, Analytics, Wireframe, Design Pattern… Uma sopa de palavras pra vocês, alguém aí fez bingo?

O papo agora é design pattern! Mas o que são design patterns? São padrões ou modelos que definem as melhores soluções de usabilidade a problemas comuns ou problemas de acessibilidade em contextos específicos. Esses modelos tornam mais fácil a compreensão de uma interface aos usuários em realizar suas tarefas.

Ok, chega de blá, bla, blá porque existem milhares de sites falando sobre design patterns. Nossa abordagem aqui é mais direta e prática…  e aí? Como aplicar no dia-a-dia a definição de design patterns?

Você, gênio da arquitetura de informação e usabilidade, já deve ter uma receita de bolo pronta, mas nós do NUX também temos nosso step-by-step, confira:

1. Definição do que será pesquisado – é a hora de escolher o foco de pesquisa. Ex.: os footers (mais uma palavra para marcar na cartela de bingo) dos sites que sou responsável estão fora de padrão, cada novo release (bingo!) possui um footer diferente do anterior. Preciso então definir um padrão mega-blaster para os footers! Muito bem garotão, próximo passo.

2. Benchmark – nada mais é do que obter referências, listar todos seus concorrentes, sites com soluções que você acha interessante, levando em consideração as funcionalidades. Depois de criar essa listagem de referências, analise cada caso sobre o que há de legal, ruim e dê uma nota. Ex.: achei interessante os footers da Revista Exame, CNET e desatualizados os footers do Estadão e UOL.

3. Google Analytics – a ferramenta serve para analisar qual o comportamento do usuário em seus sites, não se preocupe com os números absolutos apenas em identificar padrões de busca e acessos. Ex.: No meu site identifiquei que o usuário procura por notícias, acessa mais conteúdo específico para mulheres e como assinar meu serviço oferecido.

4. Wireframe – com base nas informações obtidas em suas referências e o Analytics, agrupe as informações e comece a rabiscar um modelo. Troque muita informação com o gerente responsável pelo projeto que trabalha, troque figurinhas com a equipe de SEO (se existir) a fim de esgotar todas as possibilidades de inputs ao seu trabalho.

wire1

Ex.: Com base no menu de navegação e resultado do analytics resolvi agrupar meu footer em 4 áreas: Navegação primária, conteúdo mais acessado, serviço ao assinante e informações institucionais.

wire2

5. Documentação – Depois que o formato for aprovado entre os interessados documente todas as funcionalidades do novo padrão criado. Crie um wireframe de alta fidelidade e compartilhe o documento entre os visual designers, diretores de criação e etc.

wire3

6. Testes com o novo formato – Como assim fechar um padrão se ele não foi testado? A chance de errar ao se criar um modelo com base no comportamento de seus usuários (via Analytics) e referências que já funcionam (benchmarks) é bem baixa, mas isso não lhe garante 100% de certeza que está indo para o caminho correto.

Todo design pattern está em eterna atualização, é um trabalho contínuo. Vocês notarão que esta não é uma receita fechada de como um footer deve ser, pois para cada produto há uma necessidade e usuários distintos.

Você, arquiteto e ux specialist precisa sempre estar atento as mudanças de cenário e novas ferramentas a fim de trazer valor a seu usuário e consequentemente um produto melhor.

Como aplicar testes de usabilidade? Isso fica para outro post com nossos ninjas do UX.


NUX no Flickr

Twitter: Siga-nux