EAD

Modelos de Processo de
Software e Prototipação

1. OBJETIVOS
• Entender os modelos de processo de software.
• Conhecer uma forma de projetar um sistema centrado no usuário.
• Entender a prototipação.

2. CONTEÚDOS
• Modelos de processo de software.
• Modelo em "cascata".
• Desenvolvimento evolucionário.
• Desenvolvimento incremental.
• Desenvolvimento em espiral.
• Projeto Centrado no Usuário.
• Prototipação.

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE

Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) Você iniciará seus estudos sobre os modelos de processo de software. Aqui, terá a
oportunidade de perceber o cuidado que há no desenvolvimento de um software,
pois é preciso levar em consideração os seus futuros usuários e as suas respectivas
 68 © Interface Humano-Computador

habilidades e dificuldades. No entanto, antes de prosseguir esta leitura, é necessário

que você reflita sobre em qual etapa desses modelos se preocuparia com as caracte-
rísticas que envolvem o usuário.
2) Com base no conteúdo "Projeto Centrado no Usuário", que será estudado nesta uni-
dade, pesquise outras formas de desenvolvimento de softwares, considerando as ca-
racterísticas dos usuários e consultando os livros e os sites indicados na bibliografia
deste Caderno de Referência de Conteúdo. Aprofunde seus conhecimentos nesta área!
Pesquise, também, sobre o Design Participativo, um conceito que tem crescido na
área acadêmica no Brasil.
3) Nesta unidade, você irá estudar a prototipação. Seria interessante conhecer mais so-
bre o uso atual dessa estratégia para o desenvolvimento de software tanto nas empre-
sas quanto nas universidades.
4) Você irá perceber que, no decorrer dos seus estudos, sua experiência no desenvolvi-
mento de software será de grande importância. Notará, também, que alguns ques-
tionamentos lhe auxiliarão a entender os conceitos que serão abordados e a como
futuramente utilizá-los:
• Você já desenvolveu algum software?
• Qual é o tipo que foi desenvolvido?
• Quando isto ocorreu, você já conhecia a interface humano-computador ?
• Em que momento se preocupou com as características dos usuários?

4. INTRODUÇÃO À UNIDADE
A preocupação em desenvolver um software de qualidade e, isso inclui considerar as pes-
soas, as suas características, suas habilidades e suas dificuldades no desenvolvimento de siste-
mas aumentou de maneira significativa nos últimos anos. Como você pôde observar na unidade
2, à medida que a evolução dos computadores acontecia, a forma de interagir com eles se modi-
ficava, embora não no mesmo ritmo, já que o hardware evoluiu em uma velocidade maior.
Atualmente, é perceptível essa preocupação, especialmente por causa da concorrência
entre os sistemas computacionais e as empresas de desenvolvimento de software. As pessoas
que implementam sistemas estão cada vez mais preocupadas com a qualidade e atentas para
essa diferença, que se torna significativa na escolha pelo usuário do melhor sistema e, conse-
quentemente, na sua aquisição. Contudo, apesar de ser importante identificar as características
dos usuários, a maneira com que eles realizam as atividades, pensam e desenvolvem todos os
outros fatores humanos, não é uma tarefa trivial.
É necessário pensar e estar muito atento a essas características desde o início do desenvol-
vimento de software, como descrito na unidade anterior. No entanto, a coleta dessas informações,
dependendo da forma que será feita, poderá causar constrangimento ou alguma insegurança
aos usuários, que, simplesmente, mesmo que inconscientemente, poderão não apoiar essa fase
importante.
A seguir, você conhecerá alguns cuidados que os usuários têm para se expressar e falar o
que pode ser mudado ou não, como também uma estratégia para evitar esse tipo de constrangi-
mento e atitude, afinal, você precisa do usuário para conhecê-lo e desenvolver uma ferramenta
útil e usável.
Como o assunto que estudaremos nesta unidade está diretamente relacionado ao de-
senvolvimento de software, serão apresentados, inicialmente, alguns modelos de processo de
software comuns na literatura e em muitas empresas.
 © U4 – Modelos de Processo de Software e Prototipação 69

5. MODELOS DE PROCESSO DE SOFTWARE

O processo de software é um conjunto de atividades para a produção de sistema compu-
tacional. O processo envolve o desenvolvimento de um sistema do início ao fim. Há vários tipos
de modelos de processo de software, porém todos possuem algumas etapas em comum, tais
como (SOMMERVILLE, 2003):
• Especificação de software: é preciso definir a funcionalidade do software e as restri-
ções em sua operação.
• Projeto e implementação de software: o software deve ser produzido de modo que
cumpra sua especificação.
• Validação de software: o software precisa ser validado para garantir que ele faz o que
o cliente deseja.
• Evolução de software: o software precisa evoluir para atender às necessidades mutá-
veis do cliente.
O estudo desses modelos não é algo diretamente relacionado à IHC, pois eles se preo-
cupam mais com os requisitos e com as funcionalidades do sistema do que com o usuário. No
entanto, é necessário conhecer e entender esses modelos, pois eles são importantes para o de-
senvolvimento do sistema. Afinal, há a necessidade de se preocupar com o usuário, assim como
com as funcionalidades e outros aspectos relacionados ao sistema.
O objetivo de apresentar os modelos é para que você possa conhecer as etapas de de-
senvolvimento de software sem a ênfase na IHC, para, depois, entender como a IHC pode ser
aplicada em cada uma das etapas, pois, diferentemente do que muitas pessoas acreditam, não
se deve começar a pensar na IHC no meio ou no final do desenvolvimento do sistema, temos de
pensar na interação desde o início.
Quatro processos de software serão apresentados a seguir, no entanto, não há uma regra
de que é necessário seguir o mesmo processo do início ao fim do sistema, pois, especialmen-
te em grandes sistemas, é natural que processos diferentes sejam utilizados para desenvolver
partes distintas do sistema. Cada processo possui características, vantagens e desvantagens que
devem ser consideradas na escolha de um determinado processo para utilizar durante todo o
desenvolvimento do software ou somente em partes dele.

Modelo em "cascata"
O modelo em "cascata" possui esse nome devido à sequência em cascata de uma fase
para a outra, a qual não pode ser alterada. Esse modelo defende que você só pode passar para
a outra etapa depois que realizou, de maneira satisfatória, a etapa atual. As principais etapas
do modelo, apresentadas na Figura 1, retratam as atividades de desenvolvimento fundamentais
(SOMMERVILLE, 2003):

