atividades de analytics para lançar website

Checklist de Atividades de Analytics para (Re)Lançamento de um Website - 11 Atividades a Considerar - PARTE 3

Introdução

Finalmente chegámos à PARTE 3 dos artigos sobre o tema de atividades a ter em consideração no (re) lançamento de um website. Na PARTE 1 – Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website – 12 Atividades a Considerar, vimos as atividades na área de UX/UI que deveríamos considerar ao (re) lançarmos um website. E na PARTE 2 – Checklist de Atividades de SEO para (Re)Lançamento de um Website – 13 Atividades a Considerar, vimos as atividades na área de SEO que deveríamos considerar ao (re)lançarmos esse mesmo website.

Nesta PARTE 3, o objetivo é elencar, de forma não exaustiva, as atividades de analytics, foco no Google Analytics, que é necessário não esquecer quando estamos a (re) lançar um website.

Obviamente que à partida estou a considerar que os Objetivos de Medição estão estipulados e assimilados pelas áreas, bem como já existe um conhecimento daquilo que são os KPIs a monitorar e, consequentemente, existe um Plano de Medição na sua versão mais básica, uma vez que tudo o que irei descrever depois deverá ser pormenorizado no novo Plano de Medição.

1. Tags GTM – Google Tag Manager

O que é: É um container JavaScript que nos permite implementar e incorporar diversas tags de medição daquilo que acontece no website.
Para que serve: Recorrendo à implementação de tags via GTM vai-nos permitir não ter a necessidade recorrente de pedir a um developer para o fazer diretamente no código fonte do website e, portanto, também não vamos sobrecarregar o website com código javascript diminuindo a sua velocidade de carregamento de páginas.
Quais são os seus componentes: nd. Ainda assim, quando estamos a criar as diferentes tags de medição, como por exemplo a tag de Google Analytics, é preciso ter em consideração que a tag em si, exige sempre a criação de um trigger que indica quando e onde se pretende despontar essa tag. Em tags mais complexas, pode ser necessário criar também algumas variáveis.
Quem deve estar envolvido: Equipas de Analytics e se necessário equipas de desenvolvimento.
Ambientes onde se implementa: WNovo website em ambientes de qualidade e de produção.
Entregáveis: Documento com indicação de todos os elementos/eventos que se pretendem implementar no website; a descrição desses eventos; a prioridade que esse evento tem em relação aos restantes; se existe a necessidade de implementação de um pixel; e se existe a necessidade de recurso a um developer.

2. Reimplementação dos eventos GTM em GA3 para GA4 e reinterpretação dos goals em UA GA para conversões em GA4

O que é: Os eventos desempenham um papel crucial no UA e no GA4. Mas a maneira como eles se denominam no UA é completamente diferente no GA4. Por esse motivo, não podemos simplesmente recriar os mesmos eventos na nova versão.

Os eventos no UA tinham uma estrutura hierárquica composta por category – action – label. No GA4, os eventos são diferenciados pelos nomes e podem ter vários parâmetros adstritos. É necessário fazer o mapeamento e traduzir a estrutura antiga para a nova estrutura de forma a garantir que os reports futuros sejam significativos.

Ainda dentro desta secção, podemos ter que reinterpretar os goals do GA3 para conversões no GA4. Uma grande mudança no GA4 é que todas as conversões são medidas por meio de eventos. No UA-GA, as conversões mais importantes provavelmente seriam baseadas em exibições de página. Isso significa que as metas que configurámos no UA-GA precisam ser reconfiguradas.

Mais uma vez, e em conjunto com os developers precisamos garantir que as conversões sejam rastreadas corretamente e seguir todas as alterações identificadas no plano de medição.

Para que serve: Ao fazermos estes passos, vamos garantir que não perdemos tudo ou a grande maioria da informação que recolhemos no UA-GA

Quais são os seus componentes: Devemos ter em atenção aos eventos, conversões, estruturas de e-commerce e audiências
Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
Entregáveis: Documento com o mapeamento do que eram os eventos no UA-GA, e qual o seu nome agora no GA4; com as conversões no UA-GA e quais serão as mesmas no atual GA4.

3. Definição dos Eventos Recomendados e dos Custom Events

O que é: No atual GA4 os tipos de eventos que existem são o seguintes:

Automatic Events – eventos coletados por defeito quando o GA4 é configurado no website. Por exemplo: file_download; first_visit; scroll…

Enhanced Events – eventos coletados quando o GA4 é configurada no website e os enhanced events são ativados. Por exemplo: pageviews; scrolls, site search; outbound links…

Depois temos uma grande segunda categoria de eventos que são os eventos que o Google Analytics 4 sugere que implementemos:

Eventos recomendados – eventos que implementamos, mas que possuem nomes e parâmetros predefinidos. Esses eventos desbloqueiam recursos de geração de relatórios existentes e futuros. Por exemplo: sign_up; login; purchase; refund…

Eventos personalizados – eventos que definimos e que são “personalizados” aquilo que é o negócio da Empresa. Por exemplo: adicionar_matrícula

Para que serve: Se não tivermos os eventos recomendados e customizados definidos e implementados, ficará mais difícil fazer análises mais granulares.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
Entregáveis: Documento com indicação da tipologia de eventos, o nome dos eventos, o local onde queremos implementar os eventos, os parâmetros adicionais a incorporar nos eventos, nomeadamente nos eventos customizados e notas/observações sobre a implementação.

4. Definição do Product Group Name

O que é: As conversões nada mais são que os eventos que são despontados no website e que a Empresa/Área de Negócio considera ser os mais importantes, ou dito de uma outra forma, são aqueles eventos que geram receita. Obviamente, que podem haver eventos considerados importantes e que não geram receita, por exemplo o envio de um formulário, mas por norma e considerando, por exemplo, a navegação de um utilizador num funil fechado, o evento mais importante será, por exemplo a compra que envolve receita.
Para que serve: Ao configurar as conversões, podemos:
- Ver as ações mais importantes para o negócio utilizando os relatórios de Aquisição, Engagement e Publicidade.
- Importar as conversões para o Google Ads para alimentar decisões manuais ou de lances inteligentes para ajudar a otimizar as campanhas.
- Combinar dados de negócio com dados de outros canais de publicidade para entender os pontos de contato ao longo da jornada do cliente até a conversão.
- Utilizar os dados de conversão para criar públicos que não converteram e importar esses públicos para o Google Ads para ações de remarketing.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
Entregáveis: No documento com indicação de todos os elementos/eventos que se pretendem implementar no website deve existir também uma coluna a identificar quais daqueles eventos devem ser considerados conversões.

5. Definição dos Customer Segments

O que é: Os customer segments são variáveis que devem ser implementadas na data layer do website se o mesmo servir ou contiver informação para diferentes públicos. Por exemplo, podemos ter websites para Crianças e para Adultos. Podemos ter websites para Consumidores finais e para Empresas. E Podemos até ter websites que tem conteúdo para todo o tipo de público, mas tem uma secção referente ao Grupo.
Para que serve: A implementação dos Customer Segments, via data layer preferencialmente, deve acontecer para quando temos um website possui diferentes grupos de conteúdo/informação, conteúdo esse que se destina a públicos diferentes. Ou seja, imaginando que temos um website de uma Empresa de produção de pasta de papel, onde existe uma secção relativa ao Grupo, outra grande secção relativa a Empresas e uma outra para Investidores e uma outra para Media. Podemos implementar 3 Customer Segments: Grupo, Media e Investidores e assim conseguiremos “segmentar” por estas variáveis no GA4 e fazer análises mais granulares.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
Entregáveis: Documento com indicação de todos os customer segments que pretendemos implementar no website e se fizer sentido, em que páginas os mesmos devem ser implementados.

6. Definição dos Host Owners

O que é: O Host Owner é a identificação do domínio do website ou de cada parte/aplicativo de um website. s conversões nada mais são que os eventos que são despontados no website e que a Empresa/Área de Negócio considera ser os mais importantes, ou dito de uma outra forma, são aqueles eventos que geram receita. Obviamente, que podem haver eventos considerados importantes e que não geram receita, por exemplo o envio de um formulário, mas por norma e considerando, por exemplo, a navegação de um utilizador num funil fechado, o evento mais importante será, por exemplo a compra que envolve receita.
Para que serve: A implementação de um host owner, via data layer preferencialmente, deve acontecer para quando temos um website que não é composto apenas e só por aplicativos da Empresa que é dona do website. Ou seja, imaginando que temos um website de e-commerce de roupa de homem feita por medida e nele existe uma secção/aplicativo que é de um fornecedor de camisas de homem que permite que os mesmos definiam as medidas exatas do comprimento das mangas da camisa, do comprimento da camisa, do raio do colarinho,…..Para se conseguir fazer análises por exemplo sobre a utilização desse aplicativo, se tivermos o host owner implementado, conseguiremos “segmentar” por essa variável no GA4.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
Entregáveis: Documento com indicação de todas as secções/aplicativos do website que são geridos por parceiros.

7. Definição dos PageTypes / Content Grouping

O que é: As PageTypes ou Content Grouping são grupos de páginas que possuem o mesmo tipo de template e que por isso podem ser classificadas, em termos de conteúdo, como sendo idênticas e únicas entre si. Por exemplo, se estivermos a falar de um website de e-commerce, haverá um template de página específico para aquilo que são as páginas de categoria de produtos, outro template para as páginas de produto e ainda outro template para as páginas relativas ao carrinho de compras.
Para que serve: O Content Grouping permite-nos visualizar e comparar métricas agregadas por tipo de conteúdo, além de poder detalhar o URL individual, título da página ou screen name. Por exemplo, podemos ver o número agregado de visualizações de página para todas as páginas classificadas como Mulheres/Calças e, em seguida, detalhar para ver cada URL ou título de página. Analytics avalia as regras em ordem.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
Entregáveis: Documento discriminativo de todos os page types / content groupings criados.

8. Definição das Virtual Pages Views – Eventos

O que é: As conversões nada mais são que os eventos que são despontados no website e que a Empresa/Área de Negócio considera ser os mais importantes, ou dito de uma outra forma, são aqueles eventos que geram receita. Obviamente, que podem haver eventos considerados importantes e que não geram receita, por exemplo o envio de um formulário, mas por norma e considerando, por exemplo, a navegação de um utilizador num funil fechado, o evento mais importante será, por exemplo a compra que envolve receita.
Para que serve: As virtual page views servem para ultrapassar o “problema” que algumas páginas, e até mesmo websites inteiros, têm que é o facto de apresentarem o mesmo URL, independentemente do utilizador ir avançando no website/aplicativo. São chamados o Single Page Applications e por norma envolvem o desenvolvimento em Ajax ou linguagens de programação semelhantes. Por exemplo e mais uma vez imaginando um website de e-commerce que desde a entrada no checkout (begin_checkout) até à compra (purchase), o URL do website não muda, mas o screen altera. Com a implementação das virtual page views vamos conseguir perceber as diferentes páginas pelas quais o utilizador navegou e com isso implementar um funil no Explorer do GA4 e fazer as análises necessárias.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
Entregáveis: Documento com o mapeamento de todos os fluxos do utilizador pelos aplicativos/website que têm o mesmo URL, indicação desse mesmo URL e indicação da proposta de nome para o “novo” URL que servirá de virtual page view.

