Sistemas Multimédia I. Paulo Duarte

Sistemas Multimédia I

User Experience

Bom UX

• Útil (ajuda o utilizador a atingir o que precisa de fazer)

• De fácil aprendizagem (é fácil de perceber como se utiliza) • _{Acessível (pode ser acedido nos dispositivos e nas alturas em}

que é necessário)

• _{Visualmente interessante (é agradável de olhar e de interagir} e faz o utilizador sentir-se melhor do que antes de utilizar o produto)

• Conetado (poderá fazer o utilizador sentir-se mais ligado ao produto ou à entidade com que está a interagir)

• Satisfatório (em suma a experiência de utilização deverá ser satisfatória)

Mau UX

• Stressante (por exemplo não saber como utilizar o produto) • Confuso (não encontrar o que se pretende ou não conseguir

perceber o caminho para algo que se quer fazer)

• _{Feio (até pode funcionar mas é desagradável do ponto de} vista estético)

• _{Distrator (pode ter demasiadas funcionalidades,}

eventualmente inúteis, que afastam do objetivo com que se utiliza o produto)

• Ineficiente (demorar muito tempo a realizar uma ação)

• Desajustado (pode não permitir que se faça algo da forma que se quer fazer)

• Frustrante (em suma uma má experiência de utilização é frustrante e deixa o utilizador frustrado pela sua utilização).

Princípios de UX

O que os

utilizadores

querem

fazer

O que nós

queremos

que os

utilizadores

façam

Princípios de UX

Princípios do UX

Esta última máxima vai um pouco mais ao encontro do que é uma boa prática de UX.

Não devemos fazer exatamente aquilo que as pessoas querem mas sim o que elas necessitam. Muitas vezes as pessoas não sabem o que necessitam, apenas pensam que sabem o que querem.

Ex: uma criança pede gelados aos pais e estes insistem em dar uma refeição saudável, porque é isso que a criança necessita (Sueoka, M., 2016).

Sucesso

Em suma devemos então desenvolver não o que as pessoas querem mas sim o que elas necessitam e para tal temos de estudar as suas necessidades e os seus hábitos de consumo e conhecer bem o problema.

Deste modo atinge-se o sucesso do User Experience, que basicamente procura alcançar 3 resultados:

• Atingir os objetivos do produto; • Repetir a utilização/consumo; • _{Recomendar a terceiros.}

Exemplos

Exemplos

O que é User Experience?

É a experiência que se tem com a utilização de determinado produto e engloba vários aspetos como:

• Utilizar o produto

• Escolher o produto (escolher aquele de entre outros similares)

• _{A aquisição do produto (desde a fase da escolha à fase do} consumo)

• Aprender a utilizar o produto (saber utilizá-lo)

• Resolução de problemas (o processo de resolver falhas, avarias, etc do produto, onde e como isso é feito).

• _{Atualização do produto (ou utilização da nova versão do} produto).

Porque é tão difícil? Como torná-lo mais fácil.

Porque é difícil?

• O developer/designer não é o utilizador

• _{Os sistemas utilizados são complexos e em constante} atualização (nomeadamente os computadores e os softwares utilizados)

Como torná-lo mais fácil

• Seguindo um processo de design (prototipagem) iterativo • Aplicar investigação centrada no utilizador e métodos de

design

Design iterativo

Avaliar

Desenhar

Construir

Investigação UX (centrada no utilizador)

• Entrevistas • Questionários

• _{Observação (direta por parte do investigador)} • Captura de ecrã/filmagens (Observação indireta) • _{Testes de usabilidade}

• Métodos de inspeção de usabilidade (e.g. avaliação heurística)

Design UX

• Personas e histórias de utilização (definir perfis de utilizadores que irão utilizar o produto)

• Desenhar e idear (criar múltiplas hipóteses e ideias de modo a termos mais opção de escolha quando selecionarmos a

pretendida)

• Storyboards (Desenhar um guião imagético de como a

interação como a aplicação será feita e como irá funcionar cada parte do sistema)

• Desenho do mapa da aplicação (todas as funcionalidades e como interagem entre si)

• Investigação comparativa (atentar à concorrência) • _Prototipagem

Comportamento humano

Perceber como as pessoas visualizam os conteúdos (a forma como percecionam os estímulos visuais, como retiram e

retêm a informação).

Perceber como se comportam (como interagem com os

dispositivos, como reagem quando têm ou não sucesso, como seguem diferentes caminhos).

