Modelagem de Interfaces em IHC

Prévia do material em texto

INTERFACE 
HUMANO-
COMPUTADOR
Leonara de Medeiros Braz
Modelagem de interfaces
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Descrever modelos e técnicas de modelagem de interfaces em IHC.
  Discutir modelos de tarefas e modelos de interação.
  Ilustrar representações e modelos utilizados no design de interface 
com o usuário.
Introdução
A interface é o canal de comunicação entre o usuário e o sistema e, 
por isso, precisa ser bem estruturada para apresentar de forma clara e 
consistente o que o usuário pode (e como) realizar dentro do sistema. 
Porém, a especificação da estrutura da interface do sistema depende de 
outras características, como a especificação dos modelos de interação e 
das funcionalidades do sistema.
O processo de design é uma atividade intelectual e criativa de desen-
volver um sistema computacional a partir de especificações de neces-
sidades dos possíveis usuários do sistema. Assim, é preciso conhecer as 
técnicas específicas para uma boa coleta e para a análise das informações 
necessárias a fim de que essas informações apoiem o processo de pro-
posta do sistema computacional. 
Além disso, o produto deve ser apresentado ao usuário para que seja 
avaliado, de modo que erros possam ser corrigidos e o conhecimento 
do designer seja aprofundado. Dessa forma, o processo de design deve 
ser cíclico, passando por essas fases constantemente até que o produto 
seja aprovado e o processo tenha sido finalizado. 
Neste capítulo, portanto, considerando a importância da interface 
para o usuário dos sistemas, você vai conhecer modelos e técnicas de 
modelagem que existem e são utilizados para o oferecimento de sistemas 
de qualidade. Para isso, vai conhecer modelos de interfaces, modelos de 
tarefas e modelos de interação considerando a relação usuário/sistema.
1 Conceitos básicos
Para que a proposta de interface tenha qualidade e apresente as informações 
de forma estruturada, outros pontos devem ser considerados no momento 
do processo de design. A especificação do processo de interação apresenta 
ao designer como o usuário irá interagir com o sistema. Entretanto, para 
que o estilo de interação seja escolhido de forma precisa, é necessário 
compreender o domínio da aplicação: quem são os usuários, conhecimen-
tos, necessidades e até mesmo o local de utilização do sistema. Dessa 
forma, fica claro para o designer o que o sistema deve disponibilizar para 
o usuário, qual é a melhor forma de o usuário interagir com o sistema e 
como as informações devem estar disponibilizadas para facilitar o processo 
de interação.
Desse modo, o processo de design assume três etapas primordiais para 
que o sistema seja visto com qualidade: análise, síntese (ou intervenção) e 
avaliação. A análise consiste em compreender a situação atual, quem são 
as pessoas impactadas pelo problema, os processos atuais realizados, os 
artefatos utilizados e outras características que sejam importantes para a 
compreensão do problema e do contexto que será trabalhado. A síntese é 
uma atividade mais criativa; com base na análise do domínio e na situação 
atual, o designer propõe soluções que atendam as necessidades observadas. 
Como última fase, o resultado da síntese deve ser avaliado pelos usuários. A 
fase de avaliação é de extrema importância para que o designer compreenda 
se a proposta realmente atende as especificações do usuário e se existem 
problemas a serem corrigidos. 
Recomenda-se que o processo seja cíclico e que o produto apresentado 
na fase de síntese configure partes do produto (a concepção da ideia, um 
protótipo do sistema, uma funcionalidade), de modo que o designer não perca 
muito tempo construindo um sistema robusto que pode ser descartado poste-
riormente. A Figura 1 apresenta um modelo genérico do processo de design 
em IHC. Alguns processos de design apresentam a sequência que deve ser 
seguida durante a realização das atividades, mas, para Lawson (2006), o que 
realmente importa é partir de um problema, realizar o processo de design e, 
no final, chagar a uma solução.
Modelagem de interfaces2
Figura 1. Sequência genérica de desenvolvimento.
Fonte: Adaptada de Lawson (2006).
Técnicas para a modelagem de interface
Vale ressaltar que modelar a interação do sistema não signifi ca modelar a 
interface, mas, para que se tenha uma boa estruturação da interface, é impor-
tante ter modelado o processo de interação. “Modelando o comportamento 
do sistema pode-se compreender a interação deste com os atores externos e 
daí refl etir nos requisitos de interação, que acabarão por auxiliar na formação 
da arquitetura da interface do usuário” (GONÇALEZ; SANTORO; MONTE, 
2010, p. 5).
Dessa forma, para ter uma boa interface (etapa de síntese, na qual o design 
usa sua criatividade para propor uma solução ao problema enfrentado pelo 
usuário), é necessário passar pela fase de análise.
A fase de análise, em processo de design de sistemas computacionais, 
investiga três pontos cruciais: usuários; atividades realizadas e objetivos 
pretendidos; e contexto de uso (físico, cultural e social). Considerando esses 
pontos, as informações apresentadas e a estrutura da interface tendem a estar 
de acordo com as expectativas dos usuários, sendo mais efetivas e aceitas.
O usuário deve ser o “centro” de interesse do designer, que, portanto, deve 
seguir o processo de design centrado no usuário, buscando garantir que as 
expectativas dos usuários sejam atendidas por meio do sistema desenvolvido 
e considerando as características e necessidades do seu público-alvo (NOR-
MAN, 2013).
3Modelagem de interfaces
O design centrado no usuário (do inglês User-Centred Design) é um termo cunhado por 
Norman e Draper em 1986 e que se popularizou principalmente após a publicação 
do livro User-Centered System Design: New Perspectives on Human-Computer Interaction.
(NORMAN; DRAPER, 1986) Essa teoria coloca as necessidades dos usuários como o 
centro da tomada de decisão no processo de design.
Com a utilização do design centrado nos usuários, algumas técnicas para 
modelagem de interface podem ser utilizadas, como: modelagem de usuários 
do sistema e modelagem de cenário de interação.
Com a modelagem do usuário, busca-se entender para quem estamos 
construindo o sistema, respondendo perguntas como: quem são meus usuários? 
Quais são seus objetivos? O primeiro passo para que se faça um registro das 
características coletadas dos usuários é traçar o seu perfil. Segundo Barbosa 
e Silva (2010, p. 175) “em geral, um designer começa seu trabalho com uma 
ideia inicial de quem são seus usuários, mas essa ideia não costuma ser su-
ficientemente detalhada e pode até ser apenas uma impressão equivocada.” 
Dessa forma, esse processo deve ser iterativo, sendo aperfeiçoado com o tempo. 
Veja, a seguir, alguns dados que podem ser analisados nessa etapa do projeto.
  Papel: qual é o papel que o usuário vai desempenhar no sistema? Quais 
tarefas, primárias e secundárias, podem ser desempenhadas por ele? 
Dados pessoais também podem ser colhidos a fim de detalhar os dife-
rentes tipos de usuários (idade, sexo, etc.).
  Conhecimento do domínio: qual é o nível de conhecimento dos usuários 
com a utilização da aplicação? Existem diferentes níveis de usuários 
(especialistas e novatos)?
  Familiaridade com tecnologia: qual é o grau de familiaridade dos 
usuários com tecnologia (leigos, especialistas)? 
  Frequência de uso: com qual frequência os usuários utilizam a 
aplicação? 
Essas informações auxiliam o designer a compreender quem são seus 
usuários e as atividades realizadas. Com essas informações, o designer pode 
categorizar seus usuários, separando-os por grupo, de modo a “generalizar” as 
informações a respeito desses usuários. A essa generalização, damos o nome 
Modelagem de interfaces4
de persona. Uma persona é um personagem, uma pessoa fictícia que representa 
as características de um grupo de usuário. Geralmente, esses personagens 
são utilizadosdesde o início do processo de design, ajudando a equipe nas 
decisões a serem tomadas (BARBOSA; SILVA, 2010).
A utilização das personas durante o processo de desenho do sistema torna 
claros os objetivos dos usuários, ajudando o designer a compreender como 
estruturar as tarefas de modo a facilitar o entendimento sobre o que o sistema 
deve fazer. Cooper acredita que uma boa prática é tentar projetar o sistema 
para atender uma única persona em vez de tentar ampliar as funcionalidades 
de modo a acomodar a maioria das pessoas (COOPER; REIMANN; CRONIN, 
2007; COOPER, 1999). 
É importante ressaltar que uma persona não deve corresponder a uma 
pessoal real, apenas as características que elas recebem devem ser reais. 
Dessa forma, nome e detalhes pessoais são informações criadas, “dando 
vida” a esse personagem; os demais detalhes (habilidades, objetivos, tarefas, 
relacionamentos, etc.) devem ser derivados dos dados das coletas realizadas. 
Quanto maior o nível de detalhamento dessas informações, mais a persona 
auxiliará o designer. A Figura 2 apresenta um exemplo de persona; note que, 
além do nome e das características pessoais, a persona ganha uma imagem que 
a representa, tornando-se uma pessoa “concreta” e que faz parte do processo 
de design.
Figura 2. Exemplo de persona para sistema acadêmico.
Fonte: Barbosa e Silva (2010, p. 178).
5Modelagem de interfaces
Além das personas, outro método utilizado para modelar a interface é a 
criação de cenários de utilização, isto é, histórias contadas com a apresentação 
de detalhes e situações de uso e usuários envolvidos.
A criação de cenário conta com um enredo, apresentando: o que os usu-
ários fazem, o que acontece com eles e que mudanças ocorrem no ambiente 
(BARBOSA; SILVA, 2010). Segundo Rosson e Carroll (2002), os elementos 
necessários para a criação de um cenário são ambientes, atores, objetivos, 
planejamento, ações, eventos e avaliação. Os designers podem fazer perguntas 
mais específicas de cada elemento para aprofundar seu entendimento sobre 
as informações presentes no cenário.
Cooper (1999) ressalta que o cenário deve abordar os diferentes usuários, 
contemplando seus objetivos e habilidades; adicionalmente, os cenários devem 
abranger ao máximo o conjunto de funcionalidades que o sistema oferece. 
Porém, o designer deve ficar atento, pois a elaboração do cenário não deve 
consumir muito tempo no processo de design; para isso, deve-se elencar os 
principais pontos do sistema para a elaboração de cenários. A Figura 3 apresenta 
um exemplo de cenário de sistema.
Figura 3. Exemplo de cenário para sistema acadêmico.
Fonte: Barbosa e Silva (2010, p. 190).
Modelagem de interfaces6
2 Análise e modelagem de tarefa 
A análise de tarefas é realizada para que o designer compreenda quais são os 
objetivos e tarefas dos usuários. 
Em IHC, a análise de tarefas pode ser utilizada nas três atividades habituais: 
para análise da situação atual (apoiada ou não por um sistema computacio-
nal), para o (re)design de um sistema computacional ou para a avaliação do 
resultado de uma intervenção que inclua a introdução de um (novo) sistema 
computacional (BARBOSA; SILVA, 2010, p. 191).
Diversos métodos podem ser utilizados para realizar a análise de tarefas 
dos usuários. Um desses métodos é o Hierarchical Task Analysis (HTA, ou 
análise hierárquica de tarefas), que quebra a tarefa do usuário em subtarefas 
menores — e essas, por sua vez, são quebradas em sub-subtarefas). Essas 
subtarefas são agrupas em uma forma hierárquica, especificando como a 
tarefa é executada. As ações do usuário (relacionadas ao software ou não) são 
incluídas nessa lista de tarefas. Veja, a seguir, um exemplo de tarefas utilizando 
o método HTA. Com esse método, gráficos podem ser feitos para estruturar 
melhor os planos de ações para a realização das tarefas.
Pegar livro emprestado na biblioteca.
1. Ir até a biblioteca.
2. Encontrar o livro:
 ■ buscar o acervo da biblioteca;
 ■ adicionar os critérios de busca;
 ■ identificar se o livro apresentado é o correto;
 ■ anotar a localização do livro.
