Skip to content

1.1. Módulo Design Sprint

Usando a lista de projetos indicados por grupo para o período letivo vigente, realizar Design Sprint para levantamento dos requisitos.

Estrutura do Design Sprint

Compreender (Unpack)

No contexto de desenvolvimento de uma nova solução ou projeto, faz-se necessário executar um planejamento, tal como a compreensão do domínio em que esse projeto está inserido, suas possíveis problemáticas, hipóteses e certezas. Dentre diversas propostas de metodologia para executar essa etapa, pode-se destacar a Design Sprint — desenvolvida pela Google Ventures — mais especificamente a etapa Unpack, ou traduzido, “Desempacotar“. Assim, este documento tem como objetivo apresentar o artefato documental resultante da fase Unpack da Design Sprint. Nesta etapa, a equipe mergulha no problema central do projeto, buscando compreender o contexto, as causas e os desafios relacionados ao universo ao qual o projeto está inserido. A motivação para a elaboração deste artefato reside na necessidade de formalizar e centralizar as descobertas, servindo como uma base de conhecimento acessível para toda a equipe e futuras consultas. Além disso, justifica-se a utilização de tal etapa, composta ao contexto da Design Sprint, por sua agilidade; isto é, em um contexto em que tempo e recursos são escassos, metodologias que priorizem a entrega rápida e aloquem seus esforços às expectativas dos stakeholders tendem a ter melhor desempenho e resultados em relação a perspectivas mais orientadas a planos. Portanto, dados tais aspectos alinhados ao contexto do presente projeto, justifica-se a utilização da prática da Design Sprint e, por conseguinte, a fase de abertura da sprint: Unpack.

Metodologia

A fase Unpack foi conduzida utilizando uma combinação de técnicas de elicitação e análise, adaptadas para a dinâmica da Design Sprint. A técnica central de elicitação foi o Brainstorming, permitindo a geração de uma diversidade de ideias e informações de forma colaborativa. Para documentar e guiar a análise dos problemas identificados, foram empregados alguns artefatos, com destaque para a adaptação da técnica Rose, Thorn, Bud, o Diagrama de Causa-Efeito (Diagrama de Ishikawa) e a metodologia 5W2H. Nesse interim, o Brainstorming ocorreu de forma presencial durante uma aula de dinâmica de grupos proposta na disciplina de Arquitetura e Desenho de software, compondo-se dos integrantes da equipe e da professora Dr.ª Milene Serrano para a dinâmica de geração de ideias. Em mérito material, utilizou-se um Mapa de Ideias (whiteboard e post-its) virtuais utilizando o Miro para organizar e visualizar as informações.

Rose, Thorn, Bud (Adaptada)

Adaptamos a técnica Rose, Thorn, Bud para avaliar o contexto inicial. Os elementos originais que compõem essa técnica, são:

  • Rose (Pontos Positivos): Foram identificados os aspectos que estão funcionando bem e que devem ser mantidos (Nome utilizado).
  • Thorn (Espinhos): Mapeamos os pontos de fricção, problemas e obstáculos.
  • Bud (Brotos): Exploramos as oportunidades de crescimento e as ideias promissoras.

Para o contexto da adaptação, foi utilizado o seguintes:

  • Certezas: No lugar de Rose, foi alocado os aspectos de certezas vinculados ao domínio do projeto, isto é, processos e aspectos de regra de negócio, tal como fatores adjacentes.
  • Brotos: Se manteve alinhado à proposta de Bud.
  • Problemas: Apesar de ligeiramente distinto, a ideia ainda é mapear problemas no contexto do projeto.
  • Stakeholders: Esse foi adicionado, para distinguir dos demais, pois são uma intersecção da classificação certezas e brotos, em mérito de potenciais stakeholders para o desenvolvimento do projeto.

Execução e Resultados

A aplicação das metodologias resultou na identificação de pontos-chave e na obtenção de um entendimento compartilhado sobre o desafio. Abaixo, segue a implementação propriamente das técnicas, seguindo de seus resultados.

Brainstorming

O Brainstorming ocorreu de forma presencial, em uma dinâmica proposta durante a aula de Arquitetura e Desenho de Software. A sessão envolveu a equipe do projeto e a professora para uma sessão de geração de ideias. As ideias foram organizadas e visualizadas em um Mapa de Ideias no Miro, usando um whiteboard virtual e post-its, vinculado ao artefato Rose, Thorn, Bud (técnica Unpack da Google Ventures). Segue abaixo algumas definições do processo, assim como o BPMN dessa parte.

