Mas o que são e para que servem os Design Sprints?
Entenda de uma vez por todas o que é o Design Sprint e como utilizá-los!
Agora você aprenderá sobre uma metodologia internacionalmente difundida para resolução de problemas e testagem de ideias. Basicamente, é uma composição de dinâmicas herdeiras de processos mais tradicionais de Design Thinking consolidadas em menos de 1 semana de projeto!
- Composição: 11 dinâmicas
- Duração: 4 dias (na versão 2.0)
- Modelo: em grupo (há dinâmicas solo e dinâmicas coletivas)
- Materiais necessários [presencial]: post-its, canetas, papéis, cola e fita!
- Materiais necessários [remoto]: boa conexão para videochamadas e acesso à ferramenta de whiteboarding, como o Miro.
Você já deve ter tido alguma ideia que achou incrível? Algo que você pensou “isso daria muito certo”?
Bom, muito provavelmente sim. Talvez no mês atual inclusive.
Todavia, talvez, mais importante que falar de ideias, devemos falar sobre como fazê-las funcionar, tirá-las do papel e implementá-las!
Enão se engane, o que falaremos hoje não é utilidade e responsabilidade exclusiva de inovadores de carteirinha, empreendedores ou os famigerados “makers”. Estamos falando de uma atividade natural de nosso dia-a-dia, que, com sorte, poderemos prestar valor desde startups a grandes corporações, mas também a você e aos desafios pontuais que tenha no seu cotidiano.
Antes de começarmos, precisamos entender como soluções são criadas de uma maneira “menos eficiente” para percebemos o valor do Sprint. Focaremos em produtos e serviços digitais, concebidos no contexto de um time, para fins práticos.
Bom, vamos lá…
Imagine uma equipe de 8 pessoas tentando criar um aplicativo para ajudar os pacientes do hospital onde trabalham a registrar informações sobre a evolução de seus sintomas remotamente. Tudo isso para não precisarem vir a tantas consultas presenciais em tempos de pandemia e gerar algumas economias.
Como geralmente acontece, parte-se de um problema, o qual inspira pessoas do time a tentar resolvê-lo.
Alguns acham que um aplicativo é a melhor solução, mas há quem diga que um chatbot capaz de se comunicar com as redes sociais do paciente seria muito melhor.
Cada um com suas ideias e suas opiniões puxando para lados frequentemente diferentes.
Aí, começam as discussões que parecem nunca acabar, os atritos interpessoais e a sensação de não sair do lugar.
Uma vez que se supere essa inércia e se iniciem os processos de entendimento, pode-se ir para ideação de fato. Ou seja, pensar em como se resolverá o desafio.
Mais uma vez, ineficientes discussões e dinâmicas de brainstorm que mais parecem um disputa de quem fala mais alto povoam casualmente essa etapa.
Mas, finalmente, chega-se ao que será desenvolvido.
A ideia parece ótima! O aplicativo revolucionará o cuidado do paciente, reduziremos taxas de transmissão intrahospitalar de COVID e ainda economizaremos recursos de todas as partes. Parece ótimo! Outras pessoas fizeram algo parecido, certo? O líder adorou! Vamos lá fazer esse aplicativo logo!
6 meses depois e 300 mil reais investidos, temos o produto. Agora só levar para mão do paciente, definir as métricas de avaliação do produto e tudo feito.
Mas, alguns meses depois do lançamento, e apenas 1% dos pacientes registraram alguma informação. Por quê? Bem, parece que aqueles pacientes não queriam instalar mais um aplicativo para registrar seus sintomas… Tinham medo que as informações sensíveis fossem vazadas ou hackeadas e ainda achavam que o aplicativo iria reduzir o número de contatos presenciais com os médicos, algo que gostam e valorizam bastante.
E não achem que essa história é a exceção!
Assim como esse exemplo, milhares de projetos morrem quando enfrentam o famoso “mundo real”. E, por mais tentador que seja apontar erros na ideia, raramente seremos capazes de chegar em planos perfeitos.
Mas qual a razão para isso?
Bom, são muitas. Muito mais do que qualquer esforço de registro poderia contemplar…
Porém, vale lembrar um fato simples: ambientes controlados (o famoso “CNTP” de nossas provas de física do ensino médio) que permeiam nossas mentes, opiniões e achismos são insuficientemente representativos da complexidade do mundo real.
Por isso, como já fazem os cientistas há algumas centenas de anos, qualquer modelo, hipótese ou ideia precisa ser colocada à prova, pois somos humanos. Erramos, esquecemos e, sobretudo, não captamos a imensidão de informações da natureza e das intrincadas relações que se desenrolam delas.
Bom, agora vamos falar como a história poderia ter sido diferente, seja com um time em um hospital, uma corporação querendo inovar ou, simplesmente, uma pessoa tentando resolver um problema de seu cotidiano.
Em linhas gerais, precisamos focar em “aprender” se aquilo que estamos pensando funciona/é verdade ou não! E muito cuidado aqui. Aprender antes de promover, vender e, com certeza, antes de sair fazendo a solução de fato.
Uma pequena ressalva: não estamos falando de coisas pequenas. Soluções muito pequenas podem simplesmente ser feitas para serem testadas se funcionarão ou não. Diferentemente de projetos mais robustos, cujo custo de desenvolvimento e/ou o impacto da falha são perigosamente altos.
É para essa última categoria que focamos esse texto, isto é, um grupo de soluções que cobram uma “validação” prévia ao desenvolvimento, o que faremos por meio de testes e protótipos iterativos.
Se algo aqui não é tão claro, não se preocupe! Escreveremos bastante sobre protótipos e testes no futuro.
Bom, agora entramos no assunto principal desse artigo:
Como criar e validar soluções a partir de desafios de forma rápida, colaborativa e eficiente?
Entre várias maneiras de fazer isso, escolhemos uma das mais pragmáticas e amigáveis para uma vasta diversidade de contextos: o Design Sprint.
O nome é intuitivo, cabendo, entre várias possíveis interpretações, encarar essa metodologia como algo capaz de trazer “agilidade” ao processo de “criar coisas”.
Formalmente, o Design Sprint é definido pela sua instituição originalmente idealizadora, a Google Ventures (GV), como:
“Um processo de cinco dias para responder a perguntas críticas de negócios por meio de design, prototipagem e ideias de teste com os clientes.”
Aqui cabe já introduzirmos nosso primeiro disclaimer: a duração de 5 dias é a clássica do modelo hoje chamado 1.0 criado pela GV com a liderança de Jake Knapp. Mas a comunidade global, com especial destaque para a agência AJ Smart, hoje traz o modelo em 4 dias, comprimindo algumas dinâmicas e concebendo o Design Sprint 2.0.
Daqui em diante, utilizaremos o 2.0 como referência, por entendermos que as economias que ele promove são bem interessantes para os propósitos desses projetos, ainda, ao longo de nossos textos, perceberá que não achamos ser um modelo do tipo “one size fits all” e sim um grupo de dinâmicas modulares que você pode usar em composições diversas a depender de seu desafio.
Simplificando, o Design Sprint é uma abordagem de Design Thinking composta a partir de uma série de dinâmicas modulares para partir de problema e chegar a uma solução prototipada testada com usuários reais.
Por isso: teste. Simples assim, teste até “provar” hipóteses, resultados e que certas ideias, de fato, “funcionam”.
Isso evitaria a morte de milhares de empresas que criaram soluções para problemas que não existem ou que simplesmente não foram suficientes para resolvê-los.
O sprint dá às equipes que o realizam um superpoder: elas podem avançar no futuro para ver seu algo próximo ao produto acabado e as reações do cliente, antes de fazer qualquer compromisso caro.
Em termos de resultado, quando uma ideia arriscada testada é bem-sucedida no sprint, ficamos bem felizes. Mas são as falhas que, embora dolorosas, fornecem o maior retorno sobre o investimento, já que nos economizam grandes investimentos e nos refinam a direção do que, de fato, funcionará.
Mas afinal, como funcionam os Design Sprints?
Basicamente, reuni-se um time e se realiza algumas dinâmicas para tornar as discussões e insights gradativamente mais maduros, focados e direcionados para co-criação de um protótipo, que será validado e iterado em direção à solução final a ser desenvolvida.
Formalmente segmentado em 4 dias na versão 2.0, o Sprint é na verdade um processo modular e, cada vez mais, temos o utilizado menos como um sequência estanque e restrita e mais como uma caixinha de dinâmicas que podemos, inclusive, associar outras dinâmicas e abordagens. Dito isso, vamos começar pelo básico, falando da forma mais tradicional e pragmática de conduzir o processo.
Primeiro dia
Geralmente na segunda feira, para aproveitaremos bem todos os dias da semana, no primeiro período do dia (normalmente manhã), focaremos em definir o desafio.
Já no segundo período, esboçaremos soluções.
Segundo dia
No primeiro período, votaremos nas ideias do dia anterior.
E no segundo período, tangibilizaremos a ideia escolhida em torno de um storyboard para o teste com usuários a ser feito.
Terceiro dia
Aqui criarmos o protótipo, definiremos o que queremos aprender. estruturamos scripts e cronogramas de entrevistas.
Quarto dia
Agora, realizaremos o testes que definimos com o protótipo criado, bem como consolidaremos as informações para concluir nossas validações.
RECAPITULANDO
- O Design Sprint é uma metodologia que possui um sistema de etapas que duram aproximadamente 1 semana para resolver grandes problemas e testar grandes ideias;
- E é muito usado para criar produtos e serviços com mais rapidez e eficiência no processo de maturação das ideias;
- Foi desenvolvido na Google Ventures, com liderança do Jake Knapp, escritor principal do livro “Design Sprint”, no contexto de reduzir ciclos de desenvolvimentos longos, potencialmente pouco econômicos no racional de "aprender para fazer o certo" e organizar um processo replicável em torno disso tudo. Depois foi readaptado pelo grupo da AJ&Smart para o Design Sprint 2.0, que encurtou o processo para 4 dias. E atualmente, vive em constante transformação para melhores resultados, como visto na modularização de suas dinâmicas e na construção de frameworks que quebram a jornada da solução em Sprints para diferentes fases.
Esquematicamente, temos as seguintes dinâmicas (não se preocupe, nos próximos artigos, explicaremos com calma cada uma delas):
Dia 1:
Manhã: Definindo o desafio
- Entrevista com os especialistas + Como nós podemos
- Objetivo do Sprint + Perguntas do Sprint
- Mapa
Tarde: Produzindo soluções
- Demonstrações relâmpago
- Esboço em 4 partes
- Tirando notas
- Rabiscando
- Crazy 8's
- Conceito
Dia 2:
Manhã: Votando nas soluções
- Votação Heat Map
- Apresentação de soluções
- Votação Enquete
- Voto do decisor
Tarde: Storyboard
- Teste de fluxo de usuário
- Storyboarding
Dia 3:
- Prototipação
Dia 4:
- Teste com usuários
Lista completa
- Mas o que são e para que servem os Design Sprints? - Esse artigo
- Dia 1 - Pergunte aos especialistas
- Dia 1 - Objetivo e perguntas do Sprint
- Dia 1 - Mapa
- Dia 1 - Lightning Demo ou Demonstrações relâmpago
- Dia 1 - Esboço de quatro partes ou 4 STEP SKETCH
- Dia 2 - Apresentação das soluções
- Dia 2 - Fluxo de teste do usuário
- Dia 2 - Storyboard
- Dia 3 - Dicas para o dia de prototipação
- Dia 4 - Como fazer User testing
- Como nós fazemos o DS
- Como se preparar para um DS
- Como vender um DS
