---
title: "Problem framing em UX: como definir o problema antes da solução"
date: 2026-08-26T12:30:00Z
modified: 2026-08-26T14:46:51Z
permalink: "https://camaraux.com.br/problem-framing-ux/"
type: post
status: publish
excerpt: "Aprenda a fazer problem framing em UX: definir, investigar e reenquadrar problemas com contexto, evidências, hipóteses e critérios de decisão."
wpid: 12462
categories:
  - Produto & Estratégia
rank_math_title: "Problem framing em UX: como definir o problema"
rank_math_description: Entenda como fazer problem framing em UX para separar problema, sintoma, oportunidade e solução antes de decidir o que construir.
rank_math_focus_keyword: problem framing
featured_image: /wp-content/uploads/2026/08/thumbnail-problem-framing-ux.png
featured_image_alt: Duas pessoas observam caminhos que saem de um emaranhado e se tornam alternativas organizadas, representando problem framing em UX.
author: Lucas Camara
timestamp: 2026-08-26T14:46:51Z
tags:
  - Produto & Estratégia
---

**Problem Framing é o processo de investigar, delimitar e formular um problema antes de decidir como resolvê-lo.** Em UX e Product Design, isso significa transformar demandas como “precisamos melhorar o cadastro”, “a conversão está baixa” ou “vamos criar uma nova tela” em uma situação que possa ser investigada com evidências. O objetivo não é produzir uma frase bonita para justificar uma solução já escolhida, mas construir uma interpretação provisória sobre quem enfrenta a dificuldade, em qual contexto, o que realmente sabemos, o que ainda estamos supondo e qual decisão precisa ser tomada.

A forma como um problema é enquadrado influencia diretamente o espaço de soluções que o time passa a considerar. Kees Dorst trata _framing_ e criação de novos enquadramentos como práticas centrais do raciocínio de design, especialmente quando trabalhamos com situações abertas, ambíguas ou que podem ser interpretadas de maneiras diferentes. Em outras palavras, antes de perguntar “qual solução devemos construir?”, precisamos entender se estamos fazendo a pergunta certa.

## O que é Problem Framing em UX?

_Problem Framing_, ou enquadramento do problema, é o trabalho de construir uma representação útil de uma situação problemática para orientar pesquisa, priorização e tomada de decisão. Um bom enquadramento explicita quem está sendo afetado, o que essa pessoa tenta realizar, em qual contexto a dificuldade aparece, quais evidências sustentam nossa interpretação, quais hipóteses ainda precisam ser verificadas e qual impacto torna aquele problema relevante.

Isso não significa que o time precisa descobrir uma verdade definitiva antes de começar. O enquadramento funciona melhor como uma **hipótese de trabalho**: uma descrição suficientemente clara para orientar os próximos passos, mas aberta o bastante para ser revista quando entrevistas, testes, dados de uso, suporte, restrições técnicas ou contexto de negócio revelarem algo novo.

