O DESIGN

DE INTERAÇÃO
E A PRODUÇÃO
DE PRODUTOS
DIGITAIS

Faculdade de Ciências e Tecnologia da Universidade de Coimbra

Setembro 2013
O Design de Interação e a produção de produtos digitais

Bruno Rito :: Tese Mestrado em Design Multimédia :: Setembro 2013

Orientador Universidade de Coimbra: Lizá Ramalho
Orientador Critical Software: Nélson Vilhena
Resumo
Esta tese tem como tema principal o design de interação e a sua ligação ao desenvol-
vimento de produtos digitais. O estudo desta área serve de base para o trabalho prá-
tico desenvolvido em contexto de estágio na Critical Software em Coimbra.

Durante o estágio foram concebidas duas soluções para dois produtos digitais, ex-
plorando e testando o trabalho de vários especialistas em design de interação e se-
guindo as metodologias adotadas pela organização.

Este trabalho enquadra-se numa fase de exploração projetual, anterior à constru-

ção e utilização dos produtos digitais. Através do desenho de vários interfaces como
método de descoberta e definição de soluções, será testada uma abordagem centra-
da no utilizador, procurando que a exposição e vivência constante com os mesmos,
possa definir uma solução para o produto a desenvolver de acordo com as expetati-
vas dos utilizadores.

Palavras-chave: “Desenho”, “Desenho de protótipos”, “Design centrado no utiliza-

dor”, “Design interação”, “Interfaces”, “Produtos digitais”, “Software” e “Utilizadores”.
Índice

5 Resumo
9 Introdução

14 Capítulo I — Estado da Arte

17 1. Interfaces Gráficos (GUI)
29 2. Design de Interação
41 3. O desenvolvimento de Software
57 4. A integração do Design de Interação nas metodologias Agile

62 Capítulo II — Objetivos

68 Capítulo III — Trabalho Prático

71 Contexto
81 Projetos desenvolvidos
83 1. Gestão Documental - DMS (Document Management System)
115 2. Ideas do Income - iTi’s

138 Conclusão

144 Referências

150 Índice de Imagens

INTRODUÇÃO
 11

From a humanities perspective, the design of digital objects

is a cultural practice like writing a book or making a film.
(Murray, 2012)

Introdução
O desenho de artefatos digitais ou de software, embora seja uma actividade bastante
recente quando comparada com outras, como o desenho de alfabetos (milénios), os
livros impressos (cerca de 500 anos), o som, ou a gravação de imagens (um século),
tornou-se atualmente uma atividade de enorme importância. (Murray, 2012)

O quotidiano está repleto de artefatos digitais e os utilizadores perante a diversida-

de de oferta esperam cada vez melhores experiências. Utilizar ou desenhar softwa-
re deixou de estar restrito a um número limitado de profissionais ou especialistas.
Assiste-se cada vez mais à colaboração de um grande número de disciplinas no pro-
cesso de desenho de software.

O design é uma das disciplinas que mais tem influenciado o desenho de produtos
digitais. Fornecendo a relação humana com os produtos tecnológicos, integrando o
que é desejável do ponto de vista humano com o que é tecnologicamente possível
e economicamente viável. Desta forma os designers têm sido capazes de criar bons
produtos ao longo dos tempos. (Brown e Katz, 2009)

Esta capacidade de criar bons produtos, exige que os designers cada vez mais au-
mentem a sua área de competências e cuidem de todos os pormenores da experiên-
cia do utilizador com os artefatos digitais.

O desenho de comportamentos é uma dessas áreas. Para além das regras de compo-
sição visual, exige-se que os designers tenham grande conhecimento do contexto de
utilização dos produtos desde o momento da compra até ao fim de vida dos produtos.

Cooper et al. (2007), referem o seguinte, “Most important of all is the understanding
of how the user wishes to use the product, in what ways, and to what ends.”

Esta tese, realizada no âmbito do mestrado em Design Multimédia discorre sobre o

tema da integração do Design de Interação no desenvolvimento de software ou pro-
dutos digitais.

As pesquisas e análises realizadas neste trabalho teórico, visaram sempre o traba-

lho prático que foi sendo desenvolvido em contexto de estágio, na empresa Critical
Software. A qual solicitou a concepção de soluções para dois novos softwares, in-
cluindo desenho e prototipagem de vários interfaces.
12

Na resposta aos desafios do trabalho prático, diário, além de seguir as metodologias

adotadas pela empresa, procurou-se sempre um suporte teórico adequado, presen-
te nos temas abordados no estado da arte.

O Capítulo I, faz uma reflexão sobre o Estado da Arte.

O primeiro ponto começa por explorar a evolução do desenho dos vários interfaces
gráficos (enquanto produtos digitais) ao longo da história. Mostrando quem foram
os pioneiros, como foram desenvolvidos os primeiros interfaces e em que contex-
to essa evolução se realizou. Assim, procura-se com esta introdução um maior en-
tendimento de algumas normas que ainda hoje são utilizadas em vários interfaces.

O segundo ponto do estado da arte aborda a prática do design de interação, com re-
ferências e metodologias de vários especialistas da área. Aqui, serão apresentados
três tópicos fundamentais que suportam o trabalho prático de estágio. São eles, o
design centrado no utilizador, a importância da prototipagem e os princípios do de-
sign de interação.

No terceiro ponto do estado da arte, foi desenvolvida alguma pesquisa sobre o de-
senvolvimento de software, com incidência particular nas metodologias Waterfall e
Agile, ambas praticadas pelas equipas de projeto da Critical Software. Também foi
realizada uma abordagem aos processos Lean e Lean UX, primeiro por serem pro-
cessos com bastante disseminação e foco na atualidade, e segundo pela forma como
tentam integrar as atividades de design com o desenvolvimento de software.

O último ponto do estado da arte, reflete sobre a forma como o design de intera-
ção se pode integrar com as metodologias Agile. A implementação desta metodolo-
gia nas equipas de projeto da Critical Software está a ser realizada atualmente, logo
torna-se de alguma relevância perceber como é que o design se pode integrar nes-
te processo.

No Capítulo II, definição dos objetivos e metodologias, faz-se um enquadramento do

trabalho prático a cumprir durante o estágio com a teoria das várias matérias explo-
radas no estado da arte. Tendo como grandes referências o trabalho de Alan Cooper,
Bill Moggridge, Tim Brown, entre outros, são definidas metodologias de orientação
para a exploração dos dois problemas propostas para o estágio.

O Capítulo III e último aborda o trabalho prático, dividido em dois projetos, DMS-
Gestão Documental e ITI’s – Ideas to Income. Este capítulo, em modo de relató-
rio, percorre todos os desafios encontrados nos projetos propostos pela Critical
Software. Recorrendo a técnicas de design de interação, para a conceção de ideias e
protótipos de interfaces, foram desenhadas soluções específicas para cada um dos
projetos.
 CAPÍTULO I
ESTADO DA ARTE
 ESTADO DA ARTE . 17

1. Interfaces Gráficos (GUI)

Actualmente, a maioria da população pertencente aos países desenvolvidos usa fre-
quentemente computadores pessoais (PC’s), quer em contexto de trabalho ou en-
tretenimento. Os PC’s tornaram-se omnipresentes e fundamentais para aumentar o
nosso conhecimento e potenciar a nossa inteligência. Assume-se que, quando utili-
zamos um computador utilizamos um interface gráfico (Graphical User Interface -
GUI) para interagir com o mesmo.

Os interfaces gráficos são parte essencial dos produtos digitais ou software. São eles
que possibilitam uma fácil interação com os PC’s, para a realização de tarefas sim-
ples ou complexas.

As primeiras ideias para um GUI, foram pensadas muito antes da tecnologia, que
iria permitir a criação dos interfaces, estar disponível. Segundo Reimer (2005) uma
das primeiras pessoas a imaginar estas máquinas foi Vannevar Bush, que no início
dos anos 30 do século XX, descreve um dispositivo a que chamou de “Memex”, “… as
looking like a desk with two touch screen graphical displays, a keyboard, and a scan-
ner attached to it. It would allow the user to access all human knowledge using con-
nections very similar to how hyperlinks work.” (Reimer, 2005)

A Segunda Guerra Mundial acabou por fornecer a motivação e financiamento ne-

cessário para o desenvolvimento de máquinas de calcular programáveis ou máqui-
nas para decifrar códigos secretos do inimigo. Fundamental para que por volta de
1937, diversos grupos em todo o mundo iniciassem a construção de computadores.

O início

Os primeiros desenvolvimentos no longo e complexo caminho de evolução dos inter-

faces gráficos (GUI) foram dados pelo Sketchpad criado por Ivan Sutherland em 1962
enquanto aluno de doutoramento do MIT (Massachusetts Institute of Technology).
Uma verdadeira revolução, como referem Perry e Voelcker (1989): “At a time when a
CRT monitor was a novelty in itself, the idea that users could interactively create ob-
jects by drawing on a computer was revolutionary.” (Perry e Voelcker, 1989)

Os utilizadores do Sketchpad podiam desenhar pontos, linhas, segmentos e ar-

cos num ecrã com tubo de raios catódicos através de caneta de luz. Além disso, o
Sketchpad permitia criar relações com os objectos, mover, rodar, copiar, etc.

Mais tarde, de forma a poder ampliar os objetos (Zoom in), Sutherland escreveu o
primeiro programa de desenho que o motivou também a criar o primeiro algoritmo
de recorte ou enquadramento (Clipping). “Clipping is a software routine that calcu-
lates which part of a graphic object is to be displayed, and displays only that part on
the screen. The program must calculate where a line is to be drawen, compare that
18 . ESTADO DA ARTE

Figura 1 - Sketchpad de Ivan Sutherland, 1962.

position to the coordinates of the window in use, and prevent the display of any line
segment whose coordinates fall outside the window.” (Perry e Voelcker, 1989)

Também em 1962, no mesmo ano em que Sutherland criou o Sketchpad, Douglas

Engelbart, Engenheiro Eletrotécnico de formação, publicou um ensaio com o títu-
lo “Augmenting Human Intellect”, referindo que os computadores poderiam fornecer
o mais rápido método para aumentar a capacidade intelectual do homem. Como ele
próprio descreve,“... increase the capability of a man to approach a complex problem
situation, to gain comprehension to suit his particular needs, and to derive solutions
to problems.” (Reimer, 2005)

Engelbart e a sua equipa trabalharam durante anos no desenvolvimento das ideias e

da tecnologia que foi apresentada em 1968, numa das mais importantes demonstra-
ções da história da computação. Diante de milhares de espetadores e com câmaras
a focar a sua cara, as mãos e o pequeno ecrã que visionava foi possível fazer uma de-
monstração inovadora e apresentar pela primeira vez uma série de novos conceitos.

Com o nome, NLS ou oN-Line System, o sistema de visualização era baseado na tec-
nologia de gráficos vectoriais e podia mostrar texto e linhas sólidas no mesmo ecrã.
Engelbart operava três dispositivos ligados ao computador, entre eles uma pequena
caixa retangular, com três botões no topo, ligada através de um longo fio - este ob-
jecto era o rato, nome atribuído mais tarde à invenção de Douglas Engelbart.

Embora outros sistemas tenham sido testados antes, o rato revelou-se, em testes
com utilizadores, a forma mais natural de manipular objetos no ecrã.
 ESTADO DA ARTE . 19

Figura 2 - oN-Line System de Doublas Engelbart, 1968.

Figura 3 - Réplica exata do primeiro rato inventado por Douglas Engelbart, criado pela empresa SRI,
criadora da versão original.

Xerox e o futuro

Com a demonstração de Engelbart e do que poderia ser o futuro, a Xerox que fez
fortuna na venda de fotocopiadoras, temendo a morte inevitável do seu negócio com
base no papel, decidiu que teria melhor futuro se dominasse esta tecnologia. Assim,
criou em 1970 o Palo Alto Research Center (PARC).

Este centro de investigação da Xerox com projetos de cinco anos e um ambiente de

trabalho relaxado, permitiu reunir e motivar os maiores investigadores dos Estados
Unidos. “The atmosphere was relaxed, yet charged with excitement. PARC research-
ers truly believed they were inventing the future of computing, and they ended up
doing just that.” (Reimer, 2005)
20 . ESTADO DA ARTE

Uma das primeiras invenções deste grupo foi uma impressora laser, ligada claramen-
te ao universo de impressão da Xerox. A nova invenção e as suas exigências gráficas
levaram o centro de investigação PARC, a inventar em 1973 o seu próprio computa-
dor para melhor tirar partido da sua impressora.

O computador Alto criado pela Xerox, tinha um ecrã com o tamanho e a orientação
de uma página impressa, uma resolução de 606 por 808 px, um teclado e uma versão
mais moderna do rato de Engelbart.

Figura 4 - À esquerda o computador Alto da Xerox de 1973 e à direita o interface do seu gestor
de ficheiros.

Além destas características, é importante salientar que é neste computador que sur-
ge pela primeira vez, o cursor em forma de seta na diagonal que conhecemos nos
nossos dias.

O primeiro software escrito para o Alto era algo rude, como se pode ver pelo seu ges-
tor de ficheiros na figura 4. Além deste gestor, o computador tinha um processador
de texto chamado Bravo e um editor gráfico com um método de funcionamento se-
melhante ao do actual Paint. O autor do processador de texto, Charles Simonyi, que
mais tarde ingressou na Microsoft, iria recriar este trabalho no Word para o MS-DOS.

Os primeiros interfaces modernos

Neste ambiente experimental, os investigadores do PARC sentiram a necessidade de

criar um novo e mais consistente interface para as suas aplicações. Assim, por vol-
ta de 1974 surgiu a linguagem de programação Smalltalk, um novo ambiente de de-
senvolvimento gráfico.

Na prática o Smalltalk era carregado no gestor de ficheiros, como as outras aplica-

ções, mas alterava por completo a aparência visual do computador Alto. As janelas
individuais do Smalltalk eram limitadas por uma linha preta que as fazia contrastar
 ESTADO DA ARTE . 21

com o padrão cinzento do fundo e cada janela tinha uma barra no topo com o títu-
lo que a identificava. Além disso, as janelas podiam ser movidas por todo o ecrã e so-
brepostas umas às outras, com a janela selecionada sempre à frente.

O conceito de ícones (pequena repre-

sentação icónica dos programas ou fi-
cheiros, que podia ser pressionada de
forma a lançar ou manipular os progra-
mas e documentos) foi também inventa-
do nesta altura. Além dos ícones, surgem
também pela primeira vez, os menus po-
pup, as scroll bars, os radio buttons e as
caixas de diálogo.

Segundo Reimer (2005), “The combina-

tion of Smalltalk and the Alto was essen-
tially a modern personal computer with
a very similar graphical user interface to
the ones we use today.”

Apesar dos desenvolvimentos, só em 1981

Figura 5 - O interface e ambiente
e por um preço elevado é que a Xerox
de desenvolvimento do Smalltalk.
lançou a primeira versão comercial des-
tes produtos, o Xerox Star. Mesmo sen-
do um marco importante, seria tarde para a Xerox, pois nesta altura grande parte dos
seus melhores investigadores juntaram-se a outras empresas.

Uma das quais a Apple, fundada em 1976 por Steve Jobs e Steve Wozniak. A Apple era
uma pequena empresa que tinha feito fortuna com a venda dos primeiros computa-
dores pessoais e que estava disposta a correr alguns riscos com as novas ideias dos
investigadores que trabalhavam no PARC. Nomeadamente, recriar e tornar comer-
ciais algumas das ideias desenvolvidas anteriormente.

O computador Lisa da Apple que começou como um tradicional computador para

utilização profissional com uma linha de comandos de texto, rapidamente se trans-
formou, sob influência de Steve Jobs, num computador com um interface gráfico.

Entre as várias inovações e novas convenções do Lisa estão: a primeira barra de

menus suspensos, onde todos os menus apareciam numa linha no topo do ecrã; se-
leções ou checkmarks ao lado das opções ativas dos menus; o conceito de atalhos
de teclado para os menus mais usados; o caixote do lixo para arrastar documentos
agendados para serem apagados; o duplo click. “As the interface required at least two
actions for each icon (selecting and running) the concept of double-clicking was in-
vented to provide this functionality.” (Reimer, 2005)

Lançado em 1983, o Lisa não foi o sucesso esperado, apesar das muitos inovações
que trouxe. O elevado preço e a dificuldade de escrever software para a nova máqui-
na foram alguns dos fatores apontados.
22 . ESTADO DA ARTE

Figura 6 - O interface do computador Lisa da Apple.

Outros interfaces dos anos 80

Nos anos 80 do século XX, além da Apple e do trabalho anterior da Xerox, eram vá-
rias as empresas que estavam a trabalhar em interfaces gráficos.

A VisiCorp em 1983 criou a primeira folha de cálculo de sempre, o VisiCalc. Era uma
versão monocromática com um interface pouco gráfico baseado em texto.

No mesmo ano, 1983, a Microsoft anunciou o Windows 1.0 que viria a lançar em 1985.
Com um interface a cores, o Windows 1.0 (Figura 7), tinha todos ornamentos gráfi-
cos dos seus predecessores.

Em 1984, a empresa Tandy Computers, lançou o seu próprio interface gráfico,

DeskMate. Desenhado para ser usado principalmente com o teclado, neste sistema
não era possível a sobreposição de janelas. Pela dificuldade de utilização não atin-
giu muito sucesso.

A Commodore Amiga computer, introduziu também o seu próprio interface gráfico

em 1985, o Workbench (Figura 8). Entre algumas ideias novas que este sistema criou,
destaca-se a possibilidade de poder selecionar, mover e trabalhar numa janela sem a
trazer automaticamente para a frente.

Em 1987, a Microsoft lançou a atualização do seu sistema, o Windows 2.0 (Figura 9),
numa versão em que se destaca a possibilidade de sobreposição das janelas. É nesta
altura que surge o primeiro processo judicial da Apple sobre a Microsoft, por causa
do aspeto do interface gráfico.
 ESTADO DA ARTE . 23

Figura 7 - O Windows 1.0 da Microsoft.

Figura 8 - Workbench da Commodore Amiga computers, 1985.

Também em 1987, a empresa Britânica Acorn, lançou o seu interface gráfico. Este sis-
tema, chamado Arthur (Figura 10), introduziu um novo conceito: a Dock ou prateleira
na base do ecrã, onde podiam ser guardados atalhos para os programas mais utiliza-
dos. Este foi o primeiro interface gráfico a reproduzir fontes no ecrã sem o serrilha-
do ou anti-aliased, mesmo no modo de 16 cores.
24 . ESTADO DA ARTE

Figura 9 - Windows 2.0 da Microsoft, 1987.

O ano de 1988 assistiu ao lançamento do NeXTSTEP (Figura 11), o novo interface grá-
fico e sistema operativo de Steve Jobs, depois de sair da Apple e já na sua empresa
Next. Este sistema introduziu um aspeto tridimensional a todos os elementos do in-
terface, e utilizou pela primeira vez o símbolo “X” para fechar uma janela. A Dock ou

Figura 10 - Arthur da Acorn computer, 1987.

 ESTADO DA ARTE . 25

prateleira presente no interface da Acorn também aparece aqui embora neste caso
pudesse ser configurada em qualquer dos lados do ecrã.

Figura 11 - NeXTSTEP, 1988.

Os anos 90 e depois

Com o início dos anos 90, assiste-se ao domínio da Apple e da Microsoft no mundo
dos computadores pessoais.

Em 1990 e 1992, a Microsoft lança o Windows 3.0 (Figura 12) e 3.1 respetivamente.
Apesar da ausência de muitas características presentes nos Macintosh, o seu aspe-
to limpo e os bonitos ícones, fizeram com que vende-se milhões de cópias. Em 1995
a Microsoft lança o seu mais popular sistema operativo de sempre, o Windows 95
(Figura 13), reforçando a sua liderança nos interfaces gráficos e no segmento dos
computadores pessoais.

O Windows 95 introduziu o novo conceito do menu iniciar, onde todos os programas

poderiam ser lançados, e a barra de tarefas que permitiu que os programas a correr
pudessem ser facilmente trocados.

Apesar das inovações e sucesso da Microsoft, a Apple continuou a trabalhar nas suas
ideias, e em 2000 lançou o seu novo interface gráfico “Aqua” (Figura 14) no seu novo
sistema operativo Mac OS X. Neste novo interface destaca-se o novo aspeto gráfico
26 . ESTADO DA ARTE

Figura 12 - Microsoft Windows 3.0.

Figura 13 - Microsoft Windows 95.

 ESTADO DA ARTE . 27

e revolucionário criado para o interface, representando um grande salto em relação

aos seus contemporâneos.

A história do desenvolvimento dos interfaces gráficos é longa e difícil de contar.

Foram muitos os intervenientes, que contribuíram com pequenos ou grandes deta-
lhes para o estado atual dos interfaces. Todos se inspiraram uns nos outros e adicio-
naram as suas contribuições de relevo.

Figura 14 - Mac OS X “Aqua”.

A massificação do computador pessoal nos anos 90, ajudou a que grande parte das
pessoas se familiariza-se com os conceitos presentes na nova máquina, e fez também
com que grande parte desses conceitos permanecessem inalterados nos interfaces
gráficos até hoje. Apesar disso, os interfaces, independentemente do dispositivo, de-
monstram grande versatilidade e capacidade para adição de novas funcionalidades e
modos de interação quase ilimitados.
 ESTADO DA ARTE . 29

2. Design de Interação
A evolução dos interfaces gráficos ajudou a transformar progressivamente o compu-
tador pessoal num produto de massas, ao mesmo tempo que potenciou a utilização
dos computadores em diferentes contextos. Esta capacidade, e a concorrência entre
as várias empresas que desenvolveram os primeiros interfaces, levou a que estes fos-
sem cada vez mais cuidados e fundamentais para estabelecer uma relação de sucesso
entre o computador e os seus utilizadores.

Das várias áreas que contribuíram para a melhoria do desenho dos interfaces, desta-
ca-se o design, nomeadamente o design de interação.

Gillian Crampton Smith, citada por Moggridge (2007), compara o design de intera-
ção com o trabalho desenvolvido pelos designers industriais, na forma como ao lon-
go da história têm moldado os objetos que fazem parte do nosso dia-a-dia. Gillian re-
fere o seguinte, “If I were to sum up interaction design in a sentence, I would say that
it’s about shaping our everyday life through digital artifacts—for work, for play, and for
entertainment.”

O Design de Interação pode ser descrito como uma disciplina do design que estuda
a relação do homem com o mundo através de produtos digitais. De forma mais téc-
nica, Alan Cooper define o Design de Interação como “… the selection of [software]
behavior, function and information and their presentation to users” (Ferreira, 2007).

Apesar de diferentes concepções, os autores reconhecem que o design deve ser um

processo de mediação numa realidade em que os artefatos ou produtos digitais ocu-
pam grande parte das nossas vidas. O design de interação deve tornar por isso a nos-
sa ligação com os artefatos digitais o mais agradável possível e através dessa media-
ção criar experiências enriquecedoras e duradouras. (Moggridge, 2007)

Esta é uma perspetiva em que o design deve intervir de forma positiva, contudo, este
não deve ser entendido sempre como solução positiva para os problemas, devemos
também ter noção dos efeitos negativos que pode provocar. As opções que tomamos
nunca são neutras e implicitamente boas, podendo por vezes o efeito ser precisa-
mente o contrário. (Moggridge, 2007)

Aliado ao processo mediação está também a noção de que o progresso é sempre im-
plicitamente benéfico. Contudo John Maeda, citado por Moggridge (2007), diz-nos
que nem sempre isso aconteceu ao longo da história, onde actualmente assistimos a
uma complexidade excessiva que dificulta a nossa vivência com os artefatos digitais.
“There is too much needless complexity in the world, he argues. Technology, which
was supposed to make our lives easier, has taken a wrong turn. In 20 years we’ve
gone from the simplicity of MacPaint to Photoshop.” (Moggridge, 2007)

O processo de design, é um processo de descoberta onde se aprende a arriscar, a

acertar e a falhar, onde arriscar é tão importante como fazer. Rodrigues e Jacoby,
2007, referem que “in the worldview of a design thinker, failure is the best way to
30 . ESTADO DA ARTE

clear the fog to see a path to success. Amplifying risk is a way to increase the amount
of information one receives from experiments and prototypes.” A amplificação do
risco é uma forma de aumentar a quantidade de informação que se recebe das expe-
riências. Quanto mais se tenta, mais se aprende.

Tim Brown (2012) num artigo publicado na “Rotman Magazine” de 2012 com o títu-
lo “The Merits of an Evolutionary Approach to Design”, acrescenta a esta perspetiva
de exploração e de lidar com erro, uma outra que a complementa: “Newton’s world
was based on the assumption that we have an ability to predict the world based on
actions in the present. When we think this way, it encourages us to be top-down in
our activities, to be predictive, to believe that we can imagine a complete system.”

A complexidade que enfrentamos hoje, segundo Tim Brown, obriga-nos a pen-

sar e agir de outra forma. Tal como Darwin pensou na evolução constante, altera-
ções emergentes e imprevisibilidade, também assim hoje devemos pensar o design.
Devemos deixar de pensar em desenhar objetos e pensar em desenhar comporta-
mentos. Pensar mais na forma como a informação circula, reconhecer que a evolu-
ção rápida é baseada em iterações rápidas e aceitar que o design nunca está con-
cluído. É necessário abraçar a mudança constante e saber cada vez mais lidar com
problemas complexos. E o design é a disciplina que historicamente sempre se dedi-
cou à resolução de problemas em várias áreas.

No campo do design de interação, Reimann (2008) define os seguintes pontos como

objetivos:

- Defining the behavior of artifacts, environments, and systems (i.e., products);

- Defining the form of products as they relate to their behavior and use;

- Anticipating how the use of products will mediate human relationships and affect
human understanding;

- Exploring the dialogue between products, people, and contexts (physical, cultur-
al, historical);

Joseph Pine e James H. Gilmore, no livro de 1989 “Experience Economy: Work is

Theatre & Every Bussiness a Stage”, citados por Manovich (2007), referem a impor-
tância dos comportamentos e a preocupação em proporcionar experiências en-
riquecedoras no mundo dos negócios. “…consumer economy was entering a new
stage where the key to succesful business was delivering experiences. According to
the authors, this was the new stage following the previous stages centered on goods
themselves and later services.” (Manovich, 2007)

À semelhança do que acontece no mundo dos negócios também o design deve ter um
âmbito muito mais alargado, preocupar-se com toda a experiência do utilizador na in-
teração com os produtos digitais.
 ESTADO DA ARTE . 31

2.1. Design centrado no utilizador

Na prática um produto digital ou software, medeia a conversação entre as pessoas e

as máquinas com vista a atingir um objetivo. O desenho de um bom software ou ou-
tro produto digital começa por entender as pessoas que o usam, o que elas gostam,
porque o usam, e como interagem com ele. (Tidwell, 2005)

