Successfully reported this slideshow.

Agile User Experience

5,641 views

Published on

Apresentação contextualizando o conceito de Agile para Arquitetura da Informação. Por Rafael Rez Oliveira, Lógica Digital.

Published in: Design

Agile User Experience

  1. 1. A gile U ser e X perience Rafael Rez Oliveira
  2. 2. Arquitetura de Informação em 2008 <ul><li>Projetos maiores e mais complexos </li></ul><ul><li>“ Web 2.0” – maior UX para ser pensada </li></ul><ul><li>Prazos sempre escassos </li></ul><ul><li>Equipes multidisciplinares, porém pequenas </li></ul><ul><li>Usuário mais experiente e focado em tarefas </li></ul><ul><li>… desafios cada vez maiores! </li></ul>
  3. 3. Silvia Melo <ul><li>“ O ano já está em sua 24ª semana e eu em meu 20º trabalho da temporada. O número realmente é assustador - quase 1 job por semana! ” </li></ul>Blog www.arquiteturadeinformacao.com
  4. 4. Jakob Nielsen <ul><li>“ As pessoas querem sites que vão direto ao ponto, elas têm pouca paciência”. </li></ul><ul><li>“ Apesar de os designers terem melhorado, os usuários também se habituaram com o ambiente interativo”. </li></ul><ul><li>“ Agora, quando estão online, as pessoas sabem o que querem e como fazer para achar”. </li></ul><ul><li>“ Os designers e proprietários dos sites ainda pensam que possuem um site especial e interessante e que as pessoas ficarão felizes com tudo o que for jogado para elas”. </li></ul>Em entrevista para a BBC.
  5. 5. AI há 7 anos <ul><li>functional requirements </li></ul><ul><li>site map </li></ul><ul><li>card sort </li></ul><ul><li>content inventory </li></ul><ul><li>wire frames </li></ul><ul><li>taxonomy / controlled vocabulary </li></ul><ul><li>navigation model </li></ul><ul><li>task flow </li></ul><ul><li>usability evaluation </li></ul><ul><li>category structure </li></ul><ul><li>personas </li></ul><ul><li>metadata </li></ul>Joe Lamantia. The DIY Future. <ul><li>content templates </li></ul><ul><li>branding </li></ul><ul><li>style guide </li></ul><ul><li>form design </li></ul>
  6. 6. AI agora <ul><li>service design </li></ul><ul><li>brand resonance </li></ul><ul><li>emotional triggers </li></ul><ul><li>design ethnography </li></ul><ul><li>social metadata systems </li></ul><ul><li>ontology / semantic networks </li></ul><ul><li>metadata repositories </li></ul><ul><li>organizational culture </li></ul><ul><li>business transformation </li></ul><ul><li>information value chains </li></ul><ul><li>scenario based visioning </li></ul><ul><li>enterprise 2.0 adoption </li></ul><ul><li>multivariate testing </li></ul><ul><li>behavior analytics </li></ul><ul><li>enterprise architecture </li></ul><ul><li>conceptual modeling </li></ul><ul><li>collaboration environments </li></ul><ul><li>mobile experience </li></ul><ul><li>knowledge management </li></ul><ul><li>rich internet </li></ul><ul><li>social media </li></ul><ul><li>innovation pipelines </li></ul><ul><li>network mechanisms </li></ul>Joe Lamantia. The DIY Future.
  7. 7. Chaos Report 1994 <ul><li>Cenário dos projetos de software: </li></ul><ul><li>Cancelados: 31% </li></ul><ul><li>Dobro do custo: 50% </li></ul><ul><li>Prazo e orçamento OK: 16% </li></ul>
  8. 8. Metodologias de Software <ul><li>Programação Extrema (XP) (XP, Beck, 2000) </li></ul><ul><li>DSDM (Dynamic Systems Development Method) (DSDM, Stapleton, 2003) </li></ul><ul><li>Adaptive Software Development (ASG, Highsmith, 1999) </li></ul><ul><li>Crystal (Cockburn, 2001) </li></ul><ul><li>Feature-Driven Development (FDD, Coad, LeFebvre et al; Palmer & Felsing, 2002) </li></ul><ul><li>Pragmatic Programming </li></ul><ul><li>Test Driven Development </li></ul><ul><li>Scrum </li></ul><ul><li>Várias tentativas de equilibrar os diversos fatores que afetam a </li></ul><ul><li>qualidade do produto final do desenvolvimento de um projeto. </li></ul>
  9. 9. A história tende a se repetir <ul><li>O que podemos aprender para não cometer os mesmos erros do passado? </li></ul><ul><li>Como manter a complexidade sob controle? </li></ul><ul><li>Existe uma forma de considerar tudo sem errar? </li></ul>
  10. 10. 37 signals <ul><li>Sucesso de Getting Real </li></ul><ul><li>Tendência pela simplificação </li></ul><ul><li>Ênfase em equipes com poucas pessoas e muitas competências </li></ul><ul><li>Para cada item que entra num projeto, um outro tem de sair </li></ul><ul><li>Foco no foco do usuário </li></ul><ul><li>Menos é mais </li></ul>
  11. 11. User Experience <ul><li>O próprio Donald Norman acredita que o termo “ user experience ” está desgastado e não encontra mais uma definição única e explícita. </li></ul><ul><li> “ Eu inventei o termo [ user experience ] porque pensei que human interface e usabilidade eram muito restritivos. Eu queria cobrir todos os aspectos da experiência da pessoa com o sistema, incluindo os gráficos de design industrial, a interface, a interação física e o manual. Mas uma vez que o termo se popularizou tanto, está começando a perder seu significado.” </li></ul>http://exvertebrum.wordpress.com/2007/12/14/entrevista-sobre-experiencia-do-usuario-com-donald-norman
  12. 12. Como definir U ser e X perience? <ul><li>Dan Saffer criou um diagrama que relaciona várias áreas que devem se preocupar com a experiência do usuário. Nathan Shedroff foi além, relacionando as áreas design. </li></ul>
  13. 13. Dan Saffer
  14. 14. Nathan Shedroff
  15. 15. Metodologia <ul><li>Se nem a definição sobre AI é precisa, nenhuma metodologia será única nem definitiva, nem mesmo conseguirá abranger todos os tipos de problemas que um Arquiteto de Informação pode vir a enfrentar ao projetar uma interface ( Organização – Rotulação – Navegação – Busca ). </li></ul><ul><li>Por isso, todas as ferramentas e metodologias são boas, mas o AI deve saber o quê usar e quando usar . </li></ul>
  16. 16.
  17. 17. AIceberg Peter Morville. IA Summit 2008.
  18. 18. <ul><li>Mesmo com tanto a se pensar, este ainda pode ser um trabalho muito solitário… </li></ul>
  19. 19. Leah Buley. How to be a UX team of one. IA Summit 2008.
  20. 20. Leah Buley. How to be a UX team of one. IA Summit 2008.
  21. 21. <ul><li>Por isso o Agile pode ajudar. </li></ul>
  22. 22. “ The Agile Manifesto” <ul><li>Simplicidade – a arte de maximizar a quantidade de trabalho não executado – é essencial. </li></ul><ul><li>As melhores arquiteturas, requerimentos e designs emergem de equipes auto-organizadas. </li></ul><ul><li>Em intervalos regulares, as equipes refletem sobre como ser mais efetivas, então se sintonizam e ajustam seu comportamento de acordo com as conclusões. </li></ul>
  23. 23. Princípios do Agile Development <ul><li>Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais; </li></ul><ul><li>Softwares funcionais são a principal medida de progresso do projeto; </li></ul><ul><li>Até mesmo mudanças tardias de escopo no projeto são bem-vindas; </li></ul><ul><li>Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores; </li></ul><ul><li>Projetos surgem através de indivíduos motivados, deve existir uma relação de confiança; </li></ul><ul><li>Rápida adaptação às mudanças; </li></ul><ul><li>Indivíduos e iterações ao invés de processos e ferramentas; </li></ul><ul><li>Software funcional ao invés de documentação extensa; </li></ul><ul><li>Colaboração com clientes ao invés de negociação de contratos; </li></ul><ul><li>Responder a mudanças ao invés de seguir um plano. </li></ul>
  24. 24. Best Practices of Agile Modeling
  25. 25. <ul><li>Agile Rápido </li></ul>
  26. 26. <ul><li>Desenvolvimento direcionado ao planejamento: </li></ul><ul><ul><li>Alta criticidade </li></ul></ul><ul><ul><li>Desenvolvedores junior </li></ul></ul><ul><ul><li>Baixa mudança nos requerimentos </li></ul></ul><ul><ul><li>Grande número de desenvolvedores </li></ul></ul><ul><ul><li>Cultura que procura a ordem </li></ul></ul><ul><li>Desenvolvimento ágil: </li></ul><ul><ul><li>Baixa criticidade </li></ul></ul><ul><ul><li>Desenvolvedores sênior </li></ul></ul><ul><ul><li>Mudanças freqüente de requerimentos </li></ul></ul><ul><ul><li>Pequeno número de desenvolvedores </li></ul></ul><ul><ul><li>Cultura que tem sucesso no caos </li></ul></ul>B. Boehm. Balancing Agility and Discipline: A Guide for the Perplexed . Boston, MA: Addison-Wesley, 2004. 55-57 p Ambiente ideal para desenvolvimento
  27. 27. <ul><li>Leah sugere apenas 3 idéias [macro-etapas] para o início de um projeto: </li></ul>
  28. 28. Leah Buley. How to be a UX team of one. IA Summit 2008.
  29. 29. A melhor ferramenta de AI…
  30. 30. Vantagens da Prototipagem em Papel <ul><li>É rápido </li></ul><ul><li>É suficientemente superficial ou relativamente profundo – dependendo da sua necessidade </li></ul><ul><li>Explorar - Permite testar facilmente diferentes idéias </li></ul><ul><li>Comunicar - Apresenta as idéias de uma forma que pode ser entendida facilmente </li></ul><ul><li>Colaborar - Facilita que todo o time de design construa e avalie o protótipo </li></ul><ul><li>Validar - Determina a eficiência dos elementos de design e do fluxo de navegação </li></ul>Paper Prototype. Guilhermo Reis. 2004.
  31. 31. Porque usar Agile para UX? <ul><li>Facilitar o trabalho colaborativo </li></ul><ul><li>Modelar objetivos de negócios </li></ul><ul><li>Modelar fluxos como estórias de usuários (User Story) </li></ul><ul><li>Mapear </li></ul><ul><li>Alinhar Prototipagem em Papel e Testes de Usabilidade </li></ul><ul><li>Fazer e seguir um Planejamento de Implantação (Design e Programação) </li></ul>
  32. 32. Permite fazer iterações curtas <ul><li>Cada iteração é uma entrega, permitindo trabalhar em sprints </li></ul><ul><li>Pode-se aprofundar o que for necessário na documentação a cada sprint , e não no início do projeto, o que muitas vezes gera atrasos e consome muito tempo, que acaba faltando na reta final </li></ul><ul><li>Colaboração com o cliente e com o usuário </li></ul><ul><li>Resposta rápida à mudanças </li></ul>
  33. 33. <ul><li>“ Faça só o que deve ser feito.” </li></ul><ul><li>“ A coisa louca é, que em retrospectiva, é quase óbvia a aplicação dos princípios do Agile para o design da experiência do usuário. Eles não fazem você necessariamente trabalhar mais rápido tanto quanto deixam você trabalhar de maneira mais ágil.” </li></ul><ul><li>Austin Govella Thinking & Making </li></ul>
  34. 34. <ul><li>“ Quando estou trabalhando em um problema, nunca penso sobre beleza. Eu penso unicamente em como resolver o problema. Mas quando eu termino, se a solução não é bonita, eu sei que está errada”. </li></ul><ul><li>Buckminster Fuller </li></ul>
  35. 35. Rafael Rez Oliveira e-mail: [email_address] Site: www.logicadigital.com.br Blog: http://exvertebrum.wordpress.com

×