9. Definição da Estrutura Mercadológica de Produtos (se não existir)

O que é: A estrutura mercadológica é a identificação e/ou agrupamento dos diferentes tipos de produtos pela sua família. De certa forma, as estruturas mercadológicas de produtos estão relacionadas com aquilo que é a arquitetura de informação de um website. Por exemplo e imaginando um website de uma insígnia de hipermercados. Se estivermos a pensar num queijo flamengo Terra Nostra, o mesmo pode ser classificado na seguinte estrutura mercadológica:
- Lacticínios (1)
  - Queijos (2)
    - Queijos Sólidos/Pasta (3)
      - Queijos Portugueses (4)
        
        Queijos Flamengos (5)
Para que serve: A principal vantagem de ter uma estrutura mercadológica de produto implementada na data layer de um website é o poder fazer análises mais granulares ao nível do produto, utilizando para isso, por exemplos, o Explorer do GA4.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
Entregáveis: Documento com o mapeamento para cada um dos produtos do website de toda a sua estrutura mercadológica até 5 grupos.

10. Definição das Conversões

O que é: As conversões nada mais são que os eventos que são despontados no website e que a Empresa/Área de Negócio considera ser os mais importantes, ou dito de uma outra forma, são aqueles eventos que geram receita. Obviamente, que podem haver eventos considerados importantes e que não geram receita, por exemplo o envio de um formulário, mas por norma e considerando, por exemplo, a navegação de um utilizador num funil fechado, o evento mais importante será, por exemplo a compra que envolve receita.
Para que serve: Ao configurar as conversões, podemos:
- Ver as ações mais importantes para o negócio utilizando os relatórios de Aquisição, Engagement e Publicidade.
- Importar as conversões para o Google Ads para alimentar decisões manuais ou de lances inteligentes para ajudar a otimizar as campanhas.
- Combinar dados de negócio com dados de outros canais de publicidade para entender os pontos de contato ao longo da jornada do cliente até a conversão.
- Utilizar os dados de conversão para criar públicos que não converteram e importar esses públicos para o Google Ads para ações de remarketing.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de Analytics e se necessário equipas de desenvolvimento.
Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
Entregáveis: No documento com indicação de todos os elementos/eventos que se pretendem implementar no website deve existir também uma coluna a identificar quais daqueles eventos devem ser considerados conversões.

11. Definição e Implementação do Measurement Protocol

O que é: O measurement protocol é um protocolo que nos vai permitir aferir com maior rigor se as transações que foram feitas, por exemplo, offline efetivamente se efectivaram.
Para que serve: Por exemplo, pode-se dar o caso do utilizador ter pago algo com o cartão de crédito, mas mais tarde fez a devolução do produto. Com a implementação do measurement protocol conseguiremos medir esses comportamento de alguma forma.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
Entregáveis: Documento com indicação de todos os eventos que exigem implementação do measurement protocol e qual as situações/regras para o mesmo ser despoletado.

Conclusão

Lançar um website não é algo fácil e que se faça de um dia para o outro. Exige imensos cuidados, imenso trabalho e envolvimento de diversas equipas em vários momentos distintos. Para que tudo corra bem é preciso ter em consideração, mas não só, todas estas questões que mencionei nesta “coletânea” de 3 artigos

Espero que os artigos tenham sido úteis e venham a ser consultados sempre que tenham que fazer o lançamento ou relançamento de um website.

Want to read this article in English? Please click here

by João Carlos Matos

Checklist de Atividades de SEO e de UI para (Re)Lançamento de um Website - 13 Atividades a Considerar

Checklist de Atividades de SEO para (Re)Lançamento de um Website - 13 Atividades a Considerar - PARTE 2

Introdução

Este é a PARTE 2 de um conjunto de artigos que resolvi escrever sobre atividades de UX/UI, SEO e de Analytics que devemos ter em consideração antes de lançar ou relançar um website. Podem consultar a PARTE 1 – Checklist de Atividades de UX/UI para (Re)Lançamento de um Website – 12 Atividades a Considerar.

Neste artigo as atividades descritas dizem respeito ao novo website. Mas devemos ter em conta que há um trabalho prévio a fazer ainda no website antigo, se estivermos a falar de um redesign. Por exemplo, fazer um crawl a todo o website para se perceber se existem questões a resolver por exemplo com redirecionamentos de páginas; verificar a tag da ferramenta de Analytics e verificar problemas no Google Search Console – GSC.

Depois existem atividades a fazer no novo site, mas no seu ambiente de desenvolvimento que serão uma salvaguarda que devemos ter antes do novo website ser lançado. Mas vamos então ver em mais detalhe cada uma dessas atividades.

1.Crawl do Website

O que é: Rastrear todos os URLs de um website, através de uma ferramenta específica para o efeito, como a Screaming Frog ou a SEMRush.
Para que serve: O rastreamento do website serve para percebermos se existem problemas nalguma página e, é a atividade base ao mapeamento dos URLs para conseguirmos fazer os seus redirecionamentos.
Quais são os seus componentes: Como componentes principais a analisar num crawl a um website temos: as Metadatas, os broken links, os links to follow e os atributos HTML ALT tag imagens
Quem deve estar envolvido: Equipas de SEO e se necessário equipas de desenvolvimento.
Ambientes onde se implementa: Website antigo, staging do website novo e após o website ser lançado convêm fazer novo crawl para despistar quaisquer problemas.
Entregáveis: Documento com os principais findings de problemas de SEO Técnico encontrados e respetivas recomendações. E também deve ser produzido um Excel com os URLs do website antigo para se poderem mapear os novos URLs.

2. Instalação da Ferramenta de Analytics

O que é: Em regra, é um snippet code em JS que se instala no código fonte, logo depois do <header>.
Para que serve: OA ferramenta de analytics irá servir para medir aquilo que os utilizadores fazem no website, via dispositivos fixos ou mobile.
Quais são os seus componentes: nd. No entanto, é preciso relembrar que se estivermos a configurar esta tag no website em produção, já com o site lançado, é boa prática:
- Conectar o website ao Google Search Console
- Conectar o Google Signals no GA4
Quem deve estar envolvido: Equipas de SEO e se necessário equipas de desenvolvimento.
Ambientes onde se implementa: Website antigo e staging do website novo.
Entregáveis: Sendo uma atividade de configuração de uma ferramenta, pode haver um entregável da equipa de SEO para as equipas técnicas que será o seu Guia de Implementação. Por exemplo Guia de Implementação do Google Tag Manager no website e respetiva tag do GA4.

3. Mapeamento dos URLs e Redirecionamentos das Páginas

O que é: Os redirecionamentos das páginas significam que vamos ter que apontar os novos endereços URL do website antigo para os correspondentes no website novo ou redesenhado, se os houver.
Para que serve: Os Se não houver um mapeamento dos URLs do website antigo e do website novo, corremos o risco de termos páginas com erro 404 no novo website o que, para além de provocar uma péssima experiência para o utilizador, provocará graves problemas de indexação e ranking dessa ou dessas páginas..
Quais são os seus componentes: Não existem componentes, mas devo fazer a ressalva de não esquecer de fazer o redirecionamento da página com “www.” Para a página sem o “www”, bem como o redirecionamento do scheme protocolo “http://“ que o servidor deve ler, para as páginas com o scheme protocolo de segurança “https://“ que o servidor deve ler.
Quem deve estar envolvido: Equipas de SEO e se necessário developers front-end ou hack-end.
Ambientes onde se implementa: Os mapeamentos devem ser feitos no website antigo e os redirecionamentos devem ser implementados no ambiente de Staging do website novo e confirmados no ambiente de produção após lançamento do website.
Entregáveis: Mapa em Excel com os URLs do website antigo e respetiva correspondência no website novo, bem como a expressão regular (ou não) para que essa implementação possa ser feita ao nível do servidor

4. Testar a Velocidade do Website e a sua Responsividade

O que é: Os testes de velocidade são testes feitos à velocidade de carregamento dos conteúdos das páginas do website. Os testes de responsividade são testes de adaptação desses mesmos conteúdos a cada dispositivo em que esse mesmo website pode ser carregado, visto pelo utilizador. Por norma e maioritariamente fazem-se testes de responsividade para desktop, mobile e tablet..
Para que serve: Os testes de velocidade ao website devem ser feitos por forma a minimizar impactos na experiência do utilizador e no ranking (Core Web Vitals) do website novo.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de SEO com auxílio das equipas de desenvolvimento no caso de querermos interpretar os valores dos testes e perceber como corrigir os problemas.
Ambientes onde se implementa: Primeiros testes em ambiente de staging e confirmação no ambiente de produção após lançamento do website.
Entregáveis: Documento com os principais findings de problemas de velocidade e de responsividade – SEO Técnico encontrados e respetivas recomendações.

5. Desenho e Implementação da Página de Erro 404 e 500

O que é: As páginas de erro 404 e 500 são páginas informativas que o website apresenta quando algo se passa ao nível do carregamento das páginas ou ao nível do servidor e que não permite aos utilizadores visualizarem ou acederem ao website.
Para que serve: Se pensarmos bem, as páginas de erro de um website, sejam elas erros 404 ou erro 500 não deveriam existir. Não faz sentido haverem erros e os mesmos serem apresentados ao utilizador. Mas havendo erros, por algum motivo que até podemos não controlar ao início, devemos apresentar aos utilizadores uma página de erro com informação esclarecedora sobre o erro, o porquê do erro estar a acontecer e sugestões de páginas no website que podem visitar enquanto o erro não se resolve. E, por último, acrescentaria os contactos da Empresa.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de UX/UI, equipas de desenvolvimento e auxílio/acompanhamento das equipas de SEO.
Ambientes onde se implementa: Deve-se começar a desenhar esta página para o ambiente staging do website e confirmar no ambiente de produção após lançamento do website se a mesma ficou implementada, criando e testando um erro, por exemplo no servidor.
Entregáveis: O Protótipo e versão final das páginas de erro 404 e 500.

6. Implementação da tag HTML Href Lang*

O que é: A tag Href Lang é uma tag HTML que se coloca no código fonte do website dentro das tags <head></head>.
Para que serve: A tag Href Lang informa o Google que diferentes idiomas ou versões de países da mesma página estão relacionados, para que ele possa fornecer o conteúdo certo aos utilizadores.
Quais são os seus componentes: Não existem. Mas uma tag Href Lang tem esta configuração: <link rel=”alternate” hreflang=”es” href=”http://es.xpto.pt/” />
Quem deve estar envolvido: Equipas de desenvolvimento com acompanhamento das equipas de SEO.
Ambientes onde se implementa: Esta tag deve ser implementada no ambiente de staging do website novo e confirmada no ambiente de produção após lançamento do website.
Entregáveis: nd.

