Experiência do Utilizador Aplicada a
Sistemas de Resolução de Problemas
por Tickets: O Caso do iPTicket
Miguel Ângelo Pinto Sampaio
Mestrado Integrado em Engenharia Eletrotécnica e de Computadores Orientador: Eurico Manuel Elias de Morais Carrapatoso Orientadora Externa: Telma Cristina Marques Salgueiro
Entidade Externa: IPBRICK
Este trabalho abordou a experiência do utilizador aplicada a sistemas de resolução de proble-mas por tickets entre empresas. Com a evolução das páginas web de um meio estático para um meio mais dinâmico e interativo as empresas necessitam cada vez mais de recorrer à experiência do utilizador por forma a tornarem-se mais competitivas e criarem produtos mais apelativos. Em-bora o conceito de experiência do utilizador não seja um conceito de fácil compreensão por não existir apenas uma definição do que é, podemos defini-la como o que o utilizador obtém e o que este sente antes, durante e após a utilização de um produto, como uma página web ou uma aplica-ção. Geralmente este conceito aparece muitas vezes associado aos conceitos de design da interface do utilizador e usabilidade embora estes sejam apenas algumas das áreas trabalhadas pela UX. A interface do utilizador define-se como a forma como os utilizadores interagem com uma máquina ou um sistema por forma a conseguirem realizar os seus objetivos, enquanto que a usabilidade é um atributo qualitativo que indica a facilidade em manipular uma interface. Durante o trabalho foram estudadas as normas e práticas mais comuns ao nível da experiência do utilizador e da in-terface do utilizador, mostrando as novidades nestas áreas, dando exemplos de outros sistemas de trouble tickete abordando as várias fases de um projeto de design da UX: planeamento da estraté-gia a seguir, definição dos objetivos e requisitos, criação do conceito visual e de interação, análise dos modelos mentais e de implementação, escolha dos princípios para a construção dos mesmos e produção do protótipo. Com base nestas normas foi apresentado um design da experiência do utilizador para sistemas de resolução de problemas por tickets analisando a estrutura que deve ser utilizada, os seus principais grupos de utilizadores, a forma como as interfaces devem ser apresen-tadas e o feedback que estes devem dar. Este design foi depois validado no iPTicket, o sistema de trouble ticketda IPBRICK, sendo para tal necessário analisar a sua estrutura inicial, realizar uma analise heurística para obter as áreas mais necessitadas e produzir os requisitos do projeto com base nos seus principais grupos de utilizadores e nos stakeholders. Foi também abordada a fase de implementação do projeto contendo as novas funcionalidades desenvolvidas, as alterações nas interfaces e no sistema de email que se basearam sempre nas necessidades dos utilizadores para realizarem os seus objetivos. Numa fase final foram analisados os resultados obtidos, as melhorias ao nível da UX provocadas pelos desenvolvimentos e possíveis abordagens para trabalhos futuros nestas áreas.
This work addressed the user experience applied to trouble ticketing systems between compa-nies. With the evolution of web pages from a static medium to a more dynamic and interactive environment, companies increasingly need to tap into user experience to become more competi-tive and create more appealing products. Although the concept of user experience is not easy to understand because there is not only a single definition of a good design, we can define it as what the user gets and what he feels before, during and after using a product, such as a web page or an application. Usually these concepts are often associated with the concepts of UI design and usability, although these are just some of the areas that UX works with. The user interface is defined as how users interact with a machine or system in order to achieve their goals, while usa-bility is a qualitative attribute that indicates the ease in handling an interface. During the work, the most common norms and practices at the level of user experience and user interface were studied, showing the news in these areas, giving examples of other trouble ticket systems and addressing the various phases of a UX design project: planning of the strategy to follow, definition of the objectives and requirements, creation of the visual and interaction concept, analysis of the mental and implementation models, choice of the principles to construct them and production of the pro-totype. Based on these standards, it was presented a user experience design for trouble ticketing systems with an analysis of the structure that it should use, its user groups, the way interfaces should be presented and the feedback it has to give. This design was then validated on iPTicket, the IPBRICK helpdesk system, for which it was necessary to analyse its initial structure, perform a heuristic analysis to obtain the most needed areas and produce the project requirements based on its main groups of users and stakeholders. It also addressed the implementation phase of the project containing the new developed features, changes in the interfaces and in the email system based on the needs of its users to achieve their goals. In a final phase it was analyzed the results obtained, the improvements at UX level provoked by the developments and possible approaches for future work in these areas.
Em primeiro lugar gostaria de agradecer à IPBrick pela oportunidade de desenvolver este projeto nas suas instalações e por me dar o suporte necessário para a sua realização. Agradeço também ao meu orientador, o Professor Eurico Carrapatoso, por toda a ajuda e motivação durante o desenvolvimento deste trabalho, à minha orientadora externa, a Telma Salgueiro, por todo o suporte tanto na empresa como no projeto, ao Miguel Teixeira, ao Marco Pinto e aos meus restantes colegas da IPBRICK pelas horas despendidas a explicar-me o funcionamento do iPTicket e a ajudar-me na resolução dos mais variados problemas. A um nível mais pessoal quero agradecer aos meus pais porque sem eles e sem o seu sacrifício nunca teria a possibilidade de começar este trabalho, à minha família, à Cláudia Faria e aos meus restantes amigos por toda a motivação que me deram durante todo este período. A todos os referidos e aos demais que não vêem aqui o seu nome, mas que me ajudaram neste percurso um grande obrigado por tudo, esta tese também é em parte vossa.
Miguel Sampaio
Alan Cooper
1 Introdução 1
1.1 Enquadramento . . . 1
1.2 Objetivos . . . 2
1.3 Motivação . . . 3
1.4 Metodologia e ferramentas usadas . . . 4
1.5 Estrutura da dissertação . . . 4
2 Normas e práticas mais utilizadas ao nível da UX e UI 7 2.1 Projetar o design da experiência do utilizador . . . 7
2.1.1 Planear a estratégia e abordagem a seguir . . . 8
2.1.2 Definição dos objetivos e dos requisitos do projeto . . . 10
2.1.3 Design do conceito visual e de interação . . . 12
2.1.4 Design dirigido por metas, modelos de implementação e modelos mentais 14 2.1.5 Princípios para a criação do design e da interação . . . 15
2.1.6 Criação do protótipo, desenvolvimento e testes . . . 15
2.2 Exemplos de sistemas de resolução de problemas por tickets existentes . . . 16
2.3 Novas abordagens e tecnologias . . . 18
3 Design da UX em sistemas de resolução de problemas 21 3.1 Estrutura . . . 22
3.2 Perfis a utilizar . . . 23
3.3 Interfaces visuais . . . 26
3.4 Feedback . . . 30
4 Design da UX do iPTicket 33 4.1 Estrutura inicial do iPTicket . . . 33
4.1.1 Assistências . . . 33 4.1.2 Definições . . . 35 4.1.3 Workflow . . . 36 4.1.4 Problemas . . . 38 4.1.5 Área pessoal . . . 39 4.2 Análise heurística . . . 39 4.3 Requisitos do projeto . . . 42
5 Implementação do design da UX do iPTicket 47 5.1 Alterações nas interfaces . . . 47
5.2 Novas funcionalidades . . . 53
5.3 Email e feedback ao utilizador . . . 58
5.4 Resultados obtidos . . . 60
6 Conclusão 63 A Interfaces do iPTicket 65 A.1 Interfaces iniciais do iPTicket . . . 65
A.1.1 Assistências . . . 65
A.1.2 Definições . . . 67
A.1.3 Workflow . . . 71
A.1.4 Problemas . . . 74
2.1 Página principal da IPBRICK [IPBRICK]. . . 8
2.2 Página principal do sistema iPTicket [iPTicket, 2019]. . . 9
2.3 Exemplos de partes do mapa do site da FEUP. . . 13
2.4 Exemplo de um fluxo de tarefas representando o sistema de login e registo. . . . 13
2.5 Exemplo de um wireframe com anotações. . . 14
2.6 Design da aplicação Freshdesk [Freshdesk, 2018]. . . 16
2.7 Design da aplicação Zendesk [Zendesk]. . . 17
2.8 Design da aplicação UVdesk [UVdesk]. . . 17
2.9 Wireframeda aplicação UVdesk [Nitish, 2017]. . . 18
3.1 Fluxo de trabalho de um assistente. . . 24
3.2 Fluxo de trabalho de um queixoso. . . 25
3.3 Wireframeda interface geral do sistema de resolução de problemas. . . 26
3.4 Wireframeda lista de assistências ou de problemas. . . 28
3.5 Wireframedos formulários de inserção de novos problemas e assistências. . . 29
3.6 Wireframeda página de um problema ou assistência. . . 30
4.1 Barra de navegação do iPTicket. . . 33
4.2 Workflowbase do iPTicket. . . 37
4.3 Área pessoal do iPTicket. . . 39
5.1 Interface do tipo de assistência antes das alterações. . . 48
5.2 Interface do tipo de assistência depois das alterações. . . 48
5.3 Ícone com mensagem de ajuda sobre o campo "limite de horas para total de horas". 49 5.4 Nova interface do filtro das ações. . . 50
5.5 Wireframeda interface ações a realizar. . . 50
5.6 Interface das ações a realizar contendo as alterações dos tickets encaminhados e da data limite. . . 51
5.7 Interface da lista de problemas com os ícones realçando as datas limites. . . 52
5.8 Interface dos indicadores após as alterações. . . 52
5.9 Nova funcionalidade que permite a inserção de várias assistências de uma vez. . . 54
5.10 Interface do filtro de assistências com utilizadores inativos. . . 55
5.11 Wireframe da interface de inserção de um novo grupo. . . 55
5.12 Interface de gestão de grupos. . . 56
5.13 Interface de gestão do perfil de um utilizador externo. . . 57
5.14 Interface de dos tickets pausados. . . 58
5.15 Interface onde é possível pausar problema. . . 58
5.16 Interface de edição do email sobre a mudança de workflow. . . 60
A.1 Menu das assistências. . . 65
A.2 Formulário de inserção de uma nova assistência. . . 65
A.3 Listagem dos tipos de assistências. . . 66
A.4 Formulário de inserção e edição de um tipo de assistência. . . 66
A.5 Listagem das assistências realizadas. . . 66
A.6 Relatório das assistências realizadas. . . 67
A.7 Filtro das assistências realizadas. . . 67
A.8 Menu das definições. . . 67
A.9 Interface de gestão dos utilizadores. . . 68
A.10 Interface de gestão dos perfis dos utilizadores. . . 68
A.11 Interface do IPBRICK.Contacts. . . 68
A.12 Interface das configurações gerais. . . 69
A.13 Interface da configuração da LDAP. . . 69
A.14 Interface da gestão das contas de suporte. . . 69
A.15 Interface da gestão dos contratos de assistências. . . 70
A.16 Interface para a configuração de um email automático. . . 70
A.17 Interface para definição do horário de trabalho. . . 70
A.18 Interface para definição do email de resposta. . . 71
A.19 Menu worklow. . . 71
A.20 Listagem de templates de workflows. . . 71
A.21 Editor de workflows. . . 72
A.22 Formulário de inserção de um novo estado. . . 72
A.23 Formulário de inserção de uma nova ação. . . 72
A.24 Formulário de inserção de uma nova função de transição. . . 73
A.25 Interface de instanciação do workflow. . . 73
A.26 Interface de configuração de workflows e respetivo aviso de confirmação. . . 73
A.27 Interface de remoção de workflows. . . 74
A.28 Menu dos problemas. . . 74
A.29 Interface da listagem dos problemas. . . 74
A.30 Interface da listagem das ações a realizar. . . 75
A.31 Interface da listagem dos problemas que passaram a data limite. . . 75
A.32 Formulário de criação de novo problema. . . 75
A.33 Interface de erros aquando da criação de novo problema. . . 76
A.34 Interface de informação do problema. . . 76
A.35 Interface de alteração do problema. . . 76
A.36 Interface da cronologia do problema. . . 77
A.37 Interface do filtro dos problemas. . . 77
A.38 Interface do relatório dos problemas. . . 77
A.39 Interface para realização de ações. . . 78
A.40 Interface dos problemas abertos. . . 78
A.41 Interface de cancelar problemas. . . 78
A.42 Interface para associar utilizador aos tipos de problemas. . . 79
A.43 Interface das estatísticas e indicadores. . . 79
A.44 Listagem das configurações de problemas. . . 79
A.45 Interface de configuração dos dados a visualizar ao reportar problemas. . . 80
A.46 Interface de configuração dos graus de satisfação. . . 80
4.1 Lista de requisitos do projeto. . . 45 B.1 Análise heurística ao iPTicket. . . 86
AJAX Asynchronous JavaScript And XML BCC Blind Carbon Copy
CAT Contrato de Assistência Técnica CC Carbon Copy
CSV Comma-Separated Values FAQ Frequently Asked Questions HTML HyperText Markup Language JPEG Joint Photographic Experts Group JS JavaScript
LDAP Lightweight Directory Access Protocol PHP PHP: Hypertext Preprocessor
PNG Portable Network Graphics SVG Scalable Vector Graphics UI User Interface
UX User Experience WOFF Web Open Font Format WOFF2 Web Open Font Format 2.0 WYSIWYG What You See Is What You Get
Introdução
1.1
Enquadramento
Com a evolução das páginas web de um meio estático para um meio mais dinâmico e interativo as empresas necessitam cada vez mais de recorrer à experiência do utilizador por forma a tornarem-se mais competitivas e criarem produtos mais apelativos. Embora o conceito de experiência do utilizador (UX - User Experience) não seja um conceito de fácil compreensão por não existir ape-nas uma definição do que é, podemos defini-la como o que o utilizador obtém e o que este sente antes, durante e após a utilização de um produto, como uma página web ou uma aplicação [De-rome, 2018]. Esta experiência inclui todas as emoções, preferências, respostas e comportamentos do utilizador que resultam da imagem, apresentação, funcionalidade, performance, interatividade e capacidade de ajuda. A UX tem como principal objetivo contribuir para o desenvolvimento de um produto por forma a ajudar o utilizador a atingir os seus objetivos acrescentando-lhe valor e tornando esse processo mais fácil e agradável. Russ Unger e Carolyn Chadler indicam no seu livro A Project Guide to UX Design: For user experience designers in the field or in the making a seguinte definição para o conceito de design da experiência do utilizador:
“O design da experiência do utilizador é a criação e sincronização de elementos que afetam a experiência do utilizador com uma empresa, em particular com a intenção de influenciar as suas perceções e comportamentos.” [Unger and Chandler, 2012, Ca-pítulo 1: The Tao of UXD].
Geralmente este conceito aparece muitas vezes associado aos conceitos de design da inter-face do utilizador e usabilidade embora estes sejam apenas algumas das áreas trabalhadas pela UX. A interface do utilizador (UI - User Interface) define-se como a forma como os utilizadores interagem com uma máquina ou um sistema por forma a conseguirem realizar os seus objetivos recorrendo a várias componentes de hardware e software para com ele interagirem e o controla-rem [Christensson, 2009]. Já a usabilidade é um atributo qualitativo que indica a facilidade em manipular uma interface e baseia-se em cinco importantes componentes: o quão fácil de aprender a interface é, o quão eficaz ela é, o quão fácil é recordar o seu funcionamento quando a voltamos a
utilizar, quantos erros esta nos leva a cometer e a satisfação que nos traz quando comparada com as principais alternativas [Nielsen, 2012]. Tanto a UX como a UI de um produto são extremamente importantes, sendo dos fatores que mais influenciam o grau de satisfação dos utilizadores face a um produto e a imagem que têm de uma marca.
Um sistema de resolução de problemas por tickets, ou trouble ticketing system, tem como objetivo fazer a ligação entre os clientes de uma empresa e a sua equipa de suporte por forma a que possam apresentar os seu problemas e obter a ajuda necessária para os resolver. Geralmente o utilizador deverá submeter um ticket descrevendo o seu problema através de uma de várias plataformas, como a interface web do sistema, o email ou as redes sociais. Esse ticket irá depois entrar num de vários workflows dependendo do tipo de problema apresentado e um dos assistentes será destacado para fornecer o suporte necessário para tentar resolver o problema indicado.
Este trabalho foi realizado nas instalações da IPBRICK, SA em Vila Nova de Gaia. A IP-BRICK foi fundada em maio de 2000 para se dedicar à aplicação de tecnologias open source para empresas da cidade do Porto tendo-se especializado no desenvolvimento e distribuição de soluções de comunicações empresariais. Os seus principais objetivos são apresentar soluções ao nível do email e ferramentas colaborativas com o IPBRICK.MAIL, das comunicações unificadas com o IP-BRICK.UCoIP, da gestão de documentos e processos com o IPBRICK.iPortalDoc, e de workspace digital com o IPBRICK.CAFE, sendo todos estes serviços baseados no sistema IPBRICK.OS. O iPTicket é um sistema de helpdesk e trouble ticket com motor de workflow baseado em máquinas de estados e que usa como sistema de gestão de base de dados PostgreSQL. O registo de tickets nesta aplicação é efetuado por filtragem de emails ou através da sua interface web, sendo que esta aplicação não só é usada pelo suporte da IPBRICK para tais serviços de assistência aos seus clientes como também é comercializada a outras empresas, como a SONAE e a Expandindustria.
1.2
Objetivos
O trabalho desenvolvido teve como principais objetivos o desenvolvimento de uma proposta de design da experiência do utilizador ao nível de sistemas de resolução de problemas por tickets com uma vertente puramente empresarial e a validação dessa mesma proposta com o sistema iPTicket. Para alcançar estes objetivos foi necessário estudar as normas e práticas mais recentes ao nível do design da experiência do utilizador, do design da interface do utilizador e da usabilidade, em especial no caso dos sistemas de helpdesk. Foram também propostos princípios para a UX de um sistema de trouble ticketing e desenvolvidos designs de interação, designs de interfaces e de modos de interligação destas mesmas interfaces ao nível deste tipo de sistema, respeitando o que foi estudado. Para isso foi necessário usar ferramentas de desenvolvimento de UX como wireframes e fluxos de tarefas. Os princípios seriam depois aplicados ao caso particular do produto iPTicket, sendo necessário estudar os seus principais problemas de usabilidade e experiência do utilizador e propostas de potenciais soluções para os mesmos por forma a tentar responder às necessidades dos seus utilizadores. Para tal seria necessário um estudo dos objetivos da empresa e dos principais grupos de utilizadores para identificar os requisitos finais do projeto, criar novas funcionalidades
e desenvolver tanto para a interface web do iPTicket como o seu serviço de email. Numa fase final pretendia-se testar essas potenciais melhorias junto dos utilizadores recorrendo a testes de usabilidade para verificar o seu efeito e retirar conclusões.
1.3
Motivação
Sendo o principal objetivo da experiência do utilizador tentar preencher as necessidades de todos os utilizador e o de um sistema de resolução de problemas por tickets fornecer suporte aos seus utilizadores, sejam eles utilizadores singulares ou empresas, faz todo o sentido tentar aliar os benefícios que a experiência do utilizador pode trazer a estes sistemas de ajuda para melhorar uma experiência que pode ser muito frustrante para ambas as partes. Se os trabalhadores de uma equipa de suporte que passam grande parte do seu dia em contacto com estes sistemas puderem passar a usufruir de um sistema melhorado que os apoie no seu fluxo de trabalho isso irá ajudá-los a realizar as suas tarefas de uma forma mais rápida, eficaz e com mais qualidade. Esta junção poderá beneficiar muito os utilizadores, dos mais inexperientes aos mais habituados a utilizar estes sistemas, ajudando-os na busca de informação e de soluções para os seus problemas. Um aumento nos níveis de usabilidade poderá retirar alguma da frustração dos utilizadores destes sistemas devido à melhoria nos serviços prestados, o que irá provocar uma melhor opinião dos utilizadores sobre a prestadora destes serviços. A empresa poderá beneficiar não só de uma melhoria na sua imagem e na satisfação dos seus clientes como de um aumento de produtividade por parte dos seus assistentes, razões mais do que suficientes para apostar neste conceito.
Embora já existam algumas aplicações de helpdesk a conseguirem obter elevados níveis de UX entre empresas e os seus utilizadores singulares, o mesmo não pode ser dito para soluções puramente empresariais, havendo ainda muitos princípios de usabilidade que não são respeitados. Muitas vezes os sistemas empresariais são desenvolvidos tendo em conta unicamente a funciona-lidade e não procurando oferecer a melhor solução que ajude os seus clientes e parceiros a atingir os seus objetivos, desleixando a usabilidade e o design das interfaces do sistema.
Tal como em outros sistemas de resolução de problemas, os colaboradores da IPBRICK que prestam suporte aos clientes passam muito tempo do seu dia em contacto com o iPTicket. As alterações ao nível da experiência do utilizador poderão levar a melhorias muito significativas no fluxo de trabalho e na produtividade dos mesmos podendo ser alcançadas melhorias nos tempos e na qualidade da resposta, o que deixará os clientes e parceiros mais satisfeitos com os serviços prestados. O sistema iPTicket é um sistema com algumas lacunas ao nível das interfaces visuais e da usabilidade daí que o estudo e os desenvolvimentos com base nestas temáticas possa trazer melhorias significativas na qualidade do sistema tanto para utilização interna como para revenda a outros parceiros.
1.4
Metodologia e ferramentas usadas
Numa primeira fase do trabalho foi necessário avaliar o sistema do iPTicket e ter uma primeira imagem do estado inicial do mesmo realizando testes com vários princípios, sendo que para tal foram usadas algumas das heurísticas de Nielsen debatidas mais à frente no Capítulo 2. Estes testes resultaram num pequeno relatório inicial de áreas a melhorar, contendo algumas sugestões para possíveis alterações. A identificação dos requisitos do projeto teve em conta os requisitos da empresa que foram obtidos numa reunião com os principais stakeholders e os requisitos do utilizador produzidos através de um estudo dos principais grupos de utilizadores, recorrendo a entrevistas com os mesmos e a inquéritos contextuais, que implicaram uma visualização passiva de vários elementos do suporte da empresa a utilizarem o iPTicket no seu dia a dia para perceber quais eram os seus hábitos, como trabalhavam e de que necessitavam.
Para os desenvolvimentos no design da UX aplicados a sistemas de resolução de problemas por tickets foi feito um estudo dos principais sistemas para perceber o estado da arte neste campo sendo utilizadas ferramentas como wireframes e fluxos de tarefas para produzir respetivamente o design das interfaces e a forma como as relacionar. Aplicando depois esse trabalho ao iPTicket fo-ram usadas linguagens de progfo-ramação web como HTML, CSS, JS, AJAX e PHP, um ffo-ramework webchamado Bootstrap para o desenvolvimento de algumas componentes da interface e o ambi-ente de desenvolvimento Netbeans por serem as ferramentas usadas pela empresa nestas áreas. Foi também necessário alterar a estrutura da base de dados deste sistema para incorporar os desenvol-vimentos e melhorias efetuadas, usando para isso PostgreSQL.
1.5
Estrutura da dissertação
Esta dissertação encontra-se dividida em seis capítulos. O Capítulo 1 teve como objetivo in-troduzir o tema desta dissertação, fazendo o seu enquadramento, falando dos principais objetivos e da motivação, abordando também as metodologias e ferramentas usadas e a estrutura deste do-cumento.
No Capítulo 2 serão abordadas as normas e práticas mais utilizadas ao nível da experiência do utilizador, interface do utilizador e usabilidade. São também indicadas as principais alternati-vas em termos de sistemas de resolução de problemas por tickets e apresentados novos projetos, abordagens e tecnologias usadas na área.
No Capítulo 3 será caracterizado o problema, apresentando o tipo de sistemas de helpdesk empresariais para o qual é pretendido melhorar a UX, especificando como estes sistemas devem estar organizados e sugerindo um design de interfaces, interação e feedback ao utilizador que respeite os princípios apresentados no capítulo anterior.
No Capítulo 4 será discutido o caso particular do iPTicket sendo resumida a sua estrutura, o seu funcionamento, os seus principais problemas e o planeamento realizado para tentar resolvê-los.
O Capítulo 5 abordará os desenvolvimentos produzidos ao nível das interfaces, novas funcio-nalidades e sistema de email, assim como os testes de usabilidade realizados ao longo do projeto no lançamento de cada versão do iPTicket.
O Capítulo 6 irá apresentar as conclusões deste trabalho comentando os resultados obtidos com os desenvolvimentos produzidos, o cumprimento ou não dos objetivos inicialmente propostos e apresentando algumas possibilidades para trabalhos futuros a realizar nesta área.
Normas e práticas mais utilizadas ao
nível da UX e UI
Para poder propor melhorias ao nível da UX, da UI e da usabilidade em sistemas de resolução de problemas por tickets empresariais foi necessário estudar as melhores formas as projetar, pro-curar os melhores exemplos deste tipo de sistemas e analisar as novas abordagens e tecnologias utilizadas.
2.1
Projetar o design da experiência do utilizador
Devido ao facto do conceito da experiência do utilizador ser um pouco subjetivo existem vá-rias abordagens em como projetar o design da UX e habitualmente os livros ou sites apresentam abordagens diferentes dando mais importância a umas áreas do que a outras. Nesta dissertação será analisada mais em detalhe a proposta apresentada no livro A Project Guide to UX Design: For user experience designers in the field or in the making[Unger and Chandler, 2012] por ser um livro escrito por personalidades muito importante nestas áreas e ser uma abordagem que tem como base as melhores partes de várias outras. Segundo este livro, um projeto que estuda o design da experiência do utilizador de um determinado sistema deve seguir os seguintes passos:
• Planear a estratégia e a abordagem a seguir;
• Definir os requisitos do projeto;
• Produzir o design do conceito visual e de interação;
• Desenvolver, testar e aperfeiçoar a solução;
• Lançar o produto;
• Estender o projeto através de recomendações ou aperfeiçoamentos.
2.1.1 Planear a estratégia e abordagem a seguir
No que toca ao planeamento do projeto os autores do livro consideram importante identificar o tipo de site em que se vai trabalhar. Este pode representar a presença da marca, fazer parte de uma campanha de marketing, ser uma fonte de conteúdo ou uma aplicação baseada em tarefas.
Um site que pretenda representar a marca de uma empresa consiste numa plataforma online que facilita a relação entre a empresa e a sua audiência. Geralmente trata-se da página principal dessa empresa, de uma unidade de negócio ou então de uma submarca. Os principais objetivos deste tipo de website são comunicar os valores e a mensagem da marca, providenciar um acesso rápido à informação de determinada empresa e explicar o seu modelo de negócio. Na figura 2.1 podemos ver o exemplo da página principal da IPBRICK que tem como objetivo mostrar aos clientes ou potenciais clientes a sua marca, os seus produtos e as principais intenções da empresa.
Figura 2.1: Página principal da IPBRICK [IPBRICK].
Numa campanha de marketing o site ou aplicação terá de provocar uma resposta específica e mensurável de uma audiência em particular ou em geral durante um curto período de tempo. Alguns websites que se englobam nesta categoria são, por exemplo, uma página que divulgue uma promoção específica, um evento ou um jogo criado para provocar visitas. Esta categoria tem como principais objetivos gerar interesse e entusiasmo, envolver um determinado grupo de utilizadores, motivá-los a participar em algo ou então ajudar a empresa a obter determinadas métricas.
Em fontes de conteúdo são guardadas informações que podem conter diferentes tipos de mul-timédia e cujos objetivos podem ser informar ou entreter os utilizadores. Fazem parte deste tipo de páginas web a intranet de uma empresa, livrarias online, centros de recursos dos membros de uma organização, sites que fornecem notícias e que são constantemente atualizados ou centros de suporte a clientes. Este tipo de páginas deve apresentar o conteúdo que é mais indicado para cada visita do utilizador, suportar decisões e ajudar utilizadores que procurem informação através de formas menos ortodoxas.
As aplicações baseadas em tarefas contêm um conjunto de ferramentas que permitem ao utili-zador realizar um conjunto determinado de tarefas ou workflows. Alguns exemplos deste tipo de
websitessão aplicações que permitem a criação de um determinado tipo de objetos, ferramentas web que facilitem a execução de um workflow crítico dentro de uma empresa (como uma aplicação de gestão de tickets para suporte de clientes) ou um website que permite o acesso a informação pri-vada. Devem permitir que os utilizadores façam nessa aplicação uma determinada tarefa que não poderiam fazer de outra forma, ajudar novos utilizadores com instruções de fácil acesso, ajudar utilizadores mais experientes com acesso a funcionalidades mais avançadas e reduzir a carga no utilizador, fazendo uso de todos os recursos do sistema. Na figura 2.2 podemos ver um caso deste tipo de aplicações, o iPTicket, que funciona com base em tarefas como a inserção de problemas e a realização de assistências segundo vários tipos de workflows.
Figura 2.2: Página principal do sistema iPTicket [iPTicket, 2019].
O crescimento exponencial na venda e utilização de smartphones tornou-se num fator cada vez mais importante para a estratégia e planeamento das empresas. No livro Mobile First [Wro-blewski and Zeldman, 2011] é defendida a ideia de que a experiência do utilizador da versão móvel de uma página deve ser planeada antes da UX da versão para desktop visto que cada vez mais os utilizadores usam os seus smartphones para realizar tarefas ao invés de recorrerem ao tradicio-nal computador desktop, o que pode provocar um grande crescimento no número de utilizadores dessa página. Ao começar pela versão móvel haverá maiores limitações tendo em conta o me-nor tamanho dos ecrãs o que obriga o designer a selecionar apenas a informação mais importante para expor e dando-lhe uma maior relevância. Esta seleção prévia irá produzir uma melhor ex-periência para todos os utilizadores já que ao passar para a versão desktop existirá também uma melhor distinção da importância das várias informações. Para além de uma melhor seleção da informação prioritária é também mais fácil acrescentar informação para um ecrã de maiores di-mensões do que retirar deste; neste caso pode-se retirar dados importantes ou então não os indicar corretamente. Outro dos pontos importantes referidos neste livro é que os smartphones também apresentam ferramentas que não são comuns ou tão eficazes em desktops como GPS, interfaces gestuais e acelerómetros, o que permite desenvolver outros tipos de operações.
Quanto às abordagens ao projeto são referidas a abordagem em cascata e a abordagem ágil. Na primeira abordagem cada uma das fases do projeto é tratada de modo independente sendo que
apenas após a aprovação de uma etapa é possível iniciar a seguinte. O principal problema desta abordagem é que caso surjam novas ideias ou requisitos a meio do projeto será necessário alterar os documentos que aprovaram as fases anteriores, provocando grandes atrasos. A abordagem ágil é uma abordagem mais fluida e com possibilidade de paralelismo de tarefas que prioriza equipas pequenas localizadas perto umas das outras e em constante comunicação, de preferência cara a cara, dando uma menor importância aos papeis formais dos elementos da equipa e ao desenvol-vimento da documentação. Dentro da abordagem ágil encontra-se o conceito de Lean UX que pretende apresentar-se como uma transição da abordagem em cascata para uma abordagem mais ágil ao nível do design, sendo ideal para desenvolver produtos com elevado grau de incerteza, como no caso de produtos desenvolvidos por startups. Em vez de perder tempo a desenvolver completamente um conjunto de tarefas, esta abordagem tenta perceber por interação com os uti-lizadores quais as tarefas mais importantes a desenvolver focando-se nelas e evitando desperdiçar tempo a produzir algo que inicialmente possa parecer importante, mas que na realidade não tenha assim tanto interesse para os utilizadores quanto o esperado. Esta abordagem vê cada versão de um sistema como uma hipótese de introduzir um novo desenvolvimento, tentando validar rapida-mente decisões de design e incorporando, futurarapida-mente possíveis mudanças como resposta ao que os utilizadores necessitam, num ciclo continuo entre construir, medir as respostas dos utilizadores e retirar conclusões das mesmas. Como o seu foco é testar o comportamento de uma hipótese junto dos utilizadores não é necessário criar uma versão completamente funcional a todos os ní-veis, apenas produzir um produto minimamente viável, principalmente nas primeiras interações, o que reduz o esforço e o tempo necessários para chegar a uma versão que sirva as necessidades dos utilizadores, já que não é desperdiçado tempo a desenvolver aspetos menos relevantes para a experiência do utilizador.
2.1.2 Definição dos objetivos e dos requisitos do projeto
Para definir os objetivos de um projeto Unger e Chandler consideram que é importante analisar o estado de usabilidade apresentado por um website recorrendo a uma análise heurística. Para tal é importante ter em conta princípios para a realização de interfaces gráficas eficientes [Tognazzini, 2014] e as seguintes heurísticas de Nielsen [Nielsen, 1994]:
• Visibilidade do estado do sistema - o sistema deve sempre manter os seus utilizadores infor-mados do que está a acontecer através de informação apropriada e em tempo útil;
• O sistema condiz com o mundo real - deve ser usada uma linguagem e conceitos familiares ao utilizador;
• Liberdade e controlo do utilizador - o utilizador deve ter a liberdade de voltar atrás sempre que o entender, principalmente em caso de engano;
• Consistência e padrões - Num website todas as palavras, situações e ações devem ter o mesmo significado;
• Prevenção de erros - não devem existir situações que possam levar ao erro por parte dos utilizadores;
• Reconhecer em vez de relembrar - minimizar o impacto na memória do utilizador tornando os objetos, ações e opções visíveis;
• Flexibilidade e eficiência de utilização - proporcionar formas de acelerar a realização de tarefas através de atalhos invisíveis aos principiantes;
• Estética e design minimalistas - uma interface não deve conter informação desnecessária ao utilizador;
• Ajudar os utilizadores a reconhecer, diagnosticar e recuperar de erros - as mensagens de erro devem ser fáceis de entender, indicar precisamente qual é o problema e sugerir uma solução;
• Ajuda e documentação - devem ser providenciadas documentação e ajuda na realização de tarefas.
Os princípios para a realização de interfaces gráficas eficientes de Tognazzini são princípios que abordam vários aspetos de uma página, como a estética, a autonomia, a cor, a consistência, a descoberta, a eficiência, a aprendizagem, a legibilidade, a navegação e a lei de Fitts, para tentar tornar as interfaces mais úteis para os clientes. A definição desta lei dada pela Interaction Design Foundationé a seguinte:
“A lei de Fitts declara que a quantidade de tempo necessária para uma pessoa mover um ponteiro (por exemplo, o cursor do rato) para a área de destino é dada em função da distância ao alvo a dividir pelo tamanho do alvo. Assim, quanto maior a distância e quanto menor o tamanho do alvo, mais tempo demorará.” [Foundation].
As análises heurísticas são uma forma rápida e eficaz de perceber o estado inicial de um sistema e pensar em possíveis áreas a desenvolver. No caso de projetos que tenham em conta apenas melhorar o seu design já existente pode também ajudar a identificar pequenos arranjos que podem levar a melhorias imediatas de usabilidade.
Para se obter os requisitos do projeto devem ser tidos em conta o estado atual do sistema no qual se vai trabalhar, que se obtém usando uma lista contendo entre oito a doze das heurísticas ou princípios apresentados, os requisitos de negócio, os requisitos técnicos e os requisitos do utilizador. Os requisitos de negócio são apresentados pela empresa e podem ir desde métricas como aumentar o tráfego em dez por cento até requisitos mais técnicos como construir e incorporar um certo desenvolvimento no website. Já os requisitos técnicos podem ir desde limitações de infraestrutura à imposição de determinados softwares. Para se obter os requisitos do utilizador é importante realizar uma pesquisa aos principais grupos de utilizadores que utilizam o sistema por forma a se conseguir descobrir as suas necessidades.
Unger e Chandler consideram importante começar por definir os grupos de utilizadores mais importantes, criando uma estrutura que descreva os seus objetivos principais, os seus papeis, as suas informações demográficas e o seu nível de experiência. O envolvimento dos utilizadores deve ser pensado escolhendo uma ou mais técnicas que permitam perceber as suas necessidades e validar os grupos criados. Estas técnicas podem ir desde entrevistas aos utilizadores, a pesquisas e inquéritos contextuais, ordenamento de cartões ou testes de usabilidade. As entrevistas aos utiliza-dores podem ser simples conversas pessoais com elementos dos principais grupos de utilizautiliza-dores realizadas tanto presencialmente como à distância. Apresenta-se como uma forma relativamente fácil de fazer algumas perguntas para tentar obter informação sobre os utilizadores, mas com uma grande falta de contexto, o que pode produzir informação menos exata. Os inquéritos contextuais aliam uma entrevista normal com observações locais de utilizadores a interagirem com o sistema no seu ambiente natural, como por exemplo de trabalho. Ao ver a utilização neste ambiente pode-se retirar um maior contexto do que acontece, percebendo como o utilizador realiza as suas tarefas e workflows, permitindo assim compreender melhor os seus problemas, o equipamento com que trabalham, o seu espaço de trabalho, a sua preferência pela utilização do teclado ou do rato e que outras ferramentas necessita para atingir os seus objetivos. Usando toda a informação obtida dos utilizadores pode-se então obter os requisitos do utilizador e as personas nas quais devem ser baseadas as decisões ao criar o design das interfaces.
2.1.3 Design do conceito visual e de interação
Para estruturar o design do conceito visual e de interação é sugerida a utilização de mapas do site e de fluxos de tarefas. Um mapa do site é uma forma visual de representar as páginas de um websitee tem como principais objetivos representar a hierarquia visual e o layout da aplicação. Os fluxos de tarefas identificam quais são os caminhos e processos possíveis de realizar ao progredir pelo website e fornecem detalhes sobre as opções dos utilizadores. Na figura 2.3 pode ver-se parte do mapa do site da FEUP realizado com a ajuda de uma ferramenta chamada dynomapper [dyn] e na figura 2.4 é apresentado um fluxo de tarefas que representa a entrada num website consoante o utilizador esteja registado ou não.
Após estruturar o design deve passar-se à construção do protótipo usando wireframes e ano-tações. Um wireframe é um protótipo de uma página web com baixo nível de fidelidade e que é usado para identificar os elementos que serão mostrados no ecrã. Tipicamente são criados a preto e branco, como é possível ver no exemplo da figura 2.5, com espaços reservados para as imagens e sem entrar em detalhes específicos como o tipo de letra ou o tamanho da fonte. Nas anotações, figura 2.5, são criadas notas nos elementos ou interações de um wireframe que geralmente contêm informações sobre as regras de exibição, o destino das interações, a identificação dos conteúdos e das mensagens de erro.
Para completar o conceito visual é importante ter uma boa estratégia de conteúdo que planeie a criação e publicação do mesmo e que ajude a concretizar os objetivos de negócio. A estratégia de conteúdo, para além de fazer parte da experiência do utilizador, também a amplia para poder incorporar as ideias da marca junto dos seus clientes.
Figura 2.3: Exemplos de partes do mapa do site da FEUP.
Figura 2.5: Exemplo de um wireframe com anotações.
2.1.4 Design dirigido por metas, modelos de implementação e modelos mentais
A fundação de design de interação considera que o design de interação molda objetos digitais para o uso dos seus utilizadores [Lowgren]. Já no livro About Face: The Essentials of Interaction Design[Cooper et al., 2014] é apresentado o conceito de design dirigido por metas. Este conceito defende que, em vez de se desenhar interfaces que sejam facilmente entendidas pelos principi-antes, estas devem ser desenvolvidas de modo a responderem às necessidades dos utilizadores e ajudá-los a realizarem as suas metas. Cooper considera que o nível de experiência dos utilizadores tende a seguir uma distribuição normal onde na região central estão os utilizadores de experiência intermédia e nos extremos os pouco experientes e mais veteranos, sendo que por essa razão deve-mos focar-nos nas metas e objetivos dos utilizadores com experiência intermédia, mas nunca indo contra os utilizadores menos e mais experientes.
Ao conceito da representação de como o código trabalha na realidade é dado o nome de mo-delo de implementação. Geralmente este momo-delo difere largamente do momo-delo mental do utilizador sobre o funcionamento do programa ou ferramenta, daí que seja importante apresentar um modelo que represente as funcionalidades na interface de forma a que o utilizador as entenda. Um de-sign simples, harmonioso e que siga os modelos mentais dos principais grupos de utilizadores irá ajudá-los na realização das suas tarefas, levando-os a alcançarem as suas metas e objetivos sem interromper o fluxo de trabalho dos mesmos.
2.1.5 Princípios para a criação do design e da interação
O design visual divide-se em quatro princípios: a união versus a variedade dos elementos, a hierarquia e dominância, a economia de elementos e a proporção e equilíbrio. A união mostra-nos como certos elementos estão associados uns com os outros, recorrendo a cores, formas e posi-cionamentos, sendo que a variedade pretende diferenciar elementos que não estejam diretamente relacionados recorrendo a essas mesmas características. A hierarquia pretende estabelecer uma or-dem entre os elementos a visualizar, sendo que os presentes no topo da hierarquia devem ser mais proeminentes e chamar a atenção dos utilizadores quando comparados com elementos num nível mais baixo, que devem aparecer como elementos de suporte e com menor importância. Seguindo este princípio o utilizador será guiado pela página podendo ser mesmo encorajado a determinada ação como comprar um produto ou obter mais informação sobre algo. Elementos com descrições curtas e que sobressaem, presentes em objetos de maiores dimensões, mais brilhantes e com maior contraste, apresentam-se como dominantes mostrando um nível mais elevado na hierarquia. Na economia dos elementos pretende-se mostrar apenas o que é necessário e de uma forma clara para que o utilizador não seja sobrecarregado com informação, deixando-o confuso. Desta forma é mais fácil transmitir-lhe a mensagem pretendida sem grande ruído ao contrário do que aconteceria numa interface sobrecarregada onde tudo chamasse a sua atenção. A proporção e o equilíbrio ten-tam mostrar a importância da relação entre ten-tamanhos de diferentes elementos quando comparadas com o tamanho global do design. Este aspeto é especialmente importante em versões móveis de-vido ao facto de podermos variar entre a visualização num modo retrato e num modo panorâmico variando assim o tamanho da página, sendo que os elementos devem adaptar-se para cobrir todos os tipos de utilizadores e tamanhos de ecrã.
Para o design da interação Cooper fala-nos de interfaces metafóricas que se baseiam em cone-xões intuitivas que os utilizadores fazem entre pistas visuais e as respetivas funcionalidades para que entendam o que é possível fazer numa determinada aplicação sem terem de entender como esta funciona na realidade. Já o livro The design of everyday things [Norman, 2013] dá o nome de affordances às possibilidades presentes no mundo de como um agente pode interagir com algo, sendo que os signifiers são sinais ou etiquetas que nos indicam o que é possível fazer em determi-nada situação, isto é, indicam-nos que existe determidetermi-nada affordance.
2.1.6 Criação do protótipo, desenvolvimento e testes
Terminando o planeamento e a idealização do design será necessário criar um protótipo para testar o que foi idealizado recorrendo a ferramentas analógicas como o tradicional papel e caneta ou digitais como o Keynote, Acrobat, Visio, omnigraffle, Axure ou simplesmente puro HTML. Este protótipo deve ser o mais interativo possível para ajudar a recolher opiniões dos utilizadores, identificando assim potenciais problemas ou validando a experiência do utilizador. Criar o protó-tipo com papel e caneta é uma forma flexível, fácil e barata de testar algumas das funcionalidades de um sistema, mas apresenta claras limitações de escalabilidade quando se pretende testar sis-temas com muitas interfaces. Em termos de ferramentas digitais a forma mais rápida e simples
de testar o protótipo com os utilizadores é reutilizando os wireframes já criados, mas se pretender mostrar uma versão mais próxima do produto final o designer pode recorrer a HTML puro ou editores WYSIWYG.
Já numa fase final e após realizar os desenvolvimentos previstos é necessário testar o design produzido com os utilizadores recorrendo a testes de usabilidade. Nestes testes temos uma lista de tarefas prioritárias que o utilizador deve realizar para se obter informação sobre as suas dificulda-des de interação e usabilidade. No final da realização dificulda-destes testes devem ser analisados os dados obtidos e criadas recomendações para possíveis melhorias a desenvolver.
2.2
Exemplos de sistemas de resolução de problemas por tickets
exis-tentes
Analisando a lista das aplicações mais usadas ao nível de software de helpdesk presentes na página da capterra [cap] é possível ver que algumas das aplicações que competem com o iPTicket são o Freshdesk, cujo design podemos ver na figura 2.6, o Genesys, o Zendesk, figura 2.7, e o UVdesk, figura 2.8, cujo processo de construção das interfaces foi apresentado e explicado no seu website [Nitish, 2017]. Por análise dos designs apresentados podemos verificar que todos optam por uma barra lateral de navegação onde apresentam as várias partes do website e uma barra superior com informação pessoal.
Figura 2.6: Design da aplicação Freshdesk [Freshdesk, 2018].
Nitish Kumar, designer da equipa de UX e UI do UVdesk, afirma que o design anterior não era suficientemente ágil e que por isso foi necessário reestruturar a aplicação. Para aumentar a usabilidade e melhorar o fluxo de trabalho optaram por refazer todas as ferramentas da aplicação e como verificaram que os principais grupos de utilizadores acediam à aplicação através dos seus smartphones tornaram a aplicação mais responsiva para ecrãs mais pequenos. Na figura 2.9 é possível ver um dos wireframes usados para criar o design do protótipo que como seria de esperar, contem bastantes semelhanças com o produto final apresentado na figura 2.8.
Em termos de interfaces criadas, Nitish optou por usar 3 secções diferentes:
• Painel do administrador: um painel onde o administrador ou dono irá gerir os seus clientes, problemas e definições;
Figura 2.7: Design da aplicação Zendesk [Zendesk].
Figura 2.8: Design da aplicação UVdesk [UVdesk].
• Painel do cliente: onde o utilizador pode pedir ajuda para determinado problema e obter uma lista dos pedidos anteriores;
• Painel de ajuda: uma página de ajuda onde o cliente pode ver as perguntas mais frequentes e pesquisar por palavras chave.
Para criar o protótipo foi usada a ferramenta Adobe XD e as linguagens HTML, CSS e JS, enquanto que para criar padrões de design para todas as páginas foram usados o LessCSS e o JS. A ferramenta Adobe XD permitiu desenhar padrões de interatividade e melhorar o fluxo do websiteenquanto que o LessCSS foi usado para criar elementos, como botões, menus, formulários, mensagens, notificações, paginação e micro interações, que são comuns a toda a aplicação. Em vez de imagens em JPEG ou PNG, foram usados SVGs, por forma a aumentar a qualidade visual e aumentar a capacidade de customização.
Figura 2.9: Wireframe da aplicação UVdesk [Nitish, 2017].
2.3
Novas abordagens e tecnologias
O artigo Back to Basics [Fox, 2017] compara abordagens top down e bottom up na produção de websites. Uma abordagem de design top down foca-se em design gráficos, construção, manu-tenção e tooling da interface do utilizador que configuram a informação consoante as limitações do design. Já uma abordagem bottom up determina que o modelo de posicionamento do con-teúdo usado seja de acordo com o modelo mental dos utilizadores ou um modelo de recompensa que, como o próprio nome indica, faz uso do design para motivar o utilizador a cumprir os seus objetivos.
Jeremiah apresenta no seu artigo Web Page Visual Hierarchy: Examining Faraday’s Guideli-nes for Entry Points[Still, 2018] a ideia de que o modelo de visualização hierárquica de Faraday, apesar de popular, não apresenta os melhores resultados ao nível da experiência do utilizador. As abordagens discutidas neste relatório, para além de ajudarem no design de aplicações web, podem também ajudar a produzir um design para interfaces de aplicações em realidade aumentada [Youm et al., 2019], saúde [Wray et al., 2019] [Hung et al., 2019] e administração pública [Federici et al., 2018//].
Em Relating Experience Goals With Visual User Interface Design [Jokinen et al., 2018] é analisada a relação entre determinados elementos na interface e a experiência que provocam no utilizador. É provado que determinados elementos e características presentes em websites podem provocar que o utilizador sinta uma página como bela ou profissional. Um outro artigo, intitulado How does Parallax Scrolling Influence User Experience? [Wang and Sundar, 2018], mostra que
uma interação do CSS chamada parallax scrolling pode fazer o utilizador sentir uma perspetiva de vividez, o que provoca o compromisso por parte dele e um mapeamento natural, o que facilita a sua utilização.
O artigo Expresso: Building Responsive Interfaces with Keyframes [Krosnick et al., 2018] aborda o desenvolvimento de uma ferramenta WYSIWYG chamada Expresso, que torna mais fácil fazer uma página responsiva para vários ecrãs, uma vez que permite desenvolver várias interfaces e definir qual delas mostrar consoante o tamanho do ecrã. Esta ferramenta permite ainda criar transições suaves entre várias interfaces e limites de tamanho do ecrã. Outro artigo que aborda as dificuldades em construir um site responsivo para diferentes ecrãs é o Automatic Detection of Visibility Faults by Layout Changes in HTML5 Web Pages [Ryou and Ryu, 2018] onde são desenvolvidos algoritmos que permitem detetar automaticamente falhas nas interfaces provocadas por diferentes tamanhos de ecrã.
A empresa Avocode, criadora de uma ferramenta homónima de interação de designs prove-nientes de Sketch, Adobe XD, Photoshop, Illustrator e Figma tem um projeto onde analisa os designs que passam pela sua aplicação criando anualmente um relatório com as principais tendên-cias verificadas e algumas previsões para o ano seguinte. A análise anual de 2017 indicou que a aplicação Sketch continuou a aumentar a sua vantagem na percentagem de ficheiros de design gerados comparado com a concorrência (Adobe XD, Figma, inVision Studio e Phase) e que os ficheiros criados nesta aplicação conseguiam provocar designs até oito vezes mais rápidos que os gerados pelo Photoshop. A tendência para designs cada vez mais minimalistas continuou a verificar-se como nos anos anteriores, constatando-se uma tendência na diminuição no número de camadas que só não se verificou nas de texto, que aumentaram com o crescimento do storytelling. Em termos de imagem os ficheiros mais utilizados foram gráficos de vetores, como por exemplo os SVGs [Ryn, 2017]. Já no último relatório, lançado em Abril de 2018, foram analisados 6,354,110 ficheiros de designs permitindo verificar que ao contrário do que se verificou no ano passado o Adobe XD e o Figma tiveram percentagem de utilização muito mais próximas à do Sketch. Neste ano aconteceu também uma grande mudança ao nível das cores e dos gradientes usados visto que em anos anteriores as vinte e cinco cores mais utilizadas em designs eram todas tons de cinzento e neste ano encontramos o azul, o vermelho e o cor de laranja no top quinze. Este ano foi também um ano muito marcante em termos de tipografia, tendo sido possível verificar que os designers deixaram de utilizar apenas fontes regulares grátis da Google, e que quatro vezes mais fontes distintas foram provenientes de geradores online de fontes baseados em WOFF, WOFF2 e Font Sqirrel [Roskovec, 2018].
Design da UX em sistemas de resolução
de problemas
Como já foi referido no Capítulo 1, um sistema empresarial de resolução de problemas por tickets permite servir de ligação entre os clientes de uma empresa e a sua equipa de suporte. Esta equipa pode fazer parte da empresa que forneceu os serviços ou produtos aos clientes ou então ser contratada a outra especializada nesta área, sendo até bastante normal vermos equipas que realizam assistência a clientes de várias empresas em simultâneo, estejam elas relacionadas diretamente consigo ou não.
Em termos de estratégia e abordagem estes sistemas enquadram-se nas aplicações baseadas em tarefas porque, como referido no Capítulo 2, permitem realizar um conjunto alargado de ta-refas inseridas em vários workflows que não seriam facilmente realizáveis sem a existência deste tipo de aplicação. As principais tarefas passíveis de realizar nestes sistemas são a inserção de problemas por parte dos clientes, a realização das assistências técnicas, a gestão dos funcionários, das assistências e dos problemas inseridos, a comunicação direta entre assistentes e clientes seja por interface web, videochamada ou email, e a análise dos dados guardados com base no trabalho desenvolvido para fins estatísticos ou de contabilidade.
Em termos de grupos de utilizadores podemos distinguir três tipos principais de utilizadores: os assistentes, os clientes e os administradores. O grupo dos assistentes é constituído pelos tra-balhadores da equipa de suporte que podem prestar ajuda à distância ou presencialmente caso o problema o justifique, o que até pode justificar um investimento na UX da versão móvel do sis-tema dependendo das prioridades da empresa. Este grupo tem como principal objetivo realizar o seu trabalho de prestar suporte aos clientes da forma mais simples e eficaz possível, sendo por isso importante manter todas as ferramentas necessárias por perto e visíveis a qualquer momento, fazendo com que o seu acesso e utilização seja o mais fácil possível. Os clientes têm como prin-cipal objetivo resolver os seus problemas rapidamente, sendo importante para diminuir os seus níveis de frustração facilitar a introdução dos problemas no sistema e mostrar a todo o momento o estado dos tickets introduzidos. A informação do estado do sistema tanto pode estar disponível na interface web como por email, caso em que o feedback deve ser enviado aquando da mudança
do estado em que este se encontra. Como se trata de utilizadores menos familiarizados com o sis-tema é importante facilitar a sua experiência indicando-lhes o caminho para introduzir um ticket, como o devem fazer e sugerindo-lhes tópicos para o preencher. Outro fator importante pode ser a disponibilização de FAQ, Frequently Asked Questions, que cubram os problemas mais frequen-tes para que não sejam introduzidos problemas de fácil resolução, desperdiçando tanto o tempo dos clientes como o dos assistentes. O grupo dos administradores pode mostrar grande variância nos seus objetivos dependendo de sistema para sistema, sendo alguns dos seus possíveis objetivos gerir a sua equipa de assistentes, orientando quem deve tratar de que problema, ou realizar análi-ses estatísticas para procurar perceber o que é possível melhorar no serviço prestado aos clientes. Outros grupos que podem surgir ocasionalmente, dependendo da aplicação especifica do sistema, são o grupo dos contabilistas, que têm como principal objetivo contabilizar as assistências realiza-das, e o grupo dos editores, responsável por criar e configurar tarefas, workflows e outros aspetos particulares do sistema.
3.1
Estrutura
Um sistema empresarial de resolução de tickets de problemas para além de poder servir de suporte a vários produtos poderá também servir um número alargado de clientes, cada um deles apresentando um modelo de negócio completamente diferente dos restantes. Para tentar servir to-das as empresas é importante que o sistema se consiga adaptar às necessidades específicas de cada utilizador apresentando um grande grau de customização ao nível dos tipos de assistências, dos tipos de problemas, dos workflows, das tarefas e das prioridades disponibilizadas. Para fornecer este grau de customização a cada empresa é necessário que o sistema tenha um editor de work-flowscom vários tipos de tarefas predefinidas que permitam realizar vários tipos de ações como receber um problema, destacar um assistente para ficar encarregado de o resolver, encaminhá-lo para outro assistente, realizar uma assistência, entre outros... Ao nível das assistências o sistema deve poder incorporar vários tipos de assistências, desde assistências remotas até locais, e ter em conta a diferença de dados que é necessário guardar em ambos os casos porque, por exemplo, numa assistência em que o assistente se tenha de deslocar até outra empresa para tratar de um problema de hardware deverá ser contabilizado o tempo de viagem e os quilómetros percorridos ou as peças substituídas e o seu valor. Como os problemas podem ser inseridos por representan-tes de vários tipos de empresas, algumas revendedoras que insiram os problemas em nomes das empresas que são suas clientes, é importante que o sistema de gestão de utilizadores permita uma fácil edição com vários exemplos predefinidos adequados a todos os tipos de utilizadores, sejam eles pertencentes à equipa de suporte ou externos.
Para além de elevados níveis de adaptação e personalização é importante que o sistema cum-pra os seus principais objetivos, sendo um deles facilitar a introdução de problemas ao cliente. Esta inserção deve ser feita por mais meios para além da interface web, recorrendo por exemplo ao email, que é das ferramentas mais usadas a nível empresarial, sendo que para isso é necessário configurar endereços predefinidos para as várias contas de suporte que vão receber os pedidos de
ajuda e usar um filtro de emails que dependendo das características dos mesmos os introduza no tipo de problema e workflow mais indicado. Outro aspeto importante na comunicação é a reso-lução do problema em si, já que a ajuda pode ser feita através de vários meios de comunicação destacando-se o email, a chamada de áudio e a videochamada, por serem os meios de comunica-ção à distância mais utilizados em sistemas de helpdesk. O sistema deve conter essas opções de comunicação na sua interface web, ou pelo menos facilitar a ligação a outros programas destina-dos para esse efeito, incorporando-os na interface para que estejam facilmente acessíveis, evitando que o utilizador saia da página para realizar uma tarefa, diminuindo assim o tempo de resposta e aumentando a usabilidade do sistema.
3.2
Perfis a utilizar
Analisando os perfis de utilizadores que podem ser utilizados e tendo em conta apenas os três grupos principais já apresentados deve-se pensar num perfil de assistente, num perfil de queixoso e num perfil de administrador.
Os assistentes deverão ter acesso à lista de problemas na qual vão trabalhar, às páginas dos problemas que estão autorizados a ver, um histórico das suas assistências realizadas, algumas estatísticas sobre o seu trabalho recente, às ferramentas necessárias para comunicarem com os clientes e a algumas configurações pessoais. A sua página inicial tanto pode ser uma página contendo uma grelha com o trabalho a realizar como uma página com a informação mais relevante do seu histórico mais recente, mostrando algumas estatísticas, os problemas mais importantes e as assistências mais recentes permitindo assim uma ligação rápida a tudo o que precisar. A listagem dos problemas a trabalhar deve destacar uma breve descrição do problema e fazer a ligação à página do problema contendo a informação detalhada e oferecendo formas de contacto com o cliente. Para além da descrição, a listagem deve ainda apresentar informação sobre quem introduziu o problema, de que tipo de problema se trata, a data limite para a sua resolução e qual a próxima ação que pode ser realizada, sendo a ordenação da listagem feita pela data limite mais próxima para dar uma maior prioridade aos problemas que necessitam mais da sua atenção. Outra vertente a ter em conta nestes utilizadores é o registo dos dados do trabalho realizado para análise estatística e de contabilidade, informação esta obtida após o assistente preencher um formulário cujos campos se devem adaptar ao tipo de assistência prestada por forma a facilitar a sua rápida inserção no sistema. Por exemplo o número de quilómetros percorridos é um campo importante em assistências prestadas à distância mas sem relevância caso a mesma seja realizada localmente. O fluxo de trabalho de um assistente segue normalmente o fluxo apresentado na figura 3.1. Ao receber um novo problema o assistente pode contactar o cliente, caso seja necessário, para obter mais informação, realizar a assistência e assim que terminar o trabalho deve assinalar o problema como terminado e inserir os dados das assistências realizadas.
O perfil queixoso deve ser atribuído aos clientes, utilizadores geralmente externos à empresa prestadora de serviços, pelo que os seus utilizadores devem ter limitações nas informações apre-sentadas por uma questão de privacidade e segurança. Como tal os utilizadores com este perfil
Figura 3.1: Fluxo de trabalho de um assistente.
só devem aceder aos seus tickets, a um formulário de inserção de novos problemas, uma lista de FAQ, uma forma de comunicar com o assistente e às assistências prestadas aos seus problemas. O sistema deve mostrar ao queixoso os seus problemas e as soluções para os mesmos na sua página inicial, contendo em grande destaque uma lista com os seus tickets indicando em que estado é que se encontram e apresentando uma forma rápida de contactar os assistentes, tanto para resolução dos problemas já apresentados, como de novos que possam surgir. É importante que o utilizador tenha também disponível uma lista de problemas e dúvidas mais comuns para evitar a introdução de problemas com fácil resolução, retirando assim algum trabalho aos assistentes. Como estes uti-lizadores são menos experientes com a interface é necessário ajudá-los nas suas primeiras tarefas para que saibam o que fazer usando pequenas etiquetas de ajuda e uma distribuição dos elementos segundo o seu modelo mental. O fluxo de trabalho para estes utilizadores segue o fluxo presente na figura 3.2. Os clientes devem começar por pesquisar na lista de FAQ para ver se o problema tem uma fácil resolução e caso seja necessário introduzirem no sistema um ticket com a descrição do problema podendo depois alterar esses dados. Caso seja necessário serão contactados pelo
assis-tente para a resolução do problema e assim que verifiquem que o problema está resolvido devem indicar o fecho ao assistente.
Figura 3.2: Fluxo de trabalho de um queixoso.
Os administradores do sistema irão maioritariamente verificar estatísticas, delegar trabalho caso o sistema não o faça automaticamente e configurar o sistema para o que pretenderem. A sua página inicial deve providenciar um acesso rápido aos problemas que ainda estão por delegar, indi-cando lhes o assistente mais correto para o resolver ou o assistente com menos trabalho atribuído. Estes utilizadores devem ter acesso a estatísticas muito mais detalhadas, tanto globais como por cada um dos assistentes, e a quase toda a informação disponibilizada no sistema. A parte das con-figurações para além de ser bastante detalhada, para permitir adaptar o sistema às necessidades,
deve ainda tornar todo esse processo simples, ajudando o utilizador em cada passo. Um erro de configuração provocado por uma interface confusa pode ter resultados catastróficos como perda de informação, workflows mal configurados ou problemas inseridos em workflows errados.
As interfaces para todos os utilizadores devem ser muito flexíveis e costumizáveis, para que todos possam fazer alterações nelas consoante o que pretendam e como se sentem confortáveis, sendo essas preferências associadas ao utilizador para que não as perca ao terminar a sessão. Estas configurações podem englobar cores, tamanho ou posicionamento dos elementos.
3.3
Interfaces visuais
Respeitando as normas referidas no Capítulo 2, as interfaces do sistema devem colocar na re-gião central a informação mais importante para cada grupo de utilizadores, deixando as regiões à sua volta para informação de suporte. O wireframe apresentado figura 3.3 pretende servir como base para todas as interfaces a construir. Nele é possível distinguir seis áreas distintas marca-das com anotações de 1 a 6 assinalando respetivamente o cabeçalho, a área pessoal, a barra de navegação, a região central da página, a região lateral esquerda e a região lateral direita.
Figura 3.3: Wireframe da interface geral do sistema de resolução de problemas.
A área marcada com a anotação 1 representa o cabeçalho da página, sendo que este deve ser conciso mostrando apenas a informação necessária de modo a não sobrecarregar o utilizar ou distraí-lo da informação mais importante, presente no centro da página. O cabeçalho pode conter um logo da empresa ou da marca representada do lado esquerdo, que pode servir como uma ligação à página inicial. Esta ligação pretende dar uma sensação de conforto ao utilizador porque, independentemente da interface em que ele esteja, saberá que a qualquer momento poderá voltar atrás para uma interface que já conhece, evitando também que se perca. Esta área engloba também a área 2 que pretende representar a área pessoal do utilizador e que pode incluir uma foto
de perfil, uma ligação para os seus dados pessoais, uma ligação para as definições do utilizador, um botão para mudar o idioma da página e outro para terminar a sessão. O botão de mudança de idioma permite a um utilizador que não entenda a língua base do sistema mudá-la para uma com que se sinta mais confortável, sem ter de navegar pelo website para encontrar essa opção nas definições, facilitando esse objetivo e evitando possíveis erros que possam ocorrer no caso do utilizador mudar alguma definição que não pretendia ao tentar mudar o idioma. Por último o botão de terminar sessão permite ao utilizador, sem grande trabalho, terminar a sua sessão o que poderá ser uma ação realizada várias vezes, sendo por isso importante que esteja sempre por perto.
A barra de navegação da página está marcada com a anotação 3 e permite aceder a todas as partes do website para as quais o utilizador tenha permissão. Esta barra deve conter uma aba para cada área do sistema, sendo possível agrupar as várias páginas numa área para assistências, para os problemas, para as estatísticas e ainda outra para as configurações. A aba das assistências serve como ligação ao seu formulário de inserção e à lista contendo todas as assistências que o utilizador possa visualizar, enquanto que a dos problemas permite aceder ao seu formulário de inserção, à listagem dos problemas existentes e à lista dos que se encontram à espera de intervenção. Nas estatísticas é possível aceder a dados sobre todas as áreas do sistema e nas configurações pode-se aceder a páginas para inpode-serir e editar utilizadores, tipos de problemas, tipos de assistências, workflowse demais configurações necessárias para o correto funcionamento do sistema. Os ad-ministradores devem ter todas as permissões e, como tal, têm à sua disposição todas estas abas e funcionalidades. Já os assistentes apenas podem aceder à aba das assistências e à dos problemas e os queixosos aos problemas e a lista de assistências que lhes foram realizadas.
A anotação 4 pretende representar a região central da página onde deve estar presente a in-formação mais importante. Em páginas de inserção de problemas ou assistências o formulário de preenchimento dos dados contendo caixas de seleção ou campos de texto deve ocupar esta posição, enquanto que nas páginas de listagens de problemas ou assistências ela é ocupada pela tabela com um resumo dos dados. Nas páginas de um problema ou de uma assistência a informação completa sobre este também se apresenta nessa área.
As regiões laterais da página estão marcadas pelas anotações 5 e 6 sendo que devem ser ocu-padas por elementos que ajudem o utilizador a compreender ou realizar algo na região central. Estas áreas contêm ferramentas de ajuda, sugestões de preenchimento de formulários, sugestões de resolução de problemas e pequenas estatísticas. Para os utilizadores ocidentais a informação de suporte mais importante deve ser colocada à esquerda, visto que a sua forma de ler tende a seguir o movimento da esquerda para a direita e de cima para baixo, tendo por isso um pouco mais de atenção que a parte direita marcada com 6.
Aplicando a interface geral representada na figura 3.3 ao caso das listagens de problemas ou de assistências obtemos o wireframe apresentado na figura 3.4. É possível ver identificada com o número 1 a área central contendo um resumo das informações dos vários problemas que um assistente terá de trabalhar ou então das assistências realizadas. É importante que esta área seja clara e de fácil leitura para simplificar o trabalho do assistente daí que deva apenas encontrar a informação mais relevante, que no caso da listagem de problemas será o número do problema, um
