Desconstruindo e adaptando a Design Sprint
Apesar de nunca ter aplicado antes já fazia um tempo que estudava e lia sobre o Design Sprint, framework criado pelo Google Ventures. Eu tentava entender como poderia utilizar em aqui dentro da Resultados Digitais, mas não tinha visto ainda como encaixar em algum projeto e ver ele rodando na prática.
Vejo também que frameworks devem ser adaptados às necessidades de cada projeto. O que funciona para alguns não garante que irá funcionar para todos. E em um dia de planejamento, reparei que o novo projeto tinha algumas peculiaridades que poderia se encaixar para utilizar um Design Sprint, desde que fosse adaptado.
O cenário do projeto era o seguinte:
- Tínhamos um problema bem definido, mas precisávamos ainda mapear os principais gaps com usuários e stakeholders;
- O protótipo final não era complexo e poderia ser validado de forma barata;
- Precisávamos validar um conceito rápido, a aposta era de 1 semana;
- Tínhamos 3 pessoas (2 designers e 1 PM) dedicadas full-time no projeto, e com possibilidade de envolver mais sob demanda.
Em cima disso fiz um primeiro esboço de agenda para redesenhar as etapas. Uma das premissas era focar mais dias em “discovery”, quebrando os problemas e identificando oportunidades com clientes e stakeholders. O desenho inicial dessa agenda ficou assim:
O que sabíamos que seria algo inviável era selecionar pessoas da RD que destinassem pelo menos 3 dias de trabalho imersos conosco, então levantamos pessoas chave que pudessem estar em cada etapa, pensando em como cada um poderia contribuir trazendo valor para o projeto.
Refinamos então esse planejamento, começamos os contatos e agendamentos de sala e fechamos da seguinte forma:
Segunda / Terça / Quarta:
3 dias de conversas para imergir no problema, falando tanto com clientes como stakeholders dentro da RD.
Quinta de manhã:
Brainstorm de possíveis soluções
Quinta de tarde:
Compilado e definição das principais apostas
Sexta de manhã:
Criação do protótipo baseado nas apostas
Sexta de tarde:
Validação do protótipo com usuários
Posso dizer que foram dias intensos e os resultados foram bem positivos, acredito que muito pela necessidade e tipo de projeto. Nesse primeiro teste com um Design Sprint, mesmo que adaptado, eu tirei algumas conclusões interessantes de compartilhar:
- Não sairá uma solução final: Não tenha a falsa expectativa de que irá sair com um protótipo validado e pronto para sem implementado. Há um bom trabalho a ser feito depois que a sprint termina.
- Nem todo projeto merece uma DS: É um erro pensar que qualquer projeto deva ser trabalhado com Design Sprint. Tem que se avaliar a complexidade e o quanto do problema já se sabe para conseguir resolver, pois ele é um framework para explorar e validar as melhores soluções, não é o memento de identificar um problema;
- Mindset de validar rápido: O principal objetivo de uma Design Sprint é pensar de que forma eu consigo pegar um problema e quebrar a ponto de conseguir chegar em uma solução, iterar e validar no menor espaço de tempo.
- Redução de risco: Chegando em solução rápida (e validada) se diminui o custo do projeto e principalmente o risco de despender muito tempo em algo que poderia ter tomado outro rumo.
- Adapte, aprenda e adapte: Cada caso tem suas necessidades e que devem ser pensados para adaptar o framework. Não penso que esse modelo utilizado será a forma que irei replicar para sempre, provavelmente será preciso avaliar como desenhar essa agenda para o próximo projeto.
Essa foi apenas uma das inúmeras formas de se utilizar a Design Sprint em um projeto. Se tiver alguma história pra compartilhar eu adoraria conversar a respeito :)
Quer integrar a equipe aqui na Resultados Digitais, acesse:
http://shipit.resultadosdigitais.com.br/trabalhe-conosco/
