Compreender
Definir o desafio antes de escolher a ferramenta ou a solução.
GX LIVE MARKETING · PRÉVIA LOCAL
Design Thinking
Um guia da GX para compreender um desafio, envolver as pessoas, testar uma resposta e aprender com ela.
SOLUTION ARCHITECTURE · MÉTODO
Design Thinking
Uma prática que começa pelas pessoas, pelo contexto e pela pergunta certa antes de decidir uma solução.
Este método propõe olhar para o problema com clareza suficiente antes de defender uma resposta. Compreensão, colaboração e testes transformam uma ideia inicial em algo que pode ser revisado.
Este guia apresenta uma estrutura de reflexão para uma conversa inicial; cada aplicação exige contexto, escopo e validação específicos.
PRINCÍPIOS DE LEITURA
Um guia para estruturar a próxima conversa.
Os princípios são apresentados como uma estrutura para design e revisão. Não substituem uma recomendação, um diagnóstico ou uma implementação específicos.
Envolver
Ouvir as pessoas que vivenciam a jornada para identificar dificuldades e oportunidades.
Testar
Transformar uma hipótese em um protótipo que permita aprender sem ampliar uma suposição.
Iterar
Usar o que foi observado para ajustar a próxima versão com critério.
Da pergunta ao teste.
Uma ideia não é validada por parecer boa. O método relaciona necessidades, opções e evidências. Estas cinco atividades ajudam a organizar o trabalho; não são uma receita rígida: um teste pode nos levar de volta à pergunta inicial.
01
Compreender as pessoas
Antes de escolher um formato, observamos a jornada e ouvimos quem a vivencia. Separamos observações de suposições: uma dificuldade pode estar na informação, na espera, na interação ou no contexto, não necessariamente no produto.
- Pergunta de trabalho
- O que a pessoa tenta fazer e onde ela para?
- O que deve ficar
- Um mapa inicial de necessidades, dificuldades e perguntas a investigar.
02
Definir um desafio concreto
Transformamos essa compreensão em uma pergunta que a equipe possa trabalhar. Delimitamos quem é afetado, em qual momento e sob quais restrições. Combinamos qual observação permitirá avaliar uma alternativa, sem confundir uma preferência interna com uma necessidade do público.
- Pergunta de trabalho
- O que queremos ajudar a compreender, fazer ou decidir?
- O que deve ficar
- Uma pergunta de design, seus limites e um critério de revisão.
03
Explorar opções e escolher uma hipótese
Primeiro ampliamos as possibilidades em equipe; depois as confrontamos com o desafio, os recursos e a viabilidade. Separar esses momentos permite explorar sem descartar cedo demais e escolher sem tratar uma votação ou uma ideia como evidência.
- Pergunta de trabalho
- Quais alternativas respondem ao mesmo problema de formas diferentes?
- O que deve ficar
- Opções comparáveis e uma hipótese explícita para testar.
04
Construir uma versão pequena
Um roteiro, esboço, sinal, maquete ou jornada clicável pode bastar para testar a hipótese. Escolhemos a representação mais simples que permita aprender sobre a dúvida importante antes de comprometer a produção completa.
- Pergunta de trabalho
- O que precisamos ver funcionar antes de ampliar?
- O que deve ficar
- Um protótipo delimitado e um plano de observação.
05
Testar, aprender e decidir de novo
O teste envolve pessoas do contexto pertinente. Registramos dúvidas, ações e diferenças em relação ao esperado, inclusive o que não funcionou. Essa leitura orienta o que ajustar, manter ou descartar e o que precisa de um novo teste.
- Pergunta de trabalho
- O que mudou na nossa compreensão depois de observar?
- O que deve ficar
- Descobertas, limites do teste e o próximo ajuste com responsável.
Exemplo: de uma visita a uma interação compreensível.
Imaginemos uma experiência de marca em que alguém passa direto porque não entende o que pode fazer. Não começamos acrescentando telas: primeiro investigamos essa dificuldade. A infografia mostra uma possível sequência de trabalho, não uma ativação realizada nem uma promessa de conversão.
Como se conecta aos blocos GX.
O mesmo critério pode ser aplicado a um espaço físico, uma interface ou uma decisão de projeto. Mudam as perguntas, os protótipos e as evidências necessárias; uma solução não deve ser transferida de um contexto para outro por padrão.
Experiências de marca
Revisar convite, participação e saída. Um ensaio da dinâmica ou um teste da sinalização pode mostrar o que a pessoa entende e onde precisa de ajuda antes de produzir todo o espaço.
Explorar experiências de marcaProdutos e jornadas digitais
Examinar uma tarefa concreta: encontrar informação, entender uma opção ou concluir uma jornada. Esboços e protótipos permitem avaliar linguagem e navegação antes de decidir o desenvolvimento.
Explorar soluções digitaisSolution Architecture e CORE-A
Levar necessidades e descobertas à definição do problema. Solution Architecture organiza o projeto; o marco CORE-A relaciona contexto, decisões e aprendizado sob responsabilidade humana. Uma orientação metodológica não ativa coleta de dados nem integrações.
Voltar a Solution ArchitectureO que levar ao próximo bloco.
- O desafio e seu contexto, com suposições separadas de observações.
- A hipótese escolhida, o protótipo utilizado e as condições do teste.
- O que foi aprendido, o que segue sem resposta e a decisão pendente com seu responsável.
Concluir um workshop ou ter um protótipo atraente não basta. O valor do ciclo está em tornar explícito o que aprendemos e como isso muda a próxima decisão. Escopo, participação e tratamento de qualquer informação são combinados para cada projeto.
Perguntas para tornar o método concreto.
Aplica-se apenas a produtos físicos?
Não. O original recuperado também contempla serviços e experiências. Aqui propomos aplicações ilustrativas a interações físicas e digitais, que precisam de sua própria validação.
É preciso seguir as cinco atividades em ordem?
Elas servem como estrutura de trabalho, não como uma sequência irreversível. Se o teste revelar outro problema, voltamos a compreender ou a definir o desafio.
O teste garante que uma solução funcionará?
Não. Um teste fornece evidências sob certas condições. A decisão de implementar exige revisar seus limites, a viabilidade e o contexto de uso.
NO MESMO SISTEMA