Claretiano - Centro Universitário

 70 © Interface Humano-Computador

Fonte: SOMMERVILLE, 2003, p. 38.

Figura 1 Modelo em "cascata".

Agora, descreveremos cada etapa do modelo em "cascata", segundo Sommerville, 2003:

Análise e definição de requisitos

A etapa de análise e definição de requisitos é considerada a principal, pois todas as etapas
posteriores seguem o resultado obtido nela, ou seja, os requisitos e o objetivo do sistema com
as suas restrições e funcionalidades. É possível levantar os requisitos por meio da análise dos
documentos existentes na empresa, do software legado, como também, por meio da consulta
aos usuários.

Projeto de sistemas e de software

Após a análise de todo o resultado obtido na etapa anterior, é elaborada uma arquitetura
do sistema geral agrupando os requisitos em sistemas de hardware ou de software. O objetivo
está em utilizar todas as informações coletadas na etapa anterior para definir uma arquitetura
que defina como será o modelo computacional.

Implementação e teste de unidades

No estágio de implementação e teste de unidades, inicia-se a implementação do sistema
considerando a arquitetura definida. Há a possibilidade de implementar as funcionalidades em
unidades de programa. Portanto, no final, há o teste de unidades em que cada unidade é testada
para validar se atende à sua especificação.
 © U4 – Modelos de Processo de Software e Prototipação 71

Integração e teste de sistemas

As unidades já testadas e validadas são integradas de modo a compor um sistema com-
pleto. Posteriormente, é realizado um teste em todo o sistema para garantir que os requisitos
de software foram atendidos. Depois dos testes, o software é entregue ao cliente.
Operação e manutenção
O sistema é instalado na máquina do cliente para iniciar a sua operação. Nesse momento,
é comum encontrar erros que não foram identificados anteriormente, por isso, há, nessa fase, a
manutenção que se preocupa em corrigir tais erros. Na manutenção, também há a possibilidade
de melhorar o sistema e/ou agregar novas funcionalidades a ele.

Desenvolvimento evolucionário
O desenvolvimento evolucionário tem como objetivo inicial desenvolver uma implemen-
tação do sistema e apresentá-la para o usuário, caso tenha a necessidade de alterar algo nessa
implementação, é feita a modificação e, novamente, é apresentada ao usuário, ou seja, há vá-
rias versões para se aprimorar o sistema até que ele fique adequado. Tudo o que é feito durante
o processo é documentado, como você pode observar na Figura 2.
A abordagem evolucionária do desenvolvimento de software, muitas vezes, é mais eficaz
do que a abordagem em "cascata", pois o cliente tem contato direto com parte do sistema e
consegue observar e analisar se há algo errado ou que poderia ser mudado.
Outra característica positiva é que a especificação pode ser desenvolvida gradativamente,
pois, à medida que os usuários desenvolvem uma compreensão melhor de seus problemas, isso
pode ser refletido no sistema. Contudo, segundo Sommerville (2003), há três problemas, que
serão descritos a seguir:

Fonte: SOMMERVILLE, 2003, p. 39.

Figura 2 Desenvolvimento evolucionário.

1) O processo não é visível: os gerentes necessitam que o desenvolvimento seja regular

para que possam medir o seu progresso. Se os sistemas são desenvolvidos rapidamen-
te, não é viável produzir documentos que reflitam cada versão dele.

Claretiano - Centro Universitário

 72 © Interface Humano-Computador

2) Os sistemas, frequentemente, são mal estruturados: a mudança constante tende a

corromper a estrutura do software. Incorporar modificações no software é cada vez
mais difícil e oneroso.
3) As ferramentas e técnicas especiais podem ser exigidas: elas possibilitam o rápido
desenvolvimento, mas podem ser incompatíveis com outras ferramentas ou técnicas,
e poucas pessoas podem ter a habilitação necessária para utilizá-las.

Desenvolvimento incremental
Nesse tipo de desenvolvimento, os clientes estabelecem as partes do sistema com priori-
dade e o desenvolvimento inicia-se por essas partes. Após estabelecer as prioridades, é definida
uma série de estágios de entrega, com cada estágio, fornecendo um subconjunto das funciona-
lidades do sistema, conforme demonstrado na Figura 3.

Figura 3 Desenvolvimento incremental.

A alocação de funções aos estágios depende da prioridade da função. Dessa forma, o

cliente tem acesso às partes mais importantes antes. Como é gastado um tempo significativo
para testar, após a conclusão de uma parte do sistema, ele poderá ser colocado em operação.
Isso significa que o cliente recebe com antecedência parte da funcionalidade do sistema, ou
seja, ele pode experimentar o sistema, o que facilita uma melhor compreensão dos requisitos
da parte que está em desenvolvimento e das partes posteriores.
Dentre as vantagens desse tipo de desenvolvimento, duas serão citadas (SOMMERVILLE,
2003):
1) O cliente não precisa receber todo o sistema para poder aproveitá-lo. O primeiro está-
gio satisfaz seus requisitos importantes e, assim, o software pode ser imediatamente
utilizado.
2) Há um risco menor de fracasso completo do sistema, ou seja, mesmo que possam ser
encontrados problemas em algumas partes, é provável que outras sejam entregues
com sucesso ao cliente.
Esse tipo de desenvolvimento também possui algumas desvantagens, as principais estão
relacionadas à definição de um tamanho fixo das partes. Se falarmos de linhas de código, não
podem ser mais do que 20 mil linhas, e cada parte deve produzir alguma funcionalidade. Devido
a esta regra, há a dificuldade de mapear os requisitos dos clientes dentro de partes tão peque-
nas.
 © U4 – Modelos de Processo de Software e Prototipação 73

Desenvolvimento em espiral
O modelo de desenvolvimento em espiral, como o próprio nome diz, é representado por
um espiral ao invés de representar o processo de software como uma sequência de atividades
com algum retorno de uma atividade para outra, como você pode observar na Figura Cada loop
na espiral representa uma fase do processo de software. Assim, o loop mais interno pode estar
relacionado à viabilidade do sistema; o loop seguinte, à definição de requisitos do sistema; o
próximo loop, ao projeto do sistema e assim por diante.

