Change neon

Engaged - Designing for Behaviour Change by Amy Bucher - Simples Review com exemplos do que Aprendi

 

Terminei de ler o livro “Engaged – Design for Behavior Change”, que aprofunda vários temas de Behaviour Change e que nos ajudam a entender o comportamento humano. Amy Butcher utiliza de forma plena a Teoria da Autodeterminação (SDT) para nos guiar pelo complexo mundo Behaviour Change, enfatizando particularmente o aspeto crucial de integrar o Behaviour Change no Design de produtos e serviços digitais.

Embora o livro não aborde explicitamente os exemplos que enumerarei a seguir, eles permanecem altamente relevantes no contexto atual em que vivemos, sendo muitas vezes negligenciados por profissionais da área.

  • A E-Privacy e o GDPR – sendo, respetivamente, uma Diretiva Europeia e um Regulamento aplicado em Portugal, giram principal e logicamente em torno do panorama legal. No entanto, os mesmos foram criados porque não houve um respeito pelos utilizadores. Ou seja, a essência destes documentos está na necessidade de respeitar as escolhas das pessoas e estabelecer uma arquitetura de escolhas transparente. Os utilizadores têm o direito fundamental de compreender o propósito das tecnologias com as quais interagem, garantindo clareza e uma tomada de decisão informada.

 

  • Imagens nos maços de cigarros – Outro exemplo é a utilização de imagens gráficas em maços de cigarros como meio de desencorajar o tabagismo. Apesar das boas intenções, o conceito ignora um fator crucial conhecido como “Present Bias“. A suposição de que os indivíduos que compram cigarros têm o objetivo imediato de parar de fumar ignora a realidade de que a sua intenção principal é fumar. Ao não se guiar, primeiramente, as pessoas para a mudança de comportamento, a abordagem/tática pode não alcançar o impacto pretendido.

Estes exemplos ilustram a importância de alinhar estratégias de design com uma compreensão profunda do comportamento humano. E não o contrário. Sendo que o contrário pode ser uma grande black-box.

Ao se considerar as motivações subjacentes e os preconceitos cognitivos, os profissionais da área podem criar intervenções que ressoem nas pessoas a um nível profundo, promovendo mudanças de comportamento significativas e tornando a utilização do produto/serviço claro, transparente, duradouro e não apenas num pico de utilização com objetivo único e exclusivo de crescimento instantâneo.

by João Carlos Matos

O-que-são-Produtos-Digitais

Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?

Introdução

Já vimos na PARTE 1 – O que são Produtos Digitais. E na PARTE 2 – O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum.

Vamos agora ver na PARTE 3 – se Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?

Ambiente Waterfall

Em ambiente waterfall significa, de forma não exaustiva, o seguinte:

  1. O tipo de projeto não envolve incertezas. Ou seja já se sabe o que se vai desenvolver/construir. Por exemplo, uma casa ou uma piscina.
  2. As as atividades desse projeto, por estar inserido num ambiente de certeza e não de incerteza, são desenvolvidas sequencialmente. Ou seja, após o términos de uma atividade, começa-se a segunda.
  3. Não existe um envolvimento direto do cliente e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas
  4. Havendo possibilidade e vontade em fazer testes, estes são feitos em grande escala no final de todas as atividades estarem concluídas

Ambiente Agile

O ambiente agile significa, o contrário do ambiente waterfall. Ou seja, e de forma não exaustiva:

  1. Os projetos mais adequados para serem desenvolvidos neste tipo de ambiente são projetos complexos e que envolvem algum grau de incerteza. Por exemplo, o desenvolvimento de um produto digital, enquadra-se neste tipo de projetos.
  2. Todas as atividades que se consideram necessárias para produzir um incremento, são realizadas no sprint correspondente. E, portanto, daqui surgem duas grandes diferenças de projetos em ambiente waterfall e ambiente agile:
    1. As equipas devem ser multi-disiplinares e autónomas
    2. Os testes, devem ser considerados uma atividade que produz um incremento e, portanto, são realizados em cada sprint e não no final do projeto. Até porque, e passamos para o ponto 3…
  3. Tem de existir um envolvimento direto do cliente. Isto porque não sabemos a 100% como vai ser o produto final. E o cliente também não sabe. E, portanto o cliente tem de estar envolvido no desenrolar do projeto. Por exemplo, criando atividades de UX Research na fase em que Visão do Produto está a ser desenvolvida. E com isso, valorizamos e muito o início do projeto, porque a Visão do Produto incorpora findings e insights daquilo que são as necessidades, frustrações e motivações dos cliente.
  4. Outra altura onde o cliente pode estar presente será nas cerimónias de review para recolha direta de feedback. e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas. Ou seja, e vamos para o ponto 4…
  5. Há iterações entre as equipas, clientes e stakeholders. Iterações essas que nos vão permitindo afinar o produto final. Como? Redefinindo e refinando o backlog prioridades de produto e, posteriormente, o backlog da sprint.

Conclusão

Poder-se-ia dizer que se as metodologias, ou melhor, se os ambientes ou frameworks são diferentes, então, obrigatoriamente, será diferente criar um produto digital em ambiente agile do ambiente waterfall. E dizer isto não está errado. Afinal é uma verdade de La Palice.

O problema é que não basta dizer que estamos ou adotamos uma metodologia agiela e o desenvolvimento do produto digital, per si, será diferente.

Quem faz os ambientes serem waterfall ou agile ou de outro tipo são as pessoas. E, portanto, se não houver vontade, motivação, aprendizagem e um step-up, sem medos e com compreensão 100% da hierarquia de quais são os papéis de cada um e o que isso implica, para mudar a cultura da Empresa e assim efetivamente implementar o ambiente agile, o que vai acontecer é que estaremos a desenvolver um produto digital em ambiente “pseudo-agile”; ou seja na realidade o ambiente é waterfall.

Há várias de formas de perceber isso, elenco apenas quatro:

  • O cliente não é envolvido de início e ao longo do desenvolvimento
  • As equipas não são multi-disciplinares nem autónomas
  • A priorização das atividades ou a re-priorização das mesmas ou de algumas delas, não é feita pelo PO, mas está dependente do cargo da pessoa que faz um pedido.
  • Os testes são feitos “em barda” dias antes do lançamento do produto para o mercado

Espero que tenham gostado e aprendido alguma coisa neste conjunto de 3 artigos sobre produtos digitais.

Want to read this article in English? Please click here

by João Carlos Matos

O-que-são-Produtos-Digitais

O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum

Introdução