3. Ir até a estante em que o livro se encontra.
4. Autorizar a retirada do livro no balcão.
Outro método utilizado para a realização de análise de tarefa é o GOMS, 
que busca descrever uma tarefa analisando seus objetivos (Goals), opera-
dores (Operators), métodos (Methods) e regras de seleção (Selection rules). 
7Modelagem de interfaces
Existe um conjunto de modelos que segue o método GOMS conhecido como 
Família GOMS e que inclui, por exemplo: Keystroke-Level Model (KLM), 
CMN-GOMS e COM-GOMS (CARD; MORAN; NEWELL,1983; JOHN; 
GRAY, 1995).
Saiba mais sobre modelagem e tarefas acessando o link a seguir. 
https://qrgo.page.link/Tw6mz
Modelagem de tarefas
A partir das informações adquiridas nas fases de coletas de informações e aná-
lise de tarefas, o designer pode estruturar as tarefas que o usuário desempenha, 
traçando caminhos que devem ser percorridos para que o objetivo fi nal seja 
alcançado. Segundo Barbosa e Silva (2010), um design pautado na engenharia 
semiótica não leva em consideração apenas a sequência hierárquica da tarefa, 
mas também as interações realizadas e as tarefas alternativas. 
A nomenclatura utilizada para representar a tarefa é guiada por objetivo de 
alto nível, tarefas que são realizadas e operadores, que são operações atômicas 
(ações que são realizadas). A Figura 4 apresenta a estrutura de representação 
de cada elemento.
Figura 4. Representação gráfica dos elementos utilizados para modelagem de tarefa.
Fonte: Adaptada de Barbosa e Silva (2010).
Modelagem de interfaces8
As tarefas são modeladas em forma de estrutura hierárquica; desse modo, 
toda ação do usuário sobre o sistema ficará no último nível da “árvore” (re-
presentada por operadores). A tarefa não é uma ação em si, mas realizada de 
forma indireta por meio dos operadores associados a ela. Essas tarefas podem 
ser organizadas de diferentes formas; na Figura 5, Barbosa e Silva (2010) 
apresentam alguns dos vários modos de representação. 
Figura 5. Estruturas de tarefa: (a) sequencial, (b) independente de ordem, (c) alternativa, 
(d) iterativa, (e) ubíqua e (f) opcional.
Fonte: Barbosa e Silva (2010, p. 226).
  A estrutura em sequencial (a) é representada por uma numeração, 
mostrando a sequência de realização das ações (por exemplo, ir para o 
site, escolher o produto, realizar a compra). 
  A estrutura independente de ordem (b) é representada por números com 
sinal de interrogação, simbolizando que qualquer tarefa representada 
usando essa estrutura pode ser realizada a qualquer momento, sem 
necessariamente seguir uma ordem lógica (p. ex., o usuário pode realizar 
a compra e depois se cadastrar no site ou pode se cadastrar no site e 
depois realizar a compra).
  A estrutura alternativa (c) é representada por letras e o usuário deve 
escolher realizar uma tarefa ou outra (p. ex., filtrar um busca por preço 
ou por relevância).
9Modelagem de interfaces
  A estrutura iterativa (d) é representada por um asterisco e significa que a 
realização da sequência de atividades se dará repetidas vezes, enquanto 
for necessária a sua realização (p. ex., buscar produto e adicioná-lo no 
carrinho — o usuário faz isso quantas vezes quiser, até comprar todo 
o material que deseja).
  A estrutura ubíqua (e) é representada por um ponto preto e informa que 
aquela atividade pode ser realizada a qualquer momento, independente-
mente de ordem; por isso, ela geralmente fica abaixo do objetivo geral, 
representando que é independente das outras tarefas (p. ex., desistir de 
realizar a compra e sair do site).
  A representação opcional (f) representa uma tarefa que pode ser 
realizada pelo usuário, mas que não é obrigatória; assim, em um 
momento da interação, o usuário realiza essa tarefa e, em outro, 
pode escolher não realizá-la (p. ex., filtrar busca por faixa de preço 
até 1000 reais).
Cabe destacar, como afirmam Barbosa e Silva (2010), que, “Em geral, não 
modelamos as tarefasrelacionadas a todos os objetivos do sistema. A mode-
lagem de tarefas se destina principalmente a explorar tarefas com estruturas 
mais complexas” (BARBOSA; SILVA, 2010, p. 228).
3 Modelagem de interação
A modelagem da interação apresenta uma estrutura da conversa entre o sistema 
e o usuário. Nessa modelagem, elementos e ações de interface não devem 
ser representadas, contendo apenas ações (e troca de informações) entre o 
usuário e o sistema.
Paula (2003) desenvolveu uma linguagem para auxiliar no processo de 
modelagem da interação. A linguagem, denominada MoLIC (Modeling 
Language for Interaction as Conversation), representa a interação como 
uma conversa entre o designer (a partir do preposto do designer) e o usu-
ário. As informações sobre o que o sistema faz, o que ele permite e como 
ele age devem ser apresentadas de forma clara a partir dessa modelagem. 
“A MoLIC foi projetada de modo a ser não apenas uma notação para es-
pecificar a interação, mas também como uma ferramenta epistêmica, ou 
Modelagem de interfaces10
seja, para aumentar a compreensão dos designers sobre o problema sendo 
resolvido e o artefato sendo projetado” (BARBOSA; SILVA, 2010, p. 229).
Os elementos básicos para a criação de diagramas utilizando a linguagem 
MoLIC são cenas, transições e processos do sistema. A Figura 6 apresenta a 
representação desses elementos.
  Cenas: indica uma conversa (dentro da interface) sobre algum ponto 
que está sendo utilizado pelo usuário.
  Transições: falas que mudam a conversa, transitando entre uma cena 
e outra.
  Processos do sistema: momentos nos quais o sistema determina o 
próximo tópico da conversa.
Figura 6. Representação dos elementos do MoLIC.
A Figura 7 apresenta uma representação da utilização do MoLIC para 
modelar a interação do sistema e representa as ações que podem existir du-
rante a realização de uma transação bancária. Cada cena (retângulo) possui 
diálogos internos, que são informações que serão apresentadas aos usuários 
por meio da interface; esses diálogos podem ser solicitações de informações 
(“por favor, informe a conta de destino”) ou apresentação de informação 
(“Confira aqui os dados da conta. Eles estão corretos?”). As setas mostram 
a transição de uma cena para outra, representando a ação do usuário sobre 
o sistema (“Prosseguir: já inseri os dados necessários”). O quadrado preto 
representa o processamento, pelo sistema, dos dados enviados pelo usuário 
(“Opa! O usuário me enviou aqui os dados, deixa eu verificar se está tudo 
11Modelagem de interfaces
correto”). As bifurcações existentes representam alguns dos possíveis ce-
nários que podem acontecer: (1) conta inválida, (2) saldo insuficiente, (3) 
usuário percebeu um erro e deseja corrigir. Quanto maior a complexidade do 
sistema computacional, mais a representação vai aumentando e apresentando 
mais informações da “conversa” do sistema com o usuário.
Figura 7. Conversa utilizando o MoLIC para efetuação de uma transferência bancária.
Fonte: Barbosa e Silva (2014, p. 119).
Modelagem de interfaces12
4 Exemplo de modelagem
Considerando todos os modelos para representação da tarefa e da interação, você 
verá, a seguir, uma forma de utilizar as técnicas para o entendimento do problema.
Persona
José Fernandes tem 22 anos e é estudante de computação na universidade 
AprendaMais. José teve que se deslocar de sua cidade natal e mora com outros 
estudantes. Apesar de esforçado, José tem difi culdades para aprender certos 
conteúdos das disciplinas cursadas e, por isso, sempre que possível, aluga livros 
na biblioteca de sua faculdade. José também gosta de participar de grupos 
de estudo. A Figura 8 apresenta um infográfi co com as informações de José.
Figura 8. Dados da persona José Fernandes.
Cenário
O professor da disciplina de Interação Humano-Computador apresentou em 
sala um novo assunto: modelagem de interface. José, para não fi car atrasado 
no conteúdo, resolveu buscar o livro recomendado pelo professor na biblioteca, 
para estudar e resolver a atividade solicitada. Porém, José não sabe a locali-
zação do livro na biblioteca. Dessa forma, busca no acervo digital, inserindo 
as informações necessárias para encontrar o livro desejado.
13Modelagem de interfaces
Modelagem da tarefa
Existem duas possibilidades de ação, de modo que o plano de ação traçado 
pode variar. Por exemplo, no cenário apresentado, podemos ter dois planos 
de ação. A Figura 9 apresenta a estrutura hierárquica da tarefa.
  Plano 1 
 ■ Fazer:
 – 1. ir até a biblioteca;
 – 2. ir até a estante e pegar o livro;
 – 3. levar o livro para o balcão.
 ■ Se o livro não estiver na prateleira desejada:
 – 1. encontrar o livro;
 – 2. ir até a estante e pegar o livro;
 – 3. levar o livro para o balcão.
  Plano 2
 ■ Se não souber onde está o livro:
 – 1. acessar o acervo;
 – 2. identificar o livro;
 – 3. anotar a localização.
 ■ Se o livro não tiver identificação:
 – 1. acessar tela de busca;
 – 2. entrar com critérios de busca;
 – 3. identificar o livro desejado.