Fonte: SOMMERVILLE, 2003, p. 45.

Figura 4 Desenvolvimento em espiral

Cada loop da espiral é dividido em quatro setores (SOMMERVILLE, 2003):

Definição de objetivos
A principal tarefa desse setor é definir os objetivos para essa fase do projeto. Consideran-
do os objetivos, são identificadas as restrições para o processo e o produto. Com base nessas
informações é preparado um plano de gerenciamento detalhado que inclui todos os possíveis
riscos do projeto.
Avaliação e redução de riscos
Para cada um dos riscos identificado no setor anterior é necessário realizar uma análise
detalhada com o objetivo de identificar estratégias para reduzi-lo ou evitá-lo. Por exemplo, se
houver um risco de os requisitos serem inadequados, poderá ser desenvolvido um protótipo,
afinal, por meio dele o projetista poderá apresentar ao cliente a sua ideia para receber críticas,
sugestões, enfim refinar o que foi coletado.

Claretiano - Centro Universitário

 74 © Interface Humano-Computador

Desenvolvimento e validação
Após a avaliação dos riscos e estratégias definidas, é escolhido um modelo de desenvolvi-
mento para o sistema. Por exemplo, pode ser utilizado o modelo em cascata, o modelo evolu-
cionário etc. Não há a necessidade de utilizar o mesmo modelo em todos os loops, uma vez que
se deve escolher o melhor modelo para cada objetivo.
Planejamento
No setor de planejamento, o projeto todo é analisado para verificar o que foi realizado
e planejar quais serão os próximos passos para continuar com o loop da espiral ou finalizar o
sistema, caso ele estiver completo. Se a decisão for continuar, serão traçados os planos para a
próxima fase do projeto.
Além da sua representação em espiral, esse modelo distingue-se dos outros por se preo-
cupar com os riscos, ou seja, com algo que pode acontecer de errado.
Como você deve ter observado, todos os modelos apresentados até aqui estão direcio-
nados em investigar os requisitos do sistema, analisar todas as informações obtidas por meio
dessa investigação para projetar, implementar e testar o sistema. No entanto, pouco comenta-se
sobre a maneira com que se deve conversar com o cliente e quais são os passos que devem ser
realizados para facilitar essa comunicação, com o intuito de permitir a obtenção de informações
sobre as características dos usuários, as suas necessidade e outros dados.
É por esse motivo que alguns pesquisadores dizem que a Engenharia de Software (ES),
área em que esses modelos foram desenvolvidos, enfatiza o software e não as pessoas que o
irão utilizar, pois a ênfase é nos requisitos do sistema e não nas características dos usuários.
Contudo, a Interação Humano-Computador tem como principal característica preocupar-se com
os usuários e observar quais são as suas características físicas e cognitivas que poderiam ser
utilizadas no sistema.
Assim, sempre que alguém for desenvolver um sistema, é preciso unir essas duas áreas
importantes para construir um sistema computacional com qualidade. Nesse contexto, a técni-
ca Projeto Centrado no Usuário será descrita em detalhes a seguir, para você ter uma visão de
como é possível conhecer e coletar as informações a respeito do usuário.

Informação! –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Muitas dúvidas estão relacionadas à ordem de aplicação dos modelos (ES) e das técnicas (IHC). Qual deverá ser
aplicado primeiro? Devemos nos preocupar, antes, com o sistema ou com o usuário?
A resposta é que devemos aplicar, ao mesmo tempo, um modelo e uma técnica, pois, unindo essas duas áreas, será
possível investigar os requisitos do software e, ao mesmo tempo, observar as dificuldades e as características dos
usuários. As duas áreas devem ser aplicadas em todo o desenvolvimento, pois, assim, quando chegar ao final, será
possível testar o software de acordo com ES e IHC.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

6. PROJETO CENTRADO NO USUÁRIO (UCD – USER-CENTERED DESIGN)

O Projeto Centrado no Usuário tem como principal característica pensar no usuário e em
todo o seu processo de desenvolvimento, ou seja, leva em consideração que o usuário está no
centro das decisões, por isso, na maioria das vezes existe a participação dele em todo o processo
de software.
Vale ressaltar que não podemos confundir ter o usuário participando do desenvolvimento,
com querer que ele saiba todos os problemas e soluções, afinal, como descreve Nielsen (2010a)
 © U4 – Modelos de Processo de Software e Prototipação 75

"os usuários não são projetistas, e projetistas não são usuários". Nesse contexto, também temos
outra preocupação, por exemplo, quando o usuário está envolvido com suas atividades há mui-
tos anos e, praticamente, realiza suas atividades de modo "automático", ou seja, sem a neces-
sidade de pensar muito devido à sua prática, ele tende a abstrair muito todas as atividades que
ele realiza. Por isso é muito comum ouvirmos "gostaria de automatizar o controle de estoque"
ou "estou com um problema no controle" etc. Informações genéricas que, para os projetistas,
são importantes, mas não tão significativas, pois é preciso entender como é feito o controle de
estoque, quais são os passos, quais são as atividades mais e menos importantes, quais são as
dificuldades, qual processo é mais simples ou complexo etc.
Outro erro é perguntar diretamente aos usuários o que eles querem, observe que, muitas
vezes, eles estão com um problema e percebem, por meio de conversa entre amigos ou por notí-
cias, que a tecnologia pode ajudar em suas atividades, mas eles não são projetistas e, na maioria
das vezes, não conhecem a tecnologia e todo o seu potencial. Por isso, evitar essa pergunta é
importante, afinal, é você que tem o conhecimento da tecnologia, mas, para saber a melhor
maneira de utilizá-la, vai precisar entender o usuário e os seus problemas.
No Projeto Centrado no Usuário, há a preocupação com a colaboração entre o projetista
e o usuário, uma vez que os dois possuem conhecimentos que devem ser compartilhados, en-
tretanto, o projetista não precisa explicar sobre a linguagem de programação. Por meio dessa
colaboração, o projetista pode entender a experiência do usuário em suas atividades, as infor-
mações com que ele trabalha e, com isso, planejar como será o sistema.
Assim como IHC, que estudamos na primeira unidade, o UCD também abrange várias áre-
as, dentre elas a IHC e sua preocupação em entender as características físicas e psicocognitivas
dos usuários, os fatores humanos etc. e outras áreas, como a Engenharia de Usabilidade, que se
preocupa em entender os objetivos dos usuários, desenvolver interfaces para eles etc. (WILLIA-
MS, 2009).
Assim como nos Modelos de Processos de Software, o UCD também possui algumas eta-
pas para auxiliar o projetista nesse contato com o usuário, com o intuito de permitir melhor
entrosamento, compreensão e colaboração entre eles.
O UCD está dividido em três etapas, a primeira, chamada de Design Research, está relacio-
nada a entender os usuários e suas necessidades; a segunda, denominada de Design, tem como
objetivo projetar a interface e todos os outros elementos do software que fazem parte da inte-
ração humano-computador; e a última, Design Evaluation, permite testar o que foi planejado e
desenvolvido com o usuário. Agora, detalharemos cada uma das etapas (WILLIAMS, 2009).