7. Configuração e Implementação do Open Graph*

O que é: O Open Graph é um protocolo de internet que foi originalmente criado pelo Facebook para padronizar a utilização de metadados numa página de um qualquer website para representar o seu conteúdo.
Para que serve: Como visto acima, o Open Graph permite padronizar a utilização de metadados numa página de um qualquer website para representar o seu conteúdo.
Quais são os seus componentes: Podemos ter o Open Graph que irá ser lido pelo Google e para diferentes redes sociais, como o Facebook, Twitter, Linkedin, por exemplo. Eis na prática uma tag sobre o Open Graph para um website: <!– xpto.com !–> <meta property=“og:type” content=“profile”/>
Quem deve estar envolvido: Equipas de desenvolvimento com acompanhamento das equipas de SEO.
Ambientes onde se implementa: Esta tag deve ser implementada no ambiente de staging do website novo e confirmada no ambiente de produção após lançamento do website.
Entregáveis: nd.

8. Fazer Testes de Cross Browser

O que é: Os testes de cross browser são testes feitos ao website em ferramentas que simulam o ambiente de renderização específico de cada browser (Chrome, Sfari, IE…).
Para que serve: Os browsers interpretam e renderizam o html dos websites de formas diferentes e isso faz com que o layout das páginas e o seu conteúdo possa ser bem renderizado e, consequentemente, bem visto pelo utilizador que utiliza o Chrome, mas tal pode já não acontecer num Opera. Então, estes testes servem para verificar discrepâncias na renderização das páginas e dos seus conteúdos por parte dos diferentes browsers.
Quais são os seus componentes: nd.
Quem deve estar envolvido: Equipas de SEO com acompanhamento (para implementação de correções) das equipas de desenvolvimento.
Ambientes onde se implementa: Os testes de Cross browser devem ser feitos no ambiente staging do website e, posteriormente e após o lançamento do website, confirmar em produção que não existem erros/desformatações do website nalgum browser, por exemplo numa qualquer versão do IE ou do Edge.
Entregáveis: Documento com os principais findings de problemas de cross-browser – SEO Técnico – encontrados e respetivas recomendações.

9. Especificações de Headings das Páginas para SEO

O que é: São os principais componentes do conteúdo das diferentes páginas do website, no que ao copy diz respeito. Para cada uma dessas páginas do website funcionam como os títulos principais e secundários (headings) de um índice de um documento.
Para que serve: À semelhança daquilo que acontece com a Arquitetura de Informação, a definição dos Headings de páginas para SEO serve para os utilizadores e os motores de pesquisa entenderem a arquitetura/hierarquia de informação das diferentes páginas, através deste processo específico de organização e rotularem de elementos – títulos, sub-títulos e parágrafos de texto. Também serve, em termos de acessibilidade, para os utilizadores poderem ler, com os screen readers, e perceber como está construída a página.
Quem deve estar envolvido: Equipas de UX e equipas de SEO
Quais são os seus componentes: Considero que os componentes dos Headings para SEO podem ir desde o atributo HTML <H1> até ao <H6> e para textos poderemos estar a falar de atributos HTML <p>. Mas por norma, uma página de um website, em princípio, não terá mais do que 2 ou 3 atributos destes, ou seja terá um atributo H1 e depois tudo atributos H2 ou uma mescla entre atributos H2 e atributos H3.
Ambientes onde se implementa: Os headings devem ser definidos logo na fase de design das páginas do website. E devem ser feitos no ambiente staging do website e, posteriormente e após o lançamento do website, confirmar em produção que não existem erros.

Entregáveis: O entregável desta atividade pode ser o protótipo onde em cada titulo de página e/ou subtítulo devem estar especificados que tipo de Headings devem ser considerados no desenvolvimento dessa página pelos front-end developers. Pode também ser construído de raíz um documento de especificações, em que deverá ter uma secção que contemple as especificações de headings de SEO para os diferentes títulos, sub-títulos e textos das diferentes páginas do novo website Documento composto pelas diferentes páginas do novo website.

10. Implementação do Favicon

O que é: É a imagem ícone que se encontra no separador de cada um dos browsers e antes do Page Title, na história de websites pesquisados e que o browser guarda ou nos bookmarks. É uma imagem de 16×16 pixels.
Para que serve: O objetivo do favicon, para mim, é o de auxiliar o utilizador a “descobrir” o nosso website no meio de várias tabs abertas no browser.
Quais são os seus componentes: nd
Quem deve estar envolvido: Equipas de UX, de UI e de desenvolvimento e/ou SEO para implementação
Ambientes onde se implementa: Deve ser implementado no ambiente staging do website e, posteriormente e após o lançamento do website, confirmar em produção que está OK, sem alterações.
Entregáveis: Ficheiro png do Favicon

11. Verificação e Implementação de Políticas de Privacidade e Consentimentos

O que é: As Políticas de Cookies, tal como as Políticas de Privacidade são guidelines de como a Empresa irá armazenar (e utilizar) a informação e outros dados dos seus utilizadores e devem estar em concordância, se estivermos a falar de um website europeu, com o Regulamento Geral de Proteção de Dados – RGPD. Relativamente aos Consentimentos, são opções dadas aos utilizadores para eles aceitarem ou não; concordarem ou não com as Políticas e/ou com a configuração por default dos cookies gerados no website

Para que serve: Existem 2 grandes objetivos na redação destas Políticas: 1 – Proteger os utilizadores; 2 – Cumprir com os regulamentos legais em vigor nos diferentes países em que o website tem utilizadores. Sobre os consentimentos, por norma servem para salvaguardar qualquer tipo de tratamento de dados que a empresa faça, por exemplo, quando um utilizador preenche e submete um formulário.

Quais são os seus componentes: nd. No entanto é importante perceber que existem 5 tipos de cookies:
- First-parte cookies – São cookies “gerados” pelo próprio website quando o utilizador o visita
- Third-party cookies – São cookies “gerados” por terceiros. Ou seja, são “gerados” por domínios que não são visitados diretamente pelos utilizadores
- Cookies de Sessão – São cookies que expiram imediatamente ou alguns segundos depois dos utilizadores saírem do browser.
- Cookies Persistentes – São cookies que ao contrário dos cookies anteriores permanece no browser durante um determinado período de tempo
- Cookies de Segurança – São cookies “gerados” apenas por websites que utilizam o protocolo de segurança https://

Todos estes cookies devem ser mencionados na Política de Cookies e que devem, também, ser bloqueados de alguma forma, caso os utilizadores não aceitem os mesmos no pop-up de consentimento que deve estar disponível logo que um utilizador abra um website.

Quem deve estar envolvido: Equipas DPO, Conteúdos e de SEO
Ambientes onde se implementa: As Políticas e Consentimento devem ser implementadas no ambiente staging do website e, posteriormente e após o lançamento do website, testadas em produção, nomeadamente no pop-up de consentimento e no envio de formulários, para que não existam erros.
Entregáveis: Documentos escritos e preparados para colocar nas respetivas páginas do website sobre Política de Privacidade e Política de Cookies.

12. Criação do Sitemap

O que é: O sitemap é um ficheiro xml ou xmls que contêm toda a estrutura de URLs, sejam de categorias de páginas, páginas, ficheiros e afins de todo o website.
Para que serve: ÀA grande vantagem de um website ter um sitemap é para os motores de pesquisa terem mais facilidade em ler, indexar e encontrar as diferentes páginas desse mesmo website. Por norma, é muito mais importante que um website com muitas páginas tenha um sitemap, do que um que tenha 10, 20 ou 30 páginas.
Quem deve estar envolvido: Equipas SEO e de desenvolvimento
Quais são os seus componentes: nd.
Ambientes onde se implementa: Ambiente de produção e upload no Google Search Console para uma indexação mais rápida.
Entregáveis: Sitemap

13 . Criação do ficheiro Robots.txt

O que é: O robots.txt é um arquivo de texto com instruções para os robot dos motores de pesquisa sobre quais páginas eles podem e não podem rastrear.
Para que serve: Este ficheiro serve para “facilitar” a vida aos motores de pesquisa e para pouparmos “crawl budget”.
Quem deve estar envolvido: Equipas de SEO em conjunto com as equipas de desenvolvimento.
Quais são os seus componentes: As instruções são especificadas por “allow” (permitir) ou “disallow” (não permitir) o comportamento de determinas (ou todos) bots.
Ambientes onde se implementa: Ambiente de produção.
Entregáveis: Ficheiro Robots.txt e colocá-lo na raíz do website

Conclusão

Tal como visto na PARTE 1 deste conjunto de artigos, lançar um website ou relançar um website dá muito trabalho. Implica muito tempo e muitas atividades. E no que respeita a atividades de SEO ou relacionadas, acredito que a lista acima é um excelente ponto de partida. Contudo, queria deixar mais umas pistas:

Podemos sempre e testar e implementar 1 – o Schema Markup, de forma a tornar mais robusto o website no que respeita à “searchability” e indexação pelos motores de pesquisa e prepará-lo de alguma forma para as pesquisas por voz; 2 – Fazer o teste de indexação do website diretamente nos motores de pesquisa.

A próxima parte do artigo que será vista em 2023, será sobre as atividades a considerar no (re)lançamento de um website. Fiquem atentos!

Want to read this article in English? Please click here

by João Carlos Matos

Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar - PARTE 1

Introdução

Como todos os lançamentos ou relançamentos de um website é preciso, além de objetivos bem claros e definidos, é preciso ter em atenção as atividades que são necessárias desenvolver e planeá-las. As atividades para o lançamento ou relançamento de um website atravessam várias áreas do digital: desde atividades de UX, passando pelas atividades de UI e de Conteúdos, e atividades de SEO ou de Analytics.

Obviamente que à partida estou a considerar que os Objetivos do Website (lançamento ou relançamento) já foram ou estão definidos com recorrência e suporte das atividades de UX Research, nomeadamente no Estudo de Personas; Estudo da Experiência (pain points e love moments) e no Benchmarking e das Best Practices de UX/UI.

Neste artigo que será o primeiro de quatro irei elencar que atividades de UX e de UI é preciso ter em consideração no lançamento ou relançamento de um website.

1 – (Re) Definição da Arquitetura de Informação

