O documento resume uma aula sobre usabilidade e engenharia de software centrada em métodos ágeis. Apresenta conceitos como análise heurística, plano de curso, técnicas de prototipação como storyboards, wireframes e fluxos de tarefas. Discute como aplicar análise heurística em protótipos ou releases para encontrar problemas de usabilidade.

1. aula 6
Engenharia de Software Centrada em Métodos Ágeis
Usabilidade
Marcello de Campos Cardoso | www.mcardoso.com.br | mcardoso@gmail.com
Friday, June 17, 2011

2. Recapitulando...
Análise Heurística
“Análise Heurística (Nielsen and Molich, 1990; Nielsen 1994) é um método de
engenharia de usabilidade para encontrar os erros de usabilidade em uma interface para
que sejam corrigidos em um processo de desenvolvimento iterativo.
Envolve um pequeno grupo de avaliadores para examinar a interface e avaliá-la de
acordo com princípios de usabilidade reconhecidos (as heurísticas).” - Nielsen
Friday, June 17, 2011

3. Plano de curso
1ª aula Introdução a Usabilidade: conceitos, origem (DCU, IHC), aplicação (IxD), metas
2ª aula de usabilidade, princípios de design, estudo de casos, benefícios, ciclos de vida
de desenvolvimento (cascata x ágil), técnicas (overview).
3ª aula Técnica de Modelagem: Personas ágeis (workshop)
4ª aula Story Mapping (workshop)
5ª aula Perguntando a especialistas:
Análise Heurística, As 10 heurísticas de Nielsen (workshop)
6ª aula Projetando a interface:
Task Flow + Prototipação rápida (workshop)
7ª aula Testes de usabilidade (workshop - roteiro)
8ª aula Testes de usabilidade (workshop - aplicação)
Friday, June 17, 2011

4. Análise heurística
Onde aplicar?
Reunião diária
pode ser aplicada
Backlog do Backlog do em protótipos ou
produto sprint releases
Friday, June 17, 2011

5. Análise heurística
Como fazer?
1º passo: Briefing
• Os avaliadores discutem os critérios da avaliação como tarefas por exemplo
2º passo: Avaliação (cerca de 2h)
• Independente
• Double check - 1 para fluxo e tarefas e outro para interface e elementos
3º passo: Reunião de resultados e relatório
• Discutir problemas
• Priorizá-los
• Elaborar recomendações e soluções
Friday, June 17, 2011 sequência de uso

6. Análise heurística
Como fazer?
1º passo: Briefing
• Os avaliadores discutem os critérios da avaliação como tarefas por exemplo
2º passo: Avaliação (cerca de 2h)
• Independente
• Double check - 1 para fluxo e tarefas e outro para interface e elementos
3º passo: Reunião de resultados e relatório
• Discutir problemas
• Priorizá-los
• Elaborar recomendações e soluções
Friday, June 17, 2011 sequência de uso

7. Análise heurística
Como fazer?
1º passo: Briefing
• Os avaliadores discutem os critérios da avaliação como tarefas por exemplo
2º passo: Avaliação (cerca de 2h)
• Independente
• Double check - 1 para fluxo e tarefas e outro para interface e elementos
3º passo: Reunião de resultados e relatório
• Discutir problemas
• Priorizá-los
• Elaborar recomendações e soluções
Friday, June 17, 2011 sequência de uso

8. Exemplo de planilha de aplicação
Friday, June 17, 2011 sequência de uso

9. Exemplo de aplicação
H2
H7
H9
H5
Friday, June 17, 2011 sequência de uso

10. Exemplo de aplicação
Friday, June 17, 2011 sequência de uso

11. Análise heurística
10 Heurísticas de Jakob Nielsen
1. Visibilidade do status do sistema (feedback)
2. Compatibilidade do sistema com o mundo real (affordance)
3. Controle do usuário e liberdade
4. Consistência e padrões
5. Prevenção de erros
6. Reconhecer em vez de relembrar
7. Flexibilidade e eficiência no uso
8. Estética e design minimalista
9. Ajudar os usuários a reconhecer, diagnosticar e corrigir erros
10.Ajuda e documentação
Friday, June 17, 2011 sequência de uso

12. Prototipação
quebrando ovos para fazer omeletes
Friday, June 17, 2011 sequência de uso

13. Protótipo = modelo
Friday, June 17, 2011 sequência de uso

