metodologias de projeto e avaliação do design de interação ... · • fazer um levantamento das...
TRANSCRIPT
MESTRADO EM MULTIMÉDIA
ESPECIALIZAÇÃO EM CULTURA E ARTES
Metodologias de Projeto e Avaliação do Design de Interação: Aplicação em contexto real por equipas de dimensão reduzida.
Mariana Owen
M 2016
FACULDADES PARTICIPANTES:
FACULDADE DE ENGENHARIA FACULDADE DE BELAS ARTES FACULDADE DE CIÊNCIAS FACULDADE DE ECONOMIA FACULDADE DE LETRAS
Metodologias de Projeto e Avaliação do Design de Interação:
Aplicação em contexto real por equipas de dimensão reduzida.
Mariana Owen
Mestrado em Multimédia da Universidade do Porto
Orientador: Miguel Carvalhais (PhD)
Setembro de 2016
© Mariana Owen, 2016
Metodologias de Projeto e Avaliação do Design de Interação:
Aplicação em contexto real por equipas de dimensão reduzida.
Mariana Owen
Mestrado em Multimédia da Universidade do Porto
Aprovado em provas públicas pelo Júri:
Presidente: Bruno Giesteira (PhD)
Vogal Externo: Pedro Amado (PhD)
Orientador: Miguel Carvalhais (PhD)
Resumo
Atualmente existe uma grande preocupação em criar produtos apelativos, que respondam às necessidades dos utilizadores, e que sejam fáceis de utilizar.
A literatura propõe a aplicação de várias metodologias centradas no utilizador durante o projeto de design de interação. Contudo, isto não significa que estas sejam aplicadas como dita a literatura ou usadas por todos os profissionais.
Vários autores referem as razões mais comuns para não serem aplicadas estas metodologias, no entanto, no universo de estudo, não existem estudos que façam referência às metodologias que realmente são postas em prática.
Esta dissertação surge do interesse sobre a discrepância entre a teoria e a prática, propondo-se estudar as metodologias de projeto e avaliação do design de interação aplicadas no contexto real por empresas de pequena dimensão localizadas no Grande Porto.
Foi utilizada a técnica de amostragem snowball e foram realizadas entrevistas presenciais semiestruturadas, das quais se conclui que existe uma preocupação com a usabilidade, embora a maioria dos entrevistados não realizem testes de usabilidade. WIREFRAMES, MOCKUPS e PROTÓTIPOS são as ferramentas mais utilizadas, e o feedback de clientes e utilizadores é tido como muito importante para a iteração e desenvolvimento dos produtos.
Palavras-chave: design de interação, metodologias de projeto, metodologias de avaliação, usabilidade.
Abstract
Currently there’s a great concern to create compelling products that meet the needs of users and are easy to use.
The literature proposes the use of several methodologies centered on the user during the interaction design project. However, this doesn’t mean that they are implemented as proposed by the literature or are used by all professionals.
Several authors report the most common reasons for not applying these methodologies, however, within the studied area, there are no studies that refer which methodologies are actually put into practice.
This dissertation arises form an interest in the discrepancy between theory and practice, proposing to study project and evaluation methodologies in the interaction design project that are applied in a real context by small companies and teams located in the Porto metropolitan area.
We used the snowball sampling technique and conducted in-person semi-structured interviews, from which we concluded that there is a concern with usability, even though most respondents do not perform usability tests. WIREFRAMES, MOCKUPS and PROTOTYPES are the most used tools, and feedback from customers and users is considered very important for the iteration and development of products.
Keywords: interaction design, project methodologies, evaluation methodologies, usability.
Agradecimentos
A todos os entrevistados, pelas excelentes conversas, sem os quais não teria sido possível a realização desta dissertação;
Ao professor Miguel Carvalhais, orientador desta dissertação, pelo apoio e paciência durante a realização deste trabalho;
Aos meus amigos pela motivação e por me aturarem;
Aos meus pais, que me apoiaram durante o meu percurso académico.
Mariana Owen
Índice
Introdução .................................................................................................................................. 13
Motivação e objetivos da investigação .................................................................................... 13
Metodologia de investigação ................................................................................................... 14
Estrutura da dissertação ........................................................................................................... 14
1. Revisão de Literatura ........................................................................................................ 17
1.1 Design de Interação ..................................................................................................... 17
1.1.1 Design Centrado no Utilizador ............................................................................ 17
1.2 Usabilidade .................................................................................................................. 18
1.3 Metodologias ............................................................................................................... 19
1.3.1 Avaliação Heurística ........................................................................................... 19
1.3.2 Personas ............................................................................................................... 20
1.3.3 Card Sorting ........................................................................................................ 22
1.3.4 Prototipagem ....................................................................................................... 23
1.3.4.1 Tipologias ........................................................................................................ 24
1.3.4.2 Prototipagem horizontal e vertical .................................................................. 24
1.3.4.3 Fidelidade ........................................................................................................ 24
1.3.5 Percurso Cognitivo .............................................................................................. 25
1.3.6 Teste de Usabilidade ........................................................................................... 25
1.3.7 Grupos de Foco ................................................................................................... 27
1.3.8 Testes Multivariados (MVT) e Testes A/B ......................................................... 27
1.3.9 Questionários ....................................................................................................... 28
1.3.9.1 System Usability Scale .................................................................................... 29
1.3.10 Entrevistas ........................................................................................................... 30
1.4 Síntese conclusiva ....................................................................................................... 30
2. Trabalho de Campo .......................................................................................................... 31
2.1 Metodologia ................................................................................................................ 31
2.2 Análise de dados.......................................................................................................... 32
2.2.1 Caracterização das equipas de trabalho ou empresas .......................................... 32
2.2.2 Metodologias do projeto de design de interação ................................................. 34
2.2.3 Contacto com utilizadores reais .......................................................................... 37
2.2.4 Avaliação da usabilidade ..................................................................................... 37
2.3 Tabela de síntese da caracterização da amostra .......................................................... 39
2.4 Análise e discussão dos dados ..................................................................................... 40
3. Conclusão ........................................................................................................................... 43
3.1 Satisfação dos objetivos .............................................................................................. 43
3.2 Limitações e trabalho futuro ....................................................................................... 44
Referências ................................................................................................................................. 45
4. Entrevistas ......................................................................................................................... 49
Introdução
Motivação e objetivos da investigação
Existe cada vez mais uma preocupação com o design de interação, a experiência do utilizador e a usabilidade dos sistemas computacionais. Contudo, isto não significa que os processos para lá chegar sejam aqueles que são aconselhados pela literatura, ou que todas as metodologias de design de interação e de avaliação de usabilidade sejam aplicadas por todos os profissionais.
Vários autores referem as razões mais comuns para não serem usadas determinadas metodologias e explicam de que forma contornar esses aparentes problemas. Empresas como a Cooper, a IDEO e a GV (anteriormente Google Ventures), publicam artigos ou relatórios periodicamente sobre as metodologias que põem em prática e a mais valia das mesmas. Contudo, estas não correspondem ao universo de estudo, no qual não existe esta informação.
No decorrer do percurso académico, surgiu a oportunidade de abordar, ainda que de forma não muito aprofundada, o projeto de design de interação e aplicar algumas das suas metodologias, assim como as referentes à avaliação da usabilidade. Foi ainda possível, separadamente, aplicar metodologias de gestão de projeto num projeto semestral, numa simulação de contexto real. Contudo, estas duas vertentes nunca se cruzaram no contexto académico, o que deixou em aberto como seria feita essa interseção.
Esta investigação surge então do interesse por esta distância entre a teoria e a prática, sendo que o seu principal objetivo é perceber quais as metodologias de projeto de design de interação e de avaliação da usabilidade que são postas em prática por equipas ou empresas de pequena dimensão e por que razão estas são ou não aplicadas.
Para responder a esta questão, propõe-se a seguinte metodologia:
• Fazer um levantamento das metodologias de projeto de design de interação e das metodologias de avaliação da usabilidade.
• Fazer um levantamento de equipas de trabalho ou empresas de pequena dimensão em diversas áreas de atuação e em projetos diferenciados.
• Realizar entrevistas presenciais a elementos das equipas ou empresas.
• Analisar os dados recolhidos através das entrevistas para perceber que metodologias são aplicadas e com que grau de formalidade.
14
Optou-se por circunscrever a área de trabalho ao Grande Porto por uma questão de conveniência e economia. No entanto, considerou-se que seria possível encontrar bastantes casos de estudo interessantes.
A escolha do estudo de equipas de pequena dimensão prende-se por várias razões. Primeiramente, a escolha era necessária para poder comparar estruturas semelhantes. Apesar de uma grande empresa poder incluir equipas de trabalho com poucos elementos, pela sua dimensão, espera-se que os seus processos sejam muito mais normalizados. Esta escolha deve--se também a uma maior facilidade de contacto com as empresas e possível aceitação por parte das mesmas.
Embora num contexto restrito, a relevância deste estudo prende-se com um maior conhecimento sobre as metodologias e processos usados, podendo ser continuado dentro da mesma localização geográfica, ou expandido a outras localizações, sendo que quantos mais casos de estudo, mais conclusões se poderão retirar.
Metodologia de investigação
A investigação consistiu na realização de entrevistas presenciais com elementos de equipas e empresas selecionadas a partir do método snowball. Os contactos iniciais foram feitos com colegas, amigos ou por intermediário de docentes, que por sua vez referenciaram novos contactos.
Optou-se por realizar entrevistas, uma metodologia qualitativa que permite alguma flexibilidade quer ao entrevistado, quer ao entrevistador. Em muitos casos foi possível expandir e clarificar algumas questões, ou aprofundar outras que não estavam previstas inicialmente. Tal não teria sido possível se tivesse sido realizado um questionário ou uma entrevista por escrito. Além disso, as entrevistas foram planeadas para cerca de meia hora, o que julga-se ter tido algum impacto na aceitação por parte dos entrevistados.
As entrevistas começaram por ser semiestruturadas, tendo por base um guião de entrevista que visava abordar tópicos como informação geral sobre a equipa ou empresa, área de atuação e tipo de projetos desenvolvidos, constituição das equipas de trabalho, metodologia e processos de trabalho, contacto com utilizadores reais (atuais ou potenciais), preocupação e avaliação da usabilidade.
À medida o guião se tornou mais familiar para o entrevistador, as entrevistas foram-se tornando mais informais, servindo o guião como um conjunto de tópicos a abordar, que eram introduzidos ao longo da conversa.
Estrutura da dissertação
Esta dissertação foi estruturada de forma a apresentar uma primeira parte teórica, introduzindo os conceitos do design de interação, usabilidade e metodologias de projeto e de avaliação da usabilidade, e uma segunda parte dedicada ao trabalho de campo.
O Capítulo 1 corresponde à revisão de literatura onde se aborda o conceito de design de interação, uma breve contextualização histórica e os seus princípios. Aborda-se o design
Introdução
15
centrado no utilizador e a sua importância e apresentam-se conceitos de usabilidade segundo vários autores, e a sua importância no contexto do desenvolvimento web.
São ainda descritas as metodologias de projeto e de avaliação de usabilidade existentes. É feito um estudo de cada metodologia, apresentando uma descrição, objetivos, benefícios e recursos necessários.
O Capítulo 2 trata do trabalho de campo, explicando a metodologia de investigação usada e no qual é feita uma análise dos dados recolhidos e são apresentadas as conclusões dessa análise.
Terminando com as conclusões no Capitulo 3, tenta-se correlacionar o que a teoria e a prática, nesta pequena amostragem de dados nos permite concluir e eventualmente extrapolar para uma realidade maior.
1. Revisão de Literatura
1.1 Design de Interação
Em 2002, numa entrevista, Gillian Smith, diretora do Instituto de Design de Interação de Ivrea, resume o design de interação como a disciplina que modela o nosso dia-a-dia através de artefactos digitais, para o trabalho, diversão e entretenimento. (cit. por Smith 2007, xi)
Numa definição mais ampla, o design de interação é “o design de tudo aquilo que é digital e interativo”, incluindo assim várias áreas como a Interação Humano-Computador, ciência da computação, engenharia de software, psicologia cognitiva, sociologia, antropologia cultural, e design. (Moggridge 2007, 660)
Alan Cooper et al. (2014, xix) definem o design de interação como a prática de projetar produtos digitais interativos, ambientes, sistemas e serviços. Primeiramente, o design de interação foca-se no design do comportamento, algo que normalmente não é explorado por disciplinas tradicionais do design.
O design de interação é algo inerentemente humanístico, preocupando-se em satisfazer as necessidades e desejos das pessoas que irão interagir com um produto ou serviço. Estes objetivos podem ser entendidos como narrativas lógicas e emocionais que progridem ao longo do tempo. Assim, os produtos digitais devem responder não só ao nível lógico e de inserção e apresentação de dados, mas também ao nível humano. (Cooper et al. 2014, xx)
1.1.1 Design Centrado no Utilizador
O Design Centrado no Utilizador é uma abordagem que dá destaque à perspetiva do utilizador durante o processo de design de interação. Ao focar-se nas necessidades e objetivos do utilizador, é possível desenvolver um produto que vá de encontro ao que o utilizador realmente pretende e oferecer uma experiência de utilização agradável. (Mesquita 2013, 60)
Segundo Ben Shneiderman (1998), aplicar esta abordagem durante a fase inicial do desenvolvimento do projeto, reduz dramaticamente o seu custo e tempo de desenvolvimento.
Cooper et al. (2014, xx) referem que quando os designers se focam nos objetivos dos utilizadores – as razões pela qual usam o produto em primeiro lugar – assim como nas suas expectativas, atitudes e aptidões, conseguem encontrar soluções que além de eficazes, sejam também agradáveis de usar.
18
1.2 Usabilidade
Jakob Nielsen (2012b) define a usabilidade como um atributo qualitativo que afere a facilidade de utilização de interfaces de utilizador. Usabilidade refere-se também aos métodos usados durante o processo de design que visam melhorar a facilidade de utilização de um produto.
Ainda segundo Nielsen (2012b), a usabilidade é composta por cinco componentes qualitativos:
1. Apreensibilidade: Quanta facilidade têm os utilizadores em atingir tarefas básicas na primeira vez que encontram a interface?
2. Efficiência: Após terem aprendido a interface, com que rapidez conseguem os utilizadores realizar as tarefas?
3. Memorabilidade: Ao voltar à interface após um período de não utilização, quão depressa conseguem os utilizadores reestabelecer proficiência?
4. Erros: Quantos erros cometem os utilizadores, qual a sua severidade, e com que facilidade conseguem recuperar destes erros?
5. Safisfação: Quão agradável é a utilização da interface?
Nielsen (2012b) refere ainda que a funcionalidade do produto é também uma qualidade importante, mas apenas conjugados permitem estudar a utilidade do produto.
Na Web – e por extensão, nas aplicações móveis – a usabilidade é uma questão de sobrevivência. Se o utilizador não sentir clareza e facilidade de uso, simplesmente desistirá de navegar a página ou utilizar a aplicação. Uma vez que existem muitas outras páginas e aplicações disponíveis, o utilizador irá procurar uma outra que atenda às suas necessidades (Nielsen 2012b).
Shneiderman (1998) apenas difere de Norman na semântica, identificando, em vez de atributos, cinco fatores humanos equivalentes aos identificados por Norman: velocidade de performance, tempo de aprendizagem, retenção ao longo do tempo, rácio de erros pelos utilizadores e satisfação subjetiva (Ribeiro 2012, 24).
Alan Dix et al. (2004) apresentam e expandem três atributos principais para a definição da usabilidade: capacidade de aprendizagem, flexibilidade e robustez (Ribeiro 2012, 24).
No artigo User-Centered Software Evaluation Methodologies, John Karat (cit. Por Sandro Tavares 2013), refere que a usabilidade de um sistema deriva diretamente da experiência tida pelo utilizador ao interagir com esse mesmo sistema. Essa experiência é influenciada pelo próprio sistema, mas é necessário compreender o contexto de utilização para avaliar a sua usabilidade.
A norma (ISO 9241-11 1998) suporta esta afirmação, definindo usabilidade como “a medida em que um produto pode ser usado por utilizadores específicos para atingir determinados objetivos com eficácia, eficiência e satisfação num contexto específico de uso”.
Revisão de Literatura
19
1.3 Metodologias
Centrando-se esta dissertação na descoberta de quais as metodologias de design de interação e de avaliação da usabilidade aplicadas no contexto real, existe a necessidade de fazer um levantamento das metodologias existentes e fazer a sua análise segundo a literatura.
Nesta secção são listadas e analisadas as principais metodologias, de acordo com vários autores. É feita uma descrição do objetivo e processo de cada metodologia, salientando-se os benefícios, vantagens e desvantagens.
Procura-se assim informar o lado teórico, que no capítulo 2 será confrontado com a aplicação prática, conforme os casos de estudo.
1.3.1 Avaliação Heurística
A AVALIAÇÃO HEURÍSTICA é um método de inspeção usado para identificar problemas de usabilidade no design da interface do produto. Uma equipa de especialistas examina a interface e avalia a sua conformidade com princípios de usabilidade reconhecidos, as Heurísticas de Usabilidade, primeiramente definidas por Nielsen e Molich em 1990 (cit. por Nielsen 1995):
1. Visibilidade do estado do sistema O sistema deve manter os utilizadores sempre informados sobre o que está a acontecer, através de feedback apropriado.
2. Compatibilidade do sistema com o mundo real Deve ser usada linguagem que seja familiar ao utilizador, ao invés de termos orientados ao sistema. Devem ser seguidas convenções do mundo real, apresentado a informação de forma natural e por uma ordem lógica.
3. Controle e liberdade do utilizador Ao cometer um erro, os utilizadores procuram desfazê-lo rapidamente sem ter de navegar vários diálogos. Estas “saídas de emergência” devem estar bem assinaladas, sendo aconselhável o suporte dos comandos “desfazer” e “refazer”.
4. Consistência e uso de padrões Os utilizadores não devem colocar em dúvida se diferentes palavras, situações ou ações têm o mesmo significado. Devem ser seguidas as convenções da plataforma.
5. Prevenção de erros Melhor que uma mensagem de erro é um sistema que previne que o erro ocorra. Uma forma de o fazer é removendo condições propensas a erro, ou então fazer uma verificação e apresentar uma opção de confirmação aos utilizadores antes de estes realizarem a ação.
6. Reconhecimento em vez de lembrança Para minimizar a sobrecarga de memória do utilizador, os objetos, ações e opções devem estar visíveis. O utilizador não deve ser obrigado a relembrar informação de uma parte do diálogo para outra. As instruções de utilização do sistema devem estar visíveis ou ser facilmente acedidas sempre que apropriado.
20
7. Flexibilidade e eficiência de utilização Deve ser permitida a criação de atalhos para tarefas frequentes. Os aceleradores – invisíveis para o utilizador inexperiente – permitem ao utilizador experiente acelerar certas interações.
8. Design e estética minimalista Os diálogos devem conter apenas a informação relevante e necessária. Toda a informação extra irá competir com o conteúdo importante, reduzindo a sua visibilidade relativa.
9. Ajudar o utilizador a reconhecer, diagnosticar e resolver problemas As mensagens de erro devem ser expressas em linguagem simples (sem terminologia técnica), indicar o erro de forma precisa e sugerir uma solução de forma construtiva.
10. Ajuda e Documentação Embora seja preferível que um sistema possa ser usado sem documentação, pode ser necessário providenciar ajuda e documentação. Essa informação deve ser fácil de pesquisar, focada na tarefa do utilizador, listar passos concretos a executar, e não ser demasiado extensa.
Numa AVALIAÇÃO HEURÍSTICA, os avaliadores analisam o sistema individualmente, comentando o cumprimento ou não das heurísticas.
No final, os avaliadores comparam os resultados obtidos e elaboram um relatório final onde são compilados os problemas encontrados, com referência às heurísticas não cumpridas, e priorizados por grau de severidade.
A AVALIAÇÃO HEURÍSTICA é um método de inspeção bastante informal e com uma relação benefício/custo bastante alta, sendo por isso particularmente apropriado para o método da “Usabilidade de Guerrilha” proposto por Nielsen (1994).
Estudos demonstram que 3 a 5 especialistas são suficientes para a avaliação de uma interface do utilizador (Nielsen 1995).
Embora se recomende recorrer a especialistas para este tipo de avaliação, membros da equipa poderão fazê-la, desde que estejam familiarizados com o produto e a metodologia. Neste caso aconselha-se que a avaliação seja realizada por mais de 5 avaliadores (Raila Äijö e Mantere 2001).
O PERCURSO HEURÍSTICO é um híbrido entre o PERCURSO COGNITIVO (ver 1.3.5) e a Avaliação Heurística, em que o avaliador analisa o cumprimento das Heurísticas com base nos cenários de contexto previstos para o sistema. Segundo Andrew Sears, no artigo Heuristic Walkthroughs: Finding the Problems Without the Noise (cit. por Ribeiro 2012, 56), ao focar-se exclusivamente nas tarefas do utilizador, este método permite encontrar mais problemas de usabilidade e reduzir falsos positivos que possam ocorrer na AVALIAÇÃO HEURÍSTICA.
1.3.2 Personas
Uma PERSONA é uma representação fictícia, mas realista de um grupo de utilizadores do produto. Parte duma abordagem centrada no utilizador e da investigação dos utilizadores potenciais reais de um produto ou sistema, através de técnicas como a investigação etnográfica, entrevistas, inquéritos, sondas culturais e sintetiza as necessidades, características,
Revisão de Literatura
21
comportamentos, motivações e objetivos de utilizadores reais encontrados na investigação (Santos 2012, 9–10).
Para serem credíveis, a sua descrição deve conter também dados como nome, idade, fotografia e ocupação1. A credibilidade das PERSONAS é importante para que seja criada empatia e possam guiar o design do sistema em direção aos seus objetivos. As PERSONAS permitem que os designers se sintam conectados com os utilizadores reais (Santos 2012, 11).
Às PERSONAS são associados cenários: narrativas resumidas sobre o modo de utilização do sistema de modo a atingir determinado objetivo. Os dados para a construção dos cenários advêm da investigação feita anteriormente e dos primeiros atos de design, de projetar comportamentos esperados por parte dos utilizadores e do sistema. Ao construir as PERSONAS e os cenários, permite-se focar o design na experiência do utilizador em vez de objetivos tecnológicos ou de negócio (Tavares 2013, 85).
Existem vários tipos de cenários2: os cenários de contexto focam-se na perspetiva da PERSONA e na sua interação com o produto em função dos seus objetivos, sem entrar em detalhes sobre a interface; os cenários de percurso são elaborados após a definição dos elementos funcionais e da framework de design e, com o vocabulário da framework, descrevem passo-a-passo as interações principais e caminhos seguidos pelo utilizador; os cenários de validação detalham interações menos frequentes, com o objetivo de tentar encontrar e corrigir falhas que possam quebrar o design do produto3 (Tavares 2013, 85–86).
A personificação do utilizador-tipo promove a empatia4 por parte dos designers e developers em torno dos objetivos dos utilizadores, o que os ajuda a criar soluções que melhor sirvam as reais necessidades dos mesmos (Cooper et al. 2014, 66).
O uso de PERSONAS permite ainda comunicar com clareza, dentro da equipa e a stakeholders, acerca dos grupos de utilizadores para quem está a ser desenvolvido o produto.
As PERSONAS são construídas com base na investigação dos utilizadores reais. Segundo Cooper et al. (2014, 66–67), os principais métodos de recolha desta informação devem recorrer à observação e diálogo com atuais e potenciais utilizadores, como entrevistas ou inquéritos contextuais.
Contudo, por vários motivos, nem sempre é possível fazer este trabalho de investigação. Neste caso podem ser elaboradas PERSONAS provisórias5, também chamadas PERSONAS ad-hoc, com base em dados já existentes e completadas com suposições da equipa sobre os comportamentos, motivações e objetivos dos utilizadores. Cooper et al. (2014, 97) alertam para os potenciais erros derivados destas suposições e propõe que se deixe clara a natureza provisória destas PERSONAS, documentando a origem dos dados utilizados e que suposições foram feitas.
1 Hugo Ribeiro (2012, 47–48) e Gonçalo Machado (2013, 49–52) apresentam o processo de desenvolvimento das
PERSONAS de acordo com Cooper, Reimann, e Cronin (2007). Identificam os principais passos necessários para identificar e categorizar os padrões de comportamento dos utilizadores, os dados que deve conter um perfil de carácter da PERSONA, e descrevem os diferentes objetivos das PERSONAS. Tavares (2013, 78–80) apresenta com maior detalhe o processo de modelação das PERSONAS, de acordo com vários autores.
2 Machado (2013, 51–52) descreve em maior detalhe o processo de criação dos cenários. 3 Este conceito de cenário no âmbito do Design de Interação assemelha-se ao conceito de USER STORY (História do
Utilizador) e USE CASE (Caso de Uso) no âmbito da Engenharia de Software. 4 Norman (2004) explora a importância da empatia no processo de design e desenvolvimento de um produto, dando
exemplos da sua experiência enquanto consultor, mais concretamente de sessões em que realiza exercícios de criação de PERSONAS ad-hoc.
5 Ivo Santos (2012, 11–12) aprofunda o conceito, com base em Norman (2004) e Tamara Adlin (2007a).
22
As PERSONAS data-driven6 são criadas exclusivamente com dados recolhidos. O processo proposto por Jennifer McGinn e Kotamraju (2008) pretende colmatar falhas no processo tradicional de elaboração de PERSONAS, tornando-o mais rápido e económico. Caracteriza-se por uma inversão da ordem das atividades, em que a equipa define quais os atributos importantes das PERSONAS, seguindo-se um inquérito a pessoas com esses atributos. A partir dos resultados é realizada uma análise fatorial de onde surgem os grupos de PERSONAS. Por fim estes grupos são ajustados e validados com recurso a entrevistas a pessoas representativas de cada um.
Cooper et al. (2014, 87–90) identificam seis tipos de PERSONAS – primárias, secundárias, complementares, clientes, servidas e negativas – que correspondem a grupos de utilizadores com necessidades e objetivos semelhantes. As tipologias7 definem uma hierarquia, sendo que a PERSONA primária constitui o principal público-alvo da interface, cujas necessidades devem ser cumpridas na totalidade.
As PERSONAS podem ainda ser usadas como ferramenta básica de inspeção da usabilidade, confrontando o sistema com os objetivos e necessidades das PERSONAS, mas nunca substituem utilizadores reais (Ribeiro 2012, 48–49).
1.3.3 Card Sorting
O CARD SORTING é uma técnica útil para avaliar e refinar o agrupamento lógico da informação e terminologia de um produto.
É útil no que toca à arquitetura da informação, permitindo perceber de que forma os utilizadores agrupam e interpretam termos e conceitos. Não serve, no entanto, como instrumento de análise da usabilidade.
Numa sessão de CARD SORTING é entregue ao participante um grupo de cartões, com um termo ou expressão em cada um, e é-lhe pedido que agrupe os cartões de acordo com a tipologia escolhida.
Existem três tipologias8 de CARD SORTING que são aplicadas com objetivos diferentes:
• Aberto: São entregues dois conjuntos de cartões: um conjunto com termos ou conceitos relacionados com o produto, e outro conjunto em branco. É pedido aos participantes que agrupem por semelhança os cartões que contém termos. Pode ainda ser pedido que agrupem estes grupos em grupos maiores. No final é pedido que usem os cartões em branco para atribuir um nome ou descrição geral a cada grupo.
• Fechado: Esta tipologia é semelhante à anterior, mas os nomes dos grupos já se encontram definidos. É pedido aos participantes que distribuam os cartões com os termos e conceitos pelos grupos predefinidos. Um card sorting fechado é usado frequentemente para validar resultados de um card sorting aberto, uma ver que permite que os nomes dos grupos sejam testados.
• Inverso: Neste CARD SORTING, os participantes recebem vários grupos de cartões, sem ordem específica e é-lhes pedido que os organizem num caminho linear que
6 Santos (2012, 12) aprofunda o conceito, com base em Adlin (2007b) e McGinn e Kotamraju (2008). 7 Ribeiro (2012, 46–47), Tavares (2013, 80–81) e Catarina Mesquita (2013, 78) descrevem as tipologias de PERSONAS,
de acordo com Cooper, Reimann, e Cronin (2007). 8 Ribeiro (2012, 49–50) aprofunda a definição e objetivos de cada tipologia.
Revisão de Literatura
23
represente os passos necessários para cumprir determinada tarefa. Esta técnica é útil para validar os resultados do CARD SORTING aberto e fechado e é eficiente em todos os níveis da hierarquia do sistema.
Quando aplicadas no mesmo projeto, na sequência referida, servem como sistema de validação dos resultados das tipologias de CARD SORTING anteriores.
O CARD SORTING é uma técnica fácil e barata de realizar, podendo ser realizada com papel e caneta ou recurso a software9.
A dificuldade do CARD SORTING está na leitura e interpretação dos resultados, sendo necessário recorrer a um analista experiente. Dada a natureza quantitativa dos resultados, estes podem ser enganadores e tendenciosos, sendo aconselhável realizar uma análise qualitativa paralela, pedindo aos participantes que expliquem as suas decisões (Ribeiro 2012, 51).
Baseado no estudo de Tom Tullis e Wood (2004), Nielsen (2004) recomenda que o CARD SORTING seja realizado com 15 utilizadores, com os quais se obtem 90% de certeza que os resultados correspondem ao modelo mental formado pelos utilizadores. Hugo Ribeiro (2012, 51) considera que realizar 5 testes, obtendo uma garantia de 75%, poderá ser aceitável em projetos de pequena ou média dimensão.
1.3.4 Prototipagem
No design de interação, os PROTÓTIPOS são representações visuais da interface do sistema. Podem ser desenvolvidos ao longo de todo o projeto, com recurso a diversas ferramentas, evoluindo em complexidade e fidelidade, consoante o seu propósito e a fase do projeto.
Todd Warfel (2009, 106–107) considera que, na escolha do método ou ferramenta de PROTOTIPAGEM, devem ser ponderados uma série de fatores, como audiência, objetivo do PROTÓTIPO, familiaridade e capacidade de aprendizagem, custo, colaboração, distribuição, descartável ou reutilizável.
Consoante a fase do projeto e o objetivo do PROTÓTIPO, este pode ser desenvolvido usando diversas ferramentas, desde papel, ferramentas de design, software que permita simulação de fluxos de interação, ou até versões alfa do sistema final (Ribeiro 2012, 52).
Embora se possa considerar que a PROTOTIPAGEM como a criação de PROTÓTIPOS, Warfel (2009, 28–30) aborda-a enquanto processo iterativo e evolutivo, exemplificando com o processo usado na sua empresa10, que passa por: criação de ESBOÇOS, apresentação e crítica, modelação (criação de PROTÓTIPOS) e avaliação. Salienta os ESBOÇOS como parte essencial do processo e identifica o ciclo esboçar, apresentar, criticar, como forma de iterar rapidamente sobre um produto.
9 Ribeiro (2012, 51) enuncia software nativo de card sorting assim como ferramentas online. 10 Um esquema desde processo pode ser visualizado em: https://www.flickr.com/photos/rosenfeldmedia/3978302604/.
24
1.3.4.1 Tipologias
Vários autores11 identificam tipologias de PROTÓTIPOS12 de acordo com a sua fidelidade e funcionalidade: MOCKUPS, WIREFRAMES, STORYBOARDS e PROTÓTIPOS interativos.
Ribeiro (2012, 52) refere que os PROTÓTIPOS não são inerentemente interativos, do que Warfel (2009, xii) discorda, considerando que um PROTÓTIPO simula múltiplos estados de um sistema, diferenciando-o de representações estáticas como WIREFRAMES e STORYBOARDS13.
Warfel (2009, 71) propõe cinco tipologias de PROTÓTIPOS tendo em conta o seu propósito: criar uma comunicação partilhada, desenvolver o projeto de design, vender internamente uma ideia, realizar TESTES DE USABILIDADE ou medir a viabilidade técnica e valor do projeto.
1.3.4.2 Prototipagem horizontal e vertical
A PROTOTIPAGEM horizontal representa apenas as funcionalidades de primeiro nível. Serve para testar e analisar a navegação principal e deve representar o resultado inicial desse primeiro nível (Ribeiro 2012, 52).
A PROTOTIPAGEM vertical representa a progressão no sistema para completar determinada tarefa, permitindo que o utilizador interaja com a estrutura hierárquica de determinada função (Ribeiro 2012, 52).
1.3.4.3 Fidelidade
Os PROTÓTIPOS podem ser de baixa ou alta fidelidade consoante o nível de detalhe, funcionalidade, similaridade de interação e aproximação estética (Ribeiro 2012, 52).
Os PROTÓTIPOS de baixa fidelidade são representações simples e pouco detalhadas, podendo apresentar apenas um esboço da interface. São úteis nas fases iniciais do projeto por permitirem uma maior experimentação e serem facilmente alterados.
Os PROTÓTIPOS de alta fidelidade representam com grande fidelidade e detalhe a interface do sistema, mostrando o design da interface.
Warfel (2009, 74–75) considera que a fidelidade dos PROTÓTIPOS é uma escala e que não deve haver uma preocupação com alta ou baixa fidelidade. O nível de fidelidade adequado é aquele que cumpre o objetivo para com a audiência do PROTÓTIPO.
11 Ribeiro (2012, 52–53), Tavares (2013, 90–93), Helena Dourado (2014, 23–24) e Jodie Moule (2012, 162–166). 12 Dourado (2014, 23–24) descreve em maior detalhe as várias tipologias, de acordo com Debbie Stone et al. (2005),
Russ Unger e Chandler (2009) e Moule (2012, 162–166). 13 “A prototype, regardless of its fidelity, functionality, or how it is made, captures the intent of a design and simulates
multiple states of that design. Wireframes and storyboards are static representations of a design that on their own merit do not simulate multiple states of a design. It’s the simulation and multiple states part that creates the distinction.” (Warfel 2009, xii)
Revisão de Literatura
25
1.3.5 Percurso Cognitivo
O PERCURSO COGNITIVO é um método de inspeção, que consiste em percorrer uma série de tarefas no sistema e colocar um conjunto de questões sob a perspetiva do utilizador, com o objetivo de perceber o processo de aprendizagem de utilizadores novos ou infrequentes.
Normalmente esta avaliação é realizada por especialistas, podendo, no entanto, ser feita por membros da equipa que estejam familiarizados com a metodologia.
As tarefas a executar devem ser estabelecidas e descritas previamente, podendo ser elaboradas através dos cenários de contexto das PERSONAS. Após serem determinadas, estas devem ser divididas em passos, e em cada passo devem ser feitas as perguntas definidas por Cathleen Wharton et al. (1994, 112), para identificar em que momentos a interface não fornece ao utilizador informação suficiente para que este consiga completar a tarefa. (Ribeiro 2012, 54–55):
• O utilizador irá tentar atingir o resultado correto?
• O utilizador irá notar que a ação correta está disponível?
• O utilizador irá associar a ação correta ao resultado que tenta atingir?
• Se o utilizador executar a ação correta, poderá ver que está a efetuar progresso em direção à solução da tarefa?
No final é elaborado um relatório no qual são salientadas as tarefas que não foram concluídas com sucesso, explicando onde e porque é que os utilizadores poderão não conseguir completar a tarefa. Este documento permite compreender e melhorar o processo de aprendizagem do sistema.
Esta metodologia é eficaz na deteção de problemas nas tarefas mais comuns, mas falha na deteção de problemas resultantes de tarefas mais específicas, uma vez que tendem a não ser abrangidas neste método (Machado 2013, 60).
Não existindo o envolvimento de utilizadores, não se garante a fiabilidade dos resultados, sendo aconselhável realizar um TESTE DE USABILIDADE posteriormente (Ribeiro 2012, 55).
Esta metodologia só pode ser aplicada numa fase mais avançada do projeto, pois requer um PROTÓTIPO de boa qualidade (Machado 2013, 60; Shneiderman 1998).
1.3.6 Teste de Usabilidade
Os TESTES DE USABILIDADE consistem na observação da interação de um indivíduo com um sistema enquanto este realiza determinadas tarefas. Este método permite identificar partes da interface que são mais confusas ou frustrantes para os utilizadores, de forma a serem alteradas e testadas novamente antes do lançamento (Martin e Hanington 2012, 194).
Os TESTES DE USABILIDADE podem ser realizados em conjunto com outras metodologias e ao longo de todo o desenvolvimento do projeto, independentemente do tipo ou fidelidade dos PROTÓTIPOS, desde PROTÓTIPOS iniciais em papel a versões funcionais, próximas da implementação. Podem ainda ser realizados testes com versões implementadas, e mesmo após o lançamento (Ribeiro 2012, 58).
26
Steve Krug (2009, 13) refere que os TESTES DE USABILIDADE podem “ter muitas variedades”14 e uma forma de os categorizar é distingui-los entre testes quantitativos e qualitativos15.
Em testes qualitativos pretende-se provar algo, medindo coisas como taxa de sucesso ou tempo despendido numa tarefa. Para obter resultados fiáveis, os testes devem ser rigorosos e seguir o mesmo protocolo com todos os participantes. O número de participantes deve ser suficientemente alargado e representativo dos utilizadores reais para que os resultados sejam estatisticamente relevantes. Nestes testes, normalmente, tenta-se minimizar a interação com o participante para evitar influenciar o resultado.
Nos testes qualitativos o objetivo é recolher opiniões sobre o uso do sistema para o poder melhorar. Neste sentido, os testes podem ser muito mais informais, não é necessário seguir um protocolo rigoroso e podem ser usados menos participantes. O facilitador conduz o teste, pedindo ao participante que realize um conjunto de tarefas, expressando em voz alta o seu pensamento, aquilo a que é chamado de Think Aloud Protocol.
Através das técnicas de Usabilidade de Guerrilha, Nielsen (1989, 1994, 1997a) considera que é importante testar frequentemente o sistema ao longo do projeto, referindo que os métodos usados devem ser simples e fáceis o suficiente para que sejam postos em prática, e que é possível conduzir TESTES DE USABILIDADE a custos reduzidos e com um elevado grau de custo/benefício (1994), sem que para isso fosse necessário utilizar um laboratório de usabilidade com todo o equipamento necessário. Embora, na sua essência, sejam o mesmo, Krug (2014) faz a distinção entre Teste Tradicional e Teste Informal16, tornando claras as diferenças entre si. (Ribeiro 2012, 58).
Antes de realizar os TESTES DE USABILIDADE, é necessário estabelecer o que se pretende do mesmo, as tarefas a serem realizadas, que questões se pretendem ver respondidas no final do teste e num questionário a responder no final da sessão. As tarefas a realizar pelos participantes devem ter em conta os objetivos típicos dos utilizadores, podendo ser baseadas nos cenários definidos na construção das PERSONAS (Ribeiro 2012, 59).
A realização do teste é acompanhada por um facilitador, que indica ao participante as tarefas a executar, encorajando-o a pensar em voz alta, permitido perceber em que pontos é que existe dificuldade na interação e porquê. Ao mesmo tempo um ou mais observadores assistem ao teste e tiram notas, que no final são discutidas entre a equipa17 (Ribeiro 2012, 59–60).
Segundo Nielsen (2000, 2012a), para a maioria dos projetos, cinco utilizadores serão suficientes para encontrar 75% dos potenciais erros. No caso de projetos com custos reduzidos, pode ser adequado testar apenas dois utilizadores por estudo. Noutros projetos, podem ser necessários oito utilizadores ou mais.
Os TESTES DE USABILIDADE podem ainda ser realizados remotamente, o que pode trazer algumas vantagens, sendo a principal a de permitir live recruiting, o recrutamento de utilizadores no momento em que estes realizam uma tarefa de interesse. Isto faz toda a diferença na motivação dos participantes, uma vez que estão a realizar a tarefa pelas suas razões e não porque lhes é indicado (Bolt e Tulathimutte 2010, 15–16).
14 “There are a lot of diferent ‘flavors’ of usability testing, …” 15 “One useful way to categorize all the different flavors is by thinking of them as either quantitative or qualitative.” 16 Krug apresenta uma tabela comparativa em (2014, , em “Do-it-yourself usability testing”). 17 Ribeiro (2012, 59–61) aprofunda o processo dos TESTES DE USABILIDADE.
Revisão de Literatura
27
Os testes remotos têm outros benefícios, como a diversidade geográfica dos participantes, a possibilidade de testar em quase qualquer lado, alguns custos reduzidos, maior rapidez na preparação dos testes, e a possibilidade de testar interfaces dependentes do contexto (Bolt e Tulathimutte 2010, 20–23).
Estes testes podem ser moderados ou automatizados. Os testes moderados são também chamados de “síncronos”, uma vez que os participantes, facilitador18 e observadores estão presentes ao mesmo tempo. O facilitador interage diretamente com os participantes, podendo esclarecer alguma dúvida, encorajar os participantes a expressar em voz alta os seus pensamentos, e sondar os utilizadores sobre assuntos que surjam durante a sessão, permitindo explorar comportamentos que não tenham sido previstos durante o planeamento do teste (Bolt e Tulathimutte 2010, 36; Schade 2013).
Nos testes automatizados o investigador não tem contacto direto com os participantes. Contudo, ferramentas e serviços para realização de testes remotos permitem incluir questões complementares após cada tarefa ou no final da sessão. Neste caso não existe a possibilidade de esclarecer dúvidas ao participante ou fazer perguntas detalhadas, e embora se possa pedir ao participante que expresse o seu pensamento em voz alta, num teste automatizado não será possível relembrá-lo se este não o fizer (Schade 2013). Este tipo de teste é feito de forma assíncrona: é planeado e iniciado o teste, os participantes executam as tarefas, e só após todos terminarem é que os dados são recolhidos e analisados (Bolt e Tulathimutte 2010, 37).
1.3.7 Grupos de Foco
Os GRUPOS DE FOCO são um método de investigação que ajuda ao conhecimento das opiniões, perceções, sentimentos, motivações e desejos de um grupo utilizadores (normalmente 6 a 9) representativos do público-alvo (Nielsen 1997b).
O poder dos GRUPOS DE FOCO está na dinâmica que é criada quando o grupo é orientado por um facilitador experiente (Martin e Hanington 2012, 92). Um bom facilitador consegue obter a melhor participação de todos, levando a que expressem as suas opiniões, e pontos de vista por vezes não ocorridos anteriormente ao investigador.
Um dos problemas potenciais com os GRUPOS DE FOCO é o “pensamento coletivo”, que faz com que utilizadores individuais acabem por concordar com a opinião geral, em vez de expressarem uma opinião pessoal. Uma forma de tentar minimizar este efeito é propor aos utilizadores a realização de uma tarefa prévia, para que possam começar a pensar e a formar uma opinião pessoal antes de conhecerem as opiniões dos restantes participantes (Usability First 2013).
1.3.8 Testes Multivariados (MVT) e Testes A/B
Os TESTES MULTIVARIADOS e TESTES A/B (também conhecidos como split testing ou bucket testing), pretendem comparar diferentes versões de um sistema ou projeto e verificar qual tem melhor desempenho, de acordo com métricas pré-definidas. Permitem validar decisões de design e melhorar a taxa de conversão de utilizadores.
18 O facilitador é alguém que conduz a discussão, responsável por manter uma conversa dinâmica sobre as questões a
abordar.
28
Nielsen (2005) identifica várias limitações neste tipo de teste: só permite medir objetivos muito concretos e mensuráveis por computador, apenas funciona com sistemas já implementados, foca-se em resultados a curto prazo, e não se obtém conhecimento sobre o comportamento e motivações dos utilizadores.
O processo inicia-se com a recolha de informação sobre a utilização do sistema, de forma a identificar os objetivos de conversão. Estes podem ser muito variados, como fazer uma compra num site de e-commerce, subscrever uma newsletter ou criar uma conta.
Definidos os objetivos, a equipa pode começar a gerar hipóteses do que pode ser alterado para atingir esses mesmos objetivos. Em seguida criam-se as variações desejadas, que devem ser testadas para ter a certeza que funcionam como esperado.
O teste é então implementado, manualmente ou com recurso a ferramentas ou serviços próprios. Os utilizadores são dirigidos aleatoriamente para uma das versões e as suas interações são medidas e contabilizadas, para serem analisadas. As ferramentas existentes facilitam a construção, implementação e análise dos testes, mostrando a diferença no desempenho de cada versão e se essa diferença é estatisticamente significativa.
Os TESTES A/B são o método mais simples: testam apenas uma variável e normalmente duas versões, embora possam ser testadas mais. No caso de um site, podem ser testadas variações em elementos individuais (botão, título, call to action, formulário…), ou diferentes direções do design, apresentando duas versões completamente diferentes, sendo que neste tipo de teste é avaliado o impacto do design como um todo.
Os TESTES MULTIVARIADOS usam a mesma mecânica, mas são alterados vários elementos ao mesmo tempo, permitindo extrair mais informação sobre a forma como estes elementos interagem entre si. Por exemplo, com três versões de um título e duas versões de uma imagem obtêm-se seis combinações diferentes.
Uma vez que em testes multivariados o número de combinações cresce rapidamente, é aconselhado serem usados em páginas com tráfego diário elevado (Farmer 2009). Caso o tráfego não seja suficiente para recolher uma amostra significativa, será preferível realizar múltiplos TESTES A/B.
1.3.9 Questionários
Os QUESTIONÁRIOS são uma forma simples de recolha de informação, primariamente quantitativa, através de um conjunto de questões específicas.
A sua criação e administração é simples, mas deve-se ter em atenção a forma como são colocadas as questões e as opções de resposta, de forma a não influenciar a resposta dos participantes e conseguir obter dados relevantes para o objetivo do QUESTIONÁRIO. Deve haver ainda um cuidado com a clareza das perguntas e respostas, uma vez que no caso de ser administrado remotamente, o participante não poderá pedir ajuda.
A administração remota de QUESTIONÁRIOS permite recolher uma grande quantidade de dados em pouco tempo e possibilita a seleção de participantes dispersos geograficamente (Santos 2012, 5).
Os QUESTIONÁRIOS podem incluir questões de resposta aberta, fechada, ou uma combinação de ambas.
Revisão de Literatura
29
Nas questões de resposta fechada, são dadas duas ou mais opções de escolha, não sendo permitido ao participante desenvolver a sua resposta. São questões simples, não são muito trabalhosas para o participante, e podem ter apenas opções de sim ou não, múltiplas respostas ou uma escala para poderem escolher a opção que mais se aproxima da sua opinião (Honrado 2015, 48).
Nas questões de resposta aberta, os participantes escrevem as suas próprias respostas a perguntas. Este tipo de questões é útil quando o investigador pretende recolher as opiniões e argumentos dos participantes. Contudo, é preciso ter em atenção que as perguntas de resposta aberta são mais trabalhosas de analisar e categorizar, pelo que é aconselhável limitar o número de QUESTIONÁRIOS ou o número de questões abertas (Honrado 2015, 48).
Existem alguns QUESTIONÁRIOS criados especificamente para a medição da utilidade, facilidade de uso e avaliação da usabilidade de um sistema, como um QUESTIONÁRIO que mede a aceitação da tecnologia, baseado no TAM (Technology Acceptance Model), o SUPR-Q (Standardized Universal Percentile Rank-Questionnaire), criado especificamente para websites e que contém questões que eficazmente substituem o SUS (Sytem Usability Scale) (ver 1.3.9.1), um questionário destinado à avaliação da usabilidade de um produto (Sauro 2011b).
1.3.9.1 System Usability Scale
O SYSTEM USABILITY SCALE (SUS) é o questionário mais usado para medir a perceção da usabilidade.
Foi criado por John Brooke em 1986 com o objetivo de ser para ser administrado após a realização de TESTES DE USABILIDADE, é independente da tecnologia, tendo sido testado em hardware, software, websites, telemóveis, IVRs (Interactive Voice Response), e até as Páginas Amarelas (Sauro 2011a).
É composto por 10 perguntas com 5 opções de resposta, numa escala de “Concordo Totalmente” a “Discordo Totalmente”.
É um método eficaz que permite obter resultados fiáveis mesmo com amostras reduzidas.
Contudo, o sistema de pontuação e interpretação são algo complexos. A pontuação final é apresentada numa escala de 0 a 100, mas este valor não deve ser interpretado como sendo uma percentagem.
Os estudos revelam que o valor médio para a pontuação SUS é 68, sendo que tudo acima de 68 é considerado acima da média, e tudo abaixo é considerado abaixo da média.
A forma mais fácil de interpretar os resultados consiste em converter os resultados para percentil, através de um processo chamado normalização. Este processo é semelhante à classificação em curva (Sauro 2011a).
O SUS não determina problemas de usabilidade no sistema, apenas o classifica de acordo com a facilidade de utilização percecionada pelos utilizadores
30
1.3.10 Entrevistas
Em semelhança aos QUESTIONÁRIOS, as ENTREVISTAS são um método direto de aceder às características do utilizador. Enquanto que os métodos quantitativos nos permitem recolher informação de um maior grupo de utilizadores, as ENTREVISTAS, pela sua natureza qualitativa, permitem uma recolha de mais informação acerca de um só utilizador (Santos 2012, 5).
Comparativamente aos QUESTIONÁRIOS, as ENTREVISTAS requerem mais tempo para serem realizadas e analisadas, mas permitem uma maior flexibilidade, sendo indicadas para estudos exploratórios. Permitem ao entrevistador explicar melhor a pergunta caso esta não tenha sido compreendida e colocar questões que não tenham sido previstas anteriormente. Por sua vez, o entrevistado pode clarificar ou expandir as suas respostas (Nielsen 1993).
Patton, na obra Qualitative Research & Evaluation Methods (cit. por Tavares 2013, 52), identifica três modos de efetuar ENTREVISTAS:
• Estruturada: uma ENTREVISTA padrão, em a conversação é efetuada por meio de questões previamente definidas.
• Semiestruturada: o entrevistador tem o tema definido e a conversação gira à sua volta.
• Não estruturada: numa conversa informal, o entrevistador coloca questões em aberto para os entrevistados responderem abordando o tema da maneira como lhes parece mais relevante. Neste caso o entrevistador terá de ser suficientemente experiente para não deixar a conversa desviar-se do tema.
1.4 Síntese conclusiva
Neste capítulo apresentaram-se os conceitos de Design de Interação, Design Centrado no Utilizador e Usabilidade, destacando a importância de ter o utilizador como foco principal no processo de design de interação.
Abordaram-se as principais metodologias de projeto e avaliação de usabilidade do design de interação, salientando as suas mais valias. Nielsen e Krug propõe formas mais informais de aplicar algumas das metodologias, referindo – em relação a testes de usabilidade – que qualquer teste é melhor que nenhum teste.
Trabalho de Campo
31
2. Trabalho de Campo
2.1 Metodologia
Neste estudo optou-se por entrevistar equipas de trabalho e empresas de dimensão reduzida localizadas no Grande Porto.
A decisão de restringir a dimensão surgiu da necessidade de comparar estruturas iguais. Embora empresas grandes possam conter várias equipas de trabalho com poucos elementos, pela sua dimensão, os processos serão diferentes daqueles usados em empresas pequenas. Outra razão para esta escolha foi uma maior facilidade no contacto com estas empresas e a expectativa de uma maior aceitação por parte das mesmas em realizar uma entrevista.
A circunspeção geográfica prendeu-se por questões de conveniência e economia e por se considerar que a área do Grande Porto permitiria encontrar vários casos de estudo interessantes e diversos.
A seleção das equipas de trabalho ou empresas a entrevistar foi feita usando o método de amostragem snowball, começando por partir de contactos obtidos através de docentes, colegas e amigos. Dentro das sugestões obtidas, foi feita uma pré-seleção baseada no tipo de trabalho desenvolvido: teria que existir um componente de design de interação ou não se enquadraria no âmbito projeto.
Dada a nossa ligação à FEUP, estes contactos acabaram por se centrar bastante na área do desenvolvimento de software. Contudo, conseguiu-se obter um leque variado de áreas de atuação e projetos diferenciados.
Após a pré-seleção, procedeu-se ao contacto das empresas, solicitando uma entrevista, no final da qual os entrevistados referenciavam novos contactos.
Para este estudo considerou-se a entrevista presencial como o melhor método de recolha de dados por diversas razões:
• Tem um formato flexível tanto para o entrevistador como para o entrevistado, permitindo que no momento da entrevista seja possível expandir ou clarificar alguma questão, ou até mesmo perseguir um tópico que não estivesse previsto abordar.
• Quando o local da entrevista o propicia, é possível ver o espaço onde a equipa trabalha e inferir a facilidade e frequência de comunicação presencial entre os elementos.
• Uma entrevista com duração de meia hora tende a ser mais facilmente aceite do que um longo questionário com perguntas de resposta aberta.
• Durante uma entrevista, em questões de resposta aberta, o entrevistado pode-se alargar o quanto quiser, e o entrevistador pode aproveitar deixas para inquirir sobre algum tópico referido ou relacionado.
32
Em preparação para as entrevistas, foi criado um guião que abordava tópicos como: informação geral sobre a equipa, área de atuação e tipo de projetos desenvolvidos, constituição das equipas, metodologia e processos de trabalho, contacto com utilizadores reais (atuais ou potenciais), preocupação e avaliação da usabilidade.
Com o decorrer das entrevistas o guião foi-se tornando mais familiar e passou a servir apenas como apoio, uma lista de tópicos que se pretendia abordar durante a conversa, tornando-se estas mais informais, tendo havido, contudo, um cuidado em não dispersar do tema e tocar nos pontos de interesse com o grau de profundidade necessária.
As entrevistas foram gravadas para que durante as mesmas não houvesse uma grande preocupação em tirar notas, podendo focar toda a atenção à conversa em si. Após cada entrevista, foram tiradas notas escritas sobre a mesma (ver Anexo A), com o auxílio da gravação.
2.2 Análise de dados
Como o guião não é seguido à risca, e a conversa não decorre da mesma forma com todos os entrevistados, a análise dos conteúdos não é tão linear como seria num questionário. Optou-se por dividir a análise em secções relativas aos grandes tópicos abordados e comparam-se os dados obtidos nas várias entrevistas.
2.2.1 Caracterização das equipas de trabalho ou empresas
Foram entrevistadas um total de 9 equipas de trabalho e empresas, identificadas com letras de A a I.
P1: Qual a área de atuação da empresa?
A: desenvolve ferramentas de produtividade para diversas plataformas.
B, G: fazem projetos de design e desenvolvimento para web e mobile, sendo que a empresa B tem um foco em projetos de IoT (Internet of Things), e a empresa G apresenta o design de interface e experiência de utilizador como mais valia.
C: unidade de I&D (Investigação e Desenvolvimento) de uma empresa e realiza projetos de investigação financiados em parceria com outras empresas ou centros de investigação.
D, E: realizam produtos na área da multimédia, mais concretamente televisão, a empresa D na área de transmissão, e a empresa E na área de produção e pós-produção.
F: realiza sistemas de navegação para smartphones e automóveis.
H: pertence a uma empresa de consultoria e realiza uma ferramenta online de gestão de processos e projetos baseada em metodologias como Agile e CMMI.
I: produz tecnologia para o retalho.
P2: Qual o tipo de projetos desenvolvidos pela empresa?
A: desenvolve um produto de gestão de tarefas e projetos, e está a desenvolver uma plataforma de comunicação direcionada a empresas.
Trabalho de Campo
33
B, G: têm projetos de variadas complexidades, desde websites simples de uma página, a plataformas complexas com muita informação, ou aplicações móveis.
C: desenvolve provas de conceito sobre determidadas tecnologias, e também produtos destinados ao mercado de consumo direccionados, por exemplo, à população sénior, população com Alzheimer ou Parkinson, que podem ter duração de cerca de 2 anos.
D: trabalha na área da televisão e realiza APIs de software e projetos costumizados na área da transmissão de média, num modelo de B2B (Business to Business). O projeto discutido consiste numa ferramenta que permite o armazenamento de horas de transmissão, gravação em qualquer momento dentro do limite de armazenamento, e catalogação de assets.
E: também na área da televisão, produz tecnologias de automação de fluxos de trabalho na área da produção e pós-produção televisiva, oferecendo soluções de software, hardware, ou ambos. Pode ser entendido como “a cola do sistema”, fazendo com que diferentes produtos (e.g. câmaras, editores de vídeo, sistemas de armazenamento,…) comuniquem entre si, permitindo a fácil movimentação de conteúdos.
F: desenvolve produtos próprios e produtos quase “marca branca”, que são adaptados às necessidades e branding dos clientes (empresas, operadoras…). Na parte do negócio automóvel, oferecem soluções incorporadas de fábrica no automóvel, ou soluções after market, em que um revendedor instala o sistema posteriormente.
H: desenvolve uma plataforma de gestão de projeto para rentabilizar o expertise da empresa--mãe, que presta serviços de consultoria de melhoria contínua, tentando estandardizar as metodologias de trabalho dos clientes.
I: desenvolve vários projetos na área do retalho desde sistemas de atendimento, sinalética digital, mupis, painéis de LED, produção de vídeo, aplicações móveis e websites.
P3: Quantos elementos constituem a empresa, na sua totalidade?
A: 40 a 50;
B: 8.
C: 8.
D: 5.
E: 50.
F: 50 a 60.
G: 16.
H: 5.
I: 15.
34
P4: Como são formadas as equipas de trabalho e distribuídas as tarefas?
A–I: usam algum tipo de metodologia de projeto ágil, frequentemente adaptadas às suas necessidades. Referem que as iterações curtas e constante comunicação (internamente e com o cliente) dá origem a menos erros e torna mais fácil todo o processo de desenvolvimento.
A–I: definem metas para os projetos, dividem-nos em tarefas mais pequenas, realizando (normalmente) ciclos semanais, no início dos quais fazem a revisão do que foi feito na semana anterior e planeiam o que irão fazer nessa semana.
A: usa uma estratégia de OKRs (Objectives and Key Results), na qual são definidos os objetivos que a empresa quer alcançar a cada trimestre, e a partir daí, as equipas de trabalho e cada elemento definem os seus objetivos para cada semana, o que leva à definição das tarefas. Estes objetivos são disponibilizados a toda a empresa para que qualquer pessoa possa saber o que está a ser feito por outra equipa. Esta estratégia é semelhante à definição de um roadmap e planeamento de tarefas de acordo com o mesmo.
B, E, F: utilizam plataformas de gestão de projetos (Redmine, Basecamp,…) que permitem organizar todas as metas, tarefas, deliverables, bugs, testes de qualidade, etc. no mesmo espaço, e são tidas como ferramentas fundamentais na organização.
A, H: usam as próprias ferramentas para fazer a gestão dos projetos.
B, G: referem que o sistema de organização das pastas do projeto e de nomenclatura, especialmente no projeto de design, é fundamental para o sucesso do projeto.
A, E, F, G: em empresas com maior dimensão e existindo equipas funcionais distintas (design, desenvolvimento, marketing, suporte…), as tarefas são alocadas pelos chefes de equipa, gestores de projeto.
B, H, I: nas de dimensão mais reduzida, a decisão é feita de uma forma mais informal, entre os elementos da equipa. Esta distribuição está normalmente relacionada com as competências de cada um e disponibilidade.
G: faz questão de dar a oportunidade aos elementos de trabalharem em projetos que estejam fora da sua área de conforto para que possam evoluir.
A, G, I: referem que em ocasiões nas quais o volume de trabalho é demasiado grande para uma só pessoa, há sempre algum colega que pode dar uma ajuda. Isto revelou-se mais comum nas empresas até aos 16 elementos, não deixando de haver a possibilidade de surgir o caso nas restantes.
B, H: empresas com apenas um designer, o trabalho deste, naturalmente, não pode ser dividido. Já developers podem distribuir o trabalho da forma referida anteriormente.
2.2.2 Metodologias do projeto de design de interação
P5: Ao longo do projeto, que metodologias são usadas? Com que grau de formalidade?
D, E: devido à especificidade dos produtos que desenvolvem e do público-alvo dos mesmos, as empresas com projetos na área da televisão restringem-se bastante àquilo que é o interface típico dessa indústria. Como os seus produtos são integrados no workflow dos utilizadores a par de outros produtos da usados na indústria, não faz sentido tentar fugir àquilo a que as pessoas se
Trabalho de Campo
35
foram habituando a usar. Assim sendo, não há muita margem para ser-se criativo no aspeto da interface. Contudo, a configurabilidade, modularidade e facilidade de utilização da interface levanta um desafio maior.
D: não tem designer, mas os developers do projeto realizam ESBOÇOS para tentar perceber a melhor forma de incorporar novas funcionalidades na interface.
E: realiza MOCKUPS e PROTÓTIPOS interativos que são discutidos com os quadros superiores da empresa.
A designação de MOCKUP e PROTÓTIPO é inconsistente entre os entrevistados, e muitas vezes os termos são usados como sinónimos, refletindo as diferentes opiniões referidas no ponto 1.3.4.1. De uma forma geral, o MOCKUP é associado a uma projeção do design da interface (estático) e da interação (simulação interativa), enquanto que o termo PROTÓTIPO é tido como algo mais funcional.
A criação de WIREFRAMES, MOCKUPS e PROTÓTIPOS foram as metodologias mais referidas pelos entrevistados. Especialmente os PROTÓTIPOS interativos, são bastante úteis para apresentar ao cliente, uma vez que simula o aspeto e as interações.
D, E, I: referem não realizar WIREFRAMES, passando diretamente para os MOCKUPS.
B, D: realizam ESBOÇOS em papel.
I: realiza ESBOÇOS em quadro branco, em conjunto com toda a equipa, passado diretamente destes para para MOCKUPS de alta-fidelidade, o que por vezes torna complicado fazer alterações na interface. Recentemente foi necessário dar um passo atrás e desenhar a interface numa fidelidade intermédia para melhor explorar as possíveis soluções.
B, E, F, G, H: têm um processo de desenvolvimento ligado às metodologias ágeis de software e tendem a usar plataformas de gestão que reforçam e facilitam estes processos.
B, H: criam USER STORIES, que contêm tarefas e documentos associados.
E, F: agrupam as tarefas por grupos funcionais.
B, C, G, I: referem ter criado PERSONAS em pelo menos um projeto.
B, C: baseiam-se em dados reais para a criação das PERSONAS (ENTREVISTAS, GRUPOS DE FOCO, conversas informais com utilizadores, pessoas próximas aos utilizadores ou clientes, investigação dos utilizadores da concorrência).
B: cria PERSONAS quando o projeto o justifica e há abertura e orçamento por parte do cliente.
C: cria e usa as PERSONAS com frequência nos projetos.
G: criou PERSONAS num único caso, no decorrer do desenvolvimento do produto interno. Estas PERSONAS não se basearam em dados reais, mas naquilo que a própria equipa pretendia do produto e nas suposições sobre os potenciais utilizadores. Contrariamente ao que seria esperado, as PERSONAS não pretenderam informar o design e desenvolvimento da aplicação, mas o público-alvo da estratégia de marketing.
I: Os prazos apertados nem sempre permitem a criação de PERSONAS. Além disso, a empresa já conhece bastante bem o público para quem cria os produtos, portanto não justifica a criação de PERSONAS. É apenas feito pontualmente e visto como um complemento à documentação do
36
projeto. A sua construção baseia-se nos dados sobre os utilizadore que são fornecidos pelos clientes e na sua experiência na área.
A, C, F: realizam TESTES DE USABILIDADE e referem a sua mais-valia na compreensão das dificuldades sentidas pelos utilizadores e validação do produto.
C: tenta incluir utilizadores durante toda a duração do projeto e realiza GRUPOS DE FOCO, sessões de BRAINSTORMING e sessões de desenvolvimento de PROTÓTIPOS em conjunto, referindo que no caso das aplicações direccionadas à população sénior, esta abordagem contribui para uma maior aceitação do produto.
F, G: criam FLUXOGRAMAS para mapear produtos mais complexos.
I: já realizou TESTES A/B e pretende fazê-lo mais vezes.
F: revela interesse em explorar a utilização de TESTES A/B.
A–I: Todas as empresas têm um processo de validação, que pode ser mais ou menos formal. Normalmente o QA (Quality Assurance) consiste em testes automatizados e testes manuais.
A, E: o processo de QA (Quality Assurance), é feito por uma equipa dedicada.
B, C, G, H, I: o QA é feito pela própria equipa de design e desenvolvimento.
F: além de uma equipa dedicada, a equipa de desenvolvimento e outros elementos-chave da empresa realizam QA.
B, E, F, G, H: ao utilizarem plataformas de gestão, facilmente são geradas tarefas associadas a QA, de acordo com as tarefas realizadas.
A: os próprios developers fornecem uma lista de funcionalidades a serem testadas
I: o processo da realização dos testes é completamente informal.
D, G, I: os próprios clientes podem também contribuir para o teste do produto.
A, B, F: recorrem a ANALÍTICAS para recolher informação quantitativa sobre a forma como os utilizadores usam os produtos, podendo detetar pontos de falha e inferir quais as suas causas.
P6: Que tipo de documentação ou deliverables são criados?
A, B, C, E, F, G, H: procuram fazer a documentação necessária do projeto, mas sem ser demasiado extensivo ou formal. A utilização de plataformas de gestão de projetos facilitam o arquivo e acesso à documentação (sejam listas de requisitos, FLUXOGRAMAS, listas de tarefas, listas de bugs, WIREFRAMES, MOCKUPS, etc.).
D, I: trabalham de uma forma mais ad-hoc, sendo a documentação tratada de uma forma mais informal.
B, E, F, G, H: referem que a documentação é mais direcionada à própria equipa que ao cliente. A este apenas vão apresentando o projeto (MOCKUPS, PROTÓTIPOS) e no caso de websites ou aplicações móveis, fornecem toda a documentação associada (assets, guias de estilo, UI kits,…).
Trabalho de Campo
37
2.2.3 Contacto com utilizadores reais
P7: Existe envolvimento do utilizador final em alguma fase do projeto?
C: procura envolver os utilizadores durante todo o projeto através de sessões de BRAINSTORMING, GRUPOS DE FOCO e TESTES DE USABILIDADE.
A: envolve utilizadores apenas nas fases de teste do ciclo de desenvolvimento.
H: teve a oportunidade de em parceria com uma universidade, disponibilizar a plataforma, em fase de desenvolvimento, para utilização por parte dos alunos de uma unidade curricular, obtendo assim feedback de utilizadores reais, que permitiu melhorar progressivamente a plataforma.
P8: Procuram perceber o que o utilizador precisa/pretende?
A: os produtos surgiram das próprias necessidades do fundador e da empresa, portanto até certo ponto, eles próprios sugerem funcionalidades ou alterações que julguem necessário para a sua interação com os produtos. Contudo, o feedback dos utilizadores, quer através de TESTES DE USABILIDADE, quer através da equipa de suporte, é indispensável para melhorar os produtos.
B, G, I: sendo que fazem prestação de serviços, espera-se que o cliente já tenha uma ideia do que pretende e de quem são os seus utilizadores finais.
B: se necessário e oportuno, a equipa fala com os utilizadores finais para perceber o que pretendem do produto.
G: não faz qualquer tipo de recolha de informação sobre o utilizador, dependendo do cliente para passar toda e qualquer informação relevante.
A–I: referem que o feedback dos clientes (e por extensão dos clientes desses), é fundamental e a melhor forma de perceber o que é que se pretende e o que pode ser melhorado.
F, H: além da relação com o cliente e do feedback que chega até à equipa de suporte, lançam versões beta para serem testadas por utilizadores reais.
A–I: O feedback recebido, por clientes ou utilizadores, é avaliado e, se for determinado válido, é direcionado à equipa de desenvolvimento, que irá definir novas tarefas para responder às dificuldades ou sugestões.
2.2.4 Avaliação da usabilidade
P9: Existe uma preocupação com a usabilidade?
A–I: concordam ser importante haver uma preocupação com a usabilidade e experiência do utilizador, uma vez que o sucesso dos produtos depende da facilidade de utilização por parte dos utilizadores. Contudo, muito poucos aplicam metodologias para avaliar a usabilidade dos seus produtos, apoiando-se na sua experiência e do feedback recebido por parte de clientes e utilizadores.
38
P10: Que metodologias ou processos aplicam no sentido de garantir a usabilidade do sistema?
B, F, G, I: referem que a sua experiência acerca do meio e seus utilizadores lhes dá segurança no desenvolvimento dos produtos.
A–I: referem que o feedback do cliente e dos utilizadores (quando é o caso), é extremamente valioso para validar as opções tomadas e fazer alterações.
A, B, F: recorrem a ANALÍTICAS que permitem perceber, por exemplo, se algumas funcionalidades não estão a ser usadas, se os utilizadores não chegam a determinada página do site. Isto permite-lhes inferir quais as possíveis causas para estes problemas e tomar decisões para colmatar as falhas.
P11: Realizam testes de usabilidade?
A, C, F: realizam TESTES DE USABILIDADE, referindo que os seus resultados foram úteis para a recolha de informação sobre a utilização do produto e que os ajudaram a validar escolhas e melhorar o produto.
A: realiza testes remotos não moderados através de uma plataforma online, e também de uma forma informal com amigos ou familiares.
C: realiza testes presenciais ao longo do desenvolvimento do projeto.
F: contratou uma empresa de UX (User Experience), que realizou TESTES DE USABILIDADE e GRUPOS DE FOCO com utilizadores, referindo que é algo que pretendem explorar internamente no futuro.
As empresas que não realizam TESTES DE USABILIDADE referem principalmente limitações de tempo.
D, E: referem a impossibilidade de aceder a utilizadores reais dado a sua especificidade.
B, G, H, I: consideram que dada a experiência na área e o contacto com o cliente e indústria, não se justifica fazer este tipo de teste.
Trabalho de Campo
39
2.3 Tabela de síntese da caracterização da amostra
A B C D E
Car
acte
rizaç
ão
da e
mpr
esa
/ eq
uipa
de
traba
lho
Área de atuação ferramentas
de produtividade
design e desenvolvimento
web e mobile I&D televisão
(broadcast)
televisão (produção e pós-
produção)
Número de elementos 40 a 50 8 8 5 50
Form
ação
de
equi
pas e
dis
tribu
ição
de
tare
fas
Metodologias ágeis • • • • • OKR •
Plataformas de gestão de projetos • • Ferramentas próprias de gestão •
Sistema de organização de pastas e nomenclatura
•
Tarefas alocadas por chefe de equipa • • Tarefas alocadas informalmente •
Trabalho fora da área de conforto Partilha de tarefas em ocasiões de
grande volume de trabalho •
Apenas um designer • Nenhum designer •
Met
odol
ogia
s usa
das
Esboços • •
Mockups • • Protótipos •
Wireframes • • • User stories •
Personas • • Testes de usabilidade • •
Grupos de foco • Brainstorming •
Fluxogramas Testes A/B
QA • • • • • Analíticas • •
Envo
lvim
ento
do
util
izad
or Durante o desenvolvimento,
disponibilizando versões beta
Durante as fases de teste • Durante todo o projeto •
Nec
essi
dade
s do
util
izad
or
Feedback de clientes ou utilizadores • • • • •
Contacto direto com utilizadores finais
• •
Cliente já sabe o que pretende •
Usa
bilid
ade
Não realizam testes de usabilidade • •a •a Testes de usabilidade remotos, não
moderados •
Testes de usabilidade presenciais • Testes de usabilidade realizados por
uma empresa externa
a falta de acesso aos utilizadores reais
40
F G H I C
arac
teriz
ação
da
em
pres
a /
equi
pa d
e tra
balh
o Área de atuação
sistemas de
navegação
design e desenvolvimento
web e mobile
ferramenta de gestão de projetos
tecnologia para o retalho
Número de elementos 50 a 60 16 5 15
Form
ação
de
equi
pas e
dis
tribu
ição
de
tare
fas
Metodologias ágeis • • • • OKR
Plataformas de gestão de projetos • Ferramentas próprias de gestão
Sistema de organização de pastas e nomenclatura
•
Tarefas alocadas por chefe de equipa • • Tarefas alocadas informalmente • •
Trabalho fora da área de conforto • Partilha de tarefas em ocasiões de
grande volume de trabalho • •
Apenas um designer •
Nenhum designer
Met
odol
ogia
s usa
das
Esboços • Mockups •
Protótipos Wireframes • • • User stories •
Personas •b •c Testes de usabilidade •
Grupos de foco Brainstorming
Fluxogramas • • Testes A/B •
QA • • • • Analíticas •
Envo
lvim
ento
do
util
izad
or Durante o desenvolvimento,
disponibilizando versões beta •
Durante as fases de teste Durante todo o projeto
Nec
essi
dade
s do
util
izad
or
Feedback de clientes ou utilizadores • • • •
Contacto direto com utilizadores finais
Cliente já sabe o que pretende • •
Usa
bilid
ade
Não realizam testes de usabilidade • • • • Testes de usabilidade remotos, não
moderados
Testes de usabilidade presenciais Testes de usabilidade realizados por
uma empresa externa •d
b criou personas base na experiência e expectativas pessoais, pretendendo informar apenas a estratégia de marketing.
c criou personas com base em dados reais, mas é apenas visto como complemento à documentação, uma vez que a equipa já conhece bastante bem o público-alvo.
d testes realizados pela primeira vez durante o desvolvimento da versão mais recente
2.4 Análise e discussão dos dados
Da análise das entrevistas, pode-se concluir que existe uma grande preocupação em criar produtos apelativos e fáceis de usar, mas poucas empresas envolvem o utilizador final em
Trabalho de Campo
41
alguma fase do processo de design e desenvolvimento e ainda menos fazem avaliação da usabilidade dos seus produtos.
Na sua maioria, confiam na sua experiência e na constante comunicação com o cliente, que se supõe conhecer a sua área de negócio e os seus clientes.
Em casos de indústrias muito especializadas, como a transmissão e produção televisiva, as empresas dependem da sua experiência e conhecimento do meio, e da comunicação com o cliente, indo ganhando alguma sensibilidade com o tempo. Nestes casos não é viável realizar TESTES DE USABILIDADE ou contactar diretamente com utilizadores finais.
A equipa que realiza projetos de investigação, é a que mais metodologias usa, e mais envolve o utilizador final. Isto pode dever-se à duração típica dos projetos, de cerca de dois anos, que permite dedicar muito mais tempo à recolha de informação sobre o utilizador e validação do produto com o mesmo.
Os WIREFRAMES, MOCKUPS e PROTÓTIPOS são as ferramentas mais utilizadas pelos entrevistados, salientando a sua mais-valia na comunicação e discussão da ideia com o cliente.
Acima de tudo, a constante comunicação com o cliente, o seu feedback, e o feedback recebido de utilizadores (através de TESTES DE USABILIDADE ou do suporte ao cliente), são considerados preciosos para a melhoria dos produtos.
3. Conclusão
Esta dissertação focou-se em identificar as metodologias do design de interação e da avaliação da usabilidade aplicadas em contexto real e as suas diferenças face ao que é referido na literatura.
Ao realizar este projeto foi possível concluir que apesar dos processos e metodologias considerados pela literatura como sendo os melhores para garantir o desenvolvimento de produtos focados nas necessidades do utilizador e a usabilidade do sistema, a realidade é outra.
Na prática, as equipas encontram aquilo que funciona para elas, muitas vezes partindo da sua experiência no ramo de atividade em que se inserem, do contacto com a indústria e com os clientes. Existe uma preocupação em criar produtos usáveis e agradáveis para o utilizador, mas muitas vezes isto é feito de forma intuitiva.
Algumas das empresas entrevistadas aplicam metodologias como PERSONAS, GRUPOS DE FOCO e TESTES DE USABILIDADE.
Enquanto que algumas empresas revelam interesse em futuramente explorar o uso destas e outras metodologias que permitam melhor conhecer o utilizador (as suas motivações, objetivos, necessidades) e perceber como este interage com o seu produto, outras referem não ser algo pertinente, confiando na experiencia e no feedback recebido por clientes e utilizadores.
Sumariamente, este estudo contribuiu para um maior conhecimento sobre as metodologias que são postas em prática no processo de design de interação e na avaliação da usabilidade por parte de equipas e empresas de pequena dimensão localizadas no Grande Porto.
3.1 Satisfação dos objetivos
O principal objetivo desta dissertação consistiu em identificar que metodologias do design de interação e avaliação da usabilidade são usadas em contexto real, por empresas de pequena dimensão na área do Grande Porto.
Apesar de uma amostra pequena, foi possível angariar um grupo diverso de casos de estudo e perceber as diferenças entre aquilo que é referido na literatura e o que é aplicado no contexto real. Assim sendo, julgo que o projeto cumpriu este objetivo.
44
Quanto às metas estipuladas para alcançar este objetivo, a revisão de literatura faz um levantamento das principais e mais conhecidas metodologias do projeto de design de interação e de avaliação da usabilidade, cumprindo suficientemente o objetivo proposto.
Relativamente ao trabalho de campo, o levantamento de equipas de trabalho e empresas acabou por se concentrar na área do desenvolvimento de software, mas dentro disso foram conseguidas várias áreas de atuação e projetos diferenciados. Tendo em conta o número reduzido de entrevistas realizadas, considera-se o objetivo alcançado.
A realização e análise das entrevistas foi também conseguida com sucesso, tendo assim cumprido o objetivo pretendido.
3.2 Limitações e trabalho futuro
Embora já saísse um pouco fora do âmbito desta dissertação, poderiam ter sido abordadas na revisão de literatura as metodologias de projeto e a sua relação com o projeto de design de interação (e por extensão, experiência do utilizador), já que estas têm alguma influência na calendarização do projeto e, consequentemente, nas metodologias usadas durante o processo de design.
A secção das metodologias poderia ter sido mais exaustiva e subdividida atendendo a um determinado critério, como por exemplo as fases de desenvolvimento de um projeto, o tipo de dados recolhidos (quantitativos ou qualitativos), ou a sua classificação.
A investigação tem algumas limitações, sendo a principal a dimensão reduzida da amostra, que limita as conclusões.
Uma questão que ficou por explorar, pela necessidade de focar a investigação, é a da experiência do utilizador: a perceção que este tem do sistema, e como as equipas de trabalho ou empresas atendem a esta dimensão.
Embora não fizesse parte dos objetivos, durante as entrevistas foi questionada a possibilidade de disponibilizar alguma documentação (PERSONAS, WIREFRAMES, MOCKUPS, etc.), a fim de comparar as várias formas de abordar determinada metodologia. Infelizmente, não foram obtidas suficientes respostas positivas que justificassem a inclusão desta questão nesta dissertação. Seria interessante expandir esta questão no futuro.
Futuramente, a investigação poderá ser continuada e alargada a outras localizações, tornando possível tirar mais conclusões, a fim de refletir um panorama mais exato, podendo ainda ser acrescentadas outras questões que sejam pertinentes investigar.
Referências
Adlin, Tamara. 2007a. "Ad Hoc, or 'Assumption,' Personas". Acedido a 16 de abril de 2016. http://www.adlininc.com/what_i_do/analysis_evaluation/2007/03/create_personas.php.
———. 2007b. "Data-Driven Personas". Acedido a 16 de abril de 2016. http://www.adlininc.com/what_i_do/analysis_evaluation/2007/03/data_driven_personas.php.
Äijö, Raila, e Jussi Mantere. 2001. "Are Non-Expert Usability Evaluations Valuable?". Comunicação apresentada em 18th International Symposium on Human Factors in Telecommunications (HfT'01), em Bergen, Norway.
Bolt, Nate, e Tony Tulathimutte. 2010. Remote Research: Real Users, Real Time, Real Research: Rosenfeld Media.
Chopra, Paras. 2010. Multivariate Testing In Action: Five Simple Steps To Increase Conversion Rates. Smashing Magazine, 24 de novembro de 2010. Acedido a 14 de abril de 2016. https://www.smashingmagazine.com/2010/11/multivariate-testing-in-action-five-simple-steps-to-increase-conversion-rates/.
Cooper, Alan, Robert Reimann, e David Cronin. 2007. About Face 3: The Essentials Of Interaction Design. Indianapolis, Indiana: Wiley Publishing, Inc.
Cooper, Alan, Robert Reimann, David Cronin, e Christopher Noessel. 2014. About Face: The Essentials of Interaction Design. Fourth ed. Indianapolis, Indiana: Wiley.
Dix, Alan, Janet Finlay, Gregory D. Abowd, e Russell Beale. 2004. Human-computer Interaction: Pearson/Prentice-Hall.
46
Dourado, Helena. 2014. "Análise comparativa entre Lean UX e métodos tradicionais de UX Design". MS, Faculdade de Engenharia, Universidade do Porto.
Farmer, Jesse. 2009. "An Introduction to A/B Testing". 20bits, 19 de janeiro de 2009. Acedido a 14 de abril de 2016. http://20bits.com/article/an-introduction-to-ab-testing.
Honrado, Luís. 2015. "Estudo da Usabilidade no Desenvolvimento de Uma Plataforma de Comunicação Social Online - Caso Canal Superior". MS, Faculdade de Engenharia, Universidade do Porto. Acedido a 18 de maio de 2016.
ISO 9241-11. 1998. Ergonomic requirements for office work with visual display terminals (VDTs) – Part 11: Guidance on usability.
Krug, Steve. 2009. Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems: New Riders Publishing.
———. 2014. Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability. Berkeley, California: New Riders.
Machado, Gonçalo. 2013. "aLIVE Panoramics: Aplicação de Estratégias de Design Centrado no Utilizador". MS, Faculdade de Engenharia, Universidade do Porto. http://digitool.fe.up.pt:1801/webclient/DeliveryManager?custom_att_2=simple_viewer&metadata_request=false&pid=743850.
Martin, Bella, e Bruce Hanington. 2012. Universal Methods of Design: 100 Ways to Research Complex Problems, Develop Innovative Ideas, and Design Effective Solutions: Rockport Publishers.
McGinn, Jennifer, e Nalini Kotamraju. 2008. "Data-driven persona development". Comunicação apresentada em Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, em Florence, Italy. Acedido a 3 de abril de 2016.
Mesquita, Catarina. 2013. "Usabilidade na Web: Metodologias para a Avaliação Qualitativa da Usabilidade em Dispositivos Mobile no Sítio Web da Universidade do Porto". MS, Faculdade de Engenharia, Universidade do Porto.
Moggridge, Bill. 2007. Designing Interactions. Cambridge, Massachusetts: The MIT Press.
Moule, Jodie. 2012. Killer UX Design: SitePoint Pty, Limited.
Nielsen, Jakob. 1989. "Usability engineering at a discount". Comunicação apresentada em Proceedings of the third international conference on human-computer interaction on Designing and using human-computer interfaces and knowledge based systems (2nd ed.), em Boston, Massachusetts, USA.
———. 1993. Usability Engineering: Morgan Kaufmann.
———. 1994. Guerrilla HCI: Using Discount Usability Engineering to Penetrate the Intimidation Barrier. NNGroup, 1 de janeiro de 1994. Acedido a 16 de abril de 2016. https://www.nngroup.com/articles/guerrilla-hci/.
———. 1995. How to Conduct a Heuristic Evaluation. NNGroup, 1 de janeiro de 1995. Acedido a 15 de abril de 2016. https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/.
Referências
47
———. 1997a. Discount Usability for the Web. NNGroup, 1 de janeiro de 1997. Acedido a 2 de outubro de 2014. http://www.nngroup.com/articles/web-discount-usability/.
———. 1997b. The Use and Misuse of Focus Groups. NNGroup, 1 de janeiro de 1997. Acedido a 4 de setembro de 2016. https://www.nngroup.com/articles/focus-groups/.
———. 2000. Why You Only Need to Test with 5 Users. NNGroup, 19 de março de 2000. Acedido a 28 de julho de 2016. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/.
———. 2004. Card Sorting: How Many Users to Test. NNGroup, 19 de julho de 2004. Acedido a 10 de março de 2015. http://www.nngroup.com/articles/card-sorting-how-many-users-to-test/.
———. 2005. Putting A/B Testing in Its Place. NNGroup, 15 de agosto de 2005. Acedido a 21 de maio de 2016. https://www.nngroup.com/articles/putting-ab-testing-in-its-place/.
———. 2012a. How Many Test Users in a Usability Study? NNGroup, 4 de junho de 2012. Acedido a 2 de outubro de 2014. http://www.nngroup.com/articles/how-many-test-users/.
———. 2012b. Usability 101: Introduction to Usability. NNGroup, 4 de janeiro de 2012. Acedido a 2 de outubro de 2014. http://www.nngroup.com/articles/usability-101-introduction-to-usability/.
Norman, Donald A. 2004. Ad-Hoc Personas & Empathetic Focus. NNGroup, 16 de novembro de 2004. Acedido a 17 de fevereiro de 2015. http://www.jnd.org/dn.mss/personas_empath.html.
Ribeiro, Hugo. 2012. "Usabilidade Acessível: Metodologias para a Avaliação Qualitativa da Usabilidade no Design para a Web". MS, Faculdade de Belas Artes, Universidade of Porto.
Santos, Ivo Cristiano da Silva. 2012. "Understanding how personas and scenarios are used in real world practice". MS, Faculdade de Engenharia, Universidade do Porto.
Sauro, Jeff. 2011a. Measuring Usability with the System Usability Scale (SUS). MeasuringU, 2 de fevereiro de 2011. Acedido a 23 de abril de 2016. http://www.measuringu.com/sus.php.
———. 2011b. Measuring Usefulness. MeasuringU, 1 de novembro de 2011. Acedido a 4 de setembro de 2016. http://www.measuringu.com/blog/usefulness.php.
Schade, Amy. 2013. Remote Usability Tests: Moderated and Unmoderated. NNGroup, 12 de outubro de 2013. Acedido a 2 de outubro de 2014. http://www.nngroup.com/articles/remote-usability-tests/.
Shneiderman, Ben. 1998. Designing the User Interface: Strategies for Effective Human-Computer Interaction. 3ª ed. Maryland: Addison Wesley.
Smith, Gillian Crampton. Prefácio a Designing Interactions por Bill Moggridge, vii–xix. Cambridge, Massachusetts: The MIT Press. 2007.
Stone, Debbie, Caroline Jarrett, Mark Woodroffe, e Shailey Minocha. 2005. User Interface Design and Evaluation: Elsevier Science.
48
Tavares, Sandro. 2013. "Plataforma para Gestão de Conteúdos de Entretenimento: UX Design da Investigação ao Protótipo". MS, Faculdade de Engenharia, Universidade do Porto.
Tullis, Tom, e Larry Wood. 2004. "How Many Users are Enough for a Card-Sorting Study?". Comunicação apresentada em Proceedings of UPA 2004, em Minneapolis, MN.
Unger, Russ, e Carolyn Chandler. 2009. A Project Guide to UX Design: For user experience designers in the field or in the making: Pearson Education.
Usability First. 2013. "Usability First - Usability Glossary - Focus Groups | Usability First". Acedido a 4 de setembro de 2016. http://www.usabilityfirst.com/usability-methods/focus-groups/.
Warfel, Todd Zaki. 2009. Prototyping: A Practitioner's Guide: Rosenfeld Media.
Wharton, Cathleen, John Rieman, Clayton Lewis, e Peter Polson. 1994. "The Cognitive Walkthrough Method: A Practitioner's Guide." Em Usability inspection methods, editado por Nielsen Jakob e L. Mack Robert, 105–140. John Wiley & Sons, Inc. Acedido a 6 de julho de 2016.
Anexo A
4. Entrevistas
4.1 Empresa A
Posição do(s) entrevistado(s): Diretora de Design e Design de Produto Número de elementos: 40 a 50
Descrição: Desenvolvimento de ferramentas de produtividade. Tipo de projetos desenvolvidos: Ferramenta de gestão de projetos e tarefas
Ferramenta de comunicação para equipas e empresas Metodologias e técnicas aplicadas: Cenários
Wireframes Mockups Prototipagem Testes de usabilidade Analíticas Recolha de feedback dos utilizadores
A empresa desenvolve ferramentas de produtividade. Têm uma aplicação de gestão de tarefas e uma plataforma de comunicação direcionada a empresas, que ainda não foi lançada. Ambas surgiram de necessidades internas, por não existirem outras ferramentas que respondessem ao problema.
A empresa é constituída por 40 a 50 pessoas. Têm um escritório no Porto, mas encontram-se espalhados por todo o mundo, trabalhando remotamente.
As equipas de desenvolvimento dividem-se por projeto (uma equipa de iOS, Android e Web para cada um dos projetos), o back end, Marketing e Design são transversais.
50
A equipa de design é constituída por 6 elementos: 2 fazem front end, 2 estão focados nas aplicações móveis e Windows, e 2 em Mac OS, marketing e promoção.
Usam os próprios produtos para gestão de projetos e tarefas, e comunicação interna, recorrendo também à videoconferência para fazer reuniões.
Ao terminar uma release, planeiam o que que vai ser implementado na seguinte. A equipa de produto discute as funcionalidades para perceber como devem funcionar, partilhando depois com o resto da empresa para receber feedback e depois passam à fase de produção de MOCKUPS ou WIREFRAMES, que podem já estar integrados numa fase inicial de discussão do produto para partilhar com a empresa. Inicia-se em seguida a implementação, enquanto o design é finalizado.
Numa fase de discussão os MOCKUPS podem ser feitos em papel, mas em seguida usam o Sketch para criar MOCKUPS estáticos. Depois usam ferramentas como o Marvel para criar uma versão interativa. Com animações ou interações mais complexas usam ferramentas como o Framer.
Todos têm uma visão clara dos objetivos que a empresa e os produtos pretendem alcançar.
Têm OKRs (Objectives and Key Results) para cada trimestre, para a empresa, equipas e cada elemento, que depois leva às tarefas a realizar em cada semana.
As equipas tentam reúnem uma vez por semana para discutir o que foi feito na semana anterior, o que vai ser feito na semana seguinte, e dividir as tarefas. Isto é posteriormente colocado na plataforma de comunicação para que qualquer pessoa possa consultar.
Os prazos são decididos democraticamente. Se uma data é sugerida e por qualquer razão alguém não a pode cumprir, é negociada uma nova data.
Consideram que a sua maior limitação é o tempo. Fora isso, tudo está bastante acessível.
Todos os elementos são bastante multidisciplinares, o que significa que quando uma equipa está atrasada, outros podem intervir e dar uma ajuda.
A equipa de Suporte também realiza QA (Quality Assurance). A equipa de desenvolvimento tenta terminar as versões com alguns dias de antecedência para que a equipa de Suporte as possa rever e reportar qualquer erro ou dificuldade encontrada.
Ao ter contacto com o cliente, a equipa de Suporte reporta todos os meses as dificuldades ou erros mais encontrados pelos utilizadores. Cabe aos developers decidir se estas questões são válidas e se as alteram ou não.
O foco da empresa é a criação de produtos usáveis, que proporcionem uma ótima experiência para o utilizador.
Para criar os produtos, não se apoiam apenas nas suas opiniões. Usam ANALÍTICAS, resultados de TESTES DE USABILIDADE (remotos), e de TESTES DE USABILIDADE informais com familiares e amigos.
Não pensam primeiro nas funcionalidades, mas como o design e a experiência será para o utilizador, e só depois como integrar essas funcionalidades. As ideias para novas funcionalidades podem vir de qualquer pessoa na empresa, ou devido a feedback recebido por parte dos utilizadores (algo que não entendem, ou que poderia estar melhor).
Entrevistas
51
Com a nova versão do produto tentam tornar a experiência do utilizador o mais fácil possível. Tentam tornar mais simples a experiência do utilizador iniciado, escondendo as funcionalidades avançadas.
Fazem USER STORIES, que não são formalmente documentadas, e são normalmente baseadas nas necessidades de cada um, que são bastante diversas, ou até mesmo indo buscar a familiares, que são utilizadores menos avançados.
Fazem a documentação das funcionalidades (p. ex. como deve funcionar), e no caso da plataforma de comunicação, FLUXOGRAMAS para fazer o planeamento do desenvolvimento.
4.2 Empresa B
Posição do(s) entrevistado(s): CEO Designer
Número de elementos: Descrição: Agência de design e desenvolvimento especialmente
focada em IoT. Tipo de projetos desenvolvidos: Projetos de design, desenvolvimento, ou com ambas
as componentes; Websites; Aplicações móveis; Plataformas online.
Metodologias e técnicas aplicadas: Personas User Stories Esboços Wireframes (menos comum) Mockups Prototipagem Analíticas Recolha de feedback (clientes)
Agência que faz design e desenvolvimento de sites, aplicações móveis, plataformas online. Os projetos tanto podem ter as duas componentes, como ser apenas projetos de design ou de desenvolvimento. Existe ainda uma outra componente de marketing, em que aconselham os clientes a nível de crescimento.
Especialmente focados a trabalhar em IoT (Internet of Things), bots: vão diversificando a oferta consoante o que o mercado pede e os clientes pretendem.
A equipa é constituída por 5 pessoas, em que uma é designer, e ainda 3 estagiários.
O processo varia consoante cada projeto, por questões orçamentais, temporais, ou “pelo projeto não ser complexo suficiente para exigir algumas fases do workflow que existe à volta de um processo de design”.
Havendo apenas um designer, tentam não ter muitos projetos a decorrer ao mesmo tempo, e antes de começar um novo projeto tentam ter o máximo de coisas prontas para fazer o handoff,
52
ou seja, enquanto não é possível voltar a esse projeto, a equipa de desenvolvimento já tem alguma coisa para ir implementando.
A partir do momento em que são abordados por um cliente, fazem uma análise do projeto, fazendo uma lista daquilo que será necessário. Fazem a documentação destes requisitos e atribuem referências a todos os documentos e páginas a desenvolver, o que torna mais simples a discussão do projeto com o cliente.
Em seguida fazem uma estimativa do tempo necessário para todas as partes do projeto (design, desenvolvimento, QA), e iniciam a criação de MOCKUPS. Por vezes fazem ESBOÇOS, que servem apenas para organização interna; o cliente já vê os MOCKUPS em alta fidelidade.
Tipicamente, não fazem WIREFRAMES, por ser complicado para os clientes visualizar o produto final com uma vista estrutural do produto. Apenas em casos em que o produto não é tão visual (sites com muita informação, por exemplo tabelas) é que se faz sentido fazer WIREFRAMES.
Usam ferramentas como o InVision, Sketch e Zeplin que agilizam o processo iterativo de design (desenhar, mostrar ao cliente, alterar consoante o feedback recebido).
Em projetos que seja necessário perceber quem é o público-alvo, são criadas PERSONAS. Quando possível, falam os os utilizadores finais. Quando não é possível, por ser um público--alvo muito específico, procuram recolher informação sobre os mesmos de outras formas por exemplo, analisando a interação de utilizadores com concorrentes, extrapolando para possíveis PERSONAS que façam sentido para o projeto.
No caso de websites, depois do projeto estar implementado poderão usar, consoante o projeto, o Mouseflow, que grava a interação dos utilizadores com o website. Permite ver o percurso de navegação na página, no caso de página única, até onde foi vista, quanto tempo estão na página, heatmaps, etc. Puderam concluir que nos projetos desenvolvidos (e inclusive no próprio site da empresa), muitas pessoas não fazem scroll na primeira página se não existir indicação para o fazer, apesar de muitos artigos dizerem que hoje em dia já não é necessário indicar aos utilizadores que é possível fazer scroll.
Além desta ferramenta, não fazem qualquer tipo de TESTE DE USABILIDADE. Fazem QA internamente e recolhem feedback dos clientes. O processo de QA é definido a partir das tarefas do projeto; depois de ser implementada, a tarefa passa para o elemento da equipa que o irá testar. Em projetos mais simples, p. ex. websites, há muitas coisas que podem ser automatizadas.
Em termos de metodologia de projeto, usam a metodologia SCRUM. Realizam reuniões semanais em que definem as metas para a semana e todo o processo de design e desenvolvimento é muito integrado e acompanhado, não havendo uma grande separação entre os dois. Estão também em permanente comunicação com o cliente.
Entrevistas
53
4.3 Equipa C
Posição do(s) entrevistado(s): Diretora de I&D Número de elementos: 8
Descrição: Projetos de investigação e desenvolvimento em parceria com outras empresas e centros de investigação.
Tipo de projetos desenvolvidos: Investigação de tecnologia; Provas de conceito; Projetos destinados ao mercado de consumo,
direccionados, por exemplo, à população sénior, população com Alzheimer ou Parkinson.
Metodologias e técnicas aplicadas: Brainstorming Grupos de foco Personas Cenários Wireframes Mockups Prototipagem (em papel e digital) Testes de usabilidade Recolha de feedback (informal)
Projetos de investigação e desenvolvimento, em parceria com outras empresas ou centros de investigação em universidades.
A duração típica do desenvolvimento de um produto são 2 anos.
É uma equipa de I&D de uma empresa, composta por 5 developers, 2 designers, e uma pessoa com formação em ambas as áreas.
A constituição das equipas para cada projeto depende tanto do projeto, como da disponibilidade das pessoas. Devem, no entanto, ser pelo menos duas pessoas por projeto, e que exista sempre um designer e um developer.
Procuram envolver os utilizadores finais desde o início do projeto, tentando mantê-los até ao final do mesmo.
Nem sempre é possível fazê-lo, mas é a metodologia ótima, com a qual notam conseguir obter melhores resultados. Em vez de haver uma separação entre os utilizadores e a equipa técnica, juntam-se e tentam aplicar uma metodologia centrada no utilizador.
Desenvolvem vários tipos de projetos, alguns direcionados a pessoas com idade superior a 65 anos, portadores de Parkinson ou Alzheimer. Nestes casos nem sempre é possível envolver os utilizadores finais, portanto tentam envolver os cuidadores ou familiares.
Começam por pensar no que seria útil ao utilizador e em conjunto com estes, criam PERSONAS e cenários de utilização para cada uma delas, não sendo sempre muito exaustivos.
Por vezes realizam sessões que decorrem o dia inteiro em que além do anteriormente referido, criam também WIREFRAMES, MOCKUPS ou PROTÓTIPOS em conjunto, no sentido de ajudar os utilizadores a visualizar aquilo que a equipa entende ser o seu problema e possível resolução.
54
No caso de utilizadores que não estejam à vontade com a tecnologia, estes são feitos em papel, enquanto que com utilizadores “tecnológicos”, são realizados em formato digital.
Na realização de projetos que consistem em gerar uma prova de conceito, não recorrem a metodologias específicas, procedendo de forma mais ad hoc.
Utilizam uma metodologia ágil e tentam demonstrar e validar o produto com os utilizadores em cada uma das fases do projeto. Quando se tratam de projetos nacionais é possível fazê-lo com maior frequência. No caso de projetos internacionais, tentam recorrer a um elemento, também técnico, do país onde está a ser desenvolvido o projeto, possa ir mostrando o produto e ir dando feedback.
Nos TESTES DE USABILIDADE, tentam seguir um guião e pedir ao utilizador que realize determinadas tarefas. No entanto, em projetos como os referidos, nem sempre é possível fazê-lo dessa forma, quer por falta de paciência ou capacidade por parte do participante. Da experiência da entrevistada, a forma como os participantes entendem as instruções e se comportam no teste depende muito da cultura do país e das próprias pessoas. Algumas preferem ser elas próprias a explorar a interface e fazer perguntas sobre a forma de utilização, enquanto outras preferem seguir as instruções.
Tipicamente, um projeto começa pela criação das PERSONAS e cenários de utilização, definição da arquitetura, criação de MOCKUPS ou WIREFRAMES e validação com os utilizadores.
Nos projetos com intuito ao consumo de mercado, existe uma entidade que financia o projeto e, após a sua conclusão, a intenção é levá-lo para o mercado. A título de exemplo, no caso de uma aplicação desenvolvida para pessoas com Parkinson, que está a ser usada nas associações, a empresa mantém o contacto, oferecendo suporte e recolhendo feedback que poderá informar novas necessidades.
Em projetos de investigação que não têm ligação direta ao mercado, é necessário acordar que empresa ficará com o direito a explorar a tecnologia desenvolvida.
São realizados GRUPOS DE FOCO ou sessões de BRAINSTORMING são realizadas com a equipa, parceiros e com pessoas externas, quando possível. Servem para expor o problema e gerar ideias para resolvê-lo.
4.4 Empresa D
Posição do(s) entrevistado(s): Fundadora e Business Manager Fundador e Chief Solutions Architect Engenheiro de Software
Número de elementos: 5 Descrição: Projetos costumizados na área da transmissão
(broadcast) de média. Tipo de projetos desenvolvidos: APIs de sofware para serem usadas nos produtos do
cliente; Produtos comercializados pelos clientes.
Metodologias e técnicas aplicadas: Esboços Recolha de feedback (cliente)
Entrevistas
55
A empresa presta serviços B2B (Business to Business) numa área da multimédia e entretenimento muito específica – a transmissão (broadcast). Vendem projetos costumizados: as empresas clientes (que também desenvolvem software) contratam-nos para desenvolvimento direto sobre os seus produtos, quase como outsourcing (que perfaz a maior parte do trabalho dos últimos 2–3 anos da empresa).
Têm duas linhas de trabalho: APIs de software para ser usadas nos produtos dos clientes; e produtos comercializados pelos clientes, em que o desenvolvimento é feito pela empresa e o cliente assegura o suporte, clientes, instalação de máquinas, etc.
Começaram por fazer APIs de software até que um dia, numa feira, um cliente lhes propôs que fizessem um produto, porque não lhes agradavam as opções existentes. Era para ser um produto para ser usado nos projetos deles, que a certa altura viram viabilidade para começar a comercializar.
O produto que este cliente faz é asset management, uma ferramenta que permite organizar e catalogar media. E precisava de uma ferramenta que fosse capaz de ser um gravador de vídeo SDI, o formato usado pelas câmaras em estúdio. Desenvolveram então um gravador que é capaz de fazer armazenamento interno até um determinado número de horas e é possível fazer gravações em qualquer ponto, dentro desse tempo. Isto dá mais robustez a erros, etc.
Começaram por criar a parte de gravaçâo e mais tarde criaram também a parte do utilizador, em qur têm uma interface gráfica para controlar os vários gravadores e gravar os conteúdos. Inicialmente isto foi criado como um asset management, mas atualmente já é um produto standalone que pode ser usado em qualquer lado.
Uma das coisas que o produto tenta resolver é a dificuldade que os operadores muitas vezes têm em utilizar este tipo de ferramentas. O cliente já havia referido que as ferramentas existentes no mercado eram muito difíceis de usar e demoravam muito tempo a aprender a utilizar, portanto este produto foi feito para ser o mais simples e user friendly possível, para que qualquer pessoa com o mínimo de conhecimento da área consiga utilizar o produto sem problemas.
É uma área em que as pessoas estavam muito habituadas aos gravadores analógicos, e quando passam para o digital existem muitas mais configurações, botões, extensões… Por isso a ideia aqui foi tentar criar um interface mais próximo possível do que eram esses gravadores.
Dois dos developers estão a trabalhar neste projeto e enquanto um trabalha na parte visual (Windows), o outro trabalha na parte que está escondida para o utilizador, da gravação.
As tarefas chegam maioritariamente do cliente, de necessidades que este tem para um evento específico.
Também existe muita discussão interna, durante o desenvolvimento, e o feedback do cliente, que ao utilizar e testar aquilo que é feito sugere determinada funcionalidade ou alerta para algum erro encontrado. É um processo muito ad-hoc, não muito estruturado. Não é possível ter um plamneamenteo a 6–9 meses como existirá num produto de software típico.
O produto também surgiu de uma forma um pouco atribulada, como prova de conceito, que mais tarde se percebeu que se calhar até era bom, as pessoas até queriam algo assim e era mais fácil de usar do que aquilo que já existia.
Este não é o caso de um “produto prateleira”, que é lançado para o mercado e as pessoas têm que “agarrar” aquilo. O cliente já tem os clientes, com quem vai falar e a partir daí consegue
56
vender o produto. É uma costumização quase sempre direcionada ao utilizador e não ao mercado.
O modelo de negócio da empresa é B2B (Business to Business) e não Business to Consumer, que é um pouco diferente. Com o contacto com a indústria e com os clientes, pesquisas de mercado, presenças em feiras, acompanhamento de organizações de normalização standards, estando atentos às tecnologias, às tendências do mercado… É aí que “vamos beber o que que se está a passar” e estrategicamente fazem algo, produtizando o seu expertise.
Esta indústria tem uma característica peculiar, que é lenta, não é (a industria de consumidor muda todos os dias, para fazer dinheiro devias ter feito a coisa há 2 meses atrás), com mais entraves, gasta muito dinheiro, gosta dos compadrios (se gosta de trabalhar com alguém vai continuar a trabalhar com alguém até que lhe mudem as ideias), e nesse sentido o nosso trabalho é tentar perceber onde vão encontrar o nosso nicho de mercado, para perceber o que podem fazer de diferente, e que têm um certo mercado para isso.
Como fizeram outsorcing, ao escutarem o que os seus clientes lhes dizem, e o que os clientes deles lhes dizem, ao mesmo tempo estão a perceber o que a indústria quer. E certas coisas como a cor do interface, é uma sensibilidade que vão ganhando.
É importante perceber para onde vai evoluir a indústria, porque apesar de ser lenta, não pode ficar ad eternum sem a maior revolução do IT. Estão a tentar perceber o que isso significa para a indústria e perceber onde é que se podem posicionar para tirar partido dessa mudança. Mais do que trabalhar na televisão como é hoje, querem trabalhar na televisão como vai ser no futuro.
Não trabalham com designer. Tipicamente é um processo de tentativa erro. Se for algo análogo ao que já existe, a interface tem de o reflectir. Se for uma funcionalidade nova, terá que ser pensado como vai ser integrada na interface atual. Os 2 developers discutem algumas ideias e fazem “uns desenhos”. Mas na maioria das vezes nem é necessário, porque costumam ser coisas parecidas ao que já existe. Criam a versão que decidiram, enviam ao cliente para ele validar e dar feedback.
O produto começou duma forma que não era fácil perceber bem qual era o objetivo, não havia o scope total, portanto o objetivo foi dar algo que fosse usável, e depois foi sendo um processo iterativo, que teve a vantagem de ser filtrado por diversas pessoas.
Nem sempre é possível abordar os end users, e neste caso, são operadores que são contratados por uma televisão qualquer e nos não têm acesso a eles. Assim sendo, se forem tendo algumas coisas no produto, eles já podem ir experimentando e ir dando feedback. São muitas vezes pessoas que já fazem isto há muitos anos, e às vezes não tem os conhecimentos de informática que “nós” consideramo mínimos, e quando aparece uma coisa nova, pode ser complicado de aprender. Para quem desenvolve é complicado pensar como será mais fácil para os utilizadores usar o produto, e não têm possibilidade de falar com eles.
Em termos de usabilidade, a indústria tem particularidades interessantes. Por exemplo, o vermelho que é muitas vezes usado para mostrar o erro, neste mundo é código para o “estar a gravar”, portanto acabaram por colocar o erro a laranja. Funciona então de uma forma muito iterativa, enviam oque acham melhor, e depois recebem feedback do cliente que lhes permite fazer melhorias.
Neste caso especifico, não faz sentido juntar um grupo de pessoas numa sala para discutir a interface, porque não conseguem arranjar uma amostra que represente os utilizadores reais.
Entrevistas
57
Assim, a melhor estratégia é mesmo iterar e ir alterando consoante o feedback que vão recebendo.
4.5 Empresa E
Posição do(s) entrevistado(s): Gestor de inovação e financiamento Número de elementos: 50
Descrição: Produção de tecnologias de automação de fluxos de trabalho na área da produção e pós-produção televisiva.
Tipo de projetos desenvolvidos: N/A Metodologias e técnicas aplicadas: Mockups
Prototipagem Recolha de feedback (cliente)
Empresa que produz tecnologia para televisão. Desenvolve pequenas peças para serem encaixadas no fluxo de trabalho diário dos produtores de conteúdos de media (estações de televisão, produtoras, organizadores de eventos…).
“Somos um bocado a cola do sistema.” Tipicamente alguém escolhe um tipo de câmara, outra pessoa escolhe o editor de vídeo, outro o sistema de armazenamento… e depois as coisas não comunicam entre elas, porque não estão preparadas para o fazer. O que a empresa faz é tecnologias de automação de fluxos de trabalho, em termos de movimentação de conteúdos (o que na indústria se chama de ingest), ou processamento de vários conteúdos em simultâneo. Têm soluções de software e também de hardware, que permitem entregar um produto chave-na--mão.
Além deste foco principal na área de produção/pós-produção, estão a diversificar as áreas de negócio, de forma a incluir também a área de distribuição (em pareceria com fornecedores de serviços de cloud, de modo a que o conteúdo chegue aos utilizadores de forma rápida e com qualidade).
Em termos de investigação, em que têm a oportunidade de fazer projetos que, não sendo o dia--a-dia da empresa, complementam a sua atividade.
O produto é desenvolvido consoante aquilo que o mercado e o cliente pedem. As necessidades de cada cliente são desenvolvidas e incorporadas no produto; não existem soluções costumizadas.
A empresa é constituída por cerca de 50 pessoas e organiza-se da seguinte forma:
• CTO (Chief Technology Officer): em conjunto com a direção, é responsável pelo roadmap da empresa em termos de desenvolvimento;
• gestor de projetos: é responsável pelo planeamento, consoante o roadmap;
• uma pessoa responsável pelo acompanhamento diário da equipa, para verificar que está tudo a ser cumprido conforme o planeamento;
58
• equipa de desenvolvimento de software, que de divide em 3 equipas, cada uma com um líder de equipa:
• media, que trata da parte de mais baixo nível do produto (codificação, recodificação, leitura de ficheiros);
• middleware, responsável por toda a lógica de negócio;
• interface gráfica, onde se insere um designer.
• equipa de qualidade de software, que valida as releases, com recurso a testes automáticos e testes manuais que têm por base os requisitos do cliente;
• equipa de vendas;
• equipa de marketing;
• equipa de apoio ao cliente, que dá assistência e, no caso de não ser possível resolver o problema, reporta à equipa de desenvolvimento de software;
• equipa de desenvolvimento de hardware;
• equipa de qualidade, que garante que a empresa segue os processos de gestão de acordo com as certificações;
• equipa administrativa e financeira.
Por um lado, existe o roadmap, onde constam as funcionalidades que a empresa julga serem importantes desenvolver. Por outro lado, há aquilo que o cliente pede.
Tipicamente, o cliente pede um orçamento ao departamento de vendas, que se passar por desenvolvimento de funcionalidades, é pedida uma estimativa a essa equipa. Assim que o cliente aceita as condições, o projeto é injetado de novo na equipa de desenvolvimento, calendarizando o desenvolvimento consoante as possibilidades. O gestor de projeto faz uma primeira alocação de pessoas, e o gestor de equipa reúne com a equipa e faz a distribuição de responsabilidades.
A partir dos requisitos do cliente, são feitas as especificações funcionais, mais tarde, a equipa de qualidade poder mais facilmente testar e validar o produto. Em seguida parte-se para o desenvolvimento propriamente dito, e o próprio developer faz alguns testes sobre aquilo que desenvolve.
Usam uma metodologia ágil, e no final de cada sprint é feita uma release que é passada à equipa de qualidade. Existe então um processo iterativo entre as equipas de desenvolvimento e qualidade. Assim que se chega a uma versão estável, que cumpre o que foi pedido, é feita uma release que é encapsulada no produto e enviada ao cliente.
O produto acaba por ser uma espécie de mix and match de funcionalidades consoante as necessidades do cliente. Existe um núcleo base, e embora o produto suporte todas as funcionalidades desenvolvidas, são incluídas apenas aquelas que o cliente necessita, pois exige um custo acrescentado.
A interface é desenhada de forma modular, para que o utilizador possa configurar a vista da forma que mais lhe convém. Apesar de existirem funções, tipicamente, os utilizadores apenas usam uma pequena parte delas no trabalho diário.
Entrevistas
59
O design da interface foca-se em atingir algo que seja funcional. Não existe muita margem para a criatividade, uma vez que nesta indústria já existe um modelo de como as coisas funcionam, sendo contraintuitivo ir noutra direção. São criados MOCKUPS e PROTÓTIPOS, que são depois apresentados e discutidos.
Preocupam-se com a usabilidade mas não são realizados testes, parte do bom-senso de quem está a desenhar a interface. Contam também com o feedback do cliente.
4.6 Empresa F
Posição do(s) entrevistado(s): Diretor de I&D Número de elementos: 50 a 60
Descrição: Software de sistemas de navegação para smartphones e automóveis.
Tipo de projetos desenvolvidos: N/A Metodologias e técnicas aplicadas: Fluxogramas
Wireframes Mockups Prototipagem (digital e interativa) Testes de usabilidade (remotos, e por empresa
externa) Grupos de Foco (empresa externa) Analíticas Recolha de feedback (clientes, beta testers,
utilizadores)
Nasceu em 2001 sob outro nome e outro tipo de atividade, e foi a primeira empresa a recolher informação georreferenciada, antes de haver Google Maps.
tinha um manancial de informação bastante grande e em 2004 decidiram criar uma equipa de desenvolvimento para criar um roteiro digital que pudesse correr em smartphone, que foi um pouco o advento dos GPS.
Na altura (2002/2003) os smartphones era um nicho de mercado.
Em 2007 houve um spinoff daí nasceu esta empresa, que se passou a dedicar-se exclusivamente aos sistemas de navegação. Numa primeria fase (2007–2011) incluia produção de hardware (PNGs: portable navigation devices) desenhavam o hardware e software.
Em 2008, com a crise económica, tiveram que tomar uma decisão e optam por enveredar apenas pelo software, que tem muitos menos custos associados e riscos de stock, produção, etc.
Hoje em dia a empresa faz apenas software e sistemas de navegação, seja para dispositivos móveis ou sistemas embebidos nos carros.
Portugal tem uma expressão muito pequena no no negócio. Nesse sentido, têm vários projetos, quase marca branca, feitos à medida com customizações e funcionalidades especificas para determinados clientes (empresas, operadoras...). Têm também a parte do negócio automóvel,
60
tanto o before market (o automóvel sai da fábrica com o sistema montado) como o after market (revendedores instalam o sistema posteriormente).
São cerca de 50 a 60 pessoas no Porto onde está a maior parte da empresa. Têm ainda dois pequenos escritórios comerciais, um em Lisboa e outro na China.
No Porto, cerca de dois terços são developers, têm 3 designers e ainda a a equipa de marketing e a equipa financeira.
Estão funcionalmente organizados em áreas. Funcionam um pouco como start-up, em equipas multidisciplinares. Não existem departamentos estanques, embora existam áreas funcionais:
• Core: , que é a parte fundamental do software, faz desenvolvimento da mesma e algum I&D.
• Área aplicacional: dividida em Android e iOS
• Mapas: fazem ferramentas de ingestão de informação geográfica.
• Controlo de Qualidade: 2 ou 3 pessoas no controlo de qualidade, que se divide em dois processos: processos automatizados de teste e testes parametrizados realizados manualmente. Para os últimos utilizam uma ferramenta onde estão definidos os testes e os passos a executar. Algo que ainda não têm mas pretendem investir é em testes automáticos de interface e funcionalidade.
• Devops: procura tratar da lógica de negócio do software; questões como o licenciamento de dados, conexão de diversos serviços, e servir os milhares de utilizadores ligados.
• Design: dividida em duas áreas, o design das aplicações e o design comunicacional da empresa (site, marketing…).
• Marketing: responsável pelo lado comunicacional da empresa e também ajudar os parceiros nas ações de marketing. Procura também monitorizar o comportamento dos utilizadores nas aplicações através das ANALÍTICAS. Isto permite perceber como os utilizadores usam ou não a aplicação, que funcionalidades são mais usadas, e permite tomar decisões no desenvolvimento.
Consoante os clientes, existem funcionalidades exclusivas de alguns clientes, porque faz sentido para o seu negócio, mas não para outros clientes; existem funcionalidades genéricas que se aplicam a todos os clientes; e existem algumas modificações das funcionalidades que têm a ver com parâmetros regionais.
Contudo, não existe um roadmap aberto a todos os clientes. Apenas aqueles que historicamente têm tido mais peso, têm alguma palavra a dizer na definição das funcionalidades.
O processo para chegar a uma nova versão começa por fazer um levantamento de funcionalidade que pretendem manter, modificar ou acrescentar.
Neste processo, usam plataformas de gestão (Redmine, Basecamp) e ferramentas como o InVision para visualização de MOCKUPS.
No caso específico do redesenho da aplicação, depois do levantamento de requisitos, houve uma discussão interna em que tentam perceber que há um ponto comum no caderno de encargos e que não falta nada de essencial.
Entrevistas
61
Fechado o caderno de encargos, dividem-se em áreas funcionais (mapas, flow de pesquisa, detalhe, planeamento da rota, navegação, definições…), que permite realizar um primeiro FLUXOGRAMA da aplicação e chegar aos primeiros WIREFRAMES. Estes são validados e só depois passam ao processo de design, que começa por PROTÓTIPOS interativos no InVision, mostrando o flow, e quando validado, têm toda a parte de export. Com as guidelines, especificações, redlines, assets, etc. é que os developers começam a implementar a aplicação.
Os processos são bastante paralelos, e isto reflete-se na disposição dos postos de trabalho, em que developers trabalham ao lado de designers.
Fazem releases alfa semanais, e a equipa de QA (Quality Assurance), com base nestas mesmas especificações são criados os testes automáticos e funcionais para a interface e vão validando aquilo que vai sendo desenvolvido.
As releases beta, têm um conjunto não muito alargado de beta testers, composto por pessoas externas e clientes que nos vão dando muito feedback. É algo que querem melhorar e evoluir para incluir por exemplo TESTES A/B ou GRUPOS DE FOCO.
Recentemente subscreveram uma plataforma paga de TESTES DE USABILIDADE com utilizadores reais, e já têm alguns dados, mas não os suficientes. O entrevistado considera que a questão dos testes é que é algo que é caro e é preciso ter algum foco ao fazê-lo. Assim sendo, têm vivido bastante da própria experiência, do beta testing bastante controlado, e do feedback dos clientes.
Neste projeto contrataram também uma empresa de UX (USER EXPERIENCE) que durante o processo de PROTOTIPAGEM fez TESTES DE USABILIDADE com GRUPOS DE FOCO, cujos resultados levaram a redesenhar algumas componentes da aplicação.
No sentido de tornar a aplicação intuitiva de usar, há uma preocupação em seguir as guidelines relativas a cada plataforma, de forma a que a ação executada pelo utilizador tenha o efeito esperado.
No caso de aplicações para clientes, fazem suporte de segundo nível (ou seja, suporte ao suporte desse cliente), enquanto que para as aplicações que se encontram sob a sua alçada, fazem o suporte e respondem a comentários nas páginas da aplicação ou redes sociais. Além de recolherem muito feedback desta forma, também criam uma relação com o cliente.
62
4.7 Empresa G
Posição do(s) entrevistado(s): Gestor de projeto Número de elementos: 16
Descrição: Empresa de prestação de serviços de design e desenvolvimento de produtos web e mobile.
Tipo de projetos desenvolvidos: Websites; Aplicações móveis; Produto interno.
Metodologias e técnicas aplicadas: Fluxogramas Wireframes Prototipagem (interativa) Personas (caso único) Recolha de feedback (cliente)
A empresa tem 2 anos e 4/5 meses e foi fundada por dois UI/UX designers, que começaram por trabalhar como freelancers com alguns projetos focados em UI/UX design e à medida que os projetos e os clientes foram crescendo fez sentido constituir a empresa.
Embora a forma como se apresentam comercialmente esteja focada no design, a empresa expandiu os seus conhecimentos para o desenvolvimento e neste momento são cerca de 16 pessoas.
Têm duas áreas de incidência: prestação de serviços e o produto interno (ainda em desenvolvimento).
Têm clientes em todo o mundo, principalmente start-ups norte americanas. Tanto fazem projetos apenas de design, apenas de desenvolvimento ou ambos.
A equipa alocada ao produto que estão a desenvolver é composta por um product manager, um product owner, 2 ou 3 developers, uma pessoa relacionada com copyright e marketing, e um designer.
Na prestação de serviços, têm uma grande equipa de UI/UX designers que dependendo da complexidade dos projetos podem ser alocados a um ou vários projetos. Têm também uma equipa de desenvolvimento principalmente composta por frontend developers ou UI developers.
Têm vários projetos ao mesmo tempo, normalmente entre os 10 e os 30. Costumam ter projetos de meses o que faz com que haja um compromisso com esses clientes, o que não permite a entrada de novos.
Têm projetos de variadas complexidades, desde sites com uma única página a sites com um grande volume de informação.
A calendarização dos projetos varia, há clientes que têm 10 dias para fazer um projeto, se tudo correr bem. Há projetos a longo prazo que têm determinados objetivos, têm um marco a longo prazo e o tempo até lá dividido em tranches mais pequenas com tarefas mais reduzidas para obter objetivos mínimos mais reduzidos e cuja soma das partes vai dar ao projeto final.
As pessoas são alocadas aos projetos tanto pela sua formação que é uma mais valia para o projeto, como para saírem da sua zona de conforto e poderem evoluir outras competências.
Entrevistas
63
O foco está na qualidade, pelo que sendo necessário alargar o prazo de entrega (dentro do razoável), é preferível a entregar algo que não tem a qualidade esperada.
O projeto começa no primeiro contacto comercial, em que se tenta tirar o máximo de informação possível do cliente sobre o projeto. A avaliação é feita pelo gestor de projeto e chega-se a um consenso do orçamento. O cliente concordando chega-se a uma data. Faz-se o planeamento com 2 a 4 semanas de antecipação. Alocam X horas ao projeto e antes de se iniciar o projeto faz-se uma preparação do set-up do projeto e de todas as ferramentas que vão ser necessárias.
A partir do momento que está tudo pronto para arrancar com o projeto há uma reunião com a equipa. É repartido o projeto em partes (conforme cada projeto e informação que o cliente traz) e são planeadas 2 ou 3 apresentações semanais por secções ou funcionalidades.
Uma vez que trabalham com outros países aproveitam a diferença horária como vantagem, repartindo o trabalho e os contactos com os clientes conforme o fuso horário.
Todos os dias têm um objetivo e uma apresentação no final do dia. As tarefas são reduzidas ao mínimo e a comunicação com os clientes é aberta: poucas reuniões burocráticas, chamadas quando necessário, comentários no InVision, comunicação via Basecamp, via Slack. Existe uma grande interação com o cliente, que rapidamente dá feedback, permitindo a iteração rápida do projeto. No design ou no desenvolvimento faz-se um sprint de uma semana com múltiplas apresentações ao cliente.
No que toca à documentação, fazem um roadmap, gráficos de Gantt, FLUXOGRAMAS da navegação do produto, UI kits, styleguides, WIREFRAMES, PROTÓTIPOS em InVision.
No caso do produto interno realizaram PERSONAS baseadas nas próprias experiências e suposições acerca dos potenciais utilizadores, mais para serem usadas na parte de marketing que no desenvolvimento do produto.
Fazem a avaliação do projeto (debugging e QA) internamente. O cliente também dá feedback. Nalguns casos, o cliente prefere fazer a avaliação ou por exemplo lançar uma versão beta para receber feedback de utilizadores.
Utilizam metodologias ágeis, para desenvolvimento algo mais parecido com SCRUM e para design algo mais parecido com KANBAN.
Após a entrega do projeto, podem existir alguns ajustes, correções de erros, ou manutenção. Enviam também um inquérito de satisfação para avaliar o sucesso do projeto.
64
4.8 Equipa H
Posição do(s) entrevistado(s): Consultor e Gestor (Empresa mãe) e CTO (Produto) Número de elementos: 5
Descrição: Ferramenta online de gestão de processos e projetos baseada em metodologias como Agile e CMMI.
Tipo de projetos desenvolvidos: N/A Metodologias e técnicas aplicadas: User Stories
Wireframes Mockups (estáticos e interativos) Recolha de feedback
Enquanto CTO do projeto, é responsável por tudo, desde a parte de negócio – como vendem, preços, contacto com clientes – contratação da equipa de desenvolvimento, e a metodologia que usam, neste caso SCRUM.
A empresa em que se insere o produto presta serviços de consultoria de melhoria contínua. Normalmente, a raiz do problema das empresas-cliente é a falta de normalização de processos dentro da organização. Tentam então estandardizar a melhor forma de trabalhar para a empresa, seguindo ou não uma metodologia específica. Para “produtizar” o seu conhecimento enquanto consultora, criaram um produto que se tornou um departamento autónomo.
O produto é uma ferramenta online de gestão de processos e de projetos baseada em processos chave-na-mão, metodologias como o Agile e CMMI (Capability Maturity Model Integration), entre outras, que ajudam as empresas a seguir determinadas boas práticas e a adaptá-las à sua forma de trabalhar.
A equipa é constituída pelo CTO, 3 programadores e um designer.
A metodologia SCRUM aplicada consiste em iterações (sprints) semanais. No início da semana é feita uma reunião onde é feita a revisão da semana anterior e o planeamento da semana seguinte. A chefe de equipa (scrum master) é responsável por garantir as reuniões diárias onde é reportado o trabalho do dia anterior e identificadas as tarefas desse dia.
As necessidades podem vir de vários sítios; do mercado, dos clientes, e da própria organização.
Uma vez que se trata de Software as a Service (SaaS), não desenvolvem funcionalidades unicamente para um cliente. Ao desenvolver funcionalidades atendendo às necessidades de um cliente, estas ficam disponível para todos.
O entrevistado é responsável por tentar perceber exatamente qual é a necessidade ou ideia para transformá-la numa USER STORY que seja o mais clara possível e percetível para a equipa a possa desenvolver. A equipa faz a distribuição de tarefas de forma autónoma, atendendo à dificuldade da tarefa e à experiência dos elementos.
Principalmente em novas funcionalidades, é feito um primeiro MOCKUP: em casos simples, é feito apenas um MOCKUP estático e em casos mais complexos são feitos WIREFRAMES adicionais. Por vezes, são também realizados MOCKUPS interativos, recorrendo à ferramenta Invision.
Entrevistas
65
Não se justifica investigação sobre os utilizadores (user research), dada a dimensão da equipa. Contudo, num contexto informal, fazem validações com os clientes, quer no processo de design como de implementação.
Da parceria com uma faculdade surgiu a oportunidade de usar uma unidade curricular como base de testes. Antes até de lançar o produto ao público, foram testadas duas versões.
É bastante útil porque são muitos utilizadores e oferecem bastante e honesto feedback. São ainda as próximas pessoas a entrar no mercado, que potencialmente irão usar uma ferramenta deste género.
Ter esta base de testes permite que sejam tomados riscos e sejam testadas versões ainda instáveis, possibilitando a aprendizagem por parte da equipa. Se fosse fornecida uma versão estável, não iriam aprender tanto com o feedback dos utilizadores.
Quanto a dados quantitativos, existem ANALÍTICAS de tudo. Sabem claramente o que é clicado e quando (e podem tentar perceber porquê) e quais as funcionalidades mais utilizadas. Para o contexto da unidade curricular, criaram uma auditoria mais avançada, com base naquilo que era considerado uma boa gestão de projeto a fim de premiar a equipa que fizesse melhor uso da plataforma. Esta ferramenta acabou por ser mantida.
O feedback que recebem surge através da própria plataforma (que possui um formulário para comentários ou submissão de bugs), mas também diretamente dos clientes, com os quais mantêm uma relação próxima.
Não sendo a única plataforma de gestão de projetos existente no mercado, o dia-a-dia da empresa enquanto consultora informa as necessidades do mercado e dos clientes. Aprendem com as falhas das outras tecnologias e com a utilização de outras ferramentas (TFS (Team Foundation Server), JIRA, Trello…), e tentam perceber que funcionalidades semelhantes existem e de que forma podem tornar o produto melhor e mais competitivo.
Em termos de documentação, é feita a documentação do código, as USER STORIES descritas em detalhe e as tarefas que lhe estão associadas, MOCKUPS e WIREFRAMES. Usam a própria plataforma para gerir esta documentação, existindo ainda um backup no Google Drive, que facilita, por exemplo, a partilha de documentos com alguém externo.
66
4.9 Empresa I
Posição do(s) entrevistado(s): Designer Número de elementos: 15
Descrição: Tecnologia para o retalho. Tipo de projetos desenvolvidos: Sistemas de atendimento;
Sinalética digital; Mupis; Painéis de LED; Produção de vídeo: Aplicações Móveis; Rede de publicidade.
Metodologias e técnicas aplicadas: Fluxogramas Personas (pouco comum) Mockups Testes A/B Recolha de feedback (informal, clientes, utilizadores)
A empresa trabalha em tecnologias para o retalho, tendo como foco principal os sistemas de atendimento. Criam também sinalética digital, mupis, painéis LED, produção de vídeos para passar nos mesmos painéis, aplicações móveis e têm uma rede de publicidade.
São cerca de 15 pessoas, estando o número a aumentar. 3 são designers e os restantes são quase todos engenheiros de software. Costumam também receber vários estagiários curriculares.
Na equipa de design as funções estão relativamente definidas, um trata da parte mais administrativa (gestão dos canais, colocação de vídeos), outro trata mais da parte criativa (design de interfaces, produção de vídeo). Certas tarefas, qualquer um as executa. No caso de websites, qualquer designer os pode fazer, sendo que tendo alguma dificuldade, rapidamente pede ajuda aos colegas da informática. Quando o fluxo de trabalho é muito grande, é repartido por vários elementos da equipa.
Não se limitam a funções unicamente de design, tentado ser o mais autónomos possível. Na empresa, um designer faz de tudo, desde criação de vídeo, websites, e até mesmo Linux. O sistema que criaram permite que os vídeos sejam colocados no ecrã dos clientes à distância. Ao aprender um pouco de Linux, a equipa de design tem autonomia para colocar diretamente os vídeos após a produção, sem que seja necessário passar pela equipa de informática.
Têm uma série de clientes que procuram (e têm capacidade para) inovar, e a empresa ajuda-os a fazê-lo. Por exemplo, desenvolveram o primeiro sistema de senhas a partir de uma aplicação móvel. Com clientes com maior dimensão, o processo de tomada de decisões e chegada a um acordo é mais demorado, o que leva a que alguns projetos demorem bastante tempo até serem desenvolvidos.
O processo de desenvolvimento varia consoante o projeto.
Usam uma metodologia Lean, que consiste em iterações muito rápidas. O objetivo é atingir um MVP (Minimum Viable Product), um produto com as potencialidades mínimas, e continuar a melhorar a partir daí.
Entrevistas
67
Em projetos complexos, a equipa reúne-se toda, obrigatoriamente. Em projetos mais simples, por vezes é só necessário a equipa de design fazer uma proposta à equipa de engenharia, que ao ser validada, o projeto é iniciado. Com prazos muito curtos, a equipa de engenharia avança com o projeto e no final a equipa de design tenta “dar uma nova vida” ao projeto.
Nas reuniões, tentam saber logo o que é possível ou não fazer, para não perderem tempo. Conversam sobre o que será o produto, quais os objetivos, funcionalidades. Podem já haver ideias sobre como poderá ser a interface, e começam, em conjunto, a fazer ESBOÇOS no quadro branco ou no caderno. Estes MOCKUPS passam depois para um designer que os irá trabalhar, a fim de demonstar o “look and feel” da aplicação.
Dado o tempo reduzido para criar um MVP, não têm, normalmente, uma fase intermédia entre os ESBOÇOS em papel ou no quadro, e a interface final. Por vezes isto traz alguns problemas, quando a interface já está desenhada em alta fidelidade e é necessário fazer uma pequena mudança. Por vezes optam por voltar um pouco atrás e desenhar a interface numa fidelidade média para perceber qual a melhor forma de fazer a alteração.
Pelo menos uma vez por semana tentam reunir para ver o estado do projeto. No entanto, vão comunicando ao longo da semana.
O QA (Quality Assurance) é feito, normalmente, pelos chefes de departamento. A entrevistada também faz muitas vezes QA pela capacidade de “destruir as aplicações” com facilidade. Por vezes, quando há pouco tempo, para garantir que o produto é lançado com o número mínimo de erros é necessário que toda a equipa faça QA.
Não recorrem a nenhum tipo de guião, tentam apenas comportar-se como um utilizador típico, ou como um utilizador “arruaceiro”, cujo objetivo é quebrar a aplicação. A entrevistada refere que esta postura fora do comum se tem revelado positiva.
Às vezes as aplicações também são testadas de forma mais informal, com amigos ou família, e até mesmo no contexto em que são supostas ser usadas, que é sempre diferente de o fazer no escritório.
Geralmente as aplicações têm opção para enviar feedback, pelo que também isso os ajuda a corrigir erros e melhorar os produtos.
Por vezes fazem TESTES A/B, mas não é muito comum, por não terem muito tempo disponível.
Como fazem aplicações para o retalho e já estão habituados ao público-alvo das mesmas, não consideram necessário criar PERSONAS. Apesar disso, havendo tempo, são criadas as PERSONAS, o que torna a documentação do projeto fique mais completa.
Criam também FLUXOGRAMAS para documentar as interações dentro das aplicações.
Têm uma relação próxima com o cliente, que vai dando feedback sobre a aplicação e inclusive, testa-a antes de ser lançada.
Existe bastante liberdade, mas por vezes existem certas condicionantes. Por exemplo, no caso de o cliente ter já uma linha de aplicações (desenvolvidas por empresas diferentes), embora possa não ser o ideal, é necessário manter uma coerência com o que já existe, tanto no funcionamento como na parte visual.