O que é Design Sprint e o que se decide em cinco dias

Design Sprint é um processo de cinco dias que troca meses de discussão por um protótipo testado com clientes reais. Ele não entrega produto, e essa é a parte que costuma decepcionar quem entende errado. O que a semana entrega é uma decisão fundamentada sobre seguir, mudar ou descartar a ideia.

São cerca de quarenta horas para responder uma pergunta que normalmente leva meses e, no fim, ainda termina em opinião de quem tem mais autoridade na sala.

O método foi criado por Jake Knapp dentro do Google, e refinado no Google Ventures, o braço de venture capital da empresa, onde ele rodou mais de cem sprints com startups. Knapp publicou o processo em 2016 no livro Sprint, escrito com John Zeratsky e Braden Kowitz.

O que precisa estar pronto antes da segunda-feira

A semana falha no planejamento, não na execução.

As pessoas certas. Não só os interessados, os envolvidos. A informação que decide está espalhada: quem programa sabe coisas que quem desenha não sabe, e o comercial sabe coisas que produto não sabe. Sprint com uma área só produz a solução que aquela área já sabia fazer.

Um facilitador que conheça o processo. A função é parecida com a de um técnico de time, ou de um Scrum Master para quem vem de tecnologia: conduz, controla o tempo e mantém o grupo na etapa certa. Precisa conhecer o método e precisa conseguir soltar um grupo de gente que mal se conhece.

Local e agenda reservados de verdade. Especialista que participa "quando dá" quebra a sequência, porque cada dia depende do anterior.

E uma observação que vale para qualquer formato desse tipo: cuidado ao convidar chefe. Não por antipatia, por efeito prático. Na presença de quem avalia desempenho, as pessoas oferecem menos ideia e defendem mais a própria posição. Se a liderança precisa estar, o melhor lugar é a segunda-feira e a sexta-feira.

A semana

Segunda: mapear o problema e escolher um alvo

O dia serve para o grupo construir entendimento comum e sair com um alvo, não com uma lista.

A história do problema é contada, cada especialista contribui com o que sabe, e o grupo registra o que aprendeu em um quadro visível. Perguntas são bem-vindas, porque o custo de alguém entender errado na segunda aparece na quinta.

O facilitador tem uma responsabilidade específica aqui: garantir que todos comecem alinhados. Ao fim do dia é preciso saber qual problema a semana vai atacar.

Uma nota de nomenclatura, porque gera confusão em material em português: nas versões anteriores do processo, no Google Ventures, este dia se chamava "descompactar" ou "entender". No livro de 2016 ele é mapear.

Terça: esboçar soluções concorrentes

Papel e caneta, individualmente, e depois o grupo olha e vota.

A escolha do papel não é nostalgia. Esboço em papel é rápido, é barato de jogar fora, e não exige que todos dominem uma ferramenta. Ferramenta cria dois problemas ao mesmo tempo: gasta tempo e privilegia quem sabe usá-la.

O objetivo do dia é quantidade e variedade. Se o grupo é grande e gera ideia demais, vale reservar a última hora para reduzir a um número administrável antes de quarta.

Repare na palavra "concorrentes". As soluções são feitas para competir, não para serem combinadas em consenso. Consenso na terça produz a média das ideias, e a média raramente vence um teste.

Quarta: decidir e montar o storyboard

Escolher uma. Não há tempo de prototipar todas, e escolher é o trabalho.

Decidida a solução, o grupo monta um storyboard, que funciona como o roteiro do protótipo: passo a passo, o que a pessoa vê, o que ela faz, o que o produto responde. O storyboard é o que permite que a quinta-feira seja execução e não invenção.

Este é também o dia de recrutar quem vai testar na sexta. Deixar isso para depois é o erro que mais compromete a semana, porque sem participante confirmado não existe sexta-feira.

Quinta: prototipar algo que pareça real

Oito horas para um protótipo parece impossível. Era a minha primeira reação quando li o livro.

A resposta está no que se entende por protótipo. Não é produto, é simulação. O protótipo precisa parecer real para quem vai usar durante trinta minutos, e nada além disso.

Um exemplo do próprio livro, adaptado: se o produto é um app de mensagem, o protótipo não cadastra amigo nem envia mensagem de verdade. Ele já tem amigos e mensagens no lugar, porque o que está sendo testado é a experiência do fluxo, não funcionalidade, desempenho ou acabamento.

O livro sugere Keynote, que tem biblioteca de componentes e faz protótipo interativo rápido. Serve qualquer ferramenta que o time domine. O critério é velocidade, não sofisticação.

Sexta: testar com cinco clientes

Cinco pessoas, uma a uma. O número não é arbitrário: com cinco entrevistas os padrões de problema já aparecem, e cinco é o que cabe em um dia com tempo de conversar de verdade.

O teste não é guiado. A pessoa explora o protótipo e encontra os limites dele sozinha. O time observa e anota, e no fim do dia consolida o que viu.

É o único dia da semana em que entra informação de fora. Os quatro anteriores organizam o que a organização já sabia; a sexta traz o que ela não sabia.

Onde o Design Sprint se encaixa entre os outros

Três formatos que se confundem e param em pontos diferentes:

O Design Sprint é o mais estreito dos três, e é isso que o torna rápido. Ele não pergunta qual é o problema nem o que entra no escopo do produto. Ele pega uma solução e verifica se ela sobrevive ao contato com o cliente.

Depois que ela sobrevive, aí sim vale decidir escopo e entrar no ciclo de construir, medir e aprender do Lean Startup.

Adaptar sem descaracterizar

O livro descreve cinco dias, e a prática produziu variações mais curtas, de quatro e de três dias. A escolha depende do tamanho da pergunta e da disponibilidade real dos especialistas, porque tirar gente sênior da operação por uma semana inteira raramente é simples.

Existem também adaptações em que parte do grupo participa só das etapas de mapear, esboçar e decidir, e o restante da semana fica com o time técnico. Funciona, e reduz o custo de agenda.

O que não dá para cortar é a sexta-feira. Sprint sem teste com cliente é workshop, e workshop termina em decisão por autoridade, que é exatamente o que o formato existe para evitar.

Na minha visão, a maior dificuldade não é caber em cinco dias. É aceitar que o resultado legítimo da semana pode ser descartar a ideia que a levou até ali. Uma organização que só considera o sprint bem-sucedido quando o protótipo é aprovado transformou o método em cerimônia de validação.

E vale calibrar a expectativa: as primeiras tentativas costumam estourar o prazo. Não é um problema de disciplina, é mudança de hábito de decisão, e isso leva algumas rodadas.

Na sua organização, quando uma ideia chega ao teste e o cliente não entende, o que costuma acontecer: a ideia muda ou o teste é questionado?