Design Research
Essa primeira etapa é subdividida em alguns passos que serão descritos a seguir:

Planning
Nesse primeiro passo, que é o planejamento, identifica-se o objetivo, as restrições e as
suposições do projeto, bem como, define-se quem são os stakeholders, ou seja, as pessoas en-
volvidas. Observe que esse passo tem importância significativa para a continuidade do proces-
so, pois precisamos conhecer os objetivos, as restrições e as suposições para sabermos o que
vamos planejar. Lembre-se de que essas informações são obtidas e observadas com os usuários,
por isso há necessidade de se definir quem são as pessoas envolvidas.

Claretiano - Centro Universitário

 76 © Interface Humano-Computador

Em uma empresa, há várias pessoas, com diversos cargos e especialidades, e você precisa
saber quem são as pessoas importantes. Neste caso, as pessoas não são apenas os usuários
finais dos sistemas (empregados), mas, sim, os donos da empresa ou outras pessoas que podem
não usar diretamente o sistema, porém estão totalmente ligadas com o problema a ser solucio-
nado e os objetivos da utilização da tecnologia na empresa.
Definir os stakeholders também é importante para conduzir o projeto até o final, pois, nos
próximos passos, você perceberá que conhecer as pessoas envolvidas permitirá a você conver-
sar e mostrar resultados de acordo com a característica e necessidade de cada um, afinal, uma
pessoa de marketing tem objetivos e um olhar diferente de uma pessoa da área financeira.
Enquanto uma está preocupada em apresentar e vender o produto, a outra está preocupada
em contabilizar tudo o que está acontecendo, sendo assim, a conversa e a forma de exibir os
resultados para cada uma será completamente diferente.
Conducting
O segundo passo está voltado a conduzir a investigação na empresa, conhecer as ativida-
des das pessoas e como elas realizam essas tarefas. Há várias técnicas para se conhecer o usu-
ário, entretanto, para apresentar uma técnica muito comum, é necessário que você saiba que,
antes de conversar diretamente com o usuário, você precisa conhecer um pouco da empresa,
da linguagem que é utilizada entre as pessoas, como também, permitir que elas te conheçam
um pouco, pois isso permitirá que vocês se entrosem, de forma que elas tenham liberdade para
falar dos problemas, do que elas gostam ou não, sem a preocupação de serem avaliadas.
Algo comum que pessoas sentem nas empresas ou em qualquer outro estabelecimento
é o medo de serem avaliadas. A maioria delas pensam que se "falarem mal" de algum processo
ou atividade o chefe ficará sabendo e, consequentemente, ela poderá ser demitida, por isso,
muitas pessoas não gostam de conversar, de falar dos problemas etc. Em contrapartida, se a
pessoas te conhecem e confiam em você, elas saberão que está na empresa para ajudá-las,
para entender o que está acontecendo, quais são as dificuldades e as facilidades do processo, e
que todas essas informações são importantes para aprimorar e facilitar as tarefas que elas estão
realizando.
Assim, antes de tudo, conheça as pessoas, converse com elas, tomem um cafezinho, afi-
nal, um ambiente descontraído pode ajudar muito nesse momento. Essa estratégia é chamada
de background research, ou seja, uma pesquisa para conhecer as pessoas não precisa de forma-
lidade, pode ser algo descontraído, porém sério e com um objetivo definido.
Uma técnica muito comum e que já foi citada anteriormente é a entrevista, pois, por meio
dela, é possível ter contato com as pessoas, perguntar e/ou observar a forma com que elas rea-
lizam alguma atividade etc. Lembre-se de que há vários tipos de pesquisas, cada uma com uma
abordagem diferente, por exemplo:
• Face-to-face interviews:
Com a face-to-face interwiews, ou entrevista presencial, você pode conversar com a pes-
soa, fazer perguntas, ouvir suas respostas "face a face", ou seja, não precisa de outros recursos,
como o papel, por exemplo, para que a pessoa responda nele, sem contar que, há, ainda, a
possibilidade de gravar a entrevista, desde que você tenha a permissão. O interessante dessa
pesquisa é que, ao contrário do que acontece quando respondem no papel, as perguntas podem
sofrer alterações dependendo das respostas, pois, por meio, delas você pode ter interesse em
conhecer mais detalhes de um determinado assunto e/ou atividade, porém, da mesma forma
que acontece quando é no papel, é necessário um planejamento, ou seja, um conjunto de per-
guntas pré-estabelecidas.
 © U4 – Modelos de Processo de Software e Prototipação 77

