Design thinking advanced

Escopo: transversal. Aplica-se a qualquer linguagem ou stack do projeto.

Avançado em relação a design-thinking.md. Cobre técnicas estruturadas de descoberta, ideação e validação.

Ciclos maiores de Design Thinking exigem ferramentas mais formais: frameworks que orientam o pensamento, artefatos que visualizam fluxo completo, técnicas de ideação que produzem volume sem convergência prematura.

Framework que organiza Design Thinking em quatro fases alternando divergência e convergência:

Discover → Define → Develop → Deliver
(diverge)  (converge) (diverge)  (converge)

O primeiro diamante responde "qual problema?". O segundo responde "qual solução?". Pular o primeiro diamante leva a resolver o problema errado com solução elegante.

Jornada do usuário mais as operações internas que a suportam. Mostra o que o usuário vê e o que acontece nos bastidores para que o fluxo funcione.

Estrutura em camadas:

Service Blueprint expõe pontos onde a experiência do usuário depende de processos internos frágeis. Gargalo que não aparece em wireframe aparece no blueprint.

Journey Map completo vai além da sequência de passos. Para cada etapa, registra:

O mapa permite ver a experiência inteira, não só telas isoladas. Pontos de maior fricção emocional tendem a ser pontos de maior valor de melhoria.

Ideação não estruturada produz as ideias óbvias em poucos minutos e depois estagna. Técnicas forçam saída da zona óbvia.

Cada participante desenha oito ideias diferentes em oito minutos, uma por minuto. A pressão de tempo bloqueia o julgamento interno e força quantidade.

Regras:

O resultado: as três primeiras ideias são óbvias, as três do meio são as previsíveis melhoradas, as duas últimas costumam ser as inesperadas.

Checklist de transformações aplicadas a uma ideia existente:

SCAMPER funciona quando há uma ideia-base para explorar variações.

Estrutura expansiva: uma ideia central gera oito variações, cada variação gera outras oito. Produz 64 ideias relacionadas ao tema central.

Útil quando o problema é amplo e o time precisa mapear o espaço antes de convergir.

Comparar o problema com um domínio não-relacionado: "Como um restaurante lidaria com isso? Como um aeroporto faria?". A analogia traz soluções testadas em outro contexto que podem ser adaptadas.

Protótipos crescem em fidelidade conforme a dúvida diminui. Subir a fidelidade cedo desperdiça esforço em detalhes que vão mudar.

Esboço em papel → Wireframe → Mockup → Protótipo interativo
(fidelidade baixa)                    (fidelidade alta)

Cada estágio responde uma pergunta diferente. Usar o estágio errado para a pergunta custa tempo e cria falsa confiança.

Ambos são versões reduzidas do produto, mas com objetivos distintos:

MVP pode ter UX (User Experience, Experiência do Usuário) desagradável desde que valide a hipótese. MLP precisa de qualidade de experiência para gerar retorno real do usuário.

A escolha depende da fase: descoberta de problema usa MVP, validação de adoção usa MLP.

Observação estruturada de usuário real usando a solução. O objetivo é encontrar os pontos onde a interface falha, não provar que ela funciona.

O usuário narra o raciocínio enquanto executa a tarefa:

Usuário: "Agora eu quero ver meus pedidos anteriores. Vou procurar... estou olhando
o menu... não vejo 'pedidos'... vou clicar em perfil."

A narração revela expectativas implícitas e pontos onde a interface não corresponde ao modelo mental do usuário.

Métricas quantitativas orientam tendências. Observação qualitativa explica o porquê por trás dos números.

Antes de entregar uma solução como pronta para implementação:

Itens pendentes indicam hipóteses não validadas. Construir antes de validar transfere a validação para produção, com custo maior.

Desenvolvido por @thiagocajadev · Fork baseado no repositório pmndrs/docs · Poimandres.