Skip to content

Design Sprint

Histórico de Versão

Data Versão Descrição Autor(es)
03.02.2022 0.1 Criação do documento Nilvan Peres, Lucas Melo
04.02.2022 0.1.1 Revisão do documento Natanael Filho
11.03.2022 0.1.2 Padronizar estrutura Jonathan Jorge

Participantes

Introdução

A design sprint é uma técnica utilizada para acelerar desenvolvimento de projetos que estão na fase inicial e foi desenvolvido pela Google Ventures, são 5 dias de reuniões seguidos, e o principal objetivo é sanar dúvidas que podem comprometer o desenvolvimento do produto, otimizar tempo e validar as ideias de negócio a partir de testes. Ao invés de ter que esperar um MVP para conseguir inferir se o produto é de qualidade, essa técnica permite encurtar o tempo em apenas poucos dias, porém, são dias intensos.[1] Os fluxos da design sprint são:

Fonte: GV sprint[1]


A etapa 0, seria a de preparação para a design sprint, elaboração de um checklist para a cerimônia, e escolhas para a composição do time que fará parte do processo. O primeiro dia consiste em entender qual é o problema, explorando cada particularidade do mesmo, a fim de destrincha-lo em partes menores, que serão mais fáceis de serem entedidas. O segundo dia, consiste em esboçar possíveis soluções para esses problemas a partir de desenhos, para que o fluxo da solução comece a amadurecer, no começo a dinâmica deve ser livre e ao final os integrantes devem discutir as soluções, com o intuito de identificar pontos essenciais de cada proposta que foi desenhada. O terceiro dia, consiste em decisões, o que de fato fará parte do sistema a ser desenvolvido, nessa fase as ideias são refinadas e filtradas, a apenas um caminho é escolhido para ir para a próxima fase. O quarto dia, consiste em prototipar essa proposta de produto, a fim de ter um modelo fidedigno do projeto que será desenvolvido. O quinto dia. consiste na validação e verificação com stakeholders interessados no projeto a fim de testar o que faz sentido, o que precisa melhorar, e se o produto realmente é viável para ser desenvolvido.[2][3]


Metodologia

Realizamos a metodologia com adaptações que faziam sentido para o grupo, abaixo descreverei quais foram as adaptações em cada fase dessa técnica de desenvolvimento.
  • Unpack: Tivemos atividades síncronas e assíncronas e posteriormente nos reunimos para uma discussão para alinhar se todos estavam na mesma página sobre qual era o problema.
  • Sketch: Como essa parte é mais livre, primeiramente realizamos uma parte assíncrona onde todos podiam desenhar possíveis soluções da forma que achavam mais interessante, posteriormente nos reunimos para expor nossas proposta de soluções, e identificamos pontos fortes e fracos de cada solução para tentar elaborar e definir uma única solução compilada.
  • Decide: Nessa fase filtramos, e refinamos quais eram as principais funcionalidades, ou módulos que agregariam mais valor para o produto, e outros blocos que se implementados seriam um diferencial da aplicação.
  • Prototype: Essa fase ficou mais centrada na mãos de alguns integrantes, principalmente os que mais tinham domínio sobre a ferramenta do figma, só foi validado com os demais membros se o fluxo fazia sentido, e se a estrutura do protótipo estava aceitável para um versão inicial.


Resultados

Unpack

Para essa fase foi determinado a elaboração dos seguintes artefatos:

  • Brainstorm : Essa técnica serviu para cada membro da equipe mapear possíveis requisitos que cada usuário do sistema deveria ter, também foram levantados alguns requisitos não funcionais da aplicação.

  • Mapa mental: Técnica utilizada para organizar as ideias que surigiram no brainstorm, todos os integrantes fizeram seu próprio mapa mental, na tentativa de organizar e trazer mais clareza do escopo do projeto.

  • 5w2h: Artefato focado nos problemas, busca a resposta que o projeto tende a resolver.

  • Diagrama de causa-efeito: Essa técnica também é mais focado no problema, e faz uma classifcação dos mesmos em categorias diferentes.

Sketch

Para essa fase foi determinado a elaboração dos seguintes artefatos:

  • Rich picture: Artefatos no qual todos os integrantes do grupo participaram, com o intuito de desenhar as ideais que tiveram na fase anterior.

  • Protótipo de baixa fidelidade: Como essa fase é voltada para o rascunho, decidimos que um protótipo de baixa fidelidade iria trazer mais riqueza de detalhes para essa fase da design sprint.

  • Personas: Esse artefato foi desenvolvido para simular possíveis stakeholders interessados no projeto, e determinar melhor qual seria nosso público alvo principal, também visando melhorar essa fase da design sprint.

Decide

Após a realização da elicitação de requisitos foi realizado as seguintes técnicas para cotemplar a fase de decisão:

  • Storytelling: Utilizada com o auxílio de Personas, para o levantamento de requisitos mais precisos.
  • Introspecção: Foi a última técnica para elicitação de requisitos, com o intuito de tentar mapear requisitos ainda não explorados
  • Moscow: Artefato que filtrou todos os requisitos que foram levantados, e os priorizou deixando os que mais agregam valor como prioritários para serem desenvolvidos. Alguns requisitos também foram descartados.

Referências

[1] Design sprint - GV. Disponível em : https://www.gv.com/sprint/ . Acesso em 31: jan. 2022.

[2] Design sprint - Medium. Disponível em: https://medium.com/aela/design-sprint-como-acelerar-o-desenvolvimento-de-um-produto-767997de27c9. Acesso em 31: jan. 2022.

[3] Como funciona design sprint - Brasil UX design. Disponível em https://brasil.uxdesign.cc/google-design-sprint-como-funciona-e-como-aplicar-no-seu-projeto-279107363659. Acesso em 31: jan. 2022.

[4] Design sprint - Curumim. Disponível em : https://unbarqdsw2021-1.github.io/2021.1_G6_Curumim/base/design-sprint/doc-design-sprint/. Acesso em 3: fev. 2022.