Como refere Harry Saddler as pessoas fazem parte de todo o processo de traba-
lho do design, “Caring about people, discovering and responding to their needs and
tasks, is not an option. Interaction design is design that people participate in long af-
ter our job is done.” (Alben, 1997)

É necessário criar empatia com as pessoas e colocarmo-nos no seu papel, só as-

sim podemos perceber os problemas que as afetam. “…the effort to see the world
through the eyes of others, understand the world through their experiences, and
feel the world through their emotions.” (Brown e Katz, 2009)

Entender as pessoas e compreender o que pretendem é um trabalho complexo, uma

vez que poucas são capazes de articular e expressar as suas necessidades (Cooper et
al., 2007). “As numerous studies have shown, people are not, in general, good at pre-
dicting what will make them happy in the future … The strange truth about feature
creep is that even when you give consumers what they want they can still end up
hating you for it.” (Surowiecki, 2007)

Os tradicionais estudos de mercado por exemplo, que foram desenvolvidos para

perceber o que as pessoas querem, podem revelar ideias com pouco potencial, fun-
cionando normalmente bem para encontrar o que pessoas “dizem que querem”.
Contudo, se o objetivo é desenhar soluções inovadores e que satisfaçam os utiliza-
dores, a solução ainda nem sequer foi pensada e por definição não pode ser explica-
da. (Moggridge, 2007)

Uma das frases mais célebres da história, atribuída a Henry Ford, refere isso mesmo, “If
I’d asked my customers what they wanted, they’d have said ‘a faster horse’”.

As pessoas quando questionadas sobre o que pretendem para o futuro, ou que produtos
lhes podem ser mais úteis, têm bastante dificuldade em expressar ideias para além da-
quilo que conhecem. Não é fácil perceber quais as suas necessidades. É por isso que
os tradicionais estudos de mercado ou inquéritos, raramente nos trazem descober-
tas importantes. A melhor maneira de iniciar a descoberta, é observar o mundo e ver
como se pode melhorar o dia-a-dia das pessoas.

O design centrado no utilizador (User-centered design - UCD) é uma abordagem ao

desenvolvimento de produtos que coloca o ênfase no utilizador final do produto,
conduzindo a pesquisa sobre os utilizadores e envolvendo-os no desenho iterativo e
avaliação do produto. O objetivo do UCD é criar produtos utilizáveis que satisfaçam
as necessidades dos utilizadores (Rannikko, 2011).
32 . ESTADO DA ARTE

Esta abordagem, defende que os utilizadores finais são parte integrante do processo
de design e devem influenciar o resultado do design. Satisfazendo as suas necessida-
des adere-se à definição de usabilidade da norma ISO 9241-11: “The extent to which a
product can be used by specified users to achieve specified goals with effectiveness,
efficiency and satisfaction in a specified context of use.” (Ferreira, 2007).

Nielsen, citado por Ferreira (2007), define usabilidade como um sub-atributo da uti-
lidade, que é parte da aceitação de um sistema: “The resulting usability of the prod-
uct will depend on how easy it is to learn to use, how efficiently users can complete
their tasks, the ease with which users can remember how to use the product, the
amount of errors they make in using the product and how satisfied they are with the
overall experience”.

Reconhecer que o utilizador faz parte do processo de design exige que os designers
sejam também eles parte integrante da pesquisa sobre os utilizadores e do seu con-
texto. Cooper et al. (2007), referem que esta pode ser uma vantagem na ligação ou
análise dos dados recolhidos (entrevistas, questionários, etc) com os desenhos pro-
duzidos. “One of the most powerful tools designers bring to the table is empathy:
the ability to feel what others are feeling. The direct and extensive exposure to users
that proper user research entails immerses designers in the users’ world, and gets
them thinking about users long before they propose solutions. Additionally, it is of-
ten difficult for pure researchers to know what user information is really important
from a design perspective.” (Cooper et al., 2007)

Segundo Jared Spool (1996), o design centrado no utilizador, procura eliminar alguns
dos problemas que surgem na utilização dos produtos digitais: as chamadas “lacunas
conceptuais”. Estas surgem devido à diferença entre o modelo mental que o utiliza-
dor tem da aplicação e a forma como a aplicação funciona na realidade.

Com base neste raciocínio, Donald Norman, citado por Cooper et al. (2007) refere
que, a falta de ligação entre aquilo que é implementado pelos programadores do sof-
tware e o modelo mental das pessoas dá origem a um terceiro modelo, o modelo re-
presentado ou modelo do designer. Uma vez que os utilizadores têm tendência a for-
mar modelos mentais mais simples do que a realidade. É importante que o modelo
do designer seja o mais aproximado do modelo mental de forma a possibilitar uma
melhor experiência do produto.

Na aplicação de uma abordagem centrada no utilizador, são várias as metodologias

sugeridas, variando de autor para autor, apesar de ser possível encontrar um mes-
mo fio condutor.

Para Cooper et al. (2007), o designer deve usar técnicas de etnografia, entrevistas
com Stakeholders (interessados no processo), pesquisa de mercado, literatura com
análises ao produto, modelos de utilizadores detalhados, desenho de cenários, etc.
Ou seja, tudo o que forneça informação sobre os utilizadores e ao mesmo tempo
obedeça aos imperativos técnicos da organização. Estes autores dividem o processo
 ESTADO DA ARTE . 33

em cinco fases: “Research, Modeling, Requirements Definition, Framework Definition,

and Refinement.”

Rannikko (2011), refere na sua tese que o trabalho do design UCD deve ser um con-
junto de atividades feito durante todo o ciclo de desenvolvimento de um produto.
Das atividades a realizar, e utilizando Nielsen (1993) como referência, descreve as se-
guintes: “… know the user, competitive analysis, setting usability goals, parallel de-
sign, participatory design, coordinated design of the total interface, apply guidelines
and heuristic analysis, prototyping, empirical testing, iterative design, collect feed-
back from field use.”

Ainda, Vredenburg et al. (2002), citado por Rannikko (2011), refere cinco atividades
normalmente usadas no processo de design centrado no utilizador: desenhos itera-
tivos, avaliação de usabilidade, análise de tarefas, análise informal de peritos e estu-
dos de campo.

Ferreira (2007), refere algumas técnicas a utilizar no processo de design UCD, de for-
ma a conhecer melhor os utilizadores e as suas necessidades:

- A pesquisa de utilizadores. Como parte da recolha de requisitos para o projeto de

software. Os designers de interação devem obter dados de inquéritos, entrevistas ou
sessões de observação no local;

- Organizar os utilizadores. Com os dados recolhidos durante a pesquisa, a informa-

ção dos utilizadores deve ser organizada usando personas ou cenários (narrativa das
tarefas do utilizador num determinado contexto);

- Avaliação dos utilizadores. Revisão do utilizador recorrendo a um protótipo. Outra

técnica pode ser a utilização de um storyboard, que neste caso é uma sequência de
interações do produto;

- Regras de design. Aqui estão incluídas as 10 heurísticas (página 36) desenvolvidas

por Jakob Nielsen, que podem ser usadas como referência durante o processo de
design.

As técnicas sugeridas pelos autores, centram-se sobretudo na realização de um tra-

balho inicial de campo ou pesquisa, na organização ou modelação de utilizadores
(personas) e em desenhos ou protótipos avaliados pelos utilizadores. No fundo, um
processo que envolva os utilizadores, do ínicio ao fim do seu ciclo de desenvolvi-
mento ou conceção.

A abordagem centrada no utilizador, não é um processo completo para desenvol-

ver software. Precisa de ser integrada numa metodologia de desenvolvimento de
software para que seja possível cobrir todo o ciclo de desenvolvimento. Como refe-
re Rannikko (2011), “Ideally the UCD work should be an integral part of the require-
ments engineering activities or at least done in close collaboration to ensure that
end-users’ needs are really taken into consideration.”
34 . ESTADO DA ARTE

Fazendo parte de um processo maior, as tarefas de design não devem ser aborda-
das de forma isolada apenas pelo especialista de design, mas por toda a equipa do
projeto do qual faz parte. “All team members should carry out the life-cycle tasks
jointly to develop a shared understanding of the requirements and design issues.”
(Rannikko, 2011)

Para desenhar produtos digitais com o utilizador no centro do processo, deve-se

ainda, segundo Cooper et al. (2007), distinguir as tarefas (tasks) que estes executam
dos objetivos (goals) pretendidos na utilização de determinado produto. As tarefas são
importantes mas devem fazer parte de um cenário mais complexo em que o design
deve cumprir os objetivos dos utilizadores. No livro “About Face 3”, os mesmos au-
tores fazem uma distinção clara entre objetivos e tarefas. Sendo os objetivos a con-
dição final a atingir por parte dos utilizadores e as tarefas passos intermédios para
atingir o objetivo final.

Esta é uma visão que permite aos designers eliminarem tarefas desnecessárias à ati-
vidade humana evitando ao mesmo tempo que a tecnologia se sobreponha às ati-
vidades essenciais. “For example, when traveling from St. Louis to San Francisco,
a person’s goals are likely to be speed, comfort, and safety. In 1850, a settler would
have made the journey in a covered wagon; and, in the interest of safety, he would
have brought along his trusty rifle. Traveling from St. Louis to San Francisco today,
a businessman makes the journey in a jet aircraft; and, in the interest of safety, he is
required to leave his firearms at home. The goals remain unchanged, but the tasks
have so changed with the technology that they are, in some respects, in direct op-
position.” (Cooper et al., 2007)

A atividade de design centrado no utilizador pode trazer benefícios económicos e

sociais como refere a norma ISO 13407. Rannikko (2011), aponta alguns benefícios:

- sistemas mais fáceis de entender e usar, permitem reduzir custos de formação e

assistência;

- maior satisfação e menos desconforto do utilizador;

- maior produtividade e eficiência operacional das organizações;

- produtos de qualidade, apelam aos utilizadores e podem fornecer alguma vanta-

gem competitiva.
 ESTADO DA ARTE . 35

2.2. A importância da Prototipagem

O envolvimento dos utilizadores é parte fundamental de qualquer projeto, e o de-

sign de interação utiliza técnicas específicas como o desenho e os protótipos para
captar o mais cedo possível informação dos utilizadores. Brown e Katz (2009), re-
ferem: “… user input can begin early enough to influence the design of the product.
User involvement then obviously continues through the engineering phase, in the
form of usability testing.”

Um protótipo é uma aproximação, uma experiência que tenta simular a utilização de

um produto ou serviço (Gothelf, 2013). Segundo Hartmann (2009), a prototipagem é
uma atividade fundamental do design que conjuga a inovação, a colaboração e a cria-
tividade, “… it is through the creation of prototypes that designers learn about the
problem they are trying to solve”. Para Brown e Katz (2009), “anything tangible that
lets us explore an idea, evaluate it, and push it forward is a prototype.”

Brown e Katz (2009), referem a qualidade da informação que os testes com protótipos
nos podem fornecer. O desenho como descoberta, num processo iterativo de tenta-
tiva erro podem inspirar-nos a redefinir ou pensar em novas suposições. “The risk of
such an iterative approach is that it appears to extend the time it takes to get an idea
to market, but this is often a shortsighted perception. As we say at IDEO, “Fail early to
succeed sooner.”” (Brown e Katz, 2009)

Moggridge (2007), também refere a prototipagem como um processo fundamental

de descoberta. Criar protótipos com frequência e testá-los frequentemente é essen-
cial. “Prototype early and often, making each iterative step a little more realistic but
minimizing the time and effort invested each time.”

Contudo, é necessário alguma tolerância ao erro,é necessário testar muitas vezes

e fazer com que cada passo seja um pouco mais realista. Só testando com os futu-
ros utilizadores e várias vezes, podemos saber se o que estamos a fazer está correto.
“We will fail frequently, but the reward is that we will succeed sooner. (Moggridge,
2007)

Muitos dos problemas que o design enfrenta são complexos e a maneira de desco-
brir a melhor solução é realizar uma série de experiências. Quanto mais cedo tornar-
mos as ideias tangíveis, mais cedo as podemos avaliar. “Prototyping allows the explo-
ration of many ideas in parallel. Early prototypes should be fast, rough, and cheap.”
(Brown e Katz, 2009)

Os vários tipos de protótipos podem ser desenvolvidos com diferentes técnicas, mas
devem servir sempre os objetivos a atingir. Como refere Smith (2012) “These can
range from a very simple clickable PDF to an almost fully functioning HTML/CSS
website. It really depends on what you need for your project as to how far you go
with it.”

Hartmann (2009), defende o protótipo como um veículo para desenhar hipóteses e

testá-las perante os utilizadores. “Prototyping is not primarily about the artifacts
36 . ESTADO DA ARTE

that get built: it is about eliciting feedback (from the situation, from users, team
members & clients).”

Brown e Katz (2009), reforçam a ideia do protótipo como modelo de aprendizagem.

A identificação dos pontos fortes e fracos, permite delinear novos caminhos.

Buxton (2003), refere ainda que a engenharia vê os protótipos como parte do pro-
cesso de construir coisas, enquanto o design vê os protótipos como forma de criti-
car e descartar hipóteses. Apesar de outros autores, como Moggridge (2007), defen-
derem que o software com base em tecnologias web, com a possibilidade de aceder
a utilizadores reais enquanto são testadas hipóteses, estar a aproximar o protótipo
do produto final. ““Live prototyping” can give you the opportunity to run user tests
with large numbers of participants as you develop the design, so that each attempt
teaches the lessons of reality and gives the designer the chance to try again with the
knowledge of what worked for people. Live prototyping and the evolution of proto-
typing tools are all about moving closer and closer to the implemented result. People
are learning prototyping tools in a similar way to how they used to learn new pro-
gramming languages. (Moggridge, 2007)

2.3. Princípios do design de interação

Os princípios do design de interação são regras gerais aplicadas no desenho de in-

terfaces gráficos. São princípios fundamentais para a eficácia de qualquer produ-
to digital.

Foram abordados por várias autores, com o objetivo de melhorar o desenho dos in-
terfaces. Através de um conjunto de regras, ajudam a verificar se as aplicações que
estão a desenvolver cumprem todos os requisitos para uma utilização agradável por
parte dos utilizadores.

Jakob Nielsen, Bruce Tognazzini, Donald Norman e Ben Shneiderman, foram alguns
dos autores que trabalharam sobre o tema. Atribuindo diferentes nomes para os
seus princípios (Princípios, Regras de Ouro, Heurísticas, ou regras gerais), todos têm
como objetivo criar material de referência que melhore a usabilidade das aplicações.

Jakob Nielsen desenvolveu as suas 10 heurísticas originalmente em 1990 com Rolf

Molich. Em 1994, as heurísticas foram novamente revistas por Nielsen. Assim, os 10
princípios gerais de Nielsen (1995) são:

1. Visibilidade do estado do sistema;

2. Correspondência entre o sistema e o mundo real;

3. Liberdade de controlo do utilizador;

4. Normas e consistência;
 ESTADO DA ARTE . 37

5. Prevenção de erros;

6. Reconhecimento em vez de recordação;

7. Uso eficiente e flexível;

8. Estética de design minimalista;

9. Ajudar os utilizadores a reconhecer, diagnosticar e recuperar de erros;

10. Ajuda e documentação;

Com alguns pontos em comum, Bruce Tognazzini (2003), descreve em 16 pontos os

seus princípios gerais do design de interação:

1. Antecipação - manter o utilizador informado;

2. Autonomia - o utilizador deve comandar as ações e o sistema deve mantê-lo in-

formado do seu estado;

3. Daltonismo - quando se usa a cor para transmitir informação, deve-se usar indi-
cações secundárias;

4. Consistência - consistência visual, consistência com as expetativas dos utilizado-

res, etc;

5. Padrões;

6. Eficiência do utilizador - ter a atenção a produtividade do utilizador;

7. Interfaces exploráveis - dar pontos de referência ao mesmo tempo que se permi-

te alguma liberdade;

8. Lei de Fitts - O tempo para atingir um alvo é uma função da distância e de tama-
nho do alvo;

9. Objetos de interface humana - os objetos do interface devem ser reconhecidos;

10. Redução do tempo de resposta;

11. Aprendizagem - reduzir a curva de aprendizagem de um sistema;

12. Utilização de boas metáforas;

13. Proteger o trabalho dos utilizadores - os utilizadores nunca devem perder o tra-
balho que estão a fazer;

14. Legibilidade;

15. Controlar o estado do sistema;

16. Navegação visível;

38 . ESTADO DA ARTE

Donald Norman (1988) no livro “The Design of Everyday Things”, resume os seus
princípios em 6 pontos gerais:

1. Visibilidade - saber o que fazer;

2. Feedback - o que está a acontecer;

3. Affordance - saber como fazer ou o que se pode fazer;

4. Mapeamento - onde está o utilizador e para onde pode ir;

5. Restrições - o que não se pode fazer e porquê;

6. Consistência - familiaridade com que se está a ver;

Ainda, Ben Shneiderman (2003), aborda 8 princípios a que chamou de 8 regras de

ouro para o desenho de interfaces:

1. Procurar a consistência;

2. Permitir aos utilizadores frequentes utilizarem atalhos;

3. Dar feedback do sistema aos utilizadores;

4. Fornecer informação completa;

5. Disponibilizar ajuda para erros simples;

6. Permitir uma fácil inversão das ações;

7. Apoio no controlo das ações;

8. Reduzir a carga de memória de curto prazo;

O trabalho dos diferentes autores, decorrente da sua longa experiência, aborda com
diferentes níveis de profundidade, várias regras que numa primeira abordagem po-
dem parecer simples regras de bom senso quando se desenha uma aplicação.

Cada um dos autores, desenvolveu os princípios que na sua perspetiva são os mais
importantes. Deste trabalho diverso destacam-se alguns princípios comuns, como:
Visibilidade do estado do sistema; Consistência visual; O utilizador deve ter contro-
lo sobre o sistema; Reconhecimento do que se está a ver e acontecer; Utilização efi-
caz e produtiva; Apoio nas ações; Prevenção de erros;

Embora esse facto, é de extrema importância que antes, durante e após o desen-
volvimento de qualquer produto digital, estes princípios estejam bem presentes na
mente de quem os desenvolve.
ESTADO DA ARTE . 39
 ESTADO DA ARTE . 41

3. O desenvolvimento de Software
“Software has become our interface to the world, to others, to our memory and our
imagination.” (Manovich, 2013)

Durante as últimas duas décadas, o software tornou-se na linguagem universal atra-

vés da qual o mundo comunica e acabou por substituir outros meios tecnológicos in-
ventados nos séculos anteriores. Manovich (2013), faz a seguinte comparação, “What
electricity and the combustion engine were to the early twentieth century, software
is to the early twenty-first century”, uma verdadeira revolução, portanto.

A evolução dos interfaces gráficos permitiu que o computador se transformasse

numa verdadeira “máquina cultural”. Mediando a comunicação entre o homem e a
máquina, tornou o computador acessível a qualquer indivíduo, o qual por sua vez co-
meçou a produzir vários tipos de conteúdos, através de diferentes softwares.

Os softwares de produção de média, como o Word, o PowerPoint, Photoshop, After

Effects, Final Cut, Worpress, 3DS Max, entre outros, segundo Manovich (2013) es-
tão a moldar e a transformar a forma como os conteúdos são produzidos e por sua
vez a transformar a nossa cultura, permitindo comunicar, aprender e criar de no-
vas formas.

O computador, através do software tem possibilitado ao longo da história a criação

de novas linguagens, e sempre que se cria um novo software ou se atualiza um já
existente, novas capacidades são adicionadas à linguagem inicial. A expansão a no-
vas utilizações, técnicas e possibilidades, torna possível que o computador “fale”, de
forma quase ilimitada cada vez mais linguagens. Como refere Manovich (2013), “…to-
day software is fundamentally malleable in a way that twentieth-century industrial-
ly produced objects were not.”

Esta versatilidade ou capacidade de adaptação do software torna-o num produto

extremamente social. As técnicas presentes em cada software, resultado de inven-
ções individuais, de empresas ou de comunidades open source, acabam por migrar
de software em software à medida que o número de pessoas que as utiliza aumenta
ou quando outras empresas as passam a utilizar. Num ecosistema onde as ideias e as
técnicas se vão difundindo.

Manovich (2013), compara as aplicações de software a espécies de uma ecologia co-

mum. “… software is created to fit into already existing production procedures, job
roles, and familiar tasks. But software applications are like species within the com-
mon ecology—in this case, a shared environment of a digital computer.”
42 . ESTADO DA ARTE

3.1. Metodologias de desenvolvimento

O desenvolvimento de software é uma tarefa extremamente complexa que requer

enorme exigência e coordenação dos vários intervenientes. Dada a complexidade
e dimensão, nos projetos de desenvolvimento são normalmente criadas equipas de
trabalho para lidar com os diferentes desafios. Nestas equipas existe naturalmente
uma “ecologia diversa de personalidades e culturas”. As pessoas são todas diferentes
umas das outras e a cooperação entre elas pode variar bastante, uma variedade que
pode ser benéfica para o projeto. Ter uma equipa com diferentes características per-
mite que cada um trabalhe no que mais gosta e sabe. (Cockburn, 2001)

Por outro lado, em qualquer tarefa ou desafio com intervenção humana a equipa deve
estar sempre preparada para o erro. As pessoas erram nas estimativas de tempo, no
orçamento, a escrever, a desenhar a testar, no fundo tudo o que possamos fazer está
sujeito ao erro. “We must accept that mistakes will be made and use processes that
adjust to the fact of mistakes.” (Cockburn, 2001). No fundo, foi o resultado de erros e
de diferenças entre indivíduos que fomentou a criação de novas abordagens técnicas
aos problemas.

No desenvolvimento de software, e apesar de projetos diferentes necessitarem de

processos diferentes, as primeiras metodologias criadas não podem ser considera-
das verdadeiras metodologias. Existia sim, uma grande liberdade à medida que as or-
ganizações lutavam por ter lucro com as tecnologias relacionadas com os computa-
dores. (Serena, 2007)

Para Cockburn (2001), a metodologia é o produto de um ecosistema particular e uma

construção única de uma organização. É uma construção social baseada numa série
de convenções que se fazem regularmente. Dentro da mesma linha de pensamen-
to, Ferreira (2007), refere o seguinte. “According to Fuggetta, a software process can
be defined as “the coherent set of policies, organizational structures, technologies,
procedures, and artifacts that are needed to conceive, develop, deploy, and maintain
a software product” and research in this area assumes that the quality of the process
influences the quality of the resulting product”.

Uma metodologia pode ter vários usos e funções, mas de forma geral descrevem as
regras com que uma organização trabalha.

Cockburn (2001), no seu livro “Agile Software Development” descreve a sua utilida-
de em 6 pontos:

1. Introducing new people to the process: “Hi, how do we work around here?” is a
natural question for new team members to ask. It is helpful to have something avail-
able so they can learn their place in the organization.

2. Substituting people: Although people are not plug-replaceable, they often do need
to be replaced.

3. Delineating responsibilities: A methodology indicates what is not part of a person’s job.

 ESTADO DA ARTE . 43

4. Impressing the sponsors: The force plays on the natural reflex that a heavier and
more precisely choreographed methodology is “safer.”

5. Demonstrating visible progress: Related to impressing the sponsors, the purpose

of the methodology may be to allow the contractors to show their sponsors what
they have been doing.

6. Curriculum for education: After a methodology names techniques and standards

for people to use.

A metodologia Waterfall
A metodologia de desenvolvimento de software Waterfall teve a sua origem duran-
te os anos 60 do século XX, com o desenvolvimento de software de grande escala da
indústria militar e espacial Americana (Cusumano e Smith, 1995). Adaptada de outras
disciplinas da Engenharia, esta metodologia foi formalmente descrita pela primeira
vez, em 1970 por Winston Royce (Dubberly, 2004).

Na prática, a metodologia Waterfall tem como base o desenvolvimento de software

de forma sequencial ou linear numa série de fases organizadas e controladas, des-
de os requisitos de alto nível, passando pelos testes até à conclusão do software
(Cusumano e Smith, 1995).

Na sua essência, só avança para uma fase seguinte quando conclui correctamente a
fase anterior. Um output de uma fase, serve de input para a próxima fase (Dubberly,
2004), sendo a documentação e o código os outputs normais de cada fase.

No fim de cada fase existe um passo de certificação que marca a conclusão de uma
fase e o início de outra. Não é suposto os membros da equipa do projeto alterarem
outputs já certificados, embora a mudança de requisitos seja uma coisa que aconte-
ça constantemente.

Cusumano e Smith (1995) fazem a seguinte descrição: “Designers begin by trying to

write a specification that is as complete as possible. Next, they divide the specifica-
tion into pieces or modules in a more detailed design phase, and then assign differ-
ent individuals or teams to build these pieces in parallel. Each team tests and debugs
(finds and fixes errors) in its pieces. Only in the last phase of the project, which could
range from a few months to a few years for a large system, do the designers, devel-
opers, and testers try to put the pieces together and test the entire system. Usually,
this process of integration and system testing requires reworking the modules and
writing new code to correct problems in the operation or interactions of the piec-
es due to unforeseen problems as well as mistakes, miscommunications, or chang-
es that have crept into the design of the parts during the project. If this integration
work goes well, the team will ship the product when there are no serious bugs (er-
rors or defects) remaining.”
44 . ESTADO DA ARTE

Royce, em 1970 na sua descrição formal do processo Waterfall, propõe 7 etapas

(Figura 15) para o desenvolvimento de software (Ferreira, 2007):

“System requirements; Software requirements; Analysis; Program design; Coding;

Testing; Operations.”

Ferreira (2007) acrescenta ainda, “…in waterfall software development processes,

development activities are performed in sequence, the next activity only commen-
cing once the previous one has completed. Further, the product and the process is
expected to be heavily documented.” (Ferreira, 2007)

Documentar faz parte do processo normal de trabalho, a fase precedente cria uma
base de trabalho para a seguinte e a documentação passa a fazer parte do processo
de comunicação entre as equipas do projeto.

“How much documentation? My own view is ‘quite a lot’ certainly more than most
programmers, analysts, or program designers are willing to do if left to their own de-
vices. The first rule of managing software development is ruthless enforcement of
documentation requirements… Management of software is simply impossible with-
out a very high degree of documentation.” (Royce, 1970)

Figura 15 - Diagrama original de Royce (1970) com as etapas da metodologia Waterfall.

Desvantagens da Waterfall
Ferreira (2007), aponta algumas desvantagens à metodologia Waterfall:

“While the sequential waterfall approach has afforded project managers a sense of
control and exacted a kind of discipline from those involved in the development
project, it has not proven itself a resounding success in the software development
 ESTADO DA ARTE . 45

