Oi! Escolha uma opção para entrar

Nunca postaremos nas suas redes sociais

Se preferir, entre com seu e-mail

Esqueceu sua senha?
Não tem conta? cadastre-se grátis

Preencha o formulário abaixo para finalizar seu cadastro:


O Paradoxo do Usuário Ativo em tempos de Customer Success

A orientação de uma das premissas de Customer Success  é encaminhar clientes high-tech a se virarem sozinhos em busca da solução. Quem paga pouco onera a empresa quando telefona ou pede ajuda.

Mas é bom os novíssimos “Customer Success Managers” estudarem artigos científicos como…

Ops, antes de tudo…

Alerta: as motivações deste artigo

Cohen acordou feliz hoje.

Reuniu-se minha chefe ontem à noite na Churrascaria Komka com as outras chefes de família (o judaísmo é um matriarcado; ninguém jamais ouviu falar de papa idish, mas mama idish ou idishe mame é lugar comum) e trouxe-me muitas balas de banana (não, não é simbólico de jeito algum).

O meu pensamento é: tudo por que a alimentei segunda-feira à noite com um baita strogonoff (receita da Dona Benta) e a surpreendi com ingressos para ver o Fantasma da Ópera em São Paulo.

Sovina, ela se recusa a pagar os extorsivos preços dos ingressos, mas pago o que for para deixá-la feliz.

Te agarra num texto beeem trabalhado.

Igual a genro que leva a sogra na rodoviária, estou bem feliz.

Cohen, volte ao tema…

O resumo apresentado por Jakob Nielsen em Paradox of the Active User esclarece o tema.

Saca abaixo uma tradução minha:

O “Paradoxo do Usuário Ativo” é um conceito introduzido por John M. Carroll e Mary Beth Rosson (então na IBM, agora na Penn State) para explicar uma observação comum em vários estudos de usuários feitos no IBM User Interface Institute no início da década de 80 (e mais tarde confirmado por muitos outros estudos, incluindo o meu):

Usuários nunca leem manuais; começam a usar o software rapidamente. Estão motivados para executar sua tarefa de forma imediata: não se importam com o sistema como tal e não querem gastar tempo se inteirando do mesmo ou participando de processos de aprendizado.

O “Paradoxo do Usuário Ativo” é um paradoxo porque os usuários economizariam tempo a longo prazo se dedicassem algum tempo preliminar para configurar o sistema e aprender mais sobre o mesmo.

Mas não é assim que as pessoas se comportam no mundo real. Então é preciso que os desenvolvedores projetem softwares não para um usuário racional, mas para as condutas praticadas pelos usuários reais.

O texto acima é de 1998 e o original de “Active User Paradox” trata-se de um capítulo no livro Interfacing Thought: Cognitive Aspects of Human-Computer Interaction publicado em 1997 por John M. Carroll and Mary Beth Rosson.

Mas é meu testemunho que se relaciona a uma reclamação frequente de todos os analistas de suporte nos meus cursos: os usuários não leem as orientações, não sabem usar a tecnologia disponibilizada e por isso “sobrecarregam” o Help Desk ou Service Desk com suas demandas.

Customer Success, aí vamos nós…

No artigo O livro Customer Success: uma hábil combinação de legos expliquei que uma das orientações dessa nova abordagem junto aos clientes ilustra que não se obtém mais lealdade através do relacionamento pessoal.

A ideia da Cauda Longa — muitos clientes pagando pouco é bom — vingou em nossa área também, não só na de livros.

Primeiro por que “muitos“ geralmente significa muito dinheiro entrando pingado. Segundo por que se um deles vai embora, o impacto no negócio é pequeno, diferente se o seu maior cliente lhe abandonasse.

Mas pra atender muitos é importante dirigi-los todos para o autosserviço. Caso contrário seria necessário mobilizar um exército de atendentes atrás das linhas de telefone ou chat.

E é aí que entra o paradoxo…

Esmiuçando o Paradoxo do Usuário Ativo

Como o Nielsen escreve na introdução deste artigo, as pessoas querem executar suas tarefas imediatamente. São medidas em termos de produção. Há pressão por resultados. Ou querem fazer as coisas logo de uma vez.

Pense na minha sogra de 80 anos que instalou o Uber no seu celular. Ela quer usar, chamar o carro. Não tenciona explorar todas as facilidades que o aplicativo oferece e, quem sabe, lhe trariam maiores proveitos no futuro (definir favoritos, por exemplo).

