Como usar o Canvas do Lean UX

A intenção desse artigo foi disponibilizar um material público sobre o assunto, que seja resumido, fácil de ler e em português brasileiro. Vou apresentar a dinâmica como é normalmente feita, combinado à minha experiência e vou comentar brevemente sobre alguns erros comuns e deixar sugestões.

Introdução

No universo corporativo, equipes buscam soluções eficazes e sustentáveis. Jeff Gothelf e Josh Seiden, autores do livro “Lean UX”, acreditam que a metodologia Lean UX é o caminho certo para desenvolver soluções digitais com forte foco em pesquisa e produto. Para isso, eles usam um canvas próprio como método de exploração sobre iniciativas.

O Canvas do Lean UX é uma ferramenta de colaboração que ajuda as equipes a construir um entendimento compartilhado sobre um problema. Funciona para diferentes tipos de projetos, desde ideias em estágio inicial até projetos de inovação e sustentação. É recomendado para problemas complexos, sem solução clara.

Esses exercícios devem ser realizados por toda uma equipe de trabalho. Isso inclui: designers, engenheiros, gestores de produto (PO/PM), pesquisadores, testadores (QA), operação.

O erro mais comum que vejo quando aplicando essa dinâmica é ignorar alguns perfis da equipe, sob julgamento de ser “coisa de produto” e não “coisa de engenharia e qualidade”. Isso é um tremendo erro. A presença de todos os perfis profissionais é de enorme importância para garantir clareza sobre as suposições feitas no exercício. A ausência de engenheiros, por exemplo, pode por todo um plano por agua a baixo por não ter uma leitura clara sobre viabilidade de uma solução.

Entendendo o Canvas do Lean UX

Versão original em: www.jeffgothelf.com/blog/leanuxcanvas-v2 — Versão traduzida disponível em: https://drive.google.com/file/d/1oCaw6JnSBZia64U-_eYNqTS7lvcWvw2Z

O quadro acima ilustra, ordenadamente, os passos que devem ser preenchidos em equipe durante a dinâmica do Canvas. Explico etapa por etapa, em poucos detalhes, a partir de um exemplo único.

As normas de conduta da dinâmica são:

Duração: a duração é flexível, especialistas recomendam que os exercícios devem ser conduzidos no tempo que a equipe acreditar necessário. Minha sugestão para iniciantes é de 8 horas úteis, de preferência dividido em duas sessões, para permitir que a equipe se familiarize com o processo e tenha tempo para descansar e refletir.

Quantidade de pessoas: o mais importante é combinar as capacidades de todos os papeis disponíveis. Sugiro de uma até três pessoas de cada papel.

Como conduzir a dinâmica: é importante ser compatível com a equipe envolvida. Para uma equipe experiente e propriamente engajada, discutir ponto a ponto sobre os tópicos do canvas deve ser suficiente. Para uma equipe mais inexperiente, a dinâmica 1, 2, 4, Todos é uma excelente opção, pois ela garante que todos da equipe participem do processo.

Presencial ou remoto: nada impede de ser remoto (até porque em muitos casos é o que pode ser feito), mas especialistas do Lean UX acreditam muito em presencialidade.

A frente, vamos olhar tópico a tópico e o que se espera da resposta de cada uma delas.

1) Problema do negócio

O primeiro passo é entender o cenário atual. Para isso, as equipes devem analisar o que está acontecendo agora, e não no como elas querem resolver.

É fundamental que a declaração do problema cumpra os seguintes requisitos:

1. Entendimento sobre o “como estamos”: Quais são os objetivos do negócio? Quais são as atividades atuais?
2. Qual é o problema e suas circunstâncias: Quais são os sintomas do problema? Quais são as causas do problema?
3. Qual o efeito se o problema persistir: Quais são as consequências do problema?
4. Um chamado para atuar no problema como um desafio

Em casos mais avançados (somente naqueles que fazem sentido) também se determina:

• As diretrizes de permissões e proibições para atuar no desafio: Quais são os recursos disponíveis? Quais são as restrições?
• Fornecer medidas de KPI ou outros indicadores que a empresa deseja ver no seu público-alvo

É sugerido que os stakeholders e/ou responsáveis sejam protagonistas nessa etapa e apresentem à todos o que aconteceu para estarem nessa situação.

Exemplo: Nosso [e-commerce de produtos tecnológicos disponível via web] foi criado para atingir [uma parcela de consumidores que estavam deixando de ir às lojas físicas]. Observamos [pelos canais de atendimento] que [os usuários pedem por um aplicativo para celular], já que [se sentem inseguros comprando pela internet]; o qual [se continuar assim, nossos clientes potencialmente vão deixar de comprar conosco pelo canal web].

