Museu em casa
Publicado por: nuxabril em: Outubro 28, 2009
Você trocaria uma visita ao museu para ver obras de arte deitada na sua cama!?
Com a comodidade de um simples toque do seu dedo indicador, você passaria pelas obras de Miró a Monet, espiaria um
quadro de Magritte e se deliciaria com Salvador Dalí, sem se cansar, sem ficar com as pernas dormentes e principalmente sem ter que entender o mapa do museu. Você trocaria?
Claro que não! Ir ao Louvre e ficar diante da Coroação de Napoleão é indescritível, caminhar pelo museu do Prado e
admirar cada detalhe do Jardim das Delicias, de Bosch, conferir a Guernica de Picasso no Reina Sofía e se perder na ala de impressionismo do D’orsay… não tem preço. E nenhuma experiência virtual subistitui ou chega perto dessa sensação.
Mas confesso que essa ideia me atraiu muito. Semana passada baixei um aplicativo para meu iPod Touch chamado Art Gallery.
Nele visualizo obras de arte como se estivesse em um museu. Meu comportamento foi igual ao da vida real. Passei mais rápido pelas obras que não me agradam e me peguei admirando por mais tempo as obras que me agradam. Com a diferença que no meu ipod posso salvar meus quadros prediletos na seção Favoritos. Isso, sim, achei sensacional!
Posso ter minha própria galeria de arte na bolsa, com os quadros que já vi, ou que desejo ver um dia. Estou no ranking geral do aplicativo com 899 obras já vistas. Eba!!
Ver a Coroação de Napoleão numa tela de 320X480 não se compara à visão real do quadro. No entanto, esse aplicativo me
apróxima dos principais mestres da pintura a cada noite. E realmente fiquei me perguntando o quanto essas novas
midias enriquecem (no sentido cultural) o nosso dia-a-dia.
Como uma simples paginação de imagens, pode trazer o mundo para a palma da minha mão e diminuir as distâncias do mundo real.
Fica a dica para quem gosta de arte e tecnologia!
Abraços,
#todomundonux no 3º EBAI
Publicado por: nuxabril em: Outubro 5, 2009
Todo mundo NUX no EBAI
Começamos bem o EBAI desse ano, a Try criou uma dinâmica muito interessante, todos os participantes receberam 16 fichas de uma personalidade da área (Jared Spool, Donald Norman…), o objetivo era trocar sua personalidade com outros participantes para completar o seu Try Trunfo e concorrer a livros. O pessoal realmente se entreteve com isso, todos nos sentimos na escola de novo trocando figurinhas. Muito bem produzido, parabéns Elis (@elisfer)! =D Só não sei se o networking foi sua conseqüência, pois acabamos nos fixando tanto nas fichas que às vezes até esquecíamos de nos apresentar uns aos outros, mas valeu a brincadeira. Nos divertimos muito!
Try Trunfo - Foto de Silvio Tanaka
A maratona de palestras (13 ao todo) iniciou-se com a Silvia Melo e o Fabrício Teixeira, da AgênciaClick, falando sobre o case do portal da Fiat, desde 2006 no ar, trouxeram métricas que comprovam como o planejamento web resulta em um número maior de vendas e, também, como foi o processo de concepção do conceito. O quanto foi importante ter liberdade no início do projeto, para trazer inovação ao case, e depois voltar para as premissas do projeto. E que os testes servem para aprimorar pequenas coisas e não validar a idéia.
Seguimos com a Maria Célia Furtado, da Companhia de Processamento de Dados do Estado da Bahia (Prodeb), apresentando seu case Internet e Interatividade para a Participação Pública, sobre como estabelecer princípios e definições para projetos web que estimulem essa participação por meio da ampliação do diálogo entre Administração Pública e cidadãos.
A terceira palestra, orquestrada pela Gisele Rossi Araújo e pela Tâmara Baia, da organização OpenBossa vinculada ao Instituto Nokia de Tecnologia (INdT) deu um banho de paixão e experiência. Falaram sobre pesquisas em tecnologias móveis. Expuseram como produzem seus protótipos, inclusive de hardware, para analisarem como ocorre a interação do usuário com o aparelho. Citaram as dificuldades enfrentadas em projetar para os diferentes devices. Destaque, também, para como o Scrum é inserido no processo, em especial, aos workshops criativos -que é muito próximo de uma iniciativa que estamos implantando aqui no NUX que são nossas segundas dedicadas a projetos mirabolantes =). Distribuíram um Planning Poker personalizado para quem fez perguntas, A-D-O-R-E-I-!. O paper enviado ao EBAI está disponível para download.
Open Bossa (INdT) - Planning Poker
Iniciando as palestras da tarde, Ricardo Grandinetti Teixeira, da fhios falou sobre Design centrado no usuário. Gil Barros veio causando (e esclarecendo) muitas dúvidas em relação a posição do Arquiteto de Informação, cargos e o nosso papel dentro do planejamento da experiência do usuário. Muito rico e inquietante.
Para fechar o dia Andrew Hinton ratificou o que o Gil Barros já tinha semeado e seguiu na mesma linha de discussão sobre a macro e micro AI -e o caminho é mesmo esse, uma grande área cuja finalidade é a experiência do usuário que engloba a Arquitetura de Informação do dia-a-dia. Muita boa a palestra, principalmente por deixar claro que os gringos tem as mesmas dúvidas e anseios que nós, está na hora de nos valorizarmos mais… A apresentação está disponível no slideshare.
UX ou AI?
Assim encerramos o primeiro dia. Cansados, mas satisfeitíssimos com a qualidade das apresentações e o clima do evento.
Segundo dia…
Começamos o sábado com Alessandro Dias, do INdT de Manaus contando sua experiência sobre como provar em uma apresentação o valor do trabalho do Instituto de Pesquisa. Em seguida, Leandro Gejfinbein, da Globo.com apresentou a nova estruturação do centro de AI na empresa e o uso do Scrum – muito semelhante ao momento que vivemos aqui na Abril Digital.
Ainda pela manhã, Paola Sales veio da Itália contar como a Experientia vem trabalhando na pesquisa sobre diferenças culturais e sua influência na experiência do usuário, através de testes em protótipos em papel, muita paixão aqui também. Feliphe Lavor, da Calandra Soluções nos presenteou com a primeira palestra dessa edição que tratava TI e AI juntas, seu case era uma rede social desenvolvida para o report de horas e tarefas em um ambiente corporativo. O que particularmente nos deixou muito felizes, porque é uma vitória enorme termos pessoas de TI aliadas em prol do disseminação do conhecimento sobre UX/AI. Sem contar que esse sistema pode ser facilmente linkado com o conceito de comunicação rápida e constante difundida pelo Scrum.
A tarde começou com Frederick van Amstel, Edyd junges e Rodrigo Freese Gonzatto, do Instituto Faber Ludens, que apresentaram o projeto Conectando Conteúdos. O projeto segue a linha colaborativa – como a proposta apresentada no EBAI do ano passado pelo Fred. Dentre as idéias do projeto a mais destacada foi a de intra-etiquetas: etiquetas específicas dentro dos conteúdos. Foi legal ver os alunos do Instituto expor as pesquisas desenvolvidas lá. Só ficamos com uma dúvida sobre o que diferencia a proposta de folcsonomia apresentada do que temos hoje, pois a intra-etiqueta não valerá, também, como etiqueta? Gostaríamos de entender melhor… A apresentação já está disponível.
Quase no finalzinho, Rafael Kiso da Embraer novamente apontou para um futuro próspero com seu case que une TI e UX, no projeto da nova interface para administração de chamados de manutenção em aviões. Para fechar o dia (e o evento), Felipe Memória, hoje na HUGE, veio nos contar sua experiência no exterior e, como o Gil, sacudir nossas idéias. Excepcional!
Resumindo… Falou-se muito em:
- Mobile e os desafios enfrentados pelos diferentes devices
- Aderência ao Scrum
- Valorização do Brasil no mercado de UX, pois estamos no mesmo caminho que os gringos (Felipe Memória comprovou isso em sua palestra)
- TI incorporando UX em seus processos (ponto para nós =P)
- Tenha a dedicação e a paixão exalados em uma startup!
- AI ou UX? Precisamos de cargos? Quão importante são as documentações? E tantas outras perguntas que o tema envolvem… (ah! as perguntas… elas dão um outro post! Aguardem… =P)
Mais fotos do EBAI, por Silvio Tanaka, no http://flickr.com/nuxabril
Responda nossa enquete e comente, gostaríamos de saber sua opinião 
O que um arquiteto de informação faz (e o que não faz)
Publicado por: nuxabril em: Setembro 14, 2009
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.
Esboçando Idéias
Publicado por: nuxabril em: Setembro 8, 2009
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 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/
Benchmark + Analytics + Wireframe = Design Pattern
Publicado por: nuxabril em: Agosto 25, 2009
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.
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.
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.
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.
Checklist para formulários online
Publicado por: nuxabril em: Julho 30, 2009
O tempo todo como Analistas de Usabilidade (Arquitetos de Informação/ UXes em geral) nos deparamos com a situação de incluir informações ou solicitar informações ao cliente do site, como solução mais “lógica“ temos os formulários.
Na internet pipocam, regrinhas, dicas, orientações. Em livrarias, temos livros e mais livros que abrangem o assunto. Inúmeras pesquisas têm neles seus objetos principais. Não se conhece meio mais simples para levantamento de dados. Uma coisa é certa, não vamos nos livrar deles nos próximos anos.
Nada como um checklist básico com os elementos essenciais para nos lembrar dos elementos que compõem a experiência do usuário no momento de usar um formulário criado por nós, para qualquer situação do negócio.
Este documento é uma tradução e livre ilustração, com a devida autorização da equipe do Frontend.com, que gentilmente permitiu a publicaçao em português, claro publicada aqui com os devidos créditos.
Protótipos de papel + Scrum
Publicado por: nuxabril em: Julho 10, 2009
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.
Qual melhor ferramenta? Axure, Visio, Omnigraffle, Papel…
Publicado por: nuxabril em: Julho 8, 2009
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
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.
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:
- Visio – office.microsoft.com/pt-br/visio
- Axure – axure.com
- Axure for mac? Sim, em breve! – axureformac.com
- Omnigraffle – omnigroup.com/applications/OmniGraffle
- Stencils para o Omnigraffle – graffletopia.com
- Stencils Yahoo! – developer.yahoo.com/ypatterns/wireframes
Contos da Abril Digital: Personas
Publicado por: nuxabril em: Julho 1, 2009
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:
Fonte: Graffletopia – Luis Hernandes.
NUX na Abril Digital – Núcleo de User Experience
Publicado por: nuxabril em: Junho 24, 2009
- Em: equipe
- 2 Comentários
Em meio a tantas mudanças, a Abril Digital ganha uma área que até então não existia: o Núcleo de pesquisa focado em User Experience (UX) e Arquitetura de Informação (AI).
Provavelmente você já escutou que um sistema precisa ser enxuto, objetivo e claro o suficiente para ser bem utilizado. Afinal, o tempo que se perde pensando ou fazendo uma ação errada é muito frustrante. Chega a dar vontade de falar aquela frase que brasileiro adora dizer – é tudo culpa do sistema – e no pior dos casos, ainda acredita-se que seja falha do usuário.
Tudo isso porque, quando pensamos em uma interface, em muitos projetos, a preocupação com o usuário final só se torna explícita antes da ação de lançamento. Principalmente quando temos um prazo e metas agressivas, tudo que envolve pesquisa qualitativa demonstra um outro lado da realidade. Porém, existem métodos não muito custosos que podem ser agregados a práticas de desenvolvimento ou de produto. Investigar necessidades e manter um estudo prévio centrado no usuário pode evitar retrabalhos e melhorar a produtividade do time.
Um profissional de UX inserido em seu projeto significa o amortecimento das barreiras criadas entre projetistas e a aplicação de uma interface usável, útil e que proporcione uma experiência significativa. Baseado livremente no processo de design centrado no usuario do C.E.S.A.R. pretendemos manter um fluxo de trabalho interativo através das fases de pesquisa, ideação, prototipação e avaliação.
Desde a sua formação, em maio, o NUX já começa a dar os primeiros passos. Contamos com 3 pessoas e as atividades diárias são atualmente baseadas em demandas e prioridades, as quais complementamos de acordo com a necessidade de cada projeto e o tempo que temos para executar as melhores práticas na área.
O compromisso do núcleo é a entrega de uma interação de qualidade antes do Product Backlog. Para garantir isso, o grupo participa e atua em definição de requisitos, sketches, storyboards, paper prototype e testes com usuários.
A área entende a estratégia de cada produto junto com os PO’s e avalia as necessidades frente a seu público alvo, através de interações contínuas e acompanhamento em todas as fases de vida de um projeto.
Como esse assunto rende bastante, fica apenas um gostinho inicial. Para quem tem interesse na área, pretendemos manter este blog e atualizá-lo semanalmente. No próximo post, iremos abordar o estudo de personas e aguardamos a sua visita. Contamos com você, leitor, para que siga o propósito de design centrado no usuário em seu projeto e o NUX possa sempre ajudar em seus estudos.
RSS - PostsNUX no Flickr
|