• Close–and open-questions:
Close-and open-questions é uma entrevista, que, geralmente, acontece com o auxílio do
papel, por meio de um questionário. Você define algumas perguntas, que podem ser objetivas
ou dissertativas, para que as pessoas respondam, embora haja a limitação de não poder adaptar
as próximas perguntas de acordo com as respostas, essa estratégia é muito utilizada quando
há a necessidade de se entrevistar uma quantidade grande de pessoas, como, por exemplo,
todas as pessoas de um determinado setor. Se você for entrevistar uma por uma, precisará de
tempo e dinheiro, porém, muitas vezes, não se tem esses recursos suficientes. Por isso, quando
é necessário entrevistar várias pessoas, alguns projetistas costumam aplicar esse questionário
para obter uma média das respostas e, com base nelas, fazer um questionário face-to-face com
algumas pessoas, para saber mais detalhes ou esclarecer algo que ficou pendente.
• Remote interviews
Remote interviews, ou entrevista remota, ocorre quando você não tem a possibilidade de
um encontro presencial com a pessoa, então, a entrevista pode ser feita utilizando o telefone, a
internet ou qualquer outro meio que lhe permita ter contato com ela. Essa técnica é utilizada,
por exemplo, quando a pessoa que se deseja entrevistar está viajando para participar de uma
reunião de negócios.
• In-person interview.
Na entrevista do tipo in-person interview, você faz uma pergunta para a pessoa e ela res-
ponde fazendo uma determinada atividade, ao invés de responder com palavras (falando ou
escrevendo), ou seja, se você pergunta como é feito um determinado processo, ela explicará
realizando esse processo. Por meio dessa entrevista pode-se acompanhar todos os detalhes,
desde o comportamento do indivíduo até os objetos que ele utiliza.
Todas essas entrevistas são realizadas com os stakeholders, ou seja, as pessoas envolvidas
no processo e para cada pessoa será direcionada um tipo de pergunta, de acordo com sua fun-
ção e sua especialidade.
É importante descrever que, com a utilização dessa técnica, você conhecerá a pessoa,
suas atividades, a maneira que ela pensa, entre outras características para ajudá-lo a planejar
e a desenvolver o sistema. Contudo, há um problema muito comum entre os projetistas. No
momento em que você conhece as atividades, seu primeiro pensamento será aproveitar todo o
processo manual e aplicar no computacional, mas tome cuidado, não desenvolva o sistema para
ser meramente uma reprodução das atividades que as pessoas realizam manualmente. Toda
essa estratégia ajudará você a conhecer as capacidades e a forma com que as pessoas desempe-
nham uma atividade, porém o computador tem um potencial muito grande para facilitar a vida
das pessoas (KEINONEN, 2008).

Importante:––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Pense sempre na palavra "mapear" e não na palavra "copiar", ou seja, não copie o que o usuário fez no manual para
o computacional, mas mapeie a atividade que ele fez, pois assim, se o computador puder facilitar um determinado
processo, ou mudar a forma com que algo é feito para ajudar o usuário, será ótimo. Não se limite ao que você vê ou
ouve, compreenda e use todas as informações da melhor forma possível.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Analyzing
O terceiro passo, chamado analyzing, consiste em analisar todos os dados coletados nos
passos anteriores, com a utilização de várias técnicas descritas na literatura como análise quan-
titativa e/ou qualitativa (WILLIAMS, 2009). Você deverá organizar todas as informações, decidir

Claretiano - Centro Universitário

 78 © Interface Humano-Computador

quais são as prioridades, o que deve ser feito, o que precisa ser mudado, suas propostas, enfim,
todas as informações necessárias para, depois, conversar com as pessoas.
Reporting
Esse passo, o reporting, é justamente a conversa com as pessoas sobre tudo o que você co-
letou e sua análise sobre as informações. Você pode fazer uma apresentação e/ou escrever um
relatório com os principais dados. Uma dica para facilitar essa conversa é considerar o stakehol-
der, ou seja, se você for conversar com alguém da administração, planeje e faça algo utilizando
uma linguagem própria e assuntos que vão interessar às pessoas dessa área, e assim por diante.
Você já sabe quais são as necessidades e a linguagem que deve ser utilizada para cada área, por
causa dos passos anteriores, então, utilize essas informações para que as pessoas compreen-
dam e se interessem pelo que você vai falar.

Design
O Design é a segunda etapa do Projeto Centrado no Usuário. Nessa etapa, ocorre a conso-
lidação de todas as informações obtidas até esse momento. Tal consolidação pode ser realizada
por meio dos primeiros desenhos da interface. Esses desenhos são feitos de acordo com as in-
formações obtida e pelas conversas feitas durante esta etapa.
Há várias formas de fazer esse primeiro esboço, uma delas é apresentada no próximo tó-
pico, chamada Prototipação, uma estratégia usada para desenhar a interface, pensar como será
a interação entre o sistema e o usuário, definir a navegação etc.

Design Evaluation
Design evaluation é a terceira e última etapa do Projeto Centrado no Usuário. Essa etapa
será a avaliação de tudo o que foi investigado, feito e representado por meio do Design. Ela
pode ser feita com auxílio do usuário, pois, assim, no final da avaliação, você terá a certeza de
que tudo aquilo que foi planejado e realizado está de acordo com as necessidades e as carac-
terísticas do usuário. Se o indivíduo entender o design e conseguir trabalhar com ele, mesmo
por intermédio de protótipos, a possibilidade de interagir com a ferramenta computacional será
bem maior, ou seja, a certeza de construir um sistema com qualidade é elevada.
Vale a pena ressaltar que há maneiras de avaliar o Design sem a ajuda do usuário, são
estratégias que, ao serem aplicadas, indicam se o usuário conseguirá utilizar o sistema de modo
eficaz ou não.
Algumas estratégias para realizar a avaliação são:
• Heurística.
• Questionário de satisfação.
• Percurso cognitivo.
• Revisão pelos usuários.
Há, também, várias outras estratégias para avaliar o sistema. Na Unidade 4, você conhe-
cerá algumas delas e a forma de aplicá-las para verificar a qualidade do sistema que está sendo
planejado.
Todas as etapas explicadas anteriormente ajudarão você a entender quais são os momen-
tos propícios para conversar com as pessoas, quais são as estratégias que podem ser utilizadas,
tanto para coletar as informações a respeito do usuário, quanto para testar com ele o sistema.
 © U4 – Modelos de Processo de Software e Prototipação 79

Perceba que, apesar de parecer simples conversar com uma pessoa para explicar o que se
pretende fazer, quais serão as atividades etc., não é trivial, uma vez que você tem conhecimen-
tos e experiências diferentes. É comum acontecer de conversar com o cliente e, aparentemente,
ele entender tudo e dizer que gostou da proposta do sistema, das suas funcionalidades etc.,
mas, no momento em que você apresenta, de fato, o sistema, ele percebe que pensou bem
diferente do que realmente aconteceu.
Isso é algo comum de acontecer, pois, por mais detalhes que tentemos dizer durante al-
guma explicação, é difícil saber o que a outra pessoa está entendendo e imaginando, por isso,
a seguir, estudaremos uma estratégia, chamada de prototipação, que irá auxiliá-lo muito nessa
discussão, pois você terá um recurso concreto, simples e familiar para apresentar ao usuário.