arena. Considering the published figures touting the poor performance of tradition-
al projects in the mid 1990s, it is not surprising that practitioners were turning their
attentions to alternative approaches:

- Rodrigues and Bowers reported on the increasing trend of budget over-runs of

40–200%.

- The Standish Group reported that only 16.2% of software projects in the United
States were completed on time and within their budget

- According to the Special Interest Group concerned with the Organisational

Aspects of IT (OASIG), in 1996, just 10-20% of software products deployed in the
United Kingdom met all their success criteria;” (Ferreira, 2007)

Ao longo dos anos, a metodologia Waterfall, tem sido associada a elevados custos e
a grande burocracia e excesso de documentação que tem de ser aprovada. As alte-
rações aos projetos são bastante dispendiosas de implementar, as interações exi-
gem muito esforço e os problemas são geralmente empurrados para as fases finais
(Peterson, 2010).

Outro problema apontado, diz respeito à definição de requisitos, a metodologia

Waterfall parte do pressuposto de que é possível ter um entendimento perfeito dos
requisitos desde o início do projeto (Serena, 2007). Mas, as necessidades iniciais dos
utilizadores não são as mesmas no final do projeto, o que implica que muitas das
funcionalidades implementadas não sejam usadas (Peterson, 2010). Este problema
surge normalmente associado à falta de oportunidade de o cliente ou utilizador for-
necer feedback sobre o trabalho que está a ser desenvolvido. (Peterson, 2010)

Os métodos Agile
Desde 1970 que investigadores e gestores têm proposto alternativas à metodologia
Waterfall, com propostas mais interativas ao desenvolvimento de software.

Para produtos com muitas incertezas ou mudanças constantes de conteúdo, a me-

todologia Waterfall não tem capacidade de resposta, e muitas vezes a equipa do pro-
jeto acaba por produzir um produto que não vai ao encontro das necessidades finais
dos utilizadores (Cusumano e Smith, 1995).

Esta rápida mudança de necessidades requer que as organizações sejam cada vez
mais flexíveis nos seus processos.

Neste sentido surgiu no final de 1990, início de 2000, a metodologia de desenvolvi-

mento de software Agile. (Peterson, 2010) A partir de um encontro entre profissio-
nais da indústria do software, em Snowbird, Utah em Fevereiro de 2001, à qual de-
ram o nome de “The Agile Alliance” (Cockburn, 2001).
46 . ESTADO DA ARTE

Cockburn (2001), um dos membros presentes no encontro de 2001, refere o seguin-

te: “we are uncovering better ways of developing software by doing it and helping
others do it.”

No decorrer do encontro foi criado um manifesto, em prol da criação de um softwa-

re de qualidade, que serviu de base para o “Movimento Agile”. O manifesto reconhe-
ce o valor do trabalho desenvolvido anteriormente na indústria de software, desde
ferramentas, a processos, documentação, contratos e planos, defendendo o seguin-
te. “There is no ‘opposite’ to agile methodology, just as there is no opposite to ‘Bengal
tiger’. There are alternatives to agile methodologies, phrased according to their own
value systems: repeatable, deliberate, predictable, even capricious methodologies.”
(Cockburn, 2001)

Segundo Peterson (2010) o manifesto refere 4 valores e 12 princípios que os métodos

de desenvolvimento Agile devem seguir:

V1: Individuals and interactions over processes and tools.

V2: Working software over comprehensive documentation.

V3: Customer collaboration over contract negotiation.

V4: Responding to change over following a plan.

Com base nos 4 valores, os 12 principios a seguir são os seguintes.

P1: Customer satisfaction.

P2: Welcome change.

P3: Frequent deliveries.

P4: Work together.

P5: Motivated individuals.

P6: Face-to-face conversation.

P7: Working software.

P8: Sustainable pace.

P9: Technical excellence.

P10: Simplicity.

P11: Self-organizing teams.

P12: Continuous reflection.

Os métodos Agile reforçam o desenvolvimento de software de forma gradual, reco-

lhendo feedback dos vários intervenientes com o objetivo de satisfazer as necessida-
des dos utilizadores. Com a equipa de desenvolvimento a trabalhar perto do poten-
cial utilizador ou cliente, esta metodologia pretende entregar software funcional de
forma regular ao cliente. Depois de cada entrega ou feedback, esses inputs vão sendo
 ESTADO DA ARTE . 47

Figura 16 - Comparação das metodologias Waterfall e Agile. No desenvolvimento Agile são realizadas
várias etapas com mini-versões do produto (cada uma criada num período de 2-4 semanas). Adaptado
do “Cutter Consortium” (Sy, 2007).

entregues ao cliente nas fases subsequentes. Como refere Ferreira (2007), “At the
beginning of the iteration a set of requirements, or features, is selected and priori-
tised with the customer, after which the developers set about implementing those
features. If, at the end of the iteration, there are still outstanding features to be im-
plemented, then the next iteration is planned and carried out and repeated until the
customer agrees that the required features have been implemented.”

O método Agile tem diferentes abordagens, destas destacam-se duas, o “Extreme

Programming (XP)” e o “Scrum”. “The agile development paradigm consists of a num-
ber of instantiations in the form of agile processes. The most famous representatives
are eXtreme programming (XP) and SCRUM. Both paradigms consist of a set of prin-
ciples, but also describe a workflow and artifacts that are produced in the process.”
(Peterson, 2010)

Agile — Extreme Programming (XP)

Esta abordagem centra-se essencialmente no desenvolvimento em detrimento das
questões de gestão do projeto de software. Todos os projetos começam com um pla-
no de lançamento, seguem-se várias iterações, onde em cada uma delas existe um
teste de aceitação por parte do utilizador. Esta metodologia preza valores como, a
integração constante de alterações, velocidade de execução, programação em pares
e user stories (Serena, 2007). Nomeadamente:

“Integrate often: Development teams must integrate changes into the development
baseline at least once a day. This concept is also called continuous integration.

Project velocity: Velocity is a measure of how much work is getting done on the pro-
ject. This important metric drives release planning and schedule updates.

Pair programming: All code for a production release is created by two people work-
ing together at a single computer. XP proposes that two coders working together
48 . ESTADO DA ARTE

will satisfy user stories at the same rate as two coders working alone, but with much
higher quality.

User story: A user story describes problems to be solved by the system being built.
These stories must be written by the user. User stories do not describe a solution,
use technical language, or contain traditional requirements-speak, such as “shall”
statements.” (Serena, 2007)

Para Cockburn (2001), esta metodologia de desenvolvimento preza quatro valores

principais: Comunicação, simplicidade, testes e coragem. De forma semelhante,
Ferreira (2007), resume os princípios da metodologia em cinco tópicos:

“1 - Communication: In order for the team to cooperate effectively, good communi-

cation is essential. Learning from other team members can help to avoid mistakes
from the past.

2 - Simplicity: … to encourage teams to remove unnecessary complexity and to con-

centrate on producing working software that adhere to today’s requirements, as op-
posed to implementing features that may or may not be required in the future.

3 - Feedback: Not understanding the requirements at the outset of the project, the
team needs to generate feedback cycles that are as short as possible in order to im-
prove the software and get closer to reaching their goals with that software.

4 - Courage: There are several ways in which the value of courage can be fostered on
an XP team. Team members are encouraged to communicate with other team mem-
bers when they see a better way of performing some task. Having the courage to
speak up in such situations is seen as valuable.

5 - Respect. The team members need to respect each other as well as the project
they are working on in order for XP to work. Equality among team members is par-
ticularly vital and no one is seen as more important.” (Ferreira, 2007)

Agile — Scrum
A metodologia Scrum é uma abordagem mais empírica ao desenvolvimento de sof-
tware que aceita que o um desenvolvimento de software não seja linear, com neces-
sidades de inspeção e reajustamento constante. “Due to the unpredictable nature of
software development, Scrum consists of activities that manage tasks such as back-
log, work, risk, issues, problems and changes so that after each iteration the deliv-
ered solution, as a product of time, cost, functionality and quality, is the best one
possible.” (Ferreira, 2007)

Contrariamente ao Extreme Programming o Scrum lida com processos de gestão e

de desenvolvimento. Esta metodologia surgiu da necessidade de criar um ambiente
em que os requisitos iniciais incompletos pudessem ser alterados durante o desen-
volvimento do produto. (Serena, 2007)
 ESTADO DA ARTE . 49

À semelhança das User Stories da metodologia “XP”, no “Scrum” existem os Backlog

items que podem ser definidos como os atributos do projeto que vão ser desenvolvi-
dos durante a primeira fase do projeto. (Ferreira, 2007)

Os Backlog items devem ser definidos durante o planeamento do âmbito do proje-

to. Depois de definido o âmbito do projeto e os desenhos de alto nível, a equipa do
projeto divide o processo de desenvolvimento numa série de pequenas interações
chamadas Sprints. Cada Sprint identifica que items vão ser implementados e após o
Sprint é verificado o progresso do projeto e as lições aprendidas para as fases pos-
teriores. Durante os Sprints a equipa realiza uma reunião diária chamada Scrum.
Nesta reunião é apresentado o trabalho a realizar nesse dia, o que foi feito e dúvidas
a esclarecer. (Serena, 2007)

Até ao fim de cada Sprint o produto é apresentado ao cliente durante uma sessão de
demonstração. Após esta apresentação, os Backlog items são reorganizados e come-
ça um novo Sprint (Ferreira, 2007). O fecho do projeto, termina quando o produto é
considerado preparado para ser entregue ao cliente. Fase que inclui ainda os teste
ao produto e a finalização de documentação. (Ferreira, 2007)

O processo Lean
O termo Lean foi utilizado pela primeira vez em 1991 por James Womack, Daniel
Jones e Daniel Roos no livro “The Machine that Changed the World: The Story of
Lean Production” e desenvolvido a partir da abordagem de gestão usada pela Toyota
na indústria automóvel (Anderson, 2011). A abordagem Lean da indústria automóvel
foca-se exclusivamente na eliminação do desperdício do processo produtivo. Onde
desperdício é definido como tudo o que não contribui para a criação de valor para o
cliente (Petersen, 2010).

Aplicado ao desenvolvimento de software, o termo Lean, só foi utilizado pela pri-

meira vez em Outubro de 1992, intitulando a conferência organizada pela União
Europeia em Estugarda, Alemanha, pela iniciativa “ESPRIT”(Anderson, 2011).

Petersen (2010), chama ainda a atenção para os vários livros publicados por Mary e
Tom Poppendieck sobre a aplicação prática do Lean manufacturing no contexto da
engenharia de software.

Princípios Lean
O Lean Software Development não é considerado um método ou processo como o
Waterfall ou o Agile. Um processo de desenvolvimento de software para ser con-
siderado Lean deve estar alinhado com os princípios e valores do movimento Lean
Software Development:
50 . ESTADO DA ARTE

“There are several schools of thought within Lean Software Development. The larg-
est, and arguably leading, school is the Lean-Systems Society which is based on the
Kanban Method. Mary and Tom Poppendieck’s work stands separately, as does the
work of Craig Larman, Bas Vodde, and, most recently, Jim Coplien.” (Anderson, 2011)

De acordo com as publicações da conferência da “Lean Systems Society” de 2011, o

Lean Software Development segue os seguintes valores:

- Aceitar a condição humana;

- Aceitar que a complexidade e incerteza são naturais para o trabalho intelectual;

- Trabalhar no sentido de um melhor resultado económico;

- Permitir um melhor resultado sociológico;

- Procurar, abraçar e questionar ideias de uma vasta gama de disciplinas;

- Uma comunidade baseada em valores, aumenta a velocidade e profundidade da

mudança positiva.

Segundo Anderson (2011) a “Lean Systems Society” defende ainda 8 princípios que
devem sustentar o Lean Software Development.

1. Seguir um pensamento sistémico e uma abordagem de design

Devemos considerar no sistema as exigências feitas por todos os interessados, no-

meadamente os clientes e o resultado desejado que esperam do produto. “Demand
will include so-called ‘value demand’ for which customers are willing to pay, and
“failure demand,” which is typically rework. Failure demand often takes two forms:
rework on previously delivered value demand and additional services or support due
to a failure in supplying value demand.”

2. Resultados emergentes podem influenciar a arquitetura do contexto para um

sistema complexo adaptativo

Nos processos de desenvolvimento de software as regras simples dos sistemas adap-

tativos complexos são as políticas que compõem a definição do processo. “…the be-
lief that developing software products and services is not a deterministic activity,
and hence a defined process that cannot adapt itself will not be an adequate re-
sponse to unforeseable events.”

3. Respeitar as pessoas

A comunidade Lean adota a definição de Peter Drucker sobre conhecimento do tra-

balho, “workers are knowledge workers if they are more knowledgeable about the
work they perform than their bosses.” A voz das pessoas deve ser ouvida e as equipas
devem estar habilitadas a auto organizarem-se para concluir o trabalho e alcançar os
 ESTADO DA ARTE . 51

resultados pretendidos. Além disso, as pessoas devem poder sugerir melhorias aos
processos e saber quais são as políticas que devem seguir.

4. Utilizar o método científico

Deve-se procurar usar modelos para perceber as dinâmicas de trabalho e o seu fun-
cionamento. Devemos recolher dados quantitativos e usá-los para perceber como o
sistema está a funcionar e prever como pode mudar quando se efetuar alterações.

5. Incentivar a liderança

A liderança e a gestão não são a mesma coisa.

“Management is the activity of designing processes, creating, modifying, and de-

leting policy, making strategic and operational decisions, gathering resources, pro-
viding finance and facilities, and communicating information about context such as
strategy, goals, and desired outcomes. Leadership is about vision, strategy, tactics,
courage, innovation, judgment, advocacy, and many more attributes.”

6. Gerar visibilidade

“Knowledge work is invisible.” Tudo o que não se consiga ver é difícil de gerir. É ne-
cessário criar visibilidade a todo o processo e ao trabalho que decorre entre as várias
pessoas. É impossível criar um processo colaborativo se os fluxos de trabalho forem
invisíveis e as políticas não forem explícitas.

7. Reduzir o fluxo de tempo

Tradicionalmente o desenvolvimento de software foca-se na medição do tempo dis-

pensado a trabalhar numa determinada atividade. A comunidade Lean descobriu que
pode ser mais útil medir o tempo de um ciclo (Cycle Time), ou seja, o tempo decorri-
do que um determinado trabalho demora a ser processado. “For example, Cycle Time
through Analysis to Ready for Deployment would measure the total elapsed time for a
work item, such as a user story, to be analyzed, designed, developed, tested in sever-
al ways, and queued ready for deployment to a production environment.” Focar-se no
tempo que determinado trabalho demora a percorrer o fluxo do processo é importan-
te na qualidade inicial do trabalho, como sugerem as evidências empíricas.

8. Reduzir o desperdício para melhorar a eficiência

Todos os custos de coordenação, como reuniões para determinar o estado do pro-

jeto e para agendar ou atribuir trabalho aos membros da equipa, é considerado des-
perdício no pensamento Lean.
52 . ESTADO DA ARTE

No desenvolvimento de software, o método lean, procura eliminar ou reduzir os cus-

tos de coordenação através, da colocação dos membros da equipa em reuniões cur-
tas cara-a-cara e com controladores visuais, como cartões nas paredes.

Contudo, as falhas são as formas mais comuns de desperdício apontadas pelo pensa-
mento Lean. Tipicamente, as falhas levam a que se refaça trabalho devido à falta de
qualidade do trabalho já realizado.

Apesar de pequenas diferenças conceptuais, também outros autores reforçam a uti-

lidade de alguns dos princípios enunciados. Petersen (2010) diz-nos o seguinte, “…
lean software development does not propose a workflow or the production of spe-
cific artifacts. Rather lean states principles and provides analysis tools for process-
es to guide engineers in improving their processes to achieve a good flow of value.”
Neste sentido, descreve 7 princípios do contexto Lean que segundo o autor devem ser
seguidos para alcançar os objetivos pretendidos.

Lean UX
O Lean UX (User eXperience) é uma abordagem ao desenvolvimento de software
criado a partir do movimento Lean Startup fundado por Eric Ries. Ries desenvolveu
uma nova metodologia para o mundo das startups a partir da metodologia Lean da
industria automóvel Japonesa.

O movimento Lean UX descrito por Gothelf (2013), faz referência à metodologia Agile
e a algumas técnicas do design de interação, tornando-se pertinente fazer uma ex-
posição desse ponto de vista.

A internet mudou a forma como se distribui software. O lançamento de novas ver-

sões dos produtos já não é realizada anualmente e num suporte físico, mas distribí-
da online e com ciclos de desenvolvimento cada vez mais curtos.

A concorrência é elevada e muitas equipas de desenvolvimento de software estão

a recorrer a diferentes técnicas que aceleram os resultados, como as metodologias
Agile, integração contínua e implementação contínua. E os ciclos curtos de desen-
volvimento estão a ser usados como vantagem competitiva entre as empresas.

O Lean UX é a evolução, diz-nos Gothelf (2013). O Lean UX é profundamente colabo-

rativo. Não há trabalho isolado, mas há necessidade de trabalho diário e resposta ac-
tiva à equipa para que haja eficácia. Podemos prescindir das grandes entregas e pas-
sar a construir entendimento partilhado (Shared understanding).

O Lean UX muda também a maneira como se fala de design. Em vez de se falar de

atributos e documentos, fá-la se em funcionamento. Mais do que nunca temos aces-
so ao feedback do mercado e podemos reformular as conversas sobre design em ter-
mos de objectivos de negócio. Podemos medir o que funciona, aprender e ajustar.
 ESTADO DA ARTE . 53

Segundo Gothelf (2013), o Lean UX tem por base 3 fundamentos que guiam todo o
processo de desenvolvimento de software desta abordagem.

1. Pensamento de design

Tim Brown, CEO e presidente da IDEO, citado por Gothelf (2013), descreve o pensa-
mento de design da seguinte forma: “innovation powered by… direct observation of
what people want and need in their lives and what they like or dislike about the way
particular products are made, packaged, marketed, sold, and supported… [It’s] a dis-
cipline that uses the designer’s sensibility and methods to match people’s needs with
what is technologically feasible and what a viable business stately can convert into
customer value and market opportunity”.

O pensamento de design encoraja as equipas a colaborar entre diferentes cargos.

2. Desenvolvimento de software Agile

De forma a reduzir os ciclos de desenvolvimento e a entregar valor ao cliente de for-

ma contínua, os programadores usam métodos Agile à vários anos. Os métodos Agile
estão no centro da mentalidade Lean UX.

O Lean UX aplica os 4 princípios base do desenvolvimento Agile:

Indivíduos e interações acima de processos e ferramentas; Software a funcionar aci-

ma de documentação exaustiva; Colaboração com o cliente acima de negociações
contratuais; Responder à mudança acima de seguir um plano.

3. Método Lean Startup

O Lean Startup utiliza um ciclo de feedback chamado, “constrói-mede-apren-

de” (Build-Measure-Learn) para minimizar o risco do projeto e construir e apren-
der rapidamente. As equipas criam o chamado produto minimamente viável (MVP
- Minimum Viable Product) que testa rapidamente a ideia no mercado e inicia o pro-
cesso de aprendizagem o mais cedo possível.

No Lean UX cada design é uma solução de negócio, ou seja, uma hipótese e o objeti-
vo é validar de forma eficiente a solução proposta com o feedback do cliente.

Qualquer coisa que se construa para testar uma hipótese é um “MVP”. Este não ne-
cessita de ser código, pode ser apenas uma aproximação da experiência final.

Gothelf (2013), caracteriza ainda o Lean UX como uma viagem que deve obedecer a
15 princípios.

1. Equipas multidisciplinares: O elevado nível de colaboração entre todos os inter-

venientes, contribui para a eliminação de barreiras entre funções e para uma maior
eficiência.
54 . ESTADO DA ARTE

2. Equipas pequenas, dedicadas e localizadas: Manter as equipas pequenas (<=10

elementos ), dedicadas a um só projeto e no mesmo local. Permitindo maior comu-
nicação, foco e camaradagem.

3. Progresso = Resultados e não saídas (outputs): O Lean UX mede o progresso com

resultados de negócio. Os resultados medem a eficácia das funcionalidades que são
construídas.

4. Equipas focadas nos problemas: Como extensão do foco em resultados, as equi-

pas devem estar focadas na resolução do problema e não na implementação de uma
série de funcionalidades.

5. Eliminar o desperdício: Tudo o que não contribua para o objetivo final deve ser
removido do processo. Quanto mais desperdício for eliminado mais rapidamente se
pode avançar.

6. Lotes de dimensões reduzidas: Apenas deve ser criado o desenho que faça a equi-
pa avançar. Deve-se evitar acumular desenhos e ideias não testadas e implementadas.
Grandes quantidades de desenhos tornam as equipas menos eficientes fazendo-as es-
perar por grandes entregas de desenhos.

7. Descoberta contínua: Envolver o cliente durante o processo de design e desen-

volvimento. Devem ser agendadas atividades para descobrir o que os utilizadores fa-
zem com os produtos e porque o fazem. Conversas regulares com os clientes forne-
cem oportunidades para validar novas ideias do produto.

8. GOOB (Getting out of the building): As reuniões sobre as necessidades dos utiliza-
dores não devem ser feitas apenas dentro do escritório. As respostas estão no mer-
cado e fora do escritório.

9. Entendimento compartilhado: O entendimento compartilhado é o conhecimen-

to coletivo que a equipa vai construindo ao longo do projeto. Quanto mais coletiva-
mente uma equipa entender o que está a fazer e porquê, menos tem de depender de
relatórios e documentos detalhados.

10. Anti-padrões, Rockstars e Gurus: O Lean UX aconselha a um espírito de equi-

pa e colaboração entre elementos. Rockstars e gurus, quebram o espírito de equipa.
Pessoas com grandes “egos” normalmente tentam sobressair. Quebrar o espírito de
equipa e a colaboração entre elementos faz com que se perca também o ambiente
para criar um entendimento compartilhado.

11. Exteriorizar o trabalho: Exteriorizar quer dizer, fazer sair o trabalho da cabeça e
do computador e torná-lo público. As equipas normalmente utilizam quadros brancos,
post-its, ou impressões para demostrar o progresso do trabalho. Esta forma de traba-
lhar, cria um fluxo de informação entre os membros da equipa, e inspira novas ideias.

12. Fazer, acima de analisar: É mais valioso criar a primeira versão da ideia do que
passar uma tarde a debater essa mesma ideia. As ideias devem torna-se concretas,
uma vez que a resposta à maior parte das perguntas é fornecida pelos clientes e não
por debates em salas de reuniões.
 ESTADO DA ARTE . 55

13. Aprender acima de crescer: Saber o que construir e saber como dar escala a um
negócio são coisas difíceis de conciliar. O Lean UX foca-se primeiro na aprendizagem
e verificação de uma ideia e só depois em dar escala às ideias. Por forma a não desper-
diçar recursos, é melhor saber se uma ideia está correta antes de dar escala à mesma.

14. Permissão para errar: Para procurar as melhores soluções é necessário experi-
mentar uma vez que a maioria destas soluções pode estar errada. As equipas devem
ter permissão para falhar se querem alcançar o sucesso. A permissão para falhar cria
uma cultura de experimentação, a experimentação gera criatividade e a criativida-
de gera inovação.

15. Abandonar o negócio de entregas: O importante são os resultados alcançados e

não a documentação criada. A documentação não resolve o problema do cliente, mas
o produto resolve. O foco da equipa deve ser na aprendizagem daquilo que realmen-
te interessa ao cliente.

O Lean UX é um processo colaborativo, que junta designers e não designers na co-cria-

ção. É uma oportunidade de todas as opiniões fazerem parte do processo desde início,
criando um sentido de pertença sobre o trabalho.

A colaboração gera melhores resultados do que o trabalho criado com base em heróis
(“The practice of calling in a designer or design team to drop in, come up with some-
thing beautiful, and take off to rescue the next project”). As ideias de todos, dão ao de-
signer um leque maior de ideias sobre as quais trabalhar a experiência do utilizador.

O design colaborativo cria um entendimento compartilhado na equipa, o que faz

com que seja necessária menos documentação para fazer o projeto avançar. O de-
signer tem a responsabilidade de gerar o design colaborativo, através de reuniões
onde ele deve se rum facilitador. “In a typical collaborative design session, teams
sketch together, critique the work as it emerges, and ultimately converge on a solu-
tion that they feel has the greatest chance of success. Thr designer, while still pro-
ducing designs, takes on the additional role of facilitator to lead the team through a
series of exercises.”

O resultado destas sessões de design colaborativo são desenhos de baixa fidelidade.

A baixa qualidade é fundamental para manter maleabilidade no trabalho e permitir
mudar de ideia facilmente.
56 . ESTADO DA ARTE
 ESTADO DA ARTE . 57

4. A integração do Design de
interação nas metodologias Agile
As metodologias Agile eram inicialmente métodos para programação e por isso tem
alguma dificuldade a integrar não programadores nas equipas de desenvolvimento
(Rannikko, 2011). Este é um problema que afeta o resultado final do produto, uma vez
que é colocado mais ênfase na construção interna do programa do que no desenho
externo (Kapor, 1996). Na maior parte dos casos, a perspetiva e as competências crí-
ticas para um bom design estão ausentes do processo de desenvolvimento (Kapor,
1996). “As a result, it often overlooks interaction design and usability, which are left
to happen as a side effect of the coding. This, of course, contradicts all experience
of the last 30 years, in which user experience’s importance in system development
has steadily increased as we moved from mainframes to PCs to the Web. As the user
base and the use cases have expanded, the need for top-notch usability has grown.”
(Nielsen, 2008)

O design centrado no utilizador (UCD) e os métodos de desenvolvimento de softwa-

re Agile, são abordagens interativas que podem aumentar as hipóteses de um projeto
ter sucesso. Enquanto os métodos UCD consideram a pesquisa sobre os utilizadores
e envolvem os mesmos no processo interativo de design e avaliação do produto em
diferentes níveis de fidelidade. Antes da fase de implementação, os métodos Agile fo-
cam-se principalmente na construção e lançamento de pequenas partes do sistema
maior a desenvolver (Rannikko, 2011).

Não existem dúvidas, de que o design de interação deve ser parte integrante das me-
todologias de desenvolvimento de software. Embora tenham perspetivas diferen-
tes, tanto as metodologias Agile como o design de interação, pretendem desenvolver
software de qualidade adequado às necessidades dos utilizadores (Ferreira, 2007).

Porém, segundo Ferreira (2007), existem alguns conceitos que tornam diferente a
forma como os dois métodos se integram no desenvolvimento de software. O pri-
meiro diz respeito à fase em que o design de interação deve ser integrado no pro-
cesso de desenvolvimento de software. “... interaction designers assume that all the
requirements are known up front and consequently, their design incorporates all
the tasks that users will require when using the product. This can be referred to
as a holistic approach. Agile development, on the other hand, encourages develop-
ers to begin implementation at the start of the development project, acknowledg-
ing that every requirement will not be known up front, and that new requirements
may emerge during the software development effort — hence the need for an itera-
tive approach, to allow new requirements to be built into the product. This is known
as incremental development.”

