Disciplinas > Requisitos > Conceitos > Design Centrado no Usuário

Tópicos

O que é o design centrado no usuário? Início da página

Não há um consenso claro sobre o que é o design centrado no usuário. No entanto, John Gould e seus colegas na IBM desenvolveram um método na década de 1980 chamado Design Pensando em Usabilidade [GOU88] que compreende as definições mais comumente aceitas. Ele foi desenvolvido a partir de experiências práticas com uma série de sistemas interativos, especialmente o Olympic Messaging System (Sistema de Mensagens Eletrônicas Olímpicas) da IBM em 1984 [GOU87].  O método tem quatro componentes principais, conforme é descrito abaixo.

Foco nos usuários Início da página

Gould sugere que os desenvolvedores devem decidir quem serão os usuários e devem envolvê-los o quanto antes. Ele sugere várias formas de se familiarizar com os usuários, suas tarefas e seus requisitos:

·    Converse com os usuários

·    Visite os locais de trabalho dos clientes

·    Observe os usuários trabalhando

·    Grave em vídeo os usuários trabalhando

·    Aprenda sobre a organização do trabalho

·    Tente você mesmo

·    Faça os usuários pensarem alto enquanto trabalham

·    Elabore um design participativo

·    Inclua usuários peritos na equipe de design

·    Realize análise de tarefa

·    Utilize pesquisas e questionários

·    Desenvolva metas passíveis de teste

 No Rational Unified Process (RUP), são usados workshops em vários estágios-chave, mas eles precisarão ser complementados pelos tipos de atividades que Gould descreve se for necessário formar um retrato fiel. (Parte do argumento por trás disso é que as pessoas em geral descrevem o que fazem de forma bem diferente de como elas fazem. As tarefas mais usuais e os detalhes aparentemente sem importância, como a localização do trabalho ou a existência de recortes de papel "misteriosos", são freqüentemente esquecidos, ou omitidos porque eles não são parte "oficial" do processo atual.)

Integração com o designInício da página

Tarefas de usabilidade devem ser realizadas em paralelo desde o início do desenvolvimento. Essas tarefas incluiriam esboçar a interface do usuário e rascunhar os manuais do usuário ou ajuda on-line. Gould também argumenta que a usabilidade deve ser responsabilidade de um grupo.  

Uma característica importante do design integrado é que o modelo geral - o framework - para  design detalhado de interface do usuário é desenvolvido e testado em um estágio inicial. Essa é uma diferença importante entre o design centrado no usuário e outras técnicas puramente incrementais. Isso assegura que o design incremental realizado em fases posteriores se adapte sem emendas no framework e que a interface de usuário seja consistente em aparência, terminologia e conceito.

Dentro do RUP, esse framework pode ser estabelecido usando-se um modelo de domínio para assegurar que toda a terminologia e todos os conceitos que aparecerem na interface de usuário sejam conhecidos e compreendidos dentro do negócio em geral e pelos usuários em particular. (Existirão também subconjuntos do modelo de domínio que serão relevantes apenas para grupos específicos de usuários. Deve-se tomar cuidado para assegurar que o modelo de domínio seja organizado de modo que esses subconjuntos possam ser facilmente identificados.) À medida que o design da interface de usuário avançar na disciplina de requisitos, muitas das classes de domínio serão representadas como classes de fronteira na interface. As classes de fronteira e o relacionamento entre elas devem ser consistentes com o modelo de domínio e devem ser representadas consistentemente em todas as partes do sistema que está sendo projetado. (Isso não apenas ajuda os usuários, mas também melhora a reutilização de componentes da interface de usuário.)

Teste com o usuário no inícioInício da página

O teste com o usuário no início significa a criação inicial de protótipos, normalmente esboços e modelos descritos como protótipos de baixa fidelidade. Protótipos de alta fidelidade serão confeccionados mais tarde no processo.

Os modelos podem ser usados juntamente com casos de uso para escrever cenários concretos de uso para o sistema que está sendo projetado. Eles podem apresentar o relato da forma, relato ilustrado (usando modelos para a ilustração), encenações, ensaios (com usuários) e a base de grupos de usuários. Embora esses modelos não sejam familiares a muitos dos desenvolvedores de softwares, eles são nitidamente mais vantajosos do que a descoberta de um design inadequado ou o entendimento equivocado dos requisitos quando a implementação já está em andamento.