Já vimos na PARTE 1 – O que são Produtos Digitais. Vamos agora ver o que envolve, em termos de negócio e de equipas, criar um produto digital.

A PARTE 3 – Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall? Será publicada no final do mês de Agosto.

 

O que Envolve Criar um Produto Digital?

Criar um produto digital não é pensar o design e depois bater código. Desenvolver um produto digital envolve muito mais do que design e desenvolvimento. Tal como a construção de uma casa não envolve apenas um desenho do arquiteto. Ainda que a construção de uma casa seja um projeto fechado e um projeto que decorre em ambiente certo.

Existem diferentes temas que são essenciais para descobrir, posicionar, desenvolver, monitorar, comunicar e impulsionar a adoção deste tipo de produtos.

 

Visão do Produto – Envolve identificar os diferenciais do produto, definir a proposta de valor única e criar mensagens de marketing que comuniquem esses aspectos de maneira convincente.

 

User Experience Research – Antes de se criar um produto digital, é crucial realizar perceber quais as necessidades, motivações, frustrações, expectativas e emoções dos clientes ou potenciais clientes.

O trabalho de desenvolvimento de um produto digital deve ser feito com base em Outcomes e não em Outputs.

As atividades de UX Research fornecem uma base sólida para as decisões de design, permitindo que as equipas validem hipóteses, identifiquem problemas de usabilidade e iterem rapidamente com base no feedback dos utilizadores. Além disso, o foco contínuo nas atividades de UX Research possibilita a adaptação às mudanças ao longo do projeto, tornando o Scrum ainda mais eficiente e eficaz na entrega de soluções inovadoras e centradas no usuário.

 

User Interface Design – Aspeto fundamental do processo de desenvolvimento de produtos, dedicado a criar interfaces visualmente atraentes e user friendly que melhoram a experiência geral dos utilizadores. Estas atividades de desenho do user interface concentram-se em temas que permitam desenvolver interações entre os utilizadores e esses produtos digitais, garantindo que cada interação seja fluida e intuitiva

O User Interface Design não é só algo estético; deve haver um esforço para se encontrar o equilíbrio entre forma e função. Um interface bem pensado (UX Research) guiará os utilizadores ao longo do produto de forma suave e sem atritos, ajudando-os a realizar as suas atividades de forma eficiente e com o mínimo de frustração.

Podem saber mais sobre o tema Como Definir os Princípios de Design.

 

UX Writing ou Marketing de Conteúdo – A criação de conteúdo relevante e valioso é fundamental para a atração e retenção de potenciais utilizadores dos nossos produtos. O UX Writing não se restringe só à escrita de textos para blogues. Todo o conteúdo de um website ou loja online ou de outro produto digital deve ter uma estratégia de UX Writing. Além dos de vídeos, animações, white papers ……

E é preciso saber como escrevê-los; onde colocá-los no nosso produto e quando colocá-los.

 

SEO – A otimização para os motores de pesquisa é fundamental para garantir que o produto digital seja encontrado online, quando os utilizadores pesquisarem por keywords relevantes. Isso envolve a criação pensada e estruturada da arquitetura de Informação desse produto digital, a inserção/utilização adequada de keywords de forma a otimizar o conteúdo e a criação de backlinks.

O UX Writing ou Marketing de Conteúdo e o SEO são disciplinas que têm muita interligação entre si.

 

Acessibilidade – A acessibilidade no contexto do design, dentro de uma equipa que utiliza o Scrum, refere-se às atividades e práticas implementadas para garantir que o produto desenvolvido seja inclusivo e facilmente utilizado por todas as pessoas, independentemente de suas capacidades e/ou necessidades específicas. Este tema, tal como os anteriores e os a seguir devem ser considerados pelas equipas desde o início das atividades do projeto, incorporando-a em todas as etapas do ciclo Scrum.

Este tema, deverá ser também tido em conta aquando das atividades de UX Research. Podem ler mais sobre Empathy as a Service.

 

Analytics — Desempenha um papel fundamental no desenvolvimento de produtos dentro de um ambiente ágil. Ao aproveitar o poder dos dados e os insights que se obtêm a partir deles, as equipas podem tomar decisões informadas em cada etapa do processo de desenvolvimento.

Análises qualitativas — A incorporação de análises qualitativas capacita as equipas a adaptar estratégias com base no feedback dos clientes e em tempo real, garantindo que as suas necessidades, motivações, frustrações são tidas em conta no desenvolvimento do produto.

Análises quantitativas — Essas análises permitem compreensão profunda dos comportamentos, preferências e pontos problemáticos dos usuários, o que influencia significativamente o aperfeiçoamento e a otimização de produtos digitais. Podemos utilizar ferramentas de web analytics e/ou de user behaviour analytics.

 

Desenvolvimento – As atividades de desenvolvimento é tudo aquilo que engloba colocar em prática todo o trabalho desenvolvido nas atividades anteriormente descritas. O trabalho de desenvolvimento não é só olhar para o “design” e começar a programar. Algumas atividades que devem ser tidas em conta antes do desenvolvimento front-end e back-end apresentam-se abaixo.

    • Arquitetura funcional
    • Arquitetura técnica
    • From-end development
    • Back-end development e Gestão de Base de Dados
    • Integração de sistemas e desenvolvimento de infra-estruturas

 

Testes – Em ambiente agile todas as user stories devem ser testadas pelo membro da squad para o efeito. Desenganem-se aqueles que acreditam que os testes são feitos pelas pessoas das organizações ou que se podem fazer depois testes de usabilidade com os clientes. Deixarmos a realização dos testes, com as funcionalidades já em produção, para outras pessoas e/ou para os clientes fazerem é meio caminho andado para que a dívida técnica/UX aumente. Além de que não cumpre com aquilo que a framework do scrum apregoa.

    • Testes de Carga do Servidor
    • Testes das Funcionalidades
    • Produção de quick reports com as respetivas conclusões/correções a fazer

Depois numa fase já mais estabilizada do produto, podemos desenvolver então os testes com os utilizadores.

 

Gestão da Release – A gestão da release no contexto do Scrum refere-se ao processo de planeamento, coordenação e entrega dos outputs, sempre baseados em outcomes (o que defendo) desenvolvidas ao longo das várias sprints pronto para ser disponibilizado aos utilizadores.

Muito importante na gestão da release, nomeadamente se for uma gestão da release já com o produto “fechado” (se bem que o produto nunca estará fechado) é a definição da estratégia de lançamento.

 