Figura 9. Modelagem de tarefa.
Modelagem de interfaces14
Modelagem de interação
A modelagem da interação apresenta a conversa entre usuário e sistema para 
a realização da atividade pretendida. A linguagem MoLIC apresenta uma 
estrutura para modelar essa conversa por meio de ações e transições entre essas 
ações no decorrer da interação. Na Figura 10, a representação da interação da 
tarefa de buscar um livro no acervo da biblioteca.
Figura 10. Modelagem de interação.
Para que haja a consulta do livro, o usuário precise informar os dados 
necessários exigidos pelo sistema (“Por favor, insira as informações do livro 
que você deseja buscar.”). Ao inserir as informações, o usuário prossegue 
15Modelagem de interfaces
com a realização da busca. O sistema computa as informações fornecidas e 
verifica se os dados são válidos ou não: se forem inválidos, uma mensagem de 
erro é retornada; se os dados forem válidos, o sistema redireciona o usuário 
para uma nova cena e um novo diálogo acontece.
A utilização dessas diferentes técnicas auxilia a equipe de design a com-
preender de forma mais detalhada quem são seus usuários, suas necessidades 
e as tarefas envolvidas. Com esse entendimento, a modelagem de interface 
fica mais efetiva, pois produzirá um material adequado às necessidades dos 
usuários.
BARBOSA, S. D. J.; SILVA, B. S. Design da interação humano-computador com MoLIC. In: 
IHC '14: Companion Proceedings of the 13th Brazilian Symposium on Human Factors 
in Computing Systems, 14., Foz do Iguaçu, Brazil, 2014. Proceedings [...]. Porto Alegre: 
Sociedade Brasileira de Computação, 2014. p. 79–80.
BARBOSA, S. D. J.; SILVA, B. S. Interação humano-computador. Rio de Janeiro: Elsevier, 2010.
CARD, S. K.; MORAN, T. P.; NEWELL, A. The psychology of human-computer interaction. 
New Jersey: Lawrence Erlbaum Associates, 1983.
COOPER, A. The inmates are running the asylum: why high-tech products drive us crazy 
and how to restore the sanity. Indianapolis: Sams, 1999. 
COOPER, A.; REIMANN, R.; CRONIN, D. About Face 3: the essentials of interaction design. 
New York: John Wiley & Sons, 2007.
GONÇALEZ, M. A. D.; SANTORO, F. M.; MONTE, L. C. M. Modelando interfaces de usuários 
utilizando um processo ágil. Relatórios Técnicos do Departamento de Informática 
Aplicada da UNIRIO n° 0003/2010. Rio de Janeiro: Universidade Federal do Estado do 
Rio de Janeiro, 2010.
JOHN, B. E.; GRAY, W. D. CPM-GOMS: an analysis method for tasks with parallel acti-
vities. In: CHI '95 CONFERENCE COMPANION: MOSAIC OF CREATIVITY, 1995. Denver, 
Colorado, USA, May 7-11, 1995. Proceedings [...]. New York: Association for Computing 
Machinery, 1995. p. 393–394
LAWSON, B. How designers think: the design process demysti�ed. 4. ed. Oxford: Ar-
chitectural Press, 2006.
Modelagem de interfaces16
Os links para sites da Web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
redeé extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
NORMAN, D. A.; DRAPER, S. W. User centered system design: new perspectives on human-
-computer interaction. New Jersey: Lawrence Erlbaum Associates, 1986.
NORMAN, D. The design of everyday things: revised and expanded edition. Philadelphia: 
Basic Books, 2013.
PAULA, M. G. Projeto da interação humano-computador baseado em modelos funda-
mentados na engenharia semiótica: construção de um modelo de interação. 2003. 87 
f. Dissertação (Mestrado) – Pontifícia Universidade Católica do Rio de Janeiro, 2003.
ROSSON, M. B.; CARROLL, J. M. Usability engineering: scenario-based development of 
human-computer interaction. San Francisco: Morgan Kaufmann, 2002.
17Modelagem de interfaces
INTERFACE 
HUMANO-
COMPUTADOR 
Leonara de Medeiros Braz
Storyboarding e 
prototipação de interfaces
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Descrever métodos e técnicas de construção de interfaces.
  Demonstrar a narrativa gráfica ou storyboarding.
  Distinguir os tipos de protótipos de interfaces.