Design iterativoInício da página

O desenvolvimento orientado a objetos se tornou sinônimo de processo iterativo. O design iterativo se adapta bem a problemas que necessitam de um refinamento de compreensão e que têm requisitos variáveis. Não é surpresa, então, que o design iterativo seja um componente-chave do design centrado no usuário. Isso se deve em parte às necessidades dos usuários em constante mudança ao longo do tempo, mas também à complexidade inerente da produção de soluções de design que possam tratar de necessidades diversas.

Observe que nos métodos centrados no usuário, o design iterativo ocorre dentro de um framework integrado. Nós evitamos deliberadamente o desenvolvimento incremental, fora de um framework reconhecido, que poderia levar a uma solução do tipo "colcha de retalhos".

Por que um design centrado no usuário? Início da página

Atendimento das necessidades do usuário Início da página

Os sistemas interativos contam com sua capacidade de acomodar as necessidades dos usuários para obter sucesso. Isso significa não apenas identificar várias comunidades de usuários, mas também reconhecer o âmbito das habilidades, experiência e preferências de usuários individuais.

Embora seja tentador para os desenvolvedores e gerentes sentir que eles entendem as necessidades do usuário, na prática, eles raramente as entendem. Freqüentemente, a atenção concentra-se em como os usuários devem executar tarefas em vez de como eles preferem executá-las. Na maioria dos casos, a questão de preferência ultrapassa o simples sentimento de controle, embora essa seja, ela mesma, uma questão importante. A preferência também será determinada pela experiência, pela habilidade e pelo contexto de uso. Essas questões são consideradas suficientemente importantes no processo de design para assegurar um padrão internacional, [ISO 13407], chamado processos de design centrado no usuário para sistemas interativos. O padrão e outras questões relacionadas são abordados de forma genérica no resto deste artigo.

Design da interface do usuário Início da página

Os usuários compreendem e interagem com um sistema através da sua interface de usuário. Os conceitos, as imagens e a terminologia apresentados na interface devem ser adequados às necessidades do usuário. Por exemplo, um sistema que permite aos clientes comprar seus próprios ingressos seria bem diferente de um utilizado profissionalmente por uma equipe de vendas de ingressos. As principais diferenças não estão nos requisitos ou mesmo nos casos de uso detalhados, mas nas características dos usuários e dos ambientes nos quais os sistemas operariam.

A interface de usuário deve também atender um amplo espectro potencial de experiência em, pelo menos, duas dimensões, a experiência com computador e com domínio, como é mostrado na figura 1 abaixo. A experiência com computador inclui não só a familiaridade geral com computadores, mas também a experiência com o sistema em desenvolvimento. Os usuários com pouca experiência em computadores ou no domínio do problema, que podem ser vistos no canto esquerdo anterior da figura, exigirão um modelo na interface de usuário bem diferente da interface dos usuários peritos, mostrado no canto direito posterior.

Figura 1: Os efeitos da experiência com computador e domínio na facilidade de aprendizagem versus facilidade de uso

Note que isso não é uma conclusão irrevogável de que os usuários sem experiência se tornarão peritos com o passar do tempo. Vários fatores podem impedir isso, por exemplo, baixa freqüência de uso, baixa motivação e alta complexidade. De modo contrário, alguns sistemas podem ter, predominantemente, usuários peritos. Os fatores aqui podem ser treinamento, alta freqüência de uso ou alta motivação (confiança no emprego). Algumas dessas questões e seus efeitos no design da interface de usuário são mostrados na tabela 1.

 

Baixa

Alta

Experiência com computador

Pergunta e resposta simples, preenchimento de formulário simples, estilo de interface da Web (com hyperlinks) ou de menus

Preenchimento de formulário complexo, estilo de interface da Web (com hyperlinks) ou de menus (pergunta e resposta ou preenchimento de formulário simples seria muito frustrante para usuários experientes)

Experiência com domínio

Terminologia e conceitos usuais

