#REMOTOS Como adaptamos uma Design Sprint e Testes de usabilidade na Pandemia

Luis Carneiro Leão

Published in

sanar

16 min readJun 10, 2020

Video Sanar Webinar Tech, sobre essa história

É um desafio envolver times com backgrounds diferentes na estratégia de desenvolvimento do produto.

É preciso aproveitar essas diferenças e focar no problema pensando no que é melhor para os usuários e negócio.

Mas como facilitar a colaboração sem post-its e discussões olho a olho? Adaptamos uma design sprint 2.0 remotamente e vamos compartilhar como:

Definimos o problema;
Quais ferramentas nos ajudaram a facilitar remotamente;
Adaptamos a metodologia da design sprint;
Aprendizados e melhorias no processo;

Se você ainda acha que não vale a pena investir em discovery no desenvolvimento do seu produto, vou te contar a história de como facilitamos uma DESIGN SPRINT remotamente na Sanar.

Passamos uma semana corrida construindo um novo fluxo de cancelamento de assinatura no SanarFlix — SAAS de recorrência, há 2 anos revolucionando a educação médica no Brasil. Se você não conhece, pergunte a qualquer estudante de medicina ou à gente da Sanar. Vamos ter um prazer enorme de trocar ideia contigo! (Vagas Abertas).

Mas voltando à história: chegamos a refinar com o engenheiros e prototipar em alta. OK. Tudo certo para a próxima sprint do time de engenharia. Mas ainda estávamos inseguros sobre o formulário de cancelamento… Não tivemos tempo suficiente para testar, porque estávamos focando em entregar outros KR’s (Resultados-chave, vide “Measure What Matters”, John Doerr).

1. DISCOVERY NÃO SE PEDE, SE CONQUISTA.

Apesar da solução aparentemente não-efetiva, haviam informações! Abraçamos nossas análises de similares, dashboards sobre motivos de cancelamento, validação de protótipo com o time de Sucesso do Cliente, as copys funcionando no writing…

Nossa solução fazia sentido, mas não tínhamos testado ainda com usuários.

Ainda não havia noção clara dos riscos de implementação desse novo fluxo de cancelamento. Segunda-feira de manhã, nosso head do negócio, nos questionou sobre o cerne do problema:

“O fluxo criado pode funcionar para coletar informações sobre os motivos de cancelamento do usuário, mas ele não mostra o valor do nosso produto, nem oferece oportunidades que podem fazer o usuário mudar de ideia e não cancelar”.

Também levantou dúvidas sobre se os motivos que usuários marcavam atualmente, realmente correspondiam ao que eles escreviam nas respostas abertas. O novo fluxo poderia ser um investimento ruim: faltavam informações essenciais antes de implementarmos.

Choque de realidade: à tarde tínhamos planning (Ritual do Scrum) com os engenheiros e as histórias de usuário já estavam escritas. Se existia um problema, precisávamos investigar mais. Então fomos transparentes e compartilhamos com nosso head:

“Estávamos entregando outra parte importante do produto em paralelo, não tivemos tempo para testar durante a semana. Precisamos de mais tempo para avaliar riscos. Testar com usuários pode nos trazer respostas essenciais”.

Ele apoiou nossa decisão, e ficou à disposição para o que precisássemos para ter uma nova proposta.

Em produtos de recorrência, a churn é uma métrica tão importante quanto a aquisição de novos clientes. Do que adianta botar muita gente no produto, se as pessoas acabam cancelando as assinaturas? Equilíbrio é tudo.

2. SE SEU TIME MUDOU OS PLANOS, ACERTE COM QUEM DEPENDE DE VOCÊS.

Ganhamos tempo, mas ainda tínhamos planning à tarde. Naquela sprint priorizamos outras atividades com os engenheiros, e nosso gênio agilista arrasou refinando e adaptando as histórias a tempo para os engenheiros conseguirem trabalhar durante a quinzena, sem prejudicar o roadmap.

3. POR QUE DESIGN SPRINT?

