Understand
Define the challenge before choosing a tool or solution.
GX LIVE MARKETING · LOCAL PREVIEW
Design Thinking
A GX guide to understand a challenge, involve people, test a response, and learn from it.
SOLUTION ARCHITECTURE · METHOD
Design Thinking
A practice that starts with people, context, and the right question before deciding on a solution.
This method proposes looking at the problem with enough clarity before defending an answer. Understanding, collaboration, and testing turn an initial idea into something that can be reviewed.
This guide presents a framework for an initial conversation; each application requires its own context, scope, and validation.
READING PRINCIPLES
A guide to structure the next conversation.
The principles are presented as a framework for design and review. They do not replace a specific recommendation, diagnosis, or implementation.
Involve
Listen to the people who experience the journey to identify friction and opportunities.
Test
Turn a hypothesis into a prototype that enables learning without scaling an assumption.
Iterate
Use what was observed to guide adjustments to the next version.
From a question to a test.
An idea is not validated by sounding good. The method connects needs, options, and evidence. These five activities help organize the work; they are not a rigid recipe: a test may send us back to the initial question.
01
Understand people
Before choosing a format, we observe the journey and listen to the people experiencing it. We separate observations from assumptions: friction may lie in information, waiting, interaction, or context, rather than necessarily in the product.
- Working question
- What is the person trying to do, and where do they stop?
- What to carry forward
- An initial map of needs, friction, and questions to investigate.
02
Define a specific challenge
We turn that understanding into a question the team can work on. We identify who is affected, when, and under which constraints. We agree on what observation would help assess an alternative, without mistaking an internal preference for an audience need.
- Working question
- What do we want to help someone understand, do, or decide?
- What to carry forward
- A design question, its boundaries, and a review criterion.
03
Explore options and choose a hypothesis
First we broaden the possibilities as a team; then we assess them against the challenge, resources, and feasibility. Separating those moments lets us explore without dismissing ideas too early, and select without treating a vote or a suggestion as evidence.
- Working question
- Which alternatives address the same problem in different ways?
- What to carry forward
- Comparable options and an explicit hypothesis to test.
04
Build a small version
A script, sketch, sign, mockup, or clickable journey may be enough to test the hypothesis. We choose the simplest representation that helps us learn about the important uncertainty before committing to full production.
- Working question
- What do we need to see working before scaling?
- What to carry forward
- A bounded prototype and an observation plan.
05
Test, learn, and decide again
The test involves people from the relevant context. We record questions, actions, and differences from expectations, including what did not work. That evidence helps us decide what to adjust, keep, or discard, and what needs another test.
- Working question
- What changed in our understanding after observing?
- What to carry forward
- Findings, test limitations, and the next adjustment with an owner.
Example: turning a visit into a clear interaction.
Imagine a brand experience where someone walks past because they do not understand what they can do. We do not start by adding screens: we first investigate that friction. The graphic shows a possible working sequence, not an executed activation or a conversion promise.
How it connects to GX building blocks.
The same approach can apply to a physical space, an interface, or a project decision. The questions, prototypes, and evidence change; a solution should not be carried from one context to another by default.
Brand experiences
Review the invitation, participation, and exit. Rehearsing an activity or testing signs can reveal what someone understands and where they need help before producing the entire space.
Explore brand experiencesDigital products and journeys
Examine a specific task: finding information, understanding an option, or completing a journey. Sketches and prototypes help assess language and navigation before deciding on development.
Explore digital solutionsSolution Architecture and CORE-A
Bring needs and findings into the problem definition. Solution Architecture structures the project; the CORE-A framework connects context, decisions, and learning under human accountability. A methodological guide does not activate data collection or integrations.
Return to Solution ArchitectureWhat to take to the next building block.
- The challenge and its context, with assumptions separated from observations.
- The selected hypothesis, the prototype, and the test conditions.
- What was learned, what remains unanswered, and the pending decision with its owner.
Completing a workshop or having an attractive prototype is not enough. The value of the cycle lies in making explicit what we learned and how it changes the next decision. Scope, participation, and handling of any information are agreed on for each project.
Questions to make the method concrete.
Does it apply only to physical products?
No. The recovered original also covers services and experiences. Here we propose illustrative applications to physical and digital interactions, which need their own validation.
Must the five activities follow a fixed order?
They provide a working structure, not an irreversible sequence. If a test reveals a different problem, we return to understanding or defining the challenge.
Does a test guarantee that a solution will work?
No. A test provides evidence under certain conditions. Implementation requires reviewing its limitations, feasibility, and use context.
WITHIN THE SAME SYSTEM