O segundo conceito, diz respeito ao chamado Big Design Up Front, ou seja, a gran-
de fase do design inicial que deve ser desenvolvida antes da implementação, criando
espaço para a descoberta. “Like Norman, influential interaction design gurus Cooper
58 . ESTADO DA ARTE

and Constantine and Lockwood advocate interaction design activities such as user
research, user modeling and prototyping, as occurring ‘up front’ on a software de-
velopment project, i.e., before the coding activities begin. Cooper sees interaction
design as part of the planning aspect of software development: I’m advocating inter-
action design, which is much more akin to requirements planning than it is to inter-
face design [..] the behavioral issues need to be addressed before construction be-
gins. (Ferreira, 2007)

… the user-centered approach to interaction design advocates an intensive up-front

user research period, followed by iterative evaluations of designs with users — often
referred to as Big Design Up Front. The Portland Pattern Repository describes BDUF:
“The term Big Design Up Front is commonly used to describe methods of software
development where a ‘big’ design is created before coding and testing takes place.”
Fixing the requirements up front in the form of a design belongs to the realm of pre-
dictive methods — precisely the approach to software development that agile meth-
ods were intended to counter. (Ferreira, 2007)

As metodologias de desenvolvimento Agile não abordam a análise de requisitos (Bayer,

Holtzblatt, & Baker, 2004). A equipa espera que o cliente entregue os requisitos, e caso
isso não funcione, a equipa constrói algo e pergunta se o resultado é o que o cliente
espera. Desta forma as metodologias Agile favorecem modelações pequenas feitas no
momento, em vez da grande fase inicial de design, que pode significar esforço desne-
cessário quando os requisitos mudam. (Rannikko, 2011)

Uma terceira divergência de conceitos, diz respeito à perspetiva em relação ao cliente

(customer) na metodologia Agile e ao utilizador (user) no design de interação. “Whereas
agile development involves the customer to ensure all the required functionality has
been implemented, interaction design adds the dimension of user satisfaction, i.e.,
does the user have a satisfying experience interacting with the product.” (Ferreira,
2007)

Enquanto o design centrado no utilizador vê os utilizadores como as pessoas que

usam o software e que participam na fase de recolha de requisitos, através de en-
trevistas, estudos de campo e na avaliação do design e sua implementação através
de testes de usabilidade. O desenvolvimento Agile, apesar de valorizar a colabora-
ção com utilizadores e considera a participação dos interessados no processo como
a forma mais efetiva de comunicar as necessidades aos programadores. Neste caso
um interessado tanto pode ser um utilizador final do produto, como um especialista
da área ou o dono do produto (product owner) que representa o cliente e pode nunca
usar o software. (Rannikko, 2011) “Agile development focuses on satisfying the cus-
tomer’s needs and changing business requirements but leads to problems if there is
no one on the team that can truly represent the end-user” (Nodder & Nielsen, 2009)

Enquanto o design de interação interage com uma representação, normalmente um

protótipo do produto a ser desenvolvido, o desenvolvimento Agile interage com o
produto final. (Ferreira, 2007)
 ESTADO DA ARTE . 59

Na perspetiva do design de interação, a prototipagem é o passo necessário para aju-

dar a materializar toda a recolha feita na primeira fase do trabalho (um output das
ideias recolhidas). A sua função principal não é fazer coisas que funcionem ou que
possam ser construídas. Mas desenhar conceitos rápidos suficientes para servirem
de base à discussão, avaliação e questionamento (Buxton, 2003). Esta não é uma fase
isolada. Deve estar muito ligada à recolha feita junto dos utilizadores e à fase pos-
terior de discussão de resultados, pois a sua finalidade é acelarar o feedback e as fa-
lhas. (Rodrigues, Jacoby, 2007)

Porém, trabalhar sobre um protótipo ou sobre o produto real é diferente e como re-
fere Rannikko (2011), os diferentes níveis de fidelidade fornecem informações di-
ferentes. “Studies have shown that the higher the fidelity of the prototype used to
evaluate a product’s interaction design, the more reliably the user’s behaviour with
respect to the interaction design can be captured, i.e., the prototype should be “as
realistic as possible”. (Ferreira, 2007)

O facto de o design de interação e a perspetiva de design centrada no utilizador, se

focar no utilizador final, pode ser fundamental para combinar o design de interação
e o desenvolvimento de software Agile (Ferreira, 2007). Alan Cooper sugere: “…the
interaction designer acts a bridge between the customer and the developers, or pro-
grammers: During the design phase, the interaction designer works closely with the
customers. During the detailed design phase, the interaction designer works closely
with the programmers. (Ferreira, 2007)

Lynn Miller, citado por Ferreira (2007), diz existir experiências na gestão de proje-
tos em que o design de interação é de grande importância para o desenvolvimento
de software: “The approach sees the interaction design and the programming done
in parallel, but one iteration out of phase. In this way, the interaction designers were
doing detailed design for the iteration that the developers would do next, and doing
evaluation of the iteration that the programmers did last.”
 CAPÍTULO II
OBJETIVOS
 OBJETIVOS . 63

Objetivos e Metodologias
Os produtos digitais fazem parte da nossa cultura, e nos últimos 30 anos têm so-
frido mudanças incríveis na forma como se integram no nosso quotidiano. Importa
saber como é que esta proliferação pode fazer sentido nas nossas vidas. O design
como processo de descoberta e potenciador de soluções tem um papel importante
na orientação e mediação desta interação homem/máquina.

Criar produtos digitais, deixou de ser uma atividade onde a tecnológica se assu-
me como elemento principal e exclusiva de uma pequeno grupo de especialistas.
A quantidade e diversidade da oferta, criam ruído e dificultam as nossas escolhas.
Criar um produto e esperar que os utilizadores apareçam ou que o utilizem com sa-
tisfação e eficácia, deixou de ser um dado adquirido. Perante a diversidade e quanti-
dade da oferta, as pessoas fidelizam-se aos produtos que lhes proporcionam melho-
res experiências e lhes permitem atingir objetivos com menor grau de dificuldade.

É objetivo deste documento, dissertar sobre o papel do design de interação no de-

senvolvimento de produtos digitais em contexto de estágio, numa organização em
que a sua atividade principal há 15 anos é a criação de software. O trabalho desenvol-
vido, demonstra através de dois projetos práticos, abordagens e metodologias dife-
rentes para a descoberta e definição de dois problemas internos da Critical Software.

Por ser na sua origem uma atividade ligada à engenharia informática, a criação de
produtos digitais tem demonstrado ao longo da sua história uma grande preocupa-
ção pela forma como são construídos e como são enquadrados nas metodologias de
desenvolvimento. Não que essa seja uma influência negativa, mas os produtos digitais
deixaram de pertencer a um nicho e tornaram-se de massas. Independentemente do
contexto em que interagimos com produtos digitais, esperamos sempre que a nossa
experiência com eles seja a melhor possível. (Kapor, 1996)

A experiência das pessoas com os produtos digitais, tem sido um desses elemen-
tos de diferenciação e motivo de estudo de vários autores. As pessoas, os seus com-
portamentos, hábitos e o que as move, passaram a ser o centro da preocupação de
quem desenha produtos digitais. É fundamental criar experiências positivas e dura-
douras. Como referem Brown e Ratz (2009) no livro “Change by Design”, o design tem
influenciado a criação de produtos digitais, fornecendo a relação humana que falta-
va com os produtos tecnológicos.

Reforçando este ponto de vista, Harry Saddler refere que a preocupação com as pes-
soas, descobrir e responder às suas necessidades, não é uma opção. O design de in-
teração é uma disciplina onde as pessoas participam muito depois do nosso traba-
lho estar concluído.

Os vários autores da área não têm dúvidas de que as pessoas devem ser o centro das
atenções quando criamos produtos digitais. Mas como fazer disso parte do proces-
so de desenho? Afinal como podemos entender as pessoas e trazer informação útil
para o desenho de produtos digitais?
64 . OBJETIVOS

Esta é sem dúvida uma tarefa complexa. Mesmo sendo centrais no processo e a ra-
zão de existência de grande parte dos produtos digitais, como referem Moggridge,
Cooper, Reinmann e Cronin, poucas pessoas são capazes de articular e expressar as
suas necessidades, e se essa solução ainda não foi pensada, logo não pode ser expli-
cada. A frase da autoria de Henry Ford: “Se eu perguntasse aos meus clientes o que
eles queriam, eles teriam dito, um cavalo mais rápido”, faz todo o sentido ser reen-
quadrada neste trabalho, pois resume bem a natureza humana ao lidar com proble-
mas complexos, para os quais não tem resposta.

O design centrado no utilizador, com ênfase no utilizador final dos produtos, pode
ser uma das respostas para a criação de soluções mais utilizáveis e que satisfaçam as
necessidades dos utilizadores finais (Rannikko, 2011). Para que isso aconteça, como
referem Cooper et al. (2007) o designer deve fazer parte da pesquisa, procurando sa-
ber mais sobre os utilizadores e o seu contexto e depois fazer essa ligação com os
desenhos que produz. Os mesmo autores referem ainda que a exposição intensiva
aos utilizadores que uma atividade de pesquisa exige, é ideal para que os designers
entrem no mundo dos utilizadores.

A abordagem de design centrada no utilizador não é um processo completo para de-

senvolver software, pois necessita de ser integrada numa metodologia de desenvol-
vimento de software para cobrir todo o ciclo de desenvolvimento (Rannikko, 2011).
Mesmo assim, neste estudo é a abordagem centrada no utilizador que vai ser utiliza-
da para definir e descobrir soluções para os problemas propostos juntamente com
algumas técnicas de prototipagem.

Este trabalho de prototipagem, num processo de descoberta e tentativa erro, vai

ser utilizado para descobrir o mais cedo possível informação sobre os utilizadores
(Buxton e Katz, 2009). Num processo de descoberta, onde se arriscam soluções e o
erro é constante, são as interações constantes que aumentam a quantidade de infor-
mação sobre o utilizador. É preciso tentar muitas vezes e fazer com que cada passo
seja um pouco mais realista (Moggridge, 2007).

Os protótipos vão permitir tornar as várias ideias tangíveis testando também com os
futuros utilizadores alguns conceitos (Brown e Katz, 2009).

Não sendo um processo isolado do desenvolvimento de software, a referência às

metodologias de desenvolvimento de software, como o Waterfall, Agile e Lean, pre-
tendem dar uma perspetiva geral da forma como o design é ou não integrado no de-
senvolvimento de software.

Estas três metodologias, com pontos de contacto, representam uma evolução em

função do desenvolvimento de software de qualidade. Cada uma delas revela uma
necessidade maior de se complementar com outras áreas que lhes permita o resul-
tado cada vez melhor. Nesse resultado está a satisfação dos utilizadores dos seus
produtos, embora essa satisfação seja uma das preocupações, o desenvolvimento de
software ainda pouco aborda a forma como entende os problemas das pessoas para
a quais cria produtos. A construção do produto, ainda se sobrepões muitas vezes à
definição do problema.
 OBJETIVOS . 65

Como refere Buxton (2003), “My perspective is that the bulk of our industry is or-
ganized around the demonstrable myth that we know what we want at the start, and
how to get it, and therefore build our process assuming that we will take an optimal,
direct path to get there.“ A isto acresce o facto, de que o que distinguia um produto
digital nos anos 80 do século XX, já não fazer sentido na segunda década do século
XXI. As empresas necessitam de elementos de diferenciação perante a inovação da
concorrência e as expetativas cada vez mais altas das pessoas.

Desde os primeiros tempos, na indústria do software existe o entendimento geral de

que fazer software é eminentemente uma actividade tecnológica. E por isso, tradi-
cionalmente, todas as fases são comandadas por pessoas de engenharia e gestão do
projecto. A engenharia informática centra-se em criar o melhor código para deter-
minado problema e a gestão de projecto preocupa-se em fazê-lo no mais curto tem-
po e curto orçamento (para, dessa forma maximizar as margens de lucro).

Assim, a fase de levantamento de requisitos em waterfall, costuma ser uma fase con-
duzida pela engenharia informática, tradicionalmente muito mal preparada para
compreender os seus futuros utilizadores e que soluções lhes seriam mais conve-
nientes. A fase de levantamento de requisitos é geralmente uma fase tendencialmen-
te curta e com recurso a métodos totalmente desadequados à descoberta e ao expe-
rimentalismo, que - em boa verdade - é residual.

À falta de um período experimentalista e de prototipagem inicial (i.e., a fase de le-

vantamento/descoberta de requisitos) a tecnologia produz o que sabe fazer melhor:
produz especificações técnicas de soluções para problemas que estão, tipicamente,
muito mal estudados. Dessa forma todo o waterfall se transforma num longo e dis-
pendioso protótipo, cujo primeiro contacto com a realidade ocorre apenas nas fa-
ses terminais do projecto.

Acresce que por influencia da gestão de projecto, por uma natural tendência para a
reutilização de estruturas de código já provadas no passado, por uma natural ten-
dência para foco na abstracção tecnológica em preferência do estudo das pessoas
que irão usar os seus sistemas, a engenharia tende a usar as mesmas fórmulas para
quase todo e qualquer problema que lhes seja colocado. A falta de estudo, com-
preensão, formulação de hipóteses, de teste dessas hipóteses na fase de levanta-
mento de requisitos é a maior e - talvez única - razão para os contínuos insucessos
das metodologias waterfall.

O que acontece com muita frequência é essas necessidades dos utilizadores torna-
rem-se óbvias no momento em que se coloca o sistema - acabado de construir - em
ambiente de funcionamento real. Desta forma, o próprio software é o seu próprio
protótipo, e naturalmente, tudo aquilo que se deveria ter descoberto nas fases ini-
ciais do projecto revela-se com muita visibilidade… no fim do projecto.

As razões para a falha sucessiva da metodologia waterfall, não está no seu formato
nem no seu racional, mas sim na forma como é tipicamente executado. O design de
interacção é a disciplina que falta, principalmente na fase de “requisitos”, para liderar
66 . OBJETIVOS

e conduzir o trabalho de descoberta e teste de soluções que, em ultima análise, de-

riva nos requisitos do sistema a ser construído.

Este estudo pretende descobrir com exemplos práticos, como é que algumas ferra-
mentas e metodologias do design de interação, podem ajudar a definir problemas e
a descobrir soluções para esses problemas, sempre com o utilizador no centro do
processo. É objetivo, assim, procurar um entendimento para um problema, de base
humana sem envolver qualquer racional construtivo de um produto digital que pos-
sa afetar a descoberta e a verdadeira origem do problema.

Metodologias

Perante a evidência de que os produtos digitais devem satisfazer as necessidades

dos utilizadores finais e tornar a sua experiência agradável, a metodologias utiliza-
das pelo design centrado nos utilizadores são as mais adequadas para abordar na
prática os problemas apresentados pela Critical Software.

Os trabalhos de Brown e Ratz (2009), Cooper et al. (2007) e Moggridge (2007), refe-
rem o design centrado no utilizador com várias metodologias que colocam os utili-
zador no centro do processo, como parte fundamental e complementar ao desen-
volvimento de software de qualidade.

Esta é a abordagem que vai ser testada, não só por envolver o utilizador com entre-
vistas, questionários, sessões de desenho colaborativo e revisão de protótipos, mas
por ser uma abordagem livre e maleável, em que a representação de conceitos vi-
suais vai facilitar o diálogo entre os vários intervenientes.

Durante esta abordagem, serão utilizados desenhos como mediadores do processo

de comunicação, para exteriorizar o pensamento e criar um entendimento partilha-
do dos problemas. Outra das vantagens deste tipo de trabalho, é a rapidez com que
se apresentam soluções para discussão e a maleabilidade dessa soluções. Nas fases
iniciais, os desenhos podem ser totalmente refeitos de etapa para etapa sem gran-
des custos e perdas de tempo.

Por ser uma fase de descoberta e entendimento do problema, dos utilizadores e do

seu contexto, a criação de desenhos tomará sempre a forma de fluxos e protótipos
não funcionais. Desta forma, pretende-se testar vários conceitos de um futuro pro-
duto, enquanto se vai descobrindo se o problema está efetivamente a ser resolvido.

O objetivo é que o problema das pessoas possa ser resolvido utilizando um produto
digital como ferramenta para a sua resolução. Entende-se que só com uma fase pro-
jetual de experimentação livre, é que se pode discutir e descobrir as melhores solu-
ções para esse problema.
 OBJETIVOS . 67

A construção do produto digital é um processo importante, mas quanto mais solu-

ções forem pensadas e testadas para os problemas antes da sua construção, maior
será a probabilidade de criar produtos de qualidade.

Soluções perfeitas não existem, e as incertezas dominam qualquer atividade huma-

na, a experimentação livre com testes e eliminação de várias hipóteses, pode e deve
contribuir para um processo construtivo mais seguro e com menos indefinição.
 CAPÍTULO III
TRABALHO PRÁTICO
 TRABALHO PRÁTICO . 71

Contexto

Figura 17 - Sede da Critical Software em Coimbra.

A Critical Software é uma empresa que cria e implementa soluções de software cri-
tico, que garantem suporte para funções operacionais chave. Cria ferramentas de
software para proteger as pessoas, controla a segurança de equipamento e assegu-
ra que os processos críticos são conduzidos de forma segura e eficiente. (“crítico” no
sentido de que não pode falhar, sob pena de ocorrerem elevados danos e prejuízos)

Fundada em 1998 em Coimbra, desde o seu início tem procurado marcar a diferença
através da qualidade e inovação dos sistemas de informação que desenvolve para os
clientes. A qualidade dos seus sistemas é uma das suas vantagens competitivas desde
o início e o sistema de controlo de qualidade da empresa é certificado com os mais
exigentes standards da engenharia.

Atualmente possui escritórios em Coimbra, Lisboa, Porto, Chicago (USA), Southampton

(UK), São Paulo (Brasil), Maputo (Moçambique), Luanda (Angola), Singapura (Singapura)
e Frankfurt (Alemanha). Esta cultura internacional tem permitido à empresa o sucesso
necessário para lidar com mercados globais e um crescimento anual de 21%, com 70%
do seu volume de negócios proveniente de exportações.

Trabalhando em diversos mercados, a Critical Software possui um conjunto de co-

laboradores experientes de alta qualidade, capazes de ajudar os clientes a alcançar e
manter o sucesso nos seus empreendimentos tecnológicos. Tem cerca de 250 cola-
boradores, na sua maioria da área da engenharia Informática e de Software. Destes,
cerca de 16%, possuem doutoramento ou mestrado.

Oferece soluções para sistemas de informação críticos em vários mercados, como

a Aeronáutica, Espaço, Defesa, Transportes, Produção, Telecomunicações, Banca,
Saúde, Governo, Energia e Mobilidade, etc. (Critical, 2013)
72 . TRABALHO PRÁTICO

O Design de Interação na Critical Software

O Design de Interação ou User Experience Design (UXD), é uma nova área de es-
pecialização da Crirical Software, com uma equipa de designers a ser constituída à
cerca de 2 anos. O seu principal objectivo é transformar as necessidades dos seus
clientes em soluções utilitárias, optimizando os interfaces para maximizar a utiliza-
ção dos mesmos. Não se trata tanto de um trabalho de design gráfico mas de “expe-
riência de utilização”.

Esta preocupação, com a experiência de utilização, procura satisfazer ao máximo

os clientes com os produtos que são desenvolvidos pela organização. Este é o intui-
to não só do design de interacção, mas de toda a empresa. Naturalmente que para
ter clientes satisfeitos é necessário ir de encontro às suas expectativas, é necessá-
rio conhecê-los.

A disciplina do design está a complementar na empresa algumas equipas de projeto,

com a contratação de 5 designers, que contribuem com a sua experiência para o ob-
jetivo global de satisfação do cliente, mantendo os altos patamares de qualidade re-
conhecidos à Critical Software. O trabalho de design de interação tem estado dividi-
do entre a execução de projetos/produtos (cerca de 80%) e a execução de propostas
aos clientes (cerca de 20%).

Atualmente, o desenho de interação representa 3% da equipa de engenharia, exis-

tindo 1 designer por cada 30 engenheiros. Apesar deste facto, é fomentada grande
cooperação entre equipas e entre os membros das mesmas. O crescimento da equi-
pa de designers e o número cada vez maior de projetos onde estão envolvidos, reve-
la a sua importância crescente nas equipas de projeto.

Na empresa, os mercados onde o design mais tem integrado as equipas de desenvol-

vimento ou projecto são a Energia e Mobilidade e as Telecomunicações.

Para melhor compreender o papel do design de interação na Critical Software e a

sua integração com as áreas da engenharia e informática, nada melhor do que a aná-
lise de um caso prático de um projeto desenvolvido pela empresa. Nas próximas pá-
ginas será apresentado um estudo de caso, escrito na primeira pessoa pelo designer
de interação Nelson Vilhena, orientador desta tese na Critical Software. Trata-se de
um processo de desenvolvimento de um produto na área da saúde, com vista à re-
solução de um problema relacionado com oftalmologia, onde são descritas as várias
etapas percorridas desde a definição do problema até a implementação do produto.

A referência a este estudo de caso, nesta dissertação, torna-se pertinente pela for-
ma clarividente como é explicado todo o processo, pelos detalhes que revela e por
dar um entendimento geral da resolução de um problema real resolvido pela Critical
Software com a intervenção de um designer de interação.
 TRABALHO PRÁTICO . 73

Interaction design is not guesswork (Cooper et al., 2007)

Case Study: Retmarker

Em Setembro de 2009 colocaram-me o seguinte novo problema:

"Na AIBILI precisam de fazer umas marcações sobre umas imagens de AMD para um
estudo epidemiológico. É só alterar umas coisitas no Retmarker. É muito simples,
basta alterar o image explorer do retmarker... em dois ou três dias fazes isso."

Fui então falar com os 3 médicos que iriam fazer esse estudo.

Disseram-me que queriam "marcar" umas 5000 imagens de olhos de doentes com
AMD. Precisavam de marcar Drusens, Hiperpigmentação, Hipopigmentação, Atrofia
Geográfica e Maculopatia Exsudativa. !!!? Fiquei a perceber o mesmo.

No dia seguinte voltei lá com 6 imagens de doentes com AMD que procurei na net,
cada uma impressa em full A4 e colada num cartão, e com um acetato transparen-
te por cima. Levei um conjunto de 6 imagens para cada médico e levei-lhes também,
um jogo de canetas de acetato para cada um, com 4 cores.

Pedi-lhes para "marcarem" sobre essas imagens tal como fariam normalmente. Cada
um levou o seu "kit" para casa e entregaram-me passados dois dias.

O resultado foi este:

Comecei então a compreender o tipo de trabalho que queriam fazer:- Desenhar à

mão livre sobre imagens de fundo de olho (retinografias), desenhar formas circula-
res de vários tamanhos, desenhar formas irregulares, cada tipo de lesão com um có-
digo distinto, apagar coisas desenhadas, etc.

Pedi-lhes também nessa altura para me darem uma visão geral do que é a doença
AMD (DMRI- Degenerescência Macular Relacionada com a Idade) e o que significam
estas lesões com nomes estranhos, coisa que fizeram com prontidão e agrado, mui-
to embora tivessem estranhado que o “engenheiro da Critical” (eu) pudesse estar in-
teressado nisso.

Fui para casa, peguei no Kanski, um compêndio de Oftalmologia, e estudei mais um

pouco o capítulo da degenerescência macular.
74 . TRABALHO PRÁTICO

Por experiências passadas, muitos dos conceitos básicos de medicina e particular,

mente oftalmologia (anatomia do olho, exames, semiologia, etc) não me eram estra-
nhos e por isso foi fácil perceber o contexto geral do problema apresentado e a lin-
guagem dos médicos.

Os dias seguintes passei-os no “estirador” a desenhar uma primeira abordagem.

Esboços, ideias... algumas coisas foram desenhadas à mão livre outras foram dese-
nhadas já no computador.

Mostrei-lhes os desenhos e a reacção deles não foi muito conclusiva. Mas foi sem-
pre muito colaborante. Pelos desenhos parecia que algumas coisas poderiam funcio-
nar, outras não. Estas reuniões eram sempre muito desconfortáveis para os médicos
porque tiveram que ocorrer à hora de almoço, entre o trabalho na AIBILI e o traba-
lho nos HUC, passam a vida a correr. Os médicos apesar disso nunca faltaram a ne-
nhum dos nossos encontros.

Nesta altura já sabíamos bem que não era trabalho para uma semana e fizemos uma
proposta. Essa proposta está sintetizada na timeline seguinte. O deliverable (entre-
ga), ficou assim combinado, seria um protótipo funcional. A equipa seria composta
por um designer e por um engenheiro.

Tivemos mais algumas reuniões e nesse processo fomos tomando contacto com
muitos outros pormenores que viriam a ser cruciais, mas que só apareciam à medida
que lhes íamos pedindo que nos explicassem o porquê disto e daquilo.
 TRABALHO PRÁTICO . 75

Todos esses pormenores (como a ideia de confluência de drusens, a ideia de dimen-

sões standardizadas dos Drusen, a contabilização em área e número das marcas, a
sub-divisão dos campos da imagem...) revelaram-se como componentes fundamen-
tais do problema e todas tiveram solução no software.

Em todas a reuniões, esteve sempre comigo o Engenheiro Informático, para que

soubesse tanto do assunto quanto o designer. Os seus inputs e ideias foram muito
importantes e, com propriedade, posso afirmar que foi parte integrante da equipa de
design da aplicação. Fomos uma equipa, na verdadeira acepção da palavra.

Lá pela 5ª ou 6ª geração de desenhos, tornou-se óbvio que, para avançarmos, iría-

mos precisar mais do que desenhos. Estava na altura de avançar para o protótipo
funcional.

Com base nos esboços do designer, o engenheiro fez o protótipo muito rapidamente,
com código colado com clips e fita adesiva (not by the book). Era uma maqueta rápi-
da o que se pretendia. Demorou três ou quatro dias se bem me recordo.

Porque é que foi tão rápido fazer uma maqueta completamente funcional ? porque
por um lado foi feita sobre os alicerces do Retmarker. Por outro lado, porque o en-
genheiro já tinha tido tempo para ir pensando e experimentando pedaços de código
para algumas partes mais complexas. Por outro ainda porque o que o designer de-
senhou teve em conta o que o engenheiro dizia ser capaz de construir. Cada um tra-
balhou na sua especialidade mas não trabalharam cada um para seu lado. O milagres
não acontecem por acaso.

No inicio de Novembro levamos o protótipo, um portátil e um rato para a AIBILI e pe-