Anexar BPMN do Brainstorming: a ser adicionado.

Pré-condições do Brainstorming

  1. Definir Objetivos de Brainstorming: alinhado à técnica Rose, Thorn, Bud detalhada acima.

  2. Selecionar participantes: A partir da lista de Stakeholders, é selecionado os participantes para a dinâmica. Depois, envia-se o pedido de participação para os selecionados que, confirmados, estão aptos à ingressarem na dinâmica. Segue abaixo a lista de participantes presentes nessa etapa:

Nome Papel
Mateus Villela Facilitador/Mediador
Milene Serrano Contribuidor
Paulo Henrique Contribuidor
Letícia da Silva Contribuidor
Henrique Martins Contribuidor
Eduardo Contribuidor
Daniel Ferreira Contribuidor
Breno Alexandre Contribuidor
Víctor Moreira Contribuidor

  1. Seleção do mediador:
    Mateus Villela (representante do módulo Base).

  2. Preparação do meio material: Antes de iniciar, é necessário preparar os materiais para realizar o brainstorming. Nesse contexto, os seguintes materiais foram selecionados:

    • Notebook ou celular para utilização do whiteboard e post-its da ferramenta Miro.
    • Internet: utilizou-se a disponibilizada pela UnB.
    • Seleção da sala para ocorrer a reunião: S7 (UAC - UnB).

Dinâmica e Resultado

  • Duração da dinâmica: 30-40 min aproximadamente.
  • "Vez de falar": bate-papo intermediado por facilitador, visando equilibrar as vozes de contribuição.
  • Resultado do Whiteboard de mapa de ideias:

Refinamento do Brainstorming

Com o intuito de agragar na etapa 1 da design sprint, foi utilizado alguns artefatos generalistas, pra melhor desmembrar o universo vinculado ao projeto. Assim, segue abaixo tais artefatos que foram inspirados nos resultados do Brainstorming.

Diagrama de Causa-Efeito (Diagrama de Ishikawa)

Utilizamos o Diagrama de Causa-Efeito para analisar e identificar as causas-raiz de um dos principais problemas do projeto. A análise revelou diversas categorias de causas, como recursos, pessoas, processos e ferramentas.

Diagrama de Ishikawa

Metodologia 5W2H

A técnica 5W2H foi aplicada para detalhar as ações e plano de solução, ajudando a esclarecer: What (O quê), Why (Por quê), Where (Onde), When (Quando), Who (Quem), How (Como) e How much (Quanto).

5W2H

Conclusão

A fase Unpack foi fundamental para alinhar a equipe em torno do problema central e construir uma base sólida de conhecimento. A aplicação das técnicas mencionadas, especialmente a adaptação do Rose, Thorn, Bud e a utilização do Diagrama de Ishikawa, permitiu uma visão holística e aprofundada das complexidades do projeto. O uso do Mapa de Ideias se mostrou crucial para a visualização dosos conceitos, facilitando a identificação de padrões. No próximo topico, segue para a etapa de esboço do Design Sprint.

Referencias Bibliograficas

Histórico de Versão

Id Descrição Autor Revisor Data
1.0 Criação inicial do documento Mateus Paulo 05/09/2025
1.1 Desenvolvimento da etapa 1 (Unpack) da Design Sprint Mateus Paulo 05/09/2025

2. Esboçar (Sketch)

Introdução

Na etapa de esboço (sketch) do Design Sprint, a atenção se volta para converter ideias em representações visuais palpáveis. Depois de compreender o problema, investigar o desafio e buscar referências na fase anterior (entender), avançamos para dar forma gráfica às propostas, mesmo que de maneira simples ou conceitual. O propósito é materializar o pensamento, possibilitando a comparação de diferentes alternativas antes de escolher o caminho definitivo.

Objetivo da Etapa

O esboço funciona como elo entre conceito e prática. É o momento em que as ideias deixam o campo abstrato e passam a ser visualizadas no papel. Essa representação inicial é essencial para validar suposições, detectar pontos fracos e incentivar a colaboração do time na busca pela solução mais adequada ao desafio.

Processo

Ao longo do Design Sprint, lidamos com limitações de tempo, o que exigiu dividir as atividades entre os integrantes do grupo, de acordo com as fases do método. Dessa forma, cada participante assumiu responsabilidades específicas, alinhadas às suas competências e ao tempo disponível.

Na fase de esboçar, realizamos uma distribuição planejada das tarefas, garantindo que os aspectos visuais e conceituais mais relevantes do projeto fossem contemplados, sendo parte dessa etapa feita no ambiente da sala de aula, conforme descrito na tabela 1.