7. PROTOTIPAÇÃO
A prototipação tem como finalidade demonstrar as ideias e as características de funcio-
namento do sistema por meio de desenhos, sejam eles "rabiscos" no papel ou interfaces bem
próximas do real, feitas com ferramentas que permitem esboçar a interface de uma maneira
semelhante ao sistema final.
O uso de protótipos possibilita mostrar a interface, o processo de interação com as fun-
cionalidades e os botões, de uma maneira fácil de se compreender. Por meio dessa informação
concreta o usuário poderá não apenas entender, mas também contribuir com segurança, ex-
pressando o que gostou ou não, quais são as funcionalidades fácies e eficazes de se utilizar etc.
Conforme Pressman (2002), a prototipação é uma estratégia utilizada tanto na área da
Engenharia de Software (ES) quanto na Interação Humano-Computador (IHC), porém para cada
uma há uma finalidade distinta em sua utilização. Na ES, a preocupação está na compreensão
dos requisitos do sistema, como ele será desenvolvido do ponto de vista tecnológico, se há to-
das as funcionalidades necessárias etc. Já na IHC a preocupação está relacionada com o modelo
de interação entre o usuário e o sistema, ou seja, quais tarefas serão realizadas por meio do
sistema, como elas serão apresentadas, se as opções existentes estão relacionadas com o ma-
peamento natural do usuário etc.
Essa estratégia também é muito utilizada no início do processo de desenvolvimento para
conversar com cliente, sendo que há várias formas de utilizá-la, você pode levar um desenho
pronto para ser discutido, ou pode, simplesmente, levar papel e lápis e, durante a conversa,
esboçar um desenho etc.

Classificações de Prototipação
São três os tipos de protótipos: baixa-fidelidade, média-fidelidade e alta-fidelidade. Como
você poderá observar na leitura das classificações que descreveremos a seguir, a principal dife-
rença entre eles, está no nível de fidelidade.

Baixa-Fidelidade
Protótipos que não são semelhantes ao sistema final, na maioria das vezes, são feitos com
auxílio do papel e lápis, como demonstrado na Figura 5, para esboçar as características iniciais
da interface e o seu funcionamento auxiliando na conversa entre o projetista e os usuários sobre
as características desejáveis e as soluções mais adequadas.

Claretiano - Centro Universitário

 80 © Interface Humano-Computador

Figura 5 Protótipo feito em papel, com canetinha.

Por causa do tipo de material utilizado para elaborar esses protótipos, eles são mais bara-
tos, rápidos e fáceis de fazer e, por meio deles, é possível coletar muitas informações a respeito
dos requisitos da interface. Algumas desvantagens estão relacionadas com a não utilização do
protótipo nas etapas posteriores, a verificação limitada de erros etc. (OLIVEIRA, 2004).

Média-fidelidade
Como você verá na Figura 6, o resultado desse tipo de prototipação é mais próximo do
sistema final, se comparado com a baixa--fidelidade. Geralmente, são feitos utilizando ferra-
mentas computacionais, embora não precisem ser as mesmas ferramentas que serão utiliza-
das para desenvolver a ferramenta final; permitem simular o comportamento de interação da
interface e não requerem um mesmo conhecimento técnico necessário para implementar a
interface final.
Há algumas ferramentas que podem ser utilizadas para desenvolver protótipos nesse nível
de fidelidade, algumas delas são: Smart Draw (Wireframe, 2010), Axure (Axure, 2010), Microsoft
Office Visio, entre outras.

Alta-fidelidade
Com esse tipo de protótipo é possível elaborar uma interface semelhante ao produto final,
Figura 7, pois, geralmente, são utilizadas as mesmas matérias (software e hardware) que serão
utilizadas no final, uma vez que são desenvolvidos diretamente em linguagem de programação,
permitindo apresentar alguns recursos da interface com a interação. Na prototipação de alta-
fidelidade já existe a implementação de algumas partes do sistema.
 © U4 – Modelos de Processo de Software e Prototipação 81

Devido a essas características, esse tipo de protótipo é considerado com um alto grau de
interatividade com os usuários e de realismo, pois é possível ver e interagir com uma interface
próxima à final. No entanto, há um custo maior no seu desenvolvimento e já é necessário um
conhecimento técnico semelhante àquele para desenvolver o produto final.
Dentre as três classificações de prototipação, esta unidade abordará detalhadamente a
primeira, a prototipação em papel. A princípio, a escolha dessa classificação pode parecer estra-
nha, pois, aparentemente, ela é a mais simples e quase sem recursos.
Na verdade, essa escolha é um pouco diferente daquilo que algumas pessoas pensam na
hora de apresentar um projeto, afinal, sempre queremos apresentar o melhor, então, porque
apresentar algo no papel feito com lápis ou caneta se podemos fazer um protótipo próximo ao
real com a interface bonita, navegação, entre tantas outras características que poderiam chamar
a atenção das pessoas com que estivéssemos conversando?
A resposta é tão simples quanto um ditado muito conhecido: menos, muitas vezes, é mais.
Observe que, apesar de parecer simples, não é trivial um usuário comum entender o raciocínio
de um programador ou projetista. Nesse caso, o desenho (protótipo) passa a ser uma linguagem
comum entre eles, pois quando se vê algo é muito mais fácil entender do que apenas ouvir e
tentar imaginar o que a outra pessoa está pensando.
Com o desenho a ideia fica mais "palpável" (fácil de entender) e o usuário, abstraindo me-
lhor, poderá contribuir e dizer se está gostando ou não. Nesse caso, o papel é um potencial a
mais, porque é uma ferramenta que todos dominam, tanto projetistas quanto usuários comuns. O
usuário pode manipular o papel, rabiscar e modificar de uma forma simples. Quando o protótipo
é feito com uma ferramenta computacional, mesmo que seja "mais bonito", cria-se uma barreira
entre o usuário e o projetista, pois a computação é algo mais distante dos usuários e eles não têm
tanto controle.
Outro cuidado que devemos ter com os protótipos feitos com auxílio do computador está
na hora de conversar com o usuário, pois, na maioria das vezes, mesmo explicando-lhe que é
apenas um protótipo, ele insiste em acreditar que o sistema está quase pronto, ou seja, que
aquilo que ele está vendo (interface, navegação entre telas etc.) já é o sistema pronto, e, então,
será fácil e rápida a entrega e os custos serão menores. Essa é uma situação muito comum, o
usuário sempre quer tudo muito rápido, pois ele cria uma expectativa ao ver algo pronto, bonito
e no computador.
Quando você for utilizar esses protótipos computacionais, também terá de se preocupar
em conhecer alguma linguagem para desenvolvê-lo, preparar o ambiente para apresentá-lo,
levar o computador etc., o que poderá deixar a conversa mais complicada, pois, antes, seriam
necessários apenas as pessoas, o papel e a caneta.
Com o protótipo em papel, o cliente consegue perceber de uma maneira fácil que tudo é
apenas uma ideia e que está sendo feito um esboço para entender melhor o que ele pensa, per-
mitindo que fique à vontade para expressar-se, dizer suas opiniões, ou seja, rabiscar, também,
o papel.