Introdução
Não é de hoje que estamos cercados pela tecnologia, que, dia após dia, 
ganha ainda mais espaço na nossa vida e na realização de nossas ativi-
dades. Seja em telas de computadores, celulares ou objetos com poder 
de processamento, como os sistemas vestíveis, o ser humano está cada 
vez mais utilizando tecnologia.
Diante desse cenário, o design de interface deve ser cuidadosamente 
planejado para que ofereça soluções amigáveis e intuitivas para seus 
usuários. A atividade de design de interface envolve a prática do plane-
jamento e desenvolvimento de sistemas computacionais com o foco na 
boa experiência do usuário. Para isso, técnicas podem ser utilizadas para 
facilitar o processo de escolha feito pela equipe de design. 
Neste capítulo, você vai conhecer as principais técnicas, e sua im-
portância, para a construção de interfaces. Para isso, verá mais a fundo 
a narrativa gráfica, mais conhecida como storyboarding, e diferentes 
protótipos de interfaces.
1 Técnicas para a construção de interfaces
O processo de design em interação homem-computador (IHC) tem três fases 
fundamentais para a concepção de uma boa solução computacional: análise, 
síntese e avaliação. Porém, o esforço do designer deve ir além da compreen-
são sobre os usuários, suas tarefas e suas necessidades: deve estudar como 
estruturar as informações necessárias (de forma técnica e estética) para que 
o sistema seja funcional, tenha boa usabilidade e traga boa experiência para 
o usuário durante o uso do sistema.
Um dos grandes problemas enfrentados na construção de sistemas compu-
tacionais é a não compreensão do que realmente deve ser feito, muitas vezes 
devido às rupturas comunicativas entre usuário e designer. Esse problema de 
comunicação frequentemente se dá pelo fato de que o designer não compreende 
o domínio da aplicação — nomenclatura utilizada, contexto e tarefas realizadas 
— e porque o usuário não consegue transmitir de forma clara suas intenções. 
Em sua pesquisa, Braz (2017) percebeu a necessidade de uma melhor 
compreensão sobre o domínio da aplicação (ambiente escolar e ambiente 
educacional especializado — AEE), seus usuários (professores e alunos com 
deficiência) e o ambiente de utilização (sala de aula e salas multifuncionais). 
Para uma melhor compreensão sobre essas informações, técnicas foram utili-
zadas para auxiliar no processo de conhecimento e captação de informações.
As técnicas disponíveis na literatura servem como ferramentas poderosas para 
diminuir o esforço do designer na captura e no entendimento de informações, 
tendo como objetivo ser de baixo custo e baixo esforço de desenvolvimento.
Vale ressaltar que as diferentes técnicas disponíveis podem ser utilizadas em 
diferentes momentos no processo de design, apoiando tanto designers quanto 
usuários na estruturação do que deve ser o sistema computacional. O Quadro 
1 apresenta um conjunto de atividades que podem ser realizadas durante as 
várias fases do processo de desenvolvimento e que podem ser aplicadas tanto 
pela equipe do projeto quanto em conjunto com os clientes/usuários.
Pré-design Design Avaliação Pós-design
Clarificação/
requisitos
Inicial/iterativo Testes
Customização/
redesign
Storytelling HOOTD CISP Buttons Project
Picture Card BrainDraw Icon Design Game Priority Workshop
Group Elicitation … … …
Quadro 1. Diferentes técnicas para auxílio da construção do sistema computacional 
durante as fases do processo
Storyboarding e prototipação de interfaces2
Cada técnica, com suas características, apresenta um modo diferente (e 
complementar) de coletar informações dos usuários para que haja um bom 
entendimento do que deve — e como deve — ser estruturado na interface 
do sistema.
Storytelling
O storytelling se refere à contação de história como processo de compreensão 
do contexto do projeto. Porém, não se trata apenas de contar uma história 
— essa história precisa ser relevante para o entendimento do sistema, e 
essas narrativas são importantes para entender como o design da interface 
apoiará o usuário.
Dentro da prática de storytelling, existem várias técnicas que podem ser 
utilizadas, sempre com o mesmo objetivo: contar uma narrativa que exem-
plifique um cenário de uso.
Em uma dessas técnicas, cada participante deve contar duas histórias sobre 
o sistema: uma positiva e outra negativa, geralmente com cards vermelhos 
e verdes. Após a contação, cada participante compartilha as histórias cria-
das e todos observam os contrastes e semelhanças. Essa técnica tem como 
resultados o reconhecimento das dificuldades, o conhecimento de caracte-
rísticas e dificuldades da população de usuários e a coesão aumentada entre 
os participantes. Por isso, pode ser utilizada com os usuários, que trarão as 
dificuldades enfrentadas por eles no cenário investigado, de modo que a 
equipe terá uma compreensão mais aprofundada sobre o usuário e sobre o 
que ele deseja. Quando essa prática traz a participação do usuário, aumenta 
também a sua compreensão sobre o seu problema, compreendendo a solução e 
as limitações enfrentadas para a concepção do sistema, o que pode contribuir 
para a aceitação do produto quando ele estiver desenvolvido.
Outra técnica é a jornada de usuário, que traz uma narrativa do objetivo 
maior do usuário, das ações e dos passos dos usuários, apresentando os sen-
timentos e expectativas do usuário sobre o produto que será desenvolvido. 
Geralmente, essa técnica é realizada pela equipe de design, não tendo a partici-
pação do usuário. Com a utilização dessa técnica, o designer busca visualizar 
as oportunidades de aperfeiçoamento do sistema. A Figura 1 traz um exemplo 
de uma especificação de jornada de usuário.
3Storyboarding e prototipação de interfaces
Figura 1. Exemplo de jornada do usuário.
Fonte: Ribeiro (2018, documento on-line).
Picture card
Nesta técnica, são utilizados cartões com imagens e legendas que ilustram 
tarefas ou cenários da vida cotidiana (se necessário, a equipe de design pode 
fazer uso de cartões mais específi cos, focando em uma tarefa). Essa técnica 
é utilizada juntamente com usuários para conhecimento de seus hábitos, 
experiências, tendências e comportamentos.
Na realização da atividade planejada, utilizando esse método, ao partici-
pante pode ser solicitado que relembre um evento, situação, tarefa ou história, 
agrupando os cartões em grupos. O uso de cartões com figuras em um contexto 
de grupo ajuda o diálogo e permite várias interpretações.
Brainstorming
Esta técnica busca gerar ideias e alternativas para o projeto. Geralmente, é 
utilizada com a participação do usuário, na fase de análise do projeto, para a 
compreensão do que é deve ser atendido pelo sistema. No entanto, a técnicaé 
versátil e pode ser utilizada nas diferentes fases do processo, defi nindo como 
deve ser a estrutura da interface (fase de síntese) e determinando causas e 
soluções de problemas (fase de avaliação).
Storyboarding e prototipação de interfaces4
As atividades de brainstorming são realizadas em grupo, encorajando 
o compartilhamento de ideias e a participação de todos os envolvidos. Um 
moderador deve guiar a seção, dando oportunidade para que todos apresentem 
suas ideias, sem julgamento e sem limite. Nesse momento, o que vale é a 
quantidade de ideias apresentadas, não sua qualidade. Dessa forma, encoraja-
-se que os participantes não tenham vergonha de expor suas ideias, por mais 
“bobas” que elas possam parecer.
Após a coleta de toas as ideias, a equipe se reúne para discutir analisando 
cada proposta e priorizando as mais importantes. Desse modo, ao final da seção, 
tem-se como resultado uma lista das principais funcionalidades (requisitos) 
que o sistema deve apresentar ordenadas por relevância/prioridade.
Uma técnica semelhante, BrainDraw, pode ser utilizada para analisar 
como o usuário estrutura as informações de forma visual. Como o nome já 
indica (brain significa cérebro e draw, desenho), os usuários apresentam suas 
ideias em forma de desenho, estruturando as funcionalidades como forma de 
interface. Com essa técnica, busca-se entender como o usuário visualiza a 
solução computacional.
Geralmente essa técnica é utilizada na fase de síntese, quando já existe um 
conhecimento das funcionalidades a serem desenvolvidas; com essa técnica, 
a equipe de design busca soluções para possíveis organizações da estrutura 
do sistema. Após o término dos desenhos, todos os participantes apresentam 
a solução desenhada e priorizam os elementos e estruturas que façam sentido 
para o projeto.
Essa fase também é muito eficaz para promover a compreensão e aumentar 
a coesão entre usuários e designers, de modo que todos tenham o mesmo 
entendimento sobre o sistema a ser desenvolvido.
Existem diversas outras técnicas de design que podem ser utilizadas ao longo das fases 
de desenvolvimento do sistema computacional. Cabe à equipe escolher quais técnicas 
atendem os objetivos e necessidades da equipe. Para conhecer novos métodos de 
design, acesse o link a seguir.
https://qrgo.page.link/HsjRG
5Storyboarding e prototipação de interfaces
2 Storyboards
O storyboard busca representar uma história, contando-a de forma gráfi ca 
por meio de uma sequência de imagens em que cada uma representa um 
momento no tempo. Essa técnica é utilizada desde a década de 1920 pelos 
estúdios Walt Disney.
A técnica de storyboard é amplamente utilizada na área de design e design 
visual, na produção de desenhos animados, televisão e vídeos (HART, 1998). 
O uso do storyboard possibilita a visualização de todo o contexto do cenário 
antes mesmo de construí-lo. Esse recurso funciona como um mapa que, acom-
panhado de informações adicionais, traz orientações à equipe. 
Mas como essa técnica se aplica ao design de interfaces computacionais? 
No design de UX (user experience), os storyboards podem ser utilizados para 
descrever o produto, facilitando a sua compreensão; por exemplo, cada bloco 
ilustrado representa um estado da interface em um momento da interação.
Trata-se de um documento extremamente visual e que descreve em deta-
lhes todas as funcionalidades do produto. Ao dividir uma história em pedaços 
lineares, permite-se que o autor se concentre em cada célula separadamente, 
sem distração. Para Truong, Hayes e Abowd (2006), “os storyboards ge-
ralmente ilustram um cenário previsto de como um recurso de aplicativo 
funciona”.
Para que o sistema computacional apresente uma estrutura coerente, é 
necessário que o designer compreenda os mínimos detalhes relacionados ao 
processo de interação do usuário com o sistema. Dessa forma, os storyboards 
(Figura 2) possibilitam esse detalhamento e mapeamento do fluxo de inte-
ração, mostrando como as ações realizadas pelos usuários sobre a interface 
encadeiam eventos no sistema.
Durante a fase de análise do desenvolvimento de software, os designers 
estudam as práticas atuais das partes interessadas e realizam estudos de 
campo para gerar cenários de problemas. Durante a fase de design, os 
designers usam cenários de atividades para introduzir ideias concretas 
sobre como os requisitos do usuário podem ser atendidos por meio de 
funcionalidades de alto nível introduzidas por um novo sistema que afetará 
inerentemente as atividades atuais do usuário. Em seguida, os designers 
criam cenários de design de informações, que especificam representações 
dos objetos e ações de uma tarefa que ajudarão os usuários a perceber, 
interpretar e entender as funcionalidades propostas. Por fim, os cenários 
de design de interação especificam como os usuários interagem com o 
sistema para executar as novas atividades (TRUONG; HAYES; ABOWD, 
2006, p. 12).
Storyboarding e prototipação de interfaces6
Figura 2. Storyboard de Alice no país das maravilhas.
Fonte: Rivas (2016, documento on-line). 
O uso do storyboard no processo de design traz como vantagem a de-
monstração visual do produto, tanto sob a perspectiva do usuário quanto para 
o entendimento da equipe de design sobre a tecnologia a ser criada. Dessa 
forma, a utilização dessa técnica “abre os olhos” do designer para novos 
cenários de investigação.
Para Nick Babich (2017), o uso storyboard para contar uma história é uma 
poderosa ferramenta para captura de informação, pois:
  histórias são mais memorizáveis do que lista de planos;
  histórias captam a atenção do usuário, criando um maior engajamento;
  produz-se maior empatia: cria-se personagens que possuem vida, his-
tória, contexto.
 Considerando o ditado popular segundo o qual “uma imagem vale por 
mil palavras”, concluímos que as ilustrações ajudam no entendimento da 
ideia apresentada.
Jake Knapp (2013), designer do Google Ventures, apresentou oito passos 
que são utilizados durante as sprints de seus projetos para a criação de um 
bom storyboard; confira-os a seguir. 
7Storyboarding e prototipação de interfaces
1. Escolher parte do problema: se a história for muito grande, é melhor 
dividi-la em histórias menores.
2. Tomar notas: é preciso identificar suas considerações e impressões 
sobre o problema.
3. Mapa mental: juntamente com as notas que se tomou, deve-se adicionar 
suas ideias e organizá-las em um papel.
4. “Oito malucos”: cada membro da equipe deve ter uma folha em branco 
com oito painéis vazios. Em cinco minutos, todos da equipe devem 
desenhar oito sketches (um em cada painel). O principal objetivo dessa 
fase é apresentar uma variedade de ideias de forma rápido. Nesse passo, 
ainda não é necessário preocupar-se com beleza — considerando que 
o tempo disponível é curto, o designer deve se preocupar mais com a 
ideia do que com o estilo.
5. Storyboard: deve-se começar com um papel em branco e desenhar três 
notas, em que cada uma represente um frame do storyboard. Para isso, 
é possível utilizar as atividades passadas como auxílio no processo 
criativo. Esses três frames são utilizados para apresentar progresso — 
primeiro isso, depois aquilo e depois aquilo outro. Uma boa prática é 
deixa-lo anônimo, ou seja, não identificar quem criou cada storyboard.
6. Crítica silenciosa: de forma silenciosa, todos devem analisar os story-
boards produzidos e colocar notas em cada ideia que gostar (não há 
limites de uso das notas).
7. Três minutos de crítica: analisando os storyboards, um por vez, os 
participantes falam o que eles gostaram da proposta apresentada e 
pede-se ao autor do desenho para explicar sua ideia. Essa atividade 
deve respeitar o tempo de três minutos por storyboard.
8. Supervoto: cada membro pode votar na ideia que mais se agradou. 
O supervoto ajuda a refletir sobre as decisões. 
Após a realização desses passos, é preciso repeti-los. Essas técnicas devem 
ser seguidas de forma iterativa, realizando os passos quantas vezes foremnecessárias. Ao observar que as decisões foram tomadas e não são necessárias 
reformulações, passa-se a um novo problema. A Figura 3 apresenta a realização 
de algumas das atividades descritas por Knapp (2013), como a escolha de parte 
do problema que será abordado pelo time (a), o mapa mental construído após 
as considerações individuais de cada membro (b), as oito telas desenhadas, 
Storyboarding e prototipação de interfaces8
apresentando a ideia de solução do problema (c), a criação do storyboard (d) e 
a fase de crítica, em qye cada membro apresenta o que gostou e o que poderia 
ser melhorado nas propostas apresentadas (e).
Figura 3. Técnicas para criação de storyboards.
Fonte: Adaptada de Knapp (2013).
9Storyboarding e prototipação de interfaces
Os storyboards podem ter vários níveis de abstração e, segundo Greenberg 
et al. (2011), podem ser abstratos, podem ter uma interface visual, anotações, 
indexar ações realizadas ou apresentar um layout. A Figura 4 apresenta uma 
representação desses níveis de abstração.
Figura 4. Representação dos diferentes tipos de storyboards.
Fonte: Adaptada de Greenberg et al. (2011).
3 Tipos de protótipos
Uma das poucas certezas que existem no desenvolvimento de sistemas compu-
tacionais é que os requisitos mudam. Para não perder tempo do projeto desen-
volvendo uma versão do sistema para confi rmação com o usuário, utilizamos 
protótipos para a representação da interface. Dessa forma, representamos as 
informações necessárias e apresentamos aos usuários, de modo a observar se 
estamos seguindo o caminho correto.
O design das interfaces pode ser realizado em diferentes níveis de abstração, 
desde a representação informal, por meio de esboços (como os storyboards), 
passando por representações estruturadas e até mesmo representações de alto 
nível, fiéis ao produto final.
Storyboarding e prototipação de interfaces10
A essas representações estruturadas e de alto nível, damos o nome de 
protótipo. A ideia inicial é que a equipe de desenvolvimento inicie o processo 
de criação apresentando esboços da solução proposta e, ao longo do processo 
de desenvolvimento, vá criando novos e melhores protótipos.
De acordo com McElroy (2016), a utilização de protótipos e a sua validação 
por usuários reais (em vez da equipe de desenvolvimento) é o melhor caminho 
para criar uma solução que tenha impacto na vida do usuário final: “Existem 
muitas razões para criar protótipos e incluí-los cedo e frequentemente em seu 
processo: entender, testar e melhorar, comunicar e advogar. Cada um deles é 
semelhante, mas tem uma reviravolta única na qual os protótipos são valiosos” 
(MCELROY, 2016, documento on-line).
  Para entender: o melhor modo de entender o problema é explorar 
