A Importância do UX na Criação de Eventos para Analytics
Introdução
Antes de começarmos, vamos só recordar uma definição importante e que é a definição de “Analytics”. Analytics é algo que podemos obter através de scripts instalados no código fonte dos websites ou apps. Ou seja, na realidade (e sem muito rigor técnico) são métricas que o computador, através de alguma ferramenta, consegue recolher através desses scripts, em resposta à ação do utilizador num do web browser ou aplicativo móvel.
Desenvolvimento
Portanto, antes de mergulharmos na escolha da ferramenta de analytics e na implementação de eventos, seja via datalayer ou via DOM scrapping é fundamental reconhecer a importância do trabalho de UX e, mais especificamente, da criação de fluxos de tarefas do utilizador.
Trabalhar o UX, significa trabalhar estrategicamente a experiência holística do utilizador, incluindo entender toda a sua jornada desde o início (que pode não ser online) até ao alcançar dos seus objetivos (que pode também não ocorrer online). Como vimos na introdução, ao criarmos eventos “para analytics” estamos, essencialmente, a capturar dados sobre como os utilizadores interagem com o website ou app. E para capturar esses dados da forma mais simples possível (ou seja sem workarounds porque causa do legacy code) e, possivelmente, também de forma o mais precisa e significativa possível (tendo em conta as várias circunstâncias do mundo online, como é o caso da privacidade), é crucial compreender a jornada, para desenharmos o fluxo de interações do utilizador o mais simples possível.
Estes fluxos de utilizador fornecem uma estrutura clara para entender como os utilizadores navegam e interagem com o produto. Ao mapear esses fluxos, podemos identificar pontos de fricção, pontos de abandono e áreas de oportunidade para otimização. Isso traduz-se diretamente na criação de eventos relevantes para analytics. Ao entender os caminhos que os usuários percorrem, podemos identificar os eventos-chave que queremos rastrear para entender melhor o comportamento do utilizador e suas intenções.
Exemplo
Ao analisarmos um website de e-commerce, podemos identificar o fluxo de um utilizador desde a entrada no e-commerce até a conclusão de uma compra. Ao entender cada etapa desse fluxo, podemos identificar os eventos que indicam o seu “engajement”; como visualização de produtos, adição do produto ao carrinho, checkout e finalização da compra. Ao mapear estes eventos numa fase de planeamento da expirência, mais tarde, rastrear esses eventos, podemos obter insights valiosos sobre o desempenho do site, taxas de conversão, comportamento do usuário e muito mais.
Além disso, a criação de eventos com base nos fluxos de utilizador também nos permite personalizar e segmentar as análises. Podemos criar segmentos de utilizadores com base nos seus padrões de interação, o que nos permite entender melhor diferentes grupos e, se possível, adaptar nossa estratégia de marketing e produto de acordo.
Ao implementar esses eventos na datalayer do website e ao configurá-los corretamente no GA4 ou Adobe Analytics ou noutra ferramenta para o efeito, podemos identificar áreas de melhoria, testar hipóteses e iterar continuamente para aprimorar a experiência do utilizador.
Conclusão
Em suma, o UX desempenha um papel fundamental na criação de eventos para analytics, pois nos ajuda a entender a jornada do usuário e a identificar os eventos-chave que queremos rastrear. Ao mapear os fluxos de usuários e criar eventos relevantes, podemos obter insights valiosos que impulsionam o crescimento e o sucesso de nossos negócios online.
Podes saber mais no artigo abaixo:
Redesenho de Websites e integração com Digital Analytics
“Para Quem Não Sabe Para Onde Vai, Qualquer Caminho Serve” by Lewis Caroll
O redesenho (redesign) de websites e/ou de outros aplicativos digitais são acontecimentos comuns de ocorrerem nas organizações. Este tipo de trabalho pode ser algo pequeno e simples como a mudanças na navegação numa única página, até mudanças mais complexas que interferem tanto no front-end como no back-end.
Em qualquer dos casos, muitas organizações não contam com as equipas de Digital Analytics. E o resultado é escandaloso. O website e/ou os aplicativos são redesenhados, obrigando a novos desenvolvimentos, é colocado em produção, e muitas implementações ou todas as implementações feitas ao nível da implementação de eventos falha,….e de quem é a culpa? Do Digital analytics.
E o tema não deve, não tem e não pode ser ou continuar a ser assim nas empresas. Isto porque existem vários key-points que devem ser acautelados no desenvolvimento destes trabalhos. Aliás, as equipas que trabalham ou que fornecem metodologias de trabalho ágeis, deveriam ter pessoas competentes nestas matérias e não só “puros e duros” software developers.
Estabelecimento dos novos Objetivos de Medição
O “primeiro ato” que as equipas, seja o PO, o SM ou alguém do negócio deve ter em conta e levantar o tema junto da equipa de Digital Analytics é a indicação do que, em termos de features, se pretende medir e monitorizar. Sim, porque parte-se do princípio (ainda que a maioria das empresas e equipas não o façam dessa forma) que uma feature é resultante de um trabalho de UX-Research e vai responder a um outcome para melhorar a vida das pessoas. E esse outcome pode ser medido ou não. E mesmo sendo medido, pode sê-lo de outra forma que não através do Analytics.
Desenvolvimento de Planos de Medição e Guias de Implementação
Em seguida, e tendo em conta o que se pretende medir e como; objetivos e KPIs definidos, passa-se à fase de desenvolvimento dos planos de medição e dos guias de implementação correspondentes a esses objetivos e KPIs. Integrar os requisitos de medição e de tracking na fase de planeamento garante que os data touch points necessários serão capturados com precisão após a entrada em produção do novo website ou aplicativos.
Partilha de Protótipos Hi-Fi
A visualização e partilha dos protótipos Hi-Fi com as pessoas de Digital Analytics vai permitir aos mesmos visualizarem os diferentes fluxos dos utilizadores, identificarem pontos de fricção, data touch points, e perceber se os KPIs definidos inicialmente estão presentes naquilo que foi desenhado. Além disso, e se o protótipo estiver bem especificado, é possível contribuir também com insights sobre como medir melhor as interações do utilizador.
Especificações dos Protótipos
- HTML, CSS e JS – O esqueleto de um website é o HTML e o CSS e depois a inteligência do website vem através da implementação do JS. Se estes elementos forem completamente mexidos e alterados, tudo aquilo que havia sido implementado, muito provavelmente deixa de existir. Assim, é preciso garantir que se algum destes elementos forem alterados essas mesmas alterações tenham em consideração o que já está implementado. Além disso, é necessário estar tudo especificado por exemplo ao nível dos use cases de um cliente autenticado ou não. Ou o que acontece quando um utilizador clica no botão/CTA; para que página vai? Ou não vai para nenhuma página? Se existe a possibilidade de refresh da página e a informação mantêm-se armazenada. Que tipo de estilos vão ser aplicados, por causa dos CSS Selectors e da facilidade ou complexidade da sua utilização no caso de ser necessário implementar um trigger com base nos mesmos.
- DataLayer – Se a DataLayer for alterada ou não for considerada vai ser difícil implementar qualquer tipo de eventos via DataLayer. Relembrando que a implementação via DataLayer dos eventos é a forma mais eficaz e com menos riscos de “quebrar” a medição, que existe.
- Estrutura de URL – Os URLs devem ser especificados e, preferencialmente devem ser o mais “amigáveis” possíveis, ajudando também a performance do website ao nível do SEO. A estrutura deve ser clara o que vai garantir que todas as páginas e ações relevantes sejam capturadas na configuração dos eventos. Criação de Single Page Applications – SPA – é uma complicação para implementar. Ou até mesmo a utilização dos iframes (completamente em desuso).
Estruturas de URLs mal especificadas e, posteriormente, mal configurada podem levar a discrepâncias nos relatórios. - Implementação dos Eventos e Custom Dimensions
Além dos KPIs definidos inicialmente e, consequente e muito provavelmente, dos eventos a implementar, as equipas de digital analytics necessitam de ver especificado o tema das custom dimensions. Para acrescentá-las no UI do GA4. Por exemplo, por algum motivo válido o negócio pode querer saber a hora do login. Lembrando que o GA4 free permite apenas a categorização de 25 custom dimensions. - Ativação (ambiente de desenvolvimento e produção)
Isso proporcionará a oportunidade de revisar os dados coletados, identificar discrepâncias ou anomalias e refinar a implementação do rastreamento conforme necessário.
Ao integrar esses pontos ao processo de redesenho do site, podemos aproveitar a experiência de nosso Analista Digital para garantir que nossa configuração de rastreamento esteja alinhada com os objetivos do projeto, as necessidades do usuário e os requisitos de análise de dados.
Conclusão
As empresas muitas vezes descuram o tema do digital analytics quando estão a implementar de raiz websites ou aplicativos ou apps. E ainda mais vezes, esquecem este tema quando estão a fazer o redesenho das mesmas.
É importante sublinhar que a comunicação entre as equipas (e não uma pessoa) de desenvolvimento, design e analytics….e na altura atual até acrescentaria de data, é crucial para garantir o sucesso do projeto de redesenho.
Podem saber mais sobre estes temas nos seguintes artigos:
1 – >Checklist de Atividades de Analytics para (Re)Lançamento de um Website – 11 Atividades a Considerar – PARTE 3
2 – >Checklist de Atividades de SEO para (Re)Lançamento de um Website – 13 Atividades a Considerar – PARTE 2
3 – >Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website – 12 Atividades a Considerar – PARTE 1
Por fim, e acredito que este seja uma conclusão que todos que trabalhamos na área devamos ter é:
Medir apenas o que importa, e nunca medir tudo e mais alguma coisa, nomeadamente quando se utiliza ferramentas free.
Certificação PowerBi com Projeto Integrado
Parte do resultado do meu foco nos temas e no desenvolvimento de skills técnica de análise de dados.
Curso de Power BI Impressionador da Hashtag Treinamentos com projeto integrado e com mais de 110 horas.
Ementa para obtenção do Certificado:
1. Instruções Obrigatórias (Assista)
2. Introdução ao Power BI
3. Importação e Tratamento de Bases de Dados com PowerQuery
4. Relacionamentos
5. Funções DAX
6. Storytelling
7. Dashboard & Visualização de Dados
8. Checkpoint
9. Power BI Online
10. Exercícios de revisão
11. DAX Avançado
12. Conectando o Power BI com Bancos de Dados SQL e Introdução à linguagem SQL
Módulos opcionais (estou a fazê-los):
13. Biblioteca de Relatórios Impressionadores
14. Checkpoint 2
15. Introdução à Power Platform
16. Mentorias Tira Dúvidas Ao Vivo
17. Lives Dashboards
18. Certifcação Microsoft PL-300 (Antiga DA-100)
19. Lives Power Query & Linguagem M
20. Lives Power BI Online & Criação de Portfólio
21. Lives Modelagem de Dados
22. Lives DAX
23. Intensivão de Power BI – Edição 2.0
24. Intensivão de Power BI – Edição 3.0
25. Feedback Final
Para melhor visualização do dashboard aconselha-se a sua consulta em ambiente desktop
O que são Tabelas Facto e Tabelas Dimensão - Análise de Dados
Introdução
A distinção de dados dentro de Tabelas Facto e de dados dentro de Tabelas Dimensão, é especialmente importante quando falamos de estruturas de dados estruturais que se relacionam de alguma maneira.
Tabelas Facto
O nome da tabela diz tudo – Facto. Ou seja, as Tabelas Facto (fact_table ou fnomedatabela) contém as informações sobre todos os factos que aconteceram numa determinada instituição numa determinada data. Por exemplo, todas as informações de vendas, de devoluções, de ocorrências médicas, como uma cirurgia, etc.
As Tabelas Facto têm em cada uma das linhas toda a informação sobre esse mesmo facto.
Por exemplo, uma Tabela Facto Consulta Médica – pode ter informações sobre todas as consultas ocorridas num hospital, em linhas. Em coluna podemos ter as dimensões: ID da consulta, data da consulta, especialidade da consulta.
Já uma Tabela Facto de Vendas pode conter informações sobre todos os factos relativos a vendas e em que as dimensões em colunas podem ser: ID Venda, SKU, data da venda, quantidade vendida.
Tabelas Dimensão
As Tabelas Dimensão (dim_tables ou dnomedatabela) têm informação sobre as características, atributos, dimensões, que complementam a informação contida na Tabela Facto.
Por exemplo, para a Tabela Facto de Consulta Médica, poderemos ter, entre outras Tabelas Dimensão, uma tmedicos associada à Tabela Facto Consulta Médica em que os atributos poderiam ser: ID do Médico, nome do médico, especialidade do médico.
Já a Tabela Facto Vendas, poderá, entre outras, uma dprodutos contendo informações como: nome do produto, categoria do produto, cor do produto, tamanho do produto, preço do produto.
A Importância de ter Tabelas Facto e Tabelas Dimensão
Por três razões essenciais:
Por ser a forma mais eficiente de trabalhar com análise de dados, independentemente de utilizarmos o SQL, PowerBi ou outra ferramenta. Como as tabelas facto contêm todos os factos ocorridos numa determinada instituição num determinado período de tempo, elas vão ser tabelas com um volume de dados gigante, podendo ter centenas milhões de linhas, dependendo da Empresa e do evento a que essa tabela faz referência. Cada coluna a mais nestas tabelas, serão mais informações adicionadas e novas linhas a mais, o que deixará o arquivo mais pesado e mais lento.
Já as tabelas de dimensão são tabelas pequenas, e cada médico/medicação/paciente irá aparecer uma única vez.
Se tivéssemos estas informações médico/medicação/paciente na Tabela Facto, iríamos ter informações repetidas, sempre que esse paciente tivesse uma consulta
Por isso deixamos as tabelas dimensão como uma tabela de ‘cadastro’, auxiliar, para conseguir deixar os arquivos de SQL, PowerBI e de outro tipo muito mais leve e eficiente, sem
ficar com informação repetida desnecessariamente.
Exemplo em GA4
O exemplo que quero dar em termos de Tabela Facto e Tabela Dimensão para o Google Analytics 4 é muito simples. Até porque ainda não tive oportunidade de utilizar/trabalhar com o BigQuery para fazer análises simples e mais profundas.
Se souberem de bons cursos sobre este tema, deixem comentem o artigo.
Possível Tabela Facto
- Utilizadores
Possíveis Tabelas Dimensão
- Eventos
- Dispositivos
- Países
Espero que tenham gostado do artigo. A área de dados, nomeadamente a área de MarTech é uma área na qual me estou a debruçar devagarinho.
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:
- 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.
- 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.
- 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
- 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:
- 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.
- 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:
- As equipas devem ser multi-disiplinares e autónomas
- 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…
- 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.
- 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…
- 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.
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
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.
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.
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.