O que é: Se procurarmos o significado etimológico da palavra “Arquitetura” vemos que significa “primeiro construtor”. E em UX/UI também não é diferente o seu significado. A Arquitetura de Informação como atividade de UX/UI para (re)desenho de um website significa criar as bases e os alicerces do sistema de informação do website e a forma como as mesmas são apresentadas e como se interligam e comportam em resposta a ações do utilizador.
Para que serve: A Arquitetura de Informação de um website defini-se como sendo páginas do website A arquitetura da informação é uma atividade que pode e deve ter também o deliverable respetivo. Além disso, é uma atividade que deve ser pensada em conjunto com as área de SEO e de Conteúdos, porque no primeiro caso vai ser preciso criar o sitemap dessa arquitetura para colocar ou a) na raíz do código fonte do website; 2) compará-la com o sitemap criado automaticamente via plugin do CMS do website. No que respeita à área dos Conteúdos, simultaneamente com a área de SEO, terão a responsabilidade de analisar e verificar se as keywords utilizadas no sitemap estão em consonância com aquilo que os utilizadores pesquisam.
Quais são os seus componentes: Sendo a Arquitetura de Informação um sistema, é elementar que seja composto por vários processos e são eles: os processos de organização, os processos de rotulagem; os processos de navegação e os processos de pesquisa. Estes 4 processos devem ser trabalhados em simultâneo.
Quem deve estar envolvido: Equipas de UX, de Conteúdos, e de SEO
Entregáveis: O principal entregável da Arquitetura de Informação para o (re)desenho de um website é o sitemap que não é nada mais nada menos do que um mapa com a hierarquia das diferentes páginas do website bem como denominação dos tipos de conteúdos das mesmas, nomeadamente ao nível dos títulos.

2 – Criação dos User Flows

O que é: Os user flows são uma forma de representar, graficamente, o caminho ou os caminhos que os diferentes utilizadores (personas) irão “percorrer” ao navegar no novo ou redesenhado website. E existem 3 tipos de user flows, sendo que todos eles representam atividades, mas uns podem ser mais rudimentares do que outros no sentido em que podemos estar apenas a falar de um simples fluxograma (task flow) ou de um fluxograma relacionado com wireframes já feitos (wire flow) ou exatamente a mesma coisa, mas para cada uma das personas (user flow).
Para que serve: Eu, pessoalmente, considero haver 2 motivos para ter que se desenhar user flows: 1 – perceber se a Arquitetura de Informação está bem pensada ou deve ser revista; 2 – Garantir que o novo ou redesenhado website têm endereçadas todas as atividades que nos propusemos e que queremos que o utilizador, porque é uma necessidade dele.
Quais são os seus componentes: Se estivermos a falar de task flows os componentes são os de um fluxograma típico e ilustrativo de uma atividade. Se estivermos a falar de wire flows, os componentes são os diferentes ecrans dos wireframes ligados entre si. As componentes dos user flows são idênticas às do wire flows, mas são inerentes a cada uma das personas estudadas previamente, uma vez que podem haver diferentes use cases de navegação.
Quem deve estar envolvido: Equipas de UX e de SEO, se necessário
Entregáveis: O principal entregável são os diferentes user flows de todas ou das principais ações que os utilizadores podem fazer no website.

3 – (Re)Desenho dos Wireframes

O que é: Os wireframes são os “esqueletos” daquilo que será o novo website, seja novo no sentido estrito da palavra, seja renovado. oOs wireframes dão uma visão geral da estrutura de cada uma das páginas do website – arquitetura de informação – do layout, dos diferentes user flows e funcionalidades que despontarão os comportamentos dos utilizadores.
Para que serve: Os wireframes servem para, essencialmente, para dois objetivos:
- Apresentar a estrutura, conteúdo e layout do website (imagens e copy e alguma interatividade) desenvolvido com base naquilo que são as necessidades dos utilizadores.
- Reduzirmos os custos de design – UI – e desenvolvimento – DEV – no desenho ou redesenho de um website e, portanto, utiliza-se, na verão mais “pobre” lápis, papel e borracha para se desenhar os tais esqueletos do website – wireframes.
Quais são os seus componentes: Não existem componentes dos wireframes de um website. Mas, posso alertar que não é preciso ser um designer para produzir wireframes. É preciso saber desenhar “círculos”, “quadrados”, “triângulos”, “semi-retas”, saber escrever e pouco mais.
Quem deve estar envolvido: Equipas de UX e de SEO e de UI, se necessário.
Entregáveis: O próprio wireframe em papel ou em ficheiro de softwares como o Axure, Balsamiq, Figma e similares.

4 – (Re)Desenho dos Protótipos

O que é: Os protótipos nada mais são do que “wireframes on steróids”. Ou seja, são wireframes que já foram mais trabalhados no sentido de já ter alguma componente gráfica e de cores, de já ter mais animações e ser muito mais interativo.
Para que serve: AO grande e principal objeto do desenho dos protótipos é o de serem testados com os utilizadores finais, já que os protótipos por regra, e depois de toda a fase de estudo das necessidades dos utilizadores, devem ser muito idênticos em termos de arquitetura de Informação, user flows e interatividade, ao produto final – UI.
Quais são os seus componentes: Não existem grandes componentes num protótipo já que é quase o produto final. Podemos é ter protótipos do website, de uma app.
Quem deve estar envolvido: Equipas de UX, e se necessário de UI
Entregáveis: O principal entregável é o protótipo em si, feito em Figma ou em Sketch, por exemplo.

5 – Definição do UI – User Interface

O que é: O user interface nada mais é que o “desenho” puro e duro daquilo que foram os wireframes e os protótipos. É dar vida, ou melhor dizendo, dar fogo à peça.
Para que serve: Nesta Checklist de 12 atividades de UX/UI que devemos ter em conta ao (re)desenhar um website, o desenho do user interface – UI – é a fase final do processo, antes do mesmo ser passado para os developers. É como se fosse o “pintar” as paredes exteriores da casa.
Quais são os seus componentes: Se estivermos a falar de implementação de um Design System, existem muitos componentes associados. Por exemplo, existem os Princípios de Design, os Logos, a iconografia, a tipografia, o layout com grelhas e breakpoints, ilustrações, animações, e os diferentes componentes gráficos per si – botões, tabelas, gráficos, overlays, listas….mais recursos de e para consulta. Se não for esse o caso, provavelmente os componentes resumem-se a paleta de cores e tipografia e logos e pouco mais.
Quem deve estar envolvido: Equipas de UI e potencialmente, dependendo do trabalho e do entregável, equipas de UX Writing.
Entregáveis: Se estivermos a falar de equipas de UX/UI e restantes áreas digitais numa Empresa com maturidade e cultura digital avançada, o entregarem pode e deverá ser um Design System ou um update ao Design System. Se, pelo contrário, a empresa não tem essa maturidade, os entregáveis podem passar por um Guia de Estilos onde podem estar descriminados as cores principais e secundárias a serem utilizadas, família tipográfica, tom de voz, logotipos e suas dimensões e pouco mais.

6 – Update e/ou Criação do Design System

O que é: Um Design System é um conjunto de regras padronizadas que permitem às empresas escalarem os temas de design, reduzindo o esforço das equipas, os custos e a redundância, uma vez que todos trabalham seguindo uma metodologia que permite ter uma linguagem visual comum e consistência entre ativos digitais e canais.
Para que serve: Como visto acima, o Design System serve para as equipas operem segundo uma linguagem visual comum e construam ativos digitais consistentes para os diferentes canais em que a Empresa tem presença. Obviamente que isto irá permitir às empresas reduzirem o time to market ou o time to launch dos seus produtos digitais.
Quais são os seus componentes: Os componentes de um Design System variam de empresa para empresa, mas de uma maneira geral poderemos ter: a secção dos Fundamentos do Design System, onde estarão incluídos, entre outros, os Objetivos e os Princípios de Design; a secção de Componentes, que será o core do Design System, com todos os elementos/componentes gráficos necessários para o desenho e escalamento dos ativos digitais; Fontes de Estudo/Pesquisa.
Quem deve estar envolvido: Equipas de UX, UI e outras se necessárias
Entregáveis: Repositório ZeroHeight, por exemplo com todos os elementos que compõem um Design System e Biblioteca Figma, por exemplo com todos os componentes gráficos que servem de base ao Design System.

7 – Definição das Questões de Acessibilidade

O que é: A acessibilidade é desenhar e desenvolver os ativos digitais tendo sempre em mente a inclusão de todo o tipo de utilizadores, nomeadamente utilizadores com problemas de visão, cognitivos, de surdez, físicos, verbais, neuropsicológicos, mas não só. Por exemplo utilizadores sem este tipo de problemas, se tiverem de ver um website no smartphone que não está adaptado para o efeito é também uma questão de usabilidade.
Para que serve: O objetivo do design para todo o tipo de utilizadores é o da inclusão. Não será à toa que todos o a grande maioria dos websites públicos portugueses estão desenhados com estas regras. Por exemplo, o website da Presidência da República Portuguesa.
Quais são os seus componentes: nd
Quem deve estar envolvido: Equipas de UX, de UI e, se necessário, de Conteúdos e de SEO
Entregáveis: O As especificações de acessibilidade podem vir descriminadas no Documento final de especificações para os developers.

8 – Especificações dos Direcionamentos das Páginas

O que é: Os direcionamentos das páginas significam qual a navegação que o utilizador vai ter ou vai fazer ao visitar o website.
Para que serve: AOs direcionamentos servem para os utilizadores navegarem ao longo do website.
Quais são os seus componentes: Os utilizadores podem navegar no website seguindo 3 vias: Navegação Global – feita através do menu principal e até mesmo secundário do website; Navegação Hierárquica – feita através dos menus específicos de cada página; e Navegação Local/Circular – ; e Navegação Circular – Feita via os diferentes botões (CTA – Call-To-Action) ou hiperligações presentes nas diferentes páginas do website.
Quem deve estar envolvido: Equipas de UX e, se necessário de SEO
Entregáveis: Os direcionamentos das páginas podem estar especificados no entregável para o efeito com outras especificações, por exemplo de interatividade e de SEO ou pode-se produzir um Excel com o mapeamento dos URLs das diferentes páginas do website e indicação para onde devem encaminhar o utilizador.

9 – Especificações de Headings das Páginas para SEO

O que é: São os principais componentes do conteúdo das diferentes páginas do website, no que ao copy diz respeito. Para cada uma dessas páginas do website funcionam como os títulos principais e secundários (headings) de um índice de um documento.
Para que serve: À semelhança daquilo que acontece com a Arquitetura de Informação, a definição dos Headings de páginas para SEO serve para os utilizadores e os motores de pesquisa entenderem a arquitetura/hierarquia de informação das diferentes páginas, através deste processo específico de organização e rotularem de elementos – títulos, sub-títulos e parágrafos de texto. Também serve, em termos de acessibilidade, para os utilizadores poderem ler, com os screen readers, e perceber como está construída a página.
Quem deve estar envolvido: Equipas de UX e equipas de SEO
Quais são os seus componentes: Considero que os componentes dos Headings para SEO podem ir desde o atributo HTML <H1> até ao <H6> e para textos poderemos estar a falar de atributos HTML <p>. Mas por norma, uma página de um website, em princípio, não terá mais do que 2 ou 3 atributos destes, ou seja terá um atributo H1 e depois tudo atributos H2 ou uma mescla entre atributos H2 e atributos H3.
Entregáveis: O entregável desta atividade pode ser o protótipo onde em cada titulo de página e/ou subtítulo devem estar especificados que tipo de Headings devem ser considerados no desenvolvimento dessa página pelos front-end developers.

