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.

Um ciclo curto de Design Thinking cabe em uma conversa e um bloco de post-its. Um ciclo grande, com muita gente e um problema mal delimitado, precisa de ferramentas que organizem o pensamento: frameworks que dizem quando abrir e quando fechar o leque de opções, artefatos que mostram o fluxo inteiro (inclusive a parte que o usuário não vê) e técnicas de ideação que produzem volume antes de o time convergir para a primeira ideia razoável.

O framework organiza o trabalho em quatro fases que alternam divergência (gerar opções) e convergência (escolher entre elas):

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

O primeiro diamante responde "qual problema?" e o segundo responde "qual solução?". Times que começam pelo segundo diamante produzem uma solução elegante para um problema que ninguém tem.

O blueprint coloca lado a lado o que o usuário faz e as operações internas que sustentam cada passo. Ele mostra o caminho completo, inclusive a validação manual que alguém faz no escritório entre o clique do usuário e a confirmação na tela.

Estrutura em camadas:

O blueprint revela onde a experiência do usuário depende de um processo interno frágil. Uma tela impecável que espera três dias por uma aprovação manual parece ótima no wireframe e ruim no blueprint.

O Journey Map completo registra mais que a sequência de passos. Para cada etapa, ele responde:

Com o mapa completo, o time enxerga a experiência inteira em vez de telas isoladas. As etapas de maior fricção emocional costumam ser as de maior retorno quando melhoradas.

A ideação sem estrutura produz as ideias óbvias nos primeiros minutos e depois estagna. As técnicas abaixo empurram o time para fora dessa zona.

Cada participante desenha oito ideias diferentes em oito minutos, uma por minuto. O relógio apertado deixa pouco espaço para o julgamento interno, que é o que costuma barrar a ideia estranha antes dela ser desenhada.

Regras:

O padrão do resultado se repete: as três primeiras ideias são as óbvias, as três do meio são versões melhoradas das previsíveis, e as duas últimas costumam trazer o que ninguém tinha considerado.

Checklist de transformações aplicadas a uma ideia que já existe:

O SCAMPER precisa de uma ideia-base para explorar. Ele serve para gerar variações, e não para partir do zero.

Uma ideia central gera oito variações, e cada variação gera outras oito, o que produz 64 ideias ligadas ao tema. Serve quando o problema é amplo e o time precisa mapear o espaço todo antes de escolher por onde ir.

O time compara o problema com um domínio sem relação alguma: "Como um restaurante lidaria com isso? Como um aeroporto faria?". A comparação traz soluções já testadas em outro contexto, e algumas se adaptam.

Cada estágio de protótipo responde uma pergunta diferente. Subir a fidelidade antes da hora gasta trabalho em detalhes visuais que a próxima descoberta vai mudar.

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

Usar o estágio errado para a pergunta em jogo custa tempo e produz confiança sem base: um mockup bonito convence a diretoria de uma ideia que ninguém testou com usuário.

Ambos entregam menos que o produto completo. O que muda é a pergunta que cada um responde.

O MVP tolera uma UX (User Experience · Experiência do Usuário) desagradável, desde que a hipótese seja validada. O MLP precisa de qualidade de experiência, porque a pergunta dele é se o usuário volta a usar.

A fase decide: descoberta de problema pede MVP, validação de adoção pede MLP.

O teste procura os pontos em que a interface falha na mão de um usuário real. Uma sessão desenhada para confirmar que a interface funciona costuma conseguir exatamente isso, e não ensina nada.

O usuário narra o raciocínio em voz alta 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 expõe o que o usuário esperava encontrar. No exemplo, ele procura "pedidos" no menu e acaba em "perfil", o que indica um rótulo que o produto escolheu e o usuário não usa.

As métricas mostram a tendência e o tamanho do problema. A observação qualitativa explica a causa do número.

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

Cada item pendente é uma hipótese que ninguém validou. Ela continua existindo depois do deploy, e quem valida passa a ser o usuário em produção.

DoDocs v3.7.0 · Desenvolvido por @thiagocajadev · Baseado no trabalho de pmndrs/docs · Poimandres.