Cenários

Como visto na Seção 4.3.5, um cenário é basicamente uma história sobre pessoas rea- lizando uma atividade (Rosson e Carroll, 2002). É uma narrativa, textual ou pictórica, concreta, rica em detalhes contextu ais, de uma situação de uso da aplicação, envolven- do usuários, processos e dados reais ou potenciais. Os cenários podem ser utilizados em diversas etapas do processo, com diferentes objetivos: para descrever uma história num domínio de atividade, visando capturar requisitos e auxiliar no entendimento da atividade, levantar questões sobre a introdução de tecnologia, explorar diferentes soluções de design e avaliar se um produto satisfaz a necessidade dos seus usuários (Rosson e Carroll, 2002; Cooper, 1999). Além de poderosos, os cenários requerem menos custo e tempo quando comparados com modelos e protótipos complexos, o que os torna uma ferramenta importante em todo o processo de design de IHC.

Os cenários descrevem o comportamento e as experiências dos atores. Cada ator possui objetivos que dirigem as tarefas que ele realiza. Um cenário possui um enredo, que inclui sequências de ações e eventos: o que os usuários fazem, o que acontece com eles, que mudanças ocorrem no ambiente, e assim por diante. Essas ações e eventos podem ajudar, atrapalhar ou ser irrelevantes para o atingimento do objetivo.

Em geral, cada cenário apresenta um ator principal e um objetivo principal. Tal objetivo pode ser desdobrado em subobjetivos, numa atividade de planejamento que se passa na cabeça dos atores. Quando essa atividade mental for importante para uma situação, o cenário pode incluir informações sobre planejamento e avaliação das ações realizadas. Cada cenário costuma ter um título que descreve brevemente a situ- ação, sem muitos detalhes; os atores que participam do cenário; uma breve descrição da situação inicial em que os atores se encontram; e referências a outros cenários que permitam aos atores atingir os mesmos objetivos de diferentes maneiras. Segundo Rosson e Carroll (2002), os elementos característicos de um cenário são:

ambiente ou contexto

ƒ : detalhes da situação que motivam ou explicam os ob-

jetivos, ações e reações dos atores do cenário;

atores

ƒ : pessoas interagindo com o computador ou outros elementos do am-

objetivos

ƒ : efeitos na situação que motivam as ações realizadas pelos atores;

planejamento

ƒ : atividade mental dirigida para transformar um objetivo em

um comportamento ou conjunto de ações;

ações

ƒ : comportamento observável;

eventos

ƒ : ações externas ou reações produzidas pelo computador ou outras

características do ambiente; algumas delas podem ser ocultas ao ator mas importantes para o cenário;

avaliação

ƒ : atividade mental dirigida para interpretar a situação.

A descrição de um ator no cenário deve incluir as suas características pessoais que forem relevantes ao cenário. Caso os cenários sejam utilizados em conjunto com per- sonas, os atores dos cenários são as personas elaboradas previamente.

Na atividade de análise, em particular, utilizamos cenários de análise (por vezes denominados cenários de problema), histórias sobre o domínio de atividade do usu- ário, tal como ele existe antes da introdução de tecnologia (Rosson e Carroll, 2002). O Exemplo 6.4 ilustra dois cenários de análise relacionados para um sistema de ad- ministração acadêmica.

Cenários de análise Exemplo 6.4 –

Cadastro de projetos fi nais com coorientador externo não cadastrado Atores: Joana Marinho (secretária), Fernando Couto (aluno)

