Núcleo de User Experience

Posts Tagged ‘ai

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.

Já nos perguntaram várias vezes:

– Hey, qual programa vocês usam para criar fluxos, diagramas, wireframes, sitemaps e protótipos navegavéis?!?

A melhor resposta a esta pergunta é:

– Use o que melhor lhe servir, o que for mais prático e mais confortável a você.

Interface do Axure

Interface do Axure

Alguns dirão que hoje o Axure é a melhor ferramenta para o arquiteto uptodate (uau) que com ele é possível criar wireframes de alta fidelidade e/ou protótipos funcionais… perfeito.

Outros dirão que o Omnigraffle é a opção para usuários Apple e que o software é super-mega-ultra fácil de trabalhar, que possui uma biblioteca imensa de stencils a baixar no graffletopia.com e bla, bla, blá…

Puristas são do time do papel e lápis, dizem que é a forma mais prática e barata, afinal você não precisa comprar licença de uso de nenhum dos programas citados acima.

Independente da opção que escolher existirão prós e contras. O Axure é bem completo, mas a curva de aprendizado é maior, você precisa de um tempo dedicado até aprender a usá-lo completamente (natural em todo software novo) só que ele ainda não disponibiliza uma biblioteca vasta como a do Omnigraffle. Este por sua vez só roda em Mac OS e não possui a funcionalidade nativa de criar protótipos navegáveis.

E o papel? Bom, como você irá compartilhar o seu wireframe em papel? Tirando uma foto, claro (ah, espertão!)… Só que essa não é a melhor solução, se você quiser indexar o conteúdo do arquivo a fim de compartilhá-lo como documentação entre a equipe de desenvolvedores, como fazer? Você precisa de alguma forma digitalizá-lo, se surgir a demanda da equipe.

Yahoo! Stencil kit

Além dos principais programas, tem gente usando Power Point, Illustrator e até o Photoshop, acreditem.

Não importa o que você usa, o importante é colocar as idéias em algum lugar, organizá-las e discutí-las com a equipe do projeto envolvido. Comece no papel, se o projeto for complexo, ou necessitar de muitas alterações, digitalizá-lo é uma boa idéia pois lhe poupará tempo.

Sabe aquela história de: o que for melhor para o usuário é o que deve ser adotado? Então… e chega de “o meu é melhor que o seu”.

Comentem aí, queremos ouvir a opinião de vocês!

Links bacanas para os arquitetos de primeira viagem:

personas

A sala treze do oitavo andar estava em silêncio. Era ocupada por umas 3 ou 4 pessoas, todas compenetradas. Ronaldo fez Publicidade na USP.  Alemão é psicólogo de formação na UFPE, junto de Karina que é designer pelo SENAC em São Paulo. Todos falam como se fossem outras pessoas e agem como essas pessoas deveriam agir orientadas por um moderador.

Não, seu nerd. Isso não é uma partida de RGP e bem poderia ser. É um ensaio de contexto de uso para o estudo de personas, uma das técnicas aplicadas na fase inicial de qualquer projeto que valorize o design centrado no usuário. Mas já é possível imaginar porque você pensou isso. Uma partida de RPG começa com o narrador descrevendo um cenário. Todas as suas ações são baseadas em personagens com características preenchidas através de uma ficha como: destreza, carisma, inteligência… O prelúdio é o ponto inicial da sua jornada, de onde partem os princípios e objetivos que o personagem deseja cumprir. No live os personagens interagem entre si seguindo perfis pré-estabelecidos.

Embora o termo Personas derive da palavra latina para a máscara usada por atores na época clássica, essa técnica não é concebida unicamente em representação de papéis. Do contrário de um teatro, onde os atores recebem um script com o conjunto de suas ações, gestos e falas, as personas não seguem um roteiro premeditado e o aproximam-se mais de um trabalho incremental. A definição de personas é alterada gradativamente, e quanto mais você conhece o usuário, mais condições de aperfeiçoar a sua “personalidade”  você tem. Os dados demográficos ajudam bastante e antes de traçar qualquer perfil, portanto, certifique-se que o seu conhecimento é fundamentado.

A mecânica do estudo de personas baseia-se na construção de um personagem fictício que representa grupos de usuário do sistema. A premissa básica se traduz em auxiliar as decisões do projeto focando a atenção em humanidade e diversidade. O objetivo dessa técnica é mapear os principais comportamentos de uso e necessidades associadas a um padrão.

Construindo as personas você pode aperfeiçar a sua idéia de cenário e contexto, planejar ações, pensar no fluxograma operacional e dar credibilidade às estratégias de Arquitetura de Informação. O valor da metáfora das personas irá se refletir no seu dia a dia quando os envolvidos no projeto estiverem cientes para que tipo de padrão de comportamento estão construindo a interface, melhorando a comunicação e facilitando a argumentação na hora de tomar decisões. Ex: “ Vocês lembram do estudo de personas que fizemos? Pois é, a Fernanda, que é usuária do produto X, pensa assim, então ela não iria utilizar dessa funcionalidade”.

Atenção: personas são reflexo principalmente de dados quantitativos, que depois de bem desenvolvidos ajudam a manter uma visão qualitativa a fim de construir um perfil mais próximo do real.

Cabe-nos agora, a audácia de deixar um exemplo de “ficha” para vocês se encaminharem ao tio da “xerox” nesse divertido role-playing-game:

personasFonte: Graffletopia – Luis Hernandes.


NUX no Flickr

Twitter: Siga-nux