Tabela 1: Distribuição das tarefas durante a etapa de esboçar do Design Sprint

Membro(s) da Equipe Tarefa Realizada Descrição
Luiz Mapa mental Estruturou as ideias principais e secundárias do projeto(Feito presencialmente).
Henrique Rich Picture Representou visualmente o fluxo da solução proposta, passo a passo(Feito em reunião).
Paulo, Daniel e Eduardo Diagrama de Causa e Efeito Identificou os principais problemas e suas causas relacionadas(Feito em reunião).

Autor: Paulo Cerqueira, 2025.

Histórico de Versão

Data Versão Descrição Autor Data da Revisão Revisor
04/09/2025 1.0 Adicionado o esboçar Paulo Cerqueira 05/09/2025 Mateus Vilela

3. Decidir (Decide)

Introdução

A fase de decisão no Design Sprint é crucial, pois marca o momento em que, após reunir informações, definir requisitos e consolidar os artefatos anteriores, é preciso escolher com clareza os próximos passos do projeto. Essa definição evita bloqueios no processo e garante que a metodologia ágil siga em fluxo contínuo, sem interrupções ou retrabalhos desnecessários.

Objetivo

O propósito desta etapa é registrar como ocorreu a priorização e a escolha dos requisitos mais importantes, bem como indicar quem foram os responsáveis por cada decisão e em qual parte do projeto os documentos resultantes estão armazenados. Dessa forma, cria-se uma visão organizada e transparente sobre as escolhas realizadas.

Processo

Técnica Utilizada: Rumble or All-In-One

Nesta etapa, aplicamos a técnica Rumble or All-In-One, uma prática comum no Design Sprint para decidir qual solução deve avançar. Essa técnica funciona de duas maneiras:

Rumble: cada equipe ou participante cria uma versão própria da solução, permitindo a comparação entre alternativas diferentes. Depois, avalia-se qual delas tem maior potencial para atender ao desafio.

All-In-One: ao invés de dividir, combina-se as melhores partes das ideias em uma única proposta unificada, que concentra os pontos fortes identificados nas alternativas.

A escolha entre “Rumble” ou “All-In-One” depende do contexto do desafio: se a equipe deseja testar soluções radicalmente distintas, opta-se pelo Rumble; se o objetivo é consolidar forças em uma proposta mais robusta, recorre-se ao All-In-One. Essa abordagem garante decisões mais conscientes e alinhadas às metas do projeto.

Histórico de Versão

Data Versão Descrição Autor Data da Revisão Revisor
05/09/2025 1.0 Criação do documento Paulo Cerqueira 05/09/2025 Mateus Vilela

4. Prototipar (Prototype)

Introdução

A prototipação é uma etapa essencial no desenvolvimento de produtos, especialmente em projetos de software. Consiste na criação de modelos iniciais que simulam funcionalidades e interfaces, permitindo a validação de ideias, identificação de falhas e refinamento de requisitos antes do investimento em desenvolvimento completo. Essa abordagem reduz custos, melhora a comunicação entre equipes e garante maior alinhamento com as expectativas dos usuários.

Metodologia

Optamos por desenvolver um protótipo de alta fidelidade utilizando a plataforma Figma, visando proporcionar uma visão clara e interativa do produto final.

Os membros envolvidos na elaboração do protótipo foram:

  • Letícia Monteiro
  • Daniel Ferreira
  • Paulo Cerqueira

Resultados

5. Validação - Design Sprint: Dicas de Estágio

1. Objetivos de Validação

O objetivo principal da validação é testar o protótipo de alta fidelidade com usuários reais para aprender o que funciona, o que não funciona e como melhorar o produto antes de qualquer desenvolvimento dispendioso.

  • Objetivos de Aprendizado:

    • Validar se a proposta de valor (conectar estudantes a dicas de estágio valiosas) é clara e atraente.
    • Identificar pontos de atrito no fluxo de navegação e usabilidade da interface.
    • Coletar feedback sobre a clareza e utilidade.

  • Métricas de Sucesso Qualitativas:

    • Reação Emocional: Entusiasmo, confusão ou frustração durante a apresentação do protótipo.
    • Intenção de Uso: Se o usuário expressa desejo de usar o produto no futuro.
    • Compreensibilidade: Se o usuário entende o propósito do app sem explicações prévias.

2. Preparação para a Validação