Pode também ser construído de raíz um documento de especificações, em que deverá ter uma secção que contemple as especificações de headings de SEO para os diferentes títulos, sub-títulos e textos das diferentes páginas do novo website Documento composto pelas diferentes páginas do novo website.

10 – Definição dos break points para outros Dispositivos – Responsive Design

O que é: São testes de usabilidade feitos ao protótipo e junto dos utilizadores finais.
Para que serve: Os break points servem para o website se poder adaptar em termos de conteúdo aos diferentes ecrans dos diferentes dispositivos, sejam eles computadores, telemóveis, tablets, televisores, smartwatches, quiosques.
Quem deve estar envolvido: Equipas de UX, UI e Developers
Quais são os seus componentes: N/D.
Entregáveis: Documento das especificações com os diferentes breakpoints para cada um dos dispositivos.

11 – Especificações dos Elementos das Páginas e Outros para Desenvolvimento

O que é: Uma vez terminado todo o trabalho de UX/UI em termos daquilo que é a estratégia e o design do mesmo, é preciso especificar uma série de elementos para as equipas que vão desenvolver e implementar o website novo ou redesenhado.
Para que serve: As especificações servem para os developers entenderem aquilo que tem de fazer para dar vida ao website. É como se fosse um briefing das equipas de UX/UI, SEO, Analytics e Conteúdos para as equipas de desenvolvimento.
Quais são os seus componentes: Existem diferentes tipos de especificações, por exemplo: Especificações sobre as páginas: dimensões de grelhas, e dos breakpoints; Especificações UI: especificações hexa dos diferentes elementos das páginas como do textos, dos CTA, dos backgrounds, dos foregrounds, dos hiperlinks, entre outros; Especificações de interatividade: movimento e animações dos menus, animações e movimentos dos CTAs, animação das mudanças de páginas, entre outras animações de elementos; Especificações de SEO: headings, nomenclaturas dos URLs, direcionamentos, meta descrições… Especificações de Acessibilidade: contrastes entre cores, os próprios headings, responsável design, nomeação de imagens.…
Quem deve estar envolvido: Equipas de UX, de Conteúdos, e de SEO
Entregáveis: O principal entregável pode ser o protótipo HF com as diferentes especificações ou um documento word/powerpoint com as especificações.

12 – Desenvolvimento dos Testes de Usabilidade

O que é: São testes de usabilidade feitos ao protótipo e junto dos utilizadores finais.
Para que serve: Simples: Testar se o que foi criado é perceptível pelos utilizadores e vai ao encontro daquilo que são as suas necessidades.
Quem deve estar envolvido: Equipas de UX
Quais são os seus componentes: N/D.
Entregáveis: São essencialmente 3, os entregáveis desta atividade: 1 – Guião com as diferentes questões e atividades que, respetivamente, queremos fazer aos utilizadores e queremos que eles façam no protótipo; 2- o próprio protótipo apresentado presencialmente ou remotamente e 3 – uma apresentação dos principais findings e insights.

Conclusão

Lançar um website ou relançar um website dá muito trabalho. Implica muito tempo e muitas atividades. E temos sempre 2 hipóteses: fazê-lo bem ou fazê-lo mal.

Hipótese 1 – Para fazê-lo bem feito devemos:

a) ouvir os utilizadores e

b) seguir esta checklist de 12 atividades de ux/ui para (re)lançamento do website.

Hipótese 2 – Para fazê-lo mal feito, indo pelo caminho mais fácil e pelo caminho do adivinhar, também temos 2 hipóteses:

a) compramos um template ou

b) começamos logo com o design e a adivinhar features que ficariam bem no website, sem ouvir ninguém.

No primeiro caso temos sempre retorno no segundo temos sempre problemas.

E vocês que outras atividades de ux/ui acrescentariam a esta lista?

Want to read this article in English? Please click here

by João Carlos Matos

A falsa e prejudicial métrica NPS e como poderia ser reformulada

A Falsa e Prejudicial Métrica NPS - Net Promoter Score e Como Torná-la mais Útil

Introdução

Não consigo perceber o foco das Empresas no NPS – Net Promoter Score. Na minha maneira de ver o NPS, tal como foi inventado há está ultrapassado por várias razões e merece ser reformulado ou repensado. Neste artigo irei expor o meu ponto de vista sobre o enviesamento que o NPS dá às empresas, enquanto métrica e propor alguns tweeks ao mesmo por forma a que esse enviesamento seja menor ou inexistente mesmo!

O NPS – Net Promoter Score

Em poucas palavras, o NPS é um indicador feito com base numa pergunta sobre a probabilidade da pessoa recomendar um produto/serviço/Empresa/marca…pergunta essa que é feita online ou offline e cuja resposta que a pessoa tem de dar é dentro de uma escala que varia entre 0 a 10, em que 10 significa que Recomendaria e 0 que não recomendaria.

As pessoas que dão respostas entre 9 e 10 são denominadas de promotores e as que dão respostas entre 0 e 6 são chamadas de detratores. As respostas das pessoas que ficam situadas entre 7 e 8 são chamadas de passivas.

Com base nessas respostas, existe uma fórmula de cálculo que dá o NPS:

NPS = % Promotores – % Detratores

E logo aqui, para mim, há algo que não entendo. Porque razão as pessoas que respondem 7 e 8 não entram nas contabilização do NPS? Qual a diferença entre uma pessoa que responde 9 e uma que responde 8? Ambas não vão recomendar o produto/serviço/marca….? Diria que sim. E o mesmo acontece entre uma pessoa que responde um 6 ou um 7.

O Porquê do Enviesamento do NPS

Problemas relativamente à questão:

“De uma escala de 0 a 10, em que 10 é muito provável e 0 pouco provável, qual a probabilidade de recomendar este serviço online a familiares ou amigos?”

Perguntar sobre o futuro…Saberemos nós prever o futuro?

Estar a perguntar às pessoas se fariam algo no futuro não indica nada de concreto às Empresas no presente, diria mesmo que tende a ser uma questão enviesada porque: 1 – as pessoas realmente poderão ou não fazê-lo e as Empresas nunca saberão qual a % de pessoas que responderão 10 no NPS foram realmente aquelas que recomendaram; 2 – As pessoas fá-lo-ão se tiverem oportunidade e/ou se se lembrarem que utilizaram um serviço x e que “foi bom” ou “foi útil”
Muitas vezes aquilo que as pessoas dizem que vão fazer no futuro, não o fazem por diversas circunstâncias, sendo o esquecimento a principal delas todas.

Qual a correspondência entre a probabilidade de um acontecimento acontecer (1) ou não acontecer (0) e a escala de Lickert?

A probabilidade mede-se entre 0 e 1, em que 0 significa que o acontecimento não acontece (não recomendariam) e 1 o acontecimento acontece (recomendariam). Não consigo traduzir ou fazer a equivalência entre uma escala de Lickert que varia entre 0 e 10 e a probabilidade de um acontecimento acontecer não (0) ou acontecer (1). Se a pessoa responder 4 significa que recomendará ou que não recomendará? Ou se responder 7 significa que irá recomendar ou não vai recomendar?

O problema das escalas grandes como a de Lickert

Qual a diferença entre uma pessoa que responde com um 6 e uma pessoa que responde com um 7? Muito provavelmente, ambas querem dizer o mesmo que é que “recomendariam o serviço online a amigos ou familiares”
Mesmo em termos de heurísticas de UX, para o cérebro humano ter uma grande escala, torna o processo de escolha de um número para avaliação das experiência “complexo” para o cérebro humano e o que vai acontecer, provavelmente é haver uma tendência das pessoas escolherem valores mais ou menos médios ou intermédios.

Conseguiremos nós avaliar todas as experiências que temos na nossa vida? E recomendá-las? Eu acredito que não

Existem serviços em que é difícil para as pessoa estarem a recomendá-los, seja a amigos, familiares ou até mesmo conhecidos: por exemplo: serviços relacionados com saúde e bem-estar, concretamente ter de fazer ou passar por uma cirurgia; ter de ficar internado; ter de fazer um exame evasivo; ter de fazer um tratamento de quimioterapia; ter de fazer uma sessão de hemodiálise…e por ai vai! Para já, eu não consigo avaliar a experiência de passar por uma cirurgia. Será uma boa experiência o ter acordado da anestesia? Sem dúvida que sim, mas e se o problema não tiver sido corrigido ou resolvido, será que a experiência continua a ser boa?! E mesmo que o problema tenha sido resolvido. Mas como se avalia o problema ter sido resolvido? No 1 minuto seguinte a ter acordado? No dia seguinte, na semana seguinte, no mês seguinte ou no ano seguinte? E se existirem ou aparecerem doenças/efeitos secundários à cirurgia ou à anestesia ou até mesmo à resolução dessa doença inicial e que são até mesmo mais graves? A experiência continua a ser ótima?! É difícil de avaliar.

A experiência não é só aquilo que se passa online

Estar a pedir a uma pessoa para avaliar a sua experiência com um serviço online é enviesar completamente a informação que se vai receber. 1 – A experiência é todo o processo e não só o que acontece online ou offline. 2 – A pessoa pode ter uma excelente experiência online e apontar um 10, mas o processo e a experiência offline ter sido péssimo (apontaria um 0) ou vice-versa. Estamos a medir o que devemos medir? E estamos a receber métricas verdadeiras e reais? Eu diria que não.

As diversas interpretações das perguntas NPS

E se uma pessoa responder 0 ou 1 porque não saber dentro do seu círculos de amigos ou familiares quem possa quer ou ter a necessidade de utilizar aquele serviço online? É uma interpretação justa da pessoa, mas será que é indicativa e proveitosa como métrica para a Empresa? Provavelmente não.

Problemas relativamente à questão

“Como avalia a experiência numa escala de 0 a 10, em que 10 é excelente e 0 péssima?”

The Peek-end Rule

The peak-end rule é uma heurística psicológica na qual as pessoas julgam uma experiência em grande parte com base em como se sentiram em seu pico (ou seja, seu ponto mais intenso) e em seu final, em vez de com base na soma total ou média de cada momento da experiência. experiência. Assim, se a pessoa tiveram um excelente experiência no seu pico e no seu final, darão uma avaliação de 9 ou até mesmo de 10. Mas como terá sido o resto das experiência e se foi péssima como isso é transmitido para a Empresa para ser corrigido? Ou se, vice-versa, o pico da experiência tiver sido péssimo, a pessoa irá responder entre 0-1 à pergunta.

E por fim, existem pedidos de resposta a questões do NPS que envolvem ofertas às pessoas que respondam acima de 9. Ora, isso torna 100% enviesadas as respostas das pessoas que estarão mais interessadas nas ofertas e respondem “falsamente” à questão.

O NPS Reformulado

