• Nenhum resultado encontrado

Proposta de framework para guias de estilo de produtos digitais

N/A
N/A
Protected

Academic year: 2021

Share "Proposta de framework para guias de estilo de produtos digitais"

Copied!
144
0
0

Texto

(1)

Universidade de Aveiro Ano 2016

Departamento de Comunicação e Arte

JOÃO CARLOS

ALVES AFONSO

PIRES DA ARRUDA

PROPOSTA DE FRAMEWORK PARA GUIAS DE

ESTILO DE PRODUTOS DIGITAIS

(2)

Universidade de Aveiro Ano 2016

Departamento de Comunicação e Arte

JOÃO CARLOS

ALVES AFONSO

PIRES DA ARRUDA

PROPOSTA DE FRAMEWORK PARA GUIAS DE

ESTILO DE PRODUTOS DIGITAIS

Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Comunicação Multimédia, realizada sob a orientação científica do Doutor Pedro Amado, Professor Auxiliar do Departamento de Comunicação e Arte da Universidade de Aveiro.

(3)

Obrigado pai (in memoriam).

(4)

o júri

presidente Prof. Doutor Pedro Miguel dos Santos Beça Pereira

professor auxiliar do Departamento de Comunicação e Arte da Universidade de Aveiro

orientador Prof. Doutor Pedro Manuel Reis Amado

professor auxiliar do Departamento de Comunicação e Arte da Universidade de Aveiro

arguente Prof. Doutor José Miguel Santos Araújo Carvalhais Fonseca

professor auxiliar do Departamento de Design da Faculdade de Belas Artes da Universidade do Porto

(5)

agradecimentos Agradeço aos meus pais por todos os esforços que fizeram ao longo da minha vida académica, à minha família e amigos pela boa-disposição, ao Hugo pela força, ao meu orientador pela paciência e excelente acompanhamento, e a todos aqueles que, de uma forma ou de outra, depositaram a sua confiança em mim.

(6)

palavras-chave Front-End Style Guide, Design de interação, Branding, Fluxo de trabalho

resumo O objetivo do presente estudo passa pela elaboração de uma framework para

a criação de guias de estilo a aplicar pelas organizações no desenvolvimento de produtos digitais. As equipas responsáveis pela criação de produtos digitais são cada vez mais pluridisciplinares, podendo trabalhar assincronamente em espaço-tempos distintos. Desta forma, a ausência de um guia de estilos que identifique os principais elementos a considerar na génese de um produto digital poderá levar a perdas de tempo desnecessárias e ao surgimento de diferenças criativas que porão em causa o bom relacionamento da equipa, o desenvolvimento do projeto e a consistência dos vários componentes da marca. A utilização de um guia de estilos que dê apoio ao desenvolvimento de projetos desta natureza torna-se assim bastante relevante. Porém, a sua implementação requere o investimento de recursos por parte das organizações que geralmente não vêm esta ferramenta como uma necessidade prioritária. Com o auxílio da framework aqui apresentada espera-se que os recursos alocados à criação do guia diminuam consideravelmente, e que equipas a trabalhar em pequenas e médias organizações possam incluir um guia de estilos no seu fluxo de trabalho. Começou-se por identificar os principais elementos que deverão ser incluídos num guia de estilo de produtos digitais através da análise de Manuais de Identidade Corporativa e FESG de diversas áreas de atividade. Os elementos foram organizados numa tabela comparativa que foi posteriormente validada por profissionais nas áreas do design e programação através de entrevistas semi-estruturadas. Seguidamente,

procedeu-se à transcrição e análise qualitativa das respostas obtidas com vista a recolher opiniões de melhoria. Finalmente, foi desenvolvido um website com a framework para a criação de guias de estilo de produtos digitais que foi posto em prática por um dos entrevistados, num projeto real. O feedback obtido a a partir da implementação da framework realçou a versatilidade da ferramenta, as possibilidades de adaptação às necessidades de cada organização e a capacidade desta poder ser desenvolvida à medida da evolução do projeto, servindo como um repositório de informação e como um catalisador para o pensamento em equipa de decisões a tomar no desenvolvimento do produto digital.

(7)

keywords Front-End Style Guide, Interaction design, Branding, Workflow

abstract The aim of this study is to develop a framework for creating style guides to be

applied by organizations in the development of digital products. The teams responsible for creating digital products are increasingly multidisciplinary and can work asynchronously in different space-times. Thus, the absence of a style guide that identifies the most important elements to consider in the genesis of a digital product can lead to unnecessary loss of time and the emergence of creative differences that bring into question the good relationship of the team, the development of the project and the consistency of the various components of the Brand. The use of a style guide that supports the development of

projects of this nature thus becomes very relevant. However, its implementation requires the investment of resources by organizations that do not usually see this tool as a priority need. With the help of the framework presented here we believe that the resources allocated to the creation of the guide can decrease considerably, and that teams working in small and medium-sized organizations can make the style guide part of their workflow. The study started by identifying the major elements to be included in a style guide for digital products through the analysis of Corporate Identity Manuals and FESG from different areas of activity. These were then structured in a comparative table that was later validated by professionals in the areas of design and programming through semi-structured interviews. The researcher proceeded to the transcription and qualitative analysis of the responses received in order to collect ideas for improvements. Finally, he developed a website with the framework for creating style guides for digital products that was later tested by one of the interviewees in a real project. The feedback obtained from the implementation of the

framework highlighted the tool's versatility, the possibilities of adaptation to the needs of each organization and the advantages of being developed as the project evolves, taking its place as an information repository and as a catalyst for generating team thinking during the digital product development.

(8)

Índice

Introdução ... 1 Enquadramento ... 2 Objetivos e motivação ... 3 Organização do documento ... 4 1 Enquadramento Teórico ... 7 1.1 A Marca ... 7 1.1.1 Branding e elementos da Marca ... 8 1.2 Guias de Estilo ... 9 1.2.1 Guias de Estilo Editoriais e de Conteúdos ... 9 1.2.2 Manuais de Design Gráfico ... 11 1.2.3 Guias de Estilo de Programação e Estandardização de Código ... 12 1.2.4 Guias de Design de Interação ... 13 1.3 Desenvolvimento de Software ... 16 1.3.1 Abordagens de desenvolvimento ... 19 1.3.2 Padrões de Design ... 23 1.3.3 Prototipagem e Fidelidade no desenvolvimento ... 25 1.4 Proposta de Framework para Guias de Estilo de Produtos Digitais ... 26 1.4.1. Passos para implementar um FESG ... 27 1.4.2. Benefícios da utilização de FESG ... 27 1.5 Considerações finais do enquadramento teórico ... 28

(9)

2 Metodologia ... 29 2.1 Abordagem metodológica ... 29 2.2 Metodologia de investigação ... 30 2.3 Metodologias de pesquisa a aplicar ... 32 2.3.1 Análise Documental ... 32 2.3.2 Survey por entrevista presencial recorrendo a um guião semi-estruturado 32 2.3.3 Resumo da metodologia a utilizar ... 33 2.4 Desenho do estudo e recolha de dados ... 34 2.4.1 Análise documental ... 35 2.4.2 Entrevistas ... 40 2.4.3 Participantes ... 44 2.4.4 FESG analisados ... 44 2.4.5 Questões colocadas e material recolhido ... 49 2.5 Síntese dos dados recolhidos ... 50 2.5.1 Participantes, Metodologias e Atividades profissionais ... 51 2.5.2 Análise dos FESG apresentados ... 57 2.5.3 Implicações do FESG no fluxo de trabalho ... 58 2.5.4 Análise das opiniões sobre a tabela comparativa e conclusões da entrevista 60 3. Resultados do estudo ... 63 3.1. Processo de preenchimento ... 68 3.2. Aplicação em contexto organizacional ... 69

(10)

Conclusão ... 73 Limitações e trabalho futuro ... 74 Referências ... 75 ANEXOS ... 79 ANEXO 1 – Guião de Entrevista ... 79 ANEXO 2 – Transcrição da entrevista [Dinis] ... 84 ANEXO 3 – Transcrição da entrevista [Ricardo] ... 94 ANEXO 4 – Transcrição da entrevista [Lourenço] ... 101 ANEXO 5 – Transcrição da entrevista [Pedro] ... 111 ANEXO 6 – Transcrição da entrevista [Simões] ... 122

(11)