novas ideias, e o protótipo é uma boa ferramenta para isso. Criar uma 
variedade de alternativas auxilia o designer a entender o caminho 
que o sistema vai percorrer. Ademais, o protótipo auxilia a criar uma 
concordância de entendimento e ideias sobre o que é o sistema e como 
será a sua solução.
  Para testar e melhorar: esse é o principal objetivo da utilização dos 
protótipos. Cada pedaço da sua solução pode ser prototipada e, assim, 
ser testada pelos usuários do sistema, levando à aprovação do modelo 
de solução proposto ou à apresentação dos problemas que devem ser 
corrigidos e modificados para as próximas versões.
  Para comunicar: os protótipos auxiliam na comunicação entre a equipe 
de design e os usuários. Compreender uma ideia que é apresentada de 
forma gráfica (ou até mesmo fisicamente) é muito mais fácil do que 
analisar uma lista de requisitos que foram coletados. Por exemplo, os 
diferentes integrantes da equipe podem imaginar, a seu modo, a solução 
proposta, dificultando o alinhamento entre todas as ideias que surgirem.
  Para defender: a criação de protótipo auxilia a “defesa” da solução 
apresentada, e os testes com usuários retornam valores importantes e 
apresentam uma direção a ser seguida.
Os protótipos podem ser classificados pelo seu grau de fidelidade: na hora 
da criação do protótipo, o tipo de objetivo é o principal fator que define o seu 
nível de fidelidade, ou seja, saber quem vai usar uma simulação define como 
ela deve ser desenvolvida.
11Storyboarding e prototipação de interfaces
Protótipos de baixa fidelidade são rascunhos ou esboços da interface, sem 
preocupação com detalhes dos aspectos gráficos; podem ser feitos manual-
mente ou por computador. Alguns exemplos de ferramentas computacionais 
que auxiliam o designer na criação de protótipos de baixa fidelidade são 
Balsamiq, MockFlow, Mockingbird, Draw.io, Moqups. A Figura 5, a seguir, 
exemplifica um protótipo de baixa fidelidade feito à mão.
Figura 5. Protótipo em pape criado em minutos.
Fonte: Adaptada de Travis (2010).
Esse tipo de protótipo não se parece com o produto final, embora seja mais 
barato e fácil de fazer. O principal objetivo de se usar protótipos de baixa 
fidelidade é que sua produção é rápida e auxilia na avaliação pelo usuário, 
encontrando problemas como arquitetura da informação, navegação, fluxo 
de interação, etc. 
A ideia é utilizar esse tipo de protótipo no início do processo de design, 
quando a equipe ainda está maturando a ideia e entendendo o problema. 
Por ser barato, pode ser facilmente descartado e refeito, sem grandes custos 
orçamentais e de tempo.
Storyboarding e prototipação de interfaces12
Protótipos de média fidelidade já começam a ser mais parecidos com o 
produto final, trazendo uma visibilidade gráfica melhor. Com o aumento do 
grau de fidelidade do protótipo, aumenta também o esforço e o custo para a 
sua concepção. Dessa forma, esses protótipos são indicados para um estágio 
mais avançado no processo de design, e o seu objetivo é testar pontos mais 
específicos da solução, focando no teste da interação do usuário com o sistema. 
Exemplos são protótipos clicáveis, ou até mesmo protótipos codificados, em 
seu estado inicial. A Figura 6 apresenta um exemplo de protótipo de média 
fidelidade.
Figura 6. Protótipo de média fidelidade, apresentando mais detalhes.
Fonte: McElroy (2016, documento on-line).
Os protótipos de alta fidelidade representam fielmente a aplicação desenvol-
vida e apresentam as decisões de tamanho, posições, cores, fontes, etc. Nesse 
momento, no processo de design, a maioria das questões foram testadas nos 
protótipos anteriores; dessa forma, os protótipos funcionais são usados para 
testar pequenos detalhes, como legibilidade, tamanho da fonte e experiência 
do usuário. Devido ao seu grau de fidelidade, esses protótipos têm alto grau 
de esforço e custo de desenvolvimento. A Figura 7 apresenta uma evolução 
dos protótipos desenvolvidos para uma aplicação.
13Storyboarding e prototipação de interfaces
Figura 7. Diferentes tipos de protótipos.
Fonte: Dantas (2018, documento on-line). 
O designer deve ter cuidado com a escolha do protótipo durante o processo 
de criação, pois “O nível de fidelidade que você escolher para um protótipo 
afetará o tipo de feedback que você recebe dos usuários nos testes” (MCELROY, 
2016, documento on-line). A Figura 8 exemplifica a variação de fidelidade que 
o protótipo pode atender. Cabe ao designer responsável equilibrar a que nível 
pertence seu protótipo para atender o seu objetivo; quanto mais próximo desses 
limites de fidelidade, maior é a diferença entre as vantagens e desvantagens 
de sua utilização.
Figura 8. Diferentes graus de fidelidade do protótipo.
Fonte: Adaptada de Dantas (2018). 
Storyboarding e prototipação de interfaces14
McElroy (2016) apresenta uma comparação entre os prós e contras de cada 
nível de protótipo utilizado, indicando a visão e o comportamento do usuário ao 
utilizar essas aplicações. No Quadro 2, você confere a comparação realizada.
Fonte: Adaptado de McElroy (2016).
Baixa 
fidelidade
Média 
fidelidade
Alta 
fidelidade
Prós
Rápido, sem 
necessidade 
de muito 
conhecimento, 
barato, feito com 
materiais próximos.
Mais interativo, 
fácil de testar,bom equilíbrio 
entre tempo 
e qualidade.
Design completo, 
incluindo visual, 
conteúdo e 
interação; pode 
testar os detalhes 
da interação.
Contras
Limitações na 
interação, difícil 
testar detalhes e 
fluxos de navegação, 
apresenta pouco 
contexto para 
os usuários.
Mais demorado, 
mas não 
totalmente 
funcional.
Muito mais 
demorado, requer 
habilidades de 
software ou 
codificação, difícil de 
testar componentes 
grandes.
Uso
Exploram e testam 
conceitos de 
alto nível, como 
a arquitetura da 
informação; é o 
melhor para fazer 
várias versões 
diferentes e testar 
uma contra a outra.
Usuários testam 
interações 
específicas; é 
melhor para os 
stakeholders, 
pois apresenta 
mais contexto.
Usuários testam 
interações bastante 
específicas de 
forma detalhada, 
teste final de fluxo 
de interação e 
apresenta o design 
final para as partes 
envolvidas.
Quadro 2. Prós e contras dos diferentes níveis de fidelidade dos protótipos
A escolha do grau de fidelidade do protótipo deve estar de acordo com o 
objetivo da equipe de design. Quando se está no início do projeto, é interessante 
apresentar um protótipo de baixa fidelidade, pois a estrutura do sistema pode 
mudar; com isso, a equipe de design não desenvolverá um sistema (gastando 
tempo e orçamento) que será modificado. Quando se tem um maior conheci-
mento da estrutura do sistema, o nível de fidelidade dos protótipos aumenta, 
atendendo as novas necessidades até que o sistema seja aprovado pelo usuário.
15Storyboarding e prototipação de interfaces
BABICH, N. Storyboarding in UX Design. 2017. Disponível em: https://medium.com/@
mauri.ribeiro/o-stoytelling-e-a-import%C3%A2ncia-para-a-narrativa-dentro-do-design-
-f407b0d6c677. Acesso em: 2 fev. 2020.
BRAZ, L. M. Design para todos e educação inclusiva: envolvendo professores na criação 
de tecnologias. 2017. Dissertação (Mestrado em Ciência da Computação) — Instituto 
de Computação, Universidade Estadual de Campinas, Campinas, 2017. Disponível em: 
https://www.unicamp.br/unicamp/teses/2017/11/22/design-para-todos-e-educacao-
inclusiva-envolvendo-professores-na-criacao-de. Acesso em: 2 fev. 2020.
DANTAS, A. Um rápido estudo de prototipagem. 2018. Disponível em: https://brasil.
uxdesign.cc/uma-r%C3%A1pido-estudo-de-prototipagem-81a1b300471b. Acesso 
em: 2 fev. 2020.
DESIGN PRACTICE METHODS. 2020. Disponível em: http://www.designpracticemethods.
rmit.edu.au/. Acesso em: 2 fev. 2020.
GREENBERG, S. et al. Sketching User Experiences: The Workbook. Burlington: Morgan 
Kaufmann Publishers Inc., 2011. 
HART, J. The Art of the Storyboard: Storyboarding for Film, TV, and Animation. Massa-
chusetts: Focal Press: 1998.
KNAPP, J. The 8 steps to creating a great storyboard. 2013. Disponível em: https://www.
fastcompany.com/1672917/the-8-steps-to-creating-a-great-storyboard. Acesso em: 
2 fev. 2020.
MCELROY, K. Prototyping for physical and digital products. 2016. Disponível em: https://
www.oreilly.com/ideas/prototyping-physical-digital-products. Acesso em: 2 fev. 2020.
RIBEIRO, M. O Storytelling e a importância para a narrativa dentro do design. 2018. Dispo-
nível em: https://medium.com/@mauri.ribeiro/o-stoytelling-e-a-import%C3%A2ncia-
-para-a-narrativa-dentro-do-design-f407b0d6c677. Acesso em: 2 fev. 2020.
RIVAS, N. Storyboard. 2016. Disponível em: https://designculture.com.br/storyboard. 
Acesso em: 2 fev. 2020.
TRAVIS, D. 7 myths about paper prototyping. 2010. Disponível em: https://www.userfocus.
co.uk/articles/paperprototyping.html. Acesso em: 2 fev. 2020.
TRUONG, K. N.; HAYES, G. R.; ABOWD, G. D. Storyboarding: An Empirical Determination 
of Best Practices and Effective Guidelines. In: Proceedings of the 6th Conference on 
Designing Interactive Systems, 6., 2006. Anais… New York: ACM, 2006. Disponível em: 
https://dl.acm.org/doi/10.1145/1142405.1142410. Acesso em: 2 fev. 2020.
Storyboarding e prototipação de interfaces16
Os links para sites da Web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
17Storyboarding e prototipação de interfaces
INTERFACE 
HUMANO-
COMPUTADOR
Leonara de Medeiros Braz
Ferramentas de apoio à 
construção de interfaces
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Identificar ferramentas para construção de mokups, wireframes e 
protótipos.
  Descrever ferramentas, bibliotecas e API para a implementação de 