Como visto anteriormente, o NPS é efetivamente uma métrica falsa e que prejudica o os diferentes negócios das Empresas que o utilizam. Algumas soluções para ultrapassar alguns dos constrangimentos do NPS:

Reformular a questão do NPS e colocá-la no passado: “Na última semana ou no último dia, recomendou o nosso serviço a algum familiar ou amigo?” Desta forma não estamos a recolher métricas com base num futuro que pode ou não acontecer, mas sim com base naquilo que efetivamente aconteceu. Ou então, para novos clientes a pergunta poderá ser: “Como soube do nosso serviço? Foi algum familiar ou amigo que lhe recomendou a utilização?”
Como é que as Empresas transformam os insights ou os números da avaliação que as pessoas deram ao responder ao NPS para tornar a experiência efetivamente ótima ou excelente? => Falando com as pessoas
Se se optar por utilizar o NPS ipsis verbis como é, pelo menos utilizar os verbatins das respostas à questão “Qual a razão para ter dado essa avaliação à experiência que teve com o serviço?” Ou “Qual a razão para não recomendar o nosso serviço” e utilizar a análise sentimental para perceber em que partes da experiência as “coisas” estão más.

Want to read this article in English? Please click here

by João Carlos Matos

A Experiência do Cliente na Saúde - Systems Thinking e o Foco no Paciente

Introdução

Em Julho deste ano tive o azar de ter tido um percalço grave que na minha saúde que me obrigou a parar e a ser internado em dois hospitais públicos. Primeiro no Hospital Garcia de Orta em 2 serviços: cuidados intensivos e enfermaria de nefrologia. E depois no Hospital Curry Cabral no serviço de nefrologia. Tudo isto durante um período de mais ou menos 4 semanas. Durante esse período e entre análises, exames e outros atos médicos, não tive a melhor experiência enquanto utente do SNS. Experimentei mesmo aquilo que todos nós ouvimos falar que é o ou parece ser a total decadência do SNS e o seu completo desfoco no paciente/ser-humano.

E é com base nestas experiências que, enquanto profissional da indústria digital especialmente na área de UX – User Experience que relato neste artigo a minha opinião de como a falta de pensamento sistémico (Systems Thinking) compromete muito a recuperação e a cura dos pacientes.

Systems Thinking em Poucas Palavras

Nada nem ninguém vive isoladamente, tudo ao nosso redor está de alguma forma ligado ou relacionado, e mudanças numa parte afetam outras partes (efeito borboleta), ou seja vivemos em sistemas ou se preferirem estamos inseridos em ecossistemas.

Um sistema é qualquer grupo de partes interativas, inter-relacionadas ou interdependentes que formam um todo complexo e unificado que tem um propósito específico. E na saúde, enquanto seres humanos que somos, isso é mais do que notável, ainda que, como relato na minha experiência, os governantes e os seus profissionais não o vejam dessa forma.

Ao pensarmos em Systems Thinking permite-nos compreender a relação entre o problema que estamos a resolver e as soluções que criámos.

O processo de análise ajuda a entender a interconectividade e como cada elemento se relaciona entre si; O Systems Thinking procura descobrir relações entre os elementos dentro de um sistema. Por exemplo: A relação entre um paciente e o seu médico, e os outros médicos, os outros pacientes, os enfermeiros, os assistentes técnicos, os assistentes operacionais, os seus familiares e os familiares de outros doentes..… Ou a relação do paciente com as instalações como o quarto, as salas de exame, as casas de banho, o espaço exterior,…..Esta é uma ferramenta de diagnóstico útil para contextualizar o problema.

O Quadrante das Necessidades do Ser Humano

Se pensarmos na forma como vivemos, independentemente de sermos ricos ou pobres, novos ou velhos, saudáveis ou com menos saúde, solteiros ou casados, temos necessidades a que as empresas devem estar atentas para tornar a experiência de cliente boa e diferenciada.

Estas necessidades, singularmente, podem-se manifestar com mais força em determinadas etapas da nossa vida, episódios da vida, tipo de empresas que estamos a falar.

A falha em entender este fenómeno, que por si só é sem dúvida um sistema – o Ser Humano e o seu Ecossistema de Necessidades -por parte das entidades e/ou pessoas que criam, mantêm e dirigem os diferentes produtos/serviços, cria ainda mais problemas do que aqueles que inicialmente têm para resolver.

As Experiências em 2 Hospitais Públicos e a sua Relação com o Systems Thinking e o Círculo das Necessidades Humanas

As minhas experiências no Hospitais Garcia de Orta e Curry Cabral foram distintas, ambas más, mas distintas porque o estado de saúde em que estava em cada um deles variou.

No Hospital Garcia de Orta – serviço de cuidados intensivos – considero que a experiência que tive foi boa, no sentido de não ter nada ou muita coisa a apontar. Aliás, considerando o fenómeno da psicologia aplicado ao campo de UX que é a Peak-End Rule, foi neste serviço que me ressuscitaram e isso foi o que me ficou na memória.

Já na enfermaria de nefrologia a experiência foi péssima. Aplicando o mesmo fenómeno da Peak-End Rule o que me ficou na memória foi o dia 15 de Agosto de 2022 por volta das 11:30, altura em que tive alta.

Uma vez que a experiência nos cuidados intensivos não foi má, talvez porque a maior parte do tempo estive adormecido, vou focar-me na experiência na enfermaria de nefrologia e identificar alguns pain points.

Vivência – Como Vivemos e Convivemos — Quando estamos internados, o hospital passa a ser a nossa “casa”, os outros pacientes os nossos colegas bem como os médicos, os enfermeiros e os assistentes técnicos e operacionais. Então, faz sentido, se estivermos a pensar em Systems Thinking que as Administrações hospitalares vejam a forma como vivemos no hospital como uma extensão, ainda que temporária, da nossa casa, vida e hábitos.

Olhando para o Circulo das Necessidades, os hospitais terão que perceber as necessidades dos pacientes – além da necessidade de cura – e posicionar os diferentes espaços físicos como uma extensão da vida das pessoas.

Em termos de Systems Thinking e Necessidades Humanas e olhando para os meus pain points da experiência: 1 – em ambos os hospitais tive de utilizar para tomar banho uma casa de banho comum e aberta a todos os doentes daquela enfermaria e eram mais de 15 doentes! 2 – As referidas casas de banho eram completamente datadas, tinham falta de torneiras, falta de mobiliário, num deles, o poliban tinha ferrugem e as paredes muita humidade que se notava com a visão, mas também com o olfacto, – cheiro a bolor; 3 – não havia gel de banho, shampôs ou sabonetes (e note-se que se existe disponibilidade e vontade para fazer a barba aos doentes com utilização de gillette e gel de barbear também deveria haver a preocupação com o resto da higiene) e já não falo nos descartáveis.

Instalações limpas e higienizadas e cuidadas > Menor probabilidade de existência de bactérias/vírus > Menor probabilidade da pessoa contrair uma infeção local ou uma septicemia == Melhor e mais rápida recuperação

Equilíbrio e Lazer – Como Dormimos — Hoje em dia um paciente internado num hospital tem horários “peculiares” de acordar e fazer a higiene corporal bem como de tomar algumas refeições. O despertar é entre as 6:00 e as 6:30 da manhã, sendo que a higiene é feita nessa altura, e o jantar por exemplo é às 19:00. E estes horários existem não para bem do paciente e ser humano, mas para tornar a mudança de turno dos enfermeiros e auxiliares mais célere. Mas pior que existirem estes horários é haver uma pressão enorme, no caso dos serviços de alimentação, para que os pacientes comam depressa porque é preciso levantar o tabuleiro, arrumar a copa e ir embora.

Olhando para o Circulo das Necessidades, na parte da Vivência – Como dormimos e a quantidade de sono que temos (e está provado em diversos estudos) é não só importante para as pessoas saudáveis, o que se dirá para pessoas em recuperação.

Em termos de Systems Thinking e Necessidades Humanas e olhando para os meus pain points da experiência: 1 – em ambos os hospitais tive de praticar os referidos horários, e o horário de acordar e a pressão para fazer as refeições é por demais stressante.

Passando e pensando naqueles que nos visitam e que fazem parte da nossa vida e é quem nos dá força e nos ajuda a ultrapassar as nossas dificuldades e a tornar os momentos mais difíceis como estar doente e internado um pouco melhores.

Em termos de Systems Thinking e Necessidades Humanas e olhando para os meus pain points da experiência: 1 – as visitas serem permitidas apenas a partir das 14:00 da tarde; 2 – as visitas só pode ser uma pessoa; 3 – as visitas só poderem durar 1hora, sendo que essa hora será dividida no caso de outros doentes da enfermaria terem também visitas para essa hora.

Estar com os familiares, amigos > mais dopamina, serotinina, endromina e ocitocina (hormonas da felicidade) em circulação > torna a situação, ou pelo menos o dia melhor e mais feliz. Há até quem “viva” a pensar na altura da visita > o ânimo e a motivação do doente tende a aumentar == Melhor e mais rápida recuperação

Pensando agora nos enfermeiros e nos assistentes operacionais e técnicos e até mesmo nos médicos, há que haver um interesse em conversar e explicar ao doente o que se passa com ele, quais serão os próximos passos, que tipo de procedimento se está a fazer ou vai fazer, quais os resultados dos exames e das análises e até mesmo perguntar se está tudo bem diariamente, passar a visita diariamente….Facto é que a minha experiência nestes 2 hospitais não foi a melhor a este nível de vivência. Houve muita falta de comunicação e isso deixa os pacientes preocupados e ansiosos, além de que não podem informar o enfermeiro sobre alguma coisa que ele tenha dúvida, porque o médico não falou com o doente.

Em termos de Systems Thinking e Necessidades Humanas e olhando para os meus pain points da experiência: 1 – raramente o médico(a) passava no piso diariamente para conversar comigo sobre a minha situação; 2 – a não ser quando tive alta, os resultados dos exames e análises não era dados ou informados ao doente; 3 – Se não perguntasse, nenhum enfermeiro se dignava a dizer o que quer que fosse sobre a medicação administrada ou a necessidade de fazer algum procedimento médico ou de enfermagem….

Profissionais empáticos e interessados > O paciente percebe que os enfermeiros percebem a sua situação e aquilo que estão a passar > Maior o esforço do doente em ajudar e ajudar-se == Melhor e mais rápida recuperação

Equilíbrio e Lazer – Como Compramos – Pensando nos espaços em redor dos hospitais ou mesmo dentro dos hospitais. Este é um tema muito relacionado com o ponto anterior e a empatia de quem nos trata. Em termos de Systems Thinking e Necessidades Humanas e olhando para os meus pain points da experiência: 1 – ninguém me informou se haveria uma papelaria para poder comprar uma revista ou um jornal diário; 2 – as tais águas que eram trazidas por familiares quando estes podiam ir à visita, podiam estar a preços mais acessíveis aos doentes; 3 – se quiséssemos comprar algum miminho (um chocolate, uma fruta, um caderno e uma caneta para escrever, etc.) para além de não nos terem dado informação, acredito que esses espaços não existissem. E já não falo, ainda que acredito que mais cedo ou mais tarde isso aconteça, pode é demorar tempo, da disponibilização para doentes que estão em internamentos de longa duração, de acesso a meios informáticos para se poder fazer compras online como livros para ler, por exemplo.