dimos aos médicos que fizessem o grading sobre algumas imagens. Não explicamos
muito; apenas demos algumas dicas gerais.

Nessa primeiríssima sessão, de cerca de 60 minutos, com um medico já reformado,

com alguns problemas de motricidade e um pouco avesso a computadores, foi este
o resultado:
76 . TRABALHO PRÁTICO

A partir daqui fomos sempre experimentando e melhorando as soluções sobre o

protótipo funcional. Já não sei quantas vezes foi modificado, mas foram muitas, por-
que sempre que íamos à AIBILI levávamos uma versão melhorada do protótipo.

Muitas ideias ficaram pelo caminho, à medida que se verificavam ineficazes, por uma
razão ou por outra. Outras funcionalidades resistiram a tudo e são as que hoje com-
põem o software Retmarker AMD.

No início de Dezembro estávamos prontos para comparar o software com o método

manual e tradicional de marcação de diapositivos sobre uma mesa de luz.

Queríamos quantificar essas melhorias e queríamos aproveitar para simular uma si-
tuação mais realista de uso quotidiano do software, para perceber onde teríamos
que lhe dar umas marteladas e umas limadelas.

Montamos, com os 3 médicos, um plano para isto. A ideia seria a de marcar manual-
mente as lesões sobre fotografias reais e ampliadas, e contabilizar em numero e em
área essa lesões, em cada sub-região da retina.

Depois, em dias diferentes, fariam o mesmo sobre as mesmas imagens digitalizadas,

no software AMD.

Os médicos escolheram então 6 imagens representativas, e mandamos imprimir em folhas

A3 sobre papel fotográfico de alta qualidade. Fizemos 3 conjuntos, um para cada médico.

Em dias diferentes cada médico fez então a marcação dessas imagens, com as mes-
mas condições de luz, na mesma sala, etc para não haverem grandes flutuações das
condições do teste. Enquanto eles estavam a marcar nós estávamos a cronometrar
e a observar.
 TRABALHO PRÁTICO . 77

Para além de marcarem as imagens os médicos também tinham que contar as lesões
e calcular as suas áreas, coisa que lhes dava uma imensa dor de cabeça, apesar de
termos levado uma máquina de calcular. A imagem mostra alguns dos cálculos que
fizeram no meu caderno…

Depois, em dias diferentes, repetimos

o processo, desta vez usando o pro-
tótipo do software. Eu e o Engenheiro
Informático quase sempre em silêncio
e, à medida que cronometravamos, fo-
mos observando onde é que tinham difi-
culdades, onde é que aplicação facilitava
e onde é que dificultava, que comentá-
rios iam tecendo à medida que usavam o
protótipo, onde se enganavam, onde não
tinham dificuldades nenhumas, etc.

Estas duas imagens são dessas sessões.

O resultado foi: com o protótipo é muito mais rápido (35% mais rápido) e conse-
guiam registar muito mais lesões.

Este foi um resultado comparativo importante, mas do ponto de vista do desenho do

software não era o que mais nos interessava.

O que nos interessava era ver como é que a aplicação era utilizada, se servia os seus
propósitos, se era fácil de usar ou se era um pesadelo, se era inteligível para os mé-
dicos o que se podia fazer com ela...

Na opinião dos médicos que o utilizaram, o prototipo permitiria finalmente executar

o tal estudo epidemiológico, coisa que teria sido muito difícil e com custos extrava-
gantes de fazer manualmente. E isso foi também o que nós observamos (as vezes o
que se diz não corresponde à realidade...)

O resto de Dezembro foi passado a corrigir e redesenhar partes do sistema, tendo

por base o que observamos nessas sessões de “flight test” e a tornar o protótipo um
pouco mais robusto.

Foi entregue o projecto no Início de Janeiro, cumprindo integralmente com o que

estava contratado, no prazo combinado.
78 . TRABALHO PRÁTICO

Depois da entrega perdi o contacto com este trabalho.

Mas sei que, desde essa altura até hoje, os médicos têm usado o prototipo continua-
mente; já fizeram vários estudos (de dimensão e propósitos diferentes) e não tenho
notícia de que o que construimos na altura esteja desadequado.

O que me diz o diz o Engenheiro que ficou, posteriormente, à frente deste projecto
é que, precisamente por conseguirem trabalhar com a aplicação, tem crescido o nu-
mero de pessoas a fazerem estudos e teses e estão agora a pensar dotar o protóti-
po com novas capacidades.

A acontecer, o novo projecto será para ampliar a aplicação. Não para a refazer.

Diz-me também qualquer coisa como isto: “se não tivessemos feito o trabalho des-
ta forma, ainda por esta altura estariamos a discutir requisitos, ou a refazer a última
versão”.

Passo a inconfidência mas este é um comentário da maior importância. Não só pelo

significado explicito das palavras mas, sobretudo, porque é a expressão de um enge-
nheiro satisfeito e orgulhoso com o trabalho em que está envolvido.

Este trabalho custou 3 meses meus e 3 meses do Engenheiro Informático a que se

somou todo o tempo que os médicos despenderam connosco, trabalhando connos-
co, como médicos, como designers, como utilizadores.

Para transformar o protótipo num produto robusto e comercializável, dizem-me, se-

ria precisa 1 pessoa durante 2-3 meses para reescrever o código, executar testes e
validações, etc.

Claro que se fosse esse o caso haveria bastante trabalho de Design ainda a fazer,
principalmente no User interface.

Ou seja, em 6 meses poderiamos ter um produto acabado, utilizável, sem derrapa-

gens no tempo ou no orçamento. Isto com duas pessoas apenas, a trabalharem sem
grande pressão.

É verdade que o projecto não era extremamente complexo e já tinhamos a estrutura

retmarker pronta para reutilizar. Mas também é verdade que tivemos que aprender
tudo pelo caminho, porque no inicio nem sequer sabíamos o que é a DMRI.

É isto o design de interacção.

Tentar compreender os problemas, tentar compreender os clientes e o que preci-

sam (aquilo que eles nos dizem raramente é tudo o que precisam), inventar soluções,
fazer maquetas dessas soluções, testar essas soluções, corrigir, testar de novo, tudo
de forma expedita. Só depois construir a sério.

Isto é feito por designers, engenheiros, gestores, com os clientes. E, sobretudo, com
futuros utilizadores.
TRABALHO PRÁTICO . 79
 TRABALHO PRÁTICO . 81

Projetos desenvolvidos
O trabalho prático desenvolvido na Critical Software (CSW) teve como âmbito o de-
senvolvimento de produtos digitais com a intervenção do design de interação na de-
finição e descoberta de dois problemas apresentados pela organização.

O primeiro projeto está relacionado com gestão documental, DMS (Document

Management System) e o segundo, é um projeto de gestão de ideias, com o nome de
iTi’s (Ideas to Income).

Os projetos apresentados pela CSW foram desenvolvidos no espaço temporal de 5

meses, de Fevereiro a Junho de 2013 (Figura 18). A execução dos projetos em algumas
fases foi realizada de forma sequencial noutras em paralelo, dependendo muito do
tipo de problema e da disponibilidade dos intervenientes no processo.

Por forma a tornar clara a evolução do trabalho desenvolvido em cada um dos pro-
jetos, passar-se-á à apresentação detalhada das várias etapas, divididas por tópicos
temáticos e relatadas na primeira pessoa.

ITI’S

DMS

FEV MAR ABR MAI JUN

Figura 18 - Plano de trabalho dos dois projetos.

 TRABALHO PRÁTICO . 83

1. Gestão documental — DMS (Document Management

System)

A documentação é parte fundamental na existência das empresas. São gerados vo-

lumes incalculáveis de documentação, hoje cada vez mais digital e menos física. A
criação de documentos é no fundo uma forma de comunicação e salvaguarda de in-
formação que ajuda a consolidar e transmitir conhecimento, auxilia a tomada de de-
cisões e a resolução de problemas.

Para a Critical Software (CSW) documentar processos, projetos e outros aspetos da

sua actividade e existência, surge como uma inevitabilidade. Por outro lado, gerir e
organizar toda a documentação de uma organização como a CSW que mantém ele-
vados padrões de rigor, segurança e qualidade, é um grande desafio e uma grande
oportunidade de potenciar e rentabilizar todo o conhecimento que vai sendo criado
e acumulado diariamente pelos seus inúmeros colaboradores.

No âmbito do estágio realizado, o problema apresentado pela CSW foi o desenvolvi-

mento de uma solução para o seu sistema de gestão documental, DMS - abreviatura
do inglês, Document Management System. Na proposta de estágio apresentada pela
CSW à Universidade de Coimbra, pode ler-se o seguinte:

“Atualmente a gestão de documentos é feita de forma pouco estruturada e pouco

acessível para posterior consulta. Documentos técnicos ficam arquivados em fer-
ramentas de versionamento, documentos de negócio são guardados em múltiplos
locais (que são óbvios para quem guarda mas de difícil acesso para o resto da co-
munidade). Para além disso, toda a informação gerada pela empresa representa um
manancial de conhecimento que, por não estar catalogado de forma universal e aces-
sível de forma prática, não é, assim, rentabilizado de forma eficaz.

A CSW pretende criar uma ferramenta dedicada à gestão dos vários tipos de docu-
mentação gerada quotidianamente - desde documentação de projeto, documenta-
ção financeira, documentação técnica, etc - de forma a que possa ficar disponível e
organizada de forma contextualizada. Quer isto dizer que este projeto não preten-
de criar apenas um sistema de arquivo (que já existe) mas sim um sistema que clas-
sifique, arquive e torne visível toda a informação aos diversos agentes que dela pre-
cisem, no momento em que dela precisam.

Daqui se depreende que a criação dum sistema desta natureza é muito mais do que
um problema tecnológico. Muito neste projeto depende da análise dos contextos in-
dividuais de cada colaborador, dos seus métodos de trabalho e dos processos / polí-
ticas da organização. O trabalho a realizar neste projeto - tal como em qualquer ou-
tro projeto de software - terá mais a ver com pessoas do que com tecnologia.”
84 . TRABALHO PRÁTICO

1.1. Entender o problema

Num mundo cada vez mais dependente de tecnologia, é recorrente que esta se so-
breponha às necessidades das pessoas e seja utilizada como uma solução para a
maioria dos problemas. A última afirmação da proposta, “… tal como em qualquer
outro projeto de software - terá mais a ver com pessoas do que com tecnologia.”,
explica de forma clara a abordagem que a empresa pretende que o design de inte-
ração faça aos problemas. Colocar as pessoas no centro do processo e entendê-las.

Como elemento externo a todo o contexto de trabalho da CSW, a fase inicial de abor-
dagem ao problema proposto, teve na prática muito pouco a ver com tecnologia e
muito mais com contacto pessoal. Tentando perceber o contexto em que me encon-
trava e qual o problema a resolver.

A abordagem do design centrado no utilizador, referida por Brown e Katz (2009) e

Cooper et al. (2007), onde o utilizador final do produto é parte central do processo
de descoberta e definição do problema, orientou grande parte deste projeto. Desde
a definição do problema até à concretização dos últimos interfaces.

Na definição do problema, foi realizado algum trabalho de campo, recolhendo e tro-

cando informações e fazendo leituras de processos internos. Procurou-se essencial-
mente nos comportamentos humanos alguns detalhes que pudessem ser importan-
tes para a solução do problema.

Foi importante nesta fase a realização de algumas reuniões com as pessoas que têm
conhecimento das dificuldades existentes num determinado contexto, para que o
problema ficasse claramente definido para todas as partes envolvidas no processo.
Esta clarificação torna o trabalho mais objetivo, na medida em que todos procuram
soluções para o mesmo problema e evita que o plano de trabalho seja afetado por di-
vergências futuras. (Dubberly, 1995)

Como a gestão de documentação é um problema demasiado extenso e abstrato, os

responsáveis do projeto definiram apenas um tipo de documento como modelo para
iniciar um sistema de gestão documental. Foi definido o tipo de documento Case
Study (Estudo de Caso), que inclui todos os Case Studies dos projetos realizados pela
CSW.

Com base neste pressuposto, iniciei uma fase de pesquisa de forma a perceber que
tipo de documento se tratava, qual a sua origem e finalidade. Formulei inicialmente
3 questões. O que é um Case Study? Para que serve? Quem o utiliza?

Qualquer documento interno da CSW, tem a sua criação, edição e revisão devida-
mente documentada. Nesta documentação, procurei as primeiras informações so-
bre os Case Studies, confirmadas ou aprofundadas por reuniões posteriores com
várias pessoas que utilizam os Case Studies no seu trabalho. Além deste conheci-
mento específico, do tipo de documento que iria utilizar, nesta altura também foi
 TRABALHO PRÁTICO . 85

Figura 19 - Esquema visual do ciclo de vida de um Case Study, desenhos de Rui Cordeiro (CSW).

necessário um entendimento de toda a linguagem utilizada pela organização, quer

nos processos, quer nos cargos (roles) dos colaboradores. Uma linguagem interna
maioritariamente em inglês, pelo facto da CSW ser uma empresa multinacional.

Um Case Study de um projeto da CSW (Figura 20), é um documento que mostra de

forma sintetizada (ocupando normalmente uma página A4) os desafios do projeto,
qual a solução encontrada e quais os benefícios para o cliente. Este é um documen-
to utilizado principalmente na área comercial com o cliente, demonstrando a capa-
cidade da empresa em resolver problemas semelhantes e conseguir concretizar no-
vos negócios.

Recorrendo sempre a uma linguagem muito visual tentei desde início esquematizar
com desenhos tudo o que ia recolhendo. Entendi-a como a melhor forma de exte-
riorizar todas as ideias que me ocorriam, ao mesmo tempo que funcionava também
como validação das ideias com os interessados no projeto. É uma forma fácil de mos-
trar o entendimento que temos sobre um assunto.

O desenho da Figura 21 mostra a informação que foi recolhida sobre o fluxo do pro-
cesso dos Case Studies. Após esta esquematização, decidi realizar um vídeo com o
fluxo do documento entre os vários intervenientes na criação, edição e aprovação.
O vídeo teve como objectivo confirmar não só o fluxo de informação recolhida, após
as reuniões com os responsáveis, mas também mostrar algumas diferenças entre a
realidade do processo e o que está documentado.
86 . TRABALHO PRÁTICO

Figura 20 - Exemplo de um template de um Case Study da Critical Software.

Figura 21 - Esboço do ciclo de vida de um Case Study e seus responsáveis. O desenho mostra a
perspetiva de cada um dos cargos sobre o ciclo de vida do documento e a análise de alguns padrões.
 TRABALHO PRÁTICO . 87

Reflexões - Ciclo de Vida do Case Study

CS CS pr
BDM
Business
development E f
manager

pr
tDM
tendering
manager

CS CS CS CS CS CS CS CS
pM
project
manager C C C C C C C C

CS CS CS CS CS CS CS CS
tM
thecnical
manager C C C C C C C C

CS
Mkt
CS
CS CS
marketing
E
E f

rEpOSitOry
of case studies

kiCk Off
project a

77 kiCk Off
project B

Figura 22 - Ciclo de vida do Case Study (a azul) dentro do espaço temporal de um projeto.

1.2. Um problema complexo

Encontrar soluções para os problemas envolve perdermo-nos frequentemente. O
design e a aprendizagem são um processo confuso. Temos de fazer vários escolhas
pelo caminho onde nunca há apenas uma resposta. (Shimmell, 2012)

Os desenhos realizados (Figuras 21 e 22) foram reveladores de um processo um pou-

co complexo que inicialmente parecia mais simples. Para tal, contribuiu o facto de
estarem pelo menos cinco cargos envolvidos no ciclo de vida do Case Study com in-
teresses bastante diferentes sobre o documento.

Após várias reuniões e conversas via skype com PM’s (Project Manager), BDM’s
(Business Development Manager), TDM’s (Tendering Manager), TM’s (Technical
Manager) e responsáveis do Marketing, foi possível dividir os cinco cargos consoante
o seu interesse em três áreas, como mostra a Figura 23. À esquerda, estão os PM’s e
TM’s, responsáveis pela criação do documento de Case Study, ao centro o Marketing,
responsável pela gestão e partilha do documento, e à direita os BDM’s e TDM’s utili-
zadores do documento no contacto com o cliente.

Desta divisão resultam dois tipos de interações e o aparecimento de um elemento

central no processo, o Marketing. Na prática e tal como está documentado no pro-
cesso, o Marketing é o cargo que deve fazer a ligação entre os intervenientes no ciclo
de vida de um Case Study, e por outro lado fazer com que estes documentos sejam
criados atempadamente. Com linguagem acessível, pouco técnica, disponibilizando-
-os a quem deles precisa. O marketing é assim o responsável por manter vivo um re-
positório de Case Studies para toda a comunidade CSW.
88 . TRABALHO PRÁTICO

CREATE CONTROL / SHARE USE

PM BDM
PROJECT BUSINESS
MANAGER DEVELOPMENT
MANAGER

MKT
MARKETING

TM TDM
TECHNICAL TENDERING
MANAGER MANAGER

INTERACTION INTERACTION

Figura 23 - Divisão em 3 áreas dos cargos interessados no documento de Case Study.

As conversas acabaram por revelar um processo um pouco diferente do estipulado

internamente para os documentos de Case Study. Na realidade, o grupo de Marketing
recebe os documentos de um responsável, e só desse, e quando este não envia Case
Studies, o marketing parte do pressuposto que eles não existem.

Revelou ainda, que há uma grande dispersão de repositórios e documentos que cir-
culam entre os interessados via email, sem que exista um local definido onde todos
possam procurar por eles.

Chegando a este ponto, fez sentido colocar a seguinte questão: “Porque não guar-
dar toda a documentação dos Case Studies numa pasta partilhada internamente?”

A resposta não é imediata. A existência de um sítio comum onde todos possam pro-
curar os documentos, por si só pode não resolver. Numa organização com a dimen-
são da CSW e com a grande diversidade de cargos que existem, cada um dos inter-
venientes olha para o Case Study de forma diferente.

Cada colaborador interessa-se pelos Case Studies da sua área de atividade. Os car-
gos responsáveis pela criação do Case Study, que têm o conhecimento do projeto,
vêem o documento como uma tarefa menos agradável, uma vez que a natureza das
suas funções é mais técnica. Internamente, o marketing não tem a capacidade, au-
toridade, nem conhecimento para reunir e controlar toda esta informação dispersa.

Além disso outros problemas podem surgir. Qualquer pessoa nova na organização
terá dificuldade em conhecer todos os repositórios partilhados e atualizados da
documentação.
 TRABALHO PRÁTICO . 89

Desta análise organizacional e comportamental encontrou-se um problema comum

com diferentes perspetivas (Figura 24).

Toda a informação recolhida e sintetização visual dos processos realizada até aqui,
pretende criar um entendimento partilhado sobre o problema e confirmar a ve-
racidade das descobertas. Algumas, pontos chave orientadores do desenho da
ferramenta.

3 VIEWS OF THE SAME PROBLEM / 3 NECESSITIES

REPOSITORY
OF CASE STUDIES

PM BDM
PROJECT BUSINESS
MANAGER DEVELOPMENT
MANAGER

MKT
MARKETING

TM TDM
THECNICAL TENDERING
MANAGER MANAGER

Figura 24 - O problema é o mesmo, mas as necessidades de cada cargo são diferentes.

1.3. Os protótipos como forma de descoberta

Depois de toda a informação recolhida, foi necessário concretizá-la em desenhos ou
interfaces gráficos. Uma tarefa um pouco complicada, pela dificuldade de transfor-
mar todo o conhecimento em algo que represente uma solução para o problema.

Os primeiros desenhos, em forma de protótipos não funcionais, revelam alguns

princípios orientadores. A função principal é fomentar a critica e recolher infor-
mação para as próximas etapas, como refere Buxton (2003): “Engineers view proto-
types as part of the process of building things. Designers build prototypes to criti-
cize and tear apart”.

As interações com os intervenientes, tendo os desenhos como matéria de deba-

te, permitiram discussões mais objetivas e progressão no projeto. Como refere
Moggridge (2007), só sabemos se o que estamos a fazer está correto, quando o tes-
tamos com os futuros utilizadores.

Os desenhos da Figura 25 foram os primeiros protótipos desenhados, e embora es-

tejam ainda longe de um desenho típico de software, revelam algumas ideias impor-
tantes. Salienta-se o seguinte:
 90 . TRABALHO PRÁTICO

1.º Protótipo (ainda sem feedback)

Based on the analysis

shown in previous pages, CS Mkt view
i invented the tool case
studies for all .
CASE StUdIES fOR All Mkt
marketing
the interface
changes
depending
this is a prototype to help on the role
project details project status case study status
3 types of stakeholders
involved in the life of
the case study to deal
name Iberwind Command & Control - Collect, ... CREATED REVIEwED APPROVED VIEw
with some problems of Simple view:
communication and a Basic information
common site where people to the marketing team.
can consult relevant name SKIPPER - System, Knowledge, Information... CREATED REVIEwED APPROVED VIEw
information about the case
study.

name Optimised Asset Management for a Wind CREATED REVIEwED APPROVED VIEw

control the phase of the project control the status of the case study see what was written

CS
CASE StUdIES fOR All Mkt
marketing

project details project status case study status

name Iberwind Command & Control - Collect, ... CREATED REVIEwED APPROVED VIEw Detailed view:
kO PCM
more information about
DOwNLOAD the project (if someone
client Iberwind JOãO SantOS
pm asks the team should
know the details).
market

date

who created the first version of the case study notify the responsables for the next steps
the red icon indicates that a person must be notified

90 Figura 25 - Primeiro desenho ou aproximação ao interface de controlo dos Case Studies.

1. O marketing como utilizador principal e responsável por todo o controlo da vida

de um Case Study;

2. Três áreas importantes do documento de Case Study: nome do projeto, estado do

projeto, estado do Case Study;

3. O estado do Case Study, bem evidente na figura 25, demonstra que o marketing
para controlar os documentos deve saber em que fase se encontram os mesmos.

1.4. O objetivo da ferramenta

O marketing é a entidade definida pela organização, para gerir todos os Case Studies
e deve permitir que a restante comunidade da CSW tenha acesso aos Case Studies
dos projetos.

Os desenhos desenvolvidos na concetualização da nova ferramenta, embora apresen-

tem algum nível de refinamento e de atenção ao seu aspeto gráfico, a sua principal
função é perceber se estão de acordo com os objetivos definidos. Nesta fase vários
detalhes do aspeto gráfico foram relagados para segundo plano, pois tentávamos per-
ceber o problema a resolver, propondo aproximações de arquitetura de informação.

Numa altura em que existem muitas dúvidas sobre o que realmente interessa ao uti-
lizador da ferramenta, a atenção passou a focar-se essencialmente sobre a existên-
cia ou não, de certos elementos e menos com os detalhes visuais que os constituem.
 TRABALHO PRÁTICO . 91

“Rules of form and aesthetics mustn’t be discarded, of course, but they must work in
harmony with the larger concern of achieving user goals via appropriately designed
behaviors.” (Cooper et al., 2007)

Na fase de análise e validação do conceito dos primeiros protótipos, os utilizadores

mostraram-se mais preocupados em questionar o conteúdo dos protótipos, o signi-
ficado de certos elementos e a forma como tudo se relaciona com o problema que
estamos a resolver.

1.5. Validação de desenhos

O contacto com os utilizadores, além de orientar o caminho a seguir, também aju-
dou a perceber se se caminhava corretamente. As conversas com Filipa Almeida e
Sandra Cordeiro (área de marketing), e Rui Cordeiro (cliente e utilizador da futura
ferramenta) revelaram algumas diferenças em função do tipo de utilização que cada
um daria à ferramenta.

Para as responsáveis da área de marketing o desenho da Figura 26, mostrou-se pou-

co revelador, por vários motivos:

- O tipo de documentos apresentados no desenho tinha pouco a ver com os docu-

mentos que trabalham regularmente;

- O conhecimento sobre o tipo de ferramenta que estava a ser criada, ainda não era
muito clara. Sendo a função do marketing a gestão desses documentos e a verifi-
cação de que são escritos numa linguagem acessível, o marketing não precisa re-
gularmente desses documentos. O Case Study na CSW é um documento essencial
para quem contacta com o cliente e utiliza este documento para assegurar novos
projetos;

- Não sabendo bem para que servirá a ferramenta e talvez por falta de algum hábi-
to a dar opinião sobre interfaces de software, os comentários das responsáveis de
marketing não são muito expansivos, limitando-se a confirmar ou rejeitar algumas
opções;

A referência à falta de espírito crítico na primeira versão que apresentei ao marke-

ting, não é uma crítica pessoal, é a constatação da dificuldade em extrair informa-
ção das pessoas e da sua dificuldade em sugerir soluções para o futuro. Como re-
fere Cooper, Reimann and Cronin (2007), contrariamente ao que se pode suspeitar,
poucos utilizadores são capazes de articular e expressar as suas necessidades. Se o
objetivo é desenhar soluções inovadores e que satisfaçam os utilizadores, essa so-
lução ainda nem sequer foi pensada, logo por definição não pode ser explicada. “If
your goal is innovative design, your product or service has not even been thought of,
so by definition it cannot be explained to research participants.” (Moggridge, 2007)
92 . TRABALHO PRÁTICO

Figura 26 - Protótipo não funcional do interface.

Após a validação do desenho da Figura 26, avançou-se para uma segunda fase de
prototipagem (Figura 28 a 31) com base na informação recolhida nas conversas refe-
ridas no ponto anterior.

A Figura 28 mostra o local onde os utilizadores poderiam aceder à nova ferramenta.

A “intranet” é um website interno onde a comunidade CSW acede às últimas notícias
da empresa, a alguma informação interna e a outras ferramentas internas. Este seria
o ponto de partida para aceder à ferramenta, num contexto familiar aos utilizadores.

Na Figura 29, existem três pontos fundamentais, segundo a opinião dos utilizadores
consultados na fase anterior: o nome do projeto a decorrer ou concluído; o mercado
a que pertence; e os dois estados do Case Study (created not created). Estes pontos
coordenam a organização da informação, demonstram o modelo mental do utiliza-
dor e dão prioridade aquilo que é fundamental para gerir o processo dos documen-
tos de Case Study.

A Figura 29 mostra a informação recolhida dos projetos a decorrer e dos projetos fe-
chados (in progress e closed), utilizando um padrão de interação muito frequente nou-
tras aplicações (Figura 32 e 33) para mostrar grandes quantidades de informação - o
Two panel selector. Esta forma permite ao utilizador consultar informação de um de-
terminado projeto sem sair do mesmo ecrã e sem perder a referência à seleção que
fez, ao mesmo tempo que rapidamente acede a uma série de dados do projeto. Porém
esta forma de apresentação tem algumas limitações, na medida em que o ecrã está di-
vidido em duas área, uma com a lista de projetos e outra para mostrar a informação de
cada projeto. E existe uma grande falta de aproveitamento da área disponível, limitan-
do a quantidade de informação mostrada na área de detalhes de cada projeto.
 TRABALHO PRÁTICO . 93