BORA? Então bora! Vamos adaptar uma DESIGN SPRINT 2.0.

Mas remoto? Em tempos de pandemia do COVID19? Como?

Precisamos envolver os engenheiros: acabamos de formar novos squads e parecia o jeito mais rápido de focar numa solução de forma colaborativa.

O QUE É DESIGN SPRINT?

Metodologia criada pelo Google Ventures, indicada para:

Problemas de alto risco/ alto investimento;
Decisões rápidas;
Colaboração;
Alinhamento de visão;

O esquema ideal é em 5 dias, mas adaptamos:

Adaptando para 2 dias, focamos na IDEAÇÃO e PROTOTIPAÇÃO, sabendo qual era nosso problema, iríamos investir mais em dar contexto pro time, rabiscar soluções competitivas e testar um protótipo com usuários.

Expectativas para o fim do workshop:

Termos uma proposta de valor, representada por um protótipo;
Estruturarmos um roadmap para a construção iterativa deste produto;

4. Escolha bem seus Avengers!

Com pouco tempo disponível, selecionamos a equipe com pessoas que tivessem conhecimentos e contextos diferentes sobre o problema, e fossem agir nele no futuro próximo.

1 médico e coordenador pedagógico,
1 estudante de medicina e gestor de redes sociais,
3 engenheiros do Squad que iria trabalhar no desenvolvimento da solução,
1 Analista de Sucesso do Cliente e Copywriter,
1 Product Manager e 1 Product Owner donos do roadmap e backlog, respectivamente.

Nosso head estava como decider: com voto de minerva em caso de empates nas discussões, e consultor da estratégia de negócio da Sanar, como um todo.

Enquanto Product designer, estava como facilitador do workshop, e durante a preparação da design sprint, contei com a ajuda primordial do Analista de Sucesso do Cliente e do Product Manager. Tendo eles como especialistas, discutimos e analisamos quais seriam os dados essenciais de motivos de cancelamento e regras de negócio que iríamos reunir para dar o máximo de contexto do problema para o time.

5. MAS COMO? NO MIRO, CLARO!

Ferramentas para ajudar a fazer design sprints e testes remotamente.

Eu já estava doido para fazer remoto, vinha conversando com colegas designers de produto, sobre quais ferramentas estavam usando para ajudar a facilitar workshops e dinâmicas de colaboração em tempos de COVID19. Obrigado pela indicações, pessoal!

Essas são as principais ferramentas que acabamos usando na Sanar:

MIRO — Board da design sprint.

A maioria das etapas do workshop já estavam disponíveis lá, assim como muitas outras. Selecionei o que cabia para nossa adaptação, e traduzi as descrições das atividades do inglês para impulsionar o entendimento.

CALENDLY & Google Agenda — Recrutamento e Organizar tempo.

Usamos o link de agendamento para facilitar os estudantes de medicina marcarem um horário para os testes. Tivemos ajuda no recrutamento graças a equipe que cuida do time de Embaixadores e SC.

Google Apresentações — Guia de Informações & Storytelling.

Nem todos estavam acostumados a usar o Jira ou o Confluence. As principais informações sobre o problema, publico, estratégia e decisões, além do fluxo do que ia acontecer em cada etapa, estavam em simples slides acessíveis para todos desde antes da reunião, para compartilharmos o máximo de contexto.

Google Sheets — Classificar e gerenciar informações e hipóteses.

Planilhas compartilhadas podem levar seu time longe de forma simples. Falo mais adiante sobre, quando formos falar das hipóteses e testes.

LookBack ou Google Hangouts — Depois de pedir a autorização de quem será entrevistado, precisávamos gravar os testes para analisá-los depois.

O LookBack é uma ferramenta incrível para testes remotos e presenciais. Experimente no Trial e veja se vale a pena pro seu time — tem ferramentas como um link da entrevista ao vivo com chat, e edição e comentários sobre o que foi gravado.