Estratégia de Lançamento – A estratégia de lançamento engloba as atividades que têm como objetivo informar os utilizadores sobre as diversas vertentes do produto. A estratégia de lançamento focam-se, na sua maioria, em temas de comunicação como:

  • Campanhas offline (TV, rádio, jornais, revistas, outro tipo de publicações)
  • Organização de Eventos
  • Campanhas online (e-mail, ppc, social media, afiliados, ….)
  • Redes Sociais
  • Influenciadores

 

Conclusão

É fundamental ter em atenção a todos estes temas quando se desenvolve um produto digital, seja em ambiente agile ou ambiente waterfall. Nomeadamente, é imperativo considerar estes temas em cada uma das fases dos ambientes agile:

  • visão do negócio/produto
  • Desenvolvimento do backlog do produto
  • Desenvolvimento do backlog da sprint (Priorização de acordo com aquilo que é a visão do negocio)
  • Cerimónias de Planeamento
  • Cerimónias de Review
  • Cerimónias de Retrospective

Além disso, fica bem patente, tal como o Scrum advoga, que um desenvolvimento de um produto digital não é só desenhar e programar o desenhado.
Sabe mais sobre Scrum neste artigo – Scrum for Dummies”: Papéis e Eventos – Comparação com o Futebol

 

Want to read this article in English? Please click here

by João Carlos Matos

O-que-são-Produtos-Digitais

O que são Produtos Digitais?

Introdução

Quando pensei escrever este artigo tinha imaginado um título do género “Como gerir projetos digitais (ou não) que são transversais à Empresa e/a determinado produto digital em ambiente agile”. Mas dediquei algum do meu tempo a pensar no assunto e percebi que o título não faz sentido algum.

E para não tornar o artigo demasiado longo dividi-o em 3 partes:

PARTE 1 – O que são Produtos Digitais

PARTE 2 – O que Envolve Criar um Produto Digital

PARTE 3 – Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?

 

O que são Produtos Digitais?

Um produto digital é todo o produto que pode ser utilizado e/ou comercializado online. Ou seja, podemos ter como produtos digitais aqueles que são passíveis de download e aqueles que não são passíveis de download:

 

Produtos Digitais Passíveis de Download

  • Produtos que os utilizadores podem fazer o seu download e começam a utilizá-lo. Por exemplo uma App para afinar a guitarra como o Guitar Tuner.

 

Produtos Digitais Não Passíveis de Download – SAAS / Cloud Software

  • Produtos em que os utilizadores não necessitam de fazer download dos mesmos e ainda assim utilizá-los na modalidade de free, paga ou freemium. Todos os Softwares As a Service são este tipo de produtos. Por exemplo, a Google Cloud Platform funciona como SAS.

 

Produtos Digitais como Extensão da Experiência de Cliente – Canal Online

Depois ainda existe uma categoria de produtos digitais que são um misto entre as duas categorias acima. E que eu caracterizo não como produtos digitais, mas sim como táticas ou canais de comunicação com os utilizadores. Por exemplo:

ebooks – livros; Webinars – Conferências; PodCasts – Entrevistas; Cursos online – aulas presenciais; Websites/Lojas Online – sede ou loja física

Conclusão

A criação de produtos digitais, não é desenhar e desenvolver o front-end desse desenho. Nem é desenvolver o back-end desse front-end.

Pensar em desenvolvimento de produtos digitais com foco apenas em design, front-end e back-end vai dar origem a:

1 – Potenciais MVPs mal definidos

2- Desenvolvimento de produtos com base em features (outputs) e não outcomes (mudança que queremos ver no mundo ou nas pessoas para que a vida delas se torne melhor)

3 – Dívida Técnica com uma enormidade de bugs e issues para corrigir

4 – Custos escondidos – de desenvolvimento ou de redesenvolvimento; horas-extra da equipa; possíveis custos no suporte ao cliente, entre outros

Será isto fácil de implementar nas empresas? Certamente que não o é! Mas é meio caminho se as pessoas envolvidas tiverem esta visão e a colocar em prática, mesmo que devagar este princípio.

 

O próximo artigo PARTE 2 – O que Envolve Criar um Produto Digital

Want to read this article in English? Please click here

by João Carlos Matos

Mas-Afinal-o-que-é-um-MVP---Minimum-Viable-Product

Mas Afinal o que é um MVP - Minimum Viable Product

Introdução

Este artigo será de leitura curta, mas contém informações sobre o que é um MVP, ilustrado com alguns exemplos paradigmáticos que suportarão a própria conclusão do artigo.

 

Definição de MVP – Minimum Viable Product

O termo MVP – Minimum Viable Product foi popularizado pelo autor Eric Ries, autor do best-seller “The Lean Startup”. Sua definição diz que um MVP – Minimum Viable Product é uma versão do novo produto que nos permitirá recolher a máxima quantidade de aprendizagem validada sobre os consumidores, com o mínimo de esforço possível. Em suas próprias palavras: “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about the customers with the least effort.”

 

Será que as empresas e as equipas estão definindo e entregando efetivamente um MVP?

Lendo e compreendendo a definição de MVP – Minimum Viable Product, uma questão surge nos dias de hoje:

1 – Será que precisamos desenvolver um produto com um número mínimo de recursos para termos um MVP? A resposta é NÃO.

No entanto, a maioria das empresas e equipes que trabalham nesses assuntos acredita e faz isso repetidamente, sprint após sprint. O objetivo é entregar algo novo em cada sprint/iteração e no prazo proposto, e depois avaliar o que os clientes acham. Isso piora quando não há essa iteração.

O próprio autor do livro, Eric Ries, dá o exemplo de como foi frustrante desenvolver o que ele pensava ser um MVP. Ou seja, um produto com um número mínimo de recursos, colocá-lo online e pedir às pessoas para fazerem o download. Ele dá esse exemplo porque o número de downloads desse suposto “MVP” foi zero. Isso aconteceu apesar de todo o esforço e investimento feito em campanhas Adwords.

Se esse simples exemplo não for suficiente, analisemos os exemplos de empresas reais no próximo ponto.

 

Os Custos de uma Má Definição de MVP

Os produtos que não funcionam, ou seja, que não proporcionam uma experiência excepcional aos clientes, têm custos associados, refletindo-se em:

  • Dívida técnica e dívida de UX.
  • Custos de reputação de marca. A primeira impressão é sempre a que fica, e se a impressão for ruim, isso se traduzirá em custos.
  • Custos de suporte e treinamento. Se o produto MVP for ruim, será necessário explicar aos clientes como utilizá-lo.

 

Exemplos de MVP que não envolvem necessariamente o desenvolvimento de software

