Avaliação de usabilidade e métodos

ALAN VASCONCELOS

DESIGN DE INTERAÇÃO
/ USABILIDADE
Processos /
User Stories

RECORDAR É VIVER!

Quando?
As avaliações podem ser aplicadas em diversos momentos do ciclo de vida de um produto.

Avaliações formativas
(ocorrem em cada ciclo de sprint)

Avaliações somativas
(ocorrem no final do ciclo, ou mesmo depois)

RECORDAR É VIVER!

Como?
No que diz respeito à aplicação, os métodos de avaliação de usabilidade podem ser
empíricos ou analíticos

Empíricos:

• Requer a participação de usuários durante a coleta de dados,
que, posteriormente, serão analisados pelo especialista, a fim
de identificar os problemas da interface.
• É realizado em ambientes controlados, no qual os avaliadores
gravam toda a interação em vídeo para posterior análise.
Durante a realização do teste, um dos avaliadores vai
anotando os incidentes ocorridos durante a interação, além
dos comentários do usuário em relação à interface.
• Logo após o teste, os usuários respondem a um questionário
com perguntas relacionadas à satisfação em relação ao
produto e, também, perguntas com sugestões de melhorias.

RECORDAR É VIVER!

Como?
No que diz respeito à aplicação, os métodos de avaliação de usabilidade podem ser
empíricos ou analíticos

Analíticos:

• Também conhecidos como métodos de inspeção, ou de prognóstico,
caracterizam-se pelo fato do usuário não participar diretamente das avaliações.
• Requer a presença de um especialista, que explorará a interface, a fim de encontrar
problemas de usabilidade.
• Além da identificação dos problemas, os avaliadores fazem sugestões de correção.
• Tem como resultado um relatório formal dos problemas identificados
e as sugestões de melhorias.

RECORDAR É VIVER!

Jakob Nielsen (1993), em seu livro Usability engineering, propõe um conjunto de dez
heurísticas de usabilidade:

1. visibilidade e reconhecimento do estado ou contexto atual do sistema;
2. compatibilidade com o mundo real;
3. controle e liberdade do usuário;
4. consistência e padrões;
5. prevenção de erros;
6. reconhecimento ao invés de memorização;
7. flexibilidade e eficiência de uso;
8. projeto estético minimalista;
9. diagnóstico e correção de erros; e
10. ajuda e documentação.

As heurísticas, neste caso, são um conjunto de regras e métodos
que levam à descoberta e à resolução* de problemas (NIELSEN, 1993).

*Leva à resolução, mas não aplica/implementa a resolução dos problemas encontrados.

USER STORIES
Uma história...
Uma estória não é mais do que a descrição de uma pequena
funcionalidade que o cliente pretende ver desenvolvida no
sistema.

O termo em inglês é story (história – conto) e não history
(história - relato de fatos);

USER STORIES
O que são:
• Uma breve descrição de uma funcionalidade que foi
discutida;
• São tradicionalmente escritas em cartões ou post-its;

O que não são:
• Documentos de implementação (classes, modelagem...);
• Imutáveis: Podem sofrer alterações e negociações ao
longo do projeto;
• Casos de uso: Este último se refere à narrativa de
funções de forma impessoal, ou seja, independente do
usuário.

USER STORIES
Características
• User Stories focam nos objetivos do usuário e como o sistema alcança
esses objetivos.

• User Stories fracionam os requisitos para que seja possível (e mais
fácil) estimar o esforço para realizar aquele objetivo. Resumindo, User
Stories são descrições simples que descrevem uma funcionalidade e é
recomendável que sejam escritas segundo o ponto de vista do
usuário.

• User Stories devem ser curtas, simples e claras. Devemos conseguir
escrevê-las em um simples e pequeno cartão (conhecidos como User
Index Cards). Se não há espaço para escrevê-la em um cartão é
porquê devemos refiná-la mais, e as dividir em outras User Stories.

• Stakeholders escrevem User Stories, não os desenvolvedores. User
Stories são simples o suficiente para que as pessoas possam aprender
a escrevê-las em alguns minutos.

