Design sprint: o que é e exemplo de aplicação em cinco dias
O design sprint resolve um problema caro e comum: o time passa meses construindo uma solução e só descobre no lançamento que os clientes não a entendem, não precisam dela ou preferem outra coisa. Em vez de debater a ideia em reuniões ou apostar tudo no desenvolvimento, o design sprint comprime a decisão em cinco dias: entender o problema, gerar alternativas, escolher uma, construir um protótipo realista e testá-lo com clientes de verdade.
O processo foi criado por Jake Knapp, que começou a conduzir design sprints no Google em 2010 e os levou ao GV (antigo Google Ventures) em 2012. Ele foi documentado no livro Sprint, publicado em 2016 por Knapp, John Zeratsky e Braden Kowitz, e continua descrito em detalhe no guia mantido no site do livro.
Abaixo estão os papéis, a agenda de cada dia, um exemplo completo de aplicação e os critérios para saber quando o design sprint é a técnica certa.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é design sprint e quando usar
O design sprint é um processo estruturado de cinco dias para responder a perguntas críticas de negócio por meio de prototipação e teste com clientes. A saída não é um produto pronto: é aprendizado validado sobre uma ideia, a tempo de mudar de rumo antes de gastar com desenvolvimento.
Ele funciona melhor quando:
- O desafio é importante e caro de errar (um produto novo, um serviço digital, uma mudança grande de experiência).
- Há várias soluções possíveis e o time não consegue escolher.
- O prazo é apertado e o time precisa de uma direção rápida.
- O time está travado em discussões que não avançam.
E funciona mal quando o problema é pequeno (não justifica uma semana de várias pessoas), quando a solução já é óbvia ou quando ninguém com poder de decisão aceita participar.
Design sprint, Sprint do Scrum e outras técnicas
| Técnica | Duração | Pergunta que responde | Saída |
|---|---|---|---|
| Design sprint | Cinco dias, pontual | Esta solução funciona para o cliente? | Protótipo testado e decisão |
| Sprint do Scrum | Até um mês, contínua | O que entregamos de valor neste ciclo? | Incremento utilizável |
| Lean Inception | Cerca de uma semana, no início do produto | Qual é o MVP e o que entra nele? | Visão do produto, sequenciador de funcionalidades e canvas MVP |
| Design thinking | Variável | Qual é o problema real e que soluções existem? | Entendimento do problema e alternativas |
O nome engana: o design sprint não tem relação com a Sprint do Scrum, além da ideia de tempo fixo. Ele costuma acontecer antes do desenvolvimento, e o resultado alimenta o Product Backlog. Se a dúvida é sobre o escopo do primeiro produto, a Lean Inception costuma ser mais adequada; se o time ainda não entende o problema, a abordagem mais ampla de design thinking na gestão de projetos vem antes.
Quem participa
O guia dos autores recomenda um time de até sete pessoas, com dois papéis definidos:
- Decider: quem toma as decisões finais. Sem essa pessoa, as decisões não se sustentam. Se ela não puder ficar a semana toda, deve indicar alguém com autoridade delegada.
- Facilitador: cuida do tempo, das conversas e do processo, registra a discussão no quadro e chama o Decider quando o grupo trava.
Os demais participantes trazem perspectivas diferentes: quem conhece o cliente (atendimento, vendas), quem entende o negócio (finanças, marketing), quem sabe o que é viável (tecnologia) e quem desenha a experiência (design). Especialistas extras podem participar só por algumas horas, no primeiro dia.
Os cinco dias do design sprint
Segunda-feira: mapear
O time define a meta de longo prazo ("daqui a dois anos, por que este projeto terá dado certo?") e transforma os riscos em perguntas a responder durante a semana. Em seguida, desenha um mapa simples da jornada do cliente, de 5 a 15 passos. Especialistas são entrevistados, e o time registra as oportunidades em notas no formato "Como poderíamos...". No fim do dia, o Decider escolhe o alvo: o ponto do mapa em que o sprint vai se concentrar.
Terça-feira: esboçar
O time começa com demonstrações rápidas de soluções existentes (de concorrentes ou de outros setores) que possam inspirar. Depois, cada pessoa trabalha sozinha num esboço em quatro passos: notas, ideias, o exercício Crazy 8s (oito variações em oito minutos) e um esboço final da solução, detalhado o bastante para se explicar sozinho. Nesse dia também começa o recrutamento dos clientes que vão testar o protótipo na sexta.
Quarta-feira: decidir
Os esboços são expostos, e o time usa um processo de decisão sem debate longo: um mapa de calor com adesivos nas partes de que cada um gosta, uma votação rápida e o supervoto do Decider. A solução escolhida vira um storyboard, uma sequência de cerca de 15 quadros que mostra o que o cliente vai ver e fazer no protótipo.
Quinta-feira: prototipar
O time constrói um protótipo realista, mas só de fachada: o suficiente para parecer real ao cliente, sem nada funcionando por trás. Os papéis se dividem entre quem monta as telas ou peças, quem junta tudo, quem escreve os textos, quem reúne imagens e dados e quem prepara o roteiro da entrevista. No fim do dia, faz-se um ensaio completo.
Sexta-feira: testar
Um entrevistador conduz cinco entrevistas individuais com clientes do público-alvo, de preferência no mesmo dia, enquanto o resto do time observa a distância e anota. O guia dos autores trata cinco como o número que basta para os padrões aparecerem. As perguntas de segunda-feira viram linhas de um quadro de resultados, com uma coluna por cliente. No fim do dia, o Decider decide o próximo passo com base no que se viu.
Exemplo de design sprint: aplicativo de pedidos para pequenas lojas
O exemplo é ilustrativo. Uma distribuidora de materiais de construção atende centenas de pequenas lojas no interior, que fazem pedidos por telefone e por mensagem com o representante. A diretoria quer um aplicativo de pedidos, mas há dúvida: os lojistas vão usar, ou continuarão ligando para o representante?
Time: diretor comercial (Decider), coordenadora de atendimento, um representante de vendas, um analista de sistemas, uma designer, a gerente de projetos (Facilitadora) e uma pessoa da logística.
Segunda: a meta de longo prazo é "metade dos pedidos recorrentes chegando pelo aplicativo em dois anos". As perguntas do sprint incluem: o lojista confia num pedido sem falar com o representante? Ele consegue encontrar os produtos pelo nome que usa no balcão? O mapa vai de "lojista percebe que falta estoque" até "pedido entregue". O alvo escolhido é o momento de montar o pedido.
Terça: as demonstrações rápidas incluem aplicativos de supermercado com "repetir último pedido" e catálogos por foto. Os esboços finais trazem três ideias fortes: repetir o pedido anterior com um toque, buscar pelo apelido do produto e enviar a lista por foto para o representante confirmar.
Quarta: o mapa de calor e o supervoto escolhem "repetir pedido anterior, com ajuste de quantidades", com a busca por apelido como apoio. O storyboard tem 14 quadros, da notificação de estoque baixo à confirmação do pedido.
Quinta: a designer monta as telas numa ferramenta de prototipação; o analista preenche com produtos reais; o representante revisa os nomes; a coordenadora prepara o roteiro.
Sexta: cinco lojistas testam o protótipo. Quatro repetem o pedido sem ajuda; três estranham não ver o nome do representante e perguntam se ele "fica sabendo". A busca por apelido funciona em dois casos e falha em três. O Decider decide seguir com o "repetir pedido", incluir a confirmação do representante no fluxo e tirar a busca por apelido do primeiro lançamento.
O resultado vai para o Product Backlog do time que vai desenvolver o aplicativo, já com os principais riscos testados. O caminho seguinte, de transformar isso numa primeira versão enxuta, está em como construir um MVP do jeito certo.
Erros comuns
- Decider ausente. As decisões de quarta são revistas na semana seguinte por quem não participou.
- Time grande demais. Com mais de sete pessoas, a discussão volta e o processo perde ritmo.
- Problema pequeno. Uma semana de sete pessoas para decidir a cor de um botão é desperdício.
- Protótipo bonito demais. Gastar a quinta-feira em acabamento tira tempo do que importa: parecer real o suficiente para o teste.
- Clientes errados. Testar com colegas da empresa ou com quem não é público-alvo produz falso positivo.
- Ignorar o resultado. Se o teste mostrou que a ideia não funciona, insistir nela desperdiça o principal ganho do sprint.
Como preparar o primeiro design sprint
- Defina o desafio em uma frase e confirme que ele é grande o suficiente para justificar uma semana.
- Garanta o Decider e a agenda livre de todos por cinco dias.
- Reserve uma sala com paredes para colar papéis (ou um quadro digital, se for remoto).
- Comece o recrutamento de clientes antes da segunda-feira.
- Combine com o patrocinador o que acontece depois: quem recebe o resultado e como ele entra no plano do projeto.
O guia completo de métodos ágeis e Scrum mostra como o resultado do design sprint se encaixa no backlog e nas Sprints do time que vai construir a solução.
Para conduzir o processo com segurança, o curso de Design Thinking da Projeto Diário trabalha as técnicas de entendimento do problema, geração de ideias, prototipação e teste com usuários que sustentam cada dia do design sprint.