Na primeira semana de aula, Joana Marinho, secretária do curso de Engenharia Ambiental, precisa cadastrar entre vinte e trinta projetos fi nais dos alunos no período atual. Um projeto fi nal é um tra- balho individual de um aluno sob a orientação de um ou dois professores. Cada aluno preenche um formulário impresso e o entrega na secretaria. Em vez de cadastrar os projetos fi nais à medida que são entregues, Joana prefere juntar vários para cadastrá-los de uma vez, pois acha que assim perde menos tempo. Joana confere o formulário, verifi cando se o aluno defi niu seu(s) orientador(es) e o título e formato de entrega do seu trabalho (e.g., relatório, software), para então cadastrar os dados no sistema. No caso do aluno Fernando Couto, após informar o título do trabalho e o orientador principal, Joana descobre que o seu coorientador, que não é professor regular do curso, não está cadastrado no sistema. Ela interrompe o cadastramento, pega o e-mail de Fernando da sua fi cha cadastral (impressa) e lhe envia uma mensagem solicitando os dados do seu coorientador externo: nome completo, CPF e e-mail para contato. No dia seguinte, Joana recebe a mensagem de resposta de Fernando com os dados solicitados. Ela então reinicia o cadastro do projeto fi nal de Fernando, sem poder aproveitar o que havia feito na véspera. Ao terminar o cadastro, Joana entra no seu siste- ma de correio eletrônico e envia uma mensagem para todos os envolvidos (aluno e coorientadores), para que eles confi ram os dados cadastrados e confi rmem sua participação no projeto.

Confi rmação do cadastro de projetos fi nais Atores: Marcos Correa (professor)

Marcos Correa, orientador de Fernando, é um professor requisitado que orienta diversos alunos ao mesmo tempo. Todo início de período ele recebe diversas mensagens informando-lhe sobre os

projetos fi nais cadastrados sob sua supervisão. Infelizmente, as mensagens não apresentam os da- dos cadastrados, então ele precisa entrar no sistema para conferir os dados. Além disso, mesmo já estando no sistema e verifi cando um projeto, ele não consegue ver os dados dos outros projetos pendentes. Sendo assim, tem de fi car alternando entre o seu cliente de e-mail e o sistema acadêmi- co, e às vezes ele acaba visitando os dados de um mesmo projeto mais de uma vez.

Análise dos cenários

No primeiro cenário, observamos alguns pontos que podem ser considerados problemáticos e de- vem ser considerados em um reprojeto de IHC:

a necessidade de transcrição para o sistema de dados preenchidos pelo aluno em um formu- ƒ

lário impresso;

a falta de integração do sistema com as informações dos alunos (o e-mail de Fernando deve ser ƒ

buscado em uma fi cha impressa);

a incapacidade de enviar uma mensagem através do sistema para as pessoas envolvidas no ca- ƒ

dastro de um projeto fi nal (Joana precisa acessar seu sistema de correio eletrônico para enviar uma mensagem para o orientador, coorientador e aluno);

a impossibilidade de o professor acessar outros projetos com pendências, uma vez que já es- ƒ

teja no sistema.

Os cenários destacam objetivos sugeridos pela aparência e o comportamento de um sistema; o que as pessoas tentam fazer com ele; que procedimentos são adotados, não são adotados e realizados com sucesso ou falha; e quais interpretações as pessoas fazem do que acontece com elas (Rosson e Carroll, 2002). Por serem ricos em contex- tualização, os cená rios permitem explorar com detalhes os impactos do produto nas ativi dades e nos processos de trabalho dos usuários.

Cenários podem incluir exceções. Que eventos importantes acontecem raramen- te? Ao compreendermos situações extremas ou infrequentes que os usuários enfren- tam, podemos identifi car situações em que o produto pode se tornar problemático. Também podemos identifi car características-chave que podem benefi ciar seus usuá- rios fi nais (Cooper, 1999).

Uma diferença importante entre cenários e casos de uso utilizados em engenha- ria de soft ware é que os cenários podem enfatizar mudanças de objetivos, planos e entendimentos (Rosson e Carroll, 2002). Trata-se da descrição de um ator específi - co realizando ações específi cas. As ações potenciais e os fl uxos alternativos que são descritos num caso de uso só devem ser incluídos num cenário caso façam parte do processo de planejamento ou avaliação dos atores daquele cenário específi co. Em ou- tras palavras, cada cenário descreve apenas um dos caminhos descritos em um caso de uso. Carroll (2000) acredita que dia gramas e especifi cações abstraem a riqueza do uso do sis tema em situações reais, podendo se tornar um obstáculo tanto para uma exploração mais ampla do espaço de design quanto para o envolvimento e a partici- pação dos clientes e futuros usuários do sistema no processo de design.