Como podemos melhorar [o sentimento de insegurança dos usuários sobre comprar via web]?”

Perceba que está bem claro: contextualiza bem e não tem linguagem rebuscada. A etapa está concluída quando todos concordarem sobre a definição do problema.

Comentário rápido: nesse caso hipotético acima, muitos já assumiriam que a resposta óbvia seria de “fazer um aplicativo”; enquanto na realidade é justamente o contrário. Fazer um aplicativo é muito custoso e complexo. Usa-se de Canvas justamente para competir as respostas óbvias e nem sempre eficientes, e procurar as soluções não tão óbvias que sejam eficientes.

2) Resultados do negócio

O mínimo que se espera de resolver problemas é gerar resultados positivos. E para isso, é preciso determinar métricas que indicarão se tais problemas foram atuados de maneira eficiente. Essas métricas podem ser sobre receita, lucro, custo, aquisição, retenção, índice de satisfação, enfim, o que for compatível para seu negócio.

Todos os participantes devem por em mesa suas ideias e perspectivas sobre o tópico. Depois de validado em grupo aquilo que faz sentido ou não, concluir o pensamento e passar para a próxima etapa.

Exemplo: se [mitigarmos o sentimento de inseguranças dos usuários sobre comprar via web], deveríamos pelo menos [reter grande parte dos usuários] ou até [aumentar o número de usuários consumidores que podiam estar desistindo da compra no meio do processo].

Sugestão: se deseja se apoiar de métricas mais industrialmente estruturadas, especialmente focadas em jornada de usuário, sugiro métricas pirata.

3) Usuários

Nessa etapa, desenvolvemos o perfil dos usuários que consomem nosso produto ou serviço. E para isso, precisamos garantir que estamos falando sobre os mesmos usuários. Aqui também pode-se apoiar de métricas e estatísticas já existentes sobre quem consome seu produto e/ou reporta o problema.

Liste esse grupo de pessoas como personas: “Idosos”, “Universitários”, “Usuários web naturalizados”, “Baixa renda”. Não exagere, destaque até cinco perfis. Em seguida, garanta que essas personas consumam o seu produto e se elas sofrem do problema em questão.

Exemplo: baseado nas nossas métricas, os usuários que mais exclamam [insegurança sobre compras vias web] são [pessoas de 35 a 50 anos de idade]. Na análise de popularidade feita pela equipe de marketing anteriormente, foi percebido que [a maior população dos nossos clientes são profissionais de tecnologia]. Após validação dos dados durante a dinâmica, percebemos que as pessoas que exclamaram o sentimento de segurança são a parte dos usuários que [não são profissionais do setor de tecnologia].

Ou seja, concluímos que aqueles que sofrem do problema são [são pessoas não conhecidas sobre tecnologia], [entre os 35 e 50 anos]. Mas vale lembrar que a nossa solução deve levar em conta nossa maior base de usuários, que ainda são [profissionais do setor de tecnologia].

Uma vez concluído, ir para a próxima etapa.

4) Resultados e benefícios do usuário

Para todos os usuários, independente de estarem sofrendo do problema ou não, é importante entender o que eles esperam alcançar ao usar o produto ou serviço, e quais benefícios eles esperam obter.

• Por que os usuários consomem meu produto ou serviço?
• Como meu produto aproxima eles de um objetivo pessoal?
• Que mudança de comportamento é visível quando eles alcançam seu objetivo?

Exemplo: O usuário que [deseja comprar seus produtos tecnológicos] pelo nosso site, [compram a baixo preço] seguindo um fluxo de compra. Esse fluxo de compra permite que [ele compre sem a necessidade de autenticação], somente com dados identificação, entrega e pagamento.

Se formos analisar essa etapa do exemplo, podemos perceber uma oportunidade com o que foi apresentado. Atualmente, o nosso usuário não consegue se autenticar para fazer a compra, e isso pode ser um dos motivos para desconforto.

5) Soluções:

Depois do cumprimento dessas quatro primeiras etapas, a equipe tem uma visão ampla do problema e diferentes perspectivas sobre como resolvê-lo.

Agora a equipe precisa encontrar soluções que resolvam o problema e atendam às necessidades do cliente e da empresa. Essas soluções podem ser de alto nível, que definem os objetivos e os resultados esperados, ou de baixo nível, que especificam os passos e as tarefas necessárias para alcançar os resultados esperados. Vale lembrar que é importante considerar as capacidades da empresa e suas equipes para resolver o problema.

Essa etapa pode ser conduzida da mesma forma que já têm sido as outras etapas, mas também pode ser usada uma dinâmica específica, pela importância desse passo. Existem várias técnicas de brainstorming e trabalho colaborativo, como o “1, 2, 4, Todos” já mencionado.