interfaces de usuário.
  Aplicar ferramentas de avaliação automatizada em interfaces.
Introdução
A realização da avaliação se configura como a terceira parte fundamental 
no processo de desenvolvimento de sistemas computacionais. Porém, 
para uma maior efetividade, essas tarefas devem ser realizadas não apenas 
no final do ciclo de desenvolvimento, quando o sistema já está totalmente 
construído, mas ao longo do processo. 
No entanto, o desenvolvimento de sistemas funcionais tem um custo 
elevado e demanda muito tempo. Dessa forma, a utilização de técnicas 
para a construção parcial do sistema, tal como a arquitetura da infor-
mação, interfaces estáticas, interfaces dinâmicas, entre outras partes 
do sistema, auxilia a equipe de design a avaliar se a proposta de sistema 
está adequada às necessidades de seus usuários. Nesse sentido, várias 
ferramentas podem ser utilizadas para auxiliar na construção desses 
protótipos e em sua avaliação. 
Neste capítulo, portanto, você vai aprender sobre a importância da 
criação de storyboards e protótipos, tanto de baixa quanto de alta fide-
lidade. Além disso, vai conhecer algumas ferramentas que podem ser 
utilizadas para a criação de artefatos visuais e frameworks atuais que 
possibilitam ao desenvolvedor dar vida ao projeto desenhado, trans-
formando a solução visual em linhas de código. Por fim, vai conhecer 
algumas ferramentas para realizar a fase de avaliação do sistema com-
putacional, seguindo os critérios estabelecidos pela área de interação 
humano-computador: usabilidade, comunicabilidade, acessibilidade e 
experiência de usuário.
1 Ferramentas para a criação 
de artefatos visuais
O uso de esboços e rabiscos pode ser uma ótima ferramenta para a identifi -
cação das necessidades dos usuários em um primeiro momento. De acordo 
com McElroy (2016), os protótipos de baixa fi delidade são ótimos para uma 
avaliação inicial, pois sua construção é rápida e não exige conhecimentos 
avançados nem um orçamento elevado, pois é feita com materiais disponíveis 
no dia a dia.
No entanto, esses protótipos possuem limitações, pois uma baixa fide-
lidade pode confundir o usuário final no teste, gerando, assim, resultados 
incertos para análise. Além disso, podem surgir muitas dúvidas na hora de 
implementar a parte visual se não houver certas especificações. Dessa forma, 
outros protótipos, com níveis de fidelidades diferentes, devem ser utilizados 
para realizar a avaliação das propostas apresentadas.
Storyboards
Os storyboards buscam representar a história de forma pictórica, criando 
um cenário, de forma visual, para melhor entendimento de como a ação será 
realizada. Essa técnica é utilizada para a estruturação da produção de desenhos 
e fi lmes (HART, 1998), potencializando-se com as produtoras de vídeos e 
mostrando cenários, atores, ângulos e enquadramentos. 
Porém, os storyboards, devido a suas vantagens de utilização, estão sendo 
utilizados em vários outros setores de estudo, incluindo o desenvolvimento de 
sistemas centrado no usuário. Para Knapp (2013), os storyboards auxiliam a equipe 
de design na compreensão das ideias que estão sendo apresentadas pela equipe, 
de forma que todos tenham o mesmo entendimento do que está sendo proposto.
Os principais recursos utilizados para a criação de storyboardssão papel, 
lápis e caneta. Porém, existem ferramentas, gratuitas e pagas, que são uti-
lizadas para auxiliar esse processo. Alguns exemplos são: Photoshop, Toon 
Boom StoryBoard Pro, Storyboarder, Plot e Canva. As ferramentas Photoshop, 
Toon Boom StoryBoard Pro são ferramentas pagas, enquanto as demais são 
ferramentas gratuitas.
Ferramentas de apoio à construção de interfaces2
A ferramenta Photoshop é amplamente utilizada por profissionais de design, 
pois oferece um leque completo de funcionalidades; no entanto, é uma ferramenta 
que requer conhecimento avançado para a sua utilização. O Storyboard Pro é 
uma solução que busca combinar todas as necessidades do designer em uma 
ferramenta, apresentando funcionalidades de desenho, script, controle de câmera, 
recursos de criação de animações e som; como o Photoshop, é uma ferramenta 
voltada para profissionais, de modo que são necessárias habilidades específicas 
para sua utilização, que contém avançados controles de som e edição.
O Plot é uma ferramenta gratuita e on-line que busca oferecer suas fun-
cionalidades de forma simples e descomplicada. Seu lema é “Gaste seu tempo 
experimentando ideias, não lutando com software volumoso” (PLOT, 2020). 
Dessa forma, apresenta-se como uma ferramenta que não é tão poderosa e 
completa, mas permite a edição das telas de forma descomplicada, o que é 
interessante para uma primeira etapa do processo de desenvolvimento de 
sistemas. A Figura 1 apresenta a tela inicial da ferramenta — o painel de 
edição contém várias ferramentas para que o designer utilize sua criatividade.
Figura 1. Ferramentas do Plot.
Fonte: Adaptada de Plot (2020). 
A ferramenta Storyboarder é uma ferramenta desktop gratuita e de código 
aberto. Os criadores desenharam essa ferramenta por sentirem necessidade de 
funcionalidades que não encontravam nas que já existiam. Assim, foram incluí-
das todas as ferramentas que eram necessárias para um desenho rápido e foram 
removidas todas as outras não necessárias (WONDER UNIT, 2019). O usuário 
3Ferramentas de apoio à construção de interfaces
também pode importar os storyboards feitos em papel para a plataforma por meio 
de fotos — a ferramenta automaticamente importará os frames no projeto criado. 
Adicionalmente, o StoryBoarder possibilita uma edição mais avançada com 
o Photoshop; dessa forma, se o designer precisar de mais controle e detalhe, 
basta clicar no botão de edição que será redirecionado para o outro aplicativo. 
A ferramenta também possibilita exportar o arquivo para GIF, PDF, Final Cut 
e Premiere (ferramentas de edição de vídeo). A Figura 2 apresenta a página 
inicial da ferramenta.
Figura 2. Apresentação dos elementos disponíveis na ferramenta StoryBoarder.
Fonte: Adaptada de Wonder Unit (2019). 
Wireframes
Um wireframe representa o design do sistema em um grau de fi delidade bem 
baixo, mostrando os grupos de informações que devem aparecer no sistema e 
onde (a arquitetura) eles aparecem. Os wireframes podem ser vistos como um 
esqueleto do sistema — não apresentam cor, forma ou informações; seu principal 
objetivo é representar o sistema, contendo todas as suas partes importantes. 
A criação de wireframes deve ser feita de forma rápida e, por isso, não existe 
uma preocupação estética da interface do sistema e eles geralmente são desenhados 
em preto e branco. A escolha de ícones ou espaços reservados deve ser representada 
por um retângulo vazio com um x no meio, de modo que o designer não tome 
tempo escolhendo imagens representativas. Os wireframes são interessantes para 
a comunicação interna da equipe, permitindo que todos tenham um entendimento 
sobe a proposta apresentada e que o projeto seja bem documentado.
Ferramentas de apoio à construção de interfaces4
O Balsamiq (2020) é uma ferramenta que possibilita a criação de wirefra-
mes. Observe na Figura 3 que os elementos apresentados não são refinados 
ou bonitos, mas, simples, mostrando “como” as informações básicas serão 
apresentadas no sistema, “o que” será ou não inserido como informação e 
“onde” essas informações serão apresentadas.
Figura 3. Ferramenta Balsamiq.
Fonte: Balsamiq (2020, documento on-line).
Mockups
Os mockups são moldes ou representações em escala do sistema desenvolvido. 
Caracterizam-se por uma representação mais realista do que a dos storyboards 
e wireframes, aumentando um pouco mais o seu grau de fi delidade. Os mockups 
são utilizados para apresentar um estado do projeto (design proposto) antes 
que esteja pronto. 
Com a utilização de mockups, pode-se solicitar ao usuário que entenda 
melhor a estruturação do sistema e o design, pois, nesse momento, o designer 
pode apresentar formas, cores, tamanho, texturas e qualquer outro atributo 
importante para a validação do sistema (CRISTIAN, 2018). Adicionalmente, 
o uso de mockups auxilia o desenvolvedor a ter um melhor entendimento da 
proposta de solução.
A ideia principal da utilização de mockups é a validação da ideia do produto 
antes de produzi-lo. Trata-se de um meio-termo entre os wireframes — que 
possuem pouca informação visual e estética para ser apresentada ao usuário 
5Ferramentas de apoio à construção de interfaces
e, por isso, possuem uma maior resistência — e protótipos de alta fidelidade 
— que necessitam de mais tempo e recurso para sua criação. Dessa forma, os 
mockups apresentam mais informações sobre a arquitetura da interface (em 
comparação aos wireframes) e não consumem muito tempo e recurso para a 
sua criação (em comparação aos protótipos de alta fidelidade). Ademais, se 
mudanças forem solicitadas, é mais barata sua modificação com a utilização 
dos mockpus do que nos protótipos.
O Moqups (2020) é uma ferramenta que possibilita ao designer a criação, 
o teste e a validação de mockups detalhados de forma rápida. Ele suporta 
a evolução da aplicação, movendo-se de projetos de baixa fidelidade para 
alta fidelidade de acordo com a evolução do projeto. A Figura 4 apresenta a 
ferramenta Moqups com sua gama de funcionalidades.
Acesse o link a seguir, que apresenta um site com grande variedade de fontes de 
mockups, de forma grátis, para seus usuários.
https://qrgo.page.link/Qmb2H
Figura 4. Ferramenta Moqups.
Fonte: Moqups (2020, documento on-line).
Ferramentas de apoio à construção de interfaces6
Protótipos
Os protótipos são representações, de baixo a alto nível, da aplicação a ser 
desenvolvida. Eles servem para auxiliar a equipe de design a “aguçar” a 
criatividade e validar o entendimento do problema a ser solucionado. 
Os protótipos de alta fidelidade são criados em um momento mais “estável” 
do processo de desenvolvimento, quando a arquitetura e o design do sistema já 
estão mais avançados e definidos. Segundo McElroy (2016), eles são utilizados 
para testar a interação do sistema e seus detalhes.
A criação de protótipos funcionais exige um cuidado para que se pareça 
ao máximo com o sistema final. Outro fato importante é que o protótipo 
funcional, apesar de possibilitar a avaliação da interação, não possui back-
-end (parte funcional, que utiliza linguagem de programação), ou seja, essa 
independência reduz o custo e o tempo de desenvolvimento, pois, apesar de 
exigir mais tempo que as demais técnicas apresentadas, é muito mais rápida 
do que programar todo o sistema.
Algumas das ferramentas que auxiliam o designer na prototipação são: 
Justinmind, In Vision, Proto.io, Marvel e Adobe XD.
O Justinmind é uma ferramenta — que apresenta uma versão gratuita — 
para a prototipação de sistemas Web, mobile e desktop. O aplicativo possui 
painéis e eventos: os painéis possibilitam a inserção em tela dos diferentes 
elementos desejados, enquanto os eventos permitem informar as ações que 
devem ser realizadas ao interagir com os elementos.
A ferramenta In Vision, além de permitir a prototipagem do sistema, 
possibilita o compartilhamento, em tempo real, do projeto com os clientes, 
oferecendo um feedback mais rápido. Ademais, utiliza uma estrutura simples, 
possibilitando que os clientescompreendam as propostas apresentadas.
O Proto.io oferece a prototipação de aplicativos mobile e permite a proto-
tipação e o gerenciamento de animações utilizadas na aplicação. Além disso, 
possibilita que o designer atribua eventos aos elementos da interface para 
que a interação seja avaliada. O aplicativo Marvel é outra alternativa a todos 
esses aplicativos apresentados.
Já o Adobe XD é uma ferramenta da família Adobe que é recente, mas 
que se mostra muito eficaz para a prototipação de diferentes sistemas com-
putacionais, tais como websites, aplicações móveis, interfaces por voz, jogos 
e muito mais. A ferramenta também possibilita a criação colaborativa entre 
os membros da equipe, o compartilhamento com clientes e stakeholders e a 
reutilização de elementos em/de outros sistemas.
7Ferramentas de apoio à construção de interfaces
Implementação de interface 
Com o avançar do projeto, é importante que os artefatos criados evoluam 
para que novos conceitos sejam avaliados e novas informações possam ser 
coletadas. Dessa forma, a equipe de desenvolvimento avançará no projeto.
Além dos protótipos de alta fidelidade, é importante que a equipe inicie o 
processo de desenvolvimento do sistema utilizando ferramentas, bibliotecas 
e APIs (Application Programming Interface ou, em português, interface de 
programação de aplicativos) que os auxiliem nessa tarefa. 
Um API fornece um conjunto de padrões que devem ser seguidos, guiando 
a construção do aplicativo. Seu principal objetivo é disponibilizar recursos 
e detalhes de como o sistema deve ser implementado. Pode ser disponibili-
zado em diferentes formas, como plug-ins e frameworks. Os plug-ins são 
extensões que podem ser instaladas em programas maiores para adicionar 
novas funcionalidades ao sistema computacional, enquanto os frameworks 
são ferramentas que auxiliam o desenvolvedor a trabalhar com determinada 
linguagem de programação, contribuindo para a utilização de funcionalidades. 
Os frameworks apresentam uma estrutura definida, exigindo que o desenvol-
vedor apenas adapte ao seu programa; nesse caso, há diversos frameworks 
que podem ser utilizados.
Algumas linguagens de programação fornecem ferramentas que auxiliam 
o designer na construção das interfaces do sistema computacional. Podemos 
dividir o sistema em duas partes complementares: o front-end e o back-end. 
O front-end é como uma abstração do sistema, simplificando os componentes 
utilizados e apresentando de forma amigável, para o usuário, as informações de 
como a interação vai ocorrer. O back-end pode ser visto como a parte funcional 
do sistema, em que há processamento das informações apresentadas pelo 
usuário. O usuário não precisa ter ciência de como as informações inseridas 
por ele serão processadas; o que é necessário é entender o que o sistema está 
informando e o que é solicitado como entrada para que a interação seja efetiva.
Os frameworks front-end possibilitam o desenvolvimento de interfaces, 
fornecendo ferramentas que facilitam a tarefa de desenvolver a arquitetura das 
informações que serão passadas aos usuários por meio da interface do sistema. 
Alguns dos frameworks front-end utilizados pela comunidade de desenvolvi-
mento são: Pure, Material-UI, Semantic-UI, Materialize, Foundation e Bootstrap.
O Pure foi criado com o intuito de ser utilizado em qualquer projeto Web. 
Dessa forma, trabalha apenas com códigos que utilizam as linguagens HTML 
e CSS. O Pure é de fácil aprendizado, com aplicações leves e simples de serem 
compreendidas, principalmente por não utilizar a linguagem JavaScript. Em seu 
Ferramentas de apoio à construção de interfaces8
site, o Pure se apresenta como “ridiculamente pequeno” e também possibilita 
a criação de layouts responsivos, ou seja, que se adequam a qualquer tamanho 
de tela. Adicionalmente, possibilita ao designer adicionar novos códigos CSS, 
permitindo a personalização da aparência de acordo com o seu desejo.
O Material-UI utiliza o padrão Material Design desenvolvido pela Google, 
trazendo formas mais geométricas e coloridas aos aplicativos. Esse framework tem 
como base o framework React do JavaScript, que possui uma boa aceitação pela 
comunidade, trazendo um foco maior para a melhoria da experiência do usuário.
O Semantic-UI é um projeto livre e de código aberto que tem como diferen-
cial uma linguagem “compatível com humanos”, como o próprio site apresenta, 
utilizando uma sintaxe de linguagem natural, vinculando os conceitos de forma 
mais intuitiva. O framework oferece aos designers diferentes definições, como: 
elementos, coleções, visualizações, módulos e comportamentos que abrangem 
toda a gama de design de interface. A Figura 5, a seguir, apresenta alguns dos 
elementos disponíveis no framework Semantic-UI. 
Figura 5. Elementos oferecidos no framework Semantic-UI.
Fonte: Semantic-UI (2020, documento on-line).
Semelhante ao Material-UI, o framework Materialize utiliza o Material 
Design como ferramenta para a utilização de cores, formatos e ícones, incorpo-
rando componentes e animações e fornecendo um maior feedback aos usuários. 
Esse framework se mostra como uma ótima ferramenta para desenvolvedores 
iniciantes, com uma documentação detalhada e canal aberto de comunicação.
O Foundation se apresenta como um framework para qualquer disposi-
tivo, mídia e acessibilidade. É semântico, legível, flexível e completamente 
9Ferramentas de apoio à construção de interfaces
personalizável, utilizando marcações simples sem sacrificar a funcionalidade 
e velocidade. Ademais, ele possibilita ao designer personalizar o framework, 
incluindo e excluindo os elementos além de definir tamanho, cores e fontes.
O framework Foundation é baseado no pré-processador SASS, permitindo uma cons-
trução mais rápida, pois chama funções de estilo prontas. Para saber mais sobre 
pré-processadores, veja a matéria disponível no link a seguir.
https://qrgo.page.link/UeTm1
O Bootstrap é visto como o framework número um no desenvolvimento de 
interfaces e se destaca devido a sua farta documentação e a uma comunidade 
ativa, além da infinidade de componentes que estão disponíveis para serem 
utilizados. O Bootstrap é uma ferramenta gratuita para desenvolvimento 
HTML, CSS e JS.
Existem diversas outras ferramentas e bibliotecas disponíveis para auxiliar 
a equipe de desenvolvimento no processo de criação da interface do sistema 
computacional. O conhecimento dessas características é importante para que 
a escolha da ferramenta seja assertiva e apoie de forma efetiva a construção 
do sistema. Além disso, as habilidades e os conhecimentos do desenvolvedor 
também devem ser considerados no processo de escolha do framework.
2 Avaliação automatizada em interfaces
Além das técnicas e ferramentas utilizadas para a criação de interfaces amigá-
veis, outro conceito-chave que deve ser considerado na garantia da qualidade 
é a usabilidade. Criar sistemas amigáveis efi cientes e fáceis de usar é requisito 
mínimo que deve ser cumprido para a aceitação do sistema oferecido. Para 
auxiliar na avaliação da usabilidade dos sistemas computacionais, Nielsen 
(1994) apresenta um conjunto de dez heurísticas de usabilidade que guiam a 
avaliação da interface proposta. 
As heurísticas de Nielsen, os critérios ergonômicos (BASTIEN; SCAPIN, 
1993) e as normas ISO voltadas para o princípio de design de interface já são 
Ferramentas de apoio à construção de interfaces10
bem conhecidas e utilizadas, mas Santos et al. (2017) acreditam haver carência 
de ferramentas em algumas áreas da produção de sistemas computacionais, o 
que faz com que a sua realização seja manual.
Observando a necessidade de uma ferramenta computacional que apoie o 
designer no processo de avaliação da interface de sistemas computacionais, a 
ferramenta THEM (Tool for Heuristic Evaluation Methods) foi desenvolvida 
(SANTOS et al., 2017, documento on-line) “[...] de modo que suas funcionali-
dades contemplassem as principais etapas e artefatos da avaliação heurística 
e queos avaliadores pudessem colaborar durante a avaliação”.
Segundo Santos et al. (2017), a ferramenta apresenta uma sequência de exe-
cução similar ao passo seguido no modo tradicional utilizado para a realização 
da avaliação heurística. Com a utilização da ferramenta, os avaliadores podem: 
  criar um novo projeto; 
  incluir e gerenciar novos avaliadores colaboradores; 
  definir quais são as heurísticas que serão avaliadas (o avaliador pode 
escolher não realizar uma inspeção de todas as heurísticas, focando 
naquelas em que tem mais interesse) e seu nível de gravidade; 
  reportar os problemas encontrados; 
  gerar relatório da avaliação realizada. 