Terminologia e conceitos específicos ao domínio

Treinamento

Foco na facilidade de aprendizagem (consistente, previsível, memorável)

Foco na facilidade de uso (direto, personalizável, não intrusivo)

Freqüência de uso

Fácil de aprender e lembrar, estilo de interface simples

Fácil de usar, vários atalhos e técnicas para permitir o controle pelo usuário

Motivação

Uso recompensado, poderoso sem parecer complexo

Sofisticado com muitas características avançadas e personalizáveis

Tabela 1: Alguns fatores que afetam o design de interface do usuário

Os sistemas interativos devem ser projetados para atender uma gama apropriada de experiência do usuário e circunstâncias, ou deverão ser tomados procedimentos para restringir o universo do design. Por exemplo, o treinamento pode ser usado para reduzir o requisito de facilidade de aprendizagem em um sistema complexo. Como alternativa, o escopo de um sistema poderá ser reduzido para que ele atenda melhor os requisitos principais de seus usuários (uma sugestão feita por Alan Cooper em seu livro The Inmates Are Running the Asylum [COO99]).

Legislação e padrões Início da página

Como parte do design centrado no usuário, é necessário considerar as habilidades e os atributos físicos dos usuários. Essas questões têm sido incluídas ultimamente na legislação. Isso se aplica diretamente à adaptação de usuários com deficiências físicas. No entanto, tornar os sistemas acessíveis a uma maior variedade de usuários, em geral, é visto como um benefício à comunidade de usuários como um todo.

A tabela abaixo mostra a legislação relevante e os recursos em várias partes do mundo:

Descrição

Site na Web

AUSTRÁLIA

 

Estatuto sobre Discriminação por Deficiência Física

http://www.deakin.edu.au/extern/rdlu/ddaindex.html

Direitos sobre Deficiência Física

http://www.hreoc.gov.au/disability_rights/index.html

EUROPA

 

Tratado de Amsterdã

http://www.edf.unicall.be/teu/en/index.asp

Fórum Europeu sobre Deficiência Física

http://www.edf.unicall.be

REINO UNIDO

 

Estatuto sobre Discriminação por Deficiência Física

http://www.hmso.gov.uk/acts/acts1995/1995050.htm

Nova Política para Pessoas com Deficiência Física

http://www.disability.gov.uk

Campanha para Acesso Digital

http://www.rnib.org.uk/digital/welcome.htm

NAÇÕES UNIDAS

 

Regras Padrão das Nações Unidas sobre a Equalização de Oportunidades para Pessoas com Deficiência Física

http://www.un.org/esa/socdev/dissre00.htm

Informações sobre Desenvolvimento Social na Internet

http://unescap.org/sps/sdinfo/disablinks.htm

ESTADOS UNIDOS

 

Decreto sobre Americanos com Deficiência Física (ADA): Ministério da Justiça dos EUA

http://www.usdoj.gov/crt/ada/

Seção 508 do Decreto sobre Investimento na Força de Trabalho: Ministério da Justiça dos EUA

http://www.usdoj.gov/crt/508/508home.html

 

Comitê Consultivo sobre Tecnologia da Informação e de Eletrônica (EITAAC) da Junta de Acesso dos EUA

http://www.access-board.gov

 

Campanha de Acessibilidade à Web do Consórcio World Wide Web

http://www.w3.org/wai/

 

OUTROS RECURSOS

 

Recursos na Internet Relacionados à Deficiência Física

http://www.webable.com/

 Tabela 2a: Legislação relativa à deficiência física por país, região ou organização

À parte a legislação, o design centrado no usuário e o design de interface de usuário têm se tornado alvo crescente de padronização, como é mostrado abaixo.

Descrição

Site na Web/Padrões

ANSI

www.ansi.org

ANSI

ANSI-HFES

ANSI-NSC

O ANSI e a Sociedade de Fatores Humanos e Ergonomia publicaram vários padrões conjuntos. O ANSI também tem o ANSI-NSC Z365 que diz respeito ao controle e à prevenção de desordem por stress cumulativo (também conhecida como lesão por esforço repetitivo).