*ATENÇÃO: A maioria das pessoas pode nunca ter feito videochamadas no LookBack, a internet estar ruim, e as coisas se complicarem. Isso chegou a acontecer com a gente em um dos testes. Por isso, também usamos o Google Hangouts, que além de mais comum, é mais fácil de usar pelos usuários, e também permite a gravação da chamada.

PROTOTIPAÇÃO — Testar em alta fidelidade.

Usamos o Adobe XD que tem animações automáticas bem funcionais nos fluxos, e já tínhamos muita coisa pronta para adaptar. Mas poderia ser feito no Figma, Sketch, InVision ou até no Wix se você não tiver um designer no time.

6 . CONHEÇA E APROVEITE O QUE VOCÊ JÁ TEM PRONTO.

Se seu time de design ainda não tem um Design System de ponta, conheça bem o que você tem de styleguides, protótipos, ícones, vetores, wireframes (…) disponíveis, e deixe-os acessíveis para a fase de prototipação em alta. O time pode ganhar muito tempo nessa fase se você já tiver alguns componentes prontos, e focar mais nas interações do fluxo e em copys efetivas.

7. PASSO A PASSO METODOLOGIAS — DIA 1

Intro

Objetivo aqui é dar contexto do porquê estamos fazendo a Design Sprint, contexto estratégico e de negócio do produto, e apresentações de 1 minuto em 360.

É esperado que cada participante…

Não cheque celular/email (apenas durante os intervalos);
Respeite o power vote (HEAD) em caso de empate;
Tenha a responsabilidade de trazer as suas perspectivas: não tenha medo de ser a voz divergente;
Se jogue em cada atividade…Confie no processo!
Use o Estacionamento de ideias;
Se divirta em ser um Designer por 2.5 dias;

AGENDA — Quais ferramentas usamos nessa adaptação?

DIA 1 — Mapear e Ideação

8:00–10:30

Intro — 5 min
Icebreaker — 10 min
Contexto de negócio — 10 min
Perguntas & Respostas — 10 min
HMW + Pergunte Especialista — 30 min
Organizar HMW — 30 min
Proto-Persona — 30 min
Demos Relâmpago — 15 min

10:30–12:30

Crazy 8s (2x) (30 min)
Storyboard sketching (30 min)
Silent Voting (15 min)
Justificativas + último voto (30 min)
Decisão do Protótipo

Problema

Na Design Sprint raiz, dedicamos parte do primeiro dia para definir o problema, a partir dos Objetivos de Longo Prazo e das Perguntas que a Sprint deve responder. Mas na nossa adaptação, seguimos um modelo que cabia no nosso planejamento.

Afinal, é um desafio saber quando e quais ferramentas de facilitação são dispensáveis ou não, para ter um melhor impacto na ideação.

Não necessariamente utilizar uma metodologia ao pé-da-letra é melhor para entender seu problema, ou será melhor aceita pelo seu time naquele momento. Então é importante ter maturidade, e estudar sobre essas ferramentas, priorizando as que tiverem mais haver com a estratégia no momento. Além disso, é sempre bom validar com membros os objetivos e o roteiro, para garantir que estamos todos comprados com a importância daquele momento para o desenvolvimento do produto ou solução.

Como já tínhamos investido um tempo em definir o problema nas semanas anteriores, criamos um Guia de Informações para dar maior contexto do problema a todos.

Nessa Guia, apresentamos relacionados ao Fluxo de cancelamento:

Fluxograma atual de como usuário chega ao cancelamento;
Gravação de tela;
Principais objetivos atrelados, e Definição em qual vamos trabalhar agora e porquê.
Público escolhido para a análise de acordo com plano e regra de negócio;
Perguntas que a Design Sprint vai responder. No caso, eram:

1) “Como entender melhor o motivo de cancelamento do usuário?”
2) “Como evitar que cancelem a partir dos motivos elencados?”;

Pergunte aos Especialistas

Entreviste especialistas da sua equipe da design sprint. No caso do nosso problema, precisamos conquistar aqui:

Empatia do time sobre as dores dos usuários, quando cancelam;
Viabilidade, através do entendimento de como funcionam as regras de negócio.

Apresentaram então o Especialista Analista de SC, detalhes quantificados sobre os Motivos de Cancelamento atuais, e o Product Manager sobre as regras de negócio do produto na hora do cancelamento.

Enquanto isso, a equipe foi instruída a capturar ideias durante as apresentações, e escrever “Como poderíamos” no board.

Por exemplo, como poderíamos explicar os recursos de segurança para clientes céticos?

HMW — Como Poderíamos?

Escrever “Como poderíamos”(HMW) com base nos aprendizados com os Especialistas e do Guia de Informações. Como fica no board do Miro:

HMW Categorizar

Separar os “Como Poderíamos”(HMW) em categorias relacionadas, assim podemos visualizar melhor áreas de solução agrupando essas primeiras alternativas.

HMW Votar

Votar para entender o que está mais “quente” na cabeça das pessoas.

2 votos para cada pessoa.
1 power vote(head) para desempate.

Consciente coletivo

O objetivo aqui é uma primeira colaboração entre os membros, a opção mais votada no Como Poderíamos(HMW) não necessariamente será a que vamos prototipar e testar no último dia. É mais sobre fortalecer o consciente coletivo da equipe sobre o problema.

Proto-Persona

As personas dos usuários são melhor apresentadas como uma história para ajudar as pessoas a se conectarem melhor e a lembrarem das necessidades do usuário.

Existem 4 usos principais da persona no design do produto:

Personas devem ser usadas para validar (ou não) as decisões tomadas pela equipe de design. Por exemplo, “é disso que o usuário realmente precisa?”
Personas são usadas para desenvolver prioridades quando idéias conflitam por recursos ou tempo;
As personas devem estar disponíveis durante as sessões de ideação para agir como uma fonte de inspiração e para manter as coisas fundamentadas e focadas no usuário;
As personas devem ser referenciadas ao criticar idéias ou iterações do produto;

Demos Relâmpago

Apresentamos como outras empresas tratam o fluxo de cancelamento e formulário antes de continuar o processo de ideação. Isso ajuda a divergir expandindo a consciência sobre o problema, antes de voltar para convergir as ideias.

Demonstrações Relâmpago no board do Miro

Crazy 8–2x

Aperta a mente, mas é divertido! O objetivo aqui é convergir ideias ao máximo.

Dobre uma folha de papel 4 vezes
Desdobre para fazer uma grade com 8 caixas
Esboce rapidamente 8 ideias em 8 minutos, uma em cada caixa.
Você pode experimentar variações rápidas de idéias semelhantes.

Os Crazy-8 ajudam o time a visualizar rapidamente as ideias para resolver o problema em diferentes cenários, rapidamente. Assim, fica mais fácil de desapegar de ideias e fortalecer o imaginário sobre o problema em si, individualmente.

ESSE É O MOMENTO DE ESCOLHER O QUE VAI SER TESTADO E PROTOTIPADO.

Depois de divergir e convergir nas outras etapas, na próxima é necessário instruir o time de que cada membro terá que individualmente escolher e representar somente uma ideia que julga a mais viável de ser prototipada para ser a solução testada pela design sprint.

Storytelling Jornada

Cada pessoa propôs uma solução em três passos:

1- Antes de Usar; 2 — Usando; 3 — Depois de Usar.

Nessa organização, simulamos uma jornada do usuário com a solução proposta por cada participante. Alguns pontos podem ajudar a preparar o storytelling da sua solução, descrição do próprio Miro, sobre essa fase:

Desenhar o que o usuário vê: pode ser uma página da web, uma experiência, um vídeo etc;
Cada nota é um novo passo. Guie-nos através da sua experiência. Concentre-se no que é novo e interessante;
Se necessário, você pode adicionar algumas notas laterais. — As palavras são MUITO importantes, mas desenhos feios são bons!;
Dê um título cativante;
Não escreva seu nome, tem que ser anônimo;
Sua solução deve ser auto-explicativa, pois você NÃO poderá nos dar um discurso de vendas mais tarde;