Índice de figuras

Figura 1 – Pontos de contacto com o consumidor ... 8

Figura 2 – Guia de estilos editorial da Yale University Publications ... 10

Figura 3 - Livro de Estilo do Público ... 11

Figura 4 - Guia de Estilo para formatação de HTML ... 13

Figura 5 – Front-End Style Guide do MailChimp ... 15

Figura 6 – Evolução do processo de desenvolvimento de software ... 17

Figura 7 - Diagrama do modelo Incremental ... 20

Figura 8 - Diagrama do Modelo em Espiral ... 21

Figura 9 – Diagrama representativo do modelo Agile ... 22

Figura 10 - Primeira versão da tabela comparativa ... 36

Figura 11 - Segunda versão da tabela comparativa (pormenor) ... 37

Figura 12 - Terceira versão da tabela comparativa (vista global de secções) ... 39

Figura 13 - Foco na sub-categoria “Text” da tabela comparativa (pormenor da tabela comparativa) ... 39

Figura 14 - Página inicial do Guia de Estilos do Starbucks ... 45

Figura 15 - Explicação da utilização de grelhas nos websites do Starbucks ... 46

Figura 16 - Exemplo de visualização de grelha no Guia de Estilos do Starbucks ... 46

Figura 17 - Página inicial do Guia de Estilos do Ubuntu ... 47

Figura 18 - Explicação da utilização de grelhas nos websites do Ubuntu ... 48

Figura 19 - Explicação da criação de botões no Guia de Estilos do Ubuntu ... 48

(12)

Figura 21 – Versão final da tabela comparativa com a estrutura da framework ... 62

Figura 22 - Captura de ecrã da Framework uikit ... 64

Figura 23 - Captura de ecrã da Framework Bootstrap ... 64

Figura 24 - Mockup do guia para desenvolvimento de produtos digitais ... 65

Figura 25 – Mockup do guia em formato web ... 66

Figura 26 – Bloco “What to do?” ... 67

Figura 27 – Área “Brand Strategy” na barra de navegação ... 68

Figura 28 – Lourenço a consultar o GEPD aplicado ao Imprint+ ... 69

Figura 29 – Aplicação do GEPD ao logotipo do Imprint+ ... 70

Figura 30 – Aplicação do GEPD ao posicionamento do logo do Imprint+ ... 70

Figura 31 – Aplicação do GEPD à iconografia do website do Imprint+ ... 71

Figura 32 – Aplicação do GEPD à apresentação da hero image da área de parceiros 71 Figura 33 – Aplicação do GEPD à apresentação de um módulo do curso do Imprint+ ... 72

(13)

Índice de tabelas

Tabela 1 - Sumário das duas tipologias de Development Research ... 30

Tabela 2 - Métodos de Investigação Empregados na Pesquisa de Desenvolvimento .. 31

Tabela 3 - Procedimentos metodológicos ... 33

Tabela 4 – Desenho do estudo ... 34

Tabela 5 - Planificação da entrevista ... 41

Tabela 6 - Caraterização dos profissionais entrevistados ... 44

(14)

Lista de abreviaturas e siglas

API Application Programming Interface CSS Cascading Style Sheet

DSDM Dynamic Systems Development Method FESG Front-End Style Guide

GEPD Guia de Estilo de Produto Digital GUI Graphical User Interface

HTML HyperText Markup Language SEO Search Engine Optimization

(15)

Introdução

A presente investigação teve como objetivo criar uma framework para agilizar o desenvolvimento de Guias de Estilo a serem utilizados por equipas

multidisciplinares ao longo da criação de um Produto Digital. Espera-se que esta framework possa tornar a realização de projetos mais eficiente, poupando tempo, e mantendo a consistência da comunicação e dos outputs. Considerou-se, no início do estudo, que os Front-End Style Guides (FESG) são a tipologia de Guias de Estilo cujas caraterísticas e desafios de implementação mais se aproximam da ferramenta a desenvolver neste projeto, e sobre a qual se poderia obter informação mais relevante para apoiar o desenvolvimento da framework. Desta forma, as questões que

orientaram este estudo, centraram-se na identificação do seguinte conjunto de condicionantes e fatores:

1) principais dificuldades encontradas na implementação de um FESG; 2) principais secções e elementos a incluir nos FESG;

3) áreas profissionais onde é comum encontrar a aplicação de FESG 4) boas práticas na criação e no desenvolvimento de FESG;

5) principais vantagens da utilização de FESG.

A metodologia inicial começou pela revisão da literatura e pela seleção e identificação de guias de estilos para analisar e enquadrar numa grelha de observação elaborada para o efeito. Numa segunda fase, foram realizadas entrevistas semi-estruturadas com profissionais das áreas do design e programação para a web nas quais foram analisados os resultados provenientes da grelha de observação. Na terceira fase foi criado um protótipo com vista a delinear a arquitetura da informação, definir o peso, relevância e relação dos elementos. Posteriormente deu-se início à criação da framework em HTML.

A criação desta framework vem dar resposta à necessidade de haver um maior fluxo de conhecimento multidisciplinar dentro das organizações. Atualmente, e especialmente em organizações de pequena e média dimensão, a informação já não se encontra contida em silos, nem é detida por departamentos específicos. É comum depararmo-nos com programadores a facultar informações geralmente detidas pelo

(16)

departamento de design para, por exemplo, aplicar uma cor específica no background de uma página web, um marketeer que precisa saber como estilizar corretamente um botão a incluir numa e-newsletter, ou um designer que gostaria de obter mais

informação sobre os objetivos e valores da organização para se inspirar na criação de uma peça de comunicação. Esta troca de informação pode levar ao desperdício de tempo, frustração, surgimento de erros e à interrupção do fluxo de trabalho enquanto se aguarda por uma informação simples que poderia estar segura e rapidamente disponível num Guia de Estilo para o Desenvolvimento de Produtos Digitais (GEPD) como o que poderá ser criado com o auxilio da framework desenvolvida ao longo do presente estudo.

Enquadramento

Os Guias Estilo têm vindo a agilizar a forma como profissionais de áreas criativas desenvolvem o seu trabalho e a impactar positivamente a coerência da comunicação. Estes guias refletem o pensamento por trás da estratégia de

comunicação das marcas, quer a nível de design, valores e posicionamento, e regem a forma como os conteúdos são percecionados. O grau de rigidez dos Guias de Estilo varia de acordo com a natureza do público-alvo e com a liberdade criativa dada pela organização a quem comunica a sua imagem e valores.

Estes guias dividem-se geralmente em cinco tipologias, nomeadamente: (1) Guias de Estilo Editoriais e de Conteúdo; (2) Guias de Estilo de Marca e Identidade Corporativa; (3) Guias de Estilo de Programação e Estandardização de Código; (4) Guias de Estilo de Interação Humano-Computador; e (5) Guias de Estilo para a Web.

A nível de formatos, podem ser criados e distribuídos em papel ou online, de forma privada (utilizados apenas pelos colaboradores da respetiva organização) ou pública, caso em que o guia se encontra também acessível a elementos externos à organização.

Como forma de dar resposta à complexidade dos guias existentes e à multidisciplinariedade das equipas, este trabalho tem como objetivo criar uma framework para o desenvolvimento de GEPD que deverá tornar o trabalho das equipas mais celebre e agilizar o acesso à informação necessária para o

(17)

Objetivos e motivação

As equipas responsáveis pela criação de websites são cada vez mais

pluridisciplinares, podendo trabalhar assincronamente em espaços-tempos distintos. A ausência de um guia de estilo que identifique os principais aspetos a considerar na génese de um produto digital poderá levar a perdas de tempo desnecessárias e ao surgimento de diferenças criativas que porão em causa o bom relacionamento da equipa e a consistência da comunicação.

Existem atualmente diversas tipologias de guias de estilo, contudo, aqueles geralmente utilizados no desenvolvimento de produtos digitais são muitos específicos de cada uma das disciplinas de conhecimento para as quais dão resposta. Porém, em empresas de menor dimensão, verifica-se que cada colaborador poderá desempenhar múltiplos papeis e ter que aceder rapidamente a informações que estão tipicamente sobre a alçada de outros departamentos. O investigador deparou-se com esta situação ao longo do seu percurso profissional em pequenas e médias empresas. A importância da utilização de Guias de Estilo para manter a coerência da comunicação da marca surgiu aquando do estágio curricular na agência de marketing na qual viria a trabalhar. Aqui foi-lhe pedido que desenvolvesse um Manual de Identidade Corporativa para a organização, no qual figurassem as cores, família de fontes, variantes do logótipo e exemplos de aplicação, entre outros. Este manual foi