Figura 27 - O estado do Case Study foi um dos elementos que permaneceu após o primeiro interface.

As Figuras 30 e 31 mostram um ecrã de edição da informação do Case Study, neste

caso para ser realizada online, em vez de ser criada num documento de texto e de-
pois enviada por email para os responsáveis.

Na evolução dos interfaces e na definição da arquitetura da informação, é normal re-

correr a vários padrões de interação. Nalguns casos de forma consciente e pondera-
da, noutros de forma natural respondendo à resolução do problema.

Os padrões de interação são formas de comunicação criadas para facilitar a intera-

ção entre o utilizador e a informação que é apresentada. Recorrer a padrões de in-
teração mais comuns ou tradicionais, é uma forma de garantir que o utilizador sabe

Figura 28 - Web site da Intranet interna da CSW (site atual).

94 . TRABALHO PRÁTICO

o que fazer para realizar determinada tarefa enquanto a ação decorrente dessa op-
ção também não lhe é estranha. Como refere Tidwell (2005) “Habituation measu-
rably improves efficiency. … In essence, patterns are structural and behavioral fea-
tures that improve the ‘habitability’ of something, a user interface, a web site, an
object-oriented program, or even a building. They make things easier to understand
or more beautiful; they make tools more useful and usable. As such, patterns can be
a description of best practices within a given design domain. They capture common
solutions to design tensions (usually called “forces” in pattern literature) and thus,
by definition, are not novel.”

Figura 29 - Lista de Projetos a decorrer e concluídos

Figura 30 - Detalhes do Case Study do projeto.

 TRABALHO PRÁTICO . 95

Figura 31 - Criação do Case Study.

Figura 32 - “Two panel selector” Apple mail. Figura 33 - “Two panel selector” Windows Explorer.

A alteração dos desenhos e o teste de novas soluções é constante. Como se pode

ver na Figura 34, foi testada a solução de ordenação das colunas da lista de projetos.
Opção que se vai manter até aos últimos interfaces realizados. Mais uma vez, foi uti-
lizado um padrão de interação clássico que permite ao utilizador organizar a infor-
mação, consoante o que lhe interessa no momento. É uma opção que permite con-
trolo ao utilizador e ao mesmo tempo liberdade de escolha.

1.6. Continuar a testar soluções

O desenho da nova ferramenta nunca foi um trabalho isolado de um designer. Além
dos utilizadores da ferramenta, com dois perfis diferentes (marketing e utilizador
geral com capacidade de aprovação de Case Studies), estiveram envolvidos ao longo
do projeto dois designers da CSW, Nelson Vilhena e Tânia Santos, com funções dis-
tintas. O primeiro, coordenou e orientou todo o projeto do início ao fim, emitindo
opinião crítica e aconselhando soluções. A outra designer, manteve uma colaboração
96 . TRABALHO PRÁTICO

Figura 34 - Interface com ordenação das colunas da lista.

próxima com revisões constantes ao trabalho, colocando questões e aconselhando

soluções para os problemas.

O processo de desenho tornou-se em certa medida colaborativo, onde após cada re-
visão eram realizados novos desenhos.

Sendo uma ferramenta nova, o trabalho desenvolvido foi também testando algumas
hipóteses com base nas necessidades e comportamentos identificados na fase de
pesquisa. Por exemplo, foi testado um conceito recorrendo a 3 cenários diferentes:

Cenário 1 (Figuras 35 a 38): corresponde ao trabalho do criador do Case Study, o PM

(Project Manager). Este cargo tem o conhecimento das incidências do projeto e da
informação pertinente para realizar o documento. Porém esta é uma função mui-
to técnica. Fazer um documento que explique os principais desafios e os benefícios
para o cliente não é o trabalho habitual de um PM. Não sendo prioritário para o PM
 TRABALHO PRÁTICO . 97

a criação de um documento de Case Study, este documento corre o risco de ser fre-
quentemente relegado para segundo plano até alguém alertar para a necessidade da
sua criação.

Esta informação foi recolhida na fase de pesquisa e levou à formulação de uma hi-
pótese em que o PM receberia uma notificação por email para criar o Case Study
para determinado projeto, Figura 35. Através de um link, o Case Study seria depois
preenchido e finalizado online. Esta opção pretendeu simplificar ao máximo a tarefa
de criar um Case Study, reduzindo o esforço associado com o preenchendo de uma
simples caixa de texto. Sem a necessidade de criar um documento específico para o
efeito, num editor de texto, e depois enviar esse documento para outra pessoa rever.

Porém, esta hipótese não passou disso mesmo e foi abandonada nos protótipos pos-
teriores. A criação de mais uma forma de editar Case Study, diferente do habitual e a
necessidade de serem criados novos hábitos aos intervenientes no processo, foram
razões suficientes para abandonar a ideia. Perceber os contextos familiares e os há-
bitos dos utilizadores é também um dos fatores a ter em conta no design de intera-
ção e no desenho e implementação de novas ferramentas.

Cenário 2 (Figuras 39 a 41): O interface do Marketing permite consultar uma lista

global de todos os Case Studies criados pela CSW e adicionar responsáveis (Figura
41) à criação ou aprovação de um documento. Este cenário vem na sequência do ce-
nário 1 onde o PM depois de preencher o formulário, cria uma versão Word dessa in-
formação associada ao projeto (Figura 31).

Os interfaces visíveis aos diferentes utilizadores são idênticos, diferindo apenas nas
opções permitidas a cada cargo, consoante a sua função no processo.

Cenário 3 (Figuras 42 e 43): A aprovação do documento é realizada por um cargo es-

pecífico, tarefa que ficará visivelmente assinalada no detalhe do projeto. Na Figura
43 podemos ver em detalhe a forma de controlo do ciclo de vida do Case Study, fun-
ção importante para atribuir responsabilidades e manter o processo ativo.

A reformulação dos desenhos apresentados aos utilizadores ou interessados no pro-

cesso, segue sempre a lógica de testar soluções e perceber que informação é ou não
pertinente para realizar determinada tarefa. Neste trabalho constante de reformu-
lação dos protótipos, são sempre realizadas pequenas sequências de ecrãs que si-
mulam a utilização da ferramenta. Desta forma o utilizador poderá imaginar a ferra-
menta em funcionamento e as possibilidades existentes.

Os próximos protótipos fazem parte de uma sequência de 32 imagens, que simulam

a utilização da ferramenta na perspetiva de um utilizador de marketing, ou seja, al-
guém que controla o estado dos documentos e disponibiliza os Case Studies à res-
tante comunidade.
98 . TRABALHO PRÁTICO

Nas Figuras 44 e 45 pode-se ver o ecrã base da ferramenta, assente mais uma vez
num Two panel selector com a lista de Case Studies. Desta vez apresentadas em duas
colunas, uma para o nome do projeto outra para o mercado a que corresponde. Esta
associação, nome do projeto e mercado, surge de um racional interno da CSW, por
ser impossível dissociar um projeto do mercado a que corresponde e isso ajuda a
identificar o projeto.

Figura 35 - Formulário de preenchimento do Case Study pelos PM’s (Project Managers).

Figura 36 - Depois de preenchido, é possível ver os documentos associados ao PM.

 TRABALHO PRÁTICO . 99

Figura 37 - Resumo dos documentos já preenchidos.

Figura 38 - Acesso aos detalhes do Case Study.

Na Figura 41 são destacados quatro botões dropdown (menu suspenso) de áreas fun-
damentais de controlo da ferramenta, que funcionam como um filtro da informa-
ção apresentada ao utilizador. Os botões “dropdown” permitem ao utilizador con-
jugar várias seleções e em pouco espaço inserir múltiplas possibilidades de escolha.
100 . TRABALHO PRÁTICO

Através da validação de desenhos e das várias hipóteses testadas, os quatro items

apresentados: projectos (todos, a decorrer e concluídos); Case Study (existente ou
não), os vários mercados e os anos, revelaram-se como os mais importantes a filtrar
e a quantificar os documentos criados pela CSW ao longo da sua história.

Figura 39 - Lista de Case Studies.

Figura 40 - Two panel selector da lista de Case Studies com vista dos detalhes.
 TRABALHO PRÁTICO . 101

Figura 41 - Atribuição de um user para aprovar o Case Study.

O interface da Figura 44 mostra duas opções que acabaram por não permanecer nos
protótipos seguintes: as seleções a vermelho e os ícones no botão dropdown dos
mercados. O destaque a vermelho de uma ação está normalmente associado a ações
de perigo, o que cria alguma insegurança ao utilizador. A opção por outra cor tor-
nou-se óbvia.

Relativamente aos ícones, colocados à esquerda do nome dos mercados, a sua finali-
dade era criar uma relação emocional com as palavras que os identificam, associan-
do um símbolo gráfico ao nome do mercado. Contudo, o conjunto de ícones criava
alguma complexidade ao interface, desnecessária, introduzindo ainda mais elemen-
tos de leitura. A palavra mostrou-se suficiente, outros adereços não acrescentavam
valor efectivo.

Outra falha detectada, nos testes com os utilizadores, diz respeito a um botão com
uma ação associada e ao mesmo tempo dois estados diferentes, como se pode ver
na Figura 46. Este pormenor não foi corretamente concetualizado, nem validado,
mas o seu objetivo era claro, enviar um documento para aprovação, saber se de fac-
to este foi ou não enviado e quando, e por fim saber se foi aprovado. Este exemplo,
mostra que nem sempre é fácil perseguir as necessidades dos utilizadores, podendo
as soluções por vezes tornarem-se confusas ou mesmo ambíguas, como foi o caso.
Associar ações a realizar com estados do documento num mesmo botão, revelou-se
uma má opção que deixaria o utilizador confuso sobre o comportamento desse mes-
mo botão.
102 . TRABALHO PRÁTICO

Figura 42 - Aprovação do Case Study.

Figura 43 - Controlo do estado do Case Study.

 TRABALHO PRÁTICO . 103

Figura 44 - Lista de Case Studies com detalhes dos botões dropdown.

Figura 45 - Lista de Case Studies e respetivo detalhe de cada projeto.

104 . TRABALHO PRÁTICO

Figura 46 - Exemplo de um botão com uma ação e vários estados associados.

1.7. Testes e desenhos colaborativos

Para a sétima versão dos interfaces da ferramenta de Case Studies foi realizada uma
fase de testes com protótipos em papel. Com uma sequência de quatro ecrãs, os uti-
lizadores eram questionados sobre o fluxo de ações (Figura 47).

A vantagem deste tipo de abordagem tem a ver com a facilidade de obter a opinião
de pessoas externas ao processo e em termos práticos de esboçar opções directa-
mente no papel. Por outro lado este processo torna-se mais complicado quando
pretendemos mostrar ao utilizador sequências mais longas de ecrãs, onde o enten-
dimento do fluxo pode-se perder.

O feedback recolhido nesta fase foi convertido noutro conjunto de protótipos, Figuras
48 e 49. A primeira versão que não recorre ao Two panel selector.

Sem esta opção é possível aproveitar melhor a área disponível do ecrã para mostrar
informação relevante para o utilizador.

Além disso, a opção de two panel selector limitava bastante a área disponível para co-
locar informação relativa ao Case Study. Essa área necessitava de espaço para mais
informação. Abandonando esta opção perde-se a referência ao projeto que se sele-
ciona mas ganha-se maior área para colocar informação (Figura 49).

Esta opção só foi possível porque à partida se sabia o tipo de informação a incluir na
ferramenta e a regularidade de actualização. Trabalhar com informação real (nomes de
projetos, datas, mercados, etc) foi uma preocupação desde início, evitando sempre que
possível utilizar texto simulado. Desta forma foi possível prever os espaços necessários
 TRABALHO PRÁTICO . 105

Figura 47 - Testes com protótipos em papel.

e os padrões de interação que acomodem essa informação, evitando surpresas ou op-

ções desadequadas.

A Figura 45 mostra também a utilização de uma datagrid, (tabela de dados), com sete
colunas. Opção que se manterá até ao final.

Disponibilizar informação sob a forma de lista permite que numa só linha se possa
colocar vários tipos de informação relativa ao projeto, sem ser necessário avançar
para os detalhes do mesmo. É uma forma rápida de o utilizador saber alguma infor-
mação sobre o projecto sem necessidade de consultar informação mais detalhada.

Seguiu-se uma sessão de desenho colaborativo (Figuras 48 e 49) com os dois prin-
cipais interessados no projecto, e revisão dos protótipos (Figuras 50 a 53). Esta re-
velou-se uma das formas mais eficazes de gerar um debate de ideias capaz de fazer
progredir os protótipos, ao criar um fluxo de ideias mais rico e objetivo. Recorrendo
à projeção dos layouts da ferramenta sobre um fundo branco, cada um pôde selec-
cionar e riscar os aspectos que lhe pareceram mais ou menos adequados e sugerir
alterações.

1.8. Fase Final

Resultado da sessão de desenho colaborativo e das várias ideias registadas, surge um
novo conjunto de desenhos da ferramenta (Figuras 55 e 56).

Da última sessão salienta-se ainda, o importante tempo gasto a discutir toda a lin-
guagem da aplicação, nomeadamente as palavras dos botões que permitem ao utili-
zador entender claramente as ações associadas. Por exemplo, na Figura 54 podemos
106 . TRABALHO PRÁTICO

ver as cinco palavras utilizadas para representar o estado de um Case Study. A esco-
lha foi feita com base nos diferentes estados em que se pode encontrar o documento.

Relativamente ao desenho do interface, as novas propostas apostam numa área mais

clara e maior de apresentação da lista de projetos com a respetiva informação com-
plementar. Esta área assume-se como fundamental para o desempenho da nova

Figura 48 - Primeira opção do interface sem o Two panel selector.

Figura 49 - Área dedicada com informação do Case Study.

 TRABALHO PRÁTICO . 107

Figuras 50, 51, 52 e 53 - Sessão de revisão e desenho colaborativo.

ferramenta, daí o espaço nobre que ocupa, a clareza visual que apresenta e os já re-
feridos detalhes complementares do projeto.

A Figura 55 mostra a nova reorganização do interface com um novo menu lateral es-
querdo, criado para facilitar e filtrar a informação apresentada. O controlo e ges-
tão dos Case Studies é fundamental para a equipa de marketing, como tal, tem de ser
possível limitar e controlar os resultados apresentados, a partir de quatro áreas já
referenciadas anteriormente: Projetos, Estado do Case Study, mercados e data.

A Figura 56 apresenta alguns detalhes dos Case Study. Uma área maior para informa-
ção sobre o projeto, os cargos responsáveis pela criação, revisão e aprovação do Case
Study e toda a gestão de ficheiros associados.

O último conjunto de desenhos realizados, Figuras 57 a 60, mostram o último de-

senho da ferramenta realizado até ao final do estágio, sem a realização de qualquer
protótipo funcional. O processo desenvolvido até este ponto corresponde à defini-
ção do problema.

O fim desta fase de conceptualização, significa o fim de uma fase que pode ser com-
parada, nas metodologias de software, ao levantamento de requisitos. Foi uma fase
exploratória e muito experimentalista, com a criação de protótipos muito flexíveis,
sendo a ferramenta desenhada e aperfeiçoada passo-a-passo.
108 . TRABALHO PRÁTICO

Apesar disso, e de todo o processo co-

laborativo até aqui, nada garante que os
utilizadores quando começarem a inte-
ragir com os primeiros protótipos fun-
cionais, não mudem de opinião em rela-
ção a qualquer detalhes.

“Ideally the User-centered design work

should be an integral part of the require-
ments engineering activities or at least
done in close collaboration to ensure
that end-users’ needs are really taken
into consideration. User research would
have a bigger emphasis in the beginning Figura 54 - Estados de um Case Study.
but the focus would gradually shift to
producing and validating design solutions in further iterations.” (Rannikko, 2011)

O resultado de todo o trabalho desenvolvido até aqui é uma exploração que parte do
zero, e que utilizando desenhos como facilitadores do processo de comunicação en-
tre o designer e os utilizadores, cria um interface adaptado ao problema proposto.

Como exemplo dessa exploração, as Figuras 61 e 62 mostram a evolução do contro-

lo visual do documento de Case Study. No início do projeto não é possível saber que
um controlo deste tipo vai ser necessário, esta opção surge durante o processo de
interação com os utilizadores.

Figura 55 - Novo protótipo com uma área maior dedicada à lista de projetos.
 TRABALHO PRÁTICO . 109

Figura 56 - Novo protótipo e a vista dos detalhes do Case Study.

A Figura 61 mostra os primeiros esboços sobre o ciclo de vida do Case Study e os es-
tados que o documento pode ter. Quando foram realizados ainda não existia uma
ideia concreta da forma como iriam aparecer no interface da ferramenta, começa-
ram por ser formas de sintetizar a informação que era recolhida. Só mais tarde se
percebeu que eram fundamentais para informar os utilizadores sobre o estado do
documento.

Na Figura 62 está a evolução, da esquerda para a direita até ao desenho final, do es-
tado do Case Study. Além do aspeto visual, este elemento do interface também evo-
lui nas palavras que utiliza para descrever o estado em que o documento se encon-
tra. Estes termos como já foi referido anteriormente, fazem parte da linguagem que
a ferramenta utiliza e é muito importante que a sua escolha seja feita de forma cri-
teriosa e contextualizada com aquilo que está a descrever. Para que a criação e atua-
lização dos Case Studies seja uma atividade realizada de forma constante, é funda-
mental para quem faz a gestão da ferramenta saber corretamente em que ponto se
encontra o documento e depois realizar a ação correta para que todos os projetos
tenham os Case Studies atualizados.
110 . TRABALHO PRÁTICO

Figura 57 - Login para administradores da ferramenta.

Figura 58 - Interface de pesquisa e controlo dos projetos e respetivos Case Studies.

 TRABALHO PRÁTICO . 111

Figura 59 - Interface de detalhe do Case Study, controlo de ficheiros e publicação dos mesmos.

Figura 60 - Acesso geral à ferramenta apenas com um campo de pesquisa com uma sugestão.
112 . TRABALHO PRÁTICO

Figura 61 - Primeiros esboços do estado do Case Study.

Figura 62 - Evolução, da esquerda para a direita, do estado do documento do Case Study.

Após o estágio, este projecto entrará numa fase de implementação em que estes
condicionamentos assumirão uma expressão visível: as possibilidades das tecnolo-
gias com que esta ferramenta será construída na CSW ditarão novas revisões aos de-
senhos, assim como o tempo e o dinheiro disponível também terão impacto na so-
lução final.

Será pois necessária, mais uma vez, a intervenção do design de Interacção adaptan-
do a ferramenta a novas exigências e produzindo especificações técnicas exequíveis,
realistas e enquadradas nas limitações da técnicas, do tempo e orçamento.

Toda esta fase que decorreu, que está presente e é inerente a todas as outras in-
dústrias desde a arquitectura até ao cinema e que normalmente se designa por “an-
te-projecto”, é o que tem faltado colocar em prática nos modelos Waterfall e Agile. A
sua ausência é uma das razões para o seu falhanço sistemático.

Compreender bem os assuntos a resolver e experimentar possíveis soluções e suas

variantes, prototipando, caminhando gradualmente no sentido de um maior detalhe,
é já prática corrente em todas as indústrias.
TRABALHO PRÁTICO . 113
 TRABALHO PRÁTICO . 115

2. Ideas to Income — iTi’s

O segundo projeto desenvolvido na Critical Software, durante o período de estágio,
está relacionado com um processo interno de gestão e submissão de ideias que pos-
sam gerar novos negócios ou lucro para a empresa.

A Ideas to Income ou iTi’s é um processo, já existente na CSW, que pretende recolher

ideias de todos os colaboradores da empresa e tentar que algumas delas se tornem
boas ideias de negócio, gerando lucro para a empresa.

A área de IK (Innovation and knowledge) e os responsáveis da organização preten-

dem aproveitar a grande massa crítica interna de colaboradores para fazer nascer
dentro da empresa projetos com potencial gerador de lucro. Mas este é o objetivo
genérico que o atual programa já não responde de forma eficaz.

Este projeto é mais uma abordagem onde se espera que o design de interação inter-
venha, que vá descobrindo a raiz do problema e defina uma ou várias formas para o
tentar resolver.

O projeto iTi’s teve início com uma reunião com os responsáveis da área de IK, para
apresentação do processo e dos principais problemas que internamente lhe estão
associados.

2.1. O estado do processo

O processo Ideas to Income da CSW está aberto a todo o tipo de ideias. Ideias de me-
lhoramento do ambiente de trabalho, melhoria de processos e ideias de negócio.

No processo atual, para submeter uma ideia é necessário preencher uma work or-
der (Figura 64), um formulário de uma ferramenta interna da organização. Depois de
preenchido, os responsáveis do programa avaliam a ideia, e caso tenha potencial é di-
recionada para os responsáveis da empresa para ser avaliada e implementada caso seja
possível. As melhores ideias têm como recompensa uma viagem para o autor e respe-
tiva família.

Atualmente, segundo informação da responsável pelo processo, Fernanda Machado,

depois do entusiasmo dos primeiros anos em que eram submetidas entre 100 a 200
ideias por ano, a submissão de ideias passou para menos de 20 anualmente. Além
disso, o processo é desconhecido para os colaboradores mais novos e os mais ve-
lhos perderam alguma confiança no processo pela falta de “feedback” do mesmo.
Para muitos, submeter uma ideia e depois não saber o que lhe acontece, é frustran-
te e motivo para não voltarem a submeter.
116 . TRABALHO PRÁTICO

A documentação interna Critical (2013) consultada em Abril 2013 (ultima edição em

Junho 2010) refere o seguinte:

- iDEAS TO iNCOME is a Critical Software program with the aim of promoting result
orientated innovation.

- The increase of Critical’s competitiveness demands productivity improvements, be-

tter response to client’s needs and bigger capability of foreseeing the market’s needs.
iTiis an essential tool to make use of the collective potential of Critical’s workers.

- This is a channel that allows the expression and follow-through of ideas that are
conceived outside worker’s normal work environment.

Procedure Overview Image

Submissio Implementatio Classificati

Evaluation Reward
n n on

Figura 63 - Página da documentação interna sobre o fluxo do processo.

Annex C – Submission Form (1/3)

10
© Copyright Critical Software S.A. 1998-2010 All Rights Reserved.

33
© Copyright Critical Software S.A. 1998-2010 All Rights Reserved.
Figura 64 - Exemplo do formulário da work order para submissão de ideias.
 TRABALHO PRÁTICO . 117

- The ideas can focus any subject as long as they lead to improvements for Critical.
For example, it can be,

- A proposal for improving the software development process;

- An idea for a new commercial product;

- A better way to achieve knowledge sharing.”

2.2. Análise ao processo

Consciente do potencial que um processo de geração de ideias pode ter no seu futuro,
a CSW pretende com a revitalização do processo existente o envolvimento de toda a
comunidade CSW na construção não só de ideias, mas também do futuro da empresa.

Os responsáveis identificaram alguns pontos importantes para o novo processo:

- A comunidade além de submeter ideias, deve também avaliar as ideias submetidas;

- A nova plataforma não se pode tornar num local para resolver problemas do dia-a-dia;

- As ideias submetidas podem ser públicas ou privadas.

Após a reunião inicial e a consulta de alguma documentação interna, avança-se com

as primeiras hipoteses. Supõe-se que uma ferramenta que possa gerir o processo de
submissão de ideias não é suficiente para iniciar o processo de comunicação da co-
munidade. Para colocar em prática um processo deste género, e pela complexidade
que envolve, é fácil perceber que muitos outros aspetos da organização terão de so-
frer alterações. Encerrar a resolução do problema apenas numa ferramenta digital
sem perceber o contexto de trabalho da organização e o comportamento dos cola-
boradores na gestão de ideias, é uma forma simplista de resolver o problema.

O processo atual apresenta várias lacunas na sua conceção, a forma genérica como
está desenhado sugere uma caixa de sugestões opaca à espera de ideias espontâneas
dos colaboradores da CSW. “The traditional suggestion box approach typically fails
because there is no sense of urgency and an inadequate process for review, feedback
and implementation, leaving contributors disillusioned that management never lis-
tens.” (InnovationPoint & Idea Crossing, 2006)

Before the Submission Submission Evaluation Implementation Classification Reward

Figura 65 - Sugestão de alteração ao processo com foco na fase antes da submissão da ideia.
118 . TRABALHO PRÁTICO

feedback

Before the Submission Submission Evaluation Implementation Classification Reward

Figura 66 - Restabelecer credibilidade: O autor da ideia tem de saber em todas as fases o que está a
acontecer.

A Figura 63, que representa o fluxo do processo, não faz qualquer referência ao que
acontece antes da submissão da ideia, ou seja, o que a organização faz para despole-
tar e estimular a criação de ideias.

As referências consultadas sobre processos de inovação fazem referência a várias

técnicas que podem ser exploradas num processso de geração de ideias e que po-
dem ou não utilizar ferramentas digitais. Entre elas destacam-se:

- brainstormings;

- Webstormings;

- Opinião dos clientes;

- Concursos;

- Grupos de discussão;

Desta forma uma das primeiras sugestões de melhoramento do ITI´s foi todo o pro-
cesso que antecede a submissão da ideia (Figura 65).

Submission Evaluation Implementation Reward

idea Community Die or The community will Everyone can implementation Feedback to the
evaluation Grow empower the idea. join the team community
to implement about the
the idea. implementation
(limited roles) until the end.

Figura 67 - Fluxo de uma ideia. Destaque para a avaliação de ideias.

 TRABALHO PRÁTICO . 119

Outro ponto assinalado como prioritário foi o processo de feedback dado ao autor da
ideia, após a submissão (Figura 66). Nomeadamente uma opinião positiva ou negati-
va ou o acompanhamento de perto pelo trabalhador sempre que uma ideia avance.

No processo existente a submissão é feita numa primeira fase pelos responsáveis do

programa e só depois, caso a ideia seja válida, passa para a administração que dá o
avalo para se avançar ou não. Para o novo programa existe a ideia de que deve ser a
comunidade a avaliar as suas próprias ideias, fazendo apreciações e ajudando o seu
desenvolvimento com opiniões críticas e sugestões. Desta forma a própria comuni-
dade filtra as ideias com mais potencial.

Em resultado desta primeira fase de reflexão, foi desenhado um esquema simples

(Figura 67) que apresenta os procedimentos a seguir, previligiando neste caso, a ava-
liação das ideias.

Figura 68 - Primeiro interface Self-design para a ferramenta de iTi’s.

120 . TRABALHO PRÁTICO

2.3. Exploração Self-Design