Perceber como funcionam as emoções e os desejos humanos (De que modo os sentimentos de uma pessoa influenciam a forma como consome conteúdos, de que forma as emoções influenciam as escolhas que faz).

Elementos de UX

Valor

É útil? Responde às necessidades?

Usabilidade

Consegue-se fazer o que é pretendido?

Adotabilidade

O utilizador irá adotar à partida o produto?

Desejabilidade

É divertido/agradável?

Como avaliar o UX

Numa primeira fase da avaliação e como vimos importa perceber o que é pretendido para a aplicação/produto e, portanto, perceber o utilizador, numa segunda fase da avaliação (após a prototipagem) precisamos avaliar o

produto/aplicação. Podemos fazê-lo para estes quatro

elementos que vimos colocando as questões adequadas:

Perceber os utilizadores Avaliar a aplicação

Valor O que os utilizadores

necessitam? A aplicação preenche estas necessidades? Usabilidade Como as pessoas agem agora? Podem fazê-lo com o nosso

produto? Desejabilidade O que eles desejam? O que os

estimula? O produto é atraente? Adotabilidade Como as pessoas

Investigação UX – Recolha de dados

Os métodos para recolha de dados mais utilizados são: • Entrevistas (conversas, com maior ou menor liberdade,

geralmente individuais)

• Questionários (questões iguais para todos os intervenientes, geralmente com menor amplitude de resposta e

direcionados a um grupo vasto de pessoas)