O ANSI está preparando padrões relativos à interação homem-computador como parte do Painel de Padrões da Infra-estrutura da Informação (IISP) em http://web.ansi.org/public/iisp/std_need/needcat.html.

ISO

www.iso.ch

ISO 9241

Uma grande variedade de padrões relativos, principalmente, à ergonomia de estações de trabalho, mas também inclui um guia sobre usabilidade (parte 11). Também a base para ANSI-HFES 200, em desenvolvimento.

ISO 10075: 1991

Princípios ergonômicos relacionados à carga de trabalho mental

ISO 17041-1: 1995

Controle de cursor para edição de texto

ISO 11581

Série em desenvolvimento que trata de ícones e ponteiros

ISO 13407: 1999

Padrão para processos de design centrado no usuário para sistemas interativos

 Tabela 2b: Padrões ANSI e ISO de design centrado no usuário e de interface de usuário

Design centrado no usuário no RUP Início da página

O desenvolvimento de sistemas adequados às necessidades do usuário significa um grande esforço na análise dos requisitos. No design centrado no usuário, esse esforço é focado nos usuários finais. Eles são um subconjunto dos Atores de Negócio (para usuários externos ao negócio) e Trabalhadores de Negócio encontrados quando se trabalha na disciplina Modelagem de Negócios. Eles serão descritos posteriormente com mais detalhe na disciplina Requisitos como Atores. (O relacionamento entre Atores, Atores de Negócio e Trabalhadores de Negócio é abordado em Diretrizes: Transição de Modelos de Negócios para Sistemas.)

No entanto, um ponto importante a ser enfatizado no design centrado no usuário é que sejam compreendidos os requisitos das pessoas de verdade que preencherão os papéis descritos nos artefatos mencionados acima. Particularmente, deve-se evitar projetar usuários hipotéticos para os quais seja conveniente projetar sistemas de software. Os artefatos que descrevem os usuários finais só devem ser escritos depois do contato direto e intensivo com os usuários. No design centrado no usuário, esse contato direto é parte de um processo chamado, às vezes, de pesquisa contextual. Hugh Beyer e Karen Holtzblatt (em seu livro Contextual Design, [BEY98]) descrevem a premissa da pesquisa contextual como:

"...vá aonde o cliente trabalha, observe o cliente enquanto ele trabalha e converse com o cliente sobre o trabalho."

(Alguns exemplos concretos disso já foram listados em Foco nos Usuários.) Esse método é usado não apenas para obter uma melhor compreensão dos requisitos do sistema, mas também dos usuários, de suas tarefas e de seus ambientes. Cada um tem seus próprios atributos e em conjunto são mencionados como o contexto de uso. Eles são detalhados no padrão ISO para design centrado no usuário, descrito abaixo.

Contextos de Uso Início da página

Os Processos de design centrado no usuário para sistemas interativos [ISO13407] do padrão ISO identifica o primeiro passo do design como a compreensão e especificação do contexto de uso. Os atributos sugeridos são:

Contexto

Atributos

Tarefas

Metas do uso do sistema, freqüência e duração do desempenho, considerações sobre saúde e segurança, alocação das atividades, passos operacionais entre os recursos humanos e tecnológicos. As tarefas não devem ser descritas em termos de funções e características fornecidas por um produto ou sistema.

Usuários (para cada tipo ou papel diferente)

Conhecimento, habilidade, experiência, instrução, treinamento, atributos físicos, hábitos, preferências, recursos.

Ambientes

Hardware, software, materiais, ambientes físico e social, padrões relevantes, ambiente técnico, ambiente circundante, ambiente jurídico, ambiente social e cultural.

Tabela 3: Contexto de uso do padrão ISO para design centrado no usuário

É útil dividir o contexto do usuário em suas duas partes constituintes (tipo e papel do usuário) e considerar os relacionamentos entre todos os quatro contextos:

Figura 2: Relacionamentos entre contextos

A figura 2 mostra que cada tarefa é realizada em um papel exercido por um usuário dentro de um ambiente. Esses contextos correspondem aos artefatos do RUP mostrados na tabela 4.

Contexto do ISO 13407

O Artefato do RUP

Ambientes

Usuários

Papéis