As técnicas baseadas em cenários vêm ganhando grande aceitação por parte dos projetistas e seus clientes. Isso se deve princi palmente à natureza da atividade de de- sign de soft ware, que não é uma forma fácil ou rotineira de resolução de problemas. Problemas de design costumam ser especifi cados de forma incompleta, as soluções não são conhecidas a priori, envol vem equilibrar tensões entre diversos elementos interdependentes e requerem uma diversidade de conhecimento e habilidades. Além disso, o design de artefatos interativos causa transformações no mundo que alteram as possibilidades de atividade e experiência hu manas, com frequência extrapolando as fronteiras das soluções de design originais pre tendidas. O design de IHC baseado em cenários busca, através da concretização de situações de uso, explorar a complexi- dade da re solução de problemas de design (Carroll, 2000).

Algumas críticas ao uso de cenários se referem à frequência com que fi cam in- completos ou ambíguos. Com o objetivo de elaborar cenários mais completos, desco- brindo infor mações que tenham sido omitidas, Carroll et al. (1994) propõem a técni- ca de questionamento sistemático. Trata-se de segmentar o cenário em proposições e investigar mais profundamente cada proposição a partir de um conjunto geral de perguntas, cujas respostas, por sua vez, geram novas proposições, repetindo o ciclo até que o conjunto de proposições seja considerado sufi cientemente completo. Os tipos gerais de perguntas que eles sugerem são: Por quê? Como? O que é? X pode ser

feito da forma Y? X faz parte de Y? Associado a cada questão eles indicam o conteúdo

esperado das respostas à questão, conforme ilustrado na Tabela 6.1.

Questões para refi namento de cenários (Carroll

Tabela 6.1 et al., 1994)

questão conteúdo das respostas

questões exploratórias

Por que ...? ƒ condições para a realização da atividade consequências da atividade

ƒ

estados e eventos anteriores ou posteriores à atividade ƒ

Como ...? ƒ detalhes sobre a sequência de ações que compõem uma atividade pode revelar também objetos que não constavam do cenário origi- ƒ

nal

O que é ...? ƒ objetos e seus atributos, organizados em uma hierarquia ou outro modelo de dados

questões de verifi cação <X> pode ser feito da maneira <Y>?

respostas sim ou não ƒ

servem para avaliar se uma ação ou atributo está bem defi nido e ƒ

localizado no nível certo da hierarquia <X> faz parte de <Y>?

Para enriquecer as informações dos cenários, elaborar narrativas mais detalhadas e assim permitir uma análise mais profunda, o designer pode responder também per- guntas mais específi cas (adaptadas de Silveira et al., 2004; Aureliano, 2007), relacio- nadas com os elementos de um cenário (Tabela 6.2).

Perguntas utilizadas para refi nar cada elemento de um cenário ou auxiliar a análise Tabela 6.2

elemento perguntas

objetivo Por que os atores querem ou precisam alcançar esse objetivo? Quais as precondições para esse objetivo?

De que informações ou conhecimento os atores precisam para realizar esse objetivo?

Quais informações são (ou deveriam ser) criadas, consumidas, manipuladas ou destruídas pelo alcance do objetivo?

Que outros objetivos (de quais atores) estão relacionados a esse? ambiente Em que situações o cenário ocorre (quando, onde e por quê)?

Que dispositivos e outros recursos (inclusive tempo) estão disponíveis para o alcance do objetivo?

Quais pressões existem para o alcance do objetivo?

Quais são as tecnologias utilizadas no ambiente de trabalho? Como os usuários as utilizam?

ator(es) Quem pode alcançar o objetivo descrito no cenário?

Quais características dos atores lhes auxiliam ou atrapalham em alcançar o objetivo?

De quem depende o alcance do objetivo? Quem fornece as informações neces- sárias ao alcance do objetivo?

Quem depende do resultado do objetivo? Quem consome quais informações geradas pelo alcance do objetivo? Quem precisa ser notifi cado da conclusão (bem-sucedida ou malsucedida) do objetivo?

planejamento Como os atores alcançam o objetivo atualmente? Como gostariam de fazê-lo? Quais são as estratégias alternativas para realizar o objetivo? Quando e por

que cada estratégia é (ou deveria ser) seguida? Os atores conhecem todas as estratégias disponíveis?

