Design thinking

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

Design Thinking é o raciocínio feito antes de decidir o que construir. Parte do usuário real, do problema real, e chega à solução por etapas que podem ser descartadas sem custo de implementação. Construir sem esse raciocínio resolve o problema errado com precisão.

Design Thinking responde perguntas que implementação não resolve sozinha:

Sem essas respostas, o time constrói o que assume ser o necessário. Com elas, a solução tem critério de aceitação independente da implementação.

O processo canônico tem cinco fases que se alimentam. Não é estritamente linear: descobertas tardias podem exigir voltar a uma fase anterior.

Empathize → Define → Ideate → Prototype → Test

Cada fase produz algo descartável. O custo de descartar uma ideia na fase Ideate é uma folha de papel. O custo de descartar uma feature em produção é significativo.

Entender o usuário no contexto dele. Não o usuário ideal, não o que se supõe, o usuário real.

Técnicas comuns:

Escutar importa mais que perguntar. O usuário frequentemente descreve o sintoma, não a causa.

Transformar o entendimento do usuário em um enunciado de problema. Um bom problem statement é específico, acionável e centrado em necessidade, não em solução.

Ruim:  "Precisamos de um dashboard para o gestor"
Bom:   "O gestor precisa saber em 30 segundos se o time está no prazo, sem abrir relatórios"

Dois artefatos ajudam a enquadrar:

Aprofundamento em journey maps e service blueprints fica em design-thinking-advanced.md.

Gerar soluções sem filtro prematuro. A regra central é separar quantidade de qualidade: primeiro produzir muitas ideias, depois avaliar.

A pergunta que abre ideação é HMW (How Might We, Como Poderíamos):

Problema:  "O gestor perde tempo abrindo relatórios"
HMW:       "Como poderíamos entregar a informação crítica sem exigir ação?"

HMW é aberto o suficiente para admitir várias respostas, específico o suficiente para descartar as irrelevantes.

Materializar uma ideia com o menor custo possível. O protótipo não é o produto; é o argumento de que a ideia resolve o problema.

Começar em alta fidelidade é uma das formas mais eficientes de desperdiçar tempo. A ideia errada em baixa fidelidade custa horas; em alta fidelidade, custa semanas.

Entregar o protótipo a usuários reais e observar. O objetivo não é provar que a solução está certa; é descobrir onde está errada.

Princípios:

Uma sessão de teste bem-feita produz ajustes concretos. Sessão sem achado é sinal de teste mal desenhado ou usuário mal escolhido.

Design Thinking responde o que construir. A execução visual e de interação responde como apresentar.

Confundir Design Thinking com UI (User Interface, Interface do Usuário)/UX (User Experience, Experiência do Usuário) é comum. UI/UX é a execução visual do que Design Thinking decidiu construir.

Começa: quando existe um problema percebido, antes de existir uma solução proposta.

Termina: quando existem respostas para as quatro perguntas:

Respondidas essas perguntas, o próximo passo é execução: ui-ux.md para apresentação, methodologies.md para implementação, system-design.md para raciocínio arquitetural. Aprofundamento em técnicas de ideação, service blueprint e usability testing fica em design-thinking-advanced.md.

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