Prototipação em papel
O conceito de prototipação tornou-se comum na década de 1990, quando começou a ser
utilizado por algumas empresas como a IBM, Digital e a Microsoft como uma parte do processo
de desenvolvimento de produtos (SNYDER, 2003). No entanto, somente em 2002 houve o cres-
cimento do uso da prototipação, tanto nas empresas grandes, quanto nas pequenas.
Claretiano - Centro Universitário
 82 © Interface Humano-Computador

O uso da prototipação em papel

Se considerarmos o Projeto Centrado no Usuário, estudado anteriormente, um momento
propício de se utilizar a prototipação é na etapa do Design, momento em que você já conhece
quem são os usuários, quais são as possíveis funcionalidades e possui algumas informações para
auxiliá-lo a mapear o que acontece no real para o virtual. Com esses dados é possível esboçar
os primeiros desenhos, no entanto, não há uma etapa definida, pois não terá problema se, na
primeira conversa, alguém pegar um papel e desenhar o que as pessoas estão discutindo.
Snyder (2003) relata alguns passos que podem ser utilizados para criar, apresentar e testar
um protótipo, são eles:
• Definir os stakeholders (pessoas envolvidas) para elaborar as interfaces, conforme
apresentado na Figura

Figura 8 Preparando o laboratório para o teste.

• Escolher algumas das tarefas que o usuário realizará com apoio do sistema a ser proje-
tado.
• Realizar o esboço da interface, que poderá conter menus, páginas, caixas de diálogo,
mensagens e outras características para permitir ao usuário desempenhar as funções
na tarefa, como na Figura

Figura 9 Protótipo em papel com alguns campos.

 © U4 – Modelos de Processo de Software e Prototipação 83

Realizar testes de usabilidade com o protótipo

• Definir uma pessoa para representar os stakholders.
• Pedir para essa pessoa realizar uma determinada tarefa, utilizando o protótipo em pa-
pel – algo semelhante ao natural, pressionar o papel para simular um clique no botão,
preencher em um retângulo o nome para simular um cadastro etc., conforme o apre-
sentado pela Figura

Figura 10 Um usuário realizando alguns testes no protótipo.

• Um ou dois dos membros da equipe têm de desempenhar as funcionalidades do com-

putador, ou seja, se uma pessoa clica em um botão e a próxima tela está em um pró-
ximo papel, então o membro deve trocar as folhas para o usuário ter acesso à outra
interface do sistema, como se estivesse navegando.
• Um membro (experiente em usabilidade) deve conduzir o teste enquanto os outros
observam se há alguma dificuldade e como o usuário interage com o protótipo. Após a
realização desse teste é possível identificar em quais interfaces o usuário teve dificul-
dade, em quais momentos ele não soube como prosseguir etc.
Algumas empresas com prestígio no desenvolvimento de aplicativos web estão investindo
em protótipos em papel para explicar a todos as funcionalidades de seus sistemas. Um exemplo
de sucesso foi realizado pela empresa Google na explicação do Google Docs. Por meio de um
protótipo em papel, os funcionários da empresa conseguiram explicar, de uma maneira diverti-
da e didática, o funcionamento da ferramenta para todos os usuários da web. Algumas imagens
podem ser observadas nas Figuras 11 e

Figura 11 Protótipo em papel para explicar a ferramenta Google Docs.

Claretiano - Centro Universitário

 84 © Interface Humano-Computador

Figura 12 Funcionamento do Google Docs.

8. QUESTÕES AUTOAVALIATIVAS
Sugerimos que você procure responder, discutir e comentar as questões a seguir, que tra-
tam da temática desenvolvida nesta unidade, ou seja, da possibilidade do ensino da Interface
Humano-Computador.
A autoavaliação pode ser uma ferramenta importante para testar o seu desempenho. Se
você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos estu-
dados para sanar as suas dúvidas. Este é o momento ideal para que você faça uma revisão desta
unidade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocorre
de forma cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus
colegas.
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta
unidade:
1) De maneira geral, há a possibilidade de dizermos que existem três etapas para o desenvolvimento de um sof-
tware: a análise, o desenvolvimento e o teste. Para cada etapa, há um amadurecimento não apenas das funcio-
nalidades e das opções existentes na interface, mas também na compreensão das características dos usuários.
Durante as primeiras etapas, é possível aplicar uma estratégia chamada "prototipação" para facilitar a compre-
ensão tanto das características dos usuários quanto das funcionalidades do sistema. Considerando os conceitos
aprendidos nesta unidade, relacione, a seguir, as opções que indicam em que momento você utilizaria cada tipo
de prototipação.

( 1 ) Baixa-fidelidade ( ) Observar a forma com que o usuário

percebe a interface e refinar os requisitos.
( 2 ) Média-fidelidade ( ) Permitir ao usuário interagir com algo
próximo do sistema real para analisar as
dificuldades que podem ser encontradas.
( 3 ) Alta-fidelidade ( ) Conhecer o usuário e descobrir as fun-
cionalidades requeridas por ele, bem como
a forma com que elas podem ser apresen-
tadas.

2) Ao considerar o usuário o centro do desenvolvimento do sistema, é possível perceber melhor suas caracterís-
ticas e suas necessidades, para que o software seja realmente adequado. No entanto, conseguir a cooperação
do usuário nem sempre é uma tarefa trivial. Se você percebesse alguma resistência por parte do usuário em lhe
ajudar, o que consideraria a melhor opção para convencê-lo?
 © U4 – Modelos de Processo de Software e Prototipação 85