• Focus Group (conversas com um grupo reduzido de pessoas, permitindo economizar tempo em relação à entrevista mas ao mesmo tempo obter mais informação do que um

Investigação UX – Recolha de dados

• _{Observação etnográfica (Observação de pessoas a realizar} atividades de modo a perceber os seus comportamentos nas diversas situações) – Pode ser “participante” quando o

investigador intervém ou “não participante” quando o investigador apenas observa.

• _{Testes de utilização (Interação com protótipos feita por} utilizadores com um perfil idêntico ao utilizador final geralmente seguindo um guião de tarefas).

• Analytics (Análise de informação em grande escala a

respeito da utilização de determinado produto de modo a conhecer padrões de utilização).

Investigação UX – Recolha de dados

• _{Análise de vídeo para recolha de informação que surja} durante a testagem.

• Captura de ecrã (permite recolher informação de onde o utilizador clicou, o que digitou, etc)

• Eye Tracker (dispositivos que gravam a informação do local para onde o utilizador olha de modo a perceber em que partes do ecrã se retém mais, ou os movimentos oculares que faz na leitura da informação).

Em geral estes testes não são exclusivos, pelo contrário, são feitos vários deles em simultâneo, por exemplo:

Testes de utilização

Testes de utilização

Nos testes de utilização, pessoas com o perfil do nosso

utilizador final irão interagir com protótipo e tentarão realizar tarefas importantes à utilização desse produto.

É o método mais importante na investigação UX por ser também o mais próximo do objetivo final da criação de um produto (a sua utilização).

http://www.smallbox.com/ https://99designs-blog.imgix.net/

Testes de utilização

Termos informação sobre a utilização dos nossos produtos é a melhor forma de os otimizarmos.

Com os testes de utilização (e consequentemente com questionários e outros métodos de recolha associados) podemos verificar como as pessoas interagem com as interfaces e a partir daí identificar erros no sistema,

necessidades dos utilizadores que não tínhamos pensado

anteriormente, elementos desnecessários ou distratores que possamos eliminar, problemas no design...

Testes de utilização – Como fazer?

1. Em termos gerais devemos começar por encontrar utilizadores (avaliadores) potenciais.

2. Se for o caso dividi-los em grupos de avaliadores com diferentes perfis.

3. Criar um guião de tarefas (e definir quantas vezes será realizado o teste).

4. Apresentar o protótipo e executar o guião (pedir aos avaliadores que realizem as tarefas nele constantes). 5. Opcionalmente realizar observações durante os testes. 6. Questionar os avaliadores (e.g. entrevista, questionários). 7. Escrever toda a informação dos testes (observações,

capturas de ecrã, entrevistas, questionários) 8. Analisar a informação e agir em conformidade.

Perfil dos avaliadores

Utilizadores que se inserem no público-alvo do produto a ser testado e que podem ter um conjunto próprio de

características definidas à partida:

Idade; Género; Localização; Nacionalidade; Etnia;

Habilitações (ou com determinado tipo de literacias, e.g., literacia digital); Comportamentais (utilização de

ferramentas/produtos semelhantes).

Nota: Não devem ser considerados utilizadores atuais do produto (por exemplo em upgrades, etc). Tal como os developers/designers, estes utilizadores já conhecem o software e podem já ter desenvolvido estratégias de resolução de problemas (logo não os identificam).

Tarefas

As tarefas não são mais do que ações concretas que o avaliador tem de executar no protótipo, estas devem ser

claras e concisas, e dar origem a um resultado final que possa ser verificado.

Se estivéssemos a realizar um guião para o site da Fnac, exemplos de tarefas podiam ser:

• _{Registe-se no site;}

• Compre um livro do Plano Nacional de Leitura indicado para o 6º ano e que custe menos de 10€.

Tarefas

Certamente que, com o exemplo anterior, muito mais tarefas poderíamos criar.

Para escolher quais tarefas pretendemos efetivamente definir, devemos criá-las mediante um conjunto de pressupostos:

• Tarefas básicas à utilização do site (tarefas que a

generalidade/totalidade dos utilizadores irá realizar).

• _{Tarefas específicas para determinado grupo de utilizadores} (se este tiver diferentes grupos de utilizadores).

• Tarefas mais complexas (tarefas que a alguns utilizadores irão realizar).

Podem ainda ser criadas tarefas “abertas” em que o resultado poderá não ser verificado por ser subjetivo.

Tarefas

Conforme referido, antes de iniciar o teste deverá existir uma explicação breve do que é o produto, nesta altura deverá ficar claro para os avaliadores que é o protótipo que está a ser

avaliado e não as capacidades dos utilizadores. Deste modo o avaliador ficará mais confortável e relaxado para executar o teste.

O guião deverá seguir uma evolução em termos de

dificuldade, do mais fácil de executar para o mais difícil. Deste modo o avaliador sentir-se-á mais confiante e motivado à

medida que vai realizando as tarefas.

Devemos assegurar-nos que temos tarefas para as várias

funcionalidades (e.g. registo/autenticação, pesquisa, compra, comentário).

Observação

Poderá ser de extrema utilidade realizar observações durante os testes, sejam estas realizadas pelo investigador (developer) seja através de hardware/software (e.g. câmara de filmar,

captura de ecrã).

Deste modo poderá observar situações importantes que, ou não estavam previstas no guião, ou que são de difícil

confirmação (por exemplo em tarefas abertas), ou que

ajudam a perceber os comportamentos e dificuldades dos utilizadores.

Ainda, deverá estimular os utilizadores a verbalizarem as suas emoções/sensações durante a realização dos testes (o

Pós-teste

Após o teste deverá existir forma de aprofundar o que foi feito nos testes, através de entrevistas (mais ou menos

estruturadas) e/ou de questionários. Deste modo poderá:

• Rever situações problemáticas identificadas/verificadas nos testes;

• _{Questionar a utilidade, valor, adequabilidade do produto;} • _{Questionar aspetos de usabilidade ou de estética do}

protótipo;

• Questionar opiniões relativas a funcionalidades, ferramentas que o utilizador considere importantes de ser incluídas (ou excluídas).

Anotar, anotar, anotar

Em todos os momentos da testagem (quer durante quer nos momentos de questionamento), deverá sempre anotar o que considerar importante.

Podem haver diversas circunstâncias que façam esquecer

determinada informação (surge nova informação e “substitui” a anterior, levamos vários dias/semanas até analisar os dados recolhidos e, nesse espaço, esquecemo-nos de informação valiosa, etc).

Nesse sentido, deve sempre tirar notas mesmo que tenha registos (e.g. vídeo), pois podemos mais tarde voltar a

verificar a falha mas não nos recordarmos dos motivos que levaram à falha (e.g. erro de software, má interpretação do avaliador, dificuldade de execução, etc).

Referências

Newman, M. (2017). Introduction to User Experience. https://www.youtube.com/watch?v=0z08iqExHvc

Nielsen, J. (1998-2017). Evidence-Based User Experience Research, Training, and Consulting. https://www.nngroup.com/articles/

Sueoka, M. (2016). Don’t Design What Users Want

https://www.invisionapp.com/blog/dont-design-what-users-want/ Vasquez, C. (2013). Getting Users to do What You Want the Way They Want. https://www.slideshare.net/clickpop/barcamp2011-slide-share