14. Modelos
São ferramentas simples e poderosas para melhorar a
visibilidade, compreensão e a comunicação de informações.
Friday, June 17, 2011

15. Podem ser de baixa ou alta resolução
Baixa: Para explorar ideias, conceitos, fluxos
Alta: para validar decisões pontuais
Friday, June 17, 2011

16. “Devemos criar exatamente quanta
documentação necessitamos para
executar bem um projeto, e não mais.”
-Dan Saffer
Friday, June 17, 2011

17. Nós <3 PAPEL!
• Nada digital é mais rápido, flexível e fácil de prototipar
• Não requer habilidades específicas
• É mais barato e colaborativo;
• Variedade = possibilidades: Diferentes cores, tamanhos, texturas, adesivos..
• Tamanho é documento (difícil ter um monitor do tamanho de uma
cartolina)
• Estimula desapego
• Reciclável, divertido, estimula a equipe
Friday, June 17, 2011

18. Cenário
“São protótipos feitos de palavras”
•Os protagonistas são as PERSONAS
•Devem refletir comportamento no sistema
•Uma boa prática é passar diferentes personas pelo
mesmo cenário
•Um bom cenário é imaginar o primeiro uso
Friday, June 17, 2011

19. Cenário
Uma imagem vale mil palavras.
Mas as palavras certas podem valer algumas boas imagens.
Lúcia Maria loga em sua conta Sacolao.com. Vê seu pedido da semana passada e
decide usá-lo de novo para esta semana. Remove alguns itens arrastando-os
de sua Cestinha®, e o valor ajusta automaticamente. Satisfeita com a
compra, clica no botão Entrega rápida e confirma o débito em seu cartão de
crédito previamente salvo. A tela de confirmação informa para esperar a
entrega nas próximas 2 horas.
Friday, June 17, 2011 sequência de uso

20. TO DO DO N E
EM GRUPO!
Criar um cenário (primeiro uso ou tarefa
chave) e aplicá-lo em sua Persona Focal +
outra criada por seu grupo, a sua escolha
tempo: 15’
Friday, June 17, 2011 sequência de uso

21. Task flows
diagrama de fluxo
• Fluxos são tão importantes quanto telas
• Quanto mais “cascata”, mais robusto e formal o task flow
Friday, June 17, 2011 sequência de uso

22. Task flows
diagrama de fluxo
Friday, June 17, 2011 sequência de uso

23. FFFFFFFF
FFFFFFFF
FFFFFFFF
task flows
diagrama de fluxo
UUUUUUU
Friday, June 17, 2011 sequência de uso

24. Task flows
diagrama de fluxo
Fluxos são interações de um indivíduo, elementos / escolhas
Friday, June 17, 2011 sequência de uso

25. Task flows
diagrama de fluxo
Exemplo: Adicionando um item na TO-DO do Basecamp.
Friday, June 17, 2011 sequência de uso

26. Task flows
diagrama de fluxo
• É rápido de fazer e simples de enxergar.
• Ideal para sprints!
Friday, June 17, 2011 sequência de uso

27. Task flows
diagrama de fluxo
Estrutura
• Barra separa a UI da ação
• Barra pontilhada separa as opções para mesma ação
• Setas vão da ação para a nova UI
• Se a UI for fora de escopo, mantém simples, sem ação
Friday, June 17, 2011 sequência de uso

28. TO DO DO N E
EM GRUPO! al (e
arefa princip
lu xo da t
definir f iderando
os
cons
er tempo)
mais, se d
so.
casos de u
tem po: 15’
Friday, June 17, 2011 sequência de uso

29. Rascunhos
• Ideias primárias, generalistas, fluxos.
• São feios! estimulam a discussão sobre função e uso
Friday, June 17, 2011 sequência de uso

30. Rascunhos
Friday, June 17, 2011

31. TO DO DO N E
EM G RUPO!
relâmpago!
E xercício conteple
m o
qu e
s
Fazer rascunho
cenário.
tempo:
5’
Friday, June 17, 2011 sequência de uso

32. Storyboards
Técnica da publicidade, HQs e cinema, que ilustra
interações complexas
Friday, June 17, 2011

33. Storyboards
• Imagens + legendas
• Ilustram fluxos, momentos chave
• Casos de uso
• Mostram ambientes e contextos
• Complementam wireframes
Friday, June 17, 2011

34. Storyboards
Friday, June 17, 2011

35. Wireframes
Friday, June 17, 2011

36. Wireframes
protótipos estruturais do sistema
Friday, June 17, 2011