I) Conversar com o usuário de forma que ele possa entender a importância de sua participação no desenvolvi-
mento do sistema, uma vez que ele é um dos beneficiados com um software de qualidade.
II) Lembrar o usuário de que você é um contratado da empresa e de que uma de suas obrigações é ajudá-la
em todos os projetos nos quais se envolver – o desenvolvimento do software é um deles, portanto, é obrigado a
cooperar.
III) Acompanhar o usuário em seu ambiente de trabalho e tentar, em alguns momentos, abordá-lo de forma
amigável e questioná-lo sobre suas atividades na empresa, com o intuito de identificar algumas funcionalidades
no sistema e a forma com que ele trabalha.
a) A alternativa correta é I.
b) A alternativa correta é II.
c) A alternativa correta é III.
d) As alternativas corretas são I e II.
e) As alternativas corretas são I e III.

Gabarito
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:
1) Veja a sequência das respostas.
( 2 ) ( 3 ) ( 1 )

2) e.

9. CONSIDERAÇÕES
Apesar de não ser uma tarefa fácil preocupar-se com os usuários no desenvolvimento de
sistemas, é fundamental que exista essa preocupação. Há várias razões que justificam esse in-
vestimento de tempo e dinheiro.
Segundo Nielsen (1994), quando os usuários interagem com o sistema de forma satis-
fatória, eles se tornam leais a esse sistema ao ponto de fazer alguns investimentos, tais como
adquiri-lo e, depois, pagando pelas atualizações e modificações necessárias.
Os usuários tendem a valorizar mais os sistemas que possuem uma interface boa e utilizá-
vel, uma vez que a forma de se utilizar o sistema, em muitos casos, é mais importante do que a
quantidade de funcionalidades e recursos existentes nele, ou seja, há uma vantagem competiti-
va se comparado a sistemas em que não se considera a preocupação com o usuário.
Há, também, outra vantagem que, muitas vezes, só é percebida após a finalização e a en-
trega do sistema. Essa vantagem é a minimização dos custos posteriores. Os projetistas preocu-
pam-se mais com os custos que envolvem os processos de software durante o desenvolvimento
e com as características mais voltadas para o sistema, porém, é necessário pensar que se o
usuário não entender ou não o conseguir utilizar haverá um gasto maior com treinamento para
usar o software e até com modificações, mesmo após a entrega.
Pensar no usuário em todo o processo e testar exaustivamente o software para garantir a
qualidade é uma tarefa aparentemente árdua, mas é uma estratégia comprovadamente eficaz
para garantir um sistema aceitável e usável, por isso, na próxima unidade, você conhecerá algu-
mas formas de avaliar o sistema considerando as técnicas de IHC.

10. E-REFERÊNCIAS
AXURE. Wireframes. Disponível em: <http://www.axure.com/tourWireframe.aspx>. Acesso em: 5 fev. 2010.
NIELSEN, J. Bridging the Designer–User Gap. Disponível em: <http://www.useit.com/alertbox/designer-user-differences.html>.
Acesso em: 23 mar. 2010.

Claretiano - Centro Universitário

 86 © Interface Humano-Computador

WIREFRAME. SmartDraw – Create a wireframe or site map in minutes. Disponível em: <http://www.smartdraw.com/specials/
ppc/wireframe.htm?id=41822&gclid=COn63cH6z58CFYZx5QodJCj23A>. Acesso em: 5 fev. 2010.

Lista de figuras
Figura 3 – Desenvolvimento incremental: disponível em: <http://inf.unisul.br/~pacheco/princ_eng_sw/02_Artigo.pdf>. Acesso
em: 02 mar. 2010.
Figura 5 – Protótipo feito em papel, com canetinha: disponível em: <http://www.uxbooth.com/blog/tools-for-sketching-user-
experiences/>. Acesso em: 05 mar. 20
Figura 6 – Protótipo de média-fidelidade: disponível em: <http://usabilidoido.com.br/quanto_mais_simples_o_wireframe_
melhor.html>. Acesso em: 05 mar. 2010.
Figura 7 – Protótipo de alta-fidelidade: disponível em: <http://usabilidoido.com.br/quanto_mais_simples_o_wireframe_
melhor.html>. Acesso em: 05 mar. 2010.
Figura 8 – Preparando o laboratório para o teste: disponível em: <http://www.nngroup.com/reports/prototyping/video_stills.
html>. Acesso em: 1 jan. 2010.
Figura 9 – Protótipo em papel com alguns campos: disponível em: <http://www.nngroup.com/reports/prototyping/video_
stills.html>. Acesso em: 1 jan. 2010.
Figura 10 – Um usuário realizando alguns testes no protótipo: disponível em: <http://www.nngroup.com/reports/prototyping/
video_stills.html>. Acesso em: 1 jan. 2010.
Figura 11 – Protótipo em papel para explicar a ferramenta Google Docs: disponível em: <http://www.youtube.com/
watch?v=eRqUE6IHTEA>. Acesso em: 21 mar. 20
Figura 12 – Funcionamento do Google Docs: disponível em: <http://www.youtube.com/watch?v=eRqUE6IHTEA>. Acesso em:
21 mar. 2010.

11. REFERÊNCIAS BIBLIOGRÁFICAS

KEINONENM, T. User-centered design and fundamental need. Lund - Suécia. The 5th Nordi conference on Human-computer
interaction: building bridges, 2008.
NIELSEN, J. Heuristic Evaluation. In: NIELSEN, J; MACK, R. Usability Inspection Methods. John Wiley & Sons, 19p. 25-
OLIVEIRA, N. A. A. IHC: Modelagem e gerência de interfaces com o usuário. Florianópolis: Visual Books, 2004.
PRESSMAN, R. S. Engenharia de Software. USA: McGraw-Hill, ed. 2002.
SNYDER, C. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. San Francisco: Morgan Kaufmann, 20
SOMMERVILLE, I. Engenharia de Software. USA:Prentice-Hall, ed. 20
WILLIAMS, A. User-centered design, activity-centered design, and goal-directed design: A review of three methods for designing
web applications. Bloomington - EUA In: Special Interest Group on Design of Communication (SIGDOC), 2009.