Aulas 7. IHC – Projeto de Interface com o Usuário

1. A
Prof. Dra. Sílvia Dotta
Aulas 7. IHC –Projeto de Interface com o Usuário
IHM
Interface Humano-Máquina

2. Processo de desenvolvimento da interface

3. Projeto de Interface com o
usuário
•
O projeto de interface com o usuário cria um meio efetiv o de
comunicação entre o ser humano e o computador
“Para o usuário, a interface é o sistema”

4. •Mapade Informações(MatrizesCategorizadasde Escopo).
•Análisede Tarefas(Matrizese Fluxogramasde Tarefas).
•Regrasde NegóciosFluxogramase Documentosde Negócios).
•Testes taxonômicos.
•Escolheroselementosdainterface. (texto, áudio, vídeo, fo to,
infográficos)
•
Contexto
de
uso
.
Projeto de Interface -requisitos
•
Contexto
de
uso
.
•Cenáriode uso.
•Requisitospara“fazeracontecer”.
PDeterminarosrecursostécnicosparaa construçãodainterface.
PIntroduziroselementoscorretosde linguagemnacomunicação
com o público-alvo.
PCriarconceitoestético.
PIntroduzira Direçãode Arte no timing correto.

5. A informação“comunica” e se tornaconsistentequando:
PPossui uma categorização lógica e natural para o us uário dentro do
cenário de uso.
Projeto de Interface –design de
informação
PPodeser localizadasempreno mesmolugar.
PNãoperdea identidadequandoassociadaa outrosconteúdos, mas
agregaoutrossentidos.
PÉ importantee útildentrodos contextoe cenáriode uso propostos
parao projeto.

6. O queé maisimportanteaoprojetarmose construírmosinterfaces?
PHarmonizarElementosde Interação.
PDistribuira informaçãode forma lógicae natural.
PNuncasobreporconceitosestéticosà ArquiteturadaInfor mação.
PHarmonizarmenus e categoriasde navegação.
P
Flexibilizar
sem
bagunçar
.
Projeto de Interface -AI
P
Flexibilizar
sem
bagunçar
.
PRefletircom exatidãoas regrasde negócio.
PTratara parte de conteúdocomoum produtoeditorial.
PTratara interaçãocom sistemacomoprodutointerativo.
PMensurarretornosparapossíveiscorreções.
PCuidadoextremocom a redudânciataxonômica.
PObservaro quesitoacessibilidade.
PMensuraro momentocorretode introduzirinovações.
PDosaro conteúdoe a ofertade novas áreasourecursos/ conteúdos.

7. Não-linearidadee resgatedo “fiodameada”:
PÉ o grandedesafio.
PConteúdolinear e com grandeprofundidadepodeser editado.
PAs taxonomiassãode grandeimportânciaporqueagregam
pistassobreossubníveis.
P
Se
errarmos
na
definição
das
primeiras
categorias
, o
trabalho
Projeto de Interface -AI
P
Se
errarmos
na
definição
das
primeiras
categorias
, o
trabalho
estarácomprometido.
PA memorizaçãodainformaçãodependetambémdaforma
comoelaé apresentada.
PAs associaçõesfeitasdurantea navegaçãosubstituema
sequênciatemporal.
PDefinirnúcleosdainformaçãoé algofundamental.

8. Elementosde linguageme comunicação
•Cores.
•Símbolos.
•Idioma.
•PadrõesEstéticos.
•
Tipos
e
temas
de
fotos
.
Projeto de Interface -AI
•
Tipos
e
temas
de
fotos
.
•Sons e música.
•Etc..

9. Wireframes •Wireframes devemdeterminara proporcionalidadedos
elementosde informaçãoe interação.
•Wireframe devedeterminarquaisostiposde interaçãoaparecem
emcadanívelde informação.
•
Wireframe
deve
determinar
o
comportamento
e a
posição
dos
Projeto de Interface -AI
•
Wireframe
deve
determinar
o
comportamento
e a
posição
dos
elementosnaspáginas.
•Wireframe refletea sensibilidadeeditorial do projet o.
•Wireframe deverefletira taxonomiafinal.
•Wireframe deveespecificaras etapasde interação.

10. Projeto de Interface -AI
Wireframes

11. Projeto de Interface -AI
Wireframes

12. Projeto de Interface -AI
Wireframes

13. Projeto de Interface -AI
Wireframes

14. Projeto de Interface -AI
Wireframes

15. Projeto de Interface -AI
Wireframes

16. Projeto de Interface -AI
http://www.axure.com/features