© Jeff Patton, all rights reserved, www.AgileProductDesign.com

USER STORIES

User Stories Aqui

USER STORIES
Formato
• Os cartões seguem um formato como o descrito abaixo:


USER STORIES
Formato

• Ator – O proprietário da User Story. De forma
simplista é o usuário, o interessado naquela
funcionalidade. Mas é recomendado descrever
de forma específica quem é o ator para ser mais
fácil identificar o contexto da história dentro do
sistema.

• Ação – É o que o ator quer fazer. Utilizando
aquela ação ele espera alcançar seu objetivo
dentro do sistema.

• Objetivo/Funcionalidade – É o que o ator
espera que aconteça ao realizar a ação. Ou seja,
é o resultado de executar a ação segundo a ótica
do ator. Também pode ser visto como
justificativa.


USER STORIES
Escrevendo boas histórias

Independentes: Histórias devem ser independentes uma das outras;
(exemplo: usuário pode entrar com o nome do meio, primeiro nome e último nome.)

Negociáveis: Histórias não são contratos, mas lembretes para discussões;
(por questões de escopo, orçamento ou complexidade, as histórias podem ser removidas ou alteradas.)

De valor agregado: Histórias devem agregar valor para o usuário/cliente;
(exemplo: dizer que o sistema será feito em PHP e MySQL não é relevante para o usuário/cliente).


USER STORIES
Escrevendo boas histórias

Estimáveis: Os desenvolvedores devem ser capazes de estimar o tamanhos das história;
(se não puder ser estimada, não será usada no sprint. Se for muito complexa, dividir em histórias
menores.)

Curtas: histórias grandes dificultam as estimativas. Bem como histórias muito pequenas.
Quebre ou agrupe dependendo do caso.
(Grandes histórias (épicas) são difíceis de estimar e difíceis de planejar, elas não se encaixam bem em
uma única iteração)

Testáveis: Histórias devem ser possíveis de serem testadas.
(Em vez de: “Não fazer o usuário esperar muito em cada tela”,
use: “As telas não deverão demorar mais que 2 segundos para abrir”.)


USER STORIES
Processo: cada cartão uma história

1. Em cada cartão, listar todas as AÇÕES factíveis do usuário no
produto
Comece sempre com um verbo. Este será o “título” da história.

2. Escreva a história.
Seguindo os critérios mostrados anteriormente. Ex.: Eu como
JARDINEIRO preciso CAVAR UM BURACO para que eu possa PLANTAR
UMA SEMENTE. (Deixe espaço para mais detalhes)

3. Atribua um valor de negócio (ROI) para cada cartão
Pode ser: BAIXO, MÉDIO ou ALTO


USER STORIES
Processo: o mapa

1- Organize os cartões horizontalmente em uma sequência lógica de operação

tempo


USER STORIES
Processo: o mapa

2- Empilhe os cartões que possuem atividades simultâneas

tempo


USER STORIES
Processo: o mapa
3- Ordene verticalmente os cartões em ordem de importância ou criticidade
(frequência de uso, ROI, valor do negócio, etc...)

Tempo
importância


USER STORIES
Processo: o mapa
4- Observe os agrupamentos que se formam e discuta com a equipe.
Um conjunto de tarefas, forma uma atividade

Tempo
importância


USER STORIES
Processo: o primeiro release
4- Discuta e escolha uma das atividades que será implementada primeiro.
Peça para a equipe de desenvolvimento estimar a implementação de cada cartão.
Essa é uma decisão estratégica!

tempo
necessário
Primeiro release

opcional Segundo release
importância

mais Terceiro release
opcional


VALEU!

ALAN VASCONCELOS – www.alanvasconcelos.com

Avaliação de usabilidade e métodos

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Avaliação de usabilidade e métodos

Similaire à Avaliação de usabilidade e métodos (20)

Plus de Alan Vasconcelos

Plus de Alan Vasconcelos (20)

Avaliação de usabilidade e métodos