Marco Gomes sobre User Experience

  • 1,453 views
Uploaded on

Apresentação sobre User Experience para equipe da Trend-i.

Apresentação sobre User Experience para equipe da Trend-i.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Marco, vc falou basicamente sobre 1 pedacinho do que compõe a UX. O design das GUIs. (nem UI, sendo bem chato com os termos). De toda forma, como Design de GUI ficou muito boa a apresentação :)
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
1,453
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
30
Comments
1
Likes
10

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. DESIGN DE INTERFACE @marcogomes, boo-box, 2009 quinta-feira, 11 de junho de 2009
  • 2. A MANEIRA QUE VOCÊ EXECUTA TAREFAS COM UM PRODUTO - O QUE VOCÊ FAZ E COMO ELE RESPONDE - ISSO É A INTERFACE. Jeff Raskin, 2000 quinta-feira, 11 de junho de 2009
  • 3. DESIGN ANTES DA PROGRAMAÇÃO quinta-feira, 11 de junho de 2009 Design antes da programação Front-end antes do backend
  • 4. A PARTIR DO MOMENTO QUE O OBJETIVO DO PRODUTO É CONHECIDO, PROJETE A INTERFACE PRIMEIRO; DEPOIS PROGRAME DE ACORDO COM A INTERFACE Jeff Raskin, 2000 quinta-feira, 11 de junho de 2009
  • 5. Design da Idéia Programação Entrega interface Teste Teste Teste Tempo quinta-feira, 11 de junho de 2009
  • 6. GUIA GETTING REAL 37signals quinta-feira, 11 de junho de 2009
  • 7. DESIGN DE EPICENTRO Comece do núcleo da página e construa pra fora quinta-feira, 11 de junho de 2009 no começo, você ignora as extremidades: a navegação/menus, rodapé, cores, barra lateral, logotipo, etc. Em vez disso, você começa o epicentro e faz o design das peças de conteúdo mais importantes primeiro.
  • 8. SOLUÇÃO DE TRÊS ESTADOS Faça design para os estados regular, branco e erro. quinta-feira, 11 de junho de 2009 Regular: A tela que as pessoas vêem quando tudo está funcionando bem e sua aplicação é preenchida com dados. Branco/Vazio: A tela que as pessoas vêem quando estão usando a aplicação pela primeira vez, antes de dados serem inseridos. Erro: A tela que as pessoas vêem quando alguma coisa dá errado.
  • 9. A TELA EM BRANCO Supere as expectativas com uma primeira experiência convincente quinta-feira, 11 de junho de 2009 o estado natural da aplicação é vazia de dados. Quando alguém se cadastra, eles começam com uma tela em branco. Muito parecido com um weblog, cabe a eles popularem — o visual geral não toma forma até as pessoas colocarem seus dados: publicações, links, comentários, horas, informação de barra lateral ou o que for.
  • 10. CONTEXTO SOBRE CONSISTÊNCIA O que faz sentido aqui, pode não fazer sentido ali http://www.usabilitypost.com/2008/08/04/context-over-consistency/ quinta-feira, 11 de junho de 2009 contexto é mais importante que consistência. Tudo bem ser inconsistente se o seu design faz mais sentido dessa maneira. Forneça às pessoas apenas o que importa. Ofereça a eles o que eles precisam e livre-se de tudo o que não for necessário. É melhor ser correto do que ser consistente.
  • 11. REDAÇÃO É DESIGN DE INTERFACE Cada palavra importa. quinta-feira, 11 de junho de 2009 Você etiqueta um botão como Submeter ou Salver ou Atualizar ou Novo ou Criar? Isso é redação. Você escreve três sentenças ou cinco? Explica com exemplos gerais ou com detalhes? Etiqueta seu conteúdo como Novo ou Atualizado ou Atualizado Recentemente ou Modificado? Será Existem novas mensagens: 5 ou Existem 5 novas mensagens ou é 5 ou cinco ou mensagens ou publicações? Tudo isso importa.
  • 12. UMA INTERFACE Incorpore funções administrativas em interfaces públicas quinta-feira, 11 de junho de 2009 Para evitar a síndrome da tela-administrativa-lixo, não construa telas separadas para lidar com funções administrativas. Em vez disso, construa essas funções (isto é, editar, adicionar, deletar) na interface regular da aplicação.
  • 13. MISSÃO: ACERTAR A HORA quinta-feira, 11 de junho de 2009
  • 14. MISSÃO: ACERTAR A HORA quinta-feira, 11 de junho de 2009
  • 15. MANTENHA O SIMPLES SIMPLES quinta-feira, 11 de junho de 2009 Acertar a hora em um Relógio Digital VCR (Video Cassete)
  • 16. MISSÃO: ACERTAR A HORA quinta-feira, 11 de junho de 2009
  • 17. MISSÃO: ACERTAR A HORA quinta-feira, 11 de junho de 2009
  • 18. MISSÃO: ACERTAR A HORA + hora + minuto 19:42 - hora - minuto quinta-feira, 11 de junho de 2009
  • 19. DIVIDINDO INFORMAÇÃO NO TEMPO E NO ESPAÇO http://marcogomes.com/blog/2008/organizando-informacao-no-tempo-e-no-espaco quinta-feira, 11 de junho de 2009 No tempo, para ações não repetitivas No espaço, para ações repetitivas
  • 20. TEMPO Bom para ações não repetitivas e onde o usuário se sente inseguro, como rotinas de cadastro e configuração. Não exige treinamento. quinta-feira, 11 de junho de 2009
  • 21. ESPAÇO Bom para ações de rotina, como inserção e edição de dados. Pode exigir algum treinamento nos primeiros usos (curva de aprendizado). quinta-feira, 11 de junho de 2009
  • 22. LEI DE FITTS http://marcogomes.com/blog/2008/organizando-informacao-no-tempo-e-no-espaco quinta-feira, 11 de junho de 2009 Uma das regras mais importantes no desenvolvimento de interfaces
  • 23. MT = a + b log2(2A/W) http://particletree.com/features/visualizing-fittss-law/ quinta-feira, 11 de junho de 2009 MT = time to complete the movement a,b = relativos ao tempo de movimento e velocidade do dispositivo A = distance of movement from start to target center W = width of the target along the axis of movement
  • 24. MT = a + b log2(2A/W) WTF? http://particletree.com/features/visualizing-fittss-law/ quinta-feira, 11 de junho de 2009 MT = time to complete the movement a,b = relativos ao tempo de movimento e velocidade do dispositivo A = distance of movement from start to target center W = width of the target along the axis of movement
  • 25. A DIFICULDADE PARA ATINGIR UM ALVO É UMA FUNÇÃO DA DISTÂNCIA DO ALVO E DE SEU TAMANHO Paul Fitts, 1954 quinta-feira, 11 de junho de 2009
  • 26. Facilidade para acertar quinta-feira, 11 de junho de 2009 quanto maior o alvo, mais fácil acertar (grande coisa)
  • 27. http://particletree.com/features/visualizing-fittss-law/ quinta-feira, 11 de junho de 2009 a posição do cursor influencia
  • 28. http://particletree.com/features/visualizing-fittss-law/ quinta-feira, 11 de junho de 2009 a área de acerto também influencia, os dois últimos elementos têm áreas semelhantes, é mais fácil acertar o último. aumentar um pouco itens pequenos melhora exponencialmente a facilidade de acerto
  • 29. http://particletree.com/features/visualizing-fittss-law/ quinta-feira, 11 de junho de 2009 a fase de desaceleração é importante
  • 30. http://particletree.com/features/visualizing-fittss-law/ quinta-feira, 11 de junho de 2009 as margens da tela são os alvos mais fáceis, tem largura ou altura infinitas por não haver necessidade de desaceleração
  • 31. WINDOWS 98 Erraram por um pixel, corrigido no Windows XP http://blogs.msdn.com/jensenh/archive/2006/08/22/711808.aspx quinta-feira, 11 de junho de 2009
  • 32. MENUS FÁCEIS DE ACERTAR No topo das telas de Mac OS X e Gnome quinta-feira, 11 de junho de 2009
  • 33. MENSAGENS AO USUÁRIO http://marcogomes.com/blog/2008/organizando-informacao-no-tempo-e-no-espaco quinta-feira, 11 de junho de 2009
  • 34. MINHA INTERAÇÃO É INÚTIL Eu não posso fazer nada além de clicar no “OK”, a mensagem bloqueia o uso do navegador. quinta-feira, 11 de junho de 2009
  • 35. MENSAGEM HUMANA Não exige uma interação inútil, some com o mover do mouse e não bloqueia o uso do navegador quinta-feira, 11 de junho de 2009
  • 36. MENSAGEM INTEGRADA Não exige uma interação inútil, aparece integrada ao conteúdo e não bloqueia o uso do navegador quinta-feira, 11 de junho de 2009
  • 37. versus USE VERBOS COMO AÇÕES DE BOTÕES quinta-feira, 11 de junho de 2009 mesmo que o usuário não leia o que diz a caixa de mensagem, vai ler o que está escrito no botão.
  • 38. LEI DE HICK http://en.wikipedia.org/wiki/Hick's_law quinta-feira, 11 de junho de 2009 Tempo para achar um item numa lista (menu) Menu com poucos itens, perde-se muito Menu com muitos itens, perde-se pouco
  • 39. T = blog2(n + 1) O TEMPO NECESSÁRIO PARA ESCOLHER UM ITEM EM UMA LISTA (COMO UM MENU) AUMENTA EXPONENCIALMENTE COM O NÚMERO DE ITENS QUE PODEM SER ESCOLHIDOS quinta-feira, 11 de junho de 2009
  • 40. AO ADICIONAR UM ITEM EM UM MENU COM POUCOS ITENS VOCÊ ESTÁ DIFICULTANDO, EXPONENCIALMENTE, A ESCOLHA DOS USUÁRIOS. quinta-feira, 11 de junho de 2009
  • 41. DUAS LEIS DO DESIGN DE INTERFACE 1. Um computador não deve danificar seu trabalho ou, por inação, deixar que seu trabalho sofra danos. 2. Um computador não deve perder seu tempo ou exigir que você faça mais trabalho do que o estritamente necessário. Jef Raskin, The Humane Interface, 2000 quinta-feira, 11 de junho de 2009
  • 42. REFERÊNCIA • http://marcogomes.com/blog/2007/interfaces- • http://humanized.com/weblog/2006/09/11/ humanas-modais-e-quasimodais-jef-raskin monolog_boxes_and_transparent_messages/ • http://migre.me/20Ys • http://migre.me/20Z3 • http://www.mezzoblue.com/archives/ • http://gettingreal.37signals.com/ 2004/08/19/fitts_law/ GR_por.php#ch09 • http://www.asktog.com/columns/ 022DesignedToGiveFitts.html • http://en.wikipedia.org/wiki/Fitts's_law • http://www.mindhacks.com/blog/2005/01/ size_and_selection_t.html • http://www.usabilitypost.com/2008/08/30/ usability-tip-use-verbs-as-labels-on-buttons/ • http://www.mikewhobikes.com/hey-whats-this- button-do/ quinta-feira, 11 de junho de 2009
  • 43. DESIGN DE INTERFACE @marcogomes, boo-box, 2009 quinta-feira, 11 de junho de 2009