fundamental para agilizar a criação de matérias publicitários e transmitir rapidamente a terceiros informações relacionadas com as caraterísticas da marca. Alguns anos depois, o investigador focou-se em construir uma ponte entre os departamentos de marketing, comunicação, design e programação. Nesta posição, apercebeu-se das necessidades, dúvidas e tempo investido pelos colegas na procura de informações dificilmente acessíveis, de rápida resposta e que influenciariam grandemente a qualidade do trabalho desenvolvido. Esta situação foi posteriormente confirmada pelos comentários recolhidos ao longo das entrevistas realizadas, nas quais os entrevistados demonstraram a necessidade de aceder a informação detida pelo departamento de design como, por exemplo, códigos de cor da marca, informação sobre a disposição do logótipo, ou simplesmente que família de fontes utilizar em determinada situação.

(18)

guias de caráter mais genérico, capazes de ser lidos, compreendidos e utilizados por profissionais de várias disciplinas. Com o auxílio desta ferramenta, é esperado que a criação do manual seja mais célere, consistente e permita a uma equipa identificar a importância de cada um dos elementos e escolher quais os mais apropriados a incluir no desenvolvimento do GEPD pelo qual estão responsáveis.

Organização do documento

A dissertação é estruturada em capítulos que visam organizar a informação e explicar de forma detalhada os conceitos e processos associados ao seu

desenvolvimento. O conteúdo de cada um dos capítulos é sintetizado da seguinte forma:

Capítulo 1 – Enquadramento teórico

Devido às variadas áreas disciplinares envolvidas na criação de um GEPD, foi recolhida, ao longo do enquadramento teórico, informação que abrange as áreas do branding, design e desenvolvimento de software. Neste capítulo é estudada a importância da coerência da comunicação da marca em todos os pontos de contacto com o consumidor, as diferentes tipologias de Guias de Estilo, algumas das mais importantes metodologias de desenvolvimento de software e as características dos padrões de design de interação.

Capítulo 2 - Metodologia

Neste capítulo são abordados os procedimentos metodológicos levados a cabo no desenvolvimento do projeto, os instrumentos utilizados e os procedimentos

adotados para a seleção da amostra. Começou-se por criar uma tabela comparativa de análise dos diferentes manuais de identidade e FESG com vista a aferir quais os elementos mais relevantes a incluir na framework. Numa segunda fase foram realizadas entrevistas semi-estruturadas a profissionais de design e programação a residir em Aveiro e Lisboa, e a desempenhar funções nas áreas da imprensa, telecomunicações, visualização de dados e desenvolvimento de software. Estas

(19)

entrevistas tiveram como objetivo validar a organização da framework, baseada na tabela comparativa, e recolher sugestões para o seu desenvolvimento.

Capítulo 3 – Resultados do estudo

No terceiro capítulo é dado a conhecer o processo para a criação da framework, desde o protótipo inicial ao desenvolvimento da versão final da ferramenta. São também apresentados os resultados de aplicação da framework desenvolvida a um projeto real, em ambiente organizacional.

(20)
(21)

1 Enquadramento Teórico

Devido ao elevado número de disciplinas envolvidas na criação de um GEPD foi recolhida, ao longo do enquadramento teórico, informação que abrange as áreas do branding, design e desenvolvimento de software.

A primeira parte averigua a importância da coerência da comunicação da marca em todos os pontos de contacto com o consumidor. Seguidamente são analisadas as diferentes tipologias de Guias de Estilo existentes em várias áreas profissionais, desde o jornalismo ao desenvolvimento de software, com um enfoque particular nos guias utilizados ao longo do planeamento e desenvolvimento de Produtos Digitais.

Posteriormente foram estudadas algumas das mais importantes metodologias de desenvolvimento de software, utilizadas no desenvolvimento de Produtos Digitais, e como os GEPD se poderão encaixar e melhorar o fluxo de trabalho destas equipas. Finalmente serão abordadas as caraterísticas dos padrões de design, nomeadamente os padrões de design de interação, com vista a compreender de que forma poderão estes contribuir para o desenvolvimento do guia.

1.1 A Marca

A Internet veio trazer uma maior concorrência entre produtos e organizações. O rápido acesso à informação, a capacidade de encontrar produtos ao mais baixo preço, a diminuição das barreiras à entrada de novas empresas e a fácil importação de bens dificultam a diferenciação pelas caraterísticas do produto, tornando o papel da marca cada vez mais preponderante (Haucap & Heimeshoff, 2014). As marcas têm como fundamental objetivo criar uma ligação de cariz emocional com o público, com vista a gerar não só clientes, mas também fãs e embaixadores (Wheeler, 2006). Pretende-se que esta relação dure para toda a vida e seja capaz de tornar a marca insubstituível. A marca é assim a perceção que os clientes têm de um produto, serviço ou experiência (Neumeier, 2004) — uma forma de reputação comercial — como também a soma do valor extra que os consumidores irão pagar, ou a frequência com que optam pelas expectativas, memórias, estórias e relacionamentos de uma marca em detrimento de outras alternativas (Godin, 2009). A força da marca influencia o

(22)

uma organização sem fins lucrativos ou de uma startup (Wheeler, 2009).

1.1.1 Branding e elementos da Marca

A marca não é estática, mas sim um “organismo vivo” que se adapta ao meio, mantendo sempre os seus valores como a base dessa evolução. Tal como as marcas, as organizações devem-se transformar, mover e interagir de forma a se conseguirem adaptar à mutabilidade do mercado (Leitão, Lélis, & Mealha, 2014). A marca abraça todos os elementos que a constituem, transformando-os num sistema. Alguns desses elementos são: (a) o nome; (b) o logótipo; (c) tag line, true line, slogan ou mantra; (d) símbolo, ícone ou marca; (e) assinaturas ou trademarks; (f) cor; (g) tipografia; (h) iconografia; (i) som; (j) movimento; (k) sabor ou aroma; (l) formas de interação; (m) ou outras manifestações que possam ser registadas (Amado & Fonseca, 2014), encontradas na (figura 1).

Figura 1 – Pontos de contacto com o consumidor

(23)

Consistência

A comunicação da marca deve ser feita de forma consistente e continuada para, ao longo do tempo, criar o seu espaço na mente do consumidor (Eisenberg & Eisenberg, 2006). Esta comunicação deve trazer consistência, visual, verbal, a nível de pensamento e intenção, aos elementos distintivos da marca para ajudar ao

crescimento da empresa e tornar a venda de produtos mais eficaz (Wheeler, 2006).

1.2 Guias de Estilo

Os guias de estilo são utilizados nas áreas da educação, jornalismo, política, advocacia, marketing, design para a web, programação, design gráfico, sendo que a sua tipologia varia consoante a área de aplicação. Estas tipologias dividem-se em guias de estilo editoriais e de conteúdos (jornalismo, governo, advocacia, marketing), manuais de identidade corporativa (marketing, design gráfico), guias de estilo de programação e estandardização de código (design para web, programação), guias de estilo de interface humano-computador (design para a web, programação) e os guias de estilo para a web (design para a web, programação).

Os guias de estilo visam manter a solidez visual e funcional dos elementos da marca e da forma como estes se relacionam entre si através da promoção de boas-práticas a nível de design, reforçando o branding de forma consistente (Gale, 1996), sendo que o seu conteúdo pode variar de projeto para projeto ou de organização para organização.

Estes guias poderão seguir uma linha mais estrita e ditar regras a ser impreterivelmente aplicadas por quem com eles trabalha, ou apresentar conselhos, isto é, regras gerais que poderão ser quebradas caso o designer/programador ache justificável fazê-lo (Debenham, 2013).

1.2.1 Guias de Estilo Editoriais e de Conteúdos

Os guias de estilo de conteúdo focam-se na forma como a empresa comunica com o público, especialmente no que refere à comunicação online, estabelecendo regras para garantir que o conteúdo apresentado é sempre coerente e respeita a

(24)

mensagem e o tom-de-voz da marca. Os conteúdos são variados e podem abranger os elementos visuais, copy, SEO, metadata e comunicação nas redes sociais.