Especialmente no Lean UX, se faz muito defesa do Método Design Studio, explicado por extenso no livro Design Studio Method: Creative Problem Solving with UX Sketching (um livro que infelizmente só tem em inglês). Mas não se preocupe, é uma metodologia complexa que requer dedicação significativa e uma equipe experiente, além de ser um exercício que demora muitas horas. Pode não ser a melhor opção para todos os contextos.

Exemplo: Depois de muita análise e discussões bem aprofundadas, foram prototipadas três possíveis soluções para resolver o problema.

1) Desenvolver um aplicativo mobile; uma vez que é o que nossos clientes pediram como condição de manter o relacionamento.
2) Repaginar a jornada de aquisição implementada no website; uma vez que, depois de analisar, perceberam há muitas oportunidades de melhorias na experiência que pudesse sinalizar insegurança.
3) Uma opção de jornada de consumo autenticada; alguns membros da equipe perceberam que os usuários podem estar resistentes ao nosso modelo de aquisição sem autentica-lo, diferente de alguns e-commerces que popularizaram no nicho, como Magazine Luiza e Kabum. Criar uma jornada alternativa que permita um comprador com preferência de queira garantir controle das operações feitas no nome dele parece uma boa sugestão.

Todos essas soluções convergem em oportunidades que buscam resolver o mesmo problema de maneiras diferentes. Cada solução tem suas próprias etapas e processos de execução e implementação.

Mas como saber qual delas está na direção certa? Ou se existe alguma que serve.

Até agora, o exercício se concentrou em entender o problema, alinhar resultados que fossem favoráveis tanto para os clientes quanto para o negócio, e encontrar soluções compatíveis.

Os próximos três passos são reservados para construir hipóteses que validem essas soluções, tratando risco, valor e viabilidade de cada uma delas, priorizando e conduzindo experimentos para descobrir qual o melhor caminho para resolver o problema.

6) Hipóteses

Hipóteses são afirmações que ainda não foram testadas. Cada hipótese feita pela dinâmica deve combinar das suposições previamente estabelecidas (vamos chama-las de evidências) à uma solução proposta.

Sugestão de sentença como modelo: Acreditamos que atingiremos [esse resultado de negócio] se [esses usuários] obtiverem [conjunto de benefícios e resultados pro usuário] com [essa solução].

Exemplo:
1) Acreditamos [reter grande parte dos usuários] e [aumentar o número de usuários consumidores que podiam estar desistindo da compra no meio do processo]
- se [todos]
- obtiverem [compras a baixo preço] e [mitigarmos o sentimento de inseguranças sobre comprar via web]
- com [desenvolver um aplicativo mobile].
2) Acreditamos [reter grande parte dos usuários] e [aumentar o número de usuários consumidores que podiam estar desistindo da compra no meio do processo]
- se [pessoas de 35 a 50 anos de idade] e [não profissionais do setor de tecnologia]
- obtiverem [compras a baixo preço], [mitigarmos o sentimento de insegurança sobre comprar via web] e [comprar sem a necessidade de autenticação]
- com [repaginação da jornada de aquisição implementada no website].
3) Acreditamos [reter grande parte dos usuários]
- se [todos]
- obtiverem [compras a baixo preço], [mitigarmos o sentimento de inseguranças sobre comprar via web]
- com [uma opção de jornada de consumo autenticada]

A próxima etapa é entender as hipóteses e prever os riscos.

7) Qual é a coisa mais importante que devemos aprender primeiro?

Em outras palavras: “O que é mais importante para aprender sobre cada hipótese?”. O grupo nesse momento deve formular suposições no formato de perguntas, que questiona detalhes da hipótese que podem levar à falha do plano.

Aqui é muito comum os membros de equipes multifuncionais defenderem suas próprias preocupações à detrimento de outros. É importante que todos mantenham o foco e leitura ampla sobre os fatores em discussão, para realmente atacar as suposições críticas.

Exemplo: Foi concluído pelo grupo que:
1) Por mais que uma pequena parte dos usuários tivessem pedido por um aplicativo mobile, não sabemos se o retorno cobre o investimento e operação de manter um novo produto em produção ao longo do tempo.
As perguntas sobre a hipótese foram: A grande maioria dos clientes gostariam mesmo de consumir por um app em vez de um site? Justifica o investimento do criar e manter o app? Temos capacity técnico para investir nesse plano? Se sim, prosseguir com pesquisas de mercado para assegurar o máximo possível, pois é um investimento alto. Se não, a hipótese morre dentro do escopo desse canvas.