Museu de Arte — Votação

Depois de todas as ideias estarem disponíveis no board, todos devem usar seus dots e votar nas que acham mais viáveis para serem prototipadas.

As mais votadas fazem um breve pitch sobre do que se tratam, e o voto do decider é fundamental para seguirmos em frente com a solução para o dia seguinte.

É de boa inclusive aproveitar pedaços de ideias nesse momento, ou se a equipe tiver tempo, prototipar mais de uma solução e testar com usuários qual resolve melhor seu problema.

8. PASSO A PASSO METODOLOGIAS — DIA 2

Definimos qual seria a solução que iríamos testar no dia anterior. O objetivo hoje é testar se a ideia funciona com usuários reais.

Review da decisão — 15 min
Protótipo em Alta — 30 min
Hipóteses Definição — 30 min
TESTE 1 usuário — 30 min
TESTE 2 usuário — 30 min
TESTE 3 usuário — 30 min
TESTE 4 usuário — 30 min
TESTE 5 usuário — 30 min
Review do aprendizado — 15 min

Review do dia anterior

Começamos, passando o olho no nosso Guia de Informações e no Board do Miro para refrescar a equipe sobre como avançamos no dia anterior.

Definição de Hipóteses sobre o Problema

OK, hoje é o dia que precisamos testar o protótipo… Mas como tangibilizar o potencial da solução de dar certo?

Para isso, é importante a equipe fazer uma relação sobre quais são as hipóteses que temos sobre como a solução vai pode o problema, como essas hipóteses podem ser transformadas em tarefas, para serem testadas e validadas ou invalidadas.

Dor > Hipóteses > Tarefas > Testes > Validado?

Usar uma planilha compartilhada ajuda muito nessa parte. Daqui vão sair o roteiro, e uma visão geral do status dos testes.

O que vai ser testado, e como?

Não dava para prototipar em alta, nem testar TUDO com usuários. Por isso, priorizamos os fluxos dos motivos de cancelamento Financeiro e Conteúdo, mais relevantes no momento.

Mas qual é a melhor cena de abertura para o fluxo no protótipo?

“O contexto certo pode ajudar clientes a esquecer que estão experimentando um protótipo e a reagir com naturalidade ao produto” (SPRINT, Jake Knapp).

O truque é dar dois passos antes do início da solução que você quer testar: no nosso caso, tivemos duas cenas de abertura, a depender do teste:

“Você quer estudar um assunto específico” começando na página inicial logada, em que a primeira tarefa era usar a Busca para tentar encontrar uma aula. Ao tentar, aparecia a tela de Busca não encontrada. nosso objetivo aqui é a cena de abertura fazer o usuário sentir a dor de querer estudar, e não encontrar o que queria. Para assim entender as motivações dele(a) com relação a esse problema na hora do cancelamento da assinatura.
“Você recebeu um email de cobrança.” Começamos aqui na tela de um email de cobrança de assinatura do produto, dando o contexto: você recebeu esse email, mas não tem dinheiro para pagar. A partir desse gatilho, criamos uma motivação relacionada a ter um problema financeiro, na hora do cancelamento da assinatura.

Protótipo em alta

“Construir um protótipo em um dia parece uma tarefa intimidadora, mas, se formar uma equipe diversificada para o sprint, você terá todos os conhecimentos necessários na sala”.

Para garantir que teríamos o protótipo no curto período de tempo, dividimos nosso time em dois grupos, em videochamadas diferentes:

Um grupo comigo, participando da prototipação em alta no Adobe XD, adaptando os wireframes, aproveitando todos os componentes e styleguides possíveis já construídos, que parecessem os elementos que iam ser testados. Assim, esperamos ganhar o máximo de tempo e construir um teste interativo que simulasse o nosso produto.

