Usabilidade e Design de Interfaces
para uma Aplicação Web da Premium Minds
Francisco Fernandes Faia Villa De Brito
Julho, 2016
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.
À 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.
We can embrace the flexibility inherent to the web, without surrendering the control we require as designers.
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.
Í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
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”.
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.
PARTE I -‐ Contextualização
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
(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
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.
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,
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.
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.
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
(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
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.
PARTE II -‐ Projecto
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
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.
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
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
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.
