Escolar Documentos
Profissional Documentos
Cultura Documentos
Usabilidade e Design de Interfaces
Enviado por
Ana de SousaTítulo original
Direitos autorais
Formatos disponíveis
Compartilhar este documento
Compartilhar ou incorporar documento
Você considera este documento útil?
Este conteúdo é inapropriado?
Denunciar este documentoDireitos autorais:
Formatos disponíveis
Usabilidade e Design de Interfaces
Enviado por
Ana de SousaDireitos autorais:
Formatos disponíveis
Usabilidade
e
Design
de
Interfaces
para
uma
Aplicação
Web
da
Premium
Minds
Francisco
Fernandes
Faia
Villa
De
Brito
Relatório
de
Estágio
de
Mestrado
em
Novos
Media
e
Práticas
Web
Julho,
2016
i
Relatório
de
Estágio
apresentado
para
cumprimento
dos
requisitos
necessários
à
obtenção
do
grau
de
Mestre
em
Novos
Media
e
Práticas
Web
realizado
sobre
a
orientação
científica
da
Professora
Doutora
Graça
Simões.
ii
Agradecimentos
À
mulher
da
minha
vida
pelo
amor.
À
minha
família
por
todo
o
suporte.
Aos
meus
amigos
pelo
companheirismo.
Ao
professor
Jaime
Ceia
pela
visão
sistémica
e
social
do
design.
A
todos
os
que
tenho
como
mestres,
por
indicarem
o
caminho.
À
professora
Graça
Simões
por
me
ter
introduzido
à
disciplina
da
usabilidade
e
por
me
ter
orientado
na
componente
não
lectiva
do
mestrado.
Ao
professor
António
Câmara
pela
confiança.
A
todos
os
meus
professores
e
colegas
do
mestrado
Novos
Media
e
Práticas
Web
pela
partilha
de
conhecimento.
À
Universidade
Nova
de
Lisboa
e
Faculdade
de
Ciências
Sociais
e
Humanas
por
terem
um
espírito
jovem
e
criarem
pontes
entre
o
mundo
académico
e
o
mundo
profissional.
À
Joana
Araújo
e
à
equipa
de
design
por
me
terem
recebido
com
hospitalidade
e
me
terem
aconselhado
durante
o
estágio.
Ao
Alexandre
Fernandes
e
ao
Francisco
Areia
por
terem
acompanhado
de
perto
o
trabalho
que
desenvolvi
e
me
terem
ensinado
na
prática
a
filosofia
Agile.
A
todas
as
pessoas
que
contribuíram
para
o
projecto
que
desenvolvi
durante
o
estágio.
A
todos
os
colaboradores
da
Premium
Minds
(equipa
de
gestão,
DAF,
Product
Managers,
Agile
Coachs,
Engenheiros
de
Sistemas,
Markteers,
Designers,
Arquitectos,
Developers,
Data
Scientists
e
Quality
Engineers)
pelos
valores
e
boa
disposição.
À
Premium
Minds
pelo
bom
ambiente
de
trabalho
e
abertura
à
inovação.
iii
We
can
embrace
the
flexibility
inherent
to
the
web,
without
surrendering
the
control
we
require
as
designers.
Marcotte,
2011
iv
USABILIDADE
E
DESIGN
DE
INTERFACES
PARA
UMA
APLICAÇÃO
WEB
DA
PREMIUM
MINDS
FRANCISCO
FERNANDES
FAIA
VILLA
DE
BRITO
RESUMO
PALAVRAS-‐CHAVE:
Aplicação
Web,
Design
de
Experiências,
Design
Centrado
no
Utilizador,
Usabilidade,
Design
de
Interfaces,
Design
Atómico,
Desenvolvimento
Ágil
de
Software
Como
integrar
as
metodologias
User
Centered
Design,
Atomic
Design
e
Agile
Software
Development?
O
estágio
relatado,
em
conjunto
com
as
considerações
que
levantou,
são
uma
tentativa
de
responder
à
questão
anterior.
Decorrido
na
Premium
Minds,
uma
empresa
de
software,
o
estágio
realizado
teve
como
foco
principal
o
processo
iterativo
de
design
de
uma
aplicação
web.
Das
várias
tarefas
desempenhadas
destacam-‐se
os
fluxos
de
utilizador,
a
arquitectura
de
informação,
os
wireframes,
os
walktroughs,
os
testes
de
usabilidade
e
os
mockups.
Ao
longo
do
projecto
foram
surgindo
discordâncias
entre
as
metodologias
de
design
e
as
metodologias
da
engenharia
e
do
negócio.
Estas
diferenças
levaram
à
reflexão
de
que
para
optimizar
o
potencial
de
cada
disciplina
é
necessária
a
utilização
de
workflows
híbridos.
ABSTRACT
KEYWORDS:
Web
App,
UX
Design,
User-‐Centered
Design,
Usability,
UI
Design,
Atomic
Design,
Agile
Software
Development
How
to
best
integrate
the
methodologies
of
User-‐Centered
Design,
Atomic
Design
and
Agile
Software
Development?
The
internship
here
reported,
along
with
all
the
considerations
it
raised,
are
an
attempt
to
answer
this
very
question.
Taken
place
at
Premium
Minds,
a
software
house,
this
internship's
main
focus
was
the
iterative
process
of
designing
a
web
application.
Of
the
various
subjects
I
was
tasked
with,
information
architecture,
user
flows,
wireframing,
walktroughs,
usability
testing
and
mockups,
stand
out.
Through
the
course
of
this
project,
some
conflicts
arose
between
design
methodologies,
and
methodologies
of
business
and
engineering.
These
differences
led
to
the
reflection
that,
in
order
to
optimize
the
potential
of
each
field,
usage
of
hybrid
workflows
is
required.
v
ÍNDICE
Introdução
........................................................................................................................
1
PARTE
I
-‐
Contextualização
................................................................................................
3
Capítulo
1:
Enquadramento
Teórico
.......................................................................
4
1.1.
UX
Design
........................................................................................................
4
1.2.
UI
Design
.........................................................................................................
5
1.3.
Agile
e
Design
.................................................................................................
7
Capítulo 2: Caracterização da Empresa ................................................................... 9
2.1. Premium Minds ............................................................................................... 9
2.2. Clientes e Produtos ......................................................................................... 9
2.3. Colaboradores ............................................................................................... 10
2.4. Cultura Empresarial ....................................................................................... 11
PARTE II -‐ Projecto ........................................................................................................... 13
Capítulo 3: Pictty: uma Web App de Fotografia .................................................... 14
3.1. Relato Geral do Projecto ............................................................................... 15
3.1.1. Briefing e Planeamento ....................................................................... 15
3.1.2. Benchmarking e Fluxos de Utilizador .................................................. 16
3.1.3. Wireframes e Walktroughs ................................................................. 18
3.1.4. Testes de Usabilidade .......................................................................... 19
3.1.5. Design Visual ....................................................................................... 20
3.2. Desafios de Design ........................................................................................ 22
3.2.1. Votação e Gamification ....................................................................... 22
3.2.2. Jogo de Imagens e Cartas .................................................................... 24
3.2.3. Upload e Metadados ........................................................................... 25
3.2.4. Wallet e Depósito de Fundos .............................................................. 26
3.2.5. Comunidade e Social Sharing .............................................................. 28
Capítulo 4: Outros Trabalhos ................................................................................ 30
4.1. Encomendados .............................................................................................. 30
4.2. Auto-‐propostos .............................................................................................. 31
Conclusão
e
Considerações
Finais
....................................................................................
33
Bibliografia
......................................................................................................................
36
Lista
de
Figuras
................................................................................................................
38
Anexos
............................................................................................................................
40
vi
Introdução
O
estágio
curricular
aqui
relatado
teve
como
propósito
aplicar,
num
contexto
profissional,
os
conhecimentos
adquiridos
na
componente
lectiva
do
mestrado
em
Novos
Media
e
Práticas
Web.
Foi
realizado
na
empresa
Premium
Minds,
uma
empresa
de
desenvolvimento
de
software,
à
qual
concorri
por
me
ter
identificado
com
a
sua
cultura
organizacional.
A
empresa
aceitou-‐me,
integrou-‐me
na
equipa
de
design
e
responsabilizou-‐me
por
um
projecto
ousado.
O
estágio
teve
uma
duração
total
de
400
horas
distribuídas
ao
longo
de
quatro
meses.
O
presente
relatório
está
estruturado
em
cinco
capítulos.
Primeiro,
apresenta
um
enquadramento
teórico
sobre
as
metodologias
e
técnicas
de
usabilidade
e
design
de
interfaces
que
sustentaram
o
trabalho
desenvolvido
no
âmbito
do
estágio.
São
também
enunciados
paralelismos
entre
as
abordagens
e
metodologias
User
Centered
Design,
Atomic
Design
e
Agile.
Em
segundo
lugar,
no
Capítulo
"Caracterização
da
Empresa",
é
caracterizada
a
instituição
onde
decorreu
o
estágio;
é
descrito
o
reconhecimento
que
a
Premium
Minds
tem
no
mercado,
quais
os
seus
clientes
e
produtos,
as
variadas
disciplinas
dos
seus
colaboradores
e
a
sua
cultura
organizacional
sui
generis.
O
terceiro
capítulo
descreve
o
projecto
principal
do
estágio:
o
design
de
uma
aplicação
web
para
fotógrafos,
que
se
distingue
pela
vertente
de
jogo
e
potencial
de
ganhar
dinheiro.
Neste
capítulo
será
narrado
o
briefing
do
cliente
e
o
plano
de
tarefas
realizado
com
o
product
manager.
Será
relatado
o
que
aconteceu
ao
longo
do
projecto,
especificando
as
várias
decisões,
iterações,
fases
de
trabalho
e
momentos-‐chave
tais
como
os
fluxos
de
utilizador,
os
wireframes,
os
testes
de
usabilidade
e
os
mockups.
São
ainda
referidos
alguns
dos
desafios
de
design
que
surgiram
ao
longo
do
projecto
e
as
soluções
encontradas.
Por
último,
são
explicados
aspectos
específicos
da
aplicação
web
para
fotógrafos:
a
gamification,
o
sistema
de
cartas,
o
upload
de
imagens,
o
movimento
de
dinheiro
e
a
dimensão
de
rede
social.
Para
ilustrar
o
modelo
conceptual,
o
funcionamento
da
aplicação
Pictty
e
o
trabalho
por
mim
realizado,
o
leitor
é
remetido,
ao
longo
do
texto,
para
imagens
e
esquemas
que
criei
com
o
intuito
de
explicar,
de
uma
forma
visual,
os
assuntos
tratados
no
texto.
Tendo
sido
esta
aplicação
web
o
trabalho
central
do
presente
relatório,
e
no
qual,
de
uma
forma
mais
intensa,
me
foi
possível
testar
a
aplicação
de
toda
a
massa
crítica
estudada,
os
processos
e
trabalhos
são
relatados
contemplando
as
várias
ideias
que
surgiram
e
que
muitas
vezes
não
foram
aplicadas
e,
também,
a
relação
com
o
cliente.
Após
o
capítulo
principal—Pictty,
uma
Web
App
de
Fotografia—,
existe
um
breve
relato
de
outros
trabalhos
que
desenvolvi
no
estágio,
quer
de
web
design,
quer
de
design
gráfico
e
editorial
—
Capítulo
“Outros
Trabalhos”.
Por
último,
no
Capítulo
“Conclusão
e
Considerações
Finais”
são
enunciados
os
vários
aspectos
positivos
do
estágio
e
também
as
dificuldades
que
encontrei
em
integrar
1
abordagens
e
metodologias
próprias
do
design
numa
empresa
de
engenharia
de
software.
Desta
experiência,
resultou
uma
reflexão
e
proposta
de
como
integrar
as
abordagens
destas
duas
áreas
num
projecto
semelhante.
Tentando,
da
forma
mais
fidedigna
possível,
relatar
a
minha
experiência
de
trabalho,
o
texto
que
aqui
apresento
é,
não
raras
vezes,
bastante
descritivo
e
utiliza
recorrentemente
expressões
em
inglês
para
as
quais
não
encontrei
uma
tradução
que
de
facto
correspondesse
ao
seu
significado,
especialmente
no
que
toca
à
designação
de
processos,
metodologias
e
cargos
específicos
da
área
em
que
o
meu
estudo
se
enquadra.
Outro
momento
em
que
as
expressões
originais
em
inglês
foram
mantidas
foi
na
referência
a
páginas
da
aplicação
Pictty,
de
forma
a
facilitar
a
correspondência
entre
o
meu
texto
e
as
imagens
do
projecto
apresentadas
no
fim
deste
estudo.
2
PARTE
I
-‐
Contextualização
3
Capítulo 1: Enquadramento Teórico
1.1. UX Design
O design de experiências, ou UX design, é o processo de melhorar a experiência do
utilizador e, simultaneamente, acrescentar valor ao negócio. Tem como objectivo tornar o
produto útil, encontrável1 e acessível2, que a sua interface seja usável e desejável, e que a
informação que veicula seja credível (Morville, 2004). Associado ao UX design está o design
centrado no utilizador, ou UCD (Allen & Chudley, 2012). Trata-‐se de uma aborgadem e
metodologia que considera as necessidades, desejos e limitações dos utilizadores finais em
cada fase do processo de design, de modo a melhorar a usabilidade, ou seja, a facilidade de
uso de uma interface (Colborne, 2011). O UCD usa um processo iterativo que alterna entre
fases de investigação, design e testes de usabilidade, tantas vezes quantas o orçamento e o
prazo o permitirem (fig.1, p. xx).
O processo de UX design num dado projecto segue, de uma forma geral, os
seguintes passos:
1) O início de um projecto de UCD começa com uma fase de investigação onde se analisa e
antecipa o modo como os utilizadores vão usar o produto (Allen, 2012). Nessa fase,
algum conhecimento sedimentado em psicologia cognitiva ajuda o UX designer a
compreender e antever o modo como as pessoas em geral percepcionam, pensam e
decidem (Weinschenk, 2011). Mas é através de métodos como (i) a análise da
concorrência, (ii) a criação de personas e o desenho de (iii) fluxos de utilizador que se
conseguem antecipar as peculiaridades dos utilizadores finais.
(i) A análise da concorrência, ou benchmarking, na perspectiva do UX e UI design,
consiste em estudar cuidadosamente os produtos da concorrência avaliando a sua
a usabilidade e interface.
(ii) As Personas são descrições curtas e vívidas de uma personagem fictícia extrapolada
de dados reais sobre os grupos de utilizadores expectáveis do produto. Ajudam a
equipa de produto a ter empatia pelos utilizadores finais e a priorizar o trabalho de
acordo com as suas necessidades.
(iii) Os fluxos de utilizador são diagramas que representam a rota de um utilizador para
realizar determinadas tarefas. Este método permite simplificar as ditas rotas e,
deste modo, melhorar a experiência do utilizador (Allen & Chudley, 2012).
2) O passo seguinte consiste em utilizar a informação obtida na fase de design. Inclui as
fases de (i) estruturação da arquitectura de informação, (ii) execução de wireframes e
(iii) projecção de walkthroughs.
1
Por
encontrável
entenda-‐se
a
qualidade
do
produto
de
ser
fácil
de
localizar,
através
de
um
motor
de
busca
ou
dentro
de
um
website
na
web.
2
A
qualidade
de
ser
acessível
refere-‐se
a
ser
passível
de
ser
acedido
e
utilizado
por
pessoas
com
deficiência
(visual,
motora
ou
outra).
4
(i) Por
arquitectura
de
informação
entende-‐se
o
processo
de
agrupar
e
intitular
conteúdo,
proporcionando
caminhos
para
que
os
utilizadores
cheguem
até
ele
(Spencer,
2010).
Afecta,
portanto,
o
quão
fácil
os
sistemas
são
de
usar.
(ii) Os
wireframes
são
diagramas
de
baixa
fidelidade
que
representam
o
layout
de
um
site
ou
aplicação.
A
sua
relevância
no
processo
de
design
deve-‐se
ao
facto
de
permitem
explorar,
testar
e
iterar
ideias
de
design
numa
fase
inicial
do
projecto,
momento
em
que
as
mudanças
não
vão
aumentar
o
orçamento
do
trabalho.
É
importante
que
as
pessoas
responsáveis
pela
criação
de
conteúdo
estejam
envolvidas
no
processo
de
wireframing,
dado
que
é
difícil
que
um
wireframe
suporte
o
sentido
do
conteúdo
quando
o
conteúdo
não
está
lá.
(iii) walkthrough
é
uma
forma
de
apresentar
os
wireframes
onde
se
simulam
as
acções
e
pensamentos
de
um
utilizador
fictício
ao
percorrer,
passo
a
passo,
os
principais
fluxos
do
produto
(Allen
&
Chudley,
2012).
3) Após
a
fase
de
design,
quer
as
ideias
tenham
ganho
a
forma
de
wireframes,
walktroughs
ou
protótipos
de
baixa
fidelidade,
chega
a
fase
de
recolha
de
feedback.
Nesta
fase,
para
além
de
se
obter
o
feedback
da
equipa
de
produto,
cliente
e
stackholders,
procura-‐se
validar
os
pressupostos
da
fase
de
investigação,
recorrendo
a
testes
de
usabilidade
com
utilizadores.
Estes
testes
consistem
em
observar
utilizadores
reais
a
usar
o
produto
com
o
objectivo
de
detectar
obstáculos
que
possam
confundi-‐los
ou
frustrá-‐los.
Idealmente,
os
testes
de
usabilidade
devem
ser
realizados
desde
as
primeiras
iterações
do
projecto,
pois
o
custo
de
emendar
os
problemas
encontrados
é
muito
menor
(Krug,
2014).
1.2.
UI
Design
O
design
de
interfaces,
ou
UI
Design,
foca-‐se
em
garantir
que
os
elementos
da
interface
são
fáceis
de
aceder,
compreender
e
usar,
no
sentido
de
facilitar
as
tarefas
que
os
utilizadores
necessitam
de
realizar
(AA.VV.,
n.a.).
O
UX
design
e
o
UI
design
não
estão
separados;
o
UI
design
é
parte
integrante
do
UX
design
(Anderson
&
McRee,
2010).
Alguns
métodos
de
UX
design,
como
o
desenho
de
wireframes,
são
também
um
trabalho
de
UI
design,
na
medida
em
que
se
esboçam
os
layouts
e
padrões
da
interface.
No
entanto,
por
motivos
de
conveniência,
é
comum
chamar
UI
Design
a
uma
etapa
onde
o
aspecto
visual
da
interface
começa
a
ganhar
mais
fidelidade
(Frost,
2016).
Isto
não
significa
que
o
UI
design
deva
ter
como
principal
objectivo
a
criação
de
páginas
estáticas
de
alta-‐fidelidade,
os
aclamados
mockups3.
Isto
porque,
actualmente,
a
web
é
acedida
através
de
uma
grande
variedade
de
dispositivos
com
diferentes
características
—
smartphones,
tablets,
portáteis,
computadores
fixos,
televisões,
etc
—
pelo
que
essa
forma
de
abordar
o
design
está
3
Mockups
são
modelos
de
páginas,
em
tamanho
real
ou
à
escala,
que
apresentam,
de
forma
não
dinâmica,
o
aspecto
visual
de
uma
interface.
5
obsoleta
(Nielsen
&
Budiu,
2013).
Para
ir
de
encontro
a
essa
multiplicidade
de
formatos
surgiram
novas
abordagens
como
o
design
responsivo
e
o
design
atómico.
O
design
responsivo
é
uma
metodologia
de
design
e
de
front-‐end
development
que
permite
criar
uma
só
versão
do
produto
que
se
adapta
às
características
do
dispositivo
que
o
apresenta
(Marcotte,
2011).
Foca-‐se
na
criação
de
conteúdos
e
componentes
flexíveis
e
em
conjugá-‐los
em
diferentes
layouts
consoante
os
vários
tamanhos
do
ecrã
(fig.2,
p.
xx).
Tem
ainda
em
conta
outras
características
distintas
dos
dispositivos,
como
os
estilos
de
interação
(touch,
por
rato
e
teclado,
etc.),
o
modo
de
leitura
e
o
contexto
de
uso.
Segundo
esta
metodologia,
na
fase
de
wireframes
são
esboçadas
pelo
menos
duas
interfaces:
uma
para
mobile,
e
outra
para
desktop.
Se,
por
um
lado,
cada
interface
deve
ser
coerente
entre
si,
por
outro,
cada
uma
tem
de
corresponder
às
diretrizes
de
usabilidade
do
dispositivo
que
a
vai
incorporar
(Nielsen
&
Budiu,
2013).
Na
maior
parte
dos
projectos,
quer
nos
wireframes,
quer
nos
protótipos,
é
preferível
começar
pelos
ecrãs
pequenos
e
só
depois
passar
para
os
ecrãs
maiores
(Peterson,
2014).
Isto
deve-‐se
ao
facto
das
condicionantes
do
espaço
nos
ecrãs
pequenos
obrigarem
a
priorizar
os
conteúdos
e
funcionalidades
mais
importantes.
É
claro
que,
ao
se
passar
para
os
ecrãs
maiores,
se
podem
ir
adicionando
conteúdos
e
funcionalidades
secundárias.
O
design
atómico
é
uma
abordagem
e
metodologia
para
criar
sistemas
coerentes
de
componentes
de
interface
(Frost,
2013).
Após
os
wireframes
e
fluxos
de
utilizador
terem
sido
iterados
e
aprovados
pelo
cliente,
faz-‐se
um
inventário
de
interface:
uma
coleção
completa
dos
elementos
que
constituem
a
interface
agrupados
por
categorias
(Frost,
2016).
Entretanto,
o
front-‐end
developer
já
terá
configurando
o
ambiente
de
desenvolvimento
e
escrito
o
HTML
dos
padrões
que
vão
sendo
aprovados
nos
fluxos
de
utilizador
e
wireframes.
Deste
modo,
baseado
no
inventário
de
interface,
o
front-‐end
developer
escreve
o
HTML
dos
vários
componentes
da
interface
e,
apoiado
nos
wireframes,
escreve
o
CSS
dos
layouts
responsivos.
Isto
conduz
ao
desenvolvido
de
um
protótipo
funcional
responsivo
de
baixa
fidelidade
pronto
a
ser
sujeito
a
testes
de
usabilidade.
Em
paralelo
começa
a
fase
de
design
visual.
O
design
visual
consiste
em
criar
uma
linguagem
estética,
alinhada
com
os
objectivos
do
negócio,
que
irá
imbuir
de
vida
e
significado
os
vários
aspectos
da
interface
(Allen
&
Chudley,
2012).
Primeiro,
o
designer
deve
estabelecer
uma
direcção
visual
em
pareceria
com
a
equipa
de
produto
e
a
equipa
do
cliente,
através
de
um
20-‐second
gut
test
(Frost,
2016).
Este
tipo
de
teste
envolve
apresentar
cerca
de
30
interfaces
(de
sites
ou
aplicações),
cada
uma
durante
20
segundos,
ao
mesmo
tempo
que
todos
os
participantes
as
avaliam
individualmente
numa
escala
definida.
No
final
do
teste,
cruzam-‐se
as
classificações
e
reflete-‐se
sobre
a
razão
de
ser
dos
resultados,
despistando,
deste
modo,
os
valores
estéticos
da
equipa
do
cliente.
A
partir
dos
resultados
obtidos
no
teste
acima
descrito,
cria-‐se
um
documento
resumido
que
expressa
o
look
and
feel
do
futuro
sistema
de
design
de
interfaces.
Há
várias
formas
de
projectar
este
documento
(moodboards,
style
tiles
ou
element
collages),
mas
nele
têm
que
constar,
no
mínimo,
um
esquema
de
cores,
alguns
estilos
tipográficos
e
um
ou
6
outro
componente
da
interface
(op.
cit.).
Este
documento
é
então
sujeito
ao
feedback
do
cliente
e
iterado
caso
necessário.
A
fase
seguinte
consiste
em
desenhar
cada
um
dos
elementos
e
componentes
da
interface,
tanto
individualmente
como
em
relação
com
o
todo
(fig.3,
p.
xx).
Desta
fase
vai
resultar
um
guia
de
estilos
completo
e
coerente.
À
medida
que
o
design
visual
dos
componentes
vai
sendo
aprovado
pelo
cliente,
o
front-‐end
developer
vai
escrevendo
o
respectivo
código
de
CSS
e,
deste
modo,
o
protótipo
de
HTML
vai
começando
a
subir
de
fidelidade
(Kandy,
2016).
Daí
em
diante,
o
designer
e
o
front-‐end
developer
começam
a
colaborar
com
maior
proximidade;
acompanhando
o
protótipo
de
HTML
no
browser,
o
designer
vai
colaborando
com
o
developer
e
dando
sugestões
de
layout.
Agora
sim,
se
a
comunicação
oral
não
bastar,
pode
criar
mockups
de
alta
fidelidade
para
as
páginas
que
realmente
precisem.
Deste
modo,
o
protótipo
vai
sendo
iterado
até
se
tornar
no
produto
final
(Frost,
2016).
1.3.
Agile
e
Design
Até
ao
início
do
século
XXI
a
prática
comum
de
desenvolvimento
de
software
seguia
o
modelo
waterfall,
segundo
o
qual
as
várias
fases
do
processo
de
desenvolvimento
eram
concluídas
de
forma
linear
uma
após
outra,
desde
a
especificação
de
requisitos,
planeamento,
implementação
até
aos
testes
(Archer,
n.d.)
(fig.4,
p.
xx).
Opondo-‐se
a
este
modelo,
surgiu
a
Filosofia
Agile
e
outras
metodologias
de
desenvolvimento
de
software
como
o
scrum
e
o
kanban
(ibidem).
Com
o
objectivo
de
maximizar
a
eficiência,
o
Agile
defende
que
o
processo
de
desenvolvimento
deve
ser
iterativo
e
flexível
à
mudança
(fig.5,
p.
xx):
(i)
os
períodos
de
entrega
devem
ser
curtos
e
contínuos,
sendo
mais
importante
entregar
software
funcional
do
que
documentação;
(ii)
a
equipa
de
produto
deve
estar
disposta
a
receber
alterações
de
requisitos
mesmo
numa
fase
tardia
do
ciclo
de
desenvolvimento;
(iii)
dá-‐se
mais
enfase
à
colaboração
com
o
cliente
durante
o
processo
do
que
à
negociação
contratual;
(iv)
valoriza-‐
se
a
conversa
pessoal
e
directa
como
método
eficaz
de
passar
informação;
(v)
procura-‐se
evitar
despender
tempo
de
trabalho
em
aspectos
que
não
sejam
prioritários;
(vi)
e,
acima
de
tudo,
valorizam-‐se
equipas
auto-‐organizadas,
dado
que
as
pessoas
são
consideradas
mais
importantes
que
os
processos
e
as
ferramentas
(Beck
et
al.,
2001).
É
de
notar
que
o
design
centrado
no
utilizador
e
o
design
atómico
partilham
vários
princípios
com
o
Agile.
Todas
estas
filosofias
defendem
um
processo
iterativo.
Preferem
entregas
mais
frequentes
de
fases
com
menos
quantidades
de
trabalho
e
procuram
reduzir
a
quantidade
de
trabalho
desnecessário.
Promovem
o
envolvimento
do
cliente
e
dos
stackholders
na
totalidade
do
processo
de
design
e
de
desenvolvimento.
No
entanto,
continua
a
ser
prática
comum
tratar
o
UX
design,
o
UI
design,
o
front-‐end
e
o
back-‐end
como
etapas
isoladas
do
processo
de
design
e
desenvolvimento.
Opondo-‐se
à
falta
de
produtividade
resultante
da
separação
destas
áreas,
estão
ainda
a
ser
ensaiadas
7
metodologias
que
as
integrem
de
modo
mais
colaborativo
(Frost,
2016;
Cao,
2016;
Kandy,
2016;
Archer,
2016).
O
estágio
que
realizei
e
que
apresento
nos
capítulos
seguintes
constituiu
uma
oportunidade
de
aplicar
as
metodologias
de
UX
e
UI
Design
na
criação
de
uma
aplicação
web
numa
empresa
de
software
que
segue
metodologias
Agile.
8
Capítulo 2: Caracterização da Empresa
2.1. Premium Minds
A Premium Minds é uma empresa portuguesa que desenvolve software e que utiliza
metodologias Agile. Foi fundada em 2002 com quatro pessoas e, à data do presente
relatório, contava com mais de oitenta colaboradores. Tem como serviços principais o
desenvolvimento à medida de Aplicações Web, Aplicações para dispositivos móveis,
Soluções de Business Intelligence e Soluções de Data Science.
Recentemente, a Premium Minds recebeu vários prémios que reconhecem a
robustez financeira, a estratégia de inovação, a internacionalização, o crescimento do
volume de negócios, a gestão de pessoas e a cultura organizacional. Destes prémios
destacam-‐se o "PME Excelência'13", o "PME líder'14", o "PME Excelência'14", a "Excelência
no trabalho 2014", a presença na lista de "Melhores Empresas Para Trabalhar 2015" e,
ainda, o prémio "Empresa Feliz de 2016" (Premium Minds, 2016).
2.2. Clientes e Produtos
A Empresa tem como clientes, entre outros, a Simphar, a Empark, a Leya, a EDP, a PT, a
Vodafone, a Emel, a Galp e a Novabase. Dos vários produtos desenvolvidos pela Premium
Minds destaco dois que passo a apresentar: o software Winphar e a aplicação Telpark.
O Winphar é um sistema de gestão de informação para farmácias encomendado à
Premium Minds pela empresa Simphar. Este sistema, à data com mais de 15 anos,
apresentava cerca de 100 funcionalidades. O trabalho da Premium Minds consistiu em
actualizar e modernizar a tecnologia usada no Winphar, bem como transformá-‐lo numa
ferramenta única que passou a integrar funcionalidades inovadoras como a sugestão
inteligente de medicamentos, o portal de gestão e a gestão automática de stocks.
Actualmente, o Winphar é o segundo sistema integrado de gestão empresarial do género
mais usado em Portugal e é utilizado em mais de 400 farmácias e lojas de saúde.
O Telpark é uma aplicação de parquímetro pessoal encomendado à Premium pela
Empark. Esta empresa propôs à Premium Minds que desenvolvesse uma ferramenta que
facilitasse a fiscalização de lugares de estacionamento nas ruas. A este desafio, a Premium
respondeu criando uma aplicação que permite a quem estaciona pagar e gerir o
estacionamento nas zonas reguladas da via pública, através do seu smartphone. Com esta
aplicação, o utilizador pode fazer pagamentos de estacionamento, receber alertas de fim de
período e pagar avisos por falta de pagamento. Aquando da escrita deste estudo, a
aplicação Telpark contava com mais de 260 000 utilizadores activos, tendo sido eleita como
a melhor aplicação espanhola de 20154.
4
Segundo a Revista Expansión
9
2.3.
Colaboradores
A
Premium
Minds
organiza-‐se
em
equipas
(fig.6,
p.
xx),
de
entre
as
quais
se
destacam
(i)
a
equipa
de
gestão,
(ii)
o
Departamento
Administrativo
e
Financeiro
(DAF),
(iii)
os
Gestores
de
Produto
(Product
Managers),
(iv)
os
Agile
Coachs,
(v)
os
Engenheiros
de
Sistemas,
(vi)
os
Designers,
(vii)
os
Arquitectos
de
Software,
(viii)
os
Engenheiros
de
Software
(ou
Developers),
(ix)
os
Cientistas
de
Dados
(Data
Scientists)
e,
por
fim,
(x)
os
Engenheiros
de
Qualidade
(Quality
Engineers).
O
trabalho
destas
equipas
consiste
no
seguinte:
(i)
A
Equipa
de
Gestão
é
responsável
por
gerir
as
operações
globais
da
empresa,
assegurar
a
lucratividade,
promover
a
cultura
organizacional
e
garantir
a
autonomia
das
pessoas
e
das
equipas;
(ii)
O
DAF,
além
das
funções
administrativas
e
financeiras,
é
responsável
pelas
instalações,
compras,
eventos,
comunicação,
carros,
People
Operations
e
recrutamento.
(iii)
Os
Product
Managers
são
quem
medeia
a
relação
entre
o
cliente
e
a
equipa
do
produto.
É
esta
equipa
a
responsável
por
se
reunir
com
os
clientes,
por
recolher
os
requisitos
do
trabalho,
por
criar
uma
equipa
de
produto,
por
estabelecer
prioridades
e
distribuir
tarefas
e,
ainda,
por
controlar
prazos
e
orçamentos.
(iv)
Os
Agile
Coachs
são
responsáveis
por
agilizar
e
amadurecer
o
processo
da
equipa
de
produto.
Faz
parte
da
sua
função
remover
eventuais
bloqueios
nos
processos
de
trabalho,
ajudar
a
equipa
a
aumentar
a
velocidade
e
promover
a
comunicação
contínua.
Para
tal,
monitorizam
as
diferentes
fases
do
projecto
e
dinamizam
reuniões
de
acordo
com
as
metodologias
Agile.
(v)
Os
Engenheiros
de
Sistemas
são
responsáveis
pela
implementação
e
manutenção
de
hardware
como
servidores,
dispositivos
de
armazenamento,
firewalls,
switches
e
routers.
(vi)
Os
Designers
são
responsáveis
por
criar
as
interfaces
entre
o
software
e
o
utilizador.
Para
isso
têm
competências
em
Usabilidade,
Arquitectura
de
Informação,
Design
de
Interfaces
e
desenvolvimento
Front-‐End.
(vii)
Os
Arquitetos
de
Software
projetam
a
estrutura
do
software
de
modo
a
que
haja
coerência
entre
os
vários
componentes
e
espaço
para
novos
serviços.
São
responsáveis
por
definir
o
fluxo
de
funcionamento
do
software
bem
como
as
ferramentas
utilizadas
(linguagens,
frameworks,
bibliotecas).
(vii)
Os
Developers,
ou
Engenheiros
de
Software,
dão
corpo
à
estrutura
feita
pelos
arquitectos.
São
responsáveis
por
programar
e
garantir
a
manutenção
do
back-‐end
do
software.
Faz
parte
do
seu
trabalho
assegurar
que
o
código
que
escrevem
seja
facilmente
apreendido
por
outros
developers.
(ix)
Os
Data
Scientists
descobrem
padrões
significativos
em
vastas
quantidades
de
dados.
São
responsáveis
por
preparar
dados
em
bruto,
analisá-‐los
recorrendo
a
técnicas
estatísticas
e
assim
desvendar
novos
requisitos
que
acrescentam
vantagem
competitiva
ao
software.
10
(x)
Os
Quality
Engineers
controlam
a
qualidade
do
software.
São
responsáveis
por
realizar
testes
ao
código
desenvolvido
pelos
developers
e
sugerir
melhorias
junto
dos
Product
Managers.
Com
excepção
da
equipa
de
gestão
e
do
DAF,
os
restantes
colaboradores
da
Premium
organizam-‐se
em
equipas
simultaneamente
de
duas
formas:
em
equipas
de
produto,
constituídas
por
pessoas
de
diferentes
áreas,
como,
por
exemplo,
a
equipa
que
desenvolve
a
aplicação
Telpark,
e
em
equipas
que
partilham
a
mesma
área
de
competências.
Neste
grupo
integra-‐se,
por
exemplo,
a
equipa
de
Design.
2.4. Cultura Empresarial
A Premium Minds é uma empresa que se preocupa com o bem-‐estar dos seus
funcionários e que estimula o convívio e amizade entre os colaboradores, quer dentro da
empresa, quer fora (fig.7, p. xx). Para tal, inspira-‐se na cultura organizacional de empresas
multinacionais que sejam reconhecidas pelo seu bom ambiente de trabalho, como a Google
e a Spotify. Nesse sentido, a Premium promove, junto dos seus colaboradores, valores como
a honestidade, o respeito por todos, a responsabilidade pelos resultados e o brio técnico. A
comunicação oral e directa entre os diferentes colaboradores e equipas é também
enfatizada; para além das dinâmicas próprias das metodologias Agile (Planning, Daily,
Grooming, Review e Retrospective, entre outras) a Premium organiza vários convívios entre
os funcionários como a Reunião Mensal e o World Café.
A partilha de elogios é outro dos aspectos estimulados dentro da empresa. Circula
na empresa uma moeda virtual —o "Kudo"— que serve para elogiar, adquirir bens e
serviços e oferecer donativos. Mensalmente, cada colaborador recebe 28 kudos, que pode
usar de diferentes formas: uma das formas de gastar este valor é dar "x" kudos a um colega
que se destacou pelo seu desempenho. Estes elogios são depois publicitados no canal de
comunicação interno da empresa. Com o seu saldo, cada colaborador pode ainda adquirir
bens ou serviços, disponíveis num catálogo online, ou ainda oferecer donativos a
instituições externas à empresa.
A Premium procura também ter um ambiente informal no que se refere à relação
entre colegas e ao vestuário. Para além disso, procura-‐se que haja uma relação de igualdade
entre pessoas, independentemente do seu cargo ou equipa.
Outro aspecto que a empresa incorpora é a flexibilidade. O horário não é fixo, os
colaboradores podem trabalhar em casa quando lhes for mais conveniente e não há
contabilização dos dias de férias. No entanto, a correcta gestão desta flexibilidade é da
responsabilidade de cada colaborador.
Uma vez por mês acontece o "Dia Criativo", uma oportunidade para os
colaboradores desenvolverem trabalhos auto-‐propostos, individualmente ou em grupo.
Durante 24 horas todos os funcionários são livres para desenvolver novas ideias, sendo que
11
os
produtos
resultantes
são
muitas
vezes
usados
em
processos
internos
e
também
vendidos
a
clientes.
Todas
as
quartas-‐feiras
um
colaborador
ou
convidado
externo
faz
uma
apresentação
no
auditório
da
empresa
sobre
os
temas
mais
variados.
Para
além
disso,
a
empresa
realiza
com
frequência
eventos
de
lazer
fora
das
suas
instalações
como
jantares,
piqueniques
e
passeios.
A
Premium
Minds
é,
desta
forma,
uma
empresa
que
aposta
na
máxima
produtividade,
criatividade
e
satisfação
dos
seus
colaboradores,
através
das
metodologias
utilizadas,
da
criação
de
equipas
multidisciplinares
e
da
consolidação
de
uma
cultura
organizacional
empolgante
para
os
seus
colaboradores.
12
PARTE
II
-‐
Projecto
13
Capítulo 3: Pictty: uma Web App de Fotografia
O Pictty é uma aplicação web para fotógrafos e apreciadores de fotografia. Tal como outras
aplicações web como o Flickr, o Instagram, o Pinterest e o Behance, o Pictty é uma rede
social onde se podem apreciar várias imagens de qualidade e ver o perfil dos seus autores.
No entanto, distingue-‐se destas plataformas pela sua vertente de jogo, pela dinâmica de
votação e pelo potencial de ganhar dinheiro.
A aplicação Pictty funciona do seguinte modo:
Colocação de imagens em jogo (fig. 8, p. xx)
Sendo uma aplicação web, o utilizador acede ao Pictty através de um browser. Para começar
a "jogar", deve adicionar uma imagem ao Pictty e indicar a que categoria —viagem,
natureza, retrato, entre outras— essa imagem pertence. Seguidamente, deve adicionar
dinheiro à sua carteira virtual do Pictty e, depois, ao carregar com dinheiro5 a imagem
adicionada, esta entra numa dinâmica de jogo, que começa obrigatoriamente no nível 1 e
progride de nível em nível de modo linear. O que define se a imagem passa de nível é o
facto de ter sido escolhida em relação a outras imagens, suas concorrentes, que vão sendo
apresentadas em pares aos votadores do Pictty.
Na passagem de nível em nível a imagem vai aumentando exponencialmente de
valor. Após cada competição, ganha ou empatada, o utilizador pode decidir se quer que a
sua imagem continue a competir ou se pretende levantar a quantia ganha com a imagem.
Se optar por esta última opção, o utilizador terá que retirar a imagem do jogo. Mas, uma vez
que a imagem esteja fora de jogo, para voltar a entrar nele é necessário carregar dinheiro e
começar de novo no nível 1. No caso de perder uma competição, a imagem sai de jogo e o
utilizador perde o dinheiro que a imagem já valia. Inicialmente, e para introduzir o utilizador
à lógica do jogo, existe um momento de teste chamado playground no qual é possível ter a
experiência de competição sem carregar nem ganhar dinheiro.
Competições
Em cada competição estão envolvidas múltiplas imagens, uma do utilizador e várias outras
de utilizadores rivais. As imagens competem entre si em duelos e o resultado de cada um
destes dos duelos é decidido por votadores (fig.9, p. xx). Cada votador é escolhido
aleatoriamente pelo sistema, só pode votar num duelo por competição e não tem acesso a
informação sobre os duelos restantes. Uma competição termina quando os vários votadores
tiverem decido o resultado dos duelos, o que, dependendo do número de utilizadores do
Pictty, pode demorar segundos ou dias. Consoante os resultados dos duelos uma imagem
pode ganhar, empatar ou perder a competição6. Se uma imagem ganhar a competição,
5
O
modelo
exacto
das
quantias
de
dinheiro
envolvidas
no
jogo
é
confidencial
e
como
tal
não
foi
mencionado.
6
A
relação
exacta
entre
os
resultados
dos
duelos
e
os
resultados
de
competição
é
confidencial
e
como
tal
não
foi
mencionada.
14
passa
a
valer
mais
dinheiro
e
pode
competir
no
nível
acima
(fig.10,
p.
xx).
Se
uma
imagem
empatar
na
competição,
mantém
o
valor
e
terá
que
competir
no
mesmo
nível
novamente.
Se
uma
imagem
perder
a
competição,
perde
o
dinheiro
e
sai
de
jogo.
Votadores
Qualquer
utilizador
registado
no
Pictty
pode
participar
como
votador
de
duelos.
A
dinâmica
de
votação
é
atraente
pois
dá
ao
votador
um
papel
decisivo
nos
duelos
ao
mesmo
tempo
que
lhe
permite
apurar
o
seu
sentido
estético.
Em
cada
duelo,
duas
imagens
da
mesma
categoria
são
colocadas
lado
a
lado
e
o
votador
escolhe
aquela
que
tem
mais
qualidade
segundo
os
seus
próprios
valores
estéticos.
Cada
imagem
participa
em
múltiplos
duelos
da
mesma
competição,
e
precisa,
portanto,
de
ser
preferida
face
a
outras
por
vários
votadores
distintos.
Idealmente,
isto
fará
com
que
quanto
mais
alto
for
o
nível,
mais
alta
terá
que
ser
a
qualidade
da
imagem
que
lá
quiser
chegar.
Rede
social
O
Piccty
tem
também
a
dimensão
de
rede
social.
Existe
uma
Galeria
onde
é
possível
ver
imagens
que
atingiram
níveis
elevados.
Através
dessas
imagens
é
possível
chegar
à
página
de
perfil
dos
seus
autores,
onde
se
pode
consultar
o
seu
portfolio,
a
suas
conquistas
no
jogo,
e,
também,
as
suas
métricas
de
votador.
Deste
modo,
não
só
os
donos
das
fotografias
podem
ganhar
dinheiro,
como
os
votadores
podem
ganhar
reconhecimento
pela
comunidade.
No
histórico
das
suas
imagens
o
utilizador
pode
ver
as
suas
imagens
rivais,
aceder
à
página
de
perfil
dos
seus
autores
e
à
página
de
perfil
de
quem
votou
nos
seus
duelos.
Há
ainda
a
possibilidade
de
partilhar
votações,
resultados
de
competição
e
duelos
através
de
outras
redes
sociais
como
o
Facebook,
o
Twitter
e
Google
+.
3.1.
Relato
Geral
do
Projecto
3.1.1.
Briefing
e
Planeamento
Aquando
do
início
do
estágio
que
aqui
relato,
a
pessoa
responsável
pela
cultura
da
Premium
Minds
apresentou-‐me
a
um
dos
membros
da
equipa
de
gestão.
Nessa
primeira
reunião,
foi-‐
me
passado
um
briefing
que
recebi
com
entusiasmo:
durante
os
próximos
meses
eu
iria
trabalhar
para
uma
aplicação
web
inovadora,
chamada
Pictty,
cujo
cliente
era
o
próprio
colaborador
com
quem
me
estava
a
reunir.
Já
existiam,
à
data,
ideias
quanto
aos
fluxos
gerais
da
aplicação.
As
partes
mais
crucias
do
back-‐end
já
tinham
sido
feitas
por
um
dos
developers.
A
equipa
de
design
já
tinha
feito
um
logótipo
e
o
nome
da
aplicação
já
estava
decidido.
O
meu
contributo
seria
desenhar
uma
interface
usável
e
atractiva
para
o
Pictty,
tarefa
que
iria
concretizar
na
sala
da
equipa
de
design,
onde
poderia
receber
os
seus
conselhos
experientes.
15
Após
esta
reunião
introdutória,
foi-‐me
depois
apresentado
um
product
manager
que
passou
a
acompanhar
o
meu
trabalho
de
perto.
Este
colega,
que
neste
relatório
vou
chamar
de
product
manager
ou
PM,
pediu-‐me
que
fizesse
o
plano
do
trabalho
que
iria
desenvolver
durante
o
estágio.
Baseado
na
metodologia
UCD
planei
então
o
projecto
em
três
fases
principais,
prevendo
que
cada
uma
delas
iria
ser
sujeita
a
testes
de
usabilidade
com
utilizadores
reais
e
iterada
consoante
os
problemas
detectados
(fig.
11
,
p.
xx).
Essas
três
fases
constariam
do
seguinte:
1. Primeiramente
iria
produzir
um
protótipo
interactivo
de
baixa
fidelidade.
Iria
fazer
uma
análise
da
concorrência,
criar
personas
e
delinear
fluxos
de
utilizador.
Iria
definir
a
arquitectura
de
informação,
desenhar
os
wireframes
em
Balsamiq7
numa
abordagem
de
design
responsivo
e
criar
links
entre
as
várias
páginas
para
gerar
interactividade;
2. Na
segunda
fase
iria
produzir
um
protótipo
interactivo
de
alta
fidelidade.
Iria
criar
um
sistema
de
componentes
coerentes
no
Sketch8,
seguindo
a
metodologia
de
design
atómico.
Iria
juntar
esses
componentes
para
formar
páginas,
e
gerar
interactividade
criando
links
e
animações
entre
páginas
no
Flinto9;
3. Na
terceira
fase,
que
previ
ser
já
após
o
período
de
estágio,
iria
acompanhar
o
front-‐end
developer
no
protótipo
HTML.
Acompanhando
o
front-‐end
no
browser
iria
dar
sugestões
de
design.
Também
pretendia
realizar
testes
de
usabilidade
de
larga
escala
usando
o
Loop1110,
analisar
Heatmaps
usando
o
Hotjar11
e
acompanhar
o
tráfego
do
site
usando
o
Google
Analytics12.
Por
fim,
previa
colaborar
com
o
front-‐end
developer
no
sentido
de
solucionar
os
problemas
principais
que
surgissem
nestas
análises.
O
PM
passou
a
ser
uma
interface
entre
mim
e
o
cliente.
Através
dele,
soube
que
o
cliente
tinha
iterado
o
plano
que
desenvolvi.
Por
um
lado,
tinha
reduzido
para
cerca
de
metade
o
tempo
de
duração
da
primeira
fase.
Por
outro,
tinha
decidido
que
deviam
ser
feitos
wireframes
apenas
para
desktop.
Com
essas
alterações,
dei
inicio
ao
meu
trabalho
propriamente
dito.
3.1.2.
Benchmarking
e
Fluxos
de
Utilizador
A
fase
inicial
do
meu
trabalho
começou
por
uma
análise
da
concorrência
no
que
respeita
a
três
aspectos:
(i)
Plataformas
com
modelos
de
negócio
semelhantes;
(ii)
7
O
Balsamiq
é
um
software
de
criação
de
wireframes,
para
mais
informações
ver
https://balsamiq.com/
8
O
Sketch
é
um
software
de
design
de
interfaces,
para
mais
informações
ver
https://www.sketchapp.com/
9
O
Flinto
é
um
software
de
prototipagem
que
permite
importar
ficheiros
do
Sketch,
conceder-‐lhes
interactividade
e
animá-‐los.
Para
mais
informações
ver
https://www.flinto.com/
10
O
Loop11
é
uma
aplicação
web
de
testes
de
usabilidade
remotos.
Para
mais
informações
ver
http://www.loop11.com/
11
O
Hotjar
é
uma
aplicação
web
de
geração
de
Heatmaps
e
Visitor
Recordings,
ver
mais
em
https://www.hotjar.com/
12
O
Google
Analytics
é
uma
aplicação
web
de
rastreamento
que
permite
analisar
o
tráfego
de
um
site,
ver
mais
em
https://analytics.google.com/
16
Plataformas
que
usassem
imagens
de
modo
abundante;
(iii)
Plataformas
com
aspectos
pontuais
interessantes
que
pudessem
informar,
de
alguma
forma,
o
Pictty.
No
entanto,
o
PM
pediu-‐me
que
não
despendesse
tempo
a
fazer
um
documento
para
o
cliente
com
os
resultados
da
análise
de
concorrência.
O
PM
estava
a
ensinar-‐me
na
prática
um
dos
princípios
da
filosofia
Agile:
que
o
produto
em
si
é
mais
importante
do
que
a
documentação
(Beck
et
al.,
2001).
Prossegui,
então,
para
as
outras
tarefas
do
projecto;
no
entanto,
sempre
que
me
surgia
um
desafio
prático,
analisar
a
concorrência
continuou
a
ser
uma
ferramenta
que
utilizei
ao
longo
de
todas
as
fases
do
projecto.
Segundo
o
plano
inicial,
a
tarefa
seguinte
consistia
em
criar
personas.
Esta
tarefa
iria
demorar
um
tempo
considerável
pois
implicava
ter
acesso
a
dados
reais
sobre
os
futuros
utilizadores
e,
para
os
obter,
teria
de
usar
vários
métodos
com
os
quais
ainda
não
estava
familiarizado.
Por
outro
lado,
as
espectativas
do
cliente
eram
de
que
eu
lhe
mostrasse
wireframes
muito
em
breve.
Dadas
estas
razões,
infelizmente,
optei
por
saltar
esta
tarefa
e
começar
a
delinear
os
fluxos
de
utilizador.
Tendo
elaborado
esses
fluxos,
comecei
a
reflectir
sobre
eles
através
de
mindmaps13:
usando
um
quadro
branco,
post-‐its
e
canetas
de
diferentes
cores,
mapeei
os
fluxos
que
me
tinham
sido
transmitidos
pelo
cliente,
comecei
a
simplificá-‐los
e
ainda
a
descobrir
e
criar
fluxos
que
não
tinham
sido
pensados
antes
(fig.
12
,
p.
xx).
Embora
considere
esta
fase
de
estudo
muito
importante
e
valiosa
no
processo
de
design,
percebi
que,
para
o
cliente,
por
ser
uma
fase
invisível
era,
em
certa
medida,
vista
como
uma
“perda
de
tempo”,
aspecto
que
me
fez
sentir
alguma
pressão
em
avançar
para
a
etapa
visível
do
desenho
de
wireframes.
A
partir
dos
fluxos
de
utilizador,
fiz
ainda
um
exercício
de
arquitectura
de
informação
através
do
qual
cheguei
a
um
mapa
do
site14,
com
as
páginas
e
as
modals15
principais
(fig.
13,
p.
xx).
Tendo
feito
este
trabalho,
reuni-‐me
com
o
cliente
e
PM,
apresentei
o
mapa
do
site
e
as
ideias
que
tinha
quanto
às
várias
páginas,
modals
e
componentes
importantes.
Teria
que
desenhar
as
páginas
("homepage",
"my
votes",
"gallery",
"how
it
works",
"my
pictures"
e
"picture
page"),
as
modals
("sign
up",
"sign
in",
"add
pictures",
"deposit
funds",
"withdraw
money"
e
"settings"),
os
componentes
("navbar",
"footer"
e
"wallet")
e
ainda
outros
elementos
secundários.
Todos
estes
objectos
de
design
tinham
bastante
complexidade
pois
ou
se
comportavam
de
modo
diferente
consoante
o
estado
ou,
na
verdade,
não
eram
objectos
isolados
mas
sim
fluxos
complexos.
Com
este
material
entregue,
o
cliente
decidiu
a
ordem
de
prioridade
dos
objectos
a
serem
desenhados
em
wireframes.
O
PM
transpôs
todos
estes
objectos
organizados
por
ordem
de
prioridade
para
uma
coluna
do
Trello16
e,
sempre
que
eu
estivesse
a
trabalhar
num
desses
objectos
passava-‐o
da
coluna
"backlog"
para
a
coluna
"doing".
Quando
os
wireframes
de
determinado
objecto
estavam
concluídos
passava-‐os
para
a
coluna
"done"
13
Os
mindmaps
são
um
método
de
visualização
de
informação
no
espaço
14
Um
mapa
do
site
é
uma
representação
hierárquica
da
estrutura
de
um
site
15
Uma
modal
é
um
elemento
da
interface
com
aparência
de
janela
que
se
sobrepõe
à
janela
principal
16
O
Trello
é
uma
aplicação
web
de
gestão
de
projectos,
saber
mais
em
https://trello.com/
17
com
uns
screenshots
em
anexo.
Deste
modo,
não
só
o
cliente
e
PM
iam
acompanhado
o
trabalho,
como
o
documento
de
Trello
servia
de
suporte
de
apresentação
nas
reuniões.
3.1.3.
Wireframes
e
Walktroughs
No
plano
inicialmente
delineado,
os
wireframes
eram
vistos
apenas
como
uma
tarefa
pertencente
à
fase
do
protótipo
de
baixa
fidelidade.
No
entanto,
o
desenho
de
wireframes
foi,
por
si
só,
a
fase
mais
longa
de
todo
o
projecto.
Isto
deveu-‐se
não
só
ao
facto
de
existirem
muitas
páginas,
modals
e
componentes,
todos
eles
bastante
complexos,
mas
essencialmente
por
cada
um
destes
objectos
ter
sido
iterado
entre
3
a
6
vezes
com
base
nas
decisões
e
novos
requisitos
do
cliente.
O
desenho
de
wireframes
incluiu
também
exercícios
de
arquitectura
de
informação,
já
que
através
deles
os
diferentes
elementos
foram
distribuídos
por
páginas
e
agrupados
em
secções
distintas.
A
barra
de
navegação
foi
o
primeiro
componente
da
interface
a
ser
desenhado,
já
que
representa
a
arquitectura
de
informação
geral
da
aplicação
(fig.
14,
p.
xx).
Nas
modals,
por
exemplo,
a
informação
foi
dividida
por
várias
etapas,
afectando
também
os
fluxos
de
utilizador.
Tive
também
de
assumir,
na
fase
de
wireframes,
a
actividade
de
copywriting,
caso
contrário
não
tinha
forma
de
relacionar
o
significado
dos
conteúdos
com
o
layout;
a
alteração
do
copy
mudava
o
próprio
conceito
e
propósito
de
uma
funcionalidade
e,
deste
modo,
se
fosse
bem
feito,
o
copy
podia
ajudar
os
futuros
utilizadores,
o
cliente,
o
PM
e
mesmo
eu
a
compreenderem
melhor
um
determinado
modelo
conceptual.
No
entanto,
dado
que
novas
ideias
e
arquiteturas
de
informação
foram
marcando
cada
iteração
dos
wireframes,
foi
despendido
demasiado
tempo
em
alterações
de
copy.
Tendo
acabado
a
maior
parte
dos
wireframes,
e
por
sugestão
da
Head
of
Design
da
Premium,
fiz
e
apresentei
alguns
walktroughs
antes
de
avançar
para
o
protótipo
interactivo
(fig.
15,
p.
xx).
Os
primeiros
walktroughs
foram
apresentados
aos
membros
da
equipa
de
design
que
estavam
ou
viriam
a
estar
envolvidos
na
concretização
do
Pictty.
Tendo
seguido
as
sugestões
deles,
iterei
os
walktroughs
e
apresentei-‐os
de
novo,
estando
também
presentes
o
cliente,
o
PM
e
uma
markteer
digital.
Este
momento
do
projecto
foi
muito
enriquecedor,
pois
recebi
feedback
de
pessoas
de
disciplinas
díspares.
Os
walktroughs
foram
muito
importantes
porque
ligaram
no
tempo
instâncias
de
páginas,
modals
e
componentes
que
até
aí
tinham
sido
desenhados
separadamente.
Apesar
de
eu
ter
os
fluxos
de
utilizador
em
mente
ao
desenhar
os
wireframes,
percebi
que
o
cliente,
o
PM
e
os
meus
colegas
só
tiveram
uma
real
noção
dos
fluxos
quando
assistiram
aos
walkthroughs.
Após
estas
reuniões,
e
com
base
nas
decisões
do
cliente,
iterei
os
wireframes
no
sentido
de
contemplarem
os
novos
requisitos.
Ainda
que
faltassem
vários
dias
até
se
realizarem
os
testes
de
usabilidade,
percebi
que
estava
na
altura
de
convidar
pessoas
para
participarem
nesses
testes.
Conversei
com
o
cliente
acerca
da
importância
de
recrutar
utilizadores
finais,
pois
era
do
meu
conhecimento
que
os
vários
autores
e
massa
crítica
da
área
da
usabilidade
salientam
a
relevância
dos
18
testes
com
utilizadores
finais.
O
cliente
preferiu,
no
entanto,
testar
o
protótipo
com
colaboradores
da
Premium
que
tivessem
especial
jeito
para
o
empreendedorismo
ou
alguma
afinidade
com
a
fotografia.
Esta
decisão
prendia-‐se
essencialmente
com
a
necessidade
de
sigilo
acerca
da
aplicação
que
me
encontrava
a
desenvolver.
A
decisão
tomada
foi,
então,
convidar
os
colegas
da
Premium
indicados
pelo
cliente
a
participarem
num
teste
de
usabilidade.
Nesse
convite,
descrevi
brevemente
a
estrutura
dos
testes,
coloquei
um
link
para
um
tabela
no
Doodle17
onde
as
pessoas
escolheram,
dentro
de
algumas
datas
e
horários
predefinidos,
aqueles
em
que
estariam
disponíveis
para
realizar
o
teste
de
usabilidade
do
Pictty.
3.1.4.
Testes
de
Usabilidade
Chegou
então
a
altura
de
fazer
links
no
Balsamiq
entre
todas
as
instâncias
de
páginas
e
modals
para
criar
um
protótipo
interactivo.
No
entanto,
dada
a
quantidade
e
complexidade
de
todas
as
instâncias
previstas,
optei
por
criar
um
protótipo
em
papel.
Imprimi
e
cortei
todos
os
elementos
necessários
para
simular
uma
experiência
de
navegação
livre
pelo
Pictty.
Recebi
ainda
orientações
de
um
outro
funcionário,
um
developer
com
grande
experiência
em
usabilidade,
quanto
aos
passos
seguintes
de
preparação
e
realização
dos
testes,
que
passo
seguidamente
a
explanar:
(i)
Reservámos
uma
sala
para
realizar
os
testes
de
usabilidade
ao
protótipo
de
papel;
(ii)
Arrumámos
a
sala
de
modo
a
agilizar
e
operacionalizar
os
testes;
(iii)
Todos
os
elementos
de
papel
foram
agrupados
criteriosamente
numa
mesa,
invisível
para
o
utilizador,
de
modo
a
que
fosse
fácil
encontrar
um
determinado
elemento
durante
os
testes
e,
desse
modo,
simular
ao
utilizador
uma
experiência
próxima
da
experiência
tida
ao
computador;
(iv)
Outra
mesa
foi
tratada
como
o
local
de
interação
entre
utilizador
e
sistema
e,
nela,
foi
colocada
uma
webcam
num
ângulo
propício
para
captar
a
interface
de
papel
e
os
movimentos
das
mãos
do
utilizador.
A
forma
como
eu
tinha
aprendido
a
realizar
testes
de
usabilidade
a
protótipos
em
papel
requeria,
no
mínimo,
quatro
pessoas
presentes
durante
o
teste.
Seriam
elas
o
utilizador,
o
facilitador18,
o
“computador”19
e
o
observador20.
A
minha
ideia
era
ser
observador
em
parceria
com
o
cliente
e
convidar
dois
colegas
a
desempenharem
as
funções
restantes.
No
entanto,
como
só
foi
possível
ter
um
colega
a
ajudar-‐me
em
cada
teste,
e
devido
ao
facto
do
protótipo
de
papel
ser
bastante
complexo,
tive
que
ser
eu
o
“computador”.
Por
outro
lado,
o
cliente
não
pôde
estar
presente
durante
os
testes,
o
que
17
O
Doodle
é
uma
aplicação
web
de
agendamento
de
eventos,
ver
mais
em
http://doodle.com/
18
Num
teste
de
usabilidade
o
cargo
de
facilitador
consiste
em
sentar-‐se
ao
lado
do
utilizador,
conduzi-‐lo
ao
longo
do
teste
e
garantir
que
ele
"pensa
em
voz
alta".
19
O
cargo
de
"computador"
num
teste
de
usabilidade
com
protótipo
em
papel
consiste
em
reagir
à
interação
do
utilizador
colocando
à
sua
frente
os
recortes
de
papel
que
representarem
a
instância
da
interface
consequente.
20
O
cargo
de
observador
num
teste
de
usabilidade
consiste
em
escutar
o
que
o
utilizador
está
a
pensar,
ver
o
que
ele
está
a
fazer
e
anotar
o
que
for
confuso
ou
frustrante
para
eles.
19
tornou
os
resultados
dos
testes
pouco
accionáveis.
Colaboraram
comigo
nos
testes,
alternadamente,
o
PM
e
o
front-‐end
developer.
Cada
um
deles
ficou
com
ambas
as
tarefas
de
facilitador
e
observador.
Ao
todo
foram
realizados
seis
testes
de
usabilidade,
cada
um
com
um
participante
diferente.
Antes
de
realizar
o
teste,
cada
participante
teve
que
assinar
um
formulário
em
como
concordava
em
ser
filmado
durante
o
teste.
Durante
este,
em
vez
de
serem
delineadas
tarefas
específicas,
procurámos
que
o
utilizador
navegasse
livremente
pela
aplicação.
Por
vezes,
foi
também
necessário
conduzir
o
utilizador
de
modo
indirecto
a
explorar
um
determinado
aspecto
importante
que,
de
outro
modo,
não
teria
sido
testado.
Durante
os
testes,
vimos
os
utilizadores
a
interagirem
com
a
aplicação
de
formas
que
nunca
haviam
sido
contempladas
e
verificou-‐se
que
vários
fluxos
funcionavam
bem
mas
que
outros,
porém,
apresentavam
vários
obstáculos
ao
utilizador
(fig.
16,
p.
xx).
Após
os
testes,
a
minha
ideia
era
apresentar
ao
cliente
os
problemas
detectados
e
propostas
de
resolução
dos
mesmos
através
de
screenshots
anotados.
No
entanto,
como
eu
tinha
assumido
o
papel
de
"computador"
durante
os
testes,
não
me
foi
possível
estar
atento
a
alguns
aspectos
importantes
da
usabilidade
da
interface.
Por
isso,
despendi
ainda
bastante
tempo
a
ver
todas
as
gravações
dos
testes
e
a
registar
numa
folha
de
Excel
os
problemas
encontrados,
em
que
parte
da
aplicação
se
verificavam,
qual
nível
de
severidade
e
com
que
utilizador(es).
Fui
escrevendo
também
soluções
de
que
me
ia
lembrando
para
cada
um
dos
problemas.
Acontece
que,
após
um
dia
de
trabalho,
não
tendo
eu
concluído
a
análise
e
apresentação,
o
cliente
quis
reunir-‐se
comigo
e
com
o
PM.
Como
não
tive
tempo
para
fazer
uma
síntese
dos
problemas
e
sugestões
mais
importantes,
tive
que
apresentar
a
folha
de
Excel
ainda
por
concluir,
com
inúmeras
páginas
e
dados
por
tratar.
O
cliente,
com
urgência
em
avançar
para
a
fase
seguinte
do
projecto,
e
vendo
uma
lista
tão
extensa
de
problemas,
mostrou-‐se
relutante
em
aprovar
grande
parte
das
alterações
propostas.
No
entanto,
com
a
ajuda
do
PM,
o
cliente
aprovou
algumas
sugestões
importantes
quanto
ao
fluxo
de
votação,
à
comunicação
do
modelo
conceptual
do
jogo
e
ao
fluxo
relativo
ao
carregamento
e
levantamento
de
dinheiro.
Para
poupar
tempo
foi-‐me
pedido
que
passasse
imediatamente
à
fase
seguinte
do
projecto
e
fizesse
as
alterações
consequentes
dos
testes
de
usabilidade
realizados
directamente
na
fase
de
design
visual,
em
Sketch.
3.1.5.
Design
Visual
Pode
dizer-‐se
que,
até
este
momento
do
projecto,
eu
tinha
estado
a
trabalhar
em
UX
design;
daqui
em
diante
iria
focar-‐me
em
UI
design.
Tendo
as
fases
anteriores
demorado
mais
tempo
do
que
tinha
sido
planeado,
percebi
que
já
não
ia
haver
tempo
suficiente
durante
o
meu
estágio
para
criar
um
protótipo
interactivo
de
alta
fidelidade,
como
era
minha
intenção.
Tinha
tempo,
no
entanto,
para
criar
um
sistema
coerente
de
componentes
de
interface.
À
data,
o
front-‐end
developer
que
ia
ficar
responsável
pelo
Pictty
tinha
escrito,
no
Blog
da
Premium,
um
post
sobre
a
versatilidade
dos
web
components
(Regadas,
2016).
20
Pedi,
portanto,
permissão
ao
cliente
para
seguir
uma
abordagem
de
Atomic
Design,
fazendo
exactamente
o
oposto
do
que
Brad
Frost
sugere:
"Ask
forgiveness,
not
permission
to
do
your
best
work"
(Frost,
2013).
O
desenho
por
componentes
não
foi,
no
entanto,
aceite
pelo
cliente,
que
preferiu
que
fosse
seguida
a
metodologia
que
lhe
era
mais
familiar:
o
desenho
de
páginas
de
alta
fidelidade.
Não
sendo
a
abordagem
que
me
parecia
mais
adequada,
e
reconhecendo
a
minha
ainda
imaturidade
na
apresentação,
explicação
e
defesa
de
novos
processos
perante
um
cliente,
passei
então
ao
desenho
de
páginas,
ciente,
ainda
assim,
de
que,
como
refere
Stephen
Hay,
"we’re
not
designing
pages,
we’re
designing
systems
of
components"
(Hay,
2013).
Em
reunião
com
o
cliente,
tentei
perceber
que
tipo
de
ambiência
visual
era
desejada
para
a
aplicação.
Percebi
que
se
tratava
de
uma
estética
sóbria,
simples,
clean,
que
desse
ênfase
às
imagens
e
tivesse
alguns
apontamentos
concentrados
de
cor.
Com
essa
informação,
e
seguindo
a
sugestão
da
Head
of
Design,
concebi
um
moodboard21.
Após
um
dia
neste
trabalho,
o
cliente
e
PM
quiseram
que
eu
apresentasse
o
que
tinha
feito;
o
moodboard
não
estava,
ainda,
concluído,
mas
o
cliente
decidiu
que
este
passo
deveria
ser
abandonado
pois,
no
seu
entender,
a
ambiência
gráfica
do
projecto
só
iria
ser
possível
de
ser
apreendida
quando
os
elementos
fossem
vistos
no
seu
contexto
“final”.
Comecei
então
a
desenhar
no
Sketch
os
mockups
das
páginas
pela
ordem
de
prioridade
decidida
pelo
cliente.
Dos
wireframes
para
os
mockups,
apesar
das
funcionalidades
em
geral
se
terem
mantido,
os
diferentes
elementos
encontraram
outras
formas
de
organização
no
espaço.
Nesse
momento,
percebi
que
tinha
gasto
demasiado
tempo
em
detalhes
visuais
na
fase
de
wireframes.
Nos
mockups
fiz
as
alterações
autorizadas
pelo
cliente
consequentes
dos
testes
de
usabilidade
e,
sempre
que
me
reunia
com
o
cliente
para
apresentar
a
página
em
que
estava
a
trabalhar,
comunicava
sucintamente
os
problemas
que
tinham
surgido
no
teste
de
usabilidade
nessa
mesma
página.
Deste
modo,
o
cliente
acabou
por
aceitar
muitas
das
alterações
que
estavam
na
folha
de
Excel
com
os
resultados
dos
testes
de
usabilidade.
Mesmo
nesta
fase
de
desenho
de
páginas
de
alta
fidelidade,
continuaram
a
ser
pensados
e
desenhados
fluxos,
páginas
e
componentes
que
nunca
antes
tinham
sido
previstos.
Apesar
desta
abordagem
focada
em
desenhar
páginas
não
ter
sido
ideal
para
criar
um
sistema
coerente
de
componentes,
procurei
ir
criando
um
guia
de
estilos
à
medida
que
fui
desenhando
as
páginas
(fig.
17,
p.
xx).
Escolhi
as
quatro
cores
principais
e
os
vários
estilos
tipográficos
com
variação
de
tamanho,
cor
e
peso,
e
desenhei
os
múltiplos
estados
de
diversos
elementos
da
interface:
links
da
navbar,
links
para
redes
sociais,
vários
tipos
de
botões,
modals,
modals
miniatura,
dropdowns,
campos
de
input
normais
ou
com
validação,
checkboxes,
radiobuttons,
separadores,
botões
de
switch,
cartas,
menus
das
cartas,
painéis
e
collapses.
21
Um
moodboard
é
um
conjunto
de
elementos
que
apresenta,
de
modo
genérico
a
ambiência
gráfica
de
um
dado
projecto.
21
Quando
concluí
a
fase
de
mockups
poucos
dias
depois
terminou
o
estágio.
Deste
modo,
acabei
por
não
ter
o
tempo
necessário
para
passar
devidamente
todo
o
meu
trabalho
ao
meu
colega
front-‐end
developer
e
acompanhar
devidamente
o
protótipo
HTML.
Ainda
assim,
a
presença
do
front-‐end
developer
em
várias
reuniões
do
processo
de
design,
bem
como
a
sua
colaboração
no
teste
de
usabilidade,
foi
de
grande
importância
para
a
coesão
e
continuidade
do
projecto.
O
processo
descrito
acima
incluiu
ainda
alguns
aspectos
mais
complexos
no
que
toca
ao
modelo
conceptual
e
à
resolução
de
problemas
estruturais
do
Piccty
que,
pela
sua
complexidade
e
relevância,
passo
a
referir
mais
explicitamente
no
sub-‐capítulo
seguinte.
3.2.
Desafios
de
Design
3.2.1.
Votação
e
Gamification
O
briefing
do
cliente
para
a
home
page
da
aplicação
Pictty
concebia
esta
página
enquanto
o
lugar
de
votação
em
imagens.
Duas
imagens
iam
estar
lado
a
lado,
com
botões
de
voto
abaixo,
e
seria
possível
ler
informação
sobre
o
duelo
como
a
categoria
de
fotografia
e
o
nível
da
competição.
Ao
votar
na
imagem
de
que
mais
gostasse,
o
utilizador
iria
ler
uma
mensagem
de
agradecimento
do
sistema
e
teria
a
possibilidade
de
partilhar
os
resultados
do
duelo
através
das
redes
sociais.
O
utilizador
deveria
também
poder
denunciar
uma
imagem
caso
ela
violasse
direitos
de
autor.
Para
envolver
e
motivar
os
utilizadores
na
actividade
de
votação,
o
cliente
queria
ainda
uma
página
dedicada
a
apresentar
as
métricas
de
votador
e
o
histórico
das
imagens
votadas.
Ao
pensar
nos
fluxos
de
utilizador
fui
tendo
ideias
de
novos
requisitos:
(i)
deveria
haver
uma
frase
de
call
to
action
que
levasse
as
pessoas
a
votarem;
e
(ii)
teria
que
ser
possível
maximizar
as
imagens.
No
primeiro
wireframe
que
desenhei,
para
as
imagens
ganharem
força
visual,
o
botão
de
votação
e
links
de
denúncia
e
maximização
só
apareciam
em
mouse
over
em
cima
da
respectiva
imagem
(fig.
18,
p.
xx).
O
cliente
voltou
a
pedir-‐me
para
pôr
os
botões
sempre
presentes
por
baixo
das
imagens
mas,
ao
ver
essa
solução
desenhada,
percebeu
que
as
imagens
perdiam
muita
força
e
aceitou
a
ideia
anterior.
Pensando
que
a
homepage
devia
ter
um
incentivo
ao
registo
no
Pictty
coloquei
uma
pequena
frase
com
link
para
esse
efeito
(fig.
19,
p.
xx).
Em
conjunto
com
o
PM
projectei
duas
variantes
para
a
homepage:
uma
para
utilizadores
logados
e
outra
para
não
logados.
A
diferença
entre
estes
dois
cenários
seria
que
um
utilizador
não
logado
só
poderia
votar
em
competições
no
playground;
a
vontade
de
ver
as
imagens
que
estavam
a
competir
em
níveis
mais
elevados
tornar-‐se-‐ia,
deste
modo,
um
incentivo
ao
registo.
Outro
aspecto
também
22
contemplado
foi
o
momento
pós-‐votação
que,
para
além
dos
requisitos
iniciais,
teria
a
duração
de
segundos
e
teria
um
sinal
de
"certo"
que
apareceria
em
cima
da
imagem
votada.
O
cliente
tinha-‐me
pedido
que
retirasse
a
frase
de
"call
to
action"
da
página
de
votação
por
lhe
parecer
redundante.
Todavia,
no
teste
de
usabilidade,
ao
apresentar
a
página
de
votação
às
pessoas
que
realizaram
o
teste,
várias
vezes
foi
colocada
a
questão
"o
que
é
que
é
suposto
eu
fazer
aqui?",
denotando
que
faltava
uma
indicação
acerca
do
que
fazer.
Na
fase
de
mockups
o
cliente
voltou
a
pedir-‐me
que
colocasse
os
botões
de
votação
por
baixo
das
imagens,
argumentando
que
o
mouse
over
não
seria
usável
em
ecrãs
touch
(fig.
20,
p.
xx).
As
decisões
seguintes
disseram
respeito
ao
tamanho
das
duas
imagens
em
duelo.
A
minha
ideia
desde
o
início
era
que
as
imagens
deveriam
ocupar
exactamente
a
mesma
área,
independentemente
da
proporção
de
tela
dessa
imagem.
Para
além
disso,
as
imagens
iriam
estar
centradas
verticalmente
e,
tanto
a
medida
de
cada
margem
lateral
como
do
espaço
entre
as
duas
imagens,
deveria
ser
igual.
O
cliente
pediu
para
tentar
outras
alternativas,
mas
acabou
por
adoptar
esta
solução,
especificando
que
a
medida
das
margens
seria
2%
da
largura
do
ecrã.
O
momento
de
pós-‐votação
foi
simplificado
ainda
mais:
os
botões
de
votação
desaparecem,
um
"certo"
aparece
sobre
a
imagem
votada
e
uma
"cruz"
sobre
a
excluída
e
os
botões
de
social
share
aparecem
centrados
na
parte
de
baixo
do
ecrã.
Quanto
às
métricas
e
histórico
de
votador,
a
minha
proposta
de
wireframes
foi
deixarem
de
estar
numa
página
própria
e
passarem
a
ser
uma
secção
da
página
de
votação
abaixo
da
secção
de
duelo
(fig.
18,
p.
xx).
Pensei
também
que
as
imagens
no
histórico
podiam
vir
acompanhadas
pelo
seu
nível
e
valor
no
momento
do
duelo
em
causa.
Porém,
o
cliente
não
gostou
da
solução
e
pediu-‐me
que
criasse
uma
página
própria
para
o
efeito.
Pensei
que,
em
vez
de
um
sistema
de
métricas
aborrecido,
podia
usar
técnicas
de
gamification22
mais
sofisticadas
para
motivar
os
utilizadores
a
envolverem-‐se
na
actividade
de
votação.
Inspirado
em
plataformas
como
o
Codecademy,
o
Treehouse
e
o
Swarm,
criei
um
sistema
de
badges
de
votador
(fig.
21,
p.
xx).
Em
colaboração
com
o
cliente
e
o
PM
esbocei
três
espécies
de
badges
diferentes:
por
quantidade
de
votos,
por
frequência
de
votação
e
por
perspicácia
de
voto
(a
capacidade
de
votar
na
imagem
que
ganha
o
duelo).
Deste
modo,
tendo
o
utilizador
acabado
de
votar
numa
imagem
na
homepage,
caso
fossem
reunidas
as
condições
necessárias,
apareceria
uma
modal
de
aquisição
de
determinado
badge
(fig.
22,
p.
xx).
O
acesso
à
informação
de
votador
estava
pensado
para
acontecer
através
de
um
link
da
navbar
que
abriria
uma
página
específica
para
o
efeito.
No
entanto,
estas
informações
deixaram
de
ter
uma
página
própria
e
passaram
a
ser
um
separador
da
página
"my
pictty"
(fig.
23,
p.
xx).
Os
badges
e
o
histórico
de
votação
passaram
a
ser
secções
separadas
na
vertical.
Para
cada
badge
foi
escolhido
um
título,
descrição
e
idealizado
um
sistema
de
22
A
gamification
é
o
uso
de
técnicas
de
design
de
jogos
para
influenciar
o
comportamento
dos
utilizadores
na
interação
com
o
sistema.
Tira
partido
de
mecanismos
mentais
como
a
competição,
o
cumprimento,
a
recompensa,
a
auto-‐expressão,
a
vaidade,
o
altruísmo
e
o
reconhecimento.
23
estimativa
das
condições
em
falta
para
o
adquirir.
No
teste
de
usabilidade
os
utilizadores
tiveram
dificuldade
em
perceber
o
que
era
o
histórico
de
votação
devido
ao
layout
das
imagens
e
ao
título
utilizado.
A
alteração
feita
foi
colocar
as
imagens
num
layout
semelhante
à
galeria
e
mudar
o
título
para
"pictures
I
have
voted
for".
3.2.2.
Jogo
de
Imagens
e
Cartas
Os
requisitos
que
o
cliente
tinha
especificado
para
a
página
"my
pictures"
passavam
por
imagens
agrupadas
por
vários
separadores
consoante
o
seu
estado
no
jogo.
Em
cada
secção
seria
possível
selecionar
imagens
e
despoletar
nelas
acções
específicas
desse
estado.
Teria
também
que
estar
presente
na
página
um
botão
de
"add
pictures"
e
o
componente
"wallet".
Quando
uma
imagem
fosse
clicada,
abriria
a
sua
"picture
page".
Nessa
página
os
botões
para
dispoletar
acções
continuariam
presentes,
mas
a
imagem
apareceria
em
maior
escala
(num
padrão
de
carrousel)
e
abaixo
dela
estaria
um
histórico
da
actividade
da
imagem
no
Pictty.
Ao
delinear
os
fluxos
de
utilizador
e
desenhar
os
primeiros
wireframes
pensei
que
seria
positivo
que
todas
as
secções
de
imagens
e
respectivos
botões
estivessem
sempre
visíveis
na
mesma
página
(fig.
24,
p.
xx).
Uma
funcionalidade
que
também
achei
importante
foi
o
drag
and
drop
directo
de
imagens.
Para
além
disto,
desenhei
modals
de
resultado
de
competição,
que
despoletavam
mal
uma
competição
tivesse
terminado.
Experimentei
ainda
uma
solução
de
layout
diferente
para
a
página
"my
pictures"
que
o
cliente
pareceu
preferir:
criei
uma
barra
lateral
à
esquerda
com
a
"wallet"
e
um
sistema
de
separadores
para
as
várias
secções
de
imagens
(fig.
25,
p.
xx).
Fui
também
fazendo
um
exercício
de
arquitectura
de
informação
ao
reduzir
quatro
secções
para
apenas
duas.
Com
essa
condensação,
a
complexidade
que
residia
em
existirem
várias
secções
não
deixou
de
existir,
mas
foi
transferida
para
outro
lugar
e,
desse
modo,
tornou
o
modelo
conceptual
do
sistema
mais
simples
para
o
utilizador
(Norman,
2011).
A
componente
do
Piccty
que
cresceu
em
complexidade
foi
o
novo
sistema
de
cartas;
baseado
em
plataformas
como
o
Behance,
o
Trello,
e
em
jogos
como
o
Magic
the
Gathering,
criei
um
sistema
de
11
estados
de
cartas
com
diferentes
textos,
cores
e
botões,
quatro
tipos
de
notificações,
cinco
modals
de
confirmação
de
acção
e
três
tipos
de
menus.
A
página
"my
pictures"
e
a
página
"my
votes"
passaram
a
ser
separadores
de
uma
mesma
página
chamada
"my
pictty".
Continuando
em
iterações
à
página
"my
pictures",
a
solução
da
barra
lateral
e
o
sistema
de
secções
foi
erradicado
(fig.
26,
p.
xx).
As
imagens,
sobre
a
forma
de
cartas,
passaram
a
estar
todas
presentes
num
mesmo
lugar
e,
por
sugestão
do
front-‐end
developer,
as
cartas
em
competição
passaram
a
apresentar
miniaturas
clicáveis
das
suas
imagens
rivais.
Nos
testes
de
usabilidade
verificou-‐se
que
não
era
explícito
que
a
página
“my
pictty”
envolvia
dois
separadores.
Por
isso,
na
fase
de
design
visual,
os
separadores
foram
desenhados
de
modo
mais
evidente
(fig.
27,
p.
xx).
Por
outro
lado,
alguns
utilizadores
não
perceberam
que
o
símbolo
"..."
era
um
botão
de
menu.
Em
consequência
dessa
constatação,
foi
desenhado
um
símbolo
de
menu
mainstream
e
colocado
num
lugar
mais
24
habitual.
O
botão
de
"add
pictures"
começou
por
ocupar
o
espaço
de
uma
carta,
mas
acabou
por
ser
colocado
na
parte
superior
da
secção
por
desse
modo
ocupar
menos
espaço.
A
"picture
page"
de
uma
imagem
começou
a
ser
desenhada
mais
minuciosamente
apenas
nesta
fase
do
projecto
(fig.
28,
p.
xx).
Para
além
dos
requisitos
iniciais
foi
necessário
desenhar
um
painel
—uma
espécie
de
carta
ampliada—
e
que
tem
tantos
estados
como
as
cartas.
Foram
também
desenhadas
modals
de
confirmação
de
acção
e
um
componente
que
permite
reeditar
a
categoria
e
grau
de
violência23
da
imagem.
O
texto
em
cima
das
imagens
que
havia
sido
idealizado
na
fase
de
wireframes
acabou
por
se
revelar
pouco
legível
e
descaracterizar
as
imagens
nos
mockups.
Por
essa
e
por
outras
razões,
surgiu
a
necessidade
de
organizar
os
elementos
constituintes
das
cartas
de
outras
formas
(fig.
27,
p.
xx).
De
grande
interesse
foi
constatar,
que
nesse
processo,
o
sistema
de
cartas
foi
imensamente
simplificado,
deixando
de
ser
necessárias
notificações
e
passando
a
existir
apenas
4
tipos
de
estados
principais.
3.2.3.
Upload
e
Metadados
Quando
um
utilizador
clica
no
botão
"add
pictures"
aparece
uma
modal.
O
intuito
inicial
desta
modal
era
permitir
ao
utilizador
confirmar
os
direitos
de
autor
sobre
uma
imagem
importada
do
desktop,
atribuir-‐lhe
uma
categoria
de
competição,
declarar
se
expunha
ou
não
conteúdos
violentos
e,
finalmente,
adicioná-‐la
à
página
"my
pictures"
do
Pictty.
Apesar
da
ideia
inicial
só
permitir
adicionar
uma
imagem
de
cada
vez
que
a
modal
fosse
aberta,
o
cliente
tinha
também
a
vontade
de
possibilitar
ao
utilizador
a
importação
de
grandes
quantidades
de
imagens
através
do
Flickr
e
do
Instagram.
Defini
prontamente
que
a
modal
para
adicionar
imagens
deveria
ser
dividida
em
dois
momentos:
(i)o
primeiro
momento
viabilizaria
a
importação
de
imagens
para
dentro
da
modal
(fig.
29,
p.
xx);
(ii)
O
segundo
momento
possibilitaria
associar
metadados
a
essas
imagens
e,
finalmente,
(iii)
adicioná-‐las
à
página
"my
pictures"
(fig.
30
,
p.
xx).
(i)
O
primeiro
momento
da
modal
foi
inspirado
pelo
file
manager
do
Mailchimp24:
o
utilizador
poderia
usar
um
dropdown
para
escolher
o
modo
de
importação
das
imagens
(Desktop
ou
Social)
e,
consoante
a
opção
escolhida,
seria
disposta
informação
e
um
botão
para
concretizar
essa
acção
específica.
(ii)
No
segundo
momento
as
imagens
importadas
seriam
dispostas
num
layout
de
thumbnails,
mas
continuaria
a
ser
possível
trazer
mais
imagens
para
a
modal
usando
a
barra
superior
(fig.
31
,
p.
xx),
e
estaria
presente
um
curto
texto
que
incitaria
o
utilizador
a
selecionar
mais
imagens.
Quando
uma
ou
mais
imagens
fossem
selecionadas,
estas
ficariam
marcadas
a
azul
e
surgiria
uma
secção
inferior
na
modal
com
a
possibilidade
de
atribuir
23
Por
“grau
de
violência”
entenda-‐se
a
capacidade
potencial
que
a
imagem
apresenta
de
chocar
o
utilizador,
quer
por
mostrar
violência
explícita,
quer
por
mostrar
conteúdo
potencialmente
obsceno
ou
impróprio
para
ser
visualizado
pelo
público
em
geral.
24
O
Mailchimp
é
um
software
de
marketing
via
email.
Saber
mais
em
http://mailchimp.com
25
metadados.
Nessa
secção
estaria
presente
o
número
de
imagens
selecionadas,
um
dropdown
para
escolha
de
categoria,
um
botão
de
switch
para
declarar
conteúdos
violentos,
uma
checkbox
para
confirmar
os
direitos
de
autor
e
um
botão
para
adicionar
as
imagens
selecionadas.
Para
o
segundo
momento
da
modal
foram
previstos
diferentes
layouts
consoante
o
número
de
imagens
presentes
na
modal;
quanto
mais
imagens,
mais
colunas
de
thumbnails
e,
consequentemente,
mais
pequenas
as
imagens
apresentadas.
(iii)
Foi
também
necessário
conceber
o
que
aconteceria
no
momento
em
que
todos
os
dados
sobre
uma
imagem
tivessem
sido
preenchidos
e
fosse
clicado
o
botão
"add
pictures”:
a
imagem
seria
adicionada
à
página
"my
pictures"
mas
a
modal
não
fecharia,
de
modo
a
dar
a
possibilidade
ao
utilizador
de
continuar
a
adicionar
imagens.
Nos
testes
de
usabilidade
foram
detectados
problemas
no
fluxo
geral
da
modal.
No
segundo
momento
desta,
ao
serem
seleccionadas
imagens,
os
utilizadores
tinham
a
espectativa
de
que
estas
fossem
adicionadas
de
imediato
à
sua
página
"my
pictures".
Isto
fez
com
que,
na
iteração
seguinte,
a
secção
de
rodapé
passasse
a
estar
presente
desde
o
início
do
segundo
momento
da
modal,
para
se
perceber
que
selecionar
a
imagem
era
apenas
um
passo
no
fluxo
de
lhe
adicionar
metadados.
Outro
aspecto
que
deixou
os
utilizadores
confusos
foi
o
facto
de
existir
uma
barra
superior
com
a
hipótese
de
trazer
mais
imagens
para
a
modal
(fig.
31
,
p.
xx).
Por
conseguinte,
na
fase
de
mockups,
foi
retirada
a
barra
superior
e
as
suas
funcionalidades.
Na
fase
de
mockups,
a
solução
de
design
do
primeiro
momento
deixou
de
ter
um
dropdown
e
passou
a
dispor
as
várias
opções
divididas
entre
2
secções,
respeitantes
à
importação
do
desktop
(drag
and
drop
e
janela
de
browse)
ou
via
redes
socias
(Flickr,
Instagram
e
Picasa)
(fig.
32
,
p.
xx).
Foi
apenas
numa
fase
tardia
do
projecto
que
se
contemplaram
todos
os
pormenores
do
fluxo
do
segundo
momento
do
modal,
então
entitulado
"Complete
Picture
Information"
(fig.
33
,
p.
xx):
se
o
utilizador
clicasse
no
botão
de
"add
pictures"
sem
ter
imagens
selecionadas
surgiria
um
aviso
para
selecionar
imagens
primeiro;
se,
depois
de
selecionar
alguma
imagem,
o
utilizador
clicasse
no
botão
"add
pictures",
surgiria
o
aviso
para
confirmar
os
direitos
de
autor
sobre
as
imagens;
por
fim,
após
as
informações
sobre
uma
imagem
serem
todas
preenchidas,
ao
clicar
no
botão
"add
pictures",
esse
botão
daria
lugar
a
um
loader
que
estaria
presente
até
o
thumbnail
da
imagem
desaparecer
da
modal
e
uma
carta
com
a
dita
fotografia
ser
adicionada
à
página
"my
pictures".
3.2.4.
Wallet
e
Depósito
de
Fundos
No
briefing
que
me
foi
dado
inicialmente
era
referido
um
componente
chamado
"wallet"
com
várias
informações
e
funcionalidades
financeiras.
Estas
informações
deveriam
ser
apresentadas
em
cada
um
deste
quatro
campos:
"available",
"ready
to
collect",
"in
voting"
e
"total".
As
funcionalidades
financeiras
seriam
despoletadas
por
botões
intitulados
"deposit
funds",
"withdraw
money"
e
"collect
selected".
O
campo
"available"
indicaria
a
quantidade
de
dinheiro
acabado
de
adicionar
à
"wallet"
ou
dinheiro
recolhido
de
uma
imagem
em
jogo.
26
O
campo
"ready
to
collect"
mencionaria
a
quantidade
de
dinheiro
que
estava
“bloqueado”
em
imagens
em
jogo
que
não
estivessem
a
competir.
O
campo
"in
voting"
referiria
a
quantidade
de
dinheiro
bloqueado
em
imagens
que
estavam
em
competição.
O
campo
"total"
seria
a
soma
dos
três
campos
descritos
anteriormente.
Para
todos
estes
fluxos
relacionados
com
dinheiro
baseei-‐me
em
plataformas
como
o
Freelancer.com.
Inicialmente,
a
wallet
foi
desenhada
numa
secção
à
direita
enquanto
parte
integrante
da
página
"my
pictures"
(fig.
34
,
p.
xx).
Propus
ao
cliente
que
os
campos
"
ready
to
collect
"
e
"in
voting"
se
tornassem
num
só,
chamado
"in
photos".
O
botão
"
collect
selected
"
requerido
pelo
cliente
servia
para
passar
o
dinheiro
das
imagens
selecionadas
para
o
campo
"available"
e,
com
isso,
as
imagens
sairiam
de
jogo.
Sugeri
que
este
botão
saísse
da
wallet
e
passasse
a
estar
nas
secções
de
imagens,
dado
que
seria
uma
vantagem
financeira
para
o
Pictty.
Mais
tarde,
quando
deixou
de
haver
a
possibilidade
de
seleção
múltipla
de
imagens,
esta
funcionalidade
passou
a
estar
presente
no
menu
de
cada
carta
como
o
item
"collect
money".
O
cliente
aceitou
ambas
as
sugestões.
A
localização
da
"wallet"
foi
mudando
de
sítio
ao
longo
das
várias
iterações;
chegou
a
estar
numa
barra
lateral
à
esquerda
(fig.
35
,
p.
xx),
mas
acabou
por
se
estabelecer
enquanto
um
elemento
da
navbar
que
abre
em
mouseover
(fig.
36
,
p.
xx).
Deste
modo,
passou
a
estar
disponível
em
todas
as
páginas
da
aplicação.
No
teste
de
usabilidade
verificaram-‐se
problemas
de
usabilidade
com
alguma
gravidade
na
"wallet"
e
nos
fluxos
de
dinheiro.
Ao
clicar
em
"withdraw
money"
o
utilizador
tinha
a
espectativa
de
poder
retirar
do
Pictty
todo
o
dinheiro
que
estivesse
na
"wallet".
Mas,
segundo
o
modelo
de
negócio
do
Pictty,
só
se
pode
retirar
dinheiro
do
campo
"available".
Os
utilizadores
não
perceberam
que
tinham
de
"collect
money"
individualmente
de
cada
carta
em
jogo
para
poderem,
depois,
retirá-‐lo
do
Pictty.
Este
problema
foi
resolvido
criando
uma
tooltip25
à
frente
do
campo
"in
photos"
a
esclarecer
que
para
tornar
esse
dinheiro
"available"
era
necessário
retirar
manualmente
do
jogo
cada
carta
(fig.
37
,
p.
xx).
Durante
os
testes,
vários
utilizadores
andaram
à
procura
de
uma
página
onde
pudessem
consultar
todos
os
movimentos
financeiros.
Para
ir
ao
encontro
dessa
necessidade,
fiz
uma
proposta
de
"financial
history",
um
local
onde
constariam
todo
o
tipo
de
eventos
que
alterassem
o
valor
total
da
"wallet"
(desde
depósitos,
vitórias
e
derrotas
de
cartas
e
retiradas
de
dinheiro
do
Pictty),
mas
esta
proposta
não
foi
aceite.
A
modal
"withdraw
money"
tinha
sido
colocada
pelo
cliente
e
PM
como
um
dos
últimos
elementos
do
backlog.
O
tempo
que
seria
dedicado
a
esta
modal
acabou
por
ser
usado
em
novos
elementos
que
foram
surgindo.
A
modal
de
"deposit
funds",
pelo
contrário,
foi
pensada
e
desenhada.
O
cliente
tinha
dado
o
requisito
do
Pictty
só
aceitar
depósitos
através
de
cartões
de
crédito.
Com
essa
informação,
comecei
por
dividir
o
fluxo
da
modal
em
dois
momentos:
a
"quantia
de
depósito"
e
os
"detalhes
do
cartão
de
crédito"
(fig.
38,
p.
xx).
Posteriormente
estes
dois
25
Uma
tooltip
é
uma
instrução
ou
indicação,
normalmente
apresentada
de
forma
discreta,
sobre
como
proceder
num
determinado
momento
ou
local.
27
momentos
fundiram-‐se
num
só,
sendo
que
os
“detalhes
do
cartão
de
crédito"
ficaram
em
cima
e
a
"quantia
de
depósito"
em
baixo
(fig.
39,
p.
xx).
Foi
contemplado,
também,
um
momento
de
"erro
na
confirmação
dos
dados"
e
um
momento
de
"depósito
bem
sucedido".
No
teste
de
usabilidade
surgiu
também
a
ideia
da
quantia
a
depositar
ser
selecionada
através
de
um
dropdown
de
escolha
condicionada
(2€,
5€,
10€,
etc.).
Uma
questão
que
se
colocou
na
fase
de
mockups
foi
como
comunicar
a
taxa
de
depósito
no
modal
de
"deposit
funds".
A
solução
encontrada
consistiu
em
colocar
abaixo
da
quantia
de
depósito
o
custo
da
taxa
de
depósito
(fig.
40,
p.
xx).
Adicionalmente,
foi
criada
uma
tooltip
esclarecedora
para
quem
não
soubesse
o
que
era
a
taxa
de
depósito.
3.2.5.
Comunidade
e
Social
Sharing
Outro
desafio
interessante
do
projecto
foi
conceber
a
dimensão
"social"
do
Pictty.
Por
um
lado,
seria
necessário
tirar
partido
de
várias
redes
sociais
para
dar
visibilidade
ao
Pictty,
aumentar-‐lhe
o
tráfego
e
até
alimentá-‐lo
de
conteúdos.
Por
outro,
seria
importante
tornar
o
próprio
Pictty
uma
rede
social,
no
sentido
de
criar
um
ambiente
de
comunidade
que
fomentasse
o
envolvimento
no
jogo.
Para
dar
mais
visibilidade
ao
Pictty
foi
usada
a
dinâmica
de
"social
sharing".
Informações
como
resultados
de
duelo,
resultados
de
competição
ou
aquisição
de
"badges
de
votador",
passaram
a
poder
ser
partilhadas
via
Facebook,
Twiter,
Google
+
e
via
Email
(fig.
41,
p.
xx).
Para
cada
um
destes
casos
foram
simulados
os
conteúdos
que
seriam
partilhados.
Para
aumentar
a
notoriedade
foram
também
colocados
no
footer
botões
de
"Like",
"Tweet"
e
"G+1"
tal
como
botões
de
"Follow
Us"
(fig.
42,
p.
xx),
e
foi
utilizado
o
sistema
de
"Social
Login"
para
agilizar
o
processo
de
registo
no
Pictty
(fig.
43,
p.
xx).
Para
além
de
tudo
isto,
foi
idealizado
a
funcionalidade
de
importar
para
o
Pictty
fotografias
do
Flickr,
Instagram
e
Picasa
(fig.
44,
p.
xx).
Para
tornar
o
próprio
Pictty
uma
rede
social
seria
necessário
conectar
os
vários
utilizadores
através
de
páginas
e
conteúdos
públicos.
A
página
Gallery,
segundo
as
directrizes
iniciais,
tinha
o
objectivo
de
dar
a
conhecer
a
quaisquer
utilizadores
todas
as
fotos
em
jogo
ordenadas
pelo
dinheiro
que
valiam.
No
entanto,
considerei
que
a
"Gallery"
tinha
muito
mais
potencial
se
cada
imagem
tivesse
um
link
para
a
"página
de
perfil"
do
seu
autor
e
que
essa
mesma
imagem
mesma
fosse
um
link
para
a
sua
"picture
page"
(fig.
45,
p.
xx).
Isto
significava
que
a
página
"my
pictty"
e
a
"picture
page"
deixariam
de
ser
privadas
e
passariam
a
ser
públicas.
Assim,
a
página
"my
pictty"
passou
a
ser
a
página
de
perfil
de
outros
utilizadores
quando
vista
por
alguém
que
não
fosse
o
“dono”
dela.
Nesta
página
foi
idealizado
um
novo
elemento
crucial:
a
barra
de
perfil
(fig.
46,
p.
xx).
Nesta
barra
estariam
a
fotografia
de
perfil,
o
nome
do
utilizador,
umas
métricas
que
aferem
o
envolvimento
do
utilizador
no
Pictty
e
dois
separadores
que
abrem
as
secções
abaixo.
Tendo
esta
página
pública
de
utilizador
em
mente,
a
página
"my
pictures"
—que
se
passou
a
chamar
"portfolio"—
e
a
página
"my
votes"
passaram
a
ser
separadores
da
barra
de
perfil.
A
possibilidade
de
ver
o
histórico
de
actividade
de
uma
imagem
na
sua
"picture
page",
quer
a
28
imagem
fosse
do
utilizador
ou
de
outro
participante,
permitiria
o
acesso
ao
perfil
dos
votadores
de
um
determinado
duelo
ou
mesmo
à
"picture
page"
de
uma
imagem
rival
(fig.
47,
p.
xx).
Deste
modo
seria
possível
explorar
o
Pictty
de
um
modo
bastante
mais
aberto,
o
que,
no
meu
entender,
iria
aumentar
a
credibilidade
na
plataforma
e
fomentar
o
envolvimento
no
jogo.
O
cliente
aceitou
algumas
destas
propostas,
mas
outras
foram
postas
de
lado
por
não
irem
de
encontro
aos
interesses
do
negócio.
A
“Gallery”,
em
vez
de
ter
informação
sobre
o
valor
actual
das
imagens,
passou
a
ter
o
valor
mais
alto
que
as
imagens
atingiram.
Ficou
por
decidir
se
as
imagens
da
“Gallery”
deveriam
ter
ou
não
links
para
a
suas
"páginas
de
pormenor"
e
para
as
"páginas
de
perfil"
dos
seus
autores.
No
entanto,
decidiu-‐se
que,
ao
clicar
numa
imagem,
ela
simplesmente
apareceria
em
fullscreen.
A
barra
de
perfil
do
"my
pictty"
foi
também
aceite,
mas
a
informação
que
consta
no
separador
"my
pictures"
é
diferente
caso
seja
o
próprio
dono
ou
outro
utilizador.
Já
no
separador
"my
votes",
o
histórico
"pictures
i
voted
for"
passou
a
ser
um
conteúdo
privado
apenas
para
o
próprio
utilizador.
A
"picture
page"
deixou
de
ser
pública
e,
ao
clicar
numa
"imagem
rival",
em
vez
de
ir
para
a
sua
página
de
detalhe,
o
cliente
preferiu
que
abrisse
um
modal
com
os
resultados
do
duelo.
Em
suma,
o
processo
real
de
UX
e
UI
design
do
Pictty
diferiu
do
planeamento
inicial
(fig.
48,
p.
xx).
O
acompanhamento
e
participação
regular
do
cliente
e
PM
no
processo
de
design
permitiram
introduzir
a
perspectiva
do
Agile
Software
Develpment
no
projecto.
A
fase
de
wireframes
foi
a
mais
longa
de
todo
o
processo
e,
após
esta
fase,
surgiu
uma
tarefa
que,
não
tendo
sido
prevista
inicialmente,
se
revelou
muito
importante:
a
criação
e
apresentação
de
walktroughs.
Seguidamente
foram
feitos
testes
de
usabilidade
a
um
protótipo
de
papel
cujos
resultados
foram
integrados
directamente
no
desenho
de
mockups
para
as
várias
páginas
e
instâncias
da
aplicação.
O
resultado
final
excedeu
o
briefing
do
cliente
em
quantidade
de
funcionalidades
e
simplicidade
dos
modelos
conceptuais.
29
Capítulo 4: Outros Trabalhos
Apresentam-‐se, de seguida, outros trabalhos realizados paralelamente não relacionados
com a aplicação Pictty:
4.1. Encomendados
Cartaz "Intenções 2016" (fig. 49, p. xx)
Sendo a Premium Minds uma organização que aposta na liberdade e satisfação dos
trabalhadores, um dos processos que tive a oportunidade de acompanhar foi a recolha de
opiniões e desejos de todos os colaboradores no que se refere à sua relação com o trabalho.
Com esse levantamento, a administração da empresa estabeleceu as intenções para o ano,
intenções essas que deveriam ser apresentadas sucintamente num cartaz de comunicação
interna cuja execução me foi atribuída.
De modo a ser coerente com a imagem global da empresa, não só utilizei cores e
fontes tipográficas presentes no manual de normas gráficas da Premium, como utilizei um
layout e elementos gráficos em sintonia com os outros suportes de comunicação interna. O
cartaz foi iterado várias vezes até a administração da empresa aprovar a impressão de um
exemplar.
Depois de impresso em escala real e exposto nos locais finais percebi que fazia
sentido alterar alguns detalhes como, por exemplo, a entrelinha. Para além disso, os
próprios trabalhadores da empresa detectaram erros no texto. Por conseguinte, reeditei o
cartaz e foram impressos e afixados os novos exemplares.
Painéis e autocolantes “ORCS” (fig. 50, p. xx)
Posteriormente à determinação das intenções supra referenciadas, a administração da
empresa pediu a cada equipa que associasse os seus objectivos específicos às intenções da
Premium. Seguidamente, foi pedido a cada trabalhador que definisse resultados-‐chave para
cada objectivo e, assim, os funcionários e equipas passariam a poder trabalhar no sentido
de concretizar as intenções da empresa.
Neste contexto foi-‐me pedido que projectasse um painel que facilitasse o processo
de reflexão e comunicação dos objectivos e resultados-‐chave de cada equipa. Cada painel
devia ter espaço para no máximo 8 intenções, 10 objectivos e 4 resultados-‐chave por
objectivo. Cada equipa devia poder preencher o painel livre e independentemente de mim
ou de qualquer outro designer, contando que o resultado fosse legível e esteticamente
agradável.
A proposta que desenvolvi foi um painel-‐base e 3 tipos de autocolantes. O painel foi
concebido para ser impresso a preto e branco no formato A1, e consiste numa série de
30
“placeholders
de
autocolantes”
que
verticalmente
estão
divididos
por
intenções,
objectivos
e
resultados-‐chave
e,
horizontalmente,
estabelecem
associações
entre
estes
três.
Os
três
tipos
de
autocolantes
distinguem-‐se
entre
si
pela
cor
e
tamanho.
As
intenções
ficaram
a
azul
por
serem
vagas
e
os
resultados-‐chave
a
verde
por
serem
concretos.
Para
produzir
os
autocolantes
criei
documentos
em
formato
pdf
A4
editáveis
que
foram
preenchidos,
impressos,
cortados
e
colados
pelas
equipas.
Penso
que
o
suporte
de
comunicação
desenvolvido
foi
bem-‐sucedido
e
teve
a
vantagem
de
permitir
uma
grande
flexibilidade.
No
entanto,
como
resultaram
mais
painéis
vazios
do
que
cheios,
penso
que
num
próximo
redesign
será
uma
boa
ideia
reduzir
o
número
de
“placeholders”
e
com
isso
o
tamanho
do
Painel.
Por
outro
lado,
a
quantidade
de
caracteres
usada
pela
maior
parte
das
pessoas
foi
menor
do
que
a
que
eu
tinha
inicialmente
previsto,
pelo
que
sugiro
aumentar
o
corpo
de
letra
dos
autocolantes
que
desse
modo
ganharão
mais
legibilidade.
A
administração
da
empresa
também
verificou
ser
útil
que
cada
painel
tivesse
uma
identificação
da
equipa
e
do
período
temporal.
4.2.
Auto-‐propostos
Mockup
de
site
"Irmandade
do
Natão"
(fig.
51,
p.
xx)
Nas
primeiras
semanas
do
estágio
percebi
que,
de
vez
em
quando,
aparecia
no
refeitório
uma
caixa
de
pastéis
de
nata
de
acesso
restrito
a
apenas
alguns
funcionários.
Informei-‐me
e
fiquei
a
saber
que
se
tratava
da
dinâmica
de
um
grupo
chamado
“Irmandade
do
Natão”.
Na
sequência
desta
descoberta,
e
sendo
eu
apreciador
da
iguaria,
quis
fazer
parte
no
grupo.
Sendo
que
a
dinâmica
era
regida
por
regras
próprias
e
havia
informações
partilhadas
exclusivamente
dentro
do
grupo,
propus
fazer
o
design
de
um
site
que
apresentasse
a
referida
Irmandade.
Assim,
num
dos
Dias
Criativos
apresentados
no
capítulo
de
caracterização
da
empresa
(p.
xx),
fiz
uma
entrevista
aos
fundadores
do
grupo
de
modo
a
gerar
conteúdo,
organizei
esse
conteúdo
por
várias
secções
e
esbocei
o
layout
da
página
web.
Escolhi
dois
tipos
de
letra
e
um
esquema
de
cores
e
projectei
uma
identidade
gráfica
para
a
Irmandade.
Seleccionei
uma
imagem
apropriada
para
o
topo
do
site
e,
com
todos
estes
elementos
no
“Sketch”,
fiz
vários
ajustes
de
design
de
comunicação
(como
a
posição
e
escala
dos
elementos),
até
produzir
o
resultado
final.
O
mockup
foi
entregue
a
um
front-‐end
developer
para
ser
implementado
na
web.
Logótipos
"Premium
Ideas"
e
"Eureka"
(fig.
52,
p.
xx)
Sendo
que
uma
das
áreas
da
minha
formação
base
é
a
criação
de
identidades
gráficas,
um
dos
meus
Dias
Criativos
começou
por
perceber
se
esse
serviço
não
poderia
ser
útil
a
algum
dos
projectos
em
curso
na
empresa.
Marquei
uma
curta
reunião
com
os
colegas
que
me
reponderam
ao
email
que
enviei
a
colocar
essa
questão
e,
com
eles,
produzi
briefings
para
31
cada
um
dos
logótipos
que
eram
necessários,
um
dos
quais
foi
por
mim
executado:
um
logo
para
a
plataforma
de
inovação
da
Premium
Minds.
Com
o
projecto
principal,
o
Pictty,
estava
a
perceber
que
por
vezes
as
primeiras
ideias
que
surgiam
no
brainstorming
eram
as
melhores.
Para
além
disso,
ao
longo
das
várias
iterações
iam-‐se
abandonando
boas
soluções
que
voltavam
a
ser
trazidas
de
volta
mais
tarde.
Tendo
isto
em
consideração,
decidi
que
não
ia
perder
mais
do
que
cinco
minutos
no
brainstorming
e,
também,
que
ia
levar
a
ideia
escolhida
até
à
sua
concretização,
sem
perder
tempo
a
vaguear
por
inúmeras
possibilidades.
Para
a
plataforma
de
inovação
da
Premium
criei
então
um
logótipo
que
consiste
na
representação
de
uma
cabeça
cheia
de
ideias
acompanhada
pelo
nome
“Premium
Ideas”.
A
administração
da
empresa
não
gostou
e
pediu-‐me
para
fazer
um
outro
logótipo
a
partir
da
palavra
“Eureka”.
Então,
criei
um
símbolo
que
representa,
simultaneamente,
uma
lâmpada
e
uma
planta
a
germinar.
Esta
última
proposta
foi
aprovada
e
adoptada.
32
Conclusão e Considerações Finais
Foi um grande privilégio ter podido estagiado na Premium Minds. Não só por ser uma
Software House reconhecida no mercado pela sua excelência, como especialmente pela
cultura empresarial e pelas pessoas com quem me relacionei. Fui recebido por todos com
hospitalidade e aprendi bastante com a sua experiência. Trabalhei com colegas das
disciplinas mais variadas num ambiente informal e propício à criatividade. Verifiquei que os
valores da empresa (a honestidade, o respeito, a responsabilidade e o brio profissional)
eram de facto postos em prática e pude participar numa série de eventos onde criei laços de
amizade com vários colaboradores.
Tive também o grande privilégio de trabalhar com um cliente experiente e aberto à
inovação. Na relação com o cliente e com o product manager, para meu benefício, integrei
alguns dos princípios da filosofia Agile (fig. 53 , p. xx). Compreendi o quão importante é
evitar despender tempo de trabalho em aspectos que não sejam prioritários, e percebi que
é desejável ser acompanhado com frequência, mesmo que os avanços no projecto, entre
reuniões, não sejam visivelmente significativos. Aprendi ainda que é mais importante criar o
produto em si do que acessórios que o documentem e, sobretudo, constatei que a correcta
e eficaz comunicação oral das decisões de design é tão importante como essas mesmas
decisões.
Foi-‐me confiado o trabalho de UX e UI design de uma aplicação web ambiciosa e tive
que estudar e aprender bastante para estar à altura do desafio. Tive que pensar e desenhar
soluções para uma plataforma com vertentes tão diversas como rede social, dinâmicas de
votação, gamification, gambling e upload de imagens. O projecto passou por fases de UX
research, nas quais fiz benchmarking e fluxos de utilizador. Desenhei wireframes para
inúmeras páginas, secções e componentes e apresentei walktroughs. Fiz um protótipo em
papel e realizei um teste de usabilidade numa fase inicial do projecto. Fiz mockups e
procurei ser coerente nos componentes desenhados. Passei o meu trabalho ao front-‐end
developer e a plataforma foi realmente implementada.
O estágio teve também alguns aspectos mais difíceis. No entanto, reconheço agora,
depois desta experiência e do muito que com ela aprendi, que grande parte dos problemas
por que passei se deveram à minha (ainda) pouca capacidade de comunicação em
ambientes empresariais. As fases de research —análise da concorrência, criação de
personas e desenho de fluxos de utilizador— e mesmo os testes de usabilidade, não eram, à
data, muito valorizadas pelo cliente; foi-‐me indicado, portanto, que não realizasse algumas
etapas importantes no processo de design que acredito que podiam ter enriquecido o
produto final. Também na fase de wireframes acabei por entrar em demasiados detalhes
visuais, enquanto que, na verdade, deveria ter focado esse momento no aspecto funcional
da aplicação. Despendi ainda demasiado tempo em sucessivas iterações de criação de
textos, o que seria solucionado se existisse na equipa uma pessoa especializada em escrever
conteúdo.
33
No
que
se
refere
às
metodologias
de
design
que
tentei
implementar
—Design
Responsivo
e
Design
Atómico—
reconheço
que
posso
não
ter
conseguido
explicá-‐las
com
os
argumentos
mais
apropriados
e
no
momento
certo;
tendo
o
cliente
optado
por
metodologias
mais
antigas,
antevejo
que
podem
surgir
vários
obstáculos
quando
se
quiser
apostar
em
tornar
o
Pictty
numa
aplicação
responsiva.
Por
outro
lado,
como
não
segui
devidamente
a
metodologia
de
design
atómico,
o
trabalho
do
front-‐end
developer
ficou
também
mais
dificultado
e
demorado
do
que
se
lhe
tivesse
sido
entregue
um
documento
com
um
sistema
coerente
de
web
components.
A
metodologia
de
design
e
front-‐end
seguida
na
concepção
do
Pictty
esteve
muito
próxima
do
modelo
waterfall
e,
deste
modo,
alguns
recursos
não
foram
optimizados.
Outro
aspecto
no
qual
surgiram
algumas
dificuldades
foi
a
escolha
e
articulação
das
diferentes
ferramentas
usadas.
Embora
não
tenha
chegado
a
utilizar
nenhuma
ferramenta
de
criação
de
mind
maps,
em
projectos
desta
natureza
e
com
esta
complexidade
parece-‐me
que
a
utilização
de
softwares
para
o
efeito
pode
ser
uma
ajuda
importante,
especialmente
para
a
concepção
de
fluxos
de
utilizador.
A
passagem
do
Balsamiq
para
o
Sketch
foi
outro
dos
momentos
que
poderia
ter
sido
optimizado
com
o
auxílio
de
uma
ferramenta
adequada;
considero
que
teria
sido
mais
ágil
desenhar
os
wireframes
de
baixa
fidelidade
no
Sketch
e,
na
fase
de
design
visual,
aumentar
a
fidelidade
dos
componentes,
ou
seja,
usar
o
Sketch
para
ambos
os
momentos.
A
minha
necessidade
de
compreender
tudo,
até
ao
mais
ínfimo
pormenor,
num
estádio
inicial
do
trabalho,
foi
outro
aspecto
que
me
levou
a
despender
demasiada
energia.
Nesse
contexto,
desenhei
todos
os
detalhes
para
assim
os
compreender.
Esta
abordagem
não
só
consumiu
muito
tempo
como,
por
vezes,
me
deixou
mentalmente
exausto.
Aprendi,
com
esta
experiência,
que
no
início
do
projecto
se
deve
desenhar
apenas
os
aspectos
cruciais,
que
permitam
ter
a
noção
do
todo,
deixando
os
pormenores
para
depois.
Quanto
aos
testes
de
usabilidade,
constatei
que
é
preferível
serem
realizados
várias
vezes
ao
longo
do
projecto,
mesmo
que
de
modos
muito
simples.
O
ideal
é
testar
o
protótipo
com
utilizadores
finais
mas,
independentemente
do
perfil
do
utilizador,
os
testes
de
usabilidade
trazem
sempre
indicações
valiosas,
e
é
de
extrema
importância
que
o
cliente
e
o
designer
participem
nos
testes
como
observadores.
Estes
devem
ir
anotando
os
problemas
encontrados
e,
no
final
do
teste,
organizá-‐los
e
priorizar
as
alterações.
Deste
modo,
poupam-‐se
várias
horas
a
ver
gravações
e
possibilita-‐se
que
os
resultados
dos
testes
sejam
accionáveis.
Outra
dimensão
geradora
de
ansiedade
foi
o
facto
de
ter
que
ir
a
reuniões
onde
sentia
que
era
impossível
levar
concluído
o
que
ia
ser
discutido.
Aprendi
que
é
muito
importante
gerir
as
espectativas
do
cliente
e
ir
mostrando
avanços
ao
projecto,
ainda
que
pequenos,
com
maior
frequência.
Deste
modo,
os
clientes
ficam
mais
satisfeitos
e
existe
mais
espaço
para
uma
comunicação
genuína.
No
entanto,
este
acompanhamento
constante
do
cliente
pode
também
propiciar
que
surjam
demasiadas
mudanças
de
plano,
novos
requisitos
e
iterações
infindáveis.
Se
houver
um
prazo
final
para
a
entrega
da
totalidade
do
projecto,
este
número
exagerado
de
iterações
vai
retirar
tempo
de
trabalho
a
fases
34
posteriores igualmente importantes. Neste sentido, é indispensável limitar o número de
iterações consoante os prazos e o orçamento disponíveis.
Com toda esta aprendizagem, retomo a questão que despoletou todo este estudo:
como integrar as metodologias de User Centered Design, Atomic Design e Agile Software
Development?
Se voltasse a fazer um projecto semelhante no futuro idealizaria o workflow de
outro modo (fig. 54, p. xx):
1. Inspirado nas metodologias Agile organizaria as fases do projecto pela entrega de
deliveries mais leves;
2. Desenharia, quer os wireframes, quer os protótipos, numa abordagem de design
responsivo;
3. Começaria pelos ecrãs pequenos tendo em conta que as condicionantes do espaço
iriam obrigar a equipa a priorizar os conteúdos e funcionalidades mais importantes;
4. Seriam agendados, desde o início, vários testes de usabilidade. Os testes deveriam ser
simples e, de preferência, o cliente seria observador, de modo a que os resultados
fossem accionáveis. Caso a parte do projecto a ser testada não estivesse acabada
quando chegasse o dia do teste, testar-‐se-‐ia o que estivesse feito.
5. O mesmo devia acontecer nas reuniões com o cliente: ser apresentado o que estivesse
feito e manter um acompanhamento regular. É claro que teriam de ser limitadas as
alterações de requisitos e número de iterações consoante os prazos gerais do projecto;
6. A primeira entrega ao cliente seriam walktroughs com pouco detalhe de fluxo, feitos
em papel;
7. Depois de discutida a primeira entrega, usando o Sketch e o Flinto, seria feito um
protótipo interactivo de baixa fidelidade que contemplasse apenas os fluxos principais;
8. De seguida, seria decidido o aspecto visual genérico da interface, seria desenhado um
sistema coerente de componentes, mas poucos mockups. Entretanto, o front-‐end
developer já estaria bastante avançado no protótipo de HTML e, depois de algumas
iterações, a interface estaria pronta;
9. Faltaria agora ligar o front-‐end ao back-‐end da aplicação e, seguidamente, a aplicação
seria posta online;
10. Daqui em diante seriam feitos testes de usabilidade remotos, análises do tráfego e
heatmaps no sentido de encontrar e resolver problemas de usabilidade na interação
dos utilizadores finais com o sistema.
Fazendo uma retrospectiva, considero que toda a minha dedicação a este projecto e
ao estágio na Premium Minds foi muito bem empregue. Foi uma experiência que me
possibilitou um grande amadurecimento em termos profissionais e humanos. Considero
também que obtive bons resultados, mas, quanto a isso, convido o leitor a julgar por si
mesmo em pictty.com.
35
Bibliografia
AA.VV.
(n.d.)
User
Interface
Design
Basics
[Versão
electrónica].
Disponível
em
https://www.usability.gov/what-‐and-‐why/user-‐interface-‐design.html
Anderson,
Jonathan;
John
McRee,
(2010):
Effective
UI.
Beijing:
O'Reilly;
Allen,
Jesmond;
Chudley,
James
(2012):
Smashing
UX
Design
Foundations
for
Designing
Online
User
Experiences.
Chichester:
Wiley;
Archer,
James
(n.d.):
Agile
design:
what
we’ve
learned
[Versão
electrónica].
Disponível
em
http://forty.co/agile-‐design-‐what-‐weve-‐learned
Beck,
Kent
et
al.
(2001):
Manifesto
para
o
Desenvolvimento
Ágil
de
Software.
[Versão
electrónica].
Disponível
em
http://agilemanifesto.org/iso/ptpt/manifesto.html
Cao,
Jerry
(2016):
The
Top
10
Product
Design
Lessons
for
2016
[Versão
electrónica].
Disponível
em
https://studio.uxpin.com/blog/top-‐10-‐product-‐design-‐lessons-‐for-‐2016/
Colborne,
Giles
(2011):
Simple
and
Usable:
Web,
Mobile,
and
Interaction
Design.
Berkeley,
CA:
New
Riders;
Frost,
Brad
(2016):
Atomic
Design
[Versão
electrónica].
Disponível
em
http://bradfrost.com/blog/post/atomic-‐web-‐design/
Hay,
Stephen
(2013):
Responsive
Design
Workflow.
San
Francisco,
New
Riders;
Kandy,
A.
J.
(2016):
"Y"
Fidelity:
Adaptive
Design
for
Agile
Workflows
[Versão
electrónica].
Disponível
em
http://blog.invisionapp.com/adapting-‐design-‐agile-‐workflows/
Krug,
Steve
(2014):
Don't
Make
Me
Think,
Revisited
a
Common
Sense
Approach
to
Web
Usability.
Berkeley,
Calif.:
New
Riders;
Marcotte,
Ethan
(2011):
Responsive
Web
Design.
New
York,
Book
Apart;
Morville,
Peter
(2004):
User
Experience
Design
[Versão
electrónica].
Disponível
em
https://www.nngroup.com/articles/usability-‐101-‐introduction-‐to-‐usability/
http://semanticstudios.com/user_experience_design/
Nielsen,
Jakob;
Budiu,
Raluca
(2013):
Mobile
Usability.
Berkeley,
CA:
New
Riders;
36
Nielsen,
Jakob
(2012):
Usability
101:
Introduction
to
Usability
[Versão
electrónica].
Disponível
em
https://www.nngroup.com/articles/usability-‐101-‐introduction-‐to-‐usability/
Norman,
Donald
A.
(2011):
Living
with
Complexity.
Cambridge,
Mass.:
MIT
Press;
Peterson,
Clarissa
(2014):
Learning
Responsive
Web
Design:
A
Beginner’s
Guide.
Sebastopol,
O’Reilly
Media;
Premium
Minds
(2016):
About-‐us.
Diponível
em
http://www.premium-‐minds.com/about-‐us/
Spencer,
Donna
(2010):
A
Practical
Guide
to
Information
Architecture.
Penarth:
Five
Simple
Steps;
Weinschenk,
Susan
(2011):
100
Things
Every
Designer
Needs
to
Know
about
People.
Berkeley,
CA:
New
Riders;
37
Lista de Figuras
Figura 1 -‐ Processo do user-‐centered design ........................................................................................ 41
Figura 2 -‐ Ilustração sobre o design responsivo ................................................................................... 41
Figura 3 -‐ Modelo do Atomic Design .................................................................................................... 41
Figura 4 -‐ Modelo Waterfall ................................................................................................................. 42
Figura 5 -‐ Processo do Agile Software Development ............................................................................ 42
Figura 6 -‐ Diagrama representativo dos colaboradores e equipas da Premium Minds ........................ 43
Figura 7 -‐ Colaboradores da Premium Mind ......................................................................................... 43
Figura 8 -‐ Diagrama representativo do fluxo de uma imagem no Pictty .............................................. 44
Figura 9 -‐ Diagrama com estrutura de duelos e de votadores por cada competição do Pictty ........... 45
Figura 10 -‐ Diagrama representativo dos resultados de competição de uma imagem no Pictty ......... 45
Figura 11 -‐ Diagrama representativo das fases de trabalho planeadas inicialmente ........................... 46
Figura 12 -‐ Alguns dos mindmaps das tarefas principais da aplicação e fluxos de utilizador .............. 47
Figura 13 -‐ Mapa do site na fase inicial do projecto ............................................................................. 47
Figura 14 -‐ Wireframe dos dois estados da barra de navegação numa fase inicial do projecto .......... 47
Figura 15 -‐ Frames de um dos walktroughs apresentados de forma linear ......................................... 48
Figura 16 -‐ Frames da gravação de um dos testes de usabilidade ao protótipo de papel ................... 49
Figura 17 -‐ Alguns dos elementos e componentes do guia de estilos do Pictty ................................... 50
Figura 18 -‐ Primeiro wireframe da homepage do Pictty ...................................................................... 51
Figura 19 -‐ Outros wireframes da homepage do Pictty ........................................................................ 51
Figura 20 -‐ Mockups da homepage do Pictty ....................................................................................... 51
Figura 21 -‐ Wireframe da página “my votes” ....................................................................................... 52
Figura 22 -‐ Wireframe de momento e modal de aquisição de “badge de votador” ............................ 52
Figura 23 -‐ Mockup da página “my votes” ............................................................................................ 52
Figura 24 -‐ Primeiros wireframes da página “my pictures” e modals de resultados de competição .. 53
Figura 25 -‐ Wireframes da página “my pictures” e sistema de cartas .................................................. 53
Figura 26 -‐ Wireframes do separador “portfolio” da página “my pictty” e sistema de cartas ............ 54
Figura 27 -‐ Mockups do separador “portfolio” da página “my pictty” e sistema de cartas ................. 54
Figura 28 -‐ Wireframes e mockups da “picture page” e sistema de painéis ........................................ 54
Figura 29 -‐ Wireframes do primeiro momento da modal “add pictures” ........................................... 55
Figura 30 -‐ Wireframes do segundo momento da modal “add pictures” ............................................ 55
Figura 31 -‐ Wireframes da secção superior da modal “add pictures” ................................................. 55
Figura 32 -‐ Mockups do primeiro momento da modal “add pictures” ................................................ 56
Figura 33 -‐ Mockups do segundo momento da modal “add pictures” ................................................ 56
Figura 34 -‐ Primeiro wireframe da “wallet” ........................................................................................ 57
Figura 35 -‐ Wireframe da “wallet” na barra lateral à esquerda .......................................................... 57
Figura 36 -‐ Wireframe da “wallet” na barra de navegação ................................................................. 57
Figura 37 -‐ Mockup da “wallet” ........................................................................................................... 57
Figura 38 -‐ Primeiros wireframes da modal “deposit funds” ............................................................... 58
Figura 39 -‐ Wireframes da modal “deposit funds” .............................................................................. 58
Figura 40 -‐ Mockup da modal “deposit funds” .................................................................................... 58
38
Figura
41
-‐
Social
sharing
de
resultados
de
duelo
e
competição
e
“badges
de
votador”
....................
59
Figura
42
-‐
Botões
de
“Like”,
“Tweet”
e
“G+1”
e
“Follow
Us”
presentes
no
“footer”
..........................
59
Figura
43
-‐
Mockup
da
modal
“sign
in”
com
botões
de
social
login
.....................................................
59
Figura
44
-‐
Botões
de
importação
de
imagens
de
outras
redes
sociais
na
modal
“add
pictures”
.......
59
Figura
45
-‐
Mockup
da
página
“gallery”
...............................................................................................
60
Figura
46
-‐
Barra
de
perfil
na
página
“my
pictty”
.................................................................................
60
Figura
47
-‐
Histórico
de
competição
de
uma
imagem
na
“picture
page”
............................................
60
Figura
48
-‐
Diagrama
representativo
do
fluxo
de
trabalho
que
realmente
se
sucedeu
......................
61
Figura
49
-‐
Cartaz
“Intenções
2016”
.....................................................................................................
62
Figura
50
-‐
Painéis
e
autocolantes
“ORCS”
...........................................................................................
62
Figura
51
-‐
Mockup
de
site
“Irmandade
do
Natão”
..............................................................................
63
Figura
52
-‐
Logótipos
“Premium
Ideas”
e
“Eureka”
..............................................................................
63
Figura
53
-‐
Ilustração
de
Henrik
Kniberg
sobre
o
Agile
Software
Development
...................................
64
Figura
54
-‐
Workflow
para
um
projecto
semelhante
a
realizar
no
futuro
............................................
65
39
ANEXOS
40
Investigar
Design
ou Testar
Começar Entregar
fig. 1 - Processo do user-centered design
fig. 2 - Ilustração sobre o design responsivo
fig. 3 - Modelo do Atomic Design
41
Começar
Específicar
Planear
Implementar
Testar
Entregar
fig.4 - Modelo Waterfall
Planear
Implementar
Específicar
Começar Entregar
Testar
fig. 5 - Processo do Agile Software Development
42
Equipa de Gestão DAF
Cliente Product Managers Agile Coachs
Sistemas
Designers
Arquitectos
Developers
Data Scientists
Qualidade
fig.6 - Diagrama representativo dos colaboradores e equipas da Premium Minds
fig.7 - Colaboradores da Premium Minds
43
ganhar
perder e
Nível 5 sair de jogo
competir
empatar
recolher dinheiro
e sair de jogo Vale ainda
mais dinheiro
ganhar
perder e
Nível 4 sair de jogo
competir
empatar
recolher dinheiro
e sair de jogo Vale ainda
mais dinheiro
ganhar
perder e
Nível 3 sair de jogo
competir
empatar
recolher dinheiro
e sair de jogo Vale ainda
mais dinheiro
ganhar
perder e
sair de jogo
Nível 2
competir
recolher dinheiro empatar
e sair de jogo
Vale ainda
mais dinheiro
ganhar
perder e
Nível 1 sair de jogo
competir
empatar
recolher dinheiro
e sair de jogo
Vale dinheiro
carregar dinheiro, entrar no jogo e competir
Não vale competir Playground
dinheiro
ganhar, perder ou empatar
adicionar ao Pictty
Fora do Pictty
fig. 8 - Diagrama representativo do fluxo de uma imagem no Pictty
(O modelo exacto dos valores de dinheiro envolvidos no jogo é
confidencial e como tal não foi mencionado) 44
VS VS
Votador 1 Votador 4
VS VS
Votador 2 Votador 5
VS VS
Votador 3 Votador 6
fig. 9 - Diagrama com estrutura de duelos e de
votadores por cada competição do Pictty
vence x duelos ganha competição
vence y duelos empata competição
e nenhuma imagem rival vence x duelos
vence y duelos empata competição
mas uma imagem rival vence x duelos
vence z duelos perde competição
fig. 10 - Diagrama representativo dos resultados de competição de uma
imagem no Pictty (a relação exacta entre os resultados dos duelos e os
resultados de competição é confidencial e como tal não foi mencionada)
45
Reunião Inicial
UX Benchmarking;
Personas;
Fluxos de utilizador;
Protótipo Interactivo Arquitectura de informação;
Wireframes (design responsivo);
(baixa fidelidade) Interactividade;
Iterar fase anterior com base no
Testes de Usabilidade feedback recolhido
(com utilizadores finais);
UI Benchmarking;
Protótipo Interactivo Componentes UI (atomic design);
(alta fidelidade) Mockups (design responsivo);
Interactividade e motion design;
Iterar fase anterior com base no
Apresentação ao cliente, PM, feedback recolhido
front-end developer e colegas
(markteer e designer);
Protótipo de HTML Acompanhar front-end no browser;
Sugerir melhorias de design;
Testes de usabilidade
remotos de larga escala; Iterar fase anterior com base no
Heatmaps e user recordings; feedback recolhido
Web Analytics;
Apresentação ao cliente;
Entrega Final
fig. 11 - Diagrama representativo das fases de trabalho planeadas inicialmente
46
fig. 12 - Alguns dos mindmaps das tarefas principais da aplicação e fluxos de utilizador
fig. 13 - Mapa do site na fase inicial do projecto
fig. 14 - Wireframe dos dois estados da barra de navegação
(antes e após o login) numa fase inicial do projecto
47
fig. 15 - Frames de um dos walktroughs apresentados de forma linear
48
fig. 16 - Frames da gravação de um dos testes de usabilidade ao protótipo de papel 49
Pictty, uma aplicação web I Choose This One
Thomas K. Elliott
para de fotografia Category Traveling Level Two Prize 3 $
Report This One
Proxima nova Join Contest 1$
Pictty, uma aplicação web
para de fotografia Join Contest 1$
Ready for processing between
Thu, 24 Mar 2016 Join Contest 1$
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz Competing…
0123456789
;:_^|`!”#$%&/()=?*-.,+´\~
Unselected Unselected
Like
Over Over
Tweet
Active Active
Selected Selected
Connect with Facebook Connect with Google Default None Focus Highest Achievement
Default Highest Achievement Focus Highest Achievement
Connect with Twitter Create Account with Email
Highest Achievement
Over Highest Achievement Highest Achievement
Over empty input Over Filled input
Highest Achievement
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Highest Achievement
Over Filled input Over Filled input
Messages Files Activities To-do Settings
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Over Filled input Filling input again
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Picture Page
Compete in Level 2
Compete in Playground
If you win this level your
picture will worth 11$. If you Leave Contest
lose, it will go out of
contest. If you tie it will
Delete
continue
Won Level 1 to worth 3$. 3$
Worth Won Level 1 Worth 3$
Competing in Level 1 Won Level 1 Worth 3$ Drew Level 1 Worth 1$
OK
Competing… Compete in Level 2 Compete in Level 2
Compete in Level 2 Compete in Level 2
Picture Status: Won Level 1 Picture Value: 3$ Picture Status: New Picture Value: 1$
My Results Against Rivals Call to action or explanatory copy My Results Against Rivals Call to action or explanatory copy
Join Contest 1$
Share Picture Compete in Playground (Free) Leave Contest Delete Picture Share Picture Compete in Playground (Free) Leave Contest Delete Picture
fig. 17 - Alguns dos elementos e componentes do guia de estilos do Pictty
50
fig. 18 - Primeiro wireframe da homepage do Pictty
fig. 19 - Outros wireframes da homepage do Pictty
fig. 20 - Mockups da homepage do Pictty
51
fig. 21 - Wireframe da página “my votes” fig. 22 - Wireframe de momento e modal
de aquisição de “badge de votador”
fig. 23 - Mockup da página “my votes”
52
fig. 24 - Primeiros wireframes da página “my pictures” e modals de resultados de competição
fig. 25 - Wireframes da página “my pictures” e sistema de cartas
53
fig. 26 - Wireframes do separador “portfolio” da página “my pictty” e sistema de cartas
fig. 27 - Mockups do separador “portfolio” da página “my pictty” e sistema de cartas
fig. 28 - Wireframes e mockups da “picture page” e sistema de painéis 54
fig. 29 - Wireframes do primeiro momento da modal “add pictures”
fig. 30 - Wireframes do segundo momento da modal “add pictures”
fig. 31 - Wireframes da secção superior da modal “add pictures”
55
fig. 32 - Mockups do primeiro momento da modal “add pictures”
fig. 33 - Mockups do segundo momento da modal “add pictures” 56
fig. 34 - Primeiro wireframe da “wallet”
fig. 35 - Wireframe da “wallet” na barra lateral à esquerda
fig. 36 - Wireframe da “wallet” na barra de navegação
fig. 37 - Mockup da “wallet”
57
fig. 38 - Primeiros wireframes da modal “deposit funds”
fig. 39 - Wireframes da modal “deposit funds”
fig. 40 - Mockup da modal “deposit funds” 58
fig. 41 - Social sharing de resultados de duelo e competição e aquisição de “badges de votador”
fig. 42 - Botões de “Like”, “Tweet” e “G+1” e “Follow Us” presentes no “footer”
fig. 43 - Mockup da modal “sign in” com botões de social login
fig. 44 - Botões de importação de imagens de outras
redes sociais na modal “add pictures”
59
fig. 45 - Mockup da página “gallery”
fig. 46 - Barra de perfil na página “my pictty”
fig. 47 - Histórico de competição de uma imagem na “picture page”
60
Reunião Inicial
UX Benchmarking;
Fluxos de utilizador;
Arquitectura de Informação;
Wireframes Copywritting;
Wireframes (apenas desktop);
Cada parte da aplicação foi iterada entre
3 e 6 vezes com base no feedback
Apresentação ao cliente e PM; recolhido e decisões do cliente
Walktroughs Criar walktroughs;
Foram feitas 2 iterações com
Apresentação ao cliente, PM, base no feedback recolhido e
front-end developer e colegas decisões do cliente
(markteer e designer);
Protótipo de Papel Imprimir, cortar e organizar todos
os elementos da interface;
Teste de usabilidade
(a colegas da empresa);
Apresentação ao cliente e PM;
As alterações baseadas no feedback recolhido
e decisões do cliente foram feitas directamente
na fase dos mockups
UI Benchmarking;
Mockups Mockups;
Guia de estilos;
Cada parte da aplicação foi iterada
Apresentação ao cliente, PM e entre 1 e 3 vezes com base no feedback
colegas (front-end developer recolhido e decisões do cliente
e designer);
Entrega Final
fig. 48 - Diagrama representativo do fluxo de trabalho que realmente se sucedeu
61
INTENÇÕES 2016
Reforçar a confiança interpessoal, a cooperação e a autenticidade
entre todas as pessoas, independentemente da função e da equipa.
Continuar a gerar valor para os clientes atuais, criando
a possibilidade de aumentar o negócio com eles.
Ter uma rentabilidade sustentada que permita reduzir o
micromanagement financeiro, criando espaço para a investigação
e a criatividade sem pôr em causa a satisfação do cliente.
Garantir o equilíbrio entre a vida profissional e a vida pessoal
de todas as pessoas.
Criar oportunidades para que todas as pessoas possam
desenvolver todo o seu potencial.
Posicionar comercialmente a Premium Minds como um parceiro
de R&D, tanto de grandes empresas como de startups.
Angariar um novo cliente âncora, que traga negócio com dimensão
e duração sustentadas.
Melhorar continuamente a eficácia e a eficiência da organização
sem ter medo de experimentar.
fig. 49 - Cartaz “Intenções 2016”
Intenções Objectivos Resultados-chave
fig. 50 - Painéis e autocolantes “ORCS”
62
fig. 51 - Mockup de site “Irmandade do Natão”
fig. 52 - Logótipos “Premium Ideas” e “Eureka”
63
fig. 53 - Ilustração de Henrik Kniberg sobre o Agile Software Development
64
Reunião Inicial
UX Benchmarking;
Personas;
Fluxos de utilizador;
Walktroughs dos fluxos
Walktroughs principais em baixa-fidelidade
(apenas mobile);
limitar número de iterações consoante o
Teste de Usabilidade prazo de entrega final e o orçamento
(cliente e designer
como observadores);
Arquitectura de Informação;
Protótipo Interactivo Colaboração com copywriter;
(baixa fidelidade) Wireframes (Design Responsivo);
Interactividade (apenas mobile);
limitar número de iterações consoante o
Teste de Usabilidade prazo de entrega final e o orçamento
(cliente e designer
como observadores);
UI Benchmarking;
Inventário da Interface;
20-second gut test;
Moodboard;
Sistema de Componentes Design de componentes UI;
Mockups (poucos);
Apresentação limitar número de iterações consoante o
ao front-end developer; prazo de entrega final e o orçamento
Apresentação ao cliente e PM;
Protótipo de HTML Acompanhar front-end no browser;
Sugerir melhorias de design;
Testes de usabilidade
remotos de larga escala;
Heatmaps e user recordings; limitar número de iterações consoante o
Web Analytics; prazo de entrega final e o orçamento
Apresentação ao cliente,
PM e front-end developer;
Entrega Final
fig. 54 - Workflow para um projecto semelhante a realizar no futuro 65
Você também pode gostar
- Uso Do Project para O Aperfeiçoamento Do Planejamento E Gestão de Mão de Obra Na Construção CivilDocumento19 páginasUso Do Project para O Aperfeiçoamento Do Planejamento E Gestão de Mão de Obra Na Construção CivilJOAO MARCOS DE SOUZA CORREAAinda não há avaliações
- TCC Renato Ostrowski Revisado BancaDocumento137 páginasTCC Renato Ostrowski Revisado BancaAnderson FerreiraAinda não há avaliações
- TCC Exemplo 7Documento159 páginasTCC Exemplo 7Rafael VallerAinda não há avaliações
- Voz TV CD - Marco Caretas - 31855Documento76 páginasVoz TV CD - Marco Caretas - 31855Kelson RodriguesAinda não há avaliações
- Análise da partida do motor de indução trifásicoDocumento78 páginasAnálise da partida do motor de indução trifásicoTassio G PereiraAinda não há avaliações
- Modelagem Estrutural SAP2000Documento3 páginasModelagem Estrutural SAP2000Boots73Ainda não há avaliações
- Implantação do Orçamento como Ferramenta de ControleDocumento12 páginasImplantação do Orçamento como Ferramenta de ControleFilippi MickaelAinda não há avaliações
- Redes SociaisDocumento17 páginasRedes SociaisArthur Luiz05Ainda não há avaliações
- UC-8 Sit - Aprend - 3 - AlunoDocumento5 páginasUC-8 Sit - Aprend - 3 - AlunoSilvana Marques0% (1)
- A Aplicação Das Ferramentas Da Qualidade para Proposta de Melhoria Nos Serviços de Uma Empresa Do Ramo AlimentícioDocumento11 páginasA Aplicação Das Ferramentas Da Qualidade para Proposta de Melhoria Nos Serviços de Uma Empresa Do Ramo AlimentícioVanusaRodriguesAinda não há avaliações
- Registro de atividades de estágio em MatemáticaDocumento1 páginaRegistro de atividades de estágio em MatemáticaGeovani FelipeAinda não há avaliações
- Registro de atividades de estágio em MatemáticaDocumento1 páginaRegistro de atividades de estágio em MatemáticaGeovani FelipeAinda não há avaliações
- Instalação interativa sobre aquecimento globalDocumento1 páginaInstalação interativa sobre aquecimento globalAndré GuimarãesAinda não há avaliações
- Alan Nunes Amaral - GovernançaTICDocumento2 páginasAlan Nunes Amaral - GovernançaTICLan DelongeAinda não há avaliações
- JUAN HENRIQUE BELISIARIO GOULART MOTTA - CertificadoDocumento2 páginasJUAN HENRIQUE BELISIARIO GOULART MOTTA - CertificadoJuan Henrique MottaAinda não há avaliações
- Apostila - CRIANDO EQUIPES COOPERATIVASDocumento16 páginasApostila - CRIANDO EQUIPES COOPERATIVASvelozojr3296Ainda não há avaliações
- Da autoconstrução à arquitetura aberta no BrasilDocumento513 páginasDa autoconstrução à arquitetura aberta no BrasilRosamônica LamounierAinda não há avaliações
- Registro de atividades de estágio em Educação FísicaDocumento1 páginaRegistro de atividades de estágio em Educação FísicaRoberta PereiraAinda não há avaliações
- Leandro Da Silva Santana - CertificadoDocumento2 páginasLeandro Da Silva Santana - CertificadoModo de PrepararAinda não há avaliações
- Apostila Ilustração CientificaDocumento17 páginasApostila Ilustração CientificaTalyta RodriguesAinda não há avaliações
- O papel do conferente de cargas e as características das mercadoriasDocumento87 páginasO papel do conferente de cargas e as características das mercadoriasIsaque AlvesAinda não há avaliações
- V - L Escobar Rizzo-1Documento1 páginaV - L Escobar Rizzo-1lourenco escobarAinda não há avaliações
- Comunicação Das Coisas PDFDocumento15 páginasComunicação Das Coisas PDFÁtila AndradeAinda não há avaliações
- DAVI VINICIUS CHAVES DE LIMA OLIMPIO - CertificadoDocumento2 páginasDAVI VINICIUS CHAVES DE LIMA OLIMPIO - CertificadoDavi ViníciusAinda não há avaliações
- Gestão de ContratosDocumento22 páginasGestão de ContratosCarolina AntunesAinda não há avaliações
- Manual de Manutenção Fiat Palio Weekend, Siena e 2Documento6 páginasManual de Manutenção Fiat Palio Weekend, Siena e 2Cassio HenriqueAinda não há avaliações
- Redação Oficial e Noções de SEI e Suas Aplicações - Certificado PDFDocumento2 páginasRedação Oficial e Noções de SEI e Suas Aplicações - Certificado PDFPollyannaAinda não há avaliações
- Pim IvDocumento10 páginasPim IvAna SzAinda não há avaliações
- ISEC NORMATIVO PGH e GE 2022Documento2 páginasISEC NORMATIVO PGH e GE 2022Rodrigo AraújoAinda não há avaliações
- Cronograma de leitura para pesquisa sobre participação cidadã mediada por tecnologias cívicasDocumento35 páginasCronograma de leitura para pesquisa sobre participação cidadã mediada por tecnologias cívicasManoel dos SantosAinda não há avaliações
- Qualidade e Sustentabilidade: Construir o (Nosso) FuturoDocumento11 páginasQualidade e Sustentabilidade: Construir o (Nosso) FuturoDaniel Dos SantosAinda não há avaliações
- Uso de tintas na construçãoDocumento70 páginasUso de tintas na construçãoAndré CamposAinda não há avaliações
- R&S - Os Desafios Na COVID19Documento32 páginasR&S - Os Desafios Na COVID19VaAinda não há avaliações
- TSE - ADMINISTRATIVA - EDITAL OLÉ - (Com Base em Analista Jud. Área Administrativa - 2011)Documento7 páginasTSE - ADMINISTRATIVA - EDITAL OLÉ - (Com Base em Analista Jud. Área Administrativa - 2011)anaAinda não há avaliações
- Experiência diversa busca emprego atendimento públicoDocumento1 páginaExperiência diversa busca emprego atendimento públicoDreynna SantosAinda não há avaliações
- 8º Bootcamp RetrospectivasDocumento36 páginas8º Bootcamp Retrospectivasmatheus.vasconcelosAinda não há avaliações
- Intensiva o Mostrai Su Bim Imp r01Documento70 páginasIntensiva o Mostrai Su Bim Imp r01Fabiano PereiraAinda não há avaliações
- Clea SoaresDocumento47 páginasClea SoaresMagally Pontes Moraes AlmeidaAinda não há avaliações
- (Magazine Devmedia) Engenharia de Software - Edição 09 - MDADocumento60 páginas(Magazine Devmedia) Engenharia de Software - Edição 09 - MDACarlos Alberto RosaAinda não há avaliações
- AnexoVEdital83 2022Documento2 páginasAnexoVEdital83 2022Cristian HansenAinda não há avaliações
- Sites para baixar famílias no RevitDocumento3 páginasSites para baixar famílias no RevitTalita SchuAinda não há avaliações
- Proposta de Trabalho Tera TelecomDocumento16 páginasProposta de Trabalho Tera TelecomEdson CaetanoAinda não há avaliações
- Utilizando o Winplot Prof. ErminiaDocumento27 páginasUtilizando o Winplot Prof. ErminiaDaiane PinheiroAinda não há avaliações
- Criação de um site de receitas de bolosDocumento7 páginasCriação de um site de receitas de bolosAlicia StolerAinda não há avaliações
- Curso - 25hs StorytellingDocumento2 páginasCurso - 25hs StorytellingKalebe CastroAinda não há avaliações
- Tabela de Tarifas Pessoa Física ItauDocumento1 páginaTabela de Tarifas Pessoa Física ItauFagner VieiraAinda não há avaliações
- PF Tabela GeralDocumento1 páginaPF Tabela GeralWagnerAinda não há avaliações
- Apresentação Final Alluz - MarketingDocumento7 páginasApresentação Final Alluz - MarketingnaillastefanyAinda não há avaliações
- Projeto rede colaborativa memória tipografia MGDocumento169 páginasProjeto rede colaborativa memória tipografia MGAna Paula DacotaAinda não há avaliações
- Transformando projetos em realidadeDocumento18 páginasTransformando projetos em realidadeLeandro Farias (Jobs)Ainda não há avaliações
- CV-Fabio Dos SantosDocumento7 páginasCV-Fabio Dos SantosmarcelobmfAinda não há avaliações
- TF DocinterativoDocumento1 páginaTF DocinterativoPatrícia NogueiraAinda não há avaliações
- 1209.1.20 - Ata FinalDocumento2 páginas1209.1.20 - Ata FinalAYLA APARECIDA LORENA SEIXASAinda não há avaliações
- 01 Relatorio FGIMz2021 FINAL0231.12.21Documento51 páginas01 Relatorio FGIMz2021 FINAL0231.12.21JoséAinda não há avaliações
- Design de Negócios Sociais - Gabriela Reis - Dissertação PDFDocumento102 páginasDesign de Negócios Sociais - Gabriela Reis - Dissertação PDFArnaldo Soba100% (1)
- Mapa RUMODocumento2 páginasMapa RUMOFernando KipperAinda não há avaliações
- Bruno José Goes Bezerra - CertificadoDocumento2 páginasBruno José Goes Bezerra - CertificadoBruno GoesAinda não há avaliações
- ISMAT 21-22 MI ESBOÇO-tese ClaudiaRACAchutti-FINALDocumento25 páginasISMAT 21-22 MI ESBOÇO-tese ClaudiaRACAchutti-FINALClaudia AchuttiAinda não há avaliações
- BPMN - Poster 2.0 v49Documento1 páginaBPMN - Poster 2.0 v49RogerioAinda não há avaliações
- Virtus 1Documento3 páginasVirtus 1cassio bittencourtAinda não há avaliações
- Dicas para alcançar bons resultados no Instagram para óticasDocumento5 páginasDicas para alcançar bons resultados no Instagram para óticasGedalias SouzaAinda não há avaliações
- SAP Professional 2.0 (Prática1) - v1.1Documento70 páginasSAP Professional 2.0 (Prática1) - v1.1Vinicius VieiraAinda não há avaliações
- TM200CE24TDocumento3 páginasTM200CE24Tjbaltazar77Ainda não há avaliações
- VLANs e STPDocumento17 páginasVLANs e STPGregório HigashikawaAinda não há avaliações
- KILPP, Suzana Et Al (Org.) - Tecnocultura Audiovisual Temas, Metodologias e Questões de Pesquisa. Porto Alegre Sulina, 2015.Documento208 páginasKILPP, Suzana Et Al (Org.) - Tecnocultura Audiovisual Temas, Metodologias e Questões de Pesquisa. Porto Alegre Sulina, 2015.RafaelAinda não há avaliações
- 05 Lenovo Partner Hub - Catalogo de ProdutosDocumento59 páginas05 Lenovo Partner Hub - Catalogo de ProdutosItalo RochaAinda não há avaliações
- ItaguaciDocumento1 páginaItaguacifelipe salesAinda não há avaliações
- Os Formatos de Compressão de VídeoDocumento4 páginasOs Formatos de Compressão de VídeoAntonio Viegas SilvaAinda não há avaliações
- Configuração de senha e parâmetros do controlador de temperatura e umidadeDocumento2 páginasConfiguração de senha e parâmetros do controlador de temperatura e umidadeJose NathanAinda não há avaliações
- Exercicio Aula 3Documento3 páginasExercicio Aula 3VitorNantes100% (1)
- Conexao em Rede CAN-BusDocumento29 páginasConexao em Rede CAN-BusHelden EvertonAinda não há avaliações
- História - Dia Da MulherDocumento6 páginasHistória - Dia Da Mulhersequeira199Ainda não há avaliações
- Tecnologia em saúde e impactos na assistênciaDocumento83 páginasTecnologia em saúde e impactos na assistênciaElbert PeçanhaAinda não há avaliações
- A Historia Da Eletrônica AnalógicaDocumento25 páginasA Historia Da Eletrônica AnalógicaMussageAinda não há avaliações
- UltrassomDocumento9 páginasUltrassomRei da CopiaAinda não há avaliações
- Manual ATA-HA211-Ramais SipCodeDocumento16 páginasManual ATA-HA211-Ramais SipCodeacilonjsAinda não há avaliações
- Revisão de conceitos matemáticos básicosDocumento17 páginasRevisão de conceitos matemáticos básicosClaudio CarvalhinhoAinda não há avaliações
- Documento técnico sobre criação de parâmetro MV_NFPTER para informar qual cadastro de produto utilizar em NF-e de poder de terceiroDocumento3 páginasDocumento técnico sobre criação de parâmetro MV_NFPTER para informar qual cadastro de produto utilizar em NF-e de poder de terceiroTiago Garcia DiasAinda não há avaliações
- Certificado PressãoDocumento4 páginasCertificado PressãoAlcir GrohmannAinda não há avaliações
- Atividade 1 Unidade Curricular 15Documento2 páginasAtividade 1 Unidade Curricular 15Kassieli Joana Schuster de AguiarAinda não há avaliações
- Sistema Firjan Industria 4.0 Internet Coisas 2016Documento38 páginasSistema Firjan Industria 4.0 Internet Coisas 2016GabrielleMonteiroAinda não há avaliações
- KST ArcTech Basic 14 PTDocumento117 páginasKST ArcTech Basic 14 PTrenatobevAinda não há avaliações
- Manual de Automação Da Bomba Wayne - PDF Download GrátisDocumento16 páginasManual de Automação Da Bomba Wayne - PDF Download GrátisZilda Cristina De GrandiAinda não há avaliações
- Decidibilidade de linguagens e o problema da paradaDocumento13 páginasDecidibilidade de linguagens e o problema da paradacastellspAinda não há avaliações
- Cálculos Torque Parafusos Ligações FlangeadasDocumento9 páginasCálculos Torque Parafusos Ligações Flangeadasrhlinhares100% (2)
- Backtracking e Branch and BoundDocumento7 páginasBacktracking e Branch and BoundLameseMecatronicaAinda não há avaliações
- Redes de Computadores - Apostila 2021Documento79 páginasRedes de Computadores - Apostila 2021FRANCISCO ROBERTO DE SOUSA E SILVA100% (1)
- Semáforo inteligente como solução para mobilidade urbanaDocumento14 páginasSemáforo inteligente como solução para mobilidade urbanaryanAinda não há avaliações
- Pensamento Computacional: conceito, pilares e aplicaçõesDocumento71 páginasPensamento Computacional: conceito, pilares e aplicaçõesBeatriz AzulayAinda não há avaliações