A Figura 6 apresenta a tela da ferramenta THEM, em que o avaliador pode 
inserir os problemas encontrados na interface.
Figura 6. Cadastro do problema.
Fonte: Santos et al. (2017, documento on-line).
11Ferramentas de apoio à construção de interfaces
Ao final da realização da avaliação, a ferramenta apresenta um compilado 
de informações, como o nome e o número de heurísticas quebradas, bem como 
a gravidade associada e um relatório apresentando a incidência das quebras 
dessas heurísticas. A Figura 7 apresenta um resumo com as indicações da 
avaliação realizada.
Figura 7. Resumo da avaliação.
Fonte: Santos et al. (2017, documento on-line).
Outro trabalho que busca melhorar a usabilidade do sistema computacional 
foi desenvolvido por Lima (2014), que também toma como base as heurísticas 
de Nielsen (1994) para a realização da avaliação. O diferencial da proposta 
de Lima (2014) é que, ao invés de um avaliador, que é experiente no processo 
de design de interface, é o usuário final que avalia o sistema. Dessa forma, 
o autor criou um instrumento de avaliação que busca auxiliar os usuários no 
entendimento das heurísticas, que possuem uma linguagem formal, traduzindo-
-as para uma linguagem mais simples de ser compreendida por pessoas que 
não têm conhecimento em construção de sistemas computacionais — o autor, 
no entanto, não realizou a avaliação com os usuários.
Dando continuidade ao trabalho de Lima (2014), Silva (2016) utilizou o 
instrumento criado e a ferramenta UX Check para a realização da avaliação 
heurística por usuários do sistema. O UX Check é um plug-in para o Google 
Chrome que possibilita ao usuário criar um checklist com base nas heurísticas 
de Nielsen e consegue identificar os elementos dispostos na interface por meio 
Ferramentas de apoio à construção de interfaces12
da leitura do seu script. Com essa identificação, possibilita ao usuário selecionar 
partes dessa interface. Ao selecionar a parte que deseja marcar, uma caixa de 
diálogo é aberta, permitindo ao usuário informar a heurística que ele acredita 
estar sendo violada, o grau de severidade que quer atribuir e um comentá-
rio que deseje anexar para uma melhor compreensão nas fases posteriores. 
Ao final da avaliação, é possível gerar um documento para compartilhamento 
com a equipe. A Figura 8 apresenta a estrutura do UX Check.
Figura 8. Interface do UX Check.
Fonte: Santana (2016, documento on-line).
Em seu trabalho, Santos et al. (2017) apresentam e comparam uma variedade 
de ferramentas que auxiliam a equipe de designer na avaliação do sistema 
desenvolvido. Não só a avaliação heurística pode ser suportada por ferramentas 
automatizadas, mas também a avaliação de acessibilidade, como o Wave e 
ATRC Accessibility Checker, que seguem as diretrizes de acessibilidade do 
WCAG 2.0, e a avaliação de comunicabilidade, utilizando o método de inspeção 
semiótica (MIS), como o MISTool (REIS, 2010). A usabilidade, acessibilidade e 
comunicabilidade se estabelecem como os principais critérios de qualidade em 
IHC (BARBOSA; SILVA, 2010) e, por isso, devemos considerar a criação de 
sistemas computacionais que atendam os conceitos de qualidade estabelecidos 
para que o sistema seja aceito pelos usuários.
13Ferramentas de apoio à construção de interfaces
BALSAMIQ. Alternates. [S. l.: s. n.], 2020. Disponível em: https://balsamiq.com/wireframes/
desktop/docs/alternates/. Acesso em: 5 fev. 2020.
BARBOSA, S.; SILVA, B. Interação humano-computador. Rio de Janeiro: Elsevier Brasil, 2010.
BASTIEN, C.; SCAPIN, D. RT-0156: ergonomic criteria for the evaluation of human-com-
puter interfaces. Rapport technique INRIA, May, 1993. Disponível em: http://www.inria.
fr/rrrt/rt-0156.html. Acesso em: 5 fev. 2020.
CRISTIAN, L. O que é um mockup? In: CLUBE DO DESIGN. [S. l.: s. n.], 2018. Disponível 
em: https://clubedodesign.com/2018/o-que-e-um-mockup/. Acesso em: 5 fev. 2020.
HART, J. The art of the storyboard: storyboarding for film, tv, and animation. Massachu-
setts: Focal Press, 1998.
KNAPP, J. The 8 steps to creating a great storyboard. Fast Company, dez. 2013. Disponível em: 
https://www.fastcompany.com/1672917/the-8-steps-to-creating-a-great-storyboard. 
LIMA, C. H. T. C. Um instrumento para usuários avaliarem a interação de sistemas compu-
tacionais. 2014. 66 f. Monografia (Graduação) - Universidade Federal do Ceará, Campus 
de Quixadá, Curso de Sistemas de Informação, Quixadá, 2014.
MCELROY, K. Prototyping for physical and digital products. In: O’REILYY. [S. l.: s. n.], 2016. 
Disponível em: https://www.oreilly.com/ideas/prototyping-physical-digital-products. 
Acesso em: 5 fev. 2020.
MOQUPS. [S. l.: s. n.], 2020. Disponível em: https://moqups.com/. Acesso em: 5 fev. 2020.
NIELSEN, J. Usability engineering. San Francisco: Morgan Kaufman, 1994.
PLOT. The easiest way to storyboard your videos. [S. l.: s. n.], 2020. Disponível em: https://
theplot.io/. Acesso em: 5 fev. 2020.
REIS, M. M. Mistool, uma ferramenta para aplicação colaborativa do método de inspeção 
semiótica. 2010. 60 f. Monografia (Graduação) - Universidade Federal de Ouro Preto, 
Ouro Preto, 2010.
SANTANA, N. Ferramentas de UX: checklists e guidelines. Coletivo UX, nov. 2016. Disponível 
em: https://coletivoux.com/ferramentas-de-ux-checklists-e-guidelines-b27fb8cd1265. 
Acesso em: 4 fev. 2020.
SANTOS, F. et al. THEM: Ferramenta colaborativa para suporte a avaliações de interfa-
ces baseadas na Avaliação Heurística. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE 
COMPUTAÇÃO, 37., SIMPÓSIO BRASILEIRO DE SISTEMAS COLABORATIVOS, 14., 2017. 
Anais […]. São Paulo, 2017. Disponível em: http://csbc2017.mackenzie.br/anais. Acesso 
em: 4 fev. 2020.
Ferramentas de apoio à construção de interfaces14
Os links para sites da Web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
SEMANTIC-UI. [S. l.: s. n.], 2020. Disponível em: https://semantic-ui.com/. Acesso em: 4 
fev. 2020.
SILVA, T. V. Trazendo o usuário para realizar a avaliação heurística. 2016. 92 f. Monografia 
(Graduação) - Universidade Federal do Ceará, Quixadá. 2016.
WONDER UNIT. StoryBoarder. [S. l.: s. n.], 2019. Disponível em: https://wonderunit.com/
storyboarder/. Acesso em: 4 fev. 2020.
Leituras recomendadas
FREE MOCKUP. [S. l.: s. n.], 2020. Disponível em: https://www.free-mockup.com/. Acesso 
em: 5 fev. 2020.
GONÇALVES, T. Pré-processador CSS? Sass? O que é e por onde começar! BeCode, 2017. 
Disponível em: https://becode.com.br/pre-processador-css-sass/. Acesso em: 5 fev. 2020.
15Ferramentas de apoio à construção de interfaces
INTERFACE 
HUMANO-
COMPUTADOR 
Leonara de Medeiros Braz
Fatores humanos 
e ergonomia
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Definir ergonomia e seus principais objetivos.
  Identificar os tipos de ergonomia.
  Explicar os princípios ergonômicos.
Introdução
De acordo com Corrêa e Boletti (2015), a ergonomia emergiu como dis-
ciplina de estudo em 1940 devido ao crescente surgimento de diversos 
equipamentos ao longo