Quando o design de interação é utilizado para abordar e sugerir soluções para o pro-
blema, é importante em todas as fases criar artefatos visuais para potenciar o pro-
cesso de comunicação entre os interessados no processo, mas também criar o cha-
mado conhecimento partilhado (Gothelf, 2013). Os desenhos, sejam eles de que tipo
forem, ajudam a exteriorizar o pensamento e criam uma linguagem comum.

A abordagem nesta primeira fase pode ser considerada um Self-design de um interfa-

ce, ou seja, grande parte da solução é baseada na informação recolhida sobre o proces-
so, levando em conta os objetivo da CSW e ferramentas semelhantes existentes. No fun-
do uma ferramenta que sirva a criação e construção de ideias (Spool, 2011). O propósito
desta exploração é essencialmente o de alinhar o pensamento de todos os intervenien-
tes e gerar alguma discussão que possa trazer mais informação para a fase posterior.

A Figura 68, mostra um interface gráfico com um fluxo inicial ainda pouco desenvol-
vido. O ecrã principal apresenta um mural de ideias, quase como “post-its” com re-
ferência a uma imagem da ideia e uma pequena descrição. Este primeiro interface
tem os elementos indispensáveis para visualização e avaliação de ideias. Ao lado di-
reito, existe uma secção que acompanha a atividade do utilizador na plataforma, ou
seja, as últimas ideias com as quais o utilizador interagiu, com comentários ou apre-
ciações positivas.

O segundo ecrã, Figura 68, mostra informação acessível sobre uma ideia, desde a
descrição, a comentários, a informação do autor ou ao estado da ideia em relação
ao processo.

Este primeiro desenho permitiu iniciar a discussão e reflexão sobre o processo,

abrindo caminho a novas abordagens.

2.4. Trabalho de campo

Desenhar qualquer artefato digital que sirva os propósitos dos utilizadores, sem um
trabalho de campo que permita trazer para debate algum do seu contributo, é um
trabalho incompleto e pouco revelador da natureza dos problemas. Num projeto de
criação e gestão de ideias de uma comunidade, os primeiros interfaces sofrem de
uma falta de contextualização da realidade diária das pessoas. Levando em conta
esta ideia foi definida uma nova abordagem para o problema, com base na estratégia
de design centrado no utilizador, aconselhada por Cooper et al. (2007).

Esta estratégia de design, coloca os utilizadores no centro do processo, em vez da

tecnologia, e faz com que o seu contributo influencie todo o processo de design.

Numa segunda fase foi planeado um conjunto de entrevistas com os futuros utiliza-
dores da ferramenta e colaboradores do processo Ideas to Income. Assim, foram rea-
lizadas dentro da comunidade CSW, um conjunto de 31 entrevistas pessoais ou via
Skype, orientadas por um guião aberto de 15 perguntas.
 TRABALHO PRÁTICO . 121

Figura 69 - Entrevista com Tânia Santos.

O método de pesquisa escolhido para realizar este trabalho, foi o método qualitati-
vo, com foco na qualidade e diversidade de opiniões e não na quantidade de opiniões
similares ou preferências por certos atributos (Schuler, 2013).

De acordo com Cooper et al. (2007), “qualitative research usually involves a small
sample size and is concerned with understanding how people behave, how they think
about certain activities, and what fators affect their behavior and thought patterns.
Qualitative research helps us understand the domain, context, and constraints of a
product in different, more useful ways than quantitative research does. It also helps
us identify patterns of behavior among users and potential users of a product much
more quickly and easily than would be possible with quantitative approaches.”

O guião criado para orientar as entrevistas, constituído por 15 perguntas, procurou

revelar comportamentos e hábitos dos indivíduos na forma como lidam com as suas
ideias.

O guião foi dividido em cinco áreas, informação profissional, conhecimento do pro-

cesso antigo, hábitos de registo de ideias, formas de comunicação e motivações. As
15 perguntas do guião foram:

1a. Nome?

1b. Idade?

1c. Formação (background)?

1d. Cargo?

1e. Há quantos anos trabalha na CSW?

2a. Conhece o programa “Ideas to Income”?

2b. Já submeteu alguma ideia? Que tipo de ideia(s)?

122 . TRABALHO PRÁTICO

2c. Qual o resultado?

3a. Tem hábitos de registo de ideias? Como, onde as regista e com quem as partilha?

3b. Que tipo de ideias gostaria de submeter à organização? Ideias de negócio?

Outros assuntos?

3c. Qual a melhor forma de o fazer?

4a. Como comunica atualmente os colegas de trabalho?

4b. Utiliza alguma rede social a nível pessoal? Qual?

5a. Quais as motivações para submeter uma ideia?

5b. O que espera da organização?

Realizar uma entrevista, independentemente do ambiente, é um trabalho intrusivo

onde pode ser difícil obter um momento de atenção das pessoas. Primeiro pela na-
tureza do entrevistador e depois pela natureza do entrevistado. À partida, este não
é um trabalho natural e agradável para um designer, facto que pode contribuir para
alguma inércia na realização de um trabalho de campo deste género. Só com alguma
curiosidade e motivação se pode ultrapassar este facto.

Parte-se para o desconhecido com um objetivo em mente e espera-se que isso traga
descobertas importantes para o processo que se está a realizar.

Depois, há que dar alguma atenção a um outro fator fundamental neste processo,
a capacidade dos entrevistados em expandir as suas ideias. Pessoas que falam pou-
co ou que respondem apenas ao estritamente necessário. Embora seja aconselhá-
vel que o entrevistador estabeleça alguma empatia com o entrevistado, criando um
ambiente mais descontraído, pode não ser suficiente para recolher a informação
pretendida.

Por natureza os indivíduos são muito diferentes entre si. Têm personalidades e esta-
dos de espírito distintos. Aquilo que para uns pode ser uma boa pergunta, para ou-
tros é insuficiente e muito vaga.

A forma de conduzir o processo foi, deixar que o guião orientasse a entrevista mas
que não ao mesmo tempo não limitasse demasiado a conversa. Nas respostas per-
guntou-se várias vezes “porquê?”. Esta questão constante, às respostas do utilizador,
permite chegar à raiz do problema e perceber as verdadeiras motivações para deter-
minados comportamentos.

A sede da Critical Software em Coimbra tem mais de 200 colaboradores e isso re-
presenta um universo enorme para este trabalho. As pessoas na sua grande maio-
ria mostraram-se disponíveis para responder ao questionário. De tal forma que, os
10/15 minutos que eram pedidos inicialmente, facilmente se transformavam em 20
ou 30 minutos de conversa.
 TRABALHO PRÁTICO . 123

As 31 entrevistas realizadas durante duas semanas, foram gravadas em audio e trans-

critas numa base de dados para análise. Depois de tratadas e analisadas as entrevis-
tas foi possível reunir de forma sintetizada, alguns padrões encontrados nos utiliza-
dores reais, nas chamadas Personas (pessoas fictícas criadas a partir de grupos de
pessoas reais). Dos padrões, destacam-se a Idade do entrevistado e os anos de tra-
balho na organização.

“Personas provide us with a precise way of thinking and communicating about how
users behave, how they think, what they wish to accomplish, and why. …construct-
ing a set of personas is to represent the diversity of observed motivations, behaviors,
attitudes, aptitudes, mental models, work or activity flows, environments, and frus-
trations with current products or systems.” (Cooper, et al., 2007)

Depois de transcrever e ler várias vezes as entrevistas realizadas, duas variáveis

emergiram e guiaram o processo de criação de Personas. A idade do entrevistado e
os anos de trabalho na organização.

PEDRO, 25 anos MARIA, 28 anos

FORMAÇÃO FORMAÇÃO
Eng. Informática Gestão

ANOS NA CSW ANOS NA CSW

Menos de 1 ano 4 anos

CONTEXTO
› Há pouco tempo na empresa, não conhece todos
os processos existentes;
› O trabalho que faz requer momentos de foco
prolongados;
› Não tem muito tempo para pensar noutras
questões que não sejam o seu trabalho diário.
CONTEXTO
› Conhece os processos;
› O seu foco é resolver problemas diários;
› Não tem propensão para pensar em ideias
com impacto financeiro para a organização;

HÁBITOS
› Só costuma registar ideias relacionadas com
os problemas dos projetos que tem em mãos;
› Utiliza bastante as redes sociais para conversar
com os amigos;
HÁBITOS
› Regista ideias relacionadas com tarefas que
têm de fazer;
› Tenta aplicar logo as ideias que tem;
› Utiliza as redes sociais de forma pouco assídua;

MOTIVAÇÕES MOTIVAÇÕES
› Procura melhorar o seu desempenho pessoal › Procura melhorar o ambiente em que se encontra;
e o trabalho que faz diariamente; › Procura reconhecimento pelo trabalho que faz;
› Mostrar competências aos colaboradores diretos;

OBJETIVOS OBJETIVOS
› Sugerir melhoria aos processos de trabalho; › Melhorar o ambiente de trabalho com pequenas
› Melhorar o seu desempenho pessoal; ações ou eventos;

Figura 70 - Pedro e Maria, duas das Personas criadas.

124 . TRABALHO PRÁTICO

A maioria dos entrevistados mais velhos têm mais anos de casa que os mais novos,
o que condiciona a forma como interagem entre si e o conhecimento que têm sobre
os processos internos.

Uma terceira variável que permitiu filtrar toda a informação, foi a formação base dos
entrevistados. A CSW é uma empresa de base tecnológica e por isso grande parte
dos seus colaboradores são formados em Engenharia Informática.

As Figuras 70 e 71 são o resultado desta segmentação em quatro personas tipo, em

que se salientam hábitos e comportamentos de produção e gestão de ideias. Estas
quatro personas tornam compreensível algumas características tipo dos colaborado-
res da organização e contextualizam em parte o problema a resolver.

FÁBIO, 34 anos MIGUEL, 40 anos

FORMAÇÃO FORMAÇÃO
Eng. Informática Eng. Informática

ANOS NA CSW ANOS NA CSW

7 anos 12 anos

CONTEXTO
- Há muitos anos na empresa conhece todos
os processos;
- Conhece as pessoas responsáveis de cada área;
- O seu trabalho precisa de grandes momentos
de foco;
- Tem pouco tempo para ideias fora do seu trabalho;
CONTEXTO
- Há muitos anos na empresa conhece todos
os processos;
- Conhece as pessoas responsáveis de cada área;
- Já esteve envolvido em algumas ideias novas
na organização;
- Lidera equipas e têm autonomia de decisão;

HÁBITOS
- Regista ideias relacionadas com os processos
e fala com os responsáveis para aplicar essas ideias;
- Utiliza pouco as redes sociais, especialmente
o facebook porque mistura muito os assuntos
e as relações pessoais e profissionais;
- Confiante nas suas capacidades;
MOTIVAÇÕES
- Poder aplicar as suas sugestões;
- Receber feedback das sugestões;
- Poder partilhar conhecimento da área
em que é especialista;
OBJETIVOS
- Melhorar os processos;
- Passar conhecimento e receber o mesmo em troca;
- Reconhecimento pessoal;
HÁBITOS
- Tem hábito de registo de ideias;
- Procura conversar e testar ideias com as pessoas
mais próximas;
- Utiliza as redes sociais de forma moderada
e para fins profissionais;
- Conhece bem o sistema utilizado pelos foruns
para discutir ideias;
- Confiante nas suas capacidades;
MOTIVAÇÕES
- Estar envolvido no desenvolvimento de uma ideia,
do início ao fim;
- Saber que o processo funciona e emite uma opinião
crítica sobre as ideias submetidas;
- Saber de quem é a liderança do processo
de submissão de ideias;
OBJETIVOS
- Estar envolvido no desenvolvimento de uma ideia;
- Melhorar a organização, o resto vem por acréscimo;

Figura 71 - Fábio e Miguel as outras duas Personas criadas.

 TRABALHO PRÁTICO . 125

A recolha de informação num processo deste tipo é uma experiência muito enrique-
cedora, não só para o designer que a realiza e a transforma em desenho, mas tam-
bém para o processo das “iTi’s”. A maioria dos colaboradores para além de terem
mostrado disponibilidade para as entrevistas, também se mostraram agradados com
o facto de a organização estar preocupada com aquilo que pensam, tendo, muitos,
feito sugestões interessantes.

Não sendo objectivo deste trabalho de campo recolher as opiniões individuais, é ine-
vitável não aproveitar algumas das ideias que foram lançadas pelos entrevistados, no
melhoramento do processo.

Para compreender melhor a importância desta informação para o processo, trans-

creve-se algumas respostas/ideias dos entrevistados.

“Livre debate, que as pessoas não sejam julgadas pelas ideias. Transparência e que as ideias sejam
promovidas.”

“É mais fácil submeter ideias gerais e depois haver um grupo interno que faça essa triagem e
categorize as ideias.”

“Existe muita gente criativa aqui dentro. Para estimular, poderiam ser feitos uns workshops, uns
brainstormings, para que as pessoas que têm algumas ideias, possam sem ter medo de dar a cara
partilhar essas ideias. Grupos restritos para a partilha de ideias.”

“Haver reconhecimento do autor. Ficar com alguns louros porque faz bem ao ego.”

“A recompensa não tem de ser monetária ou equivalente (viagem, etc) deve é ser dado algum
reconhecimento ao autor.”

“Eventos ou workshops para apresentar internamente os projetos a decorrer e realizados. No portal

aparece a notícia, mas não é suficiente.”

“Dar andamento às ideias, que não fiquem paradas. Se não houver feedback as pessoas deixam de
submeter.”

“A organização não deve fazer juízos de valor ás ideias. Deve fomentar as ideias mais ridiculas.”

“Não espero nenhum retorno. Só espero que a ideia seja ouvida e se possível posta em prática.”

“Mail é forma mais simples mais prática, mas fica num circulo muito restrito.”

“Partilhar e construir coisas. Tentar que algo que não é nada se transforme em alguma coisa.”

“Nada de especial. Gosto de ajudar e não peço nada em troca.”

“Há coisas que temos de saber vender e têm de ser palpáveis. As iTi’s podem usar outros canais, que
não os canais tecnológicos.”

“Acho que algumas soluções para alguns clientes pudessem ser mais “produtizadas”, e as iTi’s
pudessem ajudar.”

“Nunca tive muito tempo para pensar nessas coisas, sou uma pessoa mais executante. As ideias de
negócio requerem mais tempo para serem pensadas.”

“O mail e o skype são formas tradicionais para partilhar ideias, e a sua utilização é natural e estamos
habituados.”

“Bastaria um módulo dentro de ferramentas que já existem, que permitisse fazer sugestões. Não sei se
existe a necessidade de criar uma nova ferramenta.”
126 . TRABALHO PRÁTICO

“As workorders significam burocracia”

“Deveria haver uma forma melhor do que uma caixa de texto para escrever e sugerir coisas. Algo com
mais interação. Destas formas, acho que se perde um pouco o contacto humano.”

“Tem que haver investimento, acho que as pessoas estão abertas a isso e a empresa também. Tem de
haver um “empurrãozinho”. Orientação, pessoa referência que fomente o processo.”

“Para mim não é um prémio ou uma competição. Porque acho que aí vão ser sempre os mesmos que
vão concorrer. Acho que o que deve haver é mais partilhas. A partilha é melhor que a competição.”

“Algumas pessoas têm um trabalho repetitivo, era interessante essas pessoas serem chamadas para
um brainstorming, ser chamada a rever o trabalho de outro, ter grupos de interesse (mailing lists).”

“Por vezes os BDM’s trazem ideias que formalizam em propostas, a forma de fazer isso é boa, mas não
pode ser a única. Tem de haver uma forma de analisar e generalizar essa ideia.”

“Para haver participação da comunidade acho que tem de haver uma “deadline” as pessoas estão
habituadas a isso, têm que sentir alguma adrenalina.”

“O problema aqui na critical é que não há tempo para essas coisas. O pessoal em geral não tem tempo.
Ás vezes até tenho tempo quando estou a viajar, registo no telemóvel, mas depois fica lá, não há
nenhuma ferramenta que sincronize...”

“Todas as ideias podem ser geradoras de “income”, quando não são, chamamos disparates. Mas mesmo
as boas ideias, no seu início parecem ser disparates.”

“Não me motiva a autoria. Não me motiva pensar que vou fazer um grande negócio. O que me motiva
é arranjar o que estiver estragado. Eficiência das coisas para todos.”

“O pior que pode acontecer a alguém que submete uma ideia é o silêncio, não acontecer nada. A
pessoa está tão entusiasmada com o que está a pensar, está a expor-se, e espera que aconteça algo.
Por respeiro, é fundamental a resposta.”

“É ótimo ouvir as pessoas internamente, mas é importante “benchmarking”, ver 3/4 casos de sucesso e
perceber como é que outras organizações resolveram o problema.”

“Já sugeri à critical um sistema de pontos, em que vamos juntando e depois recebemos um catálogo,
tipo BP, em que escolhemos alguma coisa.”

“Uma ferramenta pode ajudar, mas o contacto direto, falar, é mais construtivo, porque se pode
explicar melhor o que se pretende.”

“Ver os comentários de outros pode fomentar o debate.”

“Saber que há alguém preocupado em saber o que nós pensamos é um estímulo.”

“Uma coisas menos formal. O processo atual das iTi’s acaba por ser uma coisa formal.”

“A organização é aberta a receber o contributo de todos, mas acaba por não fazer muito por isso.”

“Justiça na avaliação de ideias submetidas.”

“Experiências de produtos. Se há uma ideia que é boa não é preciso implementar na empresa inteira,
podemos começar com uma fase experimental para reduzir custos.”

“Eficiência, negócio, melhoria contínua.”

“Coisas diferentes que possam ser área de negócios no futuro, porque nunca sabemos qual vai ser a
nossa área de negócio amanhã.”

“Acho que quanto mais se formaliza um processo criativo, menos criativo é o processo.”

“Todos são bem vindos desde que queiram soltar-se.”

 TRABALHO PRÁTICO . 127

“Conseguir dar um ambiente criativo às pessoas e propício à conversa.”

“A mim o que me motiva não é o dinheiro, é o facto de haver pessoas que vão olhar para as ideias e
ajudar-me a concretizá-las.”

“O jogo que tinhamos na empresa, evolui graças à comunidade. De início o jogo era muito mau,
muitos bugs, mas eles acreditaram e sempre nos deram feedback. Sempre orientei o jogo à
comunidade, ou seja, ter alguém que respondesse 24h e ter plataformas para dar opinião e pudessem
votar. A primeira linha de suporte nunca demorava mais do que 5 min a responder.

Tinhamos a parte do suporte e a parte de sugestões. A parte de sugestões até chegar a nós era
moderado pela comunidade. Até porque eles têm uma noção muito grande daquilo que pode ser mau
para o jogo.”

“Clarificação do programa. Uma liderança clara e um líder com carisma, que não é uma coisa fácil.

Como estou na Critical Health, sinto-me deslocado em relação a muitas coisas que acontecem na
Critical Software.”

“Haver um local onde se possa ver o que existe, motiva a participar.”

“Ver que o sistema funciona. Ver de forma detalhada o desenvolvimento de outros projetos.”

“Por exemplo incluir as iTi’s na newsletter. Ter um resumo de uma delas.”

“As pessoas devem ser premiadas pela qualidade das ideias e não pela quantidade. O processo ou
premiação deve ser visível para que as pessoas percebam que podem ser compensadas por isso.”

“Não deve haver limites. Mais do que as ideias, tem de haver a partilha de problemas. Porque não há
ideias que não sejam para resolver problemas. A ideia é uma consequência do problema.”

“Fomentar a partilha de problemas. Depois dessa partilha é que surgem ideias.”

“Deve ser feito com coisas muito simples, mas sistemáticas. Deve haver uma pessoa responsável pela
monitorização do sistema. Ver se o sistema está vivo, organizá-lo.”

“O que é importante é que a empresa consiga criar valor, porque depois tudo o resto vem
naturalmente.”

2.5. Os resultados
O trabalho de campo e a recolha de várias opiniões, é em qualquer área uma boa
oportunidade de acrescentar valor ao trabalho que estamos a realizar.

A aplicação de entrevistas guiadas por questionário não se restringem aos designers

de interação, podem ser feitas por profissionais de outras áreas, desde que tenham
um objetivo bem definido, espírito aberto e alguma facilidade no contacto pessoal.
Embora o designer possa facilitar Neste caso, o facto de ser feito por um designer,
facilita a integração da informação recolhida com os protótipos a realizar (Cooper
et al., 2007).

Antes de avançar com qualquer proposta visual, todo o trabalho realizado para o
programa das Ideas to Income foi inicialmente analisado num âmbito geral, com foco
no processo de geração de ideias, o qual deve acontecer muito antes da ferramen-
ta digital.
128 . TRABALHO PRÁTICO

Foram então definidos 4 eixos de atuação no seguimento desta fase inicial:

1. Debate e sessão de desenho colaborativo com os vários interessados no processo,

para exposição e debate de ideias e um maior envolvimento no processo.

2. Analisar casos de sucesso. Embora seja difícil encontrar estudos de caso no con-
texto de ITI´s. Esta deve ser um tarefa tanto do designer como dos responsáveis de
“Innovation and Knowledge”.

3. Fomentar a cultura de inovação em toda a empresa, É uma das ideias mais refe-
renciadas na literatura da área. Sem infiltrar a criação de ideias na cultura da CSW e
fomentar a mudança de hábitos em prol da cultura de inovação e a partilha de ideias
é muito difícil acontecer alguma coisa neste processo. “Excellence in leading inno-
vation has far less to do with the leader having innovative ideas; it has everything to
do with how that leader creates a culture where innovation and creativity thrives in
every corner.” (Edinger, 2012)

4. Potenciar a comunicação entre a comunidade da CSW. Incluindo a reutilização

da Intranet (site interno) como mural de notícias ou rede social interna da empresa.
Este é um espaço conhecido por todos os colaboradores e por isso, poderá ser mais
util o seu aperfeiçoamento que a criação de mais uma ferramenta. Sugere-se ainda
uma utilização moderada das ferramentas de comunicação interna, email e newsle-
tter, como complemento da Intranet como rede social.

Poderão ser ainda definidos tempos de inovação e brainstormings, em resposta a

problemas específicos propostos pela organização.

Os quatro pontos apresentados mostram uma abordagem mais ampla ao problema

onde a ferramenta é apenas mais uma em todo o processo.

Para além dos 4 eixos de actuação definidos, foram ainda desenvolvidas algumas es-
tratégias e protótipos não funcionais da utilização da Intranet.

A Intra (ou Intranet), Figura 72, é um site interno onde são publicadas notícias de in-
teresse para a organização (novos negócios, dicas sobre processos), documentação
interna, lista das ferramentas internas (gestão de projetos, horas de trabalho indivi-
dual, ferramentas de versionamento) e outros assuntos.

Este é um site conhecido por todos, mas que carece de alguma atualização regular.
A frequência de notícias colocadas na Intra é semanal e comunicada de forma muito
institucional, deixando pouco espaço livre ao debate.

Readaptar a Intra a novas funcões, pode ser uma solução mais eficaz e económica,
criando um local mais ativo para que a organização possa comunicar com a comu-
nidade e esta entre si.

Na base desta re-estruturação está a ideia de que o problema existente é de certa

forma um problema de comunicação. Os colaboradores comunicam naturalmente
entre si, nos projetos, nas reuniões, via Skype, na hora do café, mas sempre em con-
textos restritos e círculos de confiança.
 TRABALHO PRÁTICO . 129

Figura 72 - Intra. Site interno da Critical Software.

Não existe um debate aberto de ideias e problemas onde todos possam contribuir.
Mais do que focar uma ferramenta exclusivamente na discussão de ideias que pos-
sam gerar lucro. O debate deve ser o mais abrangente possível pois a quantidade
também pode gerar qualidade.

Em geral os colaboradores mais velhos da CSW, conhecem a Intra, mesmo que não a
utilizem com regularidade, como se pode ver na informação sintetizada das Personas.
O que pode ser uma vantagem. O objetivo não é criar uma nova ferramenta mas sim
usar algo que as pessoas já conheçam.

O trabalho premente a fazer na intra não é um re-design completo do site, mas

uma adaptação de novos conteúdos, funcionalidades e áreas do site. Apesar do de-
sign estar também um pouco desactualizado. É importante manter a estrutura base
e algumas referências visuais para que as pessoas sintam que continuam no mesmo
ambiente.

Propõe-se que a reformulação seja faseada, primeiro numa escala mais reduzida,
sem envolver toda a comunidade, identificando 10 a 20 colaboradores experientes e
auto-motivados para a criação e partilha de conteúdos. Depois do teste de algumas
funcionalidades, pode ser gradualmente expandida a toda a comunidade.

Aqui pode fazer sentido a referência à metodologia Lean ou ao Lean UX, que procura
uma adaptação das ideias quase em tempo real. Remete-se assim este teste, para a
ideia da criação de um produto minimamente viável (MVP), que se possa testar com
os utilizadores reais da ferramenta, neste caso a comunidade da CSW.
130 . TRABALHO PRÁTICO

Figura 73 - A vermelho está assinalada a zona onde se pretende inserir novos conteúdos e funcionalidades.

Figura 74 - Novo interface da Intra. Destaque para o “auto-login” ou identificação do utilizador.

 TRABALHO PRÁTICO . 131

Os testes com protótipos minimamente funcionais num grupo restrito, aconselhado

nas metodologias Lean, pode ajudar a ultrapassar algumas das suposições seguidas
após a fase de pesquisa e entrevistas com os utilizadores. Colocar um produto a tes-
te e ver a reação das pessoas para poder definir novas suposições, pode ser a melhor
forma de contornar um dos problemas referenciados por Moggridge (2007), ou seja,
perceber se aquilo que as pessoas dizem é realmente aquilo que fazem.

Inicialmente, mesmo as boas ideias, são indistinguíveis das más ideias, por isso, tem
de ser fácil partilhar qualquer coisa, ideias, problemas, etc. Ssempre com alguma
moderação e monitorização dos responsáveis do programa. Como foi identificado a
“qualidade dos conteúdos” e a “mistura de interesses” foram um dos fatores aponta-
dos para grande parte das pessoas entrevistadas não utilizarem o facebook.

A Figura 74 mostra a primeira versão da edição da intra com a introdução da nova

funcionalidade na área assinalada na Figura 73.

À semelhança das redes sociais mais utilizadas, Facebook e LinkedIn, também na

Intra foi introduzida uma área central onde o utilizador pode ver as notícias publica-
das pela organização e pelos colegas. Destaque para o topo onde existe uma caixa de
texto que sugere a publicação de algo novo. É possível publicar conteúdo, mas tem
de ser sugerido de forma pouco intrusiva.