Que decisões os atores precisam tomar a cada momento? De que maneira o ambiente e o sistema auxiliam ou impedem que os atores tomem decisões adequadas? Quais as consequências de uma decisão errada?

Que ações realizam? Como essas ações estão relacionadas?

Em que ordem os atores precisam realizar as ações? Gostariam de realizá-las em outra ordem?

elemento perguntas

ação Quais as precondições para essa ação? Como os atores as realizam?

Há diferentes formas de realizá-la? Qual deve ser adotada em que situações? Os atores gostariam de fazer isso de outra maneira? Como o fariam? De que informações ou conhecimento os atores precisam para realizar essa

ação?

Que recursos estão disponíveis para realizá-la?

Quais problemas ou difi culdades podem surgir ao realizá-la? Como podem ser resolvidos ou contornados?

Quais erros podem ser cometidos ao realizá-la? Como podem ser desfeitos? Quais suas consequências?

Quais informações são (ou deveriam ser) criadas, consumidas, manipuladas ou destruídas pela realização da ação?

Quais eventos são (ou deveriam ser) disparados pela realização da ação? evento Quais eventos disparam a necessidade de alcançar o objetivo?

Quais eventos são (ou deveriam ser) disparados pela conclusão desse objetivo? avaliação [de uma ação] Como os atores conseguem saber se uma ação foi concluída e

realizada com sucesso?

[do objetivo] Como os atores conseguem saber se o objetivo foi concluído e alcançado com sucesso?

[do objetivo] Qual é o resultado do alcance do objetivo?

Com cenários bem elaborados, os designers têm melhores condições de investigar quais atividades dos usuários poderiam ser executadas de forma mais efi ciente, o que se pode modifi car nos processos e sistemas atuais e como um sistema computacional interativo novo ou reprojetado pode melhor apoiar essas atividades, de forma a se encaixarem adequadamente no ambiente de trabalho.

Para assegurar que os cenários sejam representativos do produto, Cooper (1999) sugere que o conjunto de cenários enderece os cinco tópicos a seguir:

ciclo de vida do processo

ƒ : um processo em ampla escala deve ser decompos-

to em diversos passos, e cada passo pode ser representado por um cenário diferente;

segmentos de público

ƒ : seus cenários devem examinar os diferentes tipos de

usuário e suas experiências, objetivos habilidades, padrões de uso etc.;

funções do produto

ƒ : um produto pode ter diferentes funcionalidades, que

apoiam tarefas diferentes e não relacionadas. Seu conjunto de cenários deve cobrir a gama de funcionalidades que seu produto apoie;

variantes de uma classe de situações de tarefa

ƒ : uma simples tarefa (ou ob-

jetivo) pode ser realizada de diferentes formas. Idealmente, o conjunto de cenários deve examinar essas variações para cada tarefa;

métodos para realizar uma tarefa

ƒ : uma única tarefa é selecionada e diferen-

tes funcionalidades e métodos para realizá-la são examinados.

Cooper (1999) comenta, no entanto, que a elaboração de cenários pode consumir bastante tempo. Segundo ele, não é necessário criar cenários para todas as tarefas e situações que os usuários possam enfrentar. Em vez disso, devemos inicialmente ela- borar cenários para as tarefas principais, e para as tarefas secundárias à medida que o tempo permitir. Ele destaca os cenários de uso diário, que envolvem as principais ações que os usuários vão realizar, e com a maior frequência. Em geral, a maioria dos usuários possui poucos cenários de uso diário. Esses cenários são os que precisam de um apoio mais robusto do sistema sendo projetado. Os novos usuários precisam do- minar esses cenários rapidamente, e para isso as instruções devem ser claras e didáti- cas, embutidas no próprio sistema de forma contextualizada. Em contrapartida, como são utilizados com frequência, à medida que os usuários se tornarem experientes vão requerer atalhos e possibilidades de customização para que a interação se torne adequada às suas preferências e estilo individual. Esses cenários são em grande parte responsáveis pelo sucesso do produto.

Algumas tarefas são realizadas periodicamente mas com pouca frequência como, por exemplo, gerar um relatório anual. Elas também requerem instruções claras e didáticas embutidas no produto, mas geralmente podem prescindir de atalhos, pois raramente seriam aprendidos pelos usuários.