Tarefas

 Tabela 4: Contextos do padrão ISO para design centrado no usuário e seus artefatos do RUP

Cada um desses contextos poderia ter um impacto significativo no design de uma interface de usuário apropriada. Em conseqüência, nos deparamos com um número potencialmente grande de permutações. Mesmo em um sistema pequeno, podem existir dois ambientes (por exemplo, o escritório e o local do cliente), três tipos de usuários (aprendiz de vendas, perito em vendas e gerenciamento) e seis papéis (assistente de vendas por telefone, representante externo de vendas, etc.). Isso significa até 36 variações potenciais por tarefa, embora o conjunto de combinações realistas, em geral, seja bem menor.

É claro que as tarefas devem ser descritas individualmente, mas uma descrição única provavelmente não será apropriada para todas as permutações. Um modelo é considerar os contextos de usuário e de ambiente na descrição do papel. Essa foi a solução adotada por Constantine e Lockwood [CON99]. Ela envolve o fornecimento de um "papel de usuário" separado para cada permuta significativa de papel, usuário e ambiente, nomeando em seguida o papel de usuário resultante com uma expressão descritiva, em vez de com um simples substantivo. Compare, por exemplo, o papel "Cliente" com os papéis de usuário "Cliente Casual", "Cliente da Web", "Cliente Regular" e "Cliente Avançado".

Cada papel de usuário contém detalhes sobre o papel propriamente dito mais os seus usuários (mencionados como encarregados pelo papel) e ambiente. Esse modelo pode ser adotado com o RUP escolhendo-se atores que correspondam aos papéis de usuário.

Cenários, casos de uso e casos de uso essenciais Início da página

Os termos cenário, casos de uso e casos de uso essenciais têm um grau de confusão de sobreposição e são usados em diferentes métodos de design para significar coisas ligeiramente distintas. Por exemplo, dentro do RUP, "cenário" significa uma instância de caso de uso; simplesmente um "caminho" específico através dos possíveis fluxos básicos e alternativos. Contudo, é comum encontrar métodos de design de interface de usuário descrevendo cenários como histórias de uso, contendo muito mais detalhes do que o simples fluxo de eventos. Embora essas informações adicionais possam parecer irrelevantes nas fases posteriores de design, elas formam parte da compreensão sobre usuários, tarefas e ambientes. Como conseqüência, os cenários podem ser usados extensivamente (em encenações e interpretação de papéis) na disciplina Modelagem do Negócio, mas o foco é movido para os casos de uso na disciplina Requisitos.

A figura 3 mostra a natureza dessa sobreposição. A escala no alto incorpora vários fatores diferentes que tendem a variar juntos. Por exemplo, à medida que a finalidade se move em direção aos requisitos, a estrutura geralmente se torna mais formal. Os casos de uso essenciais aparecem à direita dos casos de uso genéricos porque os papéis de usuários os tornam um pouco mais específicos (consulte a seção precedente) e eles têm uma estrutura mais formal.

Figura 3: Sobreposição de conceitos entre cenários e casos de uso no design centrado no usuário

As diferenças entre casos de uso do sistema e casos de uso essenciais são melhor ilustradas por um exemplo.  A tabela 5 mostra um caso de uso encontrado em Software for Use, de Constantine e Lockwood [CON99]:

Ação do Usuário

Resposta do Sistema

inserir cartão

 
ler a faixa magnética
solicitar o PIN

digitar o PIN

 
verificar o PIN
exibir menu de opções de transação

pressionar tecla

 
exibir menu da conta

pressionar tecla

 
solicitar valor

digitar valor

 
exibir valor

pressionar tecla

 
retornar cartão

retirar cartão

 
entregar dinheiro

retirar dinheiro

 

Tabela 5: Caso de uso genérico para retirar dinheiro em um caixa eletrônico

Esse exemplo discrimina a seqüência de eventos entre o ator e o sistema, com a linha vertical entre as duas colunas representando a interface do usuário. Observe que Constantine e Lockwood recomendam esse estilo para casos de uso essenciais, mas esse caso de uso particular não é um essencial. A razão é que ele foi baseado em um detalhe sintático da interação. Quer dizer, como a interação ocorre. Um caso de uso essencial foca o que a interação diz respeito (chamado de semântica). A tabela 6 é a versão essencial da interação.