Já os guias de estilo editoriais pretendem ser uma ponte entre os

escritores/jornalistas e os editores permitindo uma comunicação consistente e clara quer em meios impressos ou eletrónicos. Enumeram e respondem a algumas das principais questões que podem surgir sobre títulos, significado de palavras ou imagens. O “Editorial Style Guide for Yale University Publications” (Yale University, 2011), encontrado na figura 2, é exemplo disso, apresentando

imediatamente na sua capa alguns cuidados e regras a seguir pelos investigadores da Universidade de Yale aquando da formatação das suas publicações. O Livro de Estilos do jornal Público, por sua vez (figura 3), apresenta um conjunto de regras técnicas e deontológicas que se inspiram em critérios de bom senso, bom gosto e rigor profissional (Público, 1998).

(25)

Figura 3 - Livro de Estilo do Público

1.2.2 Manuais de Design Gráfico

Os manuais de design gráfico começaram por ser utilizados para aconselhar e definir regras de como comunicar a marca em materiais impressos (Gale, 1996). Geralmente denominados de “identity standards manuals”, os nomes variam bastante, encontrando-se outras denominações como “brand bible” e “brand guidelines”, por exemplo. A complexidade pode variar bastante entre manuais sendo que alguns são muito extensos e outros bastante sintéticos. Alguns dos principais temas abordados pelos manuais de identidade (Cousins, 2013) são:

1. resumo geral da marca, incluindo a sua história, visão e personalidade; 2. especificações quanto ao logótipo e exemplos de utilização;

3. tipografia; 4. palete de cores;

5. especificação do uso da imagem, incluindo estilo de fotografia; 6. estacionário [Economato, ou aplicações de material de escritório]; 7. layouts e grelhas para projetos web e impressos;

8. especificações para sinalética e publicidade em outdoors; 9. estilo de escrita e tom de voz;

(26)

10. indicações para comunicação nas redes sociais; 11. exemplos visuais que apoiem cada uma das regras.

Os temas abordados variam geralmente de manual para manual. Referência ainda para indicações alusivas ao tom-de-voz, encontradas em alguns dos manuais analisados que indicam como a marca deverá comunicar de forma escrita (principais palavras a utilizar, a sua ordem, ritmo e cadência), assim como os valores e

caraterísticas da personalidade a transmitir.

Contudo, os manuais de design gráfico não são adaptados para a web. Apesar de esta realidade ser considerada em alguns manuais, esta é apenas uma adaptação, quando deveria ser considerada de raiz. Um exemplo incorreto desta “adaptação forçada” é a utilização do sistema de cores CMYK para representar cores que deverão ser visualizadas no ecrã; ou a utilização de fontes visualmente ricas em papel, mas de difícil legibilidade em monitores de computador.

1.2.3 Guias de Estilo de Programação e Estandardização de Código

Estes guias são geralmente dirigidos a programadores e dão indicações no que respeita à organização do código desenvolvido para, especialmente em projetos colaborativos à distância, todos os participantes seguirem a mesma lógica de

organização. Algumas das indicações dadas poderão passar pela utilização de espaços ou tabs na indentação, pela utilização de underscores versus camelCase para

identificar variáveis, comentários, whitespace, naming, entre outros.

Um dos primeiros guias de estilo de programação e estandardização de código foi criado em 1992 pela W3C (figura 4) com vista a dar a conhecer as boas-práticas de utilização de código HTML (W3C, 1992). Estes apresentam uma série de

indicações tais como regras de capitalização, utilização de abreviaturas, pontuação, gramática, formatação de citações e outras referências.

(27)

Figura 4 - Guia de Estilo para formatação de HTML

1.2.4 Guias de Design de Interação

Os Guias de Estilo de Design de Interação são: ferramentas que asseguram a consistência de um conjunto de produtos; um repositório de guias e padrões de

design; uma forma de colocar grupos a trabalhar em conjunto; um auxiliar para novos membros de uma equipa (Wilson, 2001). Estes identificam algumas regras que devem ser respeitadas de forma a que a interface do produto final seja a mais coerente e intuitiva possível. Algumas destas regras deverão assegurar que determinados elementos, tais como botões e caixas de seleção têm o mesmo comportamento que aquele que os utilizadores já trazem de outras aplicações, podendo o conhecimento ser transferido de uma ferramenta para a outra com vista a diminuir o tempo de

aprendizagem e aumentar a satisfação ao utilizar o produto (Simpson, 1999). Alguns dos benefícios dos guias de design de interação passam por (Reed et al., 1999):

Conseguir um visual e uma funcionalidade específica. A estandardização

do aspeto visual e da funcionalidade do software permite que os utilizadores transfiram o seu conhecimento de utilização de um produto de software para outro, facilitando a sua utilização e evitando que tenham que passar por um novo processo de aprendizagem, diminuindo potenciais custos associados à formação;

Melhorar a consistência. A estandardização pode ocorrer em vários

(28)

aplicação em todo, ou partes, de um sistema operativo.

Investigação em Design de Interação. Os padrões utilizam o vasto

conhecimento da pesquisa e práticas aceites no campo do design de interação. Os autores dos padrões assimilam e interpretam a pesquisa, transformando-a em boas-práticas a ser seguidas pelos designers.

Agilização do desenvolvimento. Os padrões facilitam a tomada de decisão a

nível do design, fazendo com que estes possam investir o seu tempo em tomadas de decisão estratégicas que se revelem mais difíceis ou críticas.

Avaliar a usabilidade. Os padrões providenciam uma base para aferir a

usabilidade dos produtos. Numa situação em que todas as variáveis sejam iguais, um produto que vá ao encontro dos padrões de design de interação deverá ser utilizado mais facilmente comparativamente a outro onde isso não se verifique.

Os guias de design de interação podem ajudar as equipas de programação e comerciais em vários aspetos: no que toca aos programadores, estes passam por manter o controlo sobre o aspeto visual e funcional; minimizar a reinvenção; proporcionar melhorias a nível da aprendizagem; permitir a produção de software reutilizável e reduzir o tempo necessário para o desenvolvimento e reduzir decisões de design arbitrárias. Já para a equipa comercial, as vantagens passam por criar sistemas que reduzam os custos com o apoio técnico e aumentar a satisfação do utilizador; melhorar o conhecimento do mercado; melhorar o conhecimento do produto e reduzir custos com a formação; diminuir a rotatividade da equipa e aumentar a aceitação de novos sistemas por parte dos utilizadores (Wilson, 2001).

Front-End Style Guides

São os FESG os que mais contribuem para a consistência dos elementos da Marca na web. A principal diferença entre os guias de estilo “tradicionais” e os FESG é o facto dos últimos serem gerados através de código informático e apresentados no browser, geralmente numa só página, atribuindo uma lógica modular no que refere ao desenvolvimento (Debenham, 2011).

Os FESG são compostos por elementos que operam de forma modular, como blocos que compõem o website, cujo código pode ser copiado e replicado em

(29)

podem ser combinados como uma colagem para formar um sistema (Frost, 2014). Os módulos existentes são apresentados no pattern portfolio; uma página que reúne todos os módulos do website.

Figura 5 – Front-End Style Guide do MailChimp

Criados e mantidos por programadores front-end, os FESG são compostos por blocos de código HTML. A este código são atribuídas classes específicas que,

estilizadas através de CSS e Javascript, irão editar visualmente cada componente do website. Isto permite que ao modificar uma porção do código, as alterações

visuais/funcionais se propaguem instantaneamente por todo o website. Os FESG permitem ainda agilizar o fluxo de trabalho dos membros da equipa e definir standards, de forma a tornar o código mais fácil de reutilizar e consultar.

Anna Debenham identifica duas formas de abordar as guias de design. Estas podem ser pouco rígidas e dar ao designer a possibilidade de ser criativo — como é o caso do “Brand Toolkit” da Mozilla — ou bastante precisas, encorajando a uma maior consistência na forma como a marca é apresentada, como nas “Human Interface Guidelines” da Apple (Debenham, 2011).

Os FESG permitem, por um lado, detetar mais facilmente falhas a nível da aplicação de estilos tipográficos e, por outro, ter a certeza que estes serão sempre aplicados de forma consistente e se adaptam corretamente às caraterísticas dos diferentes dispositivos e tamanhos de ecrã de forma a manter a legibilidade. Esta flexibilidade permite testar vários tamanhos de texto, fontes, cores e como estes