Daí que o paradoxo é formado por duas partes:

  1. Paradoxo da Motivação — usuário quer realizar logo seus deveres, mas se dedicasse um tempo ao aprendizado, claramente produziria muito mais. Mas não faz isso por sentir-se coagido a produzir.
  2. Paradoxo Cognitivo ou Viés da Assimilação — o usuário que já possui algum conhecimento (diferente do item acima) quer aplicá-lo em novas situações, o que pode acarretar problemas (“Era assim que eu fazia no Cabify, onde está a segunda tela de endereço?”). Isso acarreta problemas de aprendizagem, pois, de certa forma, está entrincheirado mentalmente em formas antigas de fazer (leia Einstellung – O gerente de suporte é um bocó, pois cria sua própria masmorra).

Os autores explicam que não se trata de uma interface para usuário (UI) malfeita.

Nem são defeitos de aprendizado a serem corrigidos.

São, na verdade, características fundamentais de aprendizagem.

OK, vamos nos aprofundar

Você que deseja a receita pronta para executar de uma vez a tarefa, faça o seguinte: visite o site da minha prima, Rita Lobo, a mais bem-sucedida da família e cata lá uma receita.

O resto do povo que deseja captar o que acontece com seus usuários para obter um resultado melhor, embarca na sequência do artigo (mas é grosso este Cohen, hein? kkk).

O seu usuário está a aprender — perceberam o uso de um gerúndio no formato português? — como operar a plataforma (tem até Word via browser, hein? — não entendo como o Chromebook não decolou).

Lê o manual (ou faq, ou vídeo). Olha para a tela do aplicativo. Tenta conectar os dois, integrar, interpretar. E como é habitual, acaba sofrendo — agora nosso gerúndio tradicional — duma paralisia conceitual. E até física.

Eu, por exemplo, morro de ódio com o aplicativo Itaú para desktop que é uma desgraça de entender.

Quem me dera ele licenciasse o do Banco do Brasil.

Epa, opa!

O Paradoxo da Produção

Como dito, o usuário precisa trabalhar. Fazer coisas. Produzir.

Não tem tempo pra ficar associando vídeo com plataforma e ainda por cima com suas tarefas do mundo real.

Nenhum de nossos usuários é esquizofrênico — acho — para ouvir uma vozinha sussurrando: “Faça assim, aperte ali e preencha lá.”

(OK, alguns são e outros, mesmo não penando deste transtorno mental, acabam acelerando o passo).

Acha um exagero isso?

Veja como os seus próprios técnicos de suporte são treinados. A maioria cai direto no ringue, sem um pingo de treinamento. Ou viram sombras de colega durante… Dois dias, haha.

Então constatamos novos usuários que nada conhecem e evitam a leitura ou o aprendizado. Por que como todo novato, quer mostrar serviço logo de uma vez. E atalha, arriscando opções e perdendo a oportunidade de conhecer e extrair mais da plataforma, software ou tecnologia. Eles manjam das tarefas do escritório ou da fábrica, por exemplo. E ficam impacientes, querendo fazer algo logo de uma vez.

E lidamos também com os usuários mais experientes que não desejam aprender mais. Seguem no já conhecido e não mudam seus hábitos. Perdem chances de aprimorar suas atividades (construírem uma macro no Excel ou descobrirem que existe um relatório que sintetiza tudo que desejam extrair através dos quatro outros que usam hoje).

Aqui vão sugestões dos autores para lidar com esse paradoxo (o da produção):

Gamification!

Não se chamava assim naquela época por que surgiu somente em 2010, mas… A ideia é promover recompensas intrínsecas, criar um ambiente que estimule curiosidade, fantasia e desafios.

Reduzir os riscos e efeitos duma mancada. Uma espécie de sandbox pras atividades de aprendizado do seu usuário.

Tornar o design do produto mais interessante, seguro para navegar e fácil de aprender, não esquecendo do impulso do usuário para produzir algo (por isso jamais deixe o design da interface nas mãos dos desenvolvedores! Não faça isso por que para eles tudo é fácil e óbvio de usar!).

O paradoxo da Assimilação

Quase tudo que você aprendeu ou produziu se baseia em conceitos que já aprendeu e foi alinhavando, associando e construindo novas ideias.

Tanto para usuários novatos quanto para os mais experientes, mas em diferentes graus, conhecimentos prévios podem atrapalhar o aprendizado.

Citei o caso de usuários de Cabify tentando usar o app do Uber e procurando a tela seguinte de endereço (ou onde está a tela que informa de onde estou partindo). Fui um deles, comecei primeiro pelo app espanhol.

