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.
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.