37. Wireframes
protótipos estruturais do sistema
Registram as funcionalidades do produto, seus aspectos técnicos e sua lógica
de negócios, sem a influência do design visual (branding, layout)
Friday, June 17, 2011

38. Wireframes
protótipos estruturais do sistema
Registram as funcionalidades do produto, seus aspectos técnicos e sua lógica
de negócios, sem a influência do design visual (branding, layout)
Podem ser usados para validar ideias
Friday, June 17, 2011

39. Wireframes
protótipos estruturais do sistema
Registram as funcionalidades do produto, seus aspectos técnicos e sua lógica
de negócios, sem a influência do design visual (branding, layout)
Podem ser usados para validar ideias
Podem ser usados para testes com usuários
Friday, June 17, 2011

40. Wireframes
Substituem documentos mais burocráticos, são
especificações visuais comprometidas com:
• Estrutura
• Arquitetura da informação
• Controles (padrões de interação)
• Conteúdo
Friday, June 17, 2011

41. Friday, June 17, 2011

42. Friday, June 17, 2011

43. Friday, June 17, 2011

44. Friday, June 17, 2011

45. Friday, June 17, 2011

46. Friday, June 17, 2011

47. papel=desapego
Friday, June 17, 2011

48. Friday, June 17, 2011

49. Friday, June 17, 2011

50. Prototipando e testando lo fi
http://www.youtube.com/watch?v=k9mTvt0LXgk
Friday, June 17, 2011

51. Exemplos: software (fireworks)
Wireouts
Friday, June 17, 2011

52. Exemplos: software (Fireworks)
Layouts
Friday, June 17, 2011

53. testando protótipos
teste em qualquer iteração.
Friday, June 17, 2011 sequência de uso

54. O que testar em wires de baixa resolução?
• Validar demandas • Aceitação em relação à interface
• Conceito do produto/serviço • Desempenho
• Comparar designs alternativos • Acessibilidade
• Fluxo de tarefas • Satisfação no uso
• Compreensão da interface
Friday, June 17, 2011 sequência de uso

55. O que testar em wires de média resolução?
• Validar demandas • Aceitação em relação à interface
• Conceito do produto/serviço • Desempenho
• Comparar designs alternativos • Acessibilidade
• Fluxo de tarefas
• Compreensão da interface
• Satisfação no uso
Friday, June 17, 2011 sequência de uso

56. O que testar em wires de média resolução?
• Validar demandas • Conceito do produto/serviço
• Conceito do produto/serviço • Comparar designs alternativos
• Comparar designs alternativos
• Fluxo de tarefas
• Compreensão da interface
• Satisfação no uso
• Desempenho
• Acessibilidade
• Satisfação no uso
Friday, June 17, 2011 sequência de uso

57. Considerações sobre baixa e média resolução
1. Verificação limitada de erros
2. “Uso” conduzido pelo facilitador
3. Limitações de fluxos e navegações
4. Rápido e barato
Friday, June 17, 2011 sequência de uso

58. Considerações sobre alta resolução
1. Demanda tempo para criação
2. Custo de produção mais alto
3. Uso mais próximo do real
4. Mesmo look and feel do produto final
Friday, June 17, 2011 sequência de uso

59. Wireframes
Quando testar em protótipo e não no produto final?
1. Necessário desenvolver tecnologia para o produto final
2. Limitação de orçamento ou prazo
3. Testar conceito do produto
4. Testar diferentes alternativas de design
Friday, June 17, 2011 sequência de uso

60. Wireframes
Quando testar em produto final e não no protótipo?
1. Comparação de desempenho com concorrentes
2. Criar o protótipo exigirá o mesmo tempo ou mais
3. Testar bugs no sistema
4. Compreender uso real do produto
Friday, June 17, 2011 sequência de uso

61. EM
GRU
Pro t PO !
rasc o ti p a
unho r em
s, ou cima
tem refin dos
po: r á-lo
esto s
da a
ula
isso é ágil, podemos
Lemb rem que i decidido.
mudar o que fo
ÇÃO = CAOS!
Friday, June 17, 2011
IDEA

62. gad o !
o b ri
Este arquivo contém a apresentação realizada por Marcello de Campos Cardoso,
em junho de 2011, para a disciplina Engenharia de Usabilidade ministrada no
curso de especialização Engenharia de Software Centrada em Métodos Ágeis,
no Centro Universitário UNA.
Friday, June 17, 2011