Além do protótipo, estavam organizando as hipóteses e perguntas que iríamos fazer na hora dos testes com usuários, e experimentando se ele fazia sentido com o fluxo das perguntas.

Não tenha medo de compartilhar protótipos

Você pode não estar lá, mas se tiver um protótipo, entregue-o ao entrevistado; obtenha a opinião deles. O pessoal do Google diz que, mesmo usando o site ou produto de um concorrente para obter feedback, pode ser muito útil. Quanto mais realidade você puder colocar em um produto, mais claro será o feedback.

Writing é fundamental

“O conteúdo é Rei”(Bill Gates, 1996) — Um dos maiores erros em testes com usuários é não dar atenção aos textos, imagens e preparar as copys.

Em testes de usabilidade, esqueça o Lorem Ipsum.

Em outra design sprint, tínhamos experienciado esse problema da pior forma. No teste de um outro app para médicos plantonistas, tínhamos oferecido as condutas que eles buscavam de um jeito superficial, para preencher campo de texto, já que queríamos mesmo era testar o fluxo. Esse foi nosso maior erro, porque os médicos mal notavam o fluxo, ao serem perguntados sobre o que estavam vendo, só tinham olhos para o conteúdo errado.

Absorvendo aprendizados, o segundo grupo estava focado nas copys, para garantir que usuários não se confundissem durante as etapas.

9. Dicas para o momento dos Testes com usuário

Não venda, ouça

Você não está vendendo o produto. Você está tentando descobrir o que as pessoas querem para que você possa criar um produto. Não faça críticas, obtenha feedback e ouça. Não use as perguntas principais para obter as respostas que deseja ouvir — deixe as coisas em aberto e obtenha opiniões reais. Você pode nem sempre gostar do que as pessoas dizem, mas isso deixará seu processo de design muito melhor informado.

Reproduzir de volta ao participante: na dúvida, seja um espelho.

Quando chegar ao final de uma entrevista, resuma sua compreensão ao participante do que ele disse — deixe-o corrigi-lo se você estiver errado. Nunca é demais estar 100% confiante de que você entendeu o que foi dito.

Se ligue no tempo de cada sessão para não atrapalhar a programação;
É importante aqui seguir o roteiro das tarefas nos testes, para conseguir validar ou invalidar as hipóteses sobre a solução;
É importante que seja um 1x1 entre o entrevistador e o entrevistado. Interferências podem enviesar o resultado do teste.

10. Depois dos testes

Durante, o teste com usuário, é importante que a equipe da design sprint assista, o LookBack ajuda muito com isso. Dessa forma, diferentes visões aprendem com os feedbacks do usuário sobre o protótipo e podem ajudar a validar as hipóteses.

Outputs depois da Design Sprint:

Centralizar no Guia de Informações o que aprendemos, e todos os links de entrevistas, protótipo e hipóteses;
Comparar como resolvíamos a Dor antes, e como a solução nos ajuda a resolver agora;
Identificar cada ponto no protótipo em que estamos propondo soluções para as dores iniciais do cliente. Ex.: Inserimos botão de "VOLTAR", no caso de desistência do cancelamento durante o preenchimento do formulário.
Destacar os principais Padrões de comportamento das entrevistadas identificados nos testes;
Contabilizar quantas hipóteses foram validadas ou não nos testes;
Refinar o protótipo da Design sprint com a equipe, entender limitações de produção, o que seria mais viável de investir primeiro, e estruturar um Roadmap de implementação;

11. Aprendizados

Não tenha medo de deixar o entrevistado tirá-lo da pista; você pode descobrir que os problemas mais importantes não são descobertos através de suas perguntas, mas através de informações voluntárias dos clientes em potencial.
É necessária bastante banda mental como facilitador, para ficar atento ao tempo e ajudar dar a voz a todos os membros da equipe;
Se tiver alguém para ajudar com recrutamento e agenda dos testes, pode investir tempo em outras etapas do problema;
Chamar os especialistas com antecedência para construir o Guia de informações com você, ajuda a garantir um processo colaborativo desde o início;