-
Neste vídeo vamos introduzir uma técnica chamada Avaliação Heurística.
-
Como falamos no início do curso, há muitas maneiras diferentes para avaliar software.
-
Um que você pode estar mais familiarizado é o métodos empírico,
-
onde, de algum nível de formalidade, você tem pessoas reais testando o seu software.
-
Também é possível ter métodos formais, onde você está construindo um modelo
-
de como as pessoas se comportam em uma situação particular,
-
e que permite prever como as diferentes interfaces de usuário vão funcionar.
-
Ou, se você não pode construir um modelo de forma fechada formal,
-
você também pode experimentar a sua interface com simulação e ter testes automatizados -
-
que pode detectar erros de usabilidade e projetos eficazes.
-
Isto funciona especialmente bem para baixo nível de material, é mais difícil de fazer para nível superior coisas.
-
E o que vamos falar hoje é a crítica baseada na abordagens,
-
onde as pessoas estão lhe dando feedback diretamente, com base em sua experiência ou um conjunto de heurísticas.
-
Como qualquer um de vocês que já pegou uma arte ou aula de design sabe,
-
a crítica em pares pode ser uma forma extremamente eficaz de feedback,
-
e ele pode fazer você fazer seus projetos ainda melhor.
-
Você pode começar realmente a crítica em pares em qualquer fase do seu processo de design,
-
mas eu gostaria de destacar um casal que eu acho que pode ser particularmente valioso.
-
Primeiro, é realmente valiosa para obter a crítica em pares antes de testes de usuários,
-
porque isso ajuda a não desperdiçar os seus usuários em coisas que só vai ter pego automaticamente.
-
Você quer ser capaz de concentrar os recursos valiosos de testes com usuários
-
em coisas que outras pessoas não seriam capazes de pegar.
-
O feedback rico qualitativa que a crítica em pares fornece
-
também pode ser muito valioso antes de redesenhar sua aplicação,
-
porque o que ele pode fazer é que pode mostrar-lhe que partes do seu aplicativo que você provavelmente vai querer manter,
-
e quais são as outras partes que são mais problemáticos e merecem redesign.
-
Em terceiro lugar, às vezes, você sabe que há problemas,
-
e você precisa de dados para ser capaz de convencer outras partes interessadas para fazer as mudanças.
-
E a crítica em pares pode ser uma ótima maneira, especialmente se ela é estruturada,
-
ser capaz de obter o feedback que você precisa, para fazer as mudanças que você sabe que precisa acontecer.
-
E, finalmente, esse tipo de crítica em pares estruturada pode ser muito valioso antes de liberar software,
-
porque lhe ajuda a fazer um polimento final de todo o projeto, e suavizar as arestas.
-
Como a maioria dos tipos de avaliação, geralmente é útil começar com um objetivo claro,
-
mesmo se o que você finalmente aprender é completamente inesperado.
-
E assim, o que vamos falar hoje é uma técnica especial chamada avaliação heurística.
-
Avaliação Heurística foi criado por Jakob Nielsen e seus colegas, cerca de vinte anos atrás.
-
E o objetivo da avaliação heurística é ser capaz de encontrar problemas de usabilidade no design.
-
Eu aprendi sobre avaliação heurística
-
quando eu TA'd James Landay's Intro para curso HCI, e eu fui usá-lo e ensiná-lo desde então.
-
É uma técnica muito valiosa porque permite obter um feedback muito rápido
-
e é uma alta estratégia de bang-for-the-buck.
-
E os slides que eu tenho aqui são baseados nos slides de James para este curso,
-
e os materiais estão disponíveis no site Jacob Nielsen.
-
A idéia básica da avaliação heurística é que você está indo para fornecer um conjunto de pessoas -
-
muitas vezes, outras partes interessadas na equipe de projeto ou especialistas em design de fora -
-
com um conjunto de heurística ou princípios,
-
e eles vão usar aqueles para olhar para os problemas em seu projeto.
-
Cada um deles é o primeiro a fazer isso de forma independente
-
e assim eles vão passar por uma variedade de tarefas usando o design para olhar para estes bugs.
-
E você vai ver que diferentes avaliadores vão encontrar problemas diferentes.
-
E então eles vão se comunicar e conversar apenas no final, depois.
-
Ao final do processo, eles vão voltar a ficar juntos e conversar sobre o que encontraram.
-
E este "independente em primeiro lugar, reunir depois"
-
é como você começa a "sabedoria das multidões" vantagem em ter vários avaliadores.
-
E uma das razões que nós estamos falando sobre isso no início da aula
-
é que é uma técnica que você pode usar, ou em uma interface de usuário ou trabalhando em esboços de interfaces de usuário.
-
E avaliação, de modo heurística funciona muito bem em conjunto com protótipos de papel
-
e outras rápidas, técnicas de baixa fidelidade que você pode estar usando para conseguir suas idéias de design sair rápido e rápido.
-
Aqui estão dez heurísticas de Nielsen, e eles são um conjunto muito bom.
-
Dito isto, não há nada mágico sobre estas heurísticas.
-
Eles fazem um bom trabalho de cobertura de muitos dos problemas que você vê em muitas interfaces de usuário;
-
mas você pode adicionar em qualquer um que você quiser
-
e se livrar de qualquer um que não são apropriadas para seu sistema.
-
Nós estamos iremos para o conteúdo dessas dez heurísticas nas próximas duas palestras,
-
e nesta palestra que eu gostaria de apresentar o processo que você vai usar com estas heurísticas.
-
Então aqui está o que você vai ter seus avaliadores fazerem:
-
Dê-lhes um par de tarefas para usar o seu projeto,
-
e tê-los fazer cada tarefa, percorrendo várias vezes com cuidado.
-
Quando eles estão fazendo isso, eles vão manter a lista de princípios de usabilidade
-
como um lembrete de coisas para prestar atenção.
-
Agora que os princípios que você vai usar?
-
Eu acho que dez heurísticas de Nielsen é um começo fantástico,
-
e você pode aumentar aqueles com qualquer outra coisa que é relevante para o seu domínio.
-
Então, se você tiver objetivos do projeto em particular que você gostaria que seu projeto de alcançar, incluir aqueles na lista.
-
Ou, se você tem objetivos específicos que você configurou
-
a partir de análise da concorrência de projetos que já estão lá fora,
-
isso é ótimo também.
-
Ou, se há coisas que você já viu o seu ou outros projetos se destacam menos,
-
aqueles que são metas importantes e também pode ser incluído na sua lista de heurísticas.
-
E então, obviamente, a parte mais importante é que você vai pegar o que você aprendeu com esses avaliadores
-
e utilizar essas violações de heurísticas como uma forma de corrigir problemas e remodelação.
-
Vamos falar um pouco mais sobre por que você pode querer ter avaliadores múltiplos, em vez de apenas um.
-
O gráfico neste slide é uma adaptação da obra de Jacob Nielsen sobre avaliação heurística
-
e o que você vê é que cada quadrado preto é um bug que um avaliador particular encontrada.
-
Um avaliador individual representa uma linha desta matriz
-
e há cerca de vinte avaliadores neste conjunto.
-
As colunas representam os problemas.
-
E o que você pode ver é que há alguns problemas que foram encontrados pelos avaliadores relativamente poucos
-
e outras coisas que quase todo mundo encontrou.
-
Então, vamos chamar as coisas na direita de problemas fáceis e as coisas da esquerda de problemas difíceis.
-
E assim, no total, o que podemos dizer é que nenhum avaliador concluiu todos os problemas,
-
e alguns avaliadores consideraram mais do que outros, e assim há pessoas melhores e piores para fazer isso.
-
Então, porque não ter muitos avaliadores?
-
Bem, como você adicionar mais avaliadores, eles encontram mais problemas;
-
mas esse tipo de velas ao longo do tempo - você perde esse benefício eventualmente.
-
E assim a partir de uma perspectiva de custo-benefício é apenas deixar de fazer sentido depois de um certo ponto.
-
Então, onde está o pico da curva?
-
É, naturalmente vai depender de a interface de usuário que você está trabalhando,
-
quanto você está pagando as pessoas, quanto tempo está envolvido - todos os tipos de fatores.
-
A regra de ouro de Jakob Nielsen para estes tipos de interfaces de usuário e avaliação heurística
-
é que de três a cinco pessoas tende a funcionar muito bem, e que tem sido a minha experiência também.
-
E eu acho que definitivamente uma das razões que as pessoas utilizam a avaliação heurística
-
é porque pode ser uma maneira extremamente econômico encontrar problemas.
-
Em um estudo que Jacob Nielsen correu,
-
ele estimou que o custo dos problemas encontrados com a avaliação heurística foram 500.000 dólares
-
e o custo de realizá-lo foi um pouco mais de US $ 10.000,
-
e assim ele estima um 48 vezes relação custo-benefício para essa interface de usuário particular.
-
Obviamente, estes números são parte de trás do envelope, e sua milhagem pode variar.
-
Você pode pensar sobre como estimar o benefício que você recebe de algo parecido com isto
-
se você tiver uma ferramenta de software in-house usando algo parecido com aumentos de produtividade -
-
que, se você estiver fazendo um sistema de relatórios de despesas
-
ou outro sistema interno que fará com que o tempo das pessoas de forma mais eficiente usada -
-
isso é uma vitória grande usabilidade.
-
E se você tem o software que você está disponibilizando no mercado aberto,
-
você pode pensar sobre o benefício de vendas ou outras medidas como essa.
-
Uma coisa que podemos obter a partir desse gráfico é que os avaliadores têm maior probabilidade de encontrar problemas graves
-
e que é uma boa notícia;
-
e assim, com um número relativamente pequeno de pessoas,
-
você está muito provávelmente a tropeçar em coisas mais importantes.
-
No entanto, como vimos com apenas uma pessoa, neste caso particular,
-
mesmo o melhor avaliador encontrou apenas cerca de um terço dos problemas do sistema.
-
E é por isso que agrupando-se um número de avaliadores, digamos cinco,
-
vai levá-lo a maior parte do benefício que você será capaz de alcançar.
-
Se compararmos avaliação heurística e testes com usuários, uma das coisas que vemos ver
-
é que a avaliação heurística muitas vezes pode ser muito mais rápido - Leva apenas uma ou duas horas para um avaliador -
-
e os mecanismos de obtenção de um teste de usuário em funcionamento podem levar mais tempo,
-
nem mesmo representando o fato de que você pode ter que construir software.
-
Além disso, os resultados da avaliação heurísticos vem pré-interpretado
-
porque os avaliadores estão diretamente proporcionando-lhe problemas e coisas para corrigir,
-
e assim você economiza o tempo de ter que inferir a partir dos testes de usabilidade que podem ser o problema ou solução.
-
Agora por outro lado, especialistas caminhando através de seu sistema
-
pode gerar falsos positivos que não iria realmente acontecer em um ambiente real.
-
E isso de fato acontecer, e assim por testes de usuários é, de alguma forma, por definição, será mais exato.
-
No final do dia eu acho que é valioso para métodos alternativos:
-
Todas as técnicas diferentes que você aprenderá neste curso para receber feedback pode cada um ser valiosa,
-
e que [por] ciclismo através deles muitas vezes você pode obter os benefícios de cada um.
-
E isso pode ser porque com a avaliação do usuário e testes de usuários, você vai encontrar diversos problemas,
-
e executando HE ou algo parecido no início do processo do projeto,
-
você vai evitar o desperdício de usuários reais que você pode trazer mais tarde.
-
Portanto, agora que já vimos os benefícios, quais são os passos?
-
A primeira coisa a fazer é obter todos os seus avaliadores rapidamente,
-
sobre qual é a história por trás de seu software - qualquer conhecimento de domínio necessário que seja preciso -
-
e dizer-lhes sobre o cenário que você vai tê-los avançar.
-
Então, obviamente, você tem a fase de avaliação onde as pessoas estão trabalhando por meio da interface.
-
Depois, cada pessoa vai atribuir uma classificação de gravidade,
-
e você faz isso individualmente em primeiro lugar,
-
e então você vai agregá-los em uma classificação de gravidade do grupo
-
e produzir um relatório global a partir desse.
-
E, finalmente, uma vez que tenho este relatório global, você pode compartilhar isso com a equipe de design,
-
e a equipe de design pode discutir o que fazer com isso.
-
Fazer esse tipo de análise especializada pode ser muito cansativo,
-
e assim para cada um dos cenários que você colocar no seu design,
-
ele pode ser de grande valia para o avaliador percorrer esse cenário duas vezes.
-
A primeira vez, eles vão apenas ter uma noção de que, e pela segunda vez, eles podem se concentrar em elementos mais específicos.
-
Se você tem algum sistema de walk-up-and-use, como uma máquina de bilhete em algum lugar,
-
então você pode querer não dar às pessoas alguma informação de fundo a todas,
-
porque se você tem as pessoas que estão apenas começando para fora do ônibus ou do trem,
-
e eles caminham até a sua máquina sem qualquer informação prévia,
-
essa é a experiência que você quer que seus avaliadores tenham.
-
Por outro lado, se você vai ter um sistema de genômica ou outra interface de usuário especialista,
-
você vai querer ter certeza de que qualquer treinamento que você daria para os usuários reais,
-
você vai dar a seus avaliadores também.
-
Em outras palavras, qualquer que seja o fundo é, deve ser realista.
-
Quando os avaliadores estão caminhando através de sua interface,
-
isso vai ser importante para produzir uma lista de problemas muito específicos
-
e explicar os problemas no que diz respeito a uma das heurísticas de design.
-
Você não quer que as pessoas apenas para ser, tipo, "Eu não gosto disso."
-
E para maxilinearly anunciar-lhe estes resultados para a equipe de projeto;
-
você irá querer listar cada um destes separadamente, de modo que eles podem ser tratadas com eficiência.
-
Listas separadas também pode ajudá-lo a evitar listar o mesmo problema repetida uma e outra vez.
-
Se há um elemento repetido em cada única tela, você não quer listá-lo em cada tela;
-
você deseja listar uma vez de modo que possa ser fixada uma vez.
-
E estes problemas podem ser muito detalhados, como "o nome de alguma coisa é confusa,"
-
ou podem ser algo que tem de fazer mais com o fluxo da interface do utilizador,
-
ou a arquitetura da experiência do usuário e que não está especificamente ligada a um elemento da interface.
-
Seus avaliadores também podem achar que algo está faltando que deveria estar lá,
-
e isso pode ser algumas vezes ambígua com os primeiros protótipos, como protótipos de papel.
-
E assim você vai querer esclarecer se a interface do usuário é algo que você acredita ser completa,
-
ou se existem elementos intencionais falta antes do tempo.
-
E, claro, às vezes há funcionalidades que vão ser obviamente não existe
-
que estão implícitas na interface do usuário.
-
E assim, fora maduro, e relaxar sobre as pessoas.
-
Depois que seus avaliadores passaram a interface,
-
eles podem cada um independentemente atribuir uma classificação de gravidade para todos os problemas que eles encontraram.
-
E isso vai permitir que você alocar recursos para corrigir esses problemas.
-
Ela também pode ajudar a dar feedback sobre o quão bem você está fazendo
-
em termos de a usabilidade do seu sistema em geral,
-
e dar-lhe uma espécie de referência de seus esforços nesse sentido.
-
A medida de gravidade que seu avaliadores vão apresentar vai combinar várias coisas:
-
Vai combinar a freqüência, o impacto,
-
e a difusão do problema que eles estão vendo na tela.
-
Então, algo que só está em um lugar pode ser uma coisa menor
-
do que algo que aparece em toda a interface inteira.
-
Da mesma forma, não vão ser algumas coisas como texto desalinhado,
-
que pode ser deselegante, mas não são um assassino do negócio em termos de seu software.
-
E aqui é o sistema de classificação de gravidade que Nielsen criou, você pode, obviamente, usar qualquer coisa que você deseja:
-
Ele varia de zero a quatro,
-
onde zero é "no final do dia o seu avaliador decide que na verdade não é problema de usabilidade",
-
todo o caminho até ao fato de ser algo realmente catastrófico que tem que ser consertado imediatamente.
-
E aqui é um exemplo de um problema particular
-
que o nosso TA Robby encontrado quando ele estava tomando CS147 como um estudante.
-
Ele caminhou através da interface móvel de alguém que teve um "peso" elemento de entrada para ele;
-
e ele percebeu que uma vez que você entrou em seu peso, não há nenhuma maneira para editá-la após o fato.
-
Então, esse é o tipo de desajeitado, você gostaria de poder consertá-lo - talvez não um desastre.
-
E então o que você vê aqui é que ele listou o problema, ele deu-lhe uma classificação de gravidade,
-
ele tem a heurística que viola, em seguida, ele descreve exatamente o que é o problema.
-
E, finalmente, após todos os seus avaliadores passaram a interface,
-
listados seus problemas, e combinaram em termos de gravidade e importância,
-
você vai querer interrogar com a equipe de design.
-
Esta é uma boa oportunidade de poder discutir questões gerais na interface do usuário e feedback qualitativo,
-
e dá-lhe a oportunidade de passar por cada um desses itens
-
e sugerir melhorias sobre como você pode resolver esses problemas.
-
Nesta sessão debrief, pode ser valiosa para a equipe de desenvolvimento
-
para estimar a quantidade de esforço que seria necessário para resolver um destes problemas.
-
Assim, por exemplo, se você tem algo que é um em sua escala de gravidade e não um negócio muito grande -
-
que poderia ter algo a ver com a redação e da sua sujeira simples de resolver -
-
que lhe diz "vá em frente e corrija isso."
-
Por outro lado, você pode ter algo que é uma catástrofe
-
que leva muito mais esforço, mas a sua importância vai levar você a consertá-lo.
-
E há outras coisas em que a importância relativa para o custo envolvido
-
simplesmente não faz sentido tratar agora.
-
E esta sessão debrief pode ser uma ótima maneira de trocar idéias de design futuros,
-
especialmente quando você tem todos os interessados na sala,
-
e as idéias sobre quais são os problemas com a interface do usuário estão frescas em suas mentes.
-
Nos próximos dois vídeos vamos passar por dez heurística de Neilsons e falar mais sobre o que eles significam.
