2. Processo de desenvolvimento da interface
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;
– Refiná-las;
– Tarefas resultam em objetos (ícones, menus,
etc) e ações (como manipular/organizar estes
objetos).
3. Processo de desenvolvimento da interface
Projeto
• Que mecanismos de controle utilizar
– Formas de alterar e perceber alterações do estado do 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.
4. Processo de desenvolvimento da interface
Prototipação
• Visa provocar críticas/sugestões do usuário
• Prototipação
• Versão simplificada do sistema
• Protótipo horizontal: Amplitude: Interface quase completa mas
com funcionalidade reduzida.
• Protótipo vertical: Profundidade: Interface e Funcionalidade
completas de uma parte do sistema.
5. Processo de desenvolvimento da interface
Avaliação
• Deve ser feita a cada ciclo;
• Submetida aos usuários de diferentes perfis (caso existam);
• A cada novo ciclo os protótipos tendem a se aproximar da
versão final do sistema.
6. Processo de desenvolvimento da interface
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
guideline de 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).
8. 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
• Lay-outs de tela e cenários
de usuários
• Prototipação
9. 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 de
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 qualidades
antes que o sistema venha realmente a ser construído.
10. Personas
É um personagem fictício, arquétipo hipotético de um 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)
•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?
11. 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 atividade
•Levantar questões sobre a introdução de tecnologia
•Explorar diferentes soluções de design
•Avaliar se um produto satisfaz a necessidade de seus usuários
Elementos de um cenário: ambiente ou contexto; atores, objetivos,
planejamento, ações, eventos, avaliação
12. 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 Ensino 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
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 evitar 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
14. 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.
15. 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
o comportamento da
interface muito cedo
no desenvolvimento
16. 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.
17. 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
18. 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
19. 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 (Rogers, Sharp, Preece,
2002)(Kotonya, Sommerville 1998).
• É mais indicada quando o sistema a desenvolver é software. Não é
necessário desenvolver software executável.
• Os analistas e usuários percorrem estes cenários, simulando a
utilização do sistema, sendo analisado as reações dos utilizadores, a
informação requerida e a forma de interação com o sistema.
• Este método é muito eficiente para sistemas interativos, sendo
considerado como protótipo de baixa fidelidade (Rogers, Sharp, Preece,
2002).
23. 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
24. Protótipos de Alta Fidelidade
• A apresentação
formal sugere
“produto acabado”,
pois além de
visualizar as
conexões,
conseguimos
visualizar o design: o
arranjo gráfico, o uso
das cores, os tipos,
Soft-shell mobile phone – etc.
http://www.nec-design.co.jp/showcase/
25. 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/
26. Comparativamente temos:
Aplicação Custo de Custo de
Tipo Fator +
no ciclo de alterar a alterar a
Protótipo positivo
desenvolv. aparência seqüência
Flexibilidade,
facilidade de
Baixa alterar Quase
Início Baixo
fidelidade seqüência, nenhum
comportament
o geral
Fidelidade da
Alta
aparência Final Baixo Alto
fidelidade
(Look & Feel)
28. Etapas do Projeto de Interface
• Identificação dos requisitos do usuário, das
tarefas e do ambiente
• Criação de diferentes cenários dos usuários
• Criação do lay-out de tela (a partir de
Protótipos) que ilustra o projeto gráfico,
colocação de ícones, definição de textos,
títulos, janelas, menus principais e
secundários
29. Projeto de Interface
• Para que uma interface proporcione
usabilidade é necessário fazer uma análise
criteriosa do usuário
• Características Humanas Relevantes no
projeto de uma interface:
–Percepção
–Memória
–Aprendizado
–Habilidade
–Diferenças Individuais
30. Uso de Guidelines para projeto de
interfaces
• Ergonomia
• Metáforas (uso de conhecimento prévio para
o entendimento de novas situações. Ex: sala
virtual para conversa)
• Mensagens de erro
• Feedback
• Ajuda
• Apresentação visual (lay-out, cores, fontes,
textos, ícones, animações...)
31. Regras de ouro no desenvolvimento de
interfaces Shneiderman (1998)
1. Busca de consistência
2. Permitir uso de atalhos para experientes
3. Oferecer feedback informativo
4. Organização dos diálogos de interação
5. Prover prevenção de erros e fácil tratamento
6. Prover fácil reversão das ações
7. Suportar controle local das ações
8. Reduzir a demanda por memorização
32. Regras de ouro no desenvolvimento
de interfaces
• Consistência: este item cobre aspectos relativos
desde terminologia empregada, passando por
seqüências de ações executadas em situações
semelhantes, até detalhes como cores, fontes e
menus;
• Atalhos para usuários experientes: a
disponibilização de teclas de atalho ou de outras
formas de acelerar o processo de interação é muito
importante para tornar o sistema mais produtivo a
usuários experientes;
33. Regras de ouro no desenvolvimento
de interfaces
• Feedback informativo: é essencial que o usuário
saiba o que está acontecendo com o sistema
para ter segurança sobre a execução das tarefas
requisitadas;
• Organização dos diálogos de interação: as
seqüências de ações para desempenhar uma
determinada tarefa devem ser organizadas em
grupos com início e fim bem definidos, a fim de
deixar claro ao usuário o que deve ser feito para
executar algo e quando uma tarefa está
concluída;
34. Regras de ouro no desenvolvimento
de interfaces
• Prevenção de erros de usuários: Todos os
esforços devem ser empenhados no sentido de
prevenir a maior quantidade de falhas possível.
• Reversibilidade de ações: Devem ser oferecidos
recursos para corrigir erros durante a execução
do sistema, como o comando de desfazer ações
anteriores. Prover boas mensagens de erros e
possuir recursos de ajuda on-line para facilitar a
busca de soluções em situações confusas são
expedientes que também facilitam bastante a
vida dos usuários;
35. Regras de ouro no desenvolvimento
de interfaces
• Controle do usuário sobre o sistema: sendo o usuário o
elemento racional da relação homem-computador, ele
deve se sentir com o controle da situação em que está
envolvido com o sistema;
• Redução da necessidade de memorização: o usuário
deve precisar memorizar o mínimo de informações
possível sobre a interação com o sistema. Para tanto, na
medida do possível, comandos devem ser substituídos
por opções de menu, números de objetos por nomes,
dentre outros, além de ser essencial o acesso do usuário
à documentação do sistema para esclarecer eventuais
dúvidas.
36. Projeto de Interface
• Que informação colocar numa tela?
• Fornecer somente informações
essenciais à tomada de decisão ou
execução de uma ação
• Fornecer todos os dados relacionados a
uma tarefa em uma única tela (se
possível). Não se deve ter que lembrar
de um dados da tela anterior.
37. Projeto de Interface
Características de uma boa tela
– Aparência limpa e ordenada;
– Indicação óbvia dos dados que estão sendo mostrados e o que deve ser feito
com eles;
– Informação esteja onde se espera que esteja;
– Indicação clara do que se relaciona com o que (cabeçalhos, instruções,
opções, etc);
– Vocabulário simples e explícito;
– Modo simples de encontrar o que está no sistema e como obtê-lo;
– Indicação de quando uma ação poderia realizar mudanças permanentes nos
dados ou no sistema.
38. Projeto de Telas
• Como colocar informações na tela
– Apresentar a informação de forma utilizável
diretamente, sem pedir consultas a documentos,
manuais, etc;
– Usar técnicas de destaque de vídeo (negrito, sublinhado,
outra cor, etc) para chamar a atenção de
• ítens urgentes;
• diferentes componentes da tela
• Itens a serem manipulados
– Telas não têm pauta, logo, às vezes é preciso guiar o
olhar do usuário através de linhas, tracejados,
pontilhados ou outra técnica;
– A aparência e os procedimentos devem ser coerentes.
39. Características de um bom diálogo
(comunicação/ interação)
• Fácil de aprender
• Fácil de usar
• Fácil de adaptar e modificar
• Capacidade de detectar erros
• Eficiente
• Consistente
40. Metas de Projetos de Interfaces
• Redução da carga de trabalho visual
• Redução da carga de trabalho intelectual
• Redução da carga de trabalho motora
• Redução da carga de trabalho mental
• Minimização ou eliminação de quaisquer encargos ou
instruções impostas por aspectos tecnológicos
• Elevação da produtividade
• Aumento do grau de satisfação
41. Erros mais comuns em Projetos
• Legendas confusas e questões mal formuladas
• Ênfase inadequada de tipos e gráficos
• Cabeçalhos desorientadores
• Solicitações de informações irrelevantes ou
desnecessárias
• Solicitações de informações que impliquem o retrospecto
de respostas e/ou contextos
• Distribuição restrita e/ou desordenada das componentes
na tela
• Deficiência em nível da qualidade da apresentação,
legibilidade, aparência e disposição da informação
42. Erros mais comuns em Projetos
• Inconsistência visual na apresentação dos
detalhes na tela
• Necessidade de restrição no uso de
características e elementos de projeto
• Sobrecarga de apresentações 3D
• Sobrecarga de cores muito brilhantes
• Uso de ícones mal projetados
• Deficiência tipográfica
43. Princípios Básicos para Projeto de
interface
• Proximidade (organização das informações por proximidade,
isto é os elementos logicamente conectados também serão
organizados visualmente)
• Alinhamento (não colocar os elementos de forma arbitrária
em uma tela, organizá-las)
• Contraste (diferenciar claramente o conjunto de elementos
gráficos)
• Repetição (de elementos do design)