Design Sprint: dicas que eu gostaria de ter recebido

Livro Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

Muitos dos que trabalham com desenvolvimento de produto ou serviço já ouviram aquela máxima “design centrado no usuário e/ou design thinking é muito legal, mas não temos tempo nem orçamento para isso”. Tendo isso em mente, não é de se estranhar que o livro Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, apesar de ter sido lançado há pouco tempo, já seja sucesso.

O livro apresenta como alguns designers da Google Ventures têm conseguido envolver especialistas e usuários finais desde o início na solução de problemas ou na proposta de produtos ou serviços. O alerta inicial é claro: não se trata de brainstorming. Com apenas 5 dias, não rola isso de sessão de palpitaria, nem de muro de lamentações. ❤

Imagem do livro mostrando as atividades macro dos 5 dias.

Se você já trabalhou com Design Thinking antes, enquanto estiver lendo, vai ter uma série de déjà vus, com a sensação de que o livro talvez não esteja apresentando nada novo. Não se deixe dominar por este sentimento. A grande jogada do método apresentado é se aproveitar de muitas técnicas que conhecemos e usamos de forma desconectada de outras atividades, atar tudo e mostrar como fazer ordenadamente e com tempos determinados. Todas as atividades são bem detalhadas e com exemplos. Tudo fica muito claro. Um bálsamo para um coração prático.

E o melhor de tudo: F.U.N.C.I.O.N.A. Mesmo quando falha, funciona.

Mas claro, sempre há espaço para melhorias e após ter rodado algumas vezes o método, eis algumas dicas para iniciantes:

Dicas para o antes:

1. As pessoas que você vai envolver ficarão muito muito muito muito muito ansiosas. Prepare um material para apresentar o método, tudo que será feito e como as coisas se relacionam. Seja bem didático. Lembre-se que muitas pessoas que estarão presentes são de outras áreas, que não têm muito contato com pesquisa ou design.
2. Todos os lanchinhos são muito legais, porém pesam no bolso de alguém. Lembre-se de colocar no orçamento deixar claro quem paga a conta.
3. Reserve a mesma f*cking sala para todos os dias. Dizer “preciso de uma sala com quadros brancos” é vago (e a responsabilidade é sua). Diga “preciso de uma sala que não poderá ser ocupada por mais ninguém durante 5 dias.
4. Aliás, seja bem específico, sempre. Não tema a redundância.
5. Se você não tiver 5 dias, priorize os 3 primeiros. E só escale quem puder dedicar todas as horas necessárias. Passe forte a mensagem de que meio tempo dedicado pode significar meia solução. E quem assume esse risco?

Dicas para o durante:

1. Se você for participante, pese bem suas contribuições. Seja objetivo.
2. Se você for facilitador: medite. É sério.
3. Se você for facilitador: as pessoas vão se sentir muito inseguras durante as dinâmicas e isso é normal. É sua responsabilidade fazer com que todos se sintam confortáveis. Ninguém é obrigado a ter lido o livro antes das dinâmicas. Faça um piloto mostrando como é a tarefa com um exemplo aleatório.
4. O primeiro dia é o mais cansativo. Você vai sair com a sensação de que talvez não saia nada legal e que um dia inteiro foi perdido e que talvez os diretores não precisassem estar presentes. Eles precisam. O dia seguinte vai evaporar suas dúvidas.
5. Se você entrou na sprint sem a mínima ideia do que será o produto final, adicione um dia. Todos os exemplos tratados no livro são muito tangíveis. Se você tiver que desenhar um produto novo, vai precisar de mais um dia, para garantir que problemas de fluxo, usabilidade e design não interfiram na validação.
6. Quando você tem um desafio muito concreto, do tipo "sabemos que temos um problema no carrinho de compras do ecommerce", sobra tempo. Antes de começar a sprint, já faça uma adaptação para tempos menores. Do contrário, fica entediante.

Dicas para o pós:

1. Design sprint premia muito a construção colaborativa. Mas não aborda como consolidar um material para ser apresentado a outras diretorias. Quando você rodar o método em uma empresa grande/multinacional, vai perceber que isso envolve muitas horas de trabalho e orçamento. Planeje-se para isso.
2. No fim, ter uma solução validada não quer dizer que você pode chamar o time de desenvolvimento e passar o bastão. A solução desenhada vai precisar ser detalhada e passar por todo o processo normal de desenvolvimento. A diferença é que a hipótese vai ter sido validada.

Concluindo (curti muito esse negócio de numerar):

1. Apesar da galera que escreveu o livro falar que não existe nenhum tipo de problema em que não possa ser aplicado o design sprint, eu indicaria muito mais para questões que envolvam negócios do que para desafios técnicos.
2. Os resultados do Design Sprint que temos obtidos são muito bons. Já é o nosso novo melhor amigo.

:)