Núcleo de User Experience

Archive for the ‘processos’ Category

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

Aproveitando o clima tecnológico da semana. O Nux quer saber o que os campuseiros sabem da nossa área.

Se você é da área de tecnologia, acesse o questionário e nos ajude nessa empreitada. Em alguns dias postaremos o resultado aqui! =)

Abs!


Foto: Silvio Tanaka.

Sabe quando você se sente um apêndice? Uma parte do corpo humano que não serve pra nada, que a gente diz que tem para fazer uma média, porque sabe que algumas pessoas não têm?  É um dos dilemas de vida dos arquitetos de informação. No começo é tudo muito bom, principalmente no início de um projeto. O cliente quer escutar que o projeto tem AI ou UX, então o seu olhar otimista cai bem. Marquei UX no seu coração feelings. É aí que somos levados para as reuniões como analistas de produto, consultores astrológicos, conhecedores técnicos, porque afinal, qual dessas coisas não está em contato com o usuário, então podemos ser tudo isso!

E no dia a dia, como fica? Às vezes por não saber o que pedir, o seu chefe, vai sim, te passar trabalhos nonsense. Quero deixar claro aqui que a culpa não é do chefe. Sim, a culpa é nossa. Nós deveríamos não somente ter explicado o que um arquiteto faz, mas também o que ele entrega.

Em nossa empresa, estabelecemos que não somos espelhos de analistas de produto, arquitetos de software e muito menos diretores de criação. Ok, o NUX ainda está caminhando para ser alguma coisa, mas com certeza bem alinhado nos limites de ser e não ser um Núcleo de Usabilidade.

Abaixo, alguns exemplos que procuramos buscar com sucesso nessa empreitada dentro da Abril digital:

Nota: Nossos parâmetros são alinhados ao dia a dia da nossa empresa, do nosso processo (agile/scrum), portanto, muito cuidado ao replicar e tomar essas sugestões como um ISO. Também descobrimos que seguir um processo acadêmico às vezes é um mundo ideal dentro de milhares de variáveis, então é melhor sermos diretos ao ponto e nos fazermos entender mais.


TUDO NASCE DE UMA IDÉIA…


Foto: Silvio Tanaka.

1. Idéia – acompanhamento próximo ao Product Owner e argumentação se o conteúdo apresentado gera valor para o usuário;

Documentos que podem ser entregáveis: Pesquisa de audiência (ex: on line surveys), análise crítica de benchmarks ou testes de usabilidade (aham, é possível oferecê-los antes de fazer as melhorias).
Documentos que não precisam ser entregues: Pesquisa de oportunidades de mercado.

2. Briefing – Validação sobre quais seriam as necessidades do ponto de vista da AI com as outras áreas (PO e Arquiteto de software) para garantir a adequação da interface do produto e que as regras de negócio atuais estejam consistentes;

Documentos que podem ser entregáveis: NENHUM
Documentos que não precisam ser entregues: Definição de regras de negócios, histórias escritas, definições detalhadas sobre banco de dados, direção de arte, etc.

3. Slicing das features – Garantir que as features essenciais permaneçam no Release 1 e mantenham uma boa experiência para o usuário;

Documentos que podem ser entregáveis: NENHUM.
Documentos que não precisam ser entregues: os mesmos do item 2.

4. Especificação / Requisitos – Validar com o P.O todas as orientações de produto e criar um documento que seja de fácil entendimento a todos os envolvidos no projeto. Esse documento representa os padrões que serão aplicados, a estrutura da informação, o comportamento dos elementos e a apresentação da interface. Acompanhamento junto com qualidade (seo/qa) para a construção de critérios de aceitação. Protótipo navegável e validação com usuários reais.

Documentos que podem ser entregáveis: planilha de descrição do conteúdo, resultados de card sorting, protótipo navegável, vocabulário controlado, estudo de canais, fluxogramas, entre outros.
Documentos que não precisam ser entregues: os mesmos do item 2.

5. Layout – Validação da disposição visual dos elementos e feedback visual.

Documentos que podem ser entregáveis: relatório com orientações/modificações de acordo com as heurísticas de usabilidade.
Documentos que não precisam ser entregues: definição de grid, tamanho de imagens, planejamento visual.

6. Implementação – Validação de requisitos não funcionais (tempo de carregamento, acessibilidade, etc.).

Documentos que podem ser entregáveis: NENHUM.
Documentos que não precisam ser entregues: wireframes que impactem na sprint atual, garantia de testes detalhados de Q.A.

7. Testes – Consultoria ao Q.A do projeto e validação constante no ambiente de homologação.

Documentos que podem ser entregáveis: NENHUM.
Documentos que não precisam ser entregues: testes de Q.A..

8. Implantação – Avaliação do feedback do usuário.

Documentos que podem ser entregáveis: relatório ou workshop de feedback dos usuários (ex: acessos ao google analytics, testes com usuários, pesquisas de opinião, etc).
Documentos que não precisam ser entregues: ROI do produto.

É isso! Seguindo em frente e aprendendo sempre, até à próxima!

Um abraço do NUX.

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.

Hoje Scrum é o pretinho básico das empresas de tecnologia, se você ainda não ouviu falar com certeza em breve ouvirá (saiba mais sobre scrum aqui).

A idéia do NUX não é falar sobre metodologias ágeis e sim como integrá-las ao dia a dia de um arquiteto de informação e ux specialist.

Abaixo segue um vídeo do Joe Arnold, instrutor de Scrum do Yahoo! Inc., que nos ensina como trabalhar as user stories criando protótipos de papel a fim de nortear o visual designer e equipe de desenvolvimento, confira!

Quer saber como ficou o wireframe do projeto?
Veja aqui: http://migre.me/ZYd

E o layout final do Especial?
Confira também: http://migre.me/3pAh

Obs.: O vídeo é em inglês, sem legendas.


NUX no Flickr

Twitter: Siga-nux