O usuário deseja aproveitar o conhecimento prévio no uso de um novo produto. Se você é fornecedor de ERP, saca as dificuldades que usuários migrados de seus concorrentes enfrentam ao usar o seu e buscam aplicar os conhecimentos doutro nele.

Pior: o conhecimento anterior pode cegá-los para novas formas de fazer.

Por isso, em parte, um grande player do mercado nacional não quis comprar minha base instalada de clientes Fireman: o impacto, as comparações, as formas diferentes de fazer do seu produto com o meu antigo iriam gerar conflitos e dissabores (até por que o meu era bom pra caralho caramba) para assimilar (daí a expressão) uma nova forma de fazer.

Sugestões dos autores:

Avançar para a prática durante o estudo. Fuja da parte muito teórica: em vez de explicar as táticas que o time usará, ponha o time em campo e lá dentro explique como as coisas funcionarão.

Conclusões

Conclusões a que chegaram os autores:

Ao discutir o Paradoxo da Produção, sugerimos que uma solução poderia ser reduzir o viés de produção dos alunos, tornando o sistema mais intrinsecamente interessante. Mas não está claro que todos os sistemas possam ser apresentados dessa maneira e, mesmo que pudessem, não podemos ter certeza de que os efeitos de tal abordagem seriam uniformemente benéficos — os usuários podem muito bem ver o sistema não como um recurso útil, mas sim como um brinquedo para brincar de vez em quando.

As outras soluções têm seus próprios problemas: se tentamos contornar a motivação dos alunos para produzir em vez de aprender, reduzindo o custo do aprendizado — talvez através do bloqueio de erros e da descoberta orientada de uma funcionalidade — corremos o risco de tornar o aprendizado muito passivo ou de configurar as situações de aprendizagem que podem não ser transferidas para cenários de uso cotidiano.

E, finalmente, se aceitarmos o foco no trabalho dos alunos e tentar projetar sistemas e materiais de treinamento para aproveitá-los, corremos o risco de adivinhar metas inadequadas para os usuários ou depender de que os usuários estruturem seus próprios produtos. objetivos, uma tarefa para a qual eles podem estar mal preparados.

Complementoooooo!

Em 2006 dois pesquisadores David G. Novick e Karen Ward escreveram o artigo “Why don’t people read manual?“. Não é novidade para nós esta afirmação.

Contudo eles se dedicaram a saber o porquê isso acontece.

De certa forma corroboraram o artigo em questão (o Paradoxo dos Usuários Ativos). Nas suas conclusões evidenciaram que a maioria dos usuários não utiliza os manuais (leia orientações) impressos nem os on-line. Isso acontece por quê:

  1. Há um custo de tempo entre a) ler a documentação e b) arriscar na base da tentativa-e-erro resolver o problema.
  2. Profissionais ocupados não têm tempo para a) nem b) acima. Preferem encontrar fontes seguras de orientação que são… Ou colegas ou os profissionais de suporte técnico.

Opaaaaaaaaaaaaaaaa (novamente).

Quer dizer que esta turma não lerá as orientações on-line que com tanto carinho produzimos?

Diz meu amigo Giuliano da Mega Sistemas o contrário. Que depois que publicaram on-line sua mega base de conhecimento, ocorreu uma substancial redução no número dos chamados.

Questiono-me se foi por isso mesmo (disponibilizar a ferramenta) ou se casualmente existe uma correlação beirando a zero nesse caso.

Explico: descobriu-se que alunos com maior quantidade de televisores em casa saem-se melhor nos estudos.

Mas não por causa da quantidade de televisores, destaca-se!

Mas sim por que quem tem mais aparelhos, tem maior poder econômico resultante, na maioria das vezes, da dedicação dos pais por estudo.

Logo, às vezes, uma conclusão a que chegamos pode ser enganosa (até mesmo a que meu strogonoff tenha influenciado o fato de receber balinhas de banana da chefe, por exemplo).

Mais e mais…

Caramba, segue lendo? Esplêndido, este é um diferencial seu em relação à concorrência.

Leia isso também:

Lembretes

Fine.

Recorde-se:

  1. Curso de Gestão de Serviços de Help Desk e Service Desk comigo no final de outubro em Sampa.
  2. Obrigado a Antônio Coelho. Este artigo foi escrito sob musicalidade da sua playlist no Spotify: Best of Black Sabath. E claro, muito chimarrão.

Receba grátis as principais notícias do setor de TI

Newsletter por e-mail