(30)

afetam os restantes elementos visuais presentes nas páginas de forma a tomar decisões que permitam criar um resultado final coeso, pensado de forma holística ao invés de página-a-página. Contudo, nem todas as organizações estão preparadas para investir os recursos necessários no desenvolvimento de um FESG.

1.3 Desenvolvimento de Software

O desenvolvimento de software diz respeito ao processo de programação de computadores, elaboração de documentação, realização de testes e correção de bugs.

Este processo tem vindo a evoluir ao longo dos anos (Cooper, Reimann, & Cronin, 2014). Numa fase inicial, o programador era responsável pela conceção, programação e realização dos testes ao produto digital até este estar pronto para distribuição comercial. Os programadores viram aqui a necessidade de começar a colaborar com gestores, capazes de aferir as necessidades de mercado para o qual o produto digital seria desenvolvido para aumentar a viabilidade do mesmo. Com o surgimento dos graphical user interfaces (GUI) os designers começaram também a fazer parte da equação e tornaram-se responsáveis por compreender as necessidades dos utilizadores e criar interfaces intuitivas e apelativas. A figura 6 ilustra a evolução e as várias fases do processo de desenvolvimento de software (Cooper et al., 2014).

(31)

Figura 6 – Evolução do processo de desenvolvimento de software

Assim, o desenvolvimento de software, pode incluir a investigação, desenvolvimento, prototipagem, modificação, reutilização, re-engenharia,

manutenção ou quaisquer outras atividades que resultem em produtos de software — tal como a produção/desenvolvimento de páginas da web. Estes podem ser

desenvolvidos para uma variedade de propósitos, sendo que, os três mais comuns são o atender às necessidades específicas de um cliente (como é o caso do software personalizado), atender a uma necessidade percebida por um grupo de utilizadores potenciais (como no caso do software open-source ou comercial) ou para utilização pessoal (desenvolvimento de software para agilizar tarefas recorrentes).

Existem atualmente 10 categorias de desenvolvimento de software (Neef, 2015): desenvolvimento para a web, desenvolvimento mobile, data science, desenvolvimento de aplicações, desenvolvimento back-end, desenvolvimento de ferramentas de software, desenvolvimento de API, desenvolvimento de sistemas embebidos, desenvolvimento de software de segurança e computação na nuvem. Para o desenvolvimento de software para cada uma destas categorias, os responsáveis de projeto recorrem a metodologias de desenvolvimento (também conhecidas como modelos ou ciclo-de-vida de desenvolvimento de software), cada uma com um

(32)

propósito, pontos fortes e pontos fracos (Preece, Rogers, & Sharp, 2002). Existem várias abordagens diferentes para o desenvolvimento de software: algumas seguem uma abordagem mais estruturada, baseada em engenharia para o desenvolvimento de soluções de negócios, enquanto outras apresentam uma abordagem mais incremental, em que o software evolui enquanto é desenvolvido peça-a-peça. Algumas das

abordagens mais reconhecidas são o modelo Waterfall, o modelo iterativo, o modelo espiral, o V-Model e o modelo Big Bang.

As fases de desenvolvimento podem ser do tipo linear (Waterfall), do tipo iterativo (prototipagem, RAD) ou uma combinação dos dois (Incremental, Espiral) (Department of Health & Human Services - USA, 2005). No tipo iterativo é investido menos tempo no planeamento e documentação, e mais tempo na criação de código e desenvolvimento de testes e apresentando um produto funcional (ou livre de bugs) em praticamente todas as fases do ciclo-de-vida.

A metodologia Waterfall foi a primeira abordagem a ser aplicada ao desenvolvimento de software. Aqui, os responsáveis pelo projeto tentam aferir a maioria dos riscos numa fase inicial e desenvolver um plano detalhado para o software antes da implementação (início do desenvolvimento de código), e evitar mudanças de projeto significativas e re-codificação em fases posteriores do ciclo-de-vida (Balaji, 2012). Existem vantagens e desvantagens visíveis para cada uma das abordagens, sendo que a melhor abordagem para a resolução de um desafio com base no desenvolvimento de software depende muitas vezes da natureza do próprio

desafio. O modelo Waterfall deve ser utilizado em situações nas quais o projeto é grande, complicado e envolve muitos recursos, o projeto tem objetivos claros e uma solução definida, não existe pressão para uma implementação imediata; os requisitos do projeto são estáveis ao longo do ciclo-de-vida do desenvolvimento, a composição da equipa é instável e poderá flutuar (Department of Health & Human Services - USA, 2005). Se, por outro lado, o problema for único e a solução não poder ser visualizada à partida pela equipa de desenvolvimento, então uma abordagem mais extrema pode revelar-se a solução mais adequada.

(33)

1.3.1 Abordagens de desenvolvimento

Modelo Waterfall

O modelo Waterfall é um processo de desenvolvimento sequencial, utilizado na criação de software em que o processo é visto como se a fluir de forma constante para baixo (como uma cascata), passando pelas fases de conceção, iniciação, análise, projeto, construção, teste, produção/implementação e manutenção (Preece et al., 2002). Este modelo deverá ser utilizado quando os requisitos são conhecidos, claros e fixos; o produto está bem definido; a tecnologia é compreendida, não existem

requisitos ambíguos; existem amplos recursos disponíveis e conhecimento necessário, o projeto é curto (Petersen, Wohlin, & Baca, 2009).

Este modelo teve origem nas industriais da manufatura e de construção, aplicado a ambientes físicos altamente estruturados, nos quais a realização de uma alteração posterior se tornaria proibitivamente cara ou impossível. Como não existem metodologias formais de criação de software, este processo de desenvolvimento de estruturas físicas foi adaptado a esta realidade.

No modelo em cascata original (Royce, 1970) as fases implicadas seguem a seguinte ordem:

• Levantamento de requisitos de sistema e software, registados num documento;

• Análise: que resulta na elaboração de modelos, esquemas e questões relacionadas com o negócio;

• Design: que dá origem à arquitetura de software; • Teste: para a descoberta sistemática e correção de bugs;

• Operações: a instalação, migração, suporte e manutenção de sistemas completos.

Desta forma, a metodologia Waterfall realça que só se deverá avançar para a fase seguinte depois da fase anterior ter sido revista e verificada. Contudo, alguns dos modelos Waterfall, como o “Multi Waterfall” e o V-Model (Balaji, 2012), que

seguem uma lógica incremental, apresentam adaptações relativamente ao original que podem incluir pequenas ou grandes modificações a este processo, como por exemplo, voltar a uma fase anterior após serem encontradas falhas a jusante, ou até mesmo

(34)

voltar à fase de Design caso o desenvolvimento das fases a jusante sejam consideradas insuficientes.

Modelo Incremental

No modelo Incremental todos os requisitos são divididos em vários módulos menores e mais facilmente geridos (figura 7). Cada módulo passa pelas fases de requisitos, projeto, implementação e testes. É produzida uma versão funcional do produto de software durante o primeiro módulo o que torna possível ter um software operacional nas primeiras fases do ciclo-de-vida. Cada versão posterior do módulo acrescenta funções à versão anterior. O processo continua até que todo o sistema é concluído. No modelo incremental trabalha-se gradualmente, peça-a-peça, esperando-se que cada uma dessas peças esteja totalmente concluída (Taneja, Sarpal, & Arora, 2013).

Figura 7 - Diagrama do modelo Incremental

Modelo em Espiral

O modelo em Espiral (figura 8) é semelhante ao modelo incremental, contudo, é dada mais ênfase à análise de risco e à prototipagem (Boehm et al., 1987). O modelo incorpora estes dois aspetos numa framework iterativa que permite que as ideias e o progresso sejam constantemente analisados e avaliados, tendo como principal

(35)

objetivo o controlo de riscos. Contrariamente ao que se verifica no modelo Waterfall, o modelo em Espiral encoraja a consideração de alternativas e a reavaliação das fases nas quais possam surgir problemas.

Os requisitos são recolhidos durante a fase de planeamento. Na fase de análise de risco é realizado um processo para identificar riscos e possíveis soluções, sendo criado um protótipo no final desta fase. Na fase de engenharia é desenvolvido o software, aliado à realização de testes no final da fase. A fase de avaliação permite que o cliente avalie o resultado do projeto antes de este transitar para a próxima espiral.