Viver num hospital > Proporcionar momentos de ócio e de lazer > Menor tempo para pensar naquilo que é mau na doença > Mais distração == Melhor e mais rápida recuperação

Ócio – Como Trabalhamos – eNinguém trabalha num hospital, é verdade! As pessoas estão lá para estarem descansadas, terem momentos de lazer para se esquecerem do mal da doença. Mas nos dias que correm, até porque todos nós temos um smartphone, faz todo o sentido, os doentes serem informados, por exemplo da password do WiFi, até para poderem fazer video chamadas para os seus familiares (cá está o Systems Thinking a funcionar). E até para doentes que estão em internamentos prolongados, faz sentido poderem utilizar passivamente, se quiserem o WiFi seja para as videochamadas, para jogar, ou até mesmo para fazer algum trabalho.

Viver num hospital > Poder estar virtualmente com família e amigos | Poder trabalhar de alguma forma > Menor tempo para pensar naquilo que é mau na doença > Mais distração == Melhor e mais rápida recuperação

Alimentação – Como Comemos – Ninguém gosta de estar internado! Seja porque tem um problema grave de saúde e tem de ficar 2 semanas “instalado” numa enfermaria, seja porque tem febre e precisa de ser monitorizado. Não sou exceção e detestei a experiência de internamento destes dois hospitais públicos. Todos nós sabemos ou ouvimos dizer que “a comida de hospital é uma porcaria” e na realidade a comida no Garcia de Horta – Nefrologia não era saborosa. Mas a questão em termos de Systems Thinking e Necessidades Humanas é o facto de (pain points): 1 – a dieta que me foi prescrita nos cuidados intensivos não foi alterada no momento em que fui transferido para a enfermaria (as minhas necessidades na UCI são diferentes das minhas necessidades na enfermaria); 2 – não me foi prescrita uma dieta de acordo com a minha sintomatologia; 3 – eram distribuídas apenas 2 garrafas de 0,5L / dia. Melhor do que no Curry Cabral em que a distribuição de água por parte dos serviços estava proibida pela Administração como forma de poupança, imagine-se!!! Os rins funcionam à base de líquidos e o melhor deles é a água; 4 – não me foi disponibilizada uma nutricionista para perceber que tipo de ingredientes, em que quantidades e como cozinhá-los deveria comer para recuperar mais rápido, bem como em casa.

Dieta e Nutrientes adequados > Melhoria nos parâmetros bioquímicos e compostos iónicos do organismo == Melhor e mais rápida recuperação

Conclusão

A primeira conclusão a retirar é que tudo o que foi exposto neste artigo pode e deve ser pensado e transposto para todo o tipo de indústrias: hospitais, seguradoras, bancos, cadeias de restaurantes, cadeias de lojas de roupa, empresas tecnológicas….a experiência de cliente deve ser vista de uma forma holística e com a pessoa e a empresa integradas nos diferentes “Systems” em que estão inseridos.
A biologia do Ser Humano e a importância da visão holística – Systems Thinking – dos problemas de saúde do Ser Humano, tal como acontece ao se estudar e implementar uma transformação digital numa empresa.
A necessidade de haver um foco no doente e no seu problema e não na solução, com base em sintomas ou histórico de saúde.
A experiência do doente deve ser vista como um todo, tal como deve acontecer nas áreas de UX – Research Estratégico – e não com o foco apenas nos sintomas, no órgão que está mal ou olhando para o serviço em que o doente está internado ou até mesmo fazendo juízos de valor sobre patologias pré-existentes – Research Longitudinal.

by João Carlos Matos

artigo-blogue-Regresso-ao-Básico-UX-diferente-de-UI-Marketing-Digital

Regresso ao Básico: User Experience (UX) ≠ User Interface (UI) e um pouco sobre Marketing Digital

Introdução

Este artigo não trás grandes novidades, acredito eu. Ou melhor, para quem domina a área não há novidades, mas para quem não domina a área (ainda que esteja à frente das mesmas), há. Ainda há muita confusão na cabeça de algumas Pessoas que estão em Empresas entre User Experience (UX) e o User Interface (UI). Pelo menos quase todos os dias vejo publicações do tipo “….UX/UI” e nalguns casos até chego a conversar com essas pessoas. O Marketing Digital entra no artigo, porque já vi Pessoas em Direções Marketing/Digital de Empresas a misturarem também responsabilidades que são destes profissionais, com as de UX / UI…

Ainda assim quero tornar este artigo divertido e simples de ler. E por isso dividi-o em 3 partes:

irei propor um exercício de reflexão sobre muitas funções que se exercem no mesmo âmbito profissional, mas que não podem ser executadas nem acumuladas pela mesma pessoa
A complementaridade entre User Experience (UX) e User Interface (UI)
O Marketing Digital no meio disto tudo

. . .

Funções e Responsabilidades Complementares mas não iguais, tal como acontece com o UX e o UI

Então, vamos ao que interessa e convido-vos a refletir sobre estas 10 questões. Será que:

Na projeção da sua nova casa contrataria um engenheiro civil? Ou essa é a responsabilidade de um arquiteto?
Pediria um diagnóstico complexo de saúde com respetivos exames e/ou tratamento a um enfermeiro? Ou essa é a responsabilidade do médico?
Deixaria um cardiologista fazer uma intervenção cirúrgica no seu coração? Ou essa é a responsabilidade do cirurgião cárdio-toráxico?
Quando a sua filha tiver a sua primeira menstruação levá-la-á a um obstetra? Ou essa é a responsabilidade do ginecologista?
Admitiria que um psicólogo receitasse medicação ao seu pai? Ou essa é a responsabilidade do psiquiatra?
Se precisasse de desenvolver uma aplicação móvel, queriam um front-end devolver? Ou isso é a responsabilidade do back-end developer? (Neste aspeto, também há muita confusão de conceitos e chega-se a anunciar que se quer um Full stack developer)
Acha que umm chefe de renome contrataria um pasteleiro para assumir a chefia da cozinha de quentes e frios do seu restaurante? Ou isso é responsabilidade de um chefe de cozinha de quentes e frios?
Se precisasse de construir um móvel do estilo séc. XV iria ao carpinteiro? Ou essa é uma arte e ofício do marceneiro?
Precisando de pintar todo o interior e exterior da sua casa, contrataria um artista plástico? Ou essa é uma responsabilidade do pintor?
Será que a equipa da Ferrari iria buscar um piloto de Moto GP para pilotar o seu Fórmula 1? Ou sabe que a Fórmula 1 em nada tem a ver com o Moto GP, ainda que ambos os desportos exigiam pilotos de alta velocidade?

E poderia continuar por ai fora com muitas mais “questões-exemplos”. Mas acho que deixei o meu ponto claro:

Assim, como há profissões que são exercidas no mesmo local, ou que os seus profissionais possam ter formação em comum, ou que utilizam o mesmo tipo de ferramentas, e possam inclusivamente ter teorias e práticas idênticas, as funções e responsabilidades não são as mesmas, são sim complementares, tal como acontece com o UX e o UI e o Marketing Digital.

C’est très simples!!!

. . .

Algumas das Diferenças entre o User Experience (UX) e o User Interface (UI)

Nesta segunda fase do artigo vamos ver de forma muito rápida, quais as diferenças entre o UX e o UI.

O UX é pensar em outcomes, UI é pensar mais em outputs
O UX trabalha mais o lado emocional, o UI trabalha mais o lado racional
O UX faz-nos sentir algo, o UI faz-nos ver esse algo
O UX envolve pensar estrategicamente, UI envolve executar essa estratégia
O UX é o pensamento para além do UI, o UI é o resultado do UX
O UX faz as perguntas, o UI reflete as respostas a essas perguntas
O UX é mais conceptual, o UI é mais tangível

Em cima disto, poderia falar dos entregáveis que um profissional de UX deve trabalhar e aqueles trabalhados pelos UI designers. E só por ai deveria ser perceptível que as 2 funções devem ter 2 responsáveis distintos, mas tornaria o artigo muito mais longo. Por isso e caso queiram, podem consultar, por exemplo este artigo.

Ainda assim, para quem é da área, julgo que a diferença ficou bem explícita! Para quem não é da área ou é mas continua confuso, mais dois exemplos.

O UX é o esqueleto, o UI são os músculos, os órgãos e a pele
O UX é o esboço do artista feito a lápis de carvão, o UI é o desenho final pintado com tinta

. . .

Marketing Digital e a sua relação com o UX e o UI

Bom, sobre o Marketing Digital a conversa vai ser outra. Bem mais curta, até porque dentro do Marketing Digital temos várias funções e responsabilidades: SEO (e dentro desta outras tantas áreas), e-mail marketing, automação, gestão de redes sociais, gestão de conteúdos, gestão de campanhas, monitorização e analytics…entre outras. E aquilo que acontece com a diferenciação entre UX e UI deveria acontecer, também, para as diferentes sub-áreas do marketing digital.

“A relação do Marketing Digital com o UX e o UI dito de uma forma simples é: O Marketing Digital encontra-se a jusante do trabalho de UI, no que há estratégia de lançamento diz respeito e a montante do trabalho de UI e muito interligado com as ações de UX no que há estratégia global do produto/serviço”.

As diferentes disciplinas do Marketing Digital estão relacionadas com o UX, porque afinal estamos a falar, essencialmente de estratégia, o que não significa, mais uma vez, que as mesmas devam ser exercidas pela mesma pessoa, neste caso pessoa de UX pura e dura ou de UI pura e dura no que às atividades abaixo diz respeito:

Definição de métricas – deve ser feito em conjunto com as equipas e com os stakeholders do produto/serviço e não por uma única pessoa
Otimização da conversão – A conversão é algo que está relacionado com o negócio, e considerando que o UX, como já deve estar compreendido, diz respeito a perceber quais as necessidades, expectativas, motivações e frustrações dos clientes, este ponto é algo da responsabilidade dos profissionais de Marketing Digital
Configuração e gestão de Google Tag Manager e Google Analytics – responsabilidade dos profissionais de marketing digital ou com formação para tal
Definição de requisitos de SEO – responsabilidade dos profissionais de marketing digital ou com formação para tal, nomeadamente SEO técnico, SEO conteúdo,…
Conhecimento prático das ferramentas de HTML e CSS – maior responsabilidade dos profissionais de front-end
E poderia acrescentar outras tantas atividades desde o SQL, passando pelo código puro e duro até a ferramentas e conhecimentos técnicos de Analytics e BI

