Trouxe aqui alguns problemas que enfrentei aplicando a metodologia de Design Sprint para que você não seja pego de surpresa e saibam como proceder ou até mesmo evita-los.
Contextualizando quem não conhece a metodologia, o Design Sprint é um processo de design, baseada em técnicas de UX e Design Thinking, em um formato de imersão de para validar ideias e resolver grandes desafios, em até 5 dias. Consiste em uma série de dinâmicas para mapear, idear, criar e validar solução(ões) para esses desafios, aproveitando ao máximo o conhecimento de cada membro da equipe (que deve ser o mais multidisciplinar possível) e ao final validar essa solução.
Vamos então ao que interessa, bora ver o que NÃO fazer em um DS.

Não fazer dinâmicas de quebra-gelo
Foto de Alex Perz
As dinâmicas de quebra-gelo são umas daquelas coisas que não “estão nos livros”, mas que fazem uma diferença absurda na hora do DS.
Elas não só unificam o time, trazendo um sentimento de cumplicidade como na dinâmica “2 verdades e uma mentira”, ou os coloca no mindset criativo como na “desenhe uma frase”, mas também deixa o time mais confortáveis e relaxados.
E quem é que mais precisa estar confortável e relaxado para o bom andamento de um DS? Isso mesmo, o Facilitador! Ele que passou dias planejando e se preparando para rodar as dinâmicas e principalmente nas primeiras dinâmicas não está 100% à vontade nem conhece ainda o time.

Não planejar o DS
Foto de Isaac Quesada
Quando você não planeja o DS, muita coisa passa desapercebida, e nada parece se encaixar. Não que um DS minuciosamente planejado não haverá imprevistos, mas quando não se planeja, com certeza terá uns probleminhas aqui outros acolá:
A agenda não bate com o tempo precisa; a dinâmica “X” não acontece na ordem que você precisa (principalmente as que dependem de agendamento com especialistas, stakeholders ou usuários); os preparativos e infra estrutura não são o que você espera, enfim sua tranquilidade e saude mental vão para espaço.
Sempre procure planejar e se antecipar aos acontecimentos e possíveis problemas, isso faz toda a diferença em um DS tranquilo e eficiente.

Definir objetivo, perguntas etc… antes de conversar com especialistas
Foto de Jamie Street
Tudo que você definir sem falar com especialistas e stakeholders corre um sério risco de estar num caminho que não trará soluções para o problema. A própria definição do problema do DS corre o risco de não corresponder a um problema relevante
Uma boa dica é começar o DS com a conversa com especialistas antes de todas as definições, mudança proposta pela metodologia da AJ&Smart e reconhecida pela própria Google como uma melhor prática.
Isso evitará o vai e volta e revisões no Objetivo, no Desafios e nas Perguntas do DS, tornando-os mais assertivos e objetivos.

Não manter o foco do time
Foto de Elena Taranenko
Não ter o foco nem o comprometimento do time atrapalha bastante o andamento do DS, tornando as interrupções, dispersões e repetições das instruções das dinâmicas constantes tirando a fluidez do trabalho.
É super importante explicar essas questões ao time e ser bastante insistente nas restrições de devices, principalmente notebooks, pois os membros do time em algum momento tentarão dividir sua atenção com suas responsabilidades do dia à dia e o DS.
Apesar de tudo nunca chame a atenção de ninguém. Como em geral estamos trabalhando com adultos o próprio time se auto-fiscalizará quando um membro desfocar ou sacar seu device para dar aquela espiadela.
Outra estratégia é mante-los sempre ocupados, participando de todas as atividades, mantendo-os ativos e focados no DS.

Permitir ideias fora da hora
Foto de Kristopher Roller
Como disse anteriormente o DS tem uma série de dinâmicas que visam mapear, idear, criar e validar uma solução e em especial a etapa de ideação é algo complicado, pois as pessoas muitas vezes já vem com “a ideia infalível” ou querem dar novas ideias depois do processo de ideação.
Essas ideias são muito perigosas, principalmente as ideias que surgem depois da etapa de ideação, pois não passaram por todo o crivo que as outras ideias passaram para serem escolhidas para as próximas etapas.
O DS em si costuma aflorar a criatividade das pessoas e, é normal termos insights a todo momento para nos auxiliar na tratativa dessas ideias, podemos usar o “estacionamento de ideias” onde ideias fora de hora são anotadas para não serem perdidas. Outro ponto importante é sempre relembrar ao time o objetivo e desafios do DS para que eles mesmo evitem ideias fora desse contexto.

Levar o time em alguma direção
Foto de Aron Visuals
O facilitador está no DS para guiar o time no processo à fim de conseguirem chegar em uma solução para o problema e não deve se intrometer ou direcioná-los, pois o facilitador normalmente é um agente externo que não tem a vivência na área de atuação que o time tem.
Porém como profissional de UX temos bastante conhecimento sobre experiência do usuário, peça chave na última etapa de validação da solução criada no DS, então mesmo não sendo especialistas na área de atuação da equipe podemos contribuir com alguns “conselhos” aqui e acolá.
Mas Thiago, você listou isso aqui como algo a não se fazer, e depois fala pra fazermos? Pois é, mas com muita sabedoria (com grandes poderes vem grandes responsabilidades 😆).
O que você sempre tem que ter em mente é que decisões de negócio a equipe está bem melhor qualificada, porém no que diz respeito a experiência do usuário, sua expertise auxiliará o time a tomar a melhor decisão.

Bônus — Algumas dicas mais pontuais
Foto de Ekaterina Shevchenko
- Não estenda a explicação de dinâmicas que virão a seguir a dinâmica que você está aplicando no momento, isso desfoca o time e o coloca com a atenção dividida entre a dinâmica que está sendo realizada e na que está por vir.
- Principalmente na entrevista com especialistas, não distribua folhas grandes (A4, A3) para nenhuma anotação. Faça com que o time se acostume a tomar notas individuais em post-its e com o mindset de notas de CNP (Como Nós Poderíamos) para evitar perder algum insight e facilitar na hora de clusterizar as anotações.
- O teste deve ser estritamente fechado a usuários da solução. Não adianta na hora do teste querer mostrar o trabalho desenvolvido no DS para um gerente ou alguém de cargo de liderança que não tenha participado do processo, pelo simples fato de que o processo ainda não acabou e vai deturpar o resultado do teste por não ser um usuário real. O resultado dos testes determina o sucesso ou não da solução e serve inclusive como argumentação para apresentar a solução às lideranças, então espere ter todo o DS concluído para ir mostrar para o chefe ;).
É isso, espero que essas dicas te ajudem a não terem surpresas e se tiverem algum percalço que queiram compartilhar, não deixem de comentar ou até mesmo me contatar para trocarmos figurinhas 😃.