Personas e cenários podem ser utilizados no âmbito da engenharia semiótica para ajudar a defi nir a primeira parte da metamensagem designer–usuário: “Este é o

meu (designer) entendimento de quem você (usuário) é, do que aprendi que você quer ou precisa fazer, de que maneiras prefere fazer, e por quê.” (de Souza, 2005a, p. 25).

Para melhor coletar as informações necessárias à elaboração da metamensagem, Pau- la (2003) propõe complemen tar os cenários com perguntas que revelem a intenção do designer ao elaborar os cenários e identifi quem os pontos que o designer al meja descobrir, explorar ou ratifi car junto aos usuários. O designer pode gerar uma lista única de perguntas para um conjunto de cenários, numeradas para que estes possam se referir a cada pergunta individualmente, incluindo o número da pergunta entre colchetes, logo após o trecho correspondente no cenário, conforme ilustrado pelo Exemplo 6.5.

Perguntas exploradas nos cenários Exemplo 6.5 –

Conjunto de perguntas e parte do cenário do Exemplo 6.4 anotado com referências às perguntas. Quem pode/deve cadastrar os dados dos projetos fi nais no sistema?

1.

Quando são cadastrados os projetos fi nais? 2.

Quem fornece os dados dos projetos fi nais? 3.

Quais dados de projeto fi nal devem ser cadastrados? 4.

Quantos projetos são cadastrados a cada período? 5.

Quem pode orientar um trabalho fi nal? 6.

Que dados são necessários para cadastrar um coorientador externo? 7.

Como são obtidos os dados de um coorientador externo? 8.

De quem depende a conclusão do cadastramento de projeto fi nal? 9.

De que informações os responsáveis pelo projeto precisam para confi rmarem o cadastro? 10.

Como um envolvido efetua a confi rmação do cadastro? 11.

Em que pontos a interação pode ser mais efi ciente? 12.

Como entrar em contato com um aluno? 13.

Quem precisa ser notifi cado da conclusão do cadastro? 14.

Cadastro de projetos fi nais com coorientador externo não cadastrado Atores: Joana Marinho (secretária), Fernando Couto (aluno)

Na primeira semana de aula [2], Joana Marinho, secretária do curso de Engenharia Ambiental, precisa cadastrar entre 20 e 30 projetos fi nais dos alunos no período atual [5]. Um projeto fi nal é um trabalho individual de um aluno sob a orientação de um ou dois professores [6]. Cada aluno pre- enche um formulário impresso e o entrega na secretaria [3]. Em vez de cadastrar os projetos fi nais à medida que são entregues, Joana prefere juntar vários para cadastrá-los de uma vez, pois acha que assim perde menos tempo [2]. Joana confere o formulário, verifi cando se o aluno defi niu seu(s) orientador(es) e o título e formato de entrega do seu trabalho (e.g., relatório, software [4]), para en- tão cadastrar os dados no sistema [1]. No caso do aluno Fernando Couto, após informar o título do trabalho e o orientador principal, Joana descobre que o seu coorientador, que não é professor regu- lar do curso [6], não está cadastrado no sistema. Ela interrompe o cadastramento, pega o e-mail de Fernando da sua fi cha cadastral (impressa) [13] e lhe envia uma mensagem [8] solicitando os dados do seu coorientador externo: nome completo, CPF e e-mail para contato [7]. No dia seguinte, Joana recebe a mensagem de resposta de Fernando com os dados solicitados. Ela então reinicia o cadastro do projeto fi nal de Fernando, sem poder aproveitar o que havia feito na véspera [12]. Ao terminar o cadastro, Joana entra no seu sistema de correio eletrônico e envia uma mensagem para todos os envolvidos (aluno e orientadores) [14], para que eles confi ram os dados cadastrados e confi rmem sua participação no projeto [9].

Naturalmente, nem todas as perguntas são exploradas em todos os cenários. No en- tanto, assim como no questionamento sistemático proposto por Carroll, pensar na forma de perguntas pode levar o designer a descobrir lacunas no cenário. Por exem-

No documento Simone Barbosa and Bruno Silva - Interação Homem Computador (páginas 188-200)