Os exemplos apresentados são de Empresas que oferecem uma boa experiência de cliente e tudo partiu de um MVP bem pensado. Lançar um MVP não é uma atividade fácil. É preciso saber muito bem o que se pretende com o produto que estamos a desenvolver; perceber as necessidades dos potenciais clientes e a partir dai pensar no que pode mesmo ser o seu MVP e não a versão 1.0 ou versão beta. Vejamos os exemplos abaixo.

 

Exemplo 1 – DropBox

O exemplo da DropBox é flagrante e paradigmático de que para se desenvolver um MVP não é preciso desenvolver features para um produto. No caso da DropBox o seu MVP foi um video onde se apresentava aquilo que seria o produto e era disponibilizado um endereço de e-mail para as pessoas se inscreverem. A lista de espera beta para o serviço saltou de 5.000 para 75.000 potenciais utilizadores quase da noite para o dia.

Veja o video do MVP da Dropbox

 

Exemplo 2 – Amazon

Outro exemplo interessante é o da Amazon. O MVP da Amazon baseou-se numa abordagem simples de desenvolvimento de um aplicativo com um back-end manual que os utilizadores não conhecem.

E mais, era o próprio Jeff Bezos a comprar os livros nas livrarias e despachá-los para os clientes pelo correio.

Foi uma abordagem inicial de baixo custo, como se pretende num MVP, mas funcionou. Em dois meses, a Amazon estava a ganhar perto de US$ 20.000 / semana.

 

Exemplo 3 – Instacart

O exemplo da Instacart é muito semelhante ao exemplo da Amazon.

O seu fundador teve a brilhante ideia de desenvolver um serviço móvel de entregas ao domicílio de supermercado. No entanto, na época, ele não tinha recursos para construir o extenso e complexo back-end do aplicativo.

A solução (MVP) foi o de criar, tal como a Amazon, um back-end manual, ou seja, sempre que uma pessoa encomendava algo do Instacart MVP, os fundadores tinham que comprar esses produtos e entregá-los aos clientes. Tudo manualmente.

MVP vs Versão 1.0 ou Versão beta

As diferenças entre um MVP e uma versão 1.0 ou versão beta de um produto está na sua definição, nomeadamente nos pontos:

  • “aprendizagem validada sobre os consumidores”
  • “Mínimo esforço possível”

Ou seja, a versão 1.0 ou versão beta de um produto pressupõe um lançamento. E havendo um lançamento, logicamente há ou terá de haver bastante esforço envolvido. Por outro lado, ao lançarmos uma versão 1.0 ou beta, em princípio, estamos cientes já daquilo que iremos lançar e o nosso propósito não é o de recolher findings e insights, ou seja termos uma aprendizagem validada por parte dos consumidores. Não que eles não nos possam dar feedback, mas esse feedback não fará parte do ciclo de iterações que um MVP terá. À partida, uma versão 1.0 de um produto já passou por ser um MVP. Mas um MVP não passa por ser uma versão 1.0 ou beta do produto. A não ser que o que esteja em causa na definição dessa versão 1.0 ou versão beta é a definição correta do MVP.

 

Mas Como nos focamos em Entregar um MVP na Realidade

O foco das empresas e das equipas em entregar um MVP depende primeiramente na correta compreensão do que é um MVP como visto acima. E tudo isto tem a ver com a cultura. Se a empresa tiver uma forte cultura de research e é madura o suficiente em termos de UX, o foco no que é na realidade um MVP torna-se fácil.

Por outro lado, se a cultura é a do “agile” de sprints a cada 2 semanas, entregar depressa e dentro destes prazos de forma inflexível e sem recorrer a várias iterações em cada ciclo de entrega, então o foco é a entrega de features em detrimento de entrega de outcomes que tem pro base o MVP definido à priori.

 

Conclusão

Antes de chegarmos a alguma conclusão sobre o que é definitivamente um MVP na prática, convêm perceber porque razão as empresas desenvolvem produtos ou serviços.

Eu diria que existem 2 tipos de razões. Um primeiro tipo de razões são aquelas em que o foco está no Outcome proporcionado. E um segundo tipo de razões são aquelas em que o foco está no output. Vejamos cada uma dessas razões:

Razões para desenvolver produtos/serviços em que as empresas estão focadas no Outcome

  • Provocar uma mudança no mundo e/ou nos comportamento do cliente que torne a sua vida melhor, mais fácil e vice-versa.
  • Surpreender e/ou Deliciar os clientes (relacionada com a primeira razão)

Razões para desenvolver produtos/serviços em que as empresas estão focadas no Output

  • Atrair cada vez mais clientes
  • Gerar mais receitas (relacionada com a primeira razão)

Desenvolver um determinado produto com uma série de features (mínimas ou que achamos mínimas), pode não ser o nosso MVP e, consequentemente, podemos não estar a entregar valor aos clientes, e não entregamos valor ao nosso negócio. Mas acima de tudo, não conseguimos iterar com os clientes de forma ideal para que possamos realmente apresentarmos um produto que seja “valioso” para os clientes e nos traga valor para o negócio. Isto porque não temos as iterações suficientes em termos de research.

 

Want to read this article in English? Please click here

by João Carlos Matos

Outcomes-over-Outputs---Key-points-da-Leitura-do-Livro-de-Joshua-Seiden

Outcomes over Outputs - Key points da Leitura do Livro de Joshua Seiden

Introdução

Recentemente, tive a oportunidade de ler o livro “Outcomes over Output” de Joshua Seiden. Trata-se de um livro técnico, mas de leitura acessível e agradável. Para os verdadeiros amantes da leitura, é possível concluí-lo em apenas 40 minutos. É um livro que todos aqueles que trabalham na área de gestão, especialmente em responsabilidades relacionadas à Experiência do Usuário (UX), Experiência do Cliente (CX), Pesquisa, Proprietários de Produtos e Profissionais de Marketing Digital, devem adquirir, ler e implementar nas empresas em que atuam.

Apresento aquilo que foi a meu entendimento dos Key Points do livro com algumas anotações a azul que julgo ajudarem a compreender, na minha perspetiva, aquilo que é a ideia do livro.

Podem encontrar o livro na Amazon.

 

Key Points da Leitura do Livro Outcomes Over Output

1. Outcomes podem ser definidos como mudanças no mundo que melhoram, simplificam ou facilitam a vida das pessoas. De acordo com a definição de Joshua, são mudanças no comportamento das pessoas que geram valor para o negócio. Em minha opinião, essa definição implica que tornar a vida das pessoas mais fácil resultará em mudanças em seu comportamento, inclusive emocionalmente, o que, por sua vez, gerará valor tanto para elas quanto para o negócio.