17. Análise •
Qual o perfil do usuário ?
–
Podem haver várias percepções do sistema ?
•
Quais as tarefas usadas para atingir as metas?
–
Identificar quais são;
Processo de desenvolvimento da interface
–
Identificar quais são;
–
Refiná-las;
–
Tarefas resultam em objetos (ícones, menus,
etc) e ações (como manipular/organizar estes
objetos).

18. Processo de desenvolvimento da interface
Projeto •
Que mecanismos de controle utilizar
–
Formas de alterar e perceber alterações do estado d o sistema;
–
Menus ? Formulários ? Comandos ?
•
Como será a ajuda ao usuário
–
Mensagens (construtivas, a culpa não é do usuário);
–
Sistema de ajuda on-line.

19. Prototipação
•
Visa provocar críticas/sugestões do usuário
•
Prototipação
•
Versão simplificada do sistema
•
Protótipo horizontal: Amplitude: Interface quase co mpleta mas com funcionalidade reduzida.
Processo de desenvolvimento da interface
com funcionalidade reduzida.
•
Protótipo vertical: Profundidade: Interface e Func ionalidade
completas de uma parte do sistema.

20. Avaliação •
Deve ser feita a cada ciclo;
•
Submetida aos usuários de diferentes perfis (caso exista m);
•
A cada novo ciclo os protótipos tendem a se aproximar d a versão final do sistema. Processo de desenvolvimento da interface versão final do sistema.

21. AVALIAÇÃO DAS INTERFACES •
O papel da avaliação é verificar se realmente o sistema
comporta-se como esperado e atende os requisitos dos
usuários.
•
Revisão de
Guidelines
: a interface é checada com os itens do
Processo de desenvolvimento da interface
•
Revisão de
Guidelines
: a interface é checada com os itens do
guidelinede desenvolvimento de interfaces;
•
Inspeção formal de usabilidade: os méritos e defeitos da
interface são discutidos com relação aos itens que
caracterizam a usabilidade das interfaces. (Shneiderman,
1998).

22. Processo de desenvolvimento da interface

23. Iniciando o projeto de interface
....
•
Conhecer o
usuário
(reuniões,pesquisa, entrevistas,
questionários...). Definir tarefas, necessidades .. . Ver o
contexto
•
Geração de Idéias (brainstorming, mindmaps)
•
Guias para Projeto de Interface
•
Guias para Projeto de Interface
•
Lay-outsde tela e
cenários
de usuários
•
Prototipação

24. Prototipação -Conceitos
•
É uma abordagem baseada numa visão evolutiva do
desenvolvimento de software, afetando o processo como um
todo. Esta abordagem envolve a produção de versões d e
protótipos (análogo a maquetes para a arquitetura) -de um
sistema futuro com o qual pode-se realizar verificações e
experimentações para se avaliar algumas de suas qualidade s
antes que o sistema venha realmente a ser construído. antes que o sistema venha realmente a ser construído.

25. Personas
É um personagem fictício, arquétipo hipotético de u m grupo de 
usuários reais, criada para descrever um usuário tí pico.
Elementos de uma persona
•Identidade
: nome, idade e outros dados demográficos
•Status
: primária, secundária ou outro stakeholder (p. ex. : 
antiusuário) antiusuário) •Objetivos
: com o sistema e fora dele
•Habilidades
: especialidade (educação, treinamento e 
competências)
•Tarefas
: quais? Frequência? Importância? Duração?
•Relacionamentos
: ajuda a identificar stakeholders
•Requisitos
: de que a persona precisa? 
•Expectativas
: como a persona organiza as informações? Como 
acredita que o sistema funciona?

26. Cenários
Descrevem o comportamento e as experiências dos atores, para 
atender a vários objetivos:
•Descrever uma história num domínio de atividade
•Capturar requisitos e auxiliar do entendimento da a tividade
•
Levantar questões sobre a introdução de tecnologia
•
Levantar questões sobre a introdução de tecnologia
•Explorar diferentes soluções de design
•Avaliar se um produto satisfaz a necessidade de seu s usuários
Elementos de um cenário: ambiente ou contexto; atores, objetivos, 
planejamento, ações, eventos, avaliação