Figura 8 - Diagrama do Modelo em Espiral

Modelo Agile

A filosofia Agile teve origem em 2001 com a criação do “Agile Manifesto” cuja finalidade foi a de encontrar um terreno comum para a promoção das melhores práticas para o desenvolvimento de software. Este Manifesto foi criado por um grupo de profissionais representantes das áreas de Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development e Pragmatic Programming (Robinson, 2013). O modelo Agile (figura 9) baseia-se numa filosofia iterativa que permite a criação de um produto de forma incremental. Um dos

(36)

principais benefícios é a possibilidade de adaptar e mudar o produto em qualquer fase, com base no feedback, condições do mercado e obstáculos organizacionais, com vista a criar um produto que esteja o mais próximo possível das necessidades do mercado (Sirina, 2016).

Figura 9 – Diagrama representativo do modelo Agile

Desde a criação do “Agile Manifesto” em 2001 surgiram vários métodos de desenvolvimento de software baseados no modelo Agile, tais como, DSDM, Extreme Programming, Feature Driven Development e SCRUM. Ao aplicar estes métodos o processo de desenvolvimento de software adapta-se mais facilmente ao ambiente em mudança, o software operacional torna-se mais relevante que a documentação extensa, os indivíduos e interações são considerados mais importantes que

ferramentas e processos, e o valor da colaboração do cliente é superior ao do contrato realizado (Vlaanderen, Jansen, Brinkkemper, & Jaspers, 2011). O SCRUM adjudica que muitos dos processos existentes durante o desenvolvimento de um produto de software não podem ser previstos, sendo que as únicas duas partes bem definidas durante o processo de criação de software são a primeira e a última (planeamento e encerramento) (Vlaanderen et al., 2011). Entre essas duas fases a equipa trabalha na criação do produto final numa série de fases denominadas de sprints durante os quais não podem ser introduzidos novos requisitos. O primeiro sprint é geralmente

denominado de sprint 0, durante o qual são definidos os aspetos centrais do projeto tais como questões relacionadas com formação, hardware e software a utilizar durante

(37)

o projeto. Existem ainda equipas nas quais se verifica a existência de um sprint -1, anterior ao sprint 0, composto por uma pequena equipa representativa do utilizador e da área de negócio para avaliação das necessidades e perceber as possibilidade do produto que será desenvolvido (Bowes, 2014).

1.3.2 Padrões de Design

Os padrões de design tratam-se da apresentação de melhores-práticas sistematizadas para dar resposta a problemas de design concretos e recorrentes (Tidwell, 2010).Tratam-se de soluções comprovadas para desafios a nível do design que consideram o problema em questão, e tentam balançar da melhor forma os pros e contras de cada abordagem, sugerindo a opção mais equilibrada. Os padrões podem ser de alto nível, descrevendo o contexto de aplicação, e padrões de baixo nível que podem ser utilizados no seguindo dos primeiros para refinar a solução (Borchers, 2001; Carvalhais, 2008). Segundo Carvalhais, os padrões de design “devem ser suficientemente abstratos para serem mais ou menos universais na sua utilidade, mas ao mesmo tempo, específicos o suficiente para terem alguma utilidade” (Carvalhais, 2008). Esta hierarquia estrutura uma coleção extensiva de padrões numa linguagem de padrões que por sua vez estão incluídas numa biblioteca de padrões (Camps, 2016).

Os padrões de design são encontrados em múltiplos domínios de conhecimento que podem ir da programação à arquitetura. Os primeiros e mais detalhados padrões de design surgiram com o livro “A Pattern Language” pelo autor Christopher Alexander. Aqui o autor define padrões de design como elementos de uma linguagem que relatam um problema que ocorre uma e outra vez na envolvente, descrevendo posteriormente o âmago da solução para esse problema (Alexander, Ishikawa, & Silverstein, 1977). Um problema de design encontrado no âmbito da arquitetura pode ser o facto de se desejar contruir uma habitação suficientemente iluminada, que possibilite uma boa iluminação durante todo o ano, mas que não se torne demasiado quente durante os meses quentes de verão. O padrão de design aqui aplicado não apresenta uma regra de como atuar, mas sim elementos que deverão ser considerados e adaptados de acordo com a localização, a experiência do arquiteto e os desejos do cliente. Essa solução pode depois ser aplicada milhões de vezes sem ser realizada duas vezes da mesma forma (Alexander et al., 1977). Efetivamente, documentar um padrão de design exige a explicação da situação em que um

(38)

determinado problema ocorre e como os componentes do padrão se relacionam entre si para chegar a uma solução (Maioriello, 2002).

Por sua vez, o primeiro livro relacionado com a aplicação de padrões de design a projetos de desenvolvimento de software e programação orientada a objetos surgiu em 1994 com a publicação do livro “Design Patterns: Elements of Reusable Object-Oriented Software”, por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides.

O livro apresenta 23 padrões de design identificados com base na experiência que os autores tinham na altura. Estes padrões foram selecionados por apresentar soluções de problemas comuns encontrados no processo de desenvolvimento de software. Neste caso em concreto, os padrões de design representam relações entre classes e objetos com responsabilidades definidas que atuam em concerto para chegar a uma solução. Um exemplo da aplicação dos padrões de design ao desenvolvimento de software é o padrão do Adaptador que apresenta uma solução num cenário em que o cliente e o servidor precisam interagir um com um outro, mas não podem porque as suas interfaces são incompatíveis.

A primeira coleção de padrões de design de interação surgiu com o livro “A Pattern Approach to Interaction Design”, publicado em 2001 por Jan Borchers. Este tema continuou a ser investigado com o livro “Common Ground”, publicado em 2005 por Jenifer Tidwell, que inspirou o surgimento de múltiplos padrões de design para o desenvolvimento de interfaces aplicadas a vários dispositivos com os quais

interagimos no nosso dia-a-dia, desde o smartphone ao televisor, passando pelo computador. Em “Common Ground”, Tidwell afirma que cada padrão tenta equilibrar um conjunto de forças que apontam para diferentes direções. O padrão define então uma regra primária sobre como essas forças podem ser transformadas para encontrar a melhor solução para um problema de design (Tidwell, 2000).

Os padrões de design permitem que profissionais de diferentes áreas expressem o seu conhecimento na forma de linguagem de padrões. Assim,

engenheiros de software, especialistas no desenvolvimento de aplicações e na área de interação humano-computador conseguem comunicar através de um vocabulário comum e mais explicito (Carvalhais, 2008). Outras das vantagens do uso de padrões dedesign passam por: facilitar a comunicação entre designers e engenheiros de software; melhorar a qualidade de soluções de design e reduzir o tempo e esforço em

(39)

novos projetos e facilitar a transmissão de conhecimento (Cooper et al., 2014).

1.3.3 Prototipagem e Fidelidade no desenvolvimento

No desenvolvimento de produtos digitais, os protótipos permitem criar uma representação visual da interface do sistema que poderá ser de menor complexidade e fidelidade ou representar de forma precisa a interface do produto final (Houde & Hill, 1997). Para criar um protótipo podem ser utilizadas várias ferramentas, como papel, ferramentas de design, software que permita simular fluxos de interação ou versões alfa do sistema final (Ribeiro, 2012). Os protótipos permitem consolidar ideias, fomentar a discussão saudável entre a equipa e apresentar um esboço a potenciais utilizadores para a realização de testes de usabilidade e identificar pontos de melhoria. Warfel identifica a sequência de fases que utiliza na sua organização para a criação de um protótipo: criação de esboços, apresentação e critica em equipa dos esboços realizados, desenvolvimento do protótipo, realização de testes (Warfel, 2009). No que refere à aproximação ao produto final, ou o grau de 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). Os protótipos de baixa fidelidade são representações simples, úteis nas primeiras fases do projeto pois permitem tangibilizar ideias a trocar com a equipa, experimentar e alterar com facilidade. Já os protótipos de alta fidelidade representam o aspeto final pretendido para a interface do sistema, servindo de base para a criação do mesmo. Não deve aqui haver uma preocupação com o nível de fidelidade durante o desenvolvimento do protótipo, sendo que o mais importante é que este cumpra os objetivos para com a audiência (Warfel, 2009).

(40)

1.4 Proposta de Framework para Guias de Estilo de

Produtos Digitais

