O documento discute princípios e diretrizes para o design de interfaces, incluindo: (1) projetar a interface antes da programação; (2) começar pelo conteúdo central e construir para fora; (3) considerar estados regulares, vazios e de erro.
Ataque Ninja, produtividade com times pequenos, ageis e eficientes
Design de interface: princípios e técnicas
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
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.
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
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