27. Personas e Cenários
Luiz Fernando Sallum, 16 anos, Masculino,
Rio de Janeiro, Classe social B, Mora com os pais e avós,
estudante do Ensino Médio, dá aula de tênis no
condomínio onde mora.
Do alto dos seus 16 anos, o carioca Luiz Fernando Sallum é
um investidor do tipo “agressivo”. O estudante do E nsino Médio
acompanha de perto as notícias sobre o pregão há um ano e
comprou suas primeiras ações em janeiro. Juntou o dinheiro
ganho de aniversário dos pais e avós com o que conseguiu em ganho de aniversário dos pais e avós com o que conseguiu em
três meses dando aulas de tênis no condomínio e transformou tudo em quase um
lote de ações Vale. “No primeiro mês, meu lucro foi de 31%. Achei a Bolsa de
Valores um paraíso”, conta.
Sallum acompanha os gráficos de mais de 80 ações na tela do seu sistema de
Home Broker. A um movimento destoante, busca o motivo. Se a justificativa
convence e sugere mais alta, compra o papel que geralmente fica pouco na
carteira. O estudante gosta de negociar ações de empresas menores e mais
sujeitas à volatilidade. E já aprendeu que para evi tar perdas nesses casos, deve
entrar já de olho na saída. “Programo o stop loss(ordem de venda que limita o
prejuízo) logo abaixo do preço da compra”, ensina. “Pois quando vem um tubarão
vendendo, não tem para onde correr.”
Cenário construído para o
investbolsa.com.br

28. A
Tiposde Protótipos

29. Protótipo de Baixa Fidelidade
•
Fidelidade refere-se ao nível de detalhe.
•
é uma representação artística, um esboço, com
muitos detalhes omissos
•
Vantagem: não tomam muito tempo para seu
desenvolvimento e não requer equipamento
dispendioso. dispendioso.

30. Protótipos de Baixa Fidelidade
•
são
construídos
, na
maioria das vezes,
em
papel e podem ser
testados com
usuários reais
, assim,
permitem demonstrar permitem demonstrar o comportamento da
interface muito cedo
no desenvolvimento

31. Protótipos de baixa fidelidade
•
seu uso pode aumentar a qualidade das
interfaces, pois, permitem várias avaliações pelo
usuário em pouco tempo e o retorno imediato.

32. Protótipos de baixa fidelidade
•
com eles, os usuários são obrigados a pensar no
conteúdo em vez da aparência, uma vez que
somente são realizados esboços que servem
como protótipos

33. Protótipos Físicos de Baixa Fidelidade
•
Neste tipo de protótipo, as dimensões e o
aspecto são importantes, embora ainda possam
ser feitos com materiais simples como cartolina e
massa de modelar

34. Exemplo de Protótipo de baixa
fidelidade
•
Protótipos em papel:é desenvolvido um conjunto de
interfaces associadas a cenários de utilização que são
apresentados aos usuários.
•
Este tipo de prototipação é barata e eficiente (Rog ers, Sharp, Preece,
2002)(Kotonya, Sommerville 1998). •
É mais indicada quando o sistema a desenvolver é s oftware. Não é necessário desenvolver software executável. necessário desenvolver software executável.
•
Os analistas e usuários percorrem estes cenários, s imulando a
utilização do sistema, sendo analisado as reações d os utilizadores, a
informação requerida e a forma de interação com o s istema.
•
Este método é muito eficiente para sistemas interat ivos, sendo
considerado como protótipo de baixa fidelidade (Rog ers, Sharp, Preece,
2002).

36. Interface Humano Máquina

37. A
Protótipos de Alta Fidelidade

38. Protótipos de Alta Fidelidade
•
assemelham-se ao produto final, neles
os detalhes são
importantes, pois, simulam todas as funcionalidades do
sistema
.
Wearable computer - Eurotech

39. Protótipos de Alta Fidelidade
•
A apresentação
formal sugere
“produto acabado”,
pois além de
visualizar as
conexões, conexões, conseguimos
visualizar o design: o
arranjo gráfico, o uso
das cores, os tipos,
etc.
Soft-shell mobile phone –
http://www.nec-design.co.jp/showcase/

40. Protótipos de Alta Fidelidade
•
acarreta mais tempo
e dinheiro investido
em sua confecção do
que no protótipo de
baixa fidelidade
P-ISM :
Pen-style Personal Networking Gadget
Package
http://www.nec-design.co.jp/showcase/

41. Comparativamente temos:
Tipo
Protótipo
Fator +
positivo
Aplicação
no ciclo de
desenvolv.
Custo de
alterar a
aparência
Custo de
alterar a
seqüência
Baixa
Flexibilidade,
facilidade de
alterar
Início
Quase
Baixo
Baixa fidelidade
alterar seqüência,
comportament
o geral
Início
Quase
nenhum
Baixo
Alta
fidelidade
Fidelidade da
aparência
(Look & Feel)
Final Baixo Alto