2. Existem três abordagens para a gestão de equipas: a gestão baseada em Outputs, em que todo o trabalho se concentra em funcionalidades (nesse caso, o trabalho de pesquisa geralmente é praticamente inexistente); a gestão baseada no Impacto, que estabelece um objetivo de alto nível, muitas vezes abstrato e que as equipes operacionais não compreendem completamente, como o crescimento do produto; por fim, a gestão baseada em Outcomes, em que a equipa se pergunta que mudanças no mundo ou no comportamento das pessoas podem criar para tornar suas vidas mais fáceis, gerando assim valor para o negócio.

 

3. Para realmente entender se nosso trabalho está a causar uma mudança no comportamento das pessoas, tornando as suas vidas melhores, mais fáceis e/ou mais simples, devemos criar checkpoints que sejam curtos, mensuráveis e relacionados ao trabalho que estamos a realizar.

Em UX, chamamos isso de UX Progessive Metrics, que se baseiam no Outcome = UX Success Metrics.

 

4. Pensar em Outcomes coloca efetivamente as pessoas no centro e torna as empresas verdadeiramente orientadas para o cliente – Customer Centric.

Infelizmente, na maioria dos casos em Portugal, esse jargão é usado, mas na prática o que está no centro é o negócio e as funcionalidades, e uma das razões para isso é a falta de trabalho estratégico de pesquisa. Adotar a metodologia de estabelecimento de objetivos por meio de OKR (Objectives and Key Results) facilita esse trabalho e alinha todas as equipes e direções da empresa.

 

5. O MVP (Produto Mínimo Viável) não é apenas a versão 1.0 do produto, mas sim uma experiência que representa a menor ou mais simples “coisa” que podemos e devemos fazer para testar as hipóteses iniciais.

 

6. Independentemente de realizarmos o trabalho de UX Research junto dos clientes, precisamos responder às seguintes perguntas para criar Outcomes eficazes: 1 – Que mudança no mundo (incluindo o comportamento das pessoas) devemos criar para tornar suas vidas melhores, mais fáceis, mais simples e proporcionar valor a elas, gerando valor para o negócio? 2 – O que podemos ou devemos fazer para que as pessoas percebam e adotem essa mudança? 3 – Como iremos medir nosso trabalho para avaliar se estamos no caminho certo?

Lembrem-se das UX Progressive Metrics, aquelas métricas que nos ajudam a monitorar o progresso ao longo do tempo.

 

7. Uma vez definidos os Outcomes, é crucial adotar uma abordagem iterativa de aprendizado, que envolve três etapas principais: pesquisa, criação de experiências e medição dos Outcomes.

Se repararem o descrito pelo Joshua no seu livro nada mais é do que: Definir o problema; definir hipóteses de como resolvê-lo – How Might We. E por fim, perceber se estamos no caminho certo: Are we solving people’s problems? Ou seja, Are We developing the right thing?

 

Definir o Problema com base em UX Research: É fundamental realizar pesquisas contínuas para compreender as necessidades, desejos e dores dos utilizadores. Este trabalho de UX research pode incluir métodos qualitativos, como entrevistas e observação, e métodos quantitativos, como análise de dados e testes A/B.

How Might We com base na Criação de Experiências/Hipótrses: Com base nas descobertas iniciais, devemos gerar hipóteses e ideias para resolver os problemas dos utilizadores. Utilizando a técnica “How Might We”, podemos definir hipóteses claras sobre como resolver esses problemas e criar experiências relevantes.

Are We Developing the right Thing – Medição de Outcomes: É crucial medir os resultados das experiências criadas para verificar se estamos resolvendo efetivamente os problemas dos utilizadores. Devemos perguntar-nos constantemente: “Estamos a resolver os problemas das pessoas? Estamos a desenvolver a coisa certa?”

 

8. Diferentemente dos roadmaps baseados em funcionalidades, os roadmaps centrados em Outcomes tornam o trabalho mais ágil e as equipes mais informadas e focadas. Em vez de simplesmente adivinhar quais funcionalidades devem ser desenvolvidas, baseamos nossas decisões em pesquisas e evidências.

 

9. Todo esse trabalho parte da compreensão da jornada do cliente, também conhecida como Experiência As-Is. Ao entender a jornada atual do cliente, podemos ter uma percepção clara de como será a experiência futura e a visão de negócio.

 

10. Isto porque obriga-nos a responder a questões vindas do Research e não partimos do “guessing” que desenvolver a feature A ou B vai ser estupendo, porque é digital e, portanto é melhor e porque a concorrência também tem.

 

Conclusão

No campo da Experiência do Cliente – CX, a perspectiva compartilhada por Joshua Seiden no livro “Outcomes over Output” traz insights valiosos para o trabalho das equipas envolvidas em projetos desse tipo. Acredito firmemente que essa abordagem será altamente produtiva, pois concentra-se em proporcionar valor para o cliente, o que, por sua vez, resultará em benefícios significativos para o negócio, a curto, médio e longo prazo.

 

Proporcionando Valor para o Cliente – Outcomes e não Outputs

Quando nos dedicamos a criar Outcomes que ofereçam valor real aos clientes, estamos construindo uma base sólida para o sucesso do negócio. Ao pensar estrategicamente sobre como podemos melhorar a vida das pessoas, tornando-a mais fácil, mais simples e mais satisfatória, estamos investindo na criação de relações duradouras e gerando valor sustentável.

Por outro lado, quando colocamos o foco apenas no valor para o negócio, concentrando-nos em outputs ou impactos, nem sempre conseguimos traduzir esse valor para o cliente de forma direta e eficaz. Podemos observar isso em setores como o de telecomunicações, em que, por exemplo, somos “fidelizados” por um contrato de dois anos, mas acabamos pagando mais mensalmente. Essa situação claramente beneficia o negócio, mas não agrega valor real ao cliente. Além disso, pode resultar em um mercado com pouca concorrência, prejudicando a inovação e a oferta de alternativas melhores.

 

A Importância dos Outcomes

Ao adotar uma abordagem centrada em Outcomes, colocamos o cliente no centro de nossas ações e decisões. Ao proporcionar valor para o cliente, estamos investindo em sua satisfação e fidelidade, o que se reflete diretamente nos resultados do negócio. Afinal, clientes satisfeitos são mais propensos a recomendar produtos ou serviços, gerando um impacto positivo no crescimento e na reputação da empresa.