Disclaimer: E digo isto, com conhecimento de causa, pois trabalhei com vários profissionais de UX e de UI e de marketing digital, e nenhum deles tem ou tinha conhecimentos mínimos para fazer as atividades acima descritas.

. . .

Conclusão

Como devem ter reparado eu sou defensor que para funções diferentes pessoas diferentes. E a razão é simples: mais competitividade entre pessoas e entre nas Empresas. Porém, isso não significa que uma pessoa com formação em Marketing Digital não possa mudar o seu percurso de carreira e candidatar-se a funções de UX ou UI, ou vice-versa, desde que tenha formação para tal. E também não significa que cada uma destas pessoas deva trabalhar sozinha e em silos ou que não deva ou não possa ter conhecimentos nas outras áreas. Até pode tê-los como hobbie.

E eu sou insuspeito por ter esta opinião, porque tenho uma larga formação certificada e experiência profissional nas áreas de Marketing Digital (SEO, Analytics) e UX e UX Research, ou seja sou aquilo a que chamam um colaborador formado e formatado em T-shape, “valioso” para as Empresas com visão estratégica e com foco nas pessoas (colaboradores e clientes), porque tenho largos conhecimentos nestas áreas complementares e gosto tanto de UX como de Marketing Digital.

Para mim o que significa é que a UX quem é de UX (ou mudou para esta área); a UI quem é de UI (ou mudou para esta área) e a Marketing Digital quem é desta área (ou mudou para esta área, sendo que todas elas têm o seu grau de complementaridade e, portanto a formação em T-shape de um colaborador, é uma mais valia para as Empresas, mas não significa que tenha ou deva assumir estas 3 áreas ou 2 delas, simultaneamente. Não que não o possa, mas acho que não é produtivo nem competitivo, acima de tudo para as Empresas. Pode sim, ser ouvido, consultado, se tiver esse know how e os temas serem discutidos conjuntamente. Os engenheiros civis e arquitetos estão em constante conversações no que a potencial projeto diz respeito e ajudam-se. E faz sentido! Imaginem a monotonia, e as perdas em vários sentidos, se o engenheiro civil não percebesse algo de arquitetura e vice.versa?

As funções de UX são diferentes das funções de UI e ambas são completamente distintas de quem exerce funções na área do Marketing Digital.

Aliás, é de extrema importância, na minha opinião, que as Empresas entendam que existe uma complementaridade entre elas. Não o ver desta forma, não é competitivo para ninguém! Não é competitivo para a Empresa, não o é para o colaborador e não o é para os clientes. Tal como não é competitivo nem para o Hospital, nem para os colaboradores, nem para os doentes, ter um enfermeiro a fazer o trabalho de um médico, ou num atelier ou empresa de consultoria haver um arquiteto a fazer o trabalho de um engenheiro civil.

Want to read this article in English? Please click here

by João Carlos Matos

artigo-blogue-como-definir-os-principios-de-design

Como definir os Princípios de Design

O que são os Princípios de Design

Os Princípios de Design são um conjunto de considerações que as diferentes equipas comungam com o objetivo de resolver problemas de design e com isso criar novos e bons produtos/serviços.

Quais as bases em que assentam os Princípios de Design

É interessante perceber que os Princípios de Design não têm por base temas de âmbito Digital, ou temas do âmbito do Design ou até mesmo temas do âmbito de programação e desenvolvimento de software. Os Princípios de Design têm por base as Leis da Psicologia que explicam o porquê das pessoa se comportarem de determinada maneira, e esses comportamentos podem ser transpostos para a utilização de websites e aplicativos.

Também por este motivo que os profissionais de UX e profissionais de UI devem pensar e desenhar as experiências digitais centradas nas pessoas – human-centered experiences.

Os Princípios de Design devem assentar nas diferentes Leis e Efeitos que advêm de diversos estudos feitos no campo da psicologia comportamental e cognitiva. Como o objetivo deste artigo não é o de descrever, exaustivamente, as principais Leis de UX, ou se preferirem as Leis e efeitos da psicologia comportamental e cognitiva, preparei um pequeno resumo dos mesmos, baseados no livro do Jon Yablonsky – UX Laws – e que e podem descarregar aqui.

Integrando os Princípios de Design no Processo Criativo

Uma das formas mais eficientes e, diria mesmo mais inteligentes, de conseguirmos, enquanto profissionais de UX e UI, tomarmos decisões que justifiquem as nossas escolhas é criando os tais Princípios de Design.

Os Princípios de Design permitem-nos justificar as nossas decisões de forma inequívoca. É por isso que o Design é objetivo e não subjetivo, o que não significa nem iliba o facto de podermos tomar decisões erradas.

Leis de Psicologia Comportamental

Princípios de Design

Regras

Doherty Thereshold – Objetivo para manter as pessoas completamente “interessadas” ao interagir com um dispositivo eletrónico, como o computador, tablet ou smartphone. Se o sistema destes dispositivos derem uma resposta após o limite de 400 ms, as pessoas, eventualmente ficarão ou já estarão desinteressadas.

Feedback¹

O feedback reconhece as ações e mostra os resultados para manter as pessoas informadas.

Os aplicativos iOS integrados fornecem feedback perceptível em resposta a cada ação do usuário. Os elementos interativos são destacados brevemente quando tocados, os indicadores de progresso comunicam o status das operações de longa duração e a animação e o som ajudam a esclarecer os resultados das ações.

Lei de Hick – O tempo que as pessoas demoram a tomar uma decisão, é proporcional ao número e à complexidade de opções que lhe estão disponíveis

Direction over Choice² (Simple)

CTA único proeminente por screen.

Uma única mensagem de E-mail

Uma pergunta de cada vez na jornada Join, perguntas binárias em vez de escolha múltipla.

Tom de voz simples, consistente e direto.

1 – Apple – Human Interface Guidelines

2 – Bulb – Solar Design System – Princípios de Design

As Heurísticas de Nielsen e Molich e os Princípios de Design

As Heurísticas de Neilsen e Molich nada mais são do que Princípios de Design, mas que são ou se tornaram tão “óbvios” que, aplicando-os, estamos a proporcionar uma experiência efetivamente centrada nas pessoas. Como descrito no website da NNGroup: “São chamados de “heurísticas” porque são regras gerais e não diretrizes de usabilidade específicas”.

Leis de Psicologia Comportamental

Heurística de Nilesen e Molich

Regras

Lei de Jakob – As pessoas passam a maior parte do seu tempo a navegar noutros websites. Ou seja, e em termos de modelos mentais, significa que preferem que o seu website funcione e que possam navegar nele da mesma forma que veem os outros websites funcionarem por já terem um padrão mental estabelecido

2 – Correspondência entre o Sistema e o Mundo Real

Se inovar no design, não desvirtuá-lo “too much” ao ponto de construir os modelos iniciais que já existem

Alavancar os modelos mentais que as pessoas já possuem, em famigerado de obrigá-las a aprender tudo de novo que os utilizadores entendem o significado sem precisar procurar noutros sítios

Efeito Estética e Usabilidade – As pessoas tendem a considerar o design esteticamente mais agradável como sendo também o design com melhor usabilidade.

8 – Estética e Design Minimalista

Criar designs simples e coerentes e que criem uma expectativa de que realmente vai funcionar

Priorizar features e conteúdo que se foquem no objetivo principal do website

Conclusão

Devemos sempre ao desenhar ou redesenhar um website, uma aplicação, um layout de uma loja, a decoração do interior de uma assoalhada e por ai fora, ter presente que o que estamos a fazer é para as pessoas e, portanto, é nosso dever perceber como é que estas pensam para podermos

1 – criar experiências efetivamente centradas nas pessoas – pessoas sobre objetos

2 – ter uma metodologia para resolução de problemas de design – função sobre a forma

3 – justificar as nossas escolhas enquanto profissionais, a todos os stakeholders – objetividade sobre subjetividade

Artigo redigido com base na leitura do Livro Laws of UX de Jon Yablonsky

Want to read this article in English? Please click here

by João Carlos Matos

artigo-blogue-Empathia-as-a-Service-EaaS

Empathy as a Service – EaaS

Todos nós estaremos mais ou menos familiarizados com o conceito “as a service” (como um serviço), o qual nos remete para ofertas como Software as a Service (SaaS), Infraestrutura as a Service (IaaS) ou Plataforma as a Service - serviços cujo funcionamento depende da cloud. Mas há, no entanto, uma proposta, que embora recorra a uma nomenclatura comum, é, em tudo, distinta: a Empatia as a Service.

Ao contrário dos serviços assentes na cloud, a empatia é a capacidade de, como diria o bom português, “colocarmo-nos na pele do outro”. Um termo que é visto e quantificado por alguns profissionais da área de Customer e Brand Experience como a experiência dos utilizadores face ao serviço ou produto desenhado. Enganam-se. A isso chamamos de UX – User Experience ou experiência do utilizador. Para que o consumidor tenha uma boa experiência enquanto utilizador, a empatia não se pode focar apenas no resultado, mas sim na identificação do problema, estando presente em todas as fases da sua resolução, isto é, funcionando como um serviço.

Um dos elementos fundamentais do conceito de Empatia as a Service é a jornada do consumidor. Muito mais do que um documento pró-forma a decorar a secretária do cliente, a jornada do consumidor deve ser vista e usada como um plano estratégico de e para a gestão de topo da organização, pois é com base nela que percebemos e melhoramos os processos e competências das pessoas ligadas a cada um dos touchpoints da marca.

Na sua essência, a jornada do consumidor é empatia, isto porque tem de ser vivida. E por todos: desde a equipa de projeto ao cliente-empresa com quem trabalhamos. Só assim estaremos aptos a colocar-nos na “pele do cliente”, pensando e sentindo o que ele experiência em cada ponto de contato com a marca, garantindo, enquanto consultores, que o que entregamos é muito mais do que um simples documento. Só assim poderemos garantir que a empresa conhece, efetivamente, as dores e as alegrias dos seus clientes.

Nesse sentido, é importante criar uma relação de confiança e sintonia com o cliente-empresa para podermos gerir expetativas e projetar em conjunto soluções para o futuro, entregando, desta forma, um produto que serve o propósito para o qual foi desenhado. Sempre com o foco na Empatia as a Service.

Ver o artigo publicado no Linkedin

by João Carlos Matos

João Carlos Matos

ux

Introdução

O NPS – Net Promoter Score

O Porquê do Enviesamento do NPS

Perguntar sobre o futuro…Saberemos nós prever o futuro?

Qual a correspondência entre a probabilidade de um acontecimento acontecer (1) ou não acontecer (0) e a escala de Lickert?

O problema das escalas grandes como a de Lickert

Conseguiremos nós avaliar todas as experiências que temos na nossa vida? E recomendá-las? Eu acredito que não

A experiência não é só aquilo que se passa online

As diversas interpretações das perguntas NPS

The Peek-end Rule

O NPS Reformulado

Sobre mim

Explorar

Conversar