a) Participantes

  • Perfil Alvo: Estudantes universitários de qualquer semestre, que estejam ativamente buscando ou realizando estágios.
  • Quantidade: Pelo menos 1 usuário.

b) Protótipo e Ambiente de Teste

  • Ferramenta de Prototipagem: Figma.
  • Estado do Protótipo: Estático e de alta fidelidade, simulando o visual desejado do produto.
  • Configuração do Teste: O teste será realizado presencialmente. A sessão será gravada (com consentimento) para análise posterior.

```

3. Roteiro da Sessão de Validação (Script)

Duração Total: 37 minutos por sessão.

Tempo Fase Objetivo Perguntas/Tarefas Chave Importância
2 min Introdução Explicar o formato. "Agradeço por participar. Hoje vamos testar um protótipo de um novo app." Baixa
5 min Contexto & Hábitos Entender o background do usuário. "Você já buscou informações sobre estágios? Se sim, onde? E como foi sua experiência?" Alta
25 min Teste do Protótipo Coletar feedback. Tarefa 1: "Com base no protótipo, qual sua opinião sobre o design escolhido?"
Tarefa 2: "Sobre as funções, quais você acha mais importantes e quais você acha que estão faltando?"		 Alta
5 min Debriefing & Encerramento Coletar impressões gerais e agradecer. "No geral, o que você achou? Você usaria um app como esse? Algo que poderia mudar?" Alta

4. Papéis e Responsabilidades da Equipe

  • Facilitador/Interviewer (1 pessoa): Conduz a sessão, faz as perguntas e guia o participante. Deve criar um ambiente confortável e neutro.
  • Reporter/Anotador (1 pessoa): Responsável por tomar notas detalhadas em tempo real, focando em citações literais e comportamentos observados. Pode usar uma planilha compartilhada.

5. Técnica de Análise de Dados: Mapeamento de Padrões

Após a sessão, os dados serão revisados pela equipe e usados para ver se os resultados são esperados ou não.

  1. Compilação de Notas: A gravação será publicada e adicionada ao Pages.
  2. Identificação de Padrões: A equipe busca por:
    • Problemas de Usabilidade: Onde o usuário se frustrou.
    • Reações Positivas: O que os usuários amaram e elogiaram.
    • Insights Surpreendentes: Comportamentos ou feedbacks não antecipados.
  3. Priorização: Os problemas são categorizados por Gravidade (Bloqueador, Major, Minor).

6. Resultados e Próximos Passos

Vídeo da validação com usuário

Com base na análise, o resultado da validação se enquadrará em uma de três categorias:

Resultado Descrição Ação Recomendada para o Projeto
Sucesso A maioria das ideias funcionou; o conceito central foi validado. Iterar no protótipo: Ajustar os problemas de usabilidade identificados e prosseguir para o desenvolvimento.
Misto Algumas coisas funcionaram, outras falharam criticamente. Iterar profundamente: Manter as soluções que funcionaram e refazer as que falharam. Realizar um novo ciclo de teste focado nas partes problemáticas.
Falha O conceito central não foi compreendido ou foi rejeitado pelos usuários. Refazer: Reavaliar a premissa do problema e as suposições iniciais. É um ótimo aprendizado que evitou um grande desperdício de recursos.

Decisão Final do Decider: * [X] Prosseguir para desenvolvimento * [X] Realizar uma segunda sprint de iteração * [ ] Redefinir o escopo e a direção do projeto

Extras: O entrevistado aprovou e gostou da ideia do projeto e deu o aval para prosseguir com a maioria das coisas. Algumas ideias chave já foram implementadas no planejamento de produto final e os elementos de design que foram classificados como "quebrados" já foram comunicados para a modificação, e por isso está marcada a opção de uma segunda sprint, para poder ajustar esses problemas e dialogar sobre possíveis melhorias.

7. Checklist de Validação

  • [X] Protótipo estático de alta fidelidade finalizado.
  • [X] Roteiro de entrevista aprovado pela equipe.
  • [X] Tecnologia (gravação) testada e funcionando.
  • [X] Sessão realizada e notas detalhadas tomadas.
  • [ ] Reunião de síntese e análise realizada com a equipe de validação.
  • [ ] Relatório de insights e plano de próximos passos definido e acordado com toda a equipe.

Referências

Histórico de Versão

| Versão | Descrição | Autor | Revisor | Data | | ------ | ------------------------- | -------------- | ------------- | | 1.0 | Criação do documento | Paulo Cerqueira | Daniel Ferreira | | 1.1 | Adição da etapa Sketch | Henrique Martins Alencar | |