Intenção do Usuário

Responsabilidade do Sistema

identificar usuário

 
verificar identidade
oferecer opções

escolher


entregar dinheiro

retirar dinheiro

 

Tabela 6: Caso de uso essencial para retirar dinheiro em um caixa eletrônico

Esse caso de uso capta a essência da interação para retirar  dinheiro. Os cabeçalhos Ação do Usuário e Resposta do Sistema foram substituídos por Intenção do Usuário e Responsabilidade do Sistema para refletir a mudança de ênfase. O bom design de interface concentra as metas e as intenções do usuário que, normalmente, são ocultadas nos casos de uso convencionais.  Os casos de uso essenciais serão particularmente úteis se:

  • houver poucas restrições de design (por exemplo, a restrição de design implícita de usar cartões de banco é falsa)
  • o sistema puder ser melhorado para usar outros meios de identificação (como algum tipo de acesso seguro pela internet)
  • for desejável criar Casos de Uso sem restrições de design, para reutilização potencial em projetos que não tenham essas restrições

No entanto, os casos de uso essenciais têm suas desvantagens. Casos de uso tão compreensíveis como o mostrado na tabela 5 podem estar sujeitos a muito debate quando sua essência é passível de refinamento. Por exemplo, a inserção de um cartão identifica o cliente ou a conta? Na maioria dos caixas eletrônicos existentes, identifica a conta, embora Constantine e Lockwood escolheram interpretar isso como a identificação do cliente. Isso pode ter sido uma decisão deliberada devido à tecnologia de ponta como identificação por escaneamento de retina e impressão digital, ou pode ter sido um descuido. A conseqüência, neste caso, é uma opção adicional a ser feita pelos clientes que possuem mais de uma conta.

Outra dificuldade apresentada pelos casos de uso essenciais é que eles não são tão adequados para análise com usuários finais e outros envolvidos por causa de sua natureza abstrata. Parte desse problema provém da necessidade de reverter os casos de uso essenciais em uma forma concreta que representa as ações do usuário. Isso pode ser feito quando o modelo de design estiver disponível por cenários escritos que descrevem a interação em termos concretos (semelhante, em conceito, a uma Realização de Casos de Uso, embora seja relativo à interação do usuário do sistema e não à  colaboração de objeto interno).

Resumindo, a elaboração de casos de uso essenciais pode não ser uma boa idéia se:

  • as tecnologias de interface de usuário forem intencionalmente muito restritivas (por exemplo, o sistema é obrigado a aceitar cartões de banco)
  • o tempo necessário para que os usuários entendam os casos de uso mais abstratos for mais importante que os benefícios esperados

Casos de uso essenciais no RUP Início da página

O RUP não se refere explicitamente aos casos de uso essenciais, mas em Atividade: Modelo de Interface de Usuário, casos de uso essenciais são usados como ponto de partida e depois desenvolvidos e aumentados com requisitos de usabilidade para criar encenações de caso de uso, como é explicado em Diretrizes: Encenação de Caso de Uso.  

  • Comece esclarecendo o próprio caso de uso, e não a interface do usuário. Faça a descrição sem considerar a interface do usuário, especialmente se o caso de uso ainda não foi explorado. Mais tarde, quando o caso de uso for compreendido, a encenação do fluxo de eventos poderá ser ampliada, incluindo a interface do usuário e os aspectos de usabilidade. [de Diretrizes: Encenação de Caso de Uso]

Isso significa remover todos os detalhes de design ou de implantação atual de modo que apenas a semântica - o significado da interação - permaneça.  Em seguida, à medida que as alternativas de design forem exploradas, o detalhe sintático - como ocorre a interação - será adicionado ao caso de uso essencial como um tipo de realização.  (Cada design alternativo é, na verdade, uma realização do mesmo caso de uso essencial.)

Essas encenações de caso de uso são usadas como entrada em Atividade: Criar um Protótipo da Interface do Usuário para desenvolver os protótipos de interface de usuário.

Copyright  (c) 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process