Aqui, também é possível ver o primeiro nome do utilizador, muito importante para
criar alguma proximidade e identificação com a a nova Intra. Esta será uma das di-
ferenças para a Intra atual, onde a plataforma não sabe quem é o utilizador a não ser
que este faça login. Nesta nova versão, sem saber para já o que isso pode implicar em
termos técnicos, existe um “auto-login” onde o utilizador é identificado automatica-
mente pelo primeiro nome. Todos os detalhes contam para a experiência do utiliza-
dor neste novo espaço, regra geral todos preferimos ser tratados pelo nome em vez
de um código numérico ou uma sigla.

As novas alterações têm em conta o aspecto visual atual do site. Os novos elementos
devem enquadrar-se com o interface atual, mantendo a ideia geral que as pessoas
têm da ferramenta. Numa fase posterior é preferível criar um novo interface, para
melhorar a experiência do utilizador, porém, numa fase incial as alterações são me-
nores e focadas em dar uma nova utilização, visualmente pouco disruptiva.

De acordo com estes pressupostos, na Figura 75, podemos ver o menu da ferramen-
ta atual à esquerda e a nova sugestão à direita, com aspetos semelhantes mas fun-
ções bem diferentes.

Outra das vantagens em utilizar uma plataforma interna para uma nova função, é a
possibilidade de toda a comunidade estar automaticamente inscrita, permitindo que
a colaboração na nova estratégia tenha menos entraves, sem necessidade de regis-
to e disponibilização de dados. Por exemplo, a utilização do LinkedIn em certa parte
poderia servir a partilha de ideias e conteúdos, mas teria a grande desvantagem de
excluir todos os colaboradores que não tivessem conta nesse rede social ou não ti-
vessem intenções de criar.
132 . TRABALHO PRÁTICO

Na nova Intra, os conteúdos podem ser partilhados com todos os colaboradores da

CSW, ou num círculo restrito, fazendo menção das pessoas com quem querem par-
tilhar (Figuras 76 e 77). Esta opção, muito similar a um email, permite a avaliação e
amadurecimento das ideias em círculos restritos e de confiança.

A utilização do email, como já foi referido, é um complemento na ligação da nova pla-

taforma. O email deve funcionar como lembrete de assuntos importantes a aconte-
cer na plataforma, de forma pontual e pouco intrusiva. O utilizador recebe um email
com o resumo da mensagem e caso a pretenda visualizar segue a ligação directa para
plataforma, onde pode ver o assunto completo.

A ideia geral na nova Intra, segue o princípio de aumentar e potenciar a comunicação

entre todos. Assim, a quantidade pode gerar qualidade e qualquer ideia ou assunto
partilhado pode vir a ser uma ideia com potencial de lucro para a organização. Desta
forma é importante que os responsáveis fomentem a discussão, moderem o tipo de
ideias partilhadas, promovam concursos, entre outras atividades.

Na Figura 79, podemos ver a categoria “Ideas Bank” destinada a mostrar, numa cate-
goria separada das notícias gerais, todas as ideias com potencial de lucro. Este espa-
ço dedicado, permite seguir com clareza todas as ideias interessantes neste campo
sem o ruído de outros assuntos.

A categoria “Ideas Bank” como o próprio nome indica é um depósito de ideias, onde
se pode colocar ideias diretamente para o programa (Figura 80), ou caso isso não
aconteça, serem transferidas para essa categoria posteriormente por alguém res-
ponsável pelo programa (Figura 81).

É sempre difícil percebermos se uma ideia nova tem ou não potencial para gerar lu-
cro. A forma como a ferramenta está a ser concebida, reflete isso mesmo, podermos
partilhar qualquer coisa sem à partida a classificarmos, o que dá alguma liberdade de
ação aos utilizadores.

Esta plataforma pretende ser essencialmente um meio de comunicação entre a co-

munidade. Criar um plataforma específica para a partilha de ideias com potencial

Figura 75 - Menu de navegação da Intra antiga (esquerda) e da versão proposta (direita) com aspeto
visual semelhante.
 TRABALHO PRÁTICO . 133

de lucro seria demasiado redutor e inibidor para quem não acha que pode ter boas
ideias. Aliás, este é um erro da maior parte das pessoas. Todos podemos ter boas
ideias ou contribuir para melhorar as ideias dos outros. Será este o objetivo máxi-
mo da plataforma.

A classificação de ideias ou assuntos da plataforma é feita com “tags” (Figura 81), ou

seja, palavras que indicam o assunto, ou os assuntos, no caso de ser atribuída mais do
que uma “tag”, que permite ordenar e agrupar as ideias por tópicos específicos. Assim,
os utilizadores procuram por temas de interesse e seguem os seus assuntos favoritos.

A diferença de interesses das pessoas e a forma pouco organizada como as redes so-
ciais têm trabalhado esse assunto é um dos motivos de descontentamento de uma
parte dos utilizadores (inclusive alguns dos entrevistados). Nas redes sociais, por de-
feito seguimos as publicações de qualquer pessoa, mesmo que não partilhemos as-
suntos de interesse.

Não sei se esta é a solução para esse problema, mas é importante que seja conside-
rada uma preocupação a ter conta no futuro.

O desenho desta ferramenta ainda está longe de estar terminado, esta é apenas a se-
gunda abordagem ao problema, que naturalmente terá as suas falhas.

Figura 76 - Partilha privada de assuntos com pessoas mencionadas.

134 . TRABALHO PRÁTICO

Figura 77 - Conteúdo privado, visível apenas para as pessoas mencionadas na publicação.

O desenho de interação e sua preocupação pela experiência dos utilizadores com as

ferramentas, aborda na maior parte das vezes mais do que o desenho de um interfa-
ce. Essa é apenas uma parte dos problemas que são encontrados no contacto com os
utilizadores e esse contacto direto nunca é suficiente para perceber as verdadeiras
necessidades ou problemas. Aquilo que os utilizadores dizem que fazem, raramente
é o que efetivamente fazem.

É necessário fazer mais perguntas, testar desenhos com utilizadores, voltar a desenhar,
testar protótipos funcionais, fazer “brainstormings” de problemas reais, criar tempos de
inovação, transformar problemas em projetos, etc. No fundo é necessário criar uma co-
munidade aberta à partilha e discussão de ideias e dar-lhe argumentos para isso.

Este projeto, ainda incompleto mas em fase de desenvolvimento, deve no futuro fa-
zer parte de uma estratégia maior em que a ferramenta apenas representa uma par-
te da solução e mais pessoas experientes possam dar o contributo. Só assim, com um
espírito de missão global, será possível mudar hábitos e comportamentos em prol de
uma cultura de inovação, capaz de reinventar o seu futuro.
 TRABALHO PRÁTICO . 135

Figura 78 - Notificação de email. Pretende ligar os utilizadores com a Intra.

Figura 79 - Categoria “Ideas Bank” ainda sem qualquer ideia para mostrar.
136 . TRABALHO PRÁTICO

Figura 80 - Criação de uma ideia ou publicação diretamente no “Ideas Bank”.

 TRABALHO PRÁTICO . 137

Figura 81 - Depois da classificação de uma publicação normal como “Ideas Bank”, ela passa a ser
mostrada na categoria de notícias e ideias.
CONCLUSÃO
 141

Conclusão
A análise teórica desenvolvida e apresentada nesta tese, incide sobre o design de in-
teração enquanto disciplina do processo de desenvolvimento de produtos digitais.
Com reflexões e metodologias sugeridas por vários especialistas, procurou-se um
suporte teórico diverso capaz de sustentar o trabalho prático realizado durante o
período de estágio na Critical Software.

Como mediador da relação entre o homem e os produtos digitas, o design de intera-

ção centra-se nas pessoas para perceber de que forma os produtos digitais podem
facilitar a sua vida. Entende-se que só com uma exposição e vivência constante com
os utilizadores de produtos digitais, é possível perceber a forma como os usam, que
obstáculos encontram e o que torna a experiência de utilização agradável.

O design centrado no utilizador, com ênfase no utilizador final dos produtos, foi o
ponto de partida para o trabalho prático. De acordo com o trabalho de Moggridge,
Cooper, Brown ou Spool, procurou-se um contacto e comunicação constantes com
os utilizadores, através de entrevistas, conversas, sessões de desenho colaborativo,
criação e análise de protótipos, etc. Transformou-se depois a informação recolhida
numa exploração concetual que possibilitou a criação de interfaces o mais próximos
possível das necessidades dos utilizadores.

O trabalho dos especialistas e referências de interação serviu como hipótese a ser

testada no trabalho prático. Procurou-se, sempre, reflectir criticamente sobre os
métodos utilizados nas respostas diárias dadas ao trabalho solicitado pela CSW.

Os dois projetos desenvolvidos durante o estágio, enquadram-se numa fase de ex-

ploração projetual, anterior à construção e utilização dos produtos digitais. As téc-
nicas utilizadas de análise e exploração dos problemas, permitiram em certa medida
redefinir os problemas apresentados inicialmente. A exposição e vivência constan-
te com os utilizadores, permitiu recolher informação preciosa, que foi um importan-
te contributo na definição e redireccionamento de soluções para novas ferramenta
a desenvolver ou práticas a fomentar e implementar.

Embora a tecnologia nos permita lidar com questões extremamente complexas, que
de outra forma seria difícil ou impossível, a exploração apresentada neste trabalho
relegou a tecnologia para segundo plano. Os comportamentos humanos e o seu con-
texto, foram sempre a fonte de informação principal.

Os métodos de recolha de informação revelaram-se uma base sólida para a fase ex-
perimental de desenho dos protótipos dos interfaces, onde se arriscaram e elimi-
naram muitas hipóteses (interfaces). Ao longo deste processo, a transformação da
informação em protótipos de interfaces, foi uma importante forma de estabelecer
comunicação entre os intervenientes do projeto, ajudando a criar um mesmo modelo
mental do produto. O que leva a crer que o resultado da prototipagem - construção
142

da ferramenta ou implementação dos procedimentos - seja muito próxima daquela

que os utilizadores esperam.

Como exemplo, no projeto de gestão documental os desenhos criados para repre-

sentar numa primeira fase os fluxos de documentação, permitiram mostrar o conhe-
cimento adquirido sobre um processo complexo e confirmar a veracidade da infor-
mação. Numa segunda fase, os protótipos, permitiram materializar o conhecimento
e mostrar ao utilizador o que seria a ferramenta e como lhe poderia resolver o pro-
blema da gestão dos documentos. Aqui não se assume que cada protótipo é a solução
final. Cada protótipo criado e apresentado serve para testar hipóteses, confirman-
do ou não algumas soluções, e para refinar o cerne do problema e o seu contexto.

Esta fase projetual, ou ante-projetual, procura uma abordagem livre aos problemas.
Num processo longo e exaustivo, a maleabilidade dos interfaces, resultado da facili-
dade com que se vão criando ou alterando, cria um debate rico em direção a um re-
sultado satisfatório á maioria. Ou pelo menos, caminha de acordo com as expetati-
vas dos futuros utilizadores.

Por outro lado, o facto de não existir uma solução inicial para o problema, cria um
espaço temporal de descoberta difícil de definir e com um esforço elevado dos
colaboradores.

O espaço temporal em que decorreu o estágio, não permitiu o desenvolvimento

completo dos produtos iniciados nos dois projetos propostos, DMS e iTi´s. Facto,
que impossibilitou uma avaliação mais avançada dos métodos e resultados explora-
dos nesta fase projetual de desenho dos interfaces.

Como trabalho futuro, na construção dos produtos desenvolvidos neste trabalho,

deve-se refletir de forma crítica sobre todos os métodos e soluções encontradas na
fase projetual. Embora se devam manter alguns princípios que orientaram todo o
trabalho de estágio.

O design de interação - e a preocupação com a experiência dos utilizadores dos

produtos digitais, é uma disciplina entre várias outras, que procura melhorar todo o
processo de desenvolvimento de software.

Assumir que nada sabemos, é o ponto de partida para construir em conjunto com
os envolvidos, uma definição para os problemas que enfrentamos. E só com trabalho
conjunto e cooperação se pode construir produtos com valor.

A essência de grande parte dos problemas que nos afetam, está na nossa condição
humana. É fundamental que entendamos os nossos comportamentos e o contexto
em que se desenvolvem, para que os produtos, sejam eles digitais ou não, possam ter
significado nas nossas vidas.
143
REFERÊNCIAS
 147

1. Alben, L. (1997). At the Heart of Interaction Design. Design Management Journal pp. 9-26

2. Anderson, D. (2011). Lean Software Development. Microsoft Corporation

3. Berkun, S. (2001, Novembro). Strategies of Influence for

Interaction Designers. [Online]. (URL http://scottberkun.com/
essays/18-strategies-of-influence-for-interaction-designers/)

4. Brown, T. (2012). The Merits of an Evolutionary Approach to Design. Rotman

Magazine Spring 2012. pp. 17-21

5. Brown, T., Katz, B. (2009). Change by Design - How Design Thinking Transforms
Organizations and Inspires Innovation, HarperCollins e-books.

6. Buxton, W. (2003). Performance by Design: The Role of Design in Software Product

Development. Proceedings of the Second International Conference on Usage-
Centered Design. Portsmouth. pp. 1-15

7. Cockburn, A. (2001). Agile Software Development - Draft version: 3b

8. Cockburn, A. (2003). People and Methodologies in Software Development. Faculty

of Mathematics and Natural Sciences, University of Oslo, Norway

9. Cooper, A., Reimann, R., Cronin, D. (2007). About Face 3: The Essentials of
Interaction Design. Indianapolis, Indiana. Wiley Publishing, Inc.

10. Cooper, A. (2008). The origin of personas. [Online]. (URL http://www.cooper.com/

journal/2008/05/the_origin_of_personas.html)

11. Critical. (2013). [Online] (URL http://www.criticalsoftware.com/corporate/)

12. Cusumano, M., Smith, S. (1995). Beyond the Waterfall: Software Development at
Microsoft. MIT Sloan School of Management

13. Davis, K. (2013). Disrupt Your Thinking, Transform Your Business. [Online]. (URL
http://www.entrepreneur.com/article/227045)

14. Dubberly, H. (1995). Managing Complex Design Projects. Presentation at the “Living
Surfaces” interactive media conference sponsored by the American Center for
Design March/April 1995

15. Dubberly, H. (2004). How do you design?. Dubberly Design Office. San Francisco

16. Edinger, S., (2012). Don’t Innovate. Create a Culture of Innovation.

[Online] (URL http://www.forbes.com/sites/scottedinger/2012/11/20/
dont-innovate-create-a-culture-of-innovation)

17. Eno, B. (1999). The Revenge of the Intuitive, [Online]. (URL http://www.wired.com/
wired/archive/7.01/eno.html)

18. Ferreira, J. (2007). Interaction Design and Agile Development: A Real-World

Perspective. A thesis submitted to Victoria University of Wellington

19. Fogg, BJ. (2009). Creating Persuasive Technologies: An Eight-Step Design Process
Persuasive Technology Lab. Stanford University
148

20. Forlizzi, J., Battarbee, K. (2004) Understanding Experience in Interactive Systems.

Carnegie Mellon University, University of Art and Design Helsinki.

21. Garrett, J.J. (2011). The Elements of User Experience: User-Centered Design for the
Web and Beyond. 2nd ed. Berkeley. New Riders.

22. Gothelf, J. (2013). Lean UX - Applying Lean Principles to Improve User Experience,
O’ Reilly

23. Hartmann, B. (2009). Gaining Design Insight Through Interaction Prototyping

Tools. Stanford University, A Dissertation submitted for the degree of Doctor of
Philosophy

24. InnovationPoint & Idea Crossing (2006). Idea Competitions and Breakthrough
Innovation. [Online] (URL http://www.innovation-point.com/Idea%20
Competitions%20and%20Breakthrough%20Innovation.pdf)

25. Kay, A. (1989). Predicting The Future. Stanford Engineering, Volume 1, Number 1,
Autumn 1989, pp. 1-6

26. Kapor, M. (1996). Bringing Design to Software, Addison-Wesley

27. Kelley, T., Littman, J. (2008). The Ten Faces of Innovation: Strategies for Heightening
Creativity. London. Profile Books Ltd.

28. Kohli, J. e Mulgan, G. (2010). 24 Ways Governments and Organizations Are

Generating Great Ideas in the Public Sector. [Online]. (URL http://www.
americanprogress.org/issues/open-government/news/2010/07/01/8091/24-
ways-governments-and-organizations-are-generating-great-ideas-in-the-public-
sector)

29. Manovich, L., (2013). Software Takes Command. Bloomsbury Publishing Plc.

30. Miller, L. (2005). Case Study of Customer Input For a Successful Product. Alias,
Toronto, Canada

31. Moggridge, B. (2007). Designing Interactions. 1st ed. Cambridge, Massachusetts: The
MIT Press

32. Murray, J. (2012). Inventing the Medium - Principles of Interaction Design as a

Cultural Practice. The MIT Press, Cambridge, London.

33. Nielsen, J,. (1995, 1 Janeiro). 10 Usability Heuristics for User Interface Design.
[Online] (URL http://www.nngroup.com/articles/ten-usability-heuristics/)

34. Norman, D. (1988). The Design of Everyday Things. Basic Books

35. Norman, D. . Technology First, Needs Last. [Online]. (URL http://jnd.org/dn.mss/

technology_first_needs_last.html)

36. Patton, J. (2002). Hitting the Target: Adding Interaction Design to Agile Software
Development, Tomax Technologies, Salt Lake City

37. Petersen, K. (2010). Implementing Lean and Agile Software Development in

Industry. Blekinge Institute of Technology, Doctoral Dissertation
 149

38. Rannikko, P. (2011). User-Centered Design in Agile Software Development,

University of Tampere, M.Sc. Thesis

39. Reimann, R. (2008, 15 Maio) So you want to be an interaction designer [Online]. (URL
http://www.cooper.com/journal/2001/06/so_you_want_to_be_an_interacti.html)

40. Reimer, J. (2005, 5 Maio). A History of the GUI. [Online] (URL http://arstechnica.
com/features/2005/05/gui/)

41. Rodriguez, D., Jacoby, R. (2007). Embracing Risk to Learn, Grow and Innovate,
Rotman Magazine Spring 2007. pp. 55-58

42. Royce, W. W., (1970). Waterfall: Managing the Development ff Large Software Systems

43. Schuler, G. (2013). Getting Big Ideas Out of Small Numbers. [Online]. (URL http://
www.cooper.com/journal/2013/05/getting-big-ideas-out-of-small-research.html)

44. Serena, (2007). An Introduction to Agile Software Development

45. Seys, P. (2010, 13 Agosto). 11 Principles of Interaction

Design explained. [Online]. (URL http://shortboredsurfer.
com/2010/08/11-principles-of-interaction-design-explained/)

46. Shimmell, K. (2012, 24 Novembro). Learning by Design: It’s Not What You
Know, But How You Think. [Online]. (URL http://www.good.is/posts/
learning-by-design-it-s-not-what-you-know-but-how-you-think)

47. Shneiderman, B. (2003). Designing the User Interface. Pearson Education.

48. Smith, J. (2012). The Basics of Great UX. [Online] (URL http://webdesign.tutsplus.
com/tutorials/ux-tutorials/the-basics-of-great-ux)

49. Sy, D. (2007). Adapting Usability Investigations for Agile User-centered Design.
Autodesk, Toronto, Canada

50. SPOOL, J. (1996). Bridging Conceptual Gaps. [Online]. (URL http://www.uie.com/

articles/conceptual_gaps)

51. Soper, T. (2013). Advice from a former Apple director who coined the
term ‘user experience’. [Online] (URL http://www.geekwire.com/2013/
mitch-stein-user-experience/?goback=%2Egde_72842_member_249740715)

52. Surowiecki, J. (2007, 28 Maio). Feature Presentation. [Online] (URL http://www.

newyorker.com/talk/financial/2007/05/28/070528ta_talk_surowiecki)

53. Tidwell, J. (2005). Designing Interfaces. 1st ed. O’Reilly

54. Tognazzini, B,. First Principles of Interaction Design. [Online] (URL http://www.
asktog.com/basics/firstPrinciples.html)

55. Tucker, R,. Seven Strategies for Generating Ideas. [Online] (URL http://
innovationresource.com/resources/seven-strategies)
ÍNDICE DE IMAGENS
 153

Índice de Imagens
18 Figura 1 - Sketchpad de Ivan Sutherland, 1962.

19 Figura 2 - oN-Line System de Doublas Engelbart, 1968.

19 Figura 3 - Réplica exata do primeiro rato inventado por Douglas Engelbart,

criado pela empresa SRI, criadora da versão original.

20 Figura 4 - À esquerda o computador Alto da Xerox de 1973 e à direita

o interface do seu gestor de ficheiros.

21 Figura 5 - O interface e ambiente de desenvolvimento do Smalltalk.

22 Figura 6 - O interface do computador Lisa da Apple.

23 Figura 7 - O Windows 1.0 da Microsoft.

23 Figura 8 - Workbench da Commodore Amiga computers, 1985.

24 Figura 9 - Windows 2.0 da Microsoft, 1987.

24 Figura 10 - Arthur da Acorn computer, 1987.

25 Figura 11 - NeXTSTEP, 1988.

26 Figura 12 - Microsoft Windows 3.0.

26 Figura 13 - Microsoft Windows 95.

27 Figura 14 - Mac OS X “Aqua”.

44 Figura 15 - Diagrama original de Royce (1970) com as etapas da metodologia

Waterfall.

47 Figura 16 - Comparação das metodologias Waterfall e Agile.

No desenvolvimento Agile são realizadas várias etapas com mini-versões
do produto (cada uma criada num período de 2-4 semanas).
Adaptado do “Cutter Consortium” (Sy, 2007).

71 Figura 17 - Sede da Critical Software em Coimbra.

81 Figura 18 - Plano de trabalho dos dois projetos.

85 Figura 19 - Esquema visual do ciclo de vida de um Case Study, desenhos

de Rui Cordeiro (CSW).

86 Figura 20 - Exemplo de um template de um Case Study da Critical Software.

86 Figura 21 - Esboço do ciclo de vida de um Case Study e seus responsáveis.

O desenho mostra a perspetiva de cada um dos cargos sobre o ciclo de vida
do documento e a análise de alguns padrões.
154

87 Figura 22 - Ciclo de vida do Case Study (a azul) dentro do espaço temporal

de um projeto.

88 Figura 23 - Divisão em 3 áreas dos cargos interessados no documento

de Case Study.

89 Figura 24 - O problema é o mesmo, mas as necessidades de cada cargo

são diferentes.

90 Figura 25 - Primeiro desenho ou aproximação ao interface de controlo

dos Case Studies.

92 Figura 26 - Protótipo não funcional do interface.

93 Figura 27 - O estado do Case Study foi um dos elementos que permaneceu

após o primeiro interface.

93 Figura 28 - Web site da Intranet interna da CSW (site atual).

94 Figura 29 - Lista de Projetos a decorrer e concluídos

94 Figura 30 - Detalhes do Case Study do projeto.

95 Figura 31 - Criação do Case Study.

95 Figura 32 - “Two panel selector” Apple mail.

95 Figura 33 - “Two panel selector” Windows Explorer.

96 Figura 34 - Interface com ordenação das colunas da lista.

98 Figura 35 - Formulário de preenchimento do Case Study pelos PM’s

(Project Managers).

98 Figura 36 - Depois de preenchido, é possível ver os documentos associados

ao PM.

99 Figura 37 - Resumo dos documentos já preenchidos.

99 Figura 38 - Acesso aos detalhes do Case Study.

100 Figura 39 - Lista de Case Studies.

100 Figura 40 - Two panel selector da lista de Case Studies com vista dos detalhes.

101 Figura 41 - Atribuição de um user para aprovar o Case Study.

102 Figura 42 - Aprovação do Case Study.

102 Figura 43 - Controlo do estado do Case Study.

103 Figura 44 - Lista de Case Studies com detalhes dos botões dropdown.

103 Figura 45 - Lista de Case Studies e respetivo detalhe de cada projeto.

104 Figura 46 - Exemplo de um botão com uma ação e vários estados associados.

105 Figura 47 - Testes com protótipos em papel.

 155

106 Figura 48 - Primeira opção do interface sem o Two panel selector.

106 Figura 49 - Área dedicada com informação do Case Study.

107 Figuras 50, 51, 52 e 53 - Sessão de revisão e desenho colaborativo.

108 Figura 54 - Estados de um Case Study.

108 Figura 55 - Novo protótipo com uma área maior dedicada à lista de projetos.

109 Figura 56 - Novo protótipo e a vista dos detalhes do Case Study.

110 Figura 57 - Login para administradores da ferramenta.

110 Figura 58 - Interface de pesquisa e controlo dos projetos e respetivos

Case Studies.

111 Figura 59 - Interface de detalhe do Case Study, controlo de ficheiros

e publicação dos mesmos.

111 Figura 60 - Acesso geral à ferramenta apenas com um campo de pesquisa

com uma sugestão.

112 Figura 61 - Primeiros esboços do estado do Case Study.

112 Figura 62 - Evolução, da esquerda para a direita, do estado do documento

do Case Study.

116 Figura 63 - Página da documentação interna sobre o fluxo do processo.

116 Figura 64 - Exemplo do formulário da work order para submissão de ideias.

117 Figura 65 - Sugestão de alteração ao processo com foco na fase antes

da submissão da ideia.

118 Figura 66 - Restabelecer credibilidade: O autor da ideia tem de saber

em todas as fases o que está a acontecer.

118 Figura 67 - Fluxo de uma ideia. Destaque para a avaliação de ideias.

119 Figura 68 - Primeiro interface Self-design para a ferramenta de iTi’s.

121 Figura 69 - Entrevista com Tânia Santos.

123 Figura 70 - Pedro e Maria, duas das Personas criadas.

124 Figura 71 - Fábio e Miguel as outras duas Personas criadas.

129 Figura 72 - Intra. Site interno da Critical Software.

130 Figura 73 - A vermelho está assinalada a zona onde se pretende inserir

novos conteúdos e funcionalidades.

130 Figura 74 - Novo interface da Intra. Destaque para o “auto-login”

ou identificação do utilizador.

132 Figura 75 - Menu de navegação da Intra antiga (esquerda) e da versão

proposta (direita) com aspeto visual semelhante.
156

133 Figura 76 - Partilha privada de assuntos com pessoas mencionadas.

134 Figura 77 - Conteúdo privado, visível apenas para as pessoas mencionadas

na publicação.

135 Figura 78 - Notificação de email. Pretende ligar os utilizadores com a Intra.

135 Figura 79 - Categoria “Ideas Bank” ainda sem qualquer ideia para mostrar.

136 Figura 80 - Criação de uma ideia ou publicação diretamente no “Ideas Bank”.

137 Figura 81 - Depois da classificação de uma publicação normal como

“Ideas Bank”, ela passa a ser mostrada na categoria de notícias e ideias.