A framework para a criação de GEPD pretende identificar quais os elementos mais importantes a ser considerados por programadores, designers e marketers, aquando do desenvolvimento e manutenção de um produto digital. Este termo quer-se abrangente, para conseguir abraçar as diferentes disciplinas referidas, contudo, poderá revelar-se algo impreciso por o termo “produto digital” poder englobar diversos tipos de produto. Para além da identificação dos elementos mais relevantes, esta framework tem também uma função formativa, contextualizando cada um dos elementos e

explicando o porquê da sua existência. Assim, considera-se que os principais objetivos desta ferramenta são:

- Criar uma ponte de comunicação entre departamentos;

- Identificar os elementos mais importantes a ser considerados na criação de um GEPD;

- Contextualizar cada um dos elementos identificados; - Ser adaptável à realidade da organização;

- Ser uma ferramenta de código aberto.

Ao longo das reuniões de orientação, o investigador conclui que os FESG, são a tipologia de guias de estilo cujas caraterísticas e desafios de implementação mais se aproximam da ferramenta a desenvolver neste projeto. A sua apresentação em forma de página web permite uma rápida atualização e adaptação dos conteúdos à

necessidade de organização; apresenta de forma clara o comportamento dos

elementos funcionais do website e possibilita a introdução de elementos multimédia que, caso necessário, poderão explicar mais claramente como preencher cada elemento identificado. Desta forma, procedeu-se à recolha de informação mais aprofundada sobre os FESG no que refere aos benefícios e forma de implementação, sendo esta apresentada nos pontos 1.4.1. e 1.4.2.

(41)

1.4.1. Passos para implementar um FESG

Para a criação da framework para o desenvolvimento de GEPD, o investigador irá inspirar-se no método delineado por Anna Debenham para a criação de FESG. Esta escolha prende-se com o facto de os FESG serem também Guias de Estilo

preparados para a web que contemplam alguns dos elementos visuais e funcionais que deverão estar presentes no website.

A autora começa por fazer referência à importância de imprimir e nomear representações dos elementos e componentes que serão necessários incluir no guia de estilos, fazendo uma nota do propósito de cada um dos componentes. Nesta fase, deverão ser atribuídas cores a diferentes elementos tais como links, headings e botões. Posteriormente são atribuídos estilos-base, associados a cada um dos elementos principais, tais como headings, links, tabelas, block quotes, listas ordenadas, listas desordenadas e formulários. Cada um destes elementos deverá ter um documento específico a ser reutilizado em cada projeto. Seguidamente deverão adicionados os componentes com prioridade sobre os estilos-base, tais como caixas de pesquisa, breadcrumbs, mensagens de feedback e comentários ao blogue. Deverão ser também incluídos estilos de interação, tais como o hover e o active nos botões. Finalmente, deverá ser criado o layout e incluir os componentes nos locais desejados. Cada layout pode ser apresentado em documentos separados ou todos no mesmo documento de forma organizada (Debenham, 2013).

1.4.2. Benefícios da utilização de FESG

No que refere aos benefícios de manter um FESG, verifica-se que estes são mais fáceis de testar pois um guia de estilos unificado simplifica a identificação de break-points, permitindo conhecer rapidamente como cada elemento se adapta a diferentes larguras de ecrã, testar bugs de browsers e criar uma folha de estilos impressa quando todos os elementos se encontram na mesma página. O FESG traz ainda melhorias a nível do fluxo de trabalho já que a criação de uma ferramenta deste género no início do desenvolvimento do website agiliza todo o processo

comparativamente à criação de um guia para todas as páginas. O FESG permite ainda perceber como cada elemento se relaciona com todo o website e não apenas com a

(42)

página onde está inserido. Para além dos aspetos mencionados anteriormente, o FESG é ainda uma referência útil na medida em que se pode tornar numa checklist para designers e copywriters pois facilita a articulação dos elementos a incluir no website para que nenhum elemento importante seja esquecido.

1.5 Considerações finais do enquadramento teórico

O enquadramento teórico aqui realizado pretendeu dar resposta ao desafio deste projeto que passa pela criação de uma framework para o desenvolvimento de GEPD. Estes visam melhorar a comunicação entre equipas multidisciplinares, agilizar a criação de produtos digitais e possibilitar a comunicação dos elementos da marca de forma harmoniosa, em cada um dos pontos de contacto, para que possa ser percecionada pelos clientes como se de uma pessoa real se tratasse.

Tendo como referência as tipologias de guias de estilo identificadas no enquadramento teórico, verifica-se que os GEPD irão combinar algumas das caraterísticas dos manuais de design gráfico, dos guias de design de interação e dos guias de estilo para a web, mais concretamente dos FESG. Pretende-se assim identificar quais os elementos presentes nestes manuais que poderão ser úteis a indivíduos de áreas profissionais diferentes daquelas para as quais os manuais foram especificamente criados, e que deverão ser incluídos no GEPD.

Dada a multidisciplinariedade de perfis, será também importante recorrer à utilização de padrões de interação que sejam reconhecíveis pelos profissionais das várias áreas e que ajudem a tornar a ferramenta o mais intuitiva possível. Por a criação de um guia com estas particularidades envolver a análise de uma grande quantidade de informação, que terá que ser analisada e filtrada para chegar aos elementos mais relevantes, é importante que o

desenvolvimento da framework seja realizado de forma iterativa, recorrendo a protótipos passiveis de serem analisados e validados pelos utilizadores com vista à sua continua melhoria. O desenvolvimento da framework seguirá uma abordagem iterativa pois será necessário testar a ferramenta junto dos utilizadores e melhorá-la de acordo com o feedback obtido para possibilitar criar um produto o mais próximo possível das suas necessidades dos profissionais. Para tal será seguida uma abordagem Agile na qual serão definidas à partida metas por cada fase de iteração, geralmente definidas pelo orientador. Cada iteração terá uma

(43)

onde serão apresentados os outputs criados na última fase de iteração e delineadas as metas a concretizar na próxima iteração. Espera-se que a framework para o desenvolvimento de GEPD seja aplicada par-a-par com o desenvolvimento dos projetos de forma a que os responsáveis possam recorrer à lista de elementos disponibilizada, ao longo do processo. Numa fase inicial da aplicação poderão não ser preenchidos todos os pontos, sendo estes completados à medida que o projeto avança, servindo simultaneamente como um guia e como um elemento que irá fomentar a reflexão entre os membros da equipa sobre a melhor forma de abordar o desenvolvimento do Produto Digital.

2 Metodologia

No presente capitulo será identificada e analisada a metodologia a levar a cabo para o desenvolvimento do projeto. Aqui serão abordados os procedimentos

metodológicos a realizar na pesquisa, tais como a sua classificação em função da natureza, do problema, dos objetivos, da abordagem e dos procedimentos técnicos. Neste capítulo serão igualmente identificados os instrumentos utilizados e os procedimentos adotados para a seleção da amostra.

2.1 Abordagem metodológica

Esta investigação optará por uma abordagem metodológica qualitativa. Nesta abordagem, a nível conceptual, o objeto de estudo da investigação não são os

comportamentos, mas as intenções e situações, ou seja, trata-se de investigar ideias, de descobrir significados nas ações individuais e nas interações sociais a partir da perspetiva dos atores intervenientes no processo (Coutinho, 2013).

Esta perspetiva enquadra-se no que é pretendido para a presente investigação que tem como um dos seus objetivos recolher opiniões e ideias de profissionais e compreender o porquê das suas respostas com vista a fundamentar corretamente cada um dos elementos elegidos para fazer parte da framework para a criação de GEPD.

(44)

pois o investigador pretende desvendar a intenção, o propósito da ação, estudando-a na sua própria posição significativa sem impor expectativas prévias ao fenómeno estudado (Coutinho, 2013).

2.2 Metodologia de investigação

Neste trabalho será utilizada uma metodologia de investigação de desenvolvimento. Esta metodologia apresenta duas tipologias (Richey & Klein, 2005), sendo que, para este projeto concreto, será utilizada uma investigação de desenvolvimento do tipo 2 na qual é dada ênfase ao estudo do design,

desenvolvimento, ou processos de avaliação, ferramentas ou modelos para a criação de um produto final, neste caso uma framework para a criação de GEPD. Contudo, esta metodologia de investigação não pode ser considerada pesquisa científica pois não pretende obter conclusões de natureza generalizável (Akker, 1999).

