You are currently browsing the category archive for the 'metodologia' category.
Devido a problemas técnicos (meu computador morreu e deve reencarnar só lá pro fim da semana que vem) somados ao tempo escasso e à habitual preguiça, ando sumido dessas bandas.
Pra não deixar esse espaço abandonado, vou colocar aqui um check-list que montei devido aos vários testes de usabilidade que me têm aparecido nesses últimos tempos.
Antes de testar uma interface junto a usuários reais, é preciso fazer uma análise heurística do site para saber que pontos devem ser abordados no teste.
Fiz o check-list abaixo em 15 minutos e sem grandes pretensões estéticas, uma vez que ele será usado internamente e servirá apenas de guia.
Certamente haverá mudanças, mas acho que já dá pra começar a brincar.
Check-list para elaboração de Análise Heurística
- Qual o perfil do público-alvo (idade, classe econômica, familiaridade com computadores e internet, interesses gerais e específicos)?
- O que se pode concluir a partir da análise das métricas disponíveis (page-views, unique-visitors, caminhos feitos no site, taxas de conversão, etc)?
- Faça um benchmark e identifique os erros e os acertos da concorrência.
- Olhando a home-page consigo saber do que se trata o site?
- Quais os plug-ins necessários para a visualização do site? No caso do site ser em flash, qual a versão utilizada?
- Quais as principais tarefas a serem realizadas no site? Sua realização é fácil e intuitiva? Há muitos passos para sua realização?
- Terminologia usada obedece aos padrões normalmente empregados?
- Terminologia é adequada ao público-alvo?
- Navegação (menus, sub-menus – vertical, horizontal) é intuitiva?
- A arquitetura de informação faz sentido? Deve ser horizontal ou vertical?
- Usuário consegue se localizar facilmente a partir de qualquer ponto do site?
- Os títulos das páginas estão alinhados com os títulos dos links e menus?
- Os títulos da janela estão escritos corretamente?
- O peso das páginas condiz com a finalidade do site/público-alvo?
- O código está bem escrito? (tableless, semântico, organizado…)
- Todos os links e botões parecem clicáveis?
- Há link para a home nas páginas internas? Além do link, logomarca nas páginas internas deve levar à home.
- O site é de fácil leitura? (tamanho das fontes, contrastes, blocos de texto, adequação do texto, extensão das linhas de texto – máx. 70 caracteres)
- Texto dos links é relevante? (evitar “veja mais”, “clique aqui”, etc)
- Todas as seções são relevantes para o público-alvo?
- Imagens possuem ALT TEXT?
- Checar codificação das páginas e meta tags.
- URL, nomes de diretórios e de arquivos são intuitivos?
- Oportunidades de crossed-links são bem aproveitadas?
- Etapas de processos (cadastros, compras…) são bem sinalizadas?
- No caso de sites em ASP/PHP/JSP, há muitos reloads? Dá pra usar AJAX?
- Há um mapa completo do site? Sempre que possível, incluir uma mapa (ainda que simplificado) em html no rodapé da home.
- A busca do site funciona bem? Está bem localizada? É fácil de usar?
- Todos os campos dos formulários são necessários? É possível reduzi-los?
- Em todas as páginas há uma forma de entrar em contato com empresa?
- Testar pelo menos em 3 browsers: IE, Firefox e Safari (Já que testou nos 3, testa no Opera também, vai…).
Tags: Sem tags desta vez
Wireframes são uma parte fundamental na construção de qualquer site. Eles dão ao designer a dimensão do site, a hierarquia de importância de seus elementos e dizem o que acontece em cada situação. Além disso, dão ao cliente uma boa noção de como ficará o site depois de pronto. Ou seja, além de auxiliar a designers e clientes, o wire resguarda a ambos.
Pois bem… há várias formas de se fazer um wireframe. Sem querer entrar no certo ou errado, vou falar do jeito de que mais gosto.
Um wireframe deve, além de apresentar as telas, dar uma boa idéia da interatividade e da experiência que o usuário terá ao usar o site. Por isso, gosto dos interativos em vez de slides ou PDFs. De preferência em HTML e sem tabelas (tableless), de forma que, uma vez aprovado, o designer possa trabalhar em cima do wire, mexendo apenas no CSS pra layoutar o site.
Juntamente com os arquivos HTML, gosto de ter a árvore do site à mão pra ver o todo e poder me situar. Essa árvore pode ser, simplesmente um TXT com indicações de todos os níveis de navegação.
Outra coisa que ajuda muito é usar conteúdo real ao invés do famoso Lorem Ipsum. Conteúdo fictício é conveniente na hora do lay-out porque cada coisa “cabe” exatamente onde o designer quer. Claro. Ele é quem está decidindo o tamanho de tudo. O problema é que quase sempre, na hora de produzir o site, são necessárias mudanças e adaptações.
Essa é apenas a forma como eu vejo a coisa, mas trabalhar assim, pelo menos pra mim, é bem simples e ajuda pacas.
Tags: Sem tags desta vez
Um storyboard é uma ótima forma de se planejar e aprovar um roteiro de filme. Até porque um filme é aquilo mesmo. Se você tem um bom diretor e recursos suficientes, dificilmente o resultado vai decepcionar.
Com web é diferente. Aprovar qualquer peça interativa olhando para um stoyboard é quase sempre bem arriscado. O problema é que, depois de pronta, a coisa pode ficar bem diferente daquilo que o cliente imaginou vendo a apresentação.
O ideal é sempre produzir a peça de verdade, para que o cliente viva a experiência de usá-la. Mas aí entra uma outra questão: vamos produzir as peças sem saber se o cliente irá aprová-las? E se ele não gostar, jogamos nosso tempo no lixo?
Difícil essa. Creio que pouquíssimas agências/produtoras têm, hoje em dia, recursos pra ficar produzido peças no risco a toda hora. É inviável. Mas em alguns casos vale a pena. É sempre questão de se avaliar a situação considerando a complexidade da peça, o nível de entendimento do cliente, a importância do projeto, o prazo e os recursos disponíveis.
No caso da inviabilidade de se produzir, o jeito é mandar o storyboard mesmo, mas mesmo aí, valem alguns cuidados:
- Produza o storyboard passo a passo, com a maior riqueza de detalhes possível.
- Escreva um texto descrevendo tudo o que acontece durante a interação entre o usuário e a peça.
- Antes de mostrar ao cliente, apresente a peça a um leigo e veja se ele tem diiculdades para entender algo.
- Não confie no texto. Ligue (ou, se puder, vá ao vivo) para o cliente e explique outra vez.
- Pergunte ao cliente se ele tem alguma dúvida.
- Reze.
Tags: Sem tags desta vez