Essa lógica aparece também no [Double Diamond do Design Council](https://www.designcouncil.org.uk/resources/the-double-diamond/). Na etapa de descoberta, a recomendação é compreender o problema em vez de simplesmente assumi-lo. Depois, os aprendizados são sintetizados para definir o desafio que realmente merece atenção. O próprio Design Council ressalta que esse processo não precisa ser linear: novos aprendizados podem fazer a equipe retornar ao problema e revisar o enquadramento.

[![Double Diamond do Design Council com as etapas Discover, Define, Develop e Deliver](https://www.designcouncil.org.uk/fileadmin/uploads/dc/Photos/banners/Double_Diamond.png)

](https://www.designcouncil.org.uk/resources/the-double-diamond/)O primeiro diamante amplia e depois delimita a compreensão do problema antes da exploração de soluções. Fonte: Design Council. Imagem licenciada sob CC BY 4.0.## Por que enquadrar o problema antes de pensar na solução?

Porque uma solução pode ser muito bem projetada e ainda assim resolver o problema errado. Imagine que os dados mostrem uma queda expressiva em uma etapa de cadastro. Uma reação rápida seria concluir que “o formulário precisa ser simplificado”. O problema é que o abandono observado é um sintoma, enquanto a explicação sobre o formulário ainda é uma hipótese.

As pessoas podem não ter um documento disponível naquele momento, podem não entender por que determinada informação é solicitada, podem desconfiar do serviço ou simplesmente ter descoberto naquela etapa uma condição que não conheciam anteriormente. Cada explicação cria um espaço diferente de investigação e, consequentemente, diferentes possibilidades de solução.

Quando o time decide muito cedo que o formulário é o problema, o projeto passa a operar dentro desse enquadramento. A partir daí, existe o risco de pesquisas, métricas e discussões serem usadas apenas para justificar uma solução que já estava implicitamente escolhida. O trabalho de framing interrompe essa sequência e obriga a equipe a distinguir o que foi observado daquilo que está sendo interpretado.

## Sintoma, problema, hipótese, oportunidade e solução são coisas diferentes

Grande parte da dificuldade em definir problemas de UX acontece porque conceitos diferentes são tratados como equivalentes. Uma métrica vira “problema”, uma hipótese vira “causa” e uma ideia de funcionalidade aparece na discussão como se fosse consequência inevitável dos dados. Separar essas camadas torna o raciocínio mais verificável.



| Elemento | O que representa | Exemplo |
| --- | --- | --- |
| **Sintoma** | Algo que foi observado | Muitas pessoas abandonam o cadastro |
| **Problema** | Uma dificuldade situada que merece investigação | Pessoas chegam à etapa de documento sem saber previamente o que será exigido |
| **Hipótese** | Uma possível explicação ainda não confirmada | A falta de preparação pode estar aumentando o abandono |
| **Oportunidade** | Uma direção de valor que pode ser explorada | Tornar os requisitos do cadastro mais previsíveis |
| **Solução** | Uma intervenção possível | Informar os documentos necessários antes do início |
| **Resultado esperado** | A mudança que esperamos observar | Mais conclusões sem aumento de erros ou suporte |

“Usuários estão abandonando o cadastro” ainda não explica necessariamente o problema. “Precisamos mostrar os documentos antes do cadastro” também não: essa segunda formulação já descreve uma resposta. O trabalho de Problem Framing acontece justamente entre essas duas afirmações, quando transformamos um comportamento observado em perguntas que podem ser investigadas antes de escolher uma intervenção.

## Problem Framing e Problem Statement: qual é a diferença?

**Problem Framing é o processo de construir, testar e revisar nossa compreensão do problema. Problem Statement é uma formulação que registra esse entendimento em determinado momento.** Durante o framing, o time pode analisar comportamento, ouvir pessoas, confrontar hipóteses, identificar restrições e comparar diferentes interpretações. O problem statement condensa parte desse aprendizado em uma declaração que ajuda a alinhar a investigação ou a decisão.

Essa diferença é importante porque um problem statement não deveria se tornar uma verdade permanente. Se uma pesquisa posterior mostrar que a dificuldade ocorre principalmente em outro público, começa em uma etapa anterior ou possui uma explicação diferente daquela inicialmente imaginada, a formulação precisa mudar. O documento existe para representar o aprendizado, não para protegê-lo de novas evidências.

## Como fazer Problem Framing na prática

Não existe uma sequência universal que sirva para qualquer projeto. O nível de investigação necessário depende do risco da decisão, da complexidade do produto e do conhecimento que o time já possui. Ainda assim, algumas perguntas ajudam a impedir que uma demanda chegue à ideação sem que sua premissa tenha sido minimamente examinada.

### 1. Comece pela situação, não pela solução solicitada

Pedidos de produto frequentemente chegam na forma de entrega: “precisamos criar um dashboard”, “vamos colocar inteligência artificial”, “temos que diminuir o número de campos” ou “essa página precisa de um redesign”. Essas solicitações podem fazer sentido, mas ainda não explicam o problema que tornou a solução desejável.

Uma pergunta simples ajuda a voltar uma camada: **o que está acontecendo para que essa solução pareça necessária?** A resposta pode confirmar a direção inicial ou revelar que existem maneiras completamente diferentes de atuar sobre a situação.

### 2. Identifique quem enfrenta a situação e em qual contexto

Evite tratar “o usuário” como uma pessoa genérica. O mesmo fluxo pode funcionar bem para alguém que realiza determinada tarefa toda semana e ser problemático para quem está usando o produto pela primeira vez. Dispositivo, ambiente, conhecimento prévio, acessibilidade, pressão de tempo e objetivo também podem alterar completamente a experiência.

Em vez de escrever “o usuário tem dificuldade no cadastro”, podemos registrar que “pessoas que iniciam o cadastro pelo celular e ainda não possuem os documentos em mãos interrompem a tarefa antes do envio”. A formulação ainda não explica a causa, mas já delimita uma situação que pode ser investigada.

### 3. Separe observação de interpretação

Considere um dado hipotético: 32% das pessoas que chegam ao campo de documento não avançam para a etapa seguinte. Isso é uma observação produzida pela análise. Dizer que “o campo de documento está causando abandono” já é uma interpretação. A diferença parece pequena na linguagem, mas é enorme para a qualidade da decisão.

Talvez o documento realmente seja a principal barreira. Também é possível que aquela etapa apenas revele uma exigência que deveria ter sido comunicada antes, que a pessoa tenha interrompido a tarefa para procurar uma informação ou que outro fator esteja associado ao comportamento. Ao registrar evidência e interpretação separadamente, o time evita transformar uma explicação plausível em fato apenas porque ela parece intuitiva.

### 4. Entenda por que o problema importa

Nem todo impacto de UX precisa ser imediatamente convertido em receita ou conversão. Uma dificuldade pode aumentar esforço, provocar erros, gerar chamadas de suporte, reduzir confiança, ampliar tempo operacional ou excluir determinados grupos. Esses efeitos são relevantes mesmo quando ainda não existe uma tradução financeira precisa.

Quando houver também um objetivo de negócio, vale registrá-lo separadamente. “Precisamos aumentar a conversão do cadastro” é um objetivo do produto. “Pessoas não sabem quais documentos serão necessários antes de iniciar a tarefa” descreve uma dificuldade de experiência que pode estar associada ao resultado. Relacionar os dois é útil; tratá-los como se fossem a mesma coisa enfraquece o diagnóstico.

### 5. Torne as hipóteses explícitas

Um bom framing não exige que todas as respostas sejam conhecidas. Exige que o time saiba onde termina a evidência e começa a incerteza. No exemplo do cadastro, podemos considerar hipóteses como falta de informação prévia, dificuldade de acesso ao documento, baixa confiança na solicitação, esforço percebido alto ou até uma relação apenas aparente entre aquela etapa e o abandono.

Essas hipóteses mudam a pesquisa porque deixam de existir apenas como opiniões implícitas em uma reunião. Quando há muitas suposições importantes, o [Assumption Mapping](/assumption-mapping/) pode ajudar a identificar quais combinam maior incerteza e maior impacto, orientando o que merece ser investigado primeiro.

### 6. Verifique as restrições antes de tratá-las como imutáveis

Requisitos legais, segurança, dependências técnicas, integrações, conteúdo obrigatório, capacidade operacional e regras de negócio podem limitar as alternativas disponíveis. O cuidado está em separar restrições verificadas de decisões históricas que apenas se tornaram parte do produto com o passar do tempo.

“Esse campo sempre existiu” não é uma restrição. “Essa informação precisa ser coletada antes da contratação por uma exigência regulatória” pode ser. Essa distinção evita que decisões antigas sejam usadas para limitar artificialmente o espaço de solução.

### 7. Transforme incertezas em perguntas de pesquisa

Quando as hipóteses estão visíveis, elas podem ser convertidas em perguntas que orientam investigação. Podemos querer saber se as pessoas conhecem previamente a exigência do documento, se o comportamento muda entre celular e desktop, se o motivo da solicitação é compreendido, quais grupos são mais afetados e se quem conclui a tarefa utiliza algum tipo de ajuda externa.

Essas perguntas podem ser respondidas por entrevistas, análise de comportamento, testes de usabilidade, dados de suporte, pesquisa contextual ou outros [métodos de pesquisa em UX](/metodos-de-pesquisa-ux/). A ordem é importante: primeiro entendemos o que precisamos aprender; depois escolhemos o método adequado para produzir evidência.

### 8. Formule o problema sem fechar a solução

Depois de reunir contexto suficiente, podemos registrar uma formulação que oriente o próximo passo. Ela não precisa seguir uma fórmula rígida, mas normalmente fica mais útil quando explicita pessoa e contexto, dificuldade, evidência disponível, impacto e principais incertezas.

> Pessoas que iniciam o cadastro pelo celular interrompem a tarefa com maior frequência quando chegam à etapa que exige um documento. As evidências atuais mostram concentração do abandono nesse ponto, mas ainda não sabemos quanto desse comportamento é explicado por falta de informação prévia, dificuldade de acesso ao documento, confiança ou esforço percebido. Precisamos compreender essas diferenças antes de escolher uma intervenção.

Perceba que a formulação não promete uma causa e também não restringe a resposta a uma nova tela, mensagem, fluxo ou funcionalidade. Ela organiza o que sabemos e deixa explícito o que precisa ser aprendido para reduzir a incerteza da decisão.

## Canvas de Problem Framing da CamaraUX

Para documentar esse raciocínio, proponho um canvas simples com dez campos. A intenção não é criar mais um formulário obrigatório no processo de produto, mas preservar o entendimento atual do problema e permitir que a equipe reconheça quando alguma evidência exige uma revisão.



| Campo | Pergunta que precisa responder |
| --- | --- |
| **1. Pessoa e contexto** | Quem enfrenta a situação e em qual momento? |
| **2. Tarefa ou objetivo** | O que essa pessoa está tentando realizar? |
| **3. Evidência** | O que foi observado, por qual fonte e em qual período? |
| **4. Problema formulado** | Qual dificuldade situada merece investigação? |
| **5. Impacto** | O que acontece para a pessoa, operação ou produto? |
| **6. Restrições** | O que realmente limita nossas alternativas? |
| **7. Não objetivos** | O que não estamos tentando resolver nesta etapa? |
| **8. Hipóteses** | Quais explicações ainda não foram confirmadas? |
| **9. Perguntas de pesquisa** | O que precisamos aprender? |
| **10. Critério de decisão** | Que evidência mudará o próximo passo? |

O canvas deve representar a melhor compreensão disponível naquele momento, incluindo as fontes que sustentam afirmações importantes. Se uma pesquisa modifica o público afetado, enfraquece uma hipótese ou revela uma restrição antes desconhecida, o documento também muda. Registrar essas alterações ajuda a preservar o raciocínio do projeto e evita que cada reenquadramento pareça apenas uma mudança arbitrária de escopo.

## Problem Framing faz parte do Product Discovery

O framing não precisa acontecer em uma etapa isolada antes do [Product Discovery](/product-discovery/). Na prática, os dois processos se alimentam. O time pode começar com um enquadramento provisório, investigar a situação, descobrir novas necessidades, revisar hipóteses e mudar sua compreensão do problema antes de explorar oportunidades e soluções.

Esse caráter iterativo é importante porque discovery não deveria partir da premissa de que o problema recebido já está corretamente definido. Uma demanda pode refletir a visão de uma área específica, um sintoma pode esconder dificuldades diferentes entre segmentos e uma restrição aparentemente fixa pode desaparecer quando outras pessoas participam da discussão.

Pesquisas sobre framing em design reforçam essa dimensão. Em um estudo com designers experientes, Bec Paton e Kees Dorst observaram práticas de briefing nas quais profissionais não apenas recebiam o enquadramento do cliente, mas o investigavam, reformulavam e devolviam de uma maneira considerada mais útil para orientar o projeto. O framing, portanto, não acontece apenas depois da pesquisa: questionar o próprio brief pode fazer parte do processo de entender o problema.

## “Como poderíamos…” é a mesma coisa que Problem Framing?

Não. Perguntas “Como poderíamos…”, ou _How Might We_, podem ajudar na passagem entre compreensão do problema e ideação, mas não substituem contexto, evidência e hipóteses. A Nielsen Norman Group recomenda construir essas perguntas a partir de problemas ou aprendizados encontrados durante o discovery, evitando inserir uma solução específica dentro da própria pergunta.

Compare três formulações para o mesmo cenário:

- **Ampla demais:** “Como poderíamos melhorar o cadastro?”
- **Solução disfarçada:** “Como poderíamos mostrar uma lista de documentos antes do cadastro?”
- **Mais aberta:** “Como poderíamos ajudar as pessoas a se preparar para as informações exigidas antes de iniciar o cadastro?”

A terceira formulação abre mais possibilidades, mas ainda depende da validade do enquadramento. Se não existe evidência de que preparação é uma dificuldade relevante, apenas transformamos uma hipótese em uma pergunta aparentemente aberta. O “Como poderíamos…” funciona melhor quando vem depois de algum entendimento sobre a situação que estamos tentando mudar.

## Vídeo: como transformar pesquisa em uma declaração de necessidade

Este vídeo curto da Nielsen Norman Group complementa o framing ao mostrar como uma declaração de necessidade pode sintetizar quem é a pessoa, o que ela precisa realizar e por que isso importa sem prescrever uma funcionalidade. É especialmente útil para entender a passagem entre pesquisa e definição do problema.



User Need Statements in Design Thinking, Nielsen Norman Group.## Erros comuns ao enquadrar problemas de UX

Um framing fraco nem sempre parece obviamente errado. Muitas vezes ele utiliza linguagem de usuário, métricas e termos de produto, mas ainda carrega uma solução ou uma hipótese não verificada dentro da própria formulação. Alguns padrões merecem atenção especial.

### Começar com uma funcionalidade

“Criar um dashboard para gestores” descreve uma entrega. Antes de discutir componentes, gráficos ou filtros, precisamos entender qual decisão essas pessoas não conseguem tomar hoje, por que isso acontece e qual consequência essa dificuldade produz.

### Confundir uma métrica com o problema

“A conversão caiu 12%” é um dado relevante, mas não explica sozinho a experiência responsável pela mudança. Métricas ajudam a localizar comportamentos e medir efeitos. A compreensão do problema exige contexto adicional.

### Procurar uma única causa raiz cedo demais

Produtos digitais combinam pessoas, regras, conteúdo, tecnologia, operação, incentivos e diferentes contextos de uso. Em algumas situações existe uma causa relativamente clara; em outras, insistir imediatamente em uma única “causa raiz” produz uma simplificação artificial. Comparar hipóteses concorrentes costuma ser mais seguro do que escolher rapidamente uma explicação favorita.

### Usar “usuário” de forma genérica

Uma dificuldade pode existir apenas em determinado dispositivo, momento da jornada, condição de acessibilidade, segmento ou nível de conhecimento. Quando o contexto desaparece da formulação, o problema ganha uma abrangência que as evidências talvez não sustentem.

### Fazer pesquisa apenas para confirmar o enquadramento inicial

Se todas as perguntas de pesquisa foram construídas para validar uma única interpretação, o framing já escolheu a resposta. Uma investigação mais rigorosa também procura evidências que poderiam mostrar que nossa leitura está incompleta ou errada.

## Como saber se o problema está bem enquadrado?

Não existe um teste capaz de provar que encontramos “o problema correto”, mas podemos avaliar se o enquadramento é útil para uma decisão. Antes de avançar para ideação ou priorização, vale verificar se ele passa pelos seguintes critérios:

- identifica uma pessoa ou situação concreta em vez de falar de usuários genericamente;
- distingue observação, interpretação e hipótese;
- descreve uma dificuldade e não uma funcionalidade;
- explica por que a situação importa;
- pode ser confrontado por pesquisa ou dados;
- permite mais de uma solução plausível;
- deixa visíveis as principais incertezas;
- registra restrições relevantes sem tratá-las automaticamente como imutáveis;
- possui algum critério para orientar a decisão seguinte.

Um bom enquadramento não precisa eliminar a incerteza. Na verdade, parte de sua função é fazer o oposto: **tornar a incerteza visível e investigável**. Se a frase parece extremamente segura, mas o time não consegue explicar quais evidências sustentam sua causa, talvez estejamos apenas escondendo hipóteses dentro de uma declaração bem escrita.

## Quando reenquadrar o problema?

Reenquadrar não significa mudar a direção do projeto porque alguém apresentou uma nova preferência. Significa atualizar nossa representação da situação quando as evidências indicam que ela está incompleta, imprecisa ou conduzindo a uma decisão ruim.

Isso pode acontecer quando a pesquisa revela outro grupo significativamente afetado, quando o comportamento observado parece ser consequência de uma etapa anterior, quando segmentos diferentes apresentam dificuldades distintas ou quando uma intervenção melhora uma métrica e cria outro custo importante para a experiência. Também pode acontecer quando uma hipótese deixa de encontrar sustentação ou uma restrição considerada fixa se mostra negociável.

O Design Council reconhece explicitamente esse movimento ao explicar que organizações podem aprender algo novo sobre os problemas subjacentes e retornar às fases anteriores do processo. Em vez de enxergar isso como fracasso do discovery, faz mais sentido entendê-lo como parte natural de aprender sobre sistemas e experiências complexas.

## Do problema para oportunidades e soluções

Quando existe compreensão suficiente para avançar, o problema pode ser conectado a oportunidades e hipóteses de solução. É importante preservar essas camadas porque elas cumprem funções diferentes: o problema descreve uma dificuldade situada; a oportunidade indica uma direção de valor; a solução propõe uma intervenção específica que ainda precisa demonstrar que produz o resultado esperado.

O [Opportunity Solution Tree](/opportunity-solution-tree/) pode ser útil nessa etapa porque relaciona resultados, oportunidades e soluções sem transformar a primeira ideia em uma resposta inevitável. A lógica deixa de ser “ideia → justificativa → implementação” e se aproxima de “evidência → problema → oportunidade → hipótese de solução → experimento → aprendizado”.

## Problem Framing não garante que o time encontrará o “problema verdadeiro”

Nenhum canvas, workshop ou framework garante que existe uma única formulação correta esperando para ser descoberta. Uma mesma situação pode envolver diferentes pessoas, objetivos, restrições e perspectivas legítimas. O valor do framing está menos em declarar uma verdade definitiva e mais em tornar explícito qual interpretação está orientando a decisão atual e por quê.

Isso permite que o time explique o que está tratando como problema, quais evidências sustentam esse enquadramento, quais alternativas foram consideradas, o que ainda permanece incerto e em quais condições a formulação deverá ser revista. Essa transparência é mais útil do que produzir certeza artificial em um contexto que ainda está sendo investigado.

## Definir bem o problema é parte do trabalho de design

Problem Framing é menos sobre encontrar uma frase perfeita e mais sobre aprender a questionar o problema que recebemos. A demanda inicial pode ser uma solução, a métrica pode representar apenas um sintoma e a explicação mais intuitiva pode continuar sendo apenas uma hipótese.

Um enquadramento útil organiza essas diferenças antes que uma interpretação vire roadmap. Ele mostra quem está sendo afetado, em qual contexto, o que sabemos, que impacto está em jogo, quais hipóteses continuam abertas e o que precisa ser aprendido para avançar. E permanece revisável, porque em UX e Product Design definir o problema não acontece apenas antes da solução: acontece enquanto o time aprende.

## Perguntas frequentes sobre Problem Framing

### Problem Framing precisa ser feito em um workshop?

Não. Workshops podem ajudar a reunir diferentes perspectivas e criar alinhamento, mas o enquadramento depende principalmente de contexto e evidências. Ele também pode ser construído ao longo de análises, pesquisas, conversas com stakeholders e decisões de discovery.





### Quem deve participar do Problem Framing?

Depende do problema. Em geral, vale combinar pessoas que conhecem a experiência do usuário, operação, tecnologia, negócio e a decisão que precisa ser tomada. A participação multidisciplinar ajuda a revelar hipóteses e restrições que uma única área poderia assumir como fatos.





### Quanto tempo leva para fazer Problem Framing?

Não existe uma duração universal. Um problema relativamente conhecido pode ser organizado em uma sessão curta, enquanto situações complexas podem exigir dias ou semanas de pesquisa e revisão. O esforço deve ser proporcional ao risco e ao custo de tomar uma decisão errada.





### Problem Framing é necessário para qualquer problema de produto?

Não. Um erro técnico bem identificado, como uma funcionalidade que deixou de executar uma operação esperada, pode exigir diagnóstico e correção direta. O framing se torna mais valioso quando existe incerteza sobre a situação, as pessoas afetadas, as causas ou o resultado desejado.





### Como documentar um reenquadramento do problema?

Registre a formulação anterior, a nova formulação, a evidência que provocou a mudança e quais decisões foram afetadas. Isso preserva o raciocínio do projeto e permite entender por que o escopo ou a direção mudou em vez de tratar a revisão como uma decisão arbitrária.









## Referências e fontes

- [Dorst, K. The core of ‘design thinking’ and its application. Design Studies, 2011.](https://www.sciencedirect.com/science/article/pii/S0142694X11000603)
- [Paton, B.; Dorst, K. Briefing and reframing: A situated practice. Design Studies, 2011.](https://www.sciencedirect.com/science/article/pii/S0142694X11000561)
- [Design Council. The Double Diamond.](https://www.designcouncil.org.uk/resources/the-double-diamond/)
- [Design Council. Framework for Innovation.](https://www.designcouncil.org.uk/resources/framework-for-innovation/)
- [University of Glasgow. UX Framework: Problem Framing.](https://www.gla.ac.uk/myglasgow/ux/define/problemframing/)
- [Nielsen Norman Group. Using “How Might We” Questions to Ideate on the Right Problems.](https://www.nngroup.com/articles/how-might-we-questions/)
- [Nielsen Norman Group. User Need Statements: The ‘Define’ Stage in Design Thinking.](https://www.nngroup.com/articles/user-need-statements/)

**Conteúdos relacionados:** aprofunde o tema em [Product Discovery](/product-discovery/), [Assumption Mapping](/assumption-mapping/), [Opportunity Solution Tree](/opportunity-solution-tree/) e no guia de [métodos de pesquisa em UX](/metodos-de-pesquisa-ux/).

## Topics

**Categorias:** [Produto & Estratégia](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/category/produto-e-estrategia.md)