2) Entendemos que a jornada atual de consumo no web há várias oportunidades de melhoria.
As perguntas sobre a hipótese foram: Como os clientes inseguros sobre a solução atual ficariam mais confortáveis usando nosso produto? Os usuários proficientes no nosso produto, eles ficariam confortáveis com uma nova proposta?

3) Criar uma jornada de consumo autenticada complementa o produto já existente sem gerar complicações pros consumidores já existentes, além de melhorar algumas vulnerabilidades.
As perguntas sobre a hipótese foram: Essa jornada alternativa e conjunto de funcionalidade acopladas seriam suficientes para resolver o sentimento de insegurança do publico afetado? Os demais clientes, receberiam bem uma nova opção de consumo assim?

8) Qual é o menor esforço que precisamos fazer para aprender a próxima coisa mais importante?

Em outras palavras: “Qual é o esforço mínimo que precisamos fazer para aprender com uma hipótese.”

Nesta etapa, a equipe deve desenvolver experimentos para validar as hipóteses. Os experimentos podem ser simples ou complexos, com público especificado ou abrangente. O objetivo é adquirir conhecimento e não desenvolver um produto final. A equipe também deve ser objetiva quando selecionar quais hipóteses atuar primeiro. Esses experimentos normalmente são aplicados em forma de MVPs e pesquisas.

Dica: A definição de MVP que estamos falando aqui é a mesma presente no livro The Lean Startup de Eric Ries. Significa “produtos mínimos viáveis”, cuja finalidade não é ser preguiçosa, mas objetiva e simplista. A explicação da página do wikipedia em inglês é excelente, use um tradutor que é sucesso.

Uma rotina iterativa e incremental surge com objetivo de esclarecer uma estratégia final e como atuar nela. Ao fim, a equipe pode partir para a construção de um plano final quando se sentir confortável com o conhecimento adquirido. Se a equipe por qualquer motivo entender que acabou o tempo mesmo sem ter a resposta, reunir uma última vez para decidir como concluir todo esse processo é inteligente.

Exemplo (caso positivo): Após conduzir alguns MVPs e pesquisas ao decorrer do mês seguinte, a equipe concluiu que fazer um app não era uma preferência entre a maioria dos usuários,

os clientes que se sentem inseguros sobre comprar pelo site eram por conta tanto da experiência quanto pela estrutura da jornada; alguns desses clientes tinham medo até por errar alguma informação dele mesmo, então gostava que suas informações ficassem salvas nos sistemas de e-commerce. Um dos MVPs apresentados para clientes desse perfil, teve uma recepção bem positiva, que combinada também da proposta de solução (3).

Acabou que ficou decidido combinar as soluções (2) e (3) e realizar um super incremento na jornada de checkout.

Exemplo (caso negativo): No fim, não foi concluído muito. Tanto as pesquisas quanto os MVPs não obtiveram resultados muito positivos ao decorrer do mês seguinte. A equipe se reuniu e concluíram que, já que não obtiveram sinais positivos sobre possíveis mudanças, manter a solução atual como está é uma melhor estratégia do que cometer uma mudança potencialmente prejudicial para o negócio.

Observações e outras opiniões:

• O canvas do Lean UX foi desenvolvido para atuar em sinergia com a metodologia Lean UX, mas os próprios mantenedores dizem que não há problema utilizar em outros contextos.
• Não fique desencorajado por não obter a velocidade ou performance que esperava. Toda técnica melhora com prática; e aqui não é diferente.
• O Lean UX defende risco como uma variável de maior peso que viabilidade. Eu discordo. Vejo viabilidade como o fator de maior peso entre os dois, afinal, não adianta nada montar um plano pouco arriscado mas que exija demais para execução. Mas também sou favorável em confiar em opinião especializada quando se trata de qualquer assunto.
• O Lean UX defende que as etapas de criação e validação de hipóteses são importantíssimas para desenvolver um produtos bem estruturados. Eu acredito no valor disso, mas é complicado conseguir tanto tempo e investimento para realizar as coisas nesse ritmo.

A apresentação sobre o Canvas do Lean UX feito aqui foi fortemente influenciado pelo livro do O’Reilly, Lean UX: Projetando Ótimos Produtos com Equipes Agile, combinado à minha experiência e outros materiais sobre agilidade.

Sugiro a leitura do livro para qualquer profissional que trabalha com desenvolvimento de produtos digitais mas sente que precisa do suporte de mais técnicas. Lean UX não é tão popular no Brasil mas tem seu público lá fora.

P.S.: não estou orgulhoso com a ortografia do material e devo revisar daqui um tempo. Me perdoe se doeu ler algumas coisas. Vou aproveitar o fim do ano para descansar e levar as coisas mais leve. Feliz natal e ano novo!