A tabela 1 apresenta as principais diferenças entre as duas tipologias de Investigação de Desenvolvimento (Richey & Klein, 2005).

Tabela 1 - Sumário das duas tipologias de Development Research

Tipo 1 Tipo 2

Ênfase

Estudo do desenvolvimento de um produto ou programa específico e/ou projetos de avaliação. Estudo do design, desenvolvimento, ou processos de avaliação, ferramentas ou modelos. Produto

Conhecimento obtido a partir do desenvolvimento de produtos específicos e análise das condições que facilitam a sua utilização.

Novo design, desenvolvimento e avaliação de procedimentos e/ou modelos e condições que facilitem a sua utilização.

Conclusões específicas do

(45)

A maioria dos projetos de investigação de desenvolvimento enquadram-se na primeira tipologia, sendo geralmente empregada na análise de estudos de caso (Richey & Klein, 2005). Esta é utilizada em situações em que o processo de

desenvolvimento de um produto num contexto específico é descrito e analisado. No final da investigação são obtidas conclusões e avaliações sobre todo o processo. A segunda tipologia de investigação de desenvolvimento é orientada a uma análise mais geral do design, do desenvolvimento ou dos métodos de avaliação de um processo no seu todo ou a nível de um elemento em particular. Geralmente, nesta segunda

abordagem, a pesquisa não se inicia com a criação de um produto ou programa, focando-se no desenvolvimento a um nível mais genérico. As conclusões obtidas na investigação de desenvolvimento identificam princípios gerais que poderão ser

aplicáveis a um vasto leque de projetos de design e desenvolvimento, sendo que não é raro que a investigação de desenvolvimento do tipo 2 possa gerar mais do que um tipo de conclusão (Richey & Klein, 2005). A tabela 2 identifica algumas das metodologias de pesquisa aplicadas nas fases de desenvolvimento da framework para o

desenvolvimento de GEPD.

Tabela 2 - Métodos de Investigação Empregados na Pesquisa de Desenvolvimento

Função / Fase Metodologias de pesquisa aplicadas Desenvolvimento do

Modelo

Revisão da literatura, caso se estudo, inquérito, Delphi, protocolos think-aloud

Utilização do Modelo Inquérito, entrevista em profundidade, caso de estudo, observação de campo, análise documental

Validação do Modelo Experimental, entrevista em profundidade, análise por peritos, replicação

Independentemente da tipologia utilizada, esta metodologia pode incluir várias fases distintas, com cada uma a envolver o relato e a análise de um conjunto de dados. Na investigação de desenvolvimento o investigador pode recorrer a várias

(46)

para a realização da investigação (Richey & Klein, 2005).

2.3 Metodologias de pesquisa a aplicar

2.3.1 Análise Documental

A importância da análise documental é cada vez mais relevante graças à elevada quantidade de informação disponibilizada pelas tecnologias de informação e comunicação (TIC). Estas têm impulsionado o acesso à informação e à criação de redes de conhecimento, facilitando o acesso e tratamento de grandes volumes de informação. Apesar do acesso facilitado, ganha aqui importância a capacidade

intelectual do investigador para identificar e recolher elementos que se possam revelar importantes para a pesquisa (Peña Vera & Pirela Morillo, 2007).

Neste caso em particular, a análise documental passará por duas etapas: (a) revisão da literatura, com vista a conhecer a investigação existente na área

que possa servir de guia para a criação da framework para o

desenvolvimento de GEPD. Para além da leitura de artigos científicos será conduzida ainda a segunda etapa;

(b) recolha de guias de estilo para análise, com vista a criar uma tabela comparativa onde figurem os principais elementos a incluir na framework, ou seja, proceder à análise de vários documentos com vista a gerar um novo documento, diferente dos originais (Peña Vera & Pirela Morillo, 2007).

2.3.2 Survey por entrevista presencial recorrendo a um guião semi-estruturado

Na entrevista semi-estruturada, o investigador tem uma lista de questões ou tópicos a ser cobertos (guião de entrevista), mas a entrevista em si permite uma relativa flexibilidade. As questões podem não seguir exatamente a ordem prevista no guião e poderão, inclusive, ser colocadas questões que não se encontram no mesmo, em função do decorrer da entrevista. Segundo Coutinho a entrevista semi-estruturada é utilizada quando se pretende obter dados comparáveis dos vários participantes (Coutinho, 2013).

(47)

Entre as principais vantagens das entrevistas semi-estruturadas, contam-se as seguintes: possibilidade de acesso a uma grande riqueza informativa (contextualizada e através das palavras dos atores e das suas perspetivas); a possibilidade do

investigador esclarecer alguns aspetos no seguimento da entrevista, contrariamente ao que se verifica na entrevista estruturada ou questionário; é geradora, na fase inicial de qualquer estudo, de pontos de vista, orientações e hipóteses para o aprofundamento da investigação, a definição de novas estratégias e a seleção de outros instrumentos (Given, 2008). Pretende-se utilizar este método para a recolher informação junto da amostra de forma a conhecer opiniões sobre a utilização de FESG e como esta poderá ser melhorada. Será ainda dado a conhecer a estrutura da framework, desenvolvida através da análise documental, para validação e sugestão de melhorias.

2.3.3 Resumo da metodologia a utilizar

A tabela 3 apresenta um quadro resumo do paradigma, perspetiva metodológica, método de investigação, técnicas e instrumentos que serão utilizados ao longo da investigação.

Tabela 3 - Procedimentos metodológicos

Paradigma Qualitativo / Interpretativo

Perspetiva metodológica Qualitativa

Natureza do processo de investigação Descoberta indutiva

Método de investigação Investigação de Desenvolvimento

Métodos de recolha de dados Análise documental; Entrevistas estruturadas; Gravações áudio

Instrumentos Entrevista semiestruturada, Análise de Conteúdo

(48)

2.4 Desenho do estudo e recolha de dados

Na tabela 4 são apresentadas fases da investigação e as metodologias de pesquisa aplicadas, a elas associadas.

Tabela 4 – Desenho do estudo

Identificação da fase

Identificação da etapa Detalhes da etapa

1ª Fase – Levantamento e análise guias de estilo de marca e para a web

Levantamento de guias de estilo Pesquisa de guias de estilo de diversos sectores e profissões

Criação de tabela comparativa Dissecação dos manuais e identificação dos elementos utilizados em cada um

Identificação dos elementos a utilizar no modelo

Identificação dos elementos utilizados nos guias de estilo para de marca e para a web analisados

2ª Fase – Validação da tabela através da realização de entrevistas a profissionais

Criação do guião de entrevista

Identificação dos participantes

Contacto Contactar os participantes e chegar a um acordo sobre a data e local das entrevistas

Redação da autorização Elaboração da autorização a preencher por cada um dos participantes

Entrevistas Realização das entrevistas

Transcrição das entrevistas

Validação Leitura e validação das entrevistas por parte dos entrevistados

Codificação das entrevistas Criação dos nós para análise e comparação das respostas dos entrevistados

Referências

Documentos relacionados

Este artigo está dividido em três partes: na primeira parte descrevo de forma sumária sobre a importância do museu como instrumento para construção do conhecimento, destaco

Local de realização da avaliação: Centro de Aperfeiçoamento dos Profissionais da Educação - EAPE , endereço : SGAS 907 - Brasília/DF. Estamos à disposição

Código Descrição Atributo Saldo Anterior D/C Débito Crédito Saldo Final D/C. Este demonstrativo apresenta os dados consolidados da(s)

A participação foi observada durante todas as fases do roadmap (Alinhamento, Prova de Conceito, Piloto e Expansão), promovendo a utilização do sistema implementado e a

Ainda segundo Gil (2002), como a revisão bibliográfica esclarece os pressupostos teóricos que dão fundamentação à pesquisa e às contribuições oferecidas por

Para Piaget, a forma de raciocinar e de aprender da criança passa por estágios. Por volta dos dois anos, ela evolui do estágio sensório motor, em que a ação envolve os

A DWX-4 é ideal para laboratórios de pequeno e médio porte, que ainda não usam ferramentas digitais, ou para aqueles laboratórios com scanners que não desejam mais terceirizar

Por último, temos o vídeo que está sendo exibido dentro do celular, que é segurado e comentado por alguém, e compartilhado e comentado no perfil de BolsoWoman no Twitter. No