Acredito firmemente na abordagem proposta por Joshua Seiden, em que o foco nos Outcomes é fundamental para o sucesso de projetos de UX. Ao proporcionar valor real para o cliente, estabelecemos uma base sólida para o crescimento e a rentabilidade do negócio. Portanto, devemos sempre buscar soluções que tornem a vida das pessoas melhor, mais fácil e mais simples, promovendo uma relação de confiança e benefícios mútuos a longo prazo. Lembremo-nos de que o verdadeiro sucesso empresarial está intrinsecamente ligado ao sucesso e à satisfação dos clientes.

 

Want to read this article in English? Please click here

by João Carlos Matos

O-Maior-Problema-que os-Profissionais-de-UX-Research-devem-Resolver-Junto-das-Organizações-Serem-Estratégicos

O Maior Problema que os Profissionais de UX Research devem Resolver Junto das Organizações - Ser Estratégico

Introdução

Definindo Estratégia, de uma forma descomplicada, é um plano de alto nível, tipo “Eagles Eyes”  que nos permite atingir determinados objetivos.

As organizações precisam de definir uma estratégia comum a todas a pessoas de todas as direções para que haja um conhecimento claro e comum de quais os objetivos a atingir.

Obviamente que as Organizações terão em cada direção uma estratégia diferente. Por exemplos, a Direção de Vendas pode ter como estratégia aumentar o volume de vendas do produto A; ou aumentar a penetração no mercado e a frequência de compra do serviço B.

A Direção de Marketing pode ter como estratégia aumentar o awareness de um produto; ou aumentar o volume de leads para o HubSpot.

Mas o que é que os profissionais de UX têm a ver com as estratégias dos diferentes direções das Empresas, perguntam? É que se os profissionais de UX, nomeadamente os UX researchers não conhecerem e/ou não forem envolvidos nessas estratégias, não poderão ajudar as diferentes direções a atingir os objetivos globais da Organização. E isso faz com que percamos o nosso espaço dentro da Organização, uma vez que não demonstramos e/ou o C-Level não entendem o valor que o nosso trabalho aporta Organização. E não é pouco!

 

Os Objetivos Globais das Organizações

isso faz com que percamos o nosso espaço dentro da Organização, uma vez que não demonstramos e/ou o C-Level não entendem o valor que o nosso trabalho aporta Organização. E não é pouco!

Todos os objetivos, prioridades, estratégias, vão afetar a experiência de cliente e portanto os profissionais de UX têm tudo a ver com isto 🙂 e, consequentemente, os profissionais de UX devem ser envolvidos no delineamento dos objetivos, prioridades e estratégias desde o momento zero.

 

A Importância do Trabalho dos Profissionais de UX nas Organizações

Atualmente, ou melhor dizendo, na maioria das Organizações o trabalho dos Profissionais de UX é um trabalho tático e não estratégico. E sendo visto como tático, somos vistos apenas como basicamente corresponde apenas a atividades quotidianas que fazemos no dia-a-dia: os famosos “deliverables” (wireframes, protótipos LOFI/HIFI, customer journeys…). Ou seja, podemos estar na Empresa A, a trabalhar o produto B que somos vistos da mesma forma, já que os deliverables são os mesmos, independentemente de Empresa ou do Produto.

Como visto acima, a Estratégia é um plano “Eagles Eyes” que traçamos para atingir os objetivos pretendidos. E para que isso aconteça, é preciso termos o maior e melhor conhecimento possível da situação interna e externa da Organização, porque é a esse plano (estratégia) que vai determinar como a Organização vai cumprir os objetivos. Portanto, a estratégia foca-se mais nos objetivos, prioridades, e nos recursos e skills necessárias para que o objetivo sejam cumpridos.

Então é fácil perceber o hiato que existe entre UX tático e UX estratégico. É que se os profissionais de UX não forem envolvidos no delineamento dos objetivos, priorização dos trabalhos e alocação de recursos e skills tudo isso vai influenciar a experiência final do cliente com a nossa Organização/Produto. Por exemplo, se priorizarmos algo que não traz valor para o cliente, se almoçarmos profissionais sem as skills certas ou mais desenvolvidas para a execução do trabalho. Tudo o que é estratégico vai influenciar a experiência de cliente.

Então, mas como é que o trabalho dos profissionais de UX pode influenciar o plano estratégico das Organizações? A questão é que o trabalho dos profissionais de UX como é visto pela maioria das Organizações é num trabalho que emerge das estratégia (como já visto) e portanto, não pode influenciar. Engano! Pode e deve influenciar através das atividades de UX Research que essas sim, podem e devem alimentar a estratégia das Organizações. Ou seja, deixamos de estar a adivinhar o que os clientes querem ou que os stakeholders querem. Isto é a mudança de Paradigma para as Organizações: o trabalho dos profissionais de UX está a montante (Research) e a jusante (Nova Experiência de cliente) da Estratégia das Organizações.

As Organizações focam-se nos Outputs e não nos Outcomes (próximo artigo que publicarei).

 

Os Diferentes Níveis de Maturidade de UX Research das Organizações

Já vimos a importância que as atividades de UX Research têm na prossecução da estratégia das Organizações. Mas será que as Organizações estão preparadas para isso? Diria que não, ou que estando preparadas não fazem uso dessa preparação/maturidade de UX Research.

Tudo se resume a:

1 – Definimos corretamente o problema que temos em mãos? Sim /(Não)

2 – E compreendemos bem esse problema para definirmos bem o que temos de desenhar/desenvolver? Sim /(Não)

3 – E desenhamos/desenvolvemos bem o que tínhamos a desenvolver? Sim /(Não)

E isto torna-se algo interativo e em loop de forma a que a experiência de cliente se torne melhor e produza valor para o negócio.

 

É neste trabalho de UX Research que o trabalho dos profissionais de UX se torna estratégico, mas por norma as Organizações ficam nos entregáveis de um “design melhor”. Os níveis de maturidade de UX Research nas Organizações são diferentes, ora vejamos:

  • Estádio 0 – Inexistência de Atividades de UX Research
  • Estádio 1 – Testes de Usabilidade básicos e Ad-Hoc > Testes de Usabilidade com base em criação de atividades da “nossa cabeça”
  • Estádio 2 Testes de Usabilidade intermédios > Testes de Usabilidade com base em criação de atividades com base naquilo que são os findings da área de suporte ao cliente
  • Estádio 3 Testes de Usabilidade Avançados > Testes de Usabilidade com base em criação de atividades já com base nalgumas atividades de UX research com clientes (entrevistas) ou seja, pode até ja ter havido alterações ao protótipo)
  • Estádio 4 UX Research de Campo Básico> Presença esporádica nos ambientes em que vivem os clientes no sentido de adquirir conhecimentos sobre a utilização que os mesmos dão ao produto/serviço. Há pouca ou nenhuma interação com os clientes e mais observação, ainda que esporádica
  • Estádio 5 – Research Focado no Campo > Teams seek out users and environments to fill in gaps in the team’s knowledge.
  • Estádio 6 – Estudos de Campo Longitudinais > As equipas conduzem atividades de research já com algum nível de profundidade sobre a vida dos clientes, seja antes, durante e depois da utilização do produto/serviço
  • Estádio 7 UX Research Estratégico > As atividades fazem parte da Organização/Projeto e em que realmente passamos tempo com os clientes em todas as fases da sua jornada e utilizando várias técnicas de UX Research para produzirmos findings e insights constantes e permanentes que alimentarão as atividades nossas e de outras direções da Organização

Adaptado do Modelo idealizado por Jared Spool

 

Conclusão

É fácil perceber que os profissionais de UX, sejam eles especialistas em Research, em Growth em Analytics (os de Research devem-no ser) ou tendo outra especialização, têm um papel preponderante na estratégia das Organizações e não devem ser vistos (e muitas vezes posicionam-se como tal) apenas como meros executores de wireframes, protótipos, user interfaces,…..As Organizações não se devem focar no “Construir Bem”a 100%, mas sim dar mais ou muito mais foco na “Definição correta do Problema”. Para que as Organizações (nomeadamente as presentes em Portugal) tenham cada vez mais sucesso precisam de ter maturidade no que ao estudo da envolvência e dos seus clientes diz respeito. Temos de melhorar a vida dos nossos clientes e o seu comportamento (estratégia) e não construir algo com base nas nossas necessidades e não das deles (tático). E acredito que isso seja um trabalho que deve ser mútuo e construído pelos profissionais e pelas Organizações.

 

Want to read this article in English? Please click here

by João Carlos Matos

O que a Medicina Ensina aos Profissionais de UX - Outcomes e Outputs, Empatia, Análise Quantitativa e Quantitativa e Systems Thinking

O que a Medicina Ensina aos Profissionais de UX - Outcomes e Outputs, Empatia, Análise Quantitativa e Quantitativa e Systems Thinking

Introdução

O último mês de Março não tem sido fáceis e por essa razão não ter publicado artigos no mês de Março em joaomatosdigital.pt/blog e/ou no Medium Bootcamp. E a razão pela qual Março não me permitiu publicar artigos sobre temáticas de UX, UI, Analytics e outros temas do digital foi porque tive internado após ter sido submetido a uma grande cirurgia. E isso fez-me refletir sobre o que a Medicina tem para ensinar aos líderes e gestores de equipas de UX. E é isso que pretendo com este artigo demonstrar.

 

1 – Outcomes

Na Medicina: Quando agendamos uma consulta médica é porque há algo na nossa saúde que nos preocupa, que julgamos não estar bem, ou que julgamos poderia estar melhor. Por outro lado, podemos também agendar uma consulta médica porque é a “altura” do ano em que é suposto ir fazer o check-up anual. – UX Research

O médico recebe-nos no seu consultório, clínica ou hospital e em primeiro lugar ouve aquilo que nós temos para lhe dizer. Podemos ter queixas sobre determinado sintoma (dor, febre, tensão alta, um novo nódulo, perda de apetite,….). Também podemos ter ou não queixas, mas é visível que não estamos bem (um braço partido, uma entorse no tornozelo, ume ferida…..). E por último podemos queixar-nos sobre outras preocupações que de certa maneira influenciam o estado da nossa saúde no momento atual ou num momento futuro. – Em atividades de UX, podemos considerar este ponto como as atividades de UX Research e são essas atividades que nos v\ao dar a confiança suficiente para argumentar com Product Owners e outros stakeholders que devemos prioritizar a atividade X, em vez da atividade Y, com base, claro, numa matriz de esforço e impacto.

Com estes findings que o paciente transmite ao seu médico e este ouve-os com muita atenção e cuidado, na cabeça no médico começam a surgir insights sobre o que possa ser a patologia associada aqueles sintomas. Para além de começarem a surgir esses insights na cabeça do médico, o mesmo (se for mesmo um bom médico) começa a pensar no possível outcome que será o mesmo outcome que em UX nós deveremos pensar em primeiro lugar e que se pode resumir à seguinte frase: “Se eu fizer um excelente trabalho a diagnosticar e a examinar o problema desta pessoa como é que isso irá melhorar a vida dessa pessoa”

**

Em UX: Como visto acima, a definição de Outcomes em UX, tem um processo muito idêntico aquele que acontece no mundo da medicina. Ou seja, enquanto profissionais de UX devemos pensar sempre em primeiro lugar no Outcome: “Se fizermos um fantástico trabalho neste projeto como vamos melhorar a vida das pessoas que vão utilizá-lo?”

E não podemos assumir logo à partida que a melhoria da vida das pessoas que vão utilizar o que sair desse projeto (outputs) é um novo website, ou uma nova aplicação, ou a feature A, B ou C, ou uma reescrita do conteúdo… Isso faz parte já da solução e, primeiramente temos que nos focar no problema/diagnóstico, tal como os bons profissionais de medicina fazem.

Se nos focarmos logo nos outputs e naquilo que serão os entregáveis, como acontece na grande maioria das empresas seja no mundo ou em Portugal, corremos o sério risco de estarmos a propor uma solução (em medicina seria a cura ou a manutenção controlada da doença) que não serve os propósitos dessa pessoa e que, portanto não melhora a vida da pessoa.

Por último, os outputs variam de empresa para empresa, de produto para produto. Isto porque a experiência de cliente é diferente em qualquer empresa. E tal acontece com os outcomes em medicina. São obrigatoriamente diferentes de pessoa/paciente para pessoa/paciente. Isto porque as pessoas são todas diferentes, seja pela idade, peso, altura, pela forma de reagir aos diagnósticos, devido à sua situação familiar, pessoa profissional…..

 

2 – Outputs

Na Medicina: Os outputs em medicina é aquilo que o médico prescreve ao seu paciente, mas com base naquilo que são os findings que recebeu, dos insights que formulou e da resposta à pergunta:  “Se eu fizer um excelente trabalho a diagnosticar e a examinar o problema desta pessoa como é que isso irá melhorar a vida dessa pessoa”

São vários os outputs médicos: análises clínicas ao sangue ou à urina, exames de imagem evasivos e não evasivos, prescrição de medicação, tratamentos paliativos, internamentos, cirurgias (que por norma têm outros outputs associados….).

Mas o importante reter é que o médico não se foca nos outputs em primeiro lugar e nós enquanto profissionais de UX deveríamos fazer e/ou exigir fazer o mesmo

**

Em UX: Em UX os outputs são aquilo que entregamos e que tal como os outputs em medicina, são idênticos em qualquer projeto, isto porque são coisas concretas que entregamos com base naquilo que foi o nosso diagnóstico de UX research. Podem ser personas, mapas de empatia, jornadas de cliente, service blueprints, wireframes, arquiteturas de informação, protótipos LF ou HF,…

 

3 – Empatia

Na Medicina: A empatia é uma soft skill importantíssima e que todos os médicos deveriam ter e usá-la. É com base nessa empatia que os médicos conseguirão, da melhor forma possível, colocarem-se na pele da pessoa que têm à sua frente e com isso perceber: 1 – aquilo pelo que a pessoa está a passar; 2 – entender efetivamente qual será o outcome previsto; 3 – como devem transmitir as boas e as más notícias

**

Em UX: Em UX é igualzinho. Se partimos de um outcome e queremos perceber efetivamente como melhorar a vida da pessoa com o nosso projeto, temos de perceber em primeiro lugar, e muito bem, como é a vida dessa pessoa naquele momento. E assim, no final quando estivermos perto de atingir o outcome, vamos conseguir perceber se efetivamente melhoramos ou não a vida dessa pessoa.

 

4 – Análise Qualitativa

Na Medicina: certamente já repararam que os médicos não têm no seu consultório, seja privado ou no hospital seringas e agulhas ou máquinas de imagem que lhes permitam realizar análises quantitativas. Ou seja, análises com base em valores. E porquê? Bom, antes de responder a essa questão é preciso primeiro perceber o que significa fazer uma medição. Fazer uma medição nada mais é do que observar uma variação/mudança em algo que está à nossa volta. No caso da medicina, quando as pessoas vão à consulta e contam a sua história, como visto no ponto 1 – Outcomes, o médico consegue visualizar logo as mudanças que estão a acontecer: um sinal na pele que não existia, uma hemorragia nasal, ganho/perda de peso, dor nível 6 no local Y, ver mal, perda de apetite…Porém pode não ter dados suficientes para perceber o que se está a passar e nesse caso passará a fazer uma análise quantitativa que será sempre complementar ao observado em consulta. Não é à toa que chamamos “exames complementares de diagnóstico”

**

Em UX: Em UX é, novamente, igualzinho. Ao nos apaixonarmos pelo problema e por aquilo que as pessoas os têm para dizer, fazendo as entrevistas, os service safaris, as ações de shadowing, os dairy studies, e de forma mais rudimentar e menos madura, as surveys e questionários; estamos a observar aquilo que as pessoas dizem, pensam, sentem, fazem, as deixa motivas e que as deixa frustradas. E tal como o médico pode complementar a sua análise qualitativa com a análise quantitativa também nós profissionais de UX o podemos e, de certa forma, devemos fazê-lo. Como? Através de ferramentas analíticas que possam ser custodiadas aquilo que queremos medir ou confirmar naquilo que vimos e nos foi transmitido na análise qualitativa.

 

5. Análise Quantitativa

Na Medicina: De certa maneira já fui desvendando aquilo que será a análise quantitativa em termos médicos. Mas um pormenor interessante que serve também, tanto para a medicina, como para o campo da User Experience. E que é a escolha daquilo que queremos medir quantitativamente. Ou seja, eu posso ter a máquina A no laboratório do hospital que faz hemogramas só. Mas se o que o médico precisa de fazer são ionogramas ou doseamento de determinada medicação no sangue, vamos fazer um hemogramas porque é essa o aparelho laboratorial analítico que temos e com isso não chegarmos a nenhuma confirmação/conclusão? Ou vamos arranjar forma de efetivamente fazer o ionograma e o doseamento de determinada medicação no sangue, e para isso vamos recorrer a outro laboratório; comprar novos aparelhos…

**

Em UX: Novamente muito semelhante o processo de UX ao do da medicina e com a mesma salvaguarda. Vamos medir users, pageviews, time on site, bounce rate, porque são métricas que a ferramenta de Google Analytics nos dá de forma automática? Ou vamos configurar eventos custodiados para medir por exemplo o que se passa com o CTA de contactos; ou com o CTA de Compra? E como fazemos isso? Compramos novo software? Aprendemos a fazer essas customizações? Arranjamos um parceiro que nos oriente neste processo?

 

6. Systems Thinking

Na Medicina: Na medicina aprende-se algo como o corpo humano ser consituido por células que no seu conjunto darão origem a orgãos que formam sistemas: sistema urinário: rins, ureteres, bexiga, uretra; sistema cardiovascular: artérias, veias, sangue e coração e por ai fora.

Ora, em medicina deve-se olhar para um determinado diagnóstico de uma forma holística e não de forma singular. Isto porque muitas vezes um sintoma ou mesmo problema que acontece por exemplo na visão, pode ter origem no pâncreas e não nos olhos. Por exemplo, consequências da doença diabética.

Desde cedo e desde sempre que os médicos aprenderam a trabalhar e analisar os problemas em forma de systems thinking.

**

Em UX: Não é muito comum ver-se profissionais de UX pensarem em termos de Systems Thinking. Aliás, como temos visto anteriormente. Mas assim, como em medicina este pensamento é fundamental, também o é em UX. Temos de ser human-centered; pensar em todos os stakeholders, pensar em todos os parceiros, resolver problemas um passo de cada vez.

 

Conclusão

Tanto a medicina como a User Experience (que também deve ser tida em conta no meio médicos) tem imensas semelhanças naquilo que respeita ao modus operandi. No entanto, é algo que está muito mais enraizado no mundo médico do que no mundo empresarial, especialmente no mundo do user experience. Talvez porque os médicos sempre lidaram com pessoas, e a disciplina de UX se materialize no digital. Mas na realidade e no fundo tudo e todos nós trabalhamos em última instância, para pessoas. Não estamos sozinhos no mundo, embora sejamos indivíduos. E portanto o ponto é sempre: Se eu fizer um fantástico trabalho em A, B ou C como é que isso vai melhorar a vida das pessoas.

O próximo artigo que estou a pensar produzir tem a ver com “O Maior Problema que os Profissionais de UX tem de resolver. E não é desenhar um website ou uma app. Se tudo correr bem sairá em Maio. Fiquem atentos!

 

Want to read this article in English? Please click here

by João Carlos Matos

atividades de analytics para lanç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)Lanç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