Design Sprint da Vida Real

Uma sprint, partindo do livro Sprint de Jake Knapp, que trouxe esse método pra galera, serve basicamente para validar uma ideia de produto, antes de arcar com os custos de produção e implementação.

Quando eu li o livro fiquei animada com o método e vendemos para alguns clientes essa design sprint, mas já na primeira experiência dentro da Novatics (que não é uma grande corporação), percebi que não iria conseguir aplicar o método da Google Ventures, assim como mostra o livro.

Quando um cliente vai até uma empresa de desenvolvimento de software ele não quer validar uma ideia, ele quer executar a sua ideia. Isso não quer dizer que o método deva ser descartado, mas sim adaptado ao contexto. O entendimento do problema e do que deve ser feito para sair com uma solução ainda são de extrema importância para que não se tenha mais um produto fracassado no mercado.

A design sprint, no contexto da execução de uma ideia pronta, serve para garantir, ou ao menos tentar fortemente, não trabalhar em algo mirabolante que não atende aos usuários finais. E nesta adaptação, se tem, no final da semana, expectativas alinhadas, valor do produto definido, um backlogpriorizado, e um MVP (mínimo produto viável).

Vou compartilhar com vocês a adaptação que cheguei, até agora, da design sprint baseada nas minhas experiências. Abaixo eu descrevo um planejamento em formato de agenda semanal com as atividades de cada dia.

Dia 01: Mapeie

Time do projeto (designer, desenvolvedor, product manager etc) e cliente presentes (pessoas que entendem bem sobre o negócio ou estudaram o potencial). O objetivo deste dia é alinhar e contextualizar o cliente e o time sobre a semana, qual o objetivo e como alcançá-lo. E, em seguida, partir para a imersão de descobrimento e delimitação do problema.

Manhã

• Converse sobre a agenda da semana e a disponibilidade da equipe.

• Hora do cliente: Qual é o problema? Qual as expectativas? O que ele imagina como solução? Quais suas suposições? Quais os impedimentos? E as restrições?

Esse é um momento em que pode ser usado a primeira "ferramenta". Para o dia não parecer como uma grande reunião e melhor já começar movimentando a energia do local de trabalho. Então a primeira dica é: Não fiquem sentados. Para deixar o trabalho mais visível e interativo dê um jeito de criar grandes áreas demarcadas na parede para todo mundo poder colar em notas adesivas respostas para as perguntas. Um exemplo, muito bem feito (rs), abaixo:

Divida espaços, coloque os questionamentos e ponha a equipe para responder ativamente com notas adesivas.

• Converse sobre concorrentes e similares. É bom aproveitar as referências e visão do cliente, pois ele provavelmente sabe bem mais que você. O que ele vê como vantagem, desvantagem, diferencial etc. Certifique-se de entender como o problema é resolvido hoje e com quais auxiliares (sistemas, aplicativos, cadernos, força humana etc, que garantem que o trabalho seja feito hoje), sendo pelos concorrentes ou pelo próprio cliente/clientes do seu cliente.

Tarde

Depois de um almoço gostosinho (mas leve, vocês precisam de energia!), eu prefiro começar descobrindo, deixando claro, quem são os usuários finais e os stakeholders. Para isso eu uso a seguinte ferramenta:

Ferramenta de definição de usuários e stakeholders à esquerda, aplicação em projeto à direita.

Use notas adesivas para posicionar as pessoas e/ou cargos envolvidos. Usuários diretos no centro e stakeholders de fora. Quanto menor a conexão com o produto, mais longe do centro do círculo ele deve ser posicionado. E você pode usar código de cores para identificar prioridade ou intimidade com o produto (como exemplo usuário direto, usuário tangível, touchpointetc).

Após entender o conceito e expectativas do cliente, para quem vocês vão fazer o produto e como o processo funciona hoje, faça este mapeamento de forma visual. Construa o fluxograma, passo por passo, usando os resultado das ferramentas anteriores para atribuir ações e responsabilidades, mapeando inclusive outros tipos de touchpoints existentes (como envio de e-mails, documentos físicos, uso de banco de dados etc). Uma boa forma de mapear o processo, que eu julgo fácil de fazer e ler posteriormente, é usando a lógica do BPMN.

Imagens de um mesmo fluxo de solução: à esquerda formalizado, à direita brainstorming e montagem do fluxo.

Dia 02: Mapeie (de novo, a continuação)

Este tipo de trabalho é bastante cansativo e exaustivo, apesar da diversão intensa (hehe), então é bom ter grandes processos de imersão quebrados em dias. Dormir nas ideias também é bastante proveitoso e gerador de mais ou melhores ideias. Então o dia 02 é uma continuação do primeiro dia.

Manhã

• Revisite o que foi feito no dia anterior, especialmente o fluxograma do processo. Aproveite para já identificar que parte do processo se repete ou é o coração do negócio, pois aí você pode ter o seu MVP (olha aí!).

• Se você sentir a necessidade, parta para a criação de personas (se é que já não fez durante o mapeamento do processo). Tem um milhão de formas de criar personas. Para mim, qualquer uma serve, desde que essa persona tenha um apelido bastante característico, uma qualidade que a descreve, e uma "dor" predominante.

Se a equipe não criar personas pela manhã, parta para as próximas ferramentas que vou apresentar abaixo. Todo este planejamento por dia depende do andamento da equipe. Eu não as julgo obrigatórias para o processo, mas as considero muito boas para definir as funcionalidades que entrarão pro backlog do projeto.

• Faça a matriz de objetivos. Desenhe ou escreva a matriz como mostrada abaixo, tenha bastante canetas e notas adesivas e coloque a equipe para definir o que o produto é, não é, faz, não faz. Algumas perguntas podem ser feitas à equipe para facilitar o exercício, tais como: "o que você já escutou dos seus clientes que eles precisam?", ou "o que pode ser útil para eles e que eles não sabem que precisam?".

Matriz de objetivos à esquerda, aplicação em projeto à direita.

Tarde

Tome um cafezinho, revisite a matriz de objetivos, e parta para a definição das funcionalidades.

• Use a tabela personas vs. objetivos. Nesta ferramenta você vai cruzar os objetivos da matriz de objetivos com as personas que a equipe criou. Como a persona 1 conseguiria alcançar o objetivo 1? E a persona 2? e o objetivo 4? Os cruzamentos (anotados em notas adesivas pela equipe) serão as famigeradas funcionalidades do seu produto.

Ferramenta de definição de funcionalidades (personas vs. objetivos) à esquerda, aplicação em projeto à direita.

Você pode substituir a matriz de objetivos e o cruzamento objetivos vs. personas pela ferramenta de "Como poderíamos?" descrita no livro Sprint. Vocês vão chegar a ideias de funcionalidades também. Eu não curto muito, mas se a equipe estiver com dificuldades, ou o tempo corrido, é uma boa opção :)Os cruzamentos anotados pela equipe na tabela persona vs. objetivos serão nossas funcionalidades aqui. E toda a equipe vai analisar, votar e priorizar estas funcionalidades na famosa matriz relevância vs. esforço. Como nas imagens abaixo (tem várias matrizes similares que servem para priorizar), vocês vão classificar cada ideia/funcionalidade em relação ao seu grau de valor entregue (mais ou menos relevante) e o custo de implementar essa funcionalidade (mais ou menos esforço).

Um tipo de matriz relevância vs. esforço à esquerda, duas variações de aplicação da ferramenta à direita.

Importante: Essa fase de priorizar funcionalidades pode ser feita no dia 03! É crucial não forçar demais e terminar a tarefa de cabeça exausta. É importante respeitar o andamento da equipe, que também inclui o cliente. No dia 03 dá e sobra para fazer a priorização e a geração de alternativas!

O quadrante que será priorizado vai depender do projeto e do cliente. Esteja preparado. Ele tem uma mega ideia, onde o coração do produto é de grande relevância e alto custo de implementação, onde o risco é grande? Comece por aí! Valide esse rolê.

Funcionalidades de alta priorização e baixo esforço são passíveis de serem as primeiras funcionalidades entregues. Mas leve em consideração como a empresa, em que você trabalha, entrega o projeto. Se for por sprints(pequenas entregas em um espaço de tempo, que pode ir de duas semanas a um mês) tente adicionar uma e não mais que duas funcionalidades de alto esforço e alto valor, uma média de funcionalidades de médio esforço e completar com funcionalidades de baixo esforço para fechar fluxos de navegação completinhos por entrega.

Dia 03: Esboce

Agora sim vamos começar a criar! Ufa! Garanta que a equipe tenha fechado todas as atividades anteriores antes de começar as gerações de alternativas. E não tem problema não ter terminado, como mencionei anteriormente, termine nesta manhã. Então:

Manhã

• Faça uma retrospectiva dos dias anteriores (lembre-se que deve estar tudo visível, nas paredes etc) e priorize as funcionalidades usando a matriz relevância vs. esforço. Foquem em criar um backlog para o MVP, pois as ondas de entrega (sprints) podem ser feitas depois com a equipe interna e alinhadas com o cliente.

Tarde

Vamos iniciar a geração coletiva de alternativas. É muito bom criar todo mundo junto: designers (experts em usabilidade e experiência), desenvolvedores (que sabem das possibilidades e impedimentos técnicos de execução) e o cliente (que imagina a solução e tem milhares de expectativas) para ter estas diferentes visões e perspectivas de desenvolvimento de uma solução. Aqui o uso de intervalos de tempo para a execução das atividades é muito importante (falo mais no final do texto).

• Comece por um aquecimento. A ferramenta Crazy-8 é bem bacana para isso, especialmente para quem não está acostumado a manifestar as ideias no papel. Dobre uma folha A4 em 8 partes, criando 8 "telas". Em cada tela será desenhado um esboço de alternativa. Cronometre 1 minuto para cada tela, totalizando 8 min e 8 esboços. Depois, cole tudo na parede, e todo mundo deve apresentar suas 8 ideias, anotando palavras chaves próximas ao papel.

Deixe tudo visível ao time: fluxo, processos, geração. Crazy-8 na extrema direita.

• Com as cabeças fervilhando de ideias depois do aquecimento, façam desenhos da solução. Peça para cada um escolher uma tela ou um pequeno fluxo abarcando as funcionalidades priorizadas para o MVP, e desenhar um wireframe (ou mais de um) detalhado-os mais que os esboços do Crazy-8. Definam um intervalo de tempo de cerca de 10–15min para desenhar e apresentem logo em seguida. Faça essas rodadas quantas vezes forem necessárias para ter todas as telas do fluxo do MVP geradas.

Cole todas as telas, ordenadas e organizadas na parede e finalize o dia. Durante a noite, muitas pessoas tem novas ideias de solução para funcionalidades!

Crazy-8 e anotações de solução.

Dia 04: Decida e Construa

Chegou a hora de votar! Revise os wireframes com toda a equipe e use algo colorido como canetinha, adesivos, etc para cada um escolher uma alternativa por "tela". As telas mais votadas serão destacadas do montante e organizadas no fluxo do MVP. Se necessário, pois podem ter mais de uma tela bastante votada, em consentimento, redesenhem a tela com as características e funcionalidades presentes nas duas que foram predominantes e decisivas para a votação. Esta foi a manhã!

Tarde

Com o wireflow bem visível, adicionem partes do processo importantes de serem anotados, como envio de e-mails, documentos atrelados, as soluções e impedimentos para uploads de arquivos, se houver. Anotem também o que a equipe técnica levanta para o fluxo do MVP como integração com APIs externas, ou a serem desenvolvidas pela equipe.

Wireflow montado no Overflow (teste de baixa fidelidade).

É importante que as telas e o(s) fluxo(s) sejam construídos pela equipe, pois isso agiliza o processo de desenvolvimento. Se todo mundo sabe quais são as funções e onde vai o quê, enquanto o designer trabalha na UI, o desenvolvedor já pode garantir a estrutura do front (escolher frameworks, criar o repositório, montar ambiente de testes e outras tarefas iniciais. Não envolve implementar funcionalidades!).Então, finalizado o detalhamento do wireflow, o time pode começar a construir: prototipar as telas, fazer as provas de conceito, setup inicial do projeto etc.

Dia 05: Refine e Entregue

Dependendo do tamanho e complexidade do MVP, pode ser entregue um fluxo prototipado, de baixa, média ou até alta qualidade. Dependendo, esse protótipo pode ser um mock com o front já implementado.

Não tem tanto sentido dividir esse dia em manhã e tarde, e nem envolver o cliente, já que é uma parte mais técnica. Inclusive eu recomendo que o cliente participe apenas nos 3 primeiros dias (e início do dia 04). A impressão que eu tenho é que ele fica meio deslocado na parte de construção técnica do MVP, dependendo da proficiência dele.

Se for algo mais complexo, é mais produtivo os desenvolvedores se envolverem com a prototipação e uma maior definição da tela, e entregar uma navegação simulada no seu software de preferência (Invision, Overflow, etc), já que não dá tempo de implementar. E quanto mais fiel (fluxo e navegação, não a UI final) o MVP ficar para validação, melhor!

Prototipação usando o Craft (plugin do Invision para o Sketch) à esquerda e navegação desse protótipo no Invision.

Como vocês podem ver, não tem o dia de testar a solução, pois não é uma sprint para validar uma ideia, mas para executar essa ideia. E no fim desses 5 dias dá para entender bem o produto, seu valor, um backlog claro e com funcionalidades que a equipe e o cliente não tiraram de qualquer lugar. Além disso, temos um MVP navegável para validar tanto com o cliente, quanto com usuários finais ou stakeholders. Não é um teste de usabilidade, mas dá para apresentar de forma dinâmica para validar a solução como um todo.

Lembre-se. Documente tudo o que foi feito nesta semana! Pode ser chato, mas vale a pena. Deixe visível os resultados durante a execução do projeto e guarde no final para referência de futuros projetos!

Dicas quentes que eu aprovo: (1) defina um facilitador pra design sprint… e deixe apenas esta pessoa facilitar! Isso evita discussões sobre condução da semana na frente do cliente. (2) Garanta comida e bebida disponíveis todos os dias, especialmente nas partes da tarde, isso mantém a energia e disposição do time. (3) Não fique na mesma sala/ambiente o tempo todo/todos os dias. Isso drena a motivação e disposição de qualquer um. (4) Use intervalos de tempo definidos, como pomodoro, adaptado para vocês se necessário, para evitar o desgaste do time.

Espero que esse artigo seja útil para vocês! Quebrei algumas caras pra chegar até aqui e tenho certeza que ainda vou quebrar bastante, pois todo processo pode ser refinado. Existem muitas outras ferramentas que podemos testar e substituir, ou otimizar certas atividades. Enfim, compartilhem comigo nos comentários abaixo (ou em outras mídias) as suas experiências! O que deu certo? O que deu errado? Quais são as ferramentas que vocês usam?

Até a próxima!