Comprender
Definir el reto antes de elegir la herramienta o la solución.
GX LIVE MARKETING · VISTA LOCAL
Design Thinking
Una guía de GX para comprender un reto, involucrar a las personas, probar una respuesta y aprender de ella.
SOLUTION ARCHITECTURE · MÉTODO
Design Thinking
Una práctica para empezar por las personas, el contexto y la pregunta correcta antes de decidir una solución.
Este método propone mirar el problema con suficiente claridad antes de defender una respuesta. La comprensión, la colaboración y la prueba convierten una idea inicial en algo que puede revisarse.
Esta guía presenta un marco de lectura para una conversación inicial; cada aplicación requiere contexto, alcance y validación específicos.
PRINCIPIOS DE LECTURA
Una guía para estructurar la siguiente conversación.
Los principios se presentan como marco de diseño y revisión. No sustituyen una recomendación, diagnóstico o implementación específica.
Involucrar
Escuchar a quienes viven el recorrido para encontrar fricción y oportunidades.
Probar
Convertir una hipótesis en un prototipo que permita aprender sin escalar una suposición.
Iterar
Usar lo observado para ajustar la siguiente versión con criterio.
De la pregunta a la prueba.
Una idea no se valida por sonar bien. El método ayuda a relacionar necesidades, opciones y evidencia. Estas cinco actividades sirven para ordenar el trabajo; no son una receta rígida: una prueba puede obligarnos a volver a la pregunta inicial.
01
Comprender a las personas
Antes de elegir un formato, observamos el recorrido y escuchamos a quienes lo viven. Separamos lo que hemos visto de lo que suponemos: una fricción puede estar en la información, la espera, la interacción o el contexto, no necesariamente en el producto.
- Pregunta de trabajo
- ¿Qué intenta hacer la persona y dónde se detiene?
- Qué debería quedar
- Un mapa inicial de necesidades, fricciones y preguntas por comprobar.
02
Definir un reto concreto
Convertimos esa lectura en una pregunta que el equipo pueda trabajar. Delimitamos a quién afecta, en qué momento y bajo qué restricciones. Acordamos qué observación permitiría evaluar una alternativa, sin confundir una preferencia interna con una necesidad de la audiencia.
- Pregunta de trabajo
- ¿Qué queremos ayudar a comprender, hacer o decidir?
- Qué debería quedar
- Una pregunta de diseño, sus límites y un criterio de revisión.
03
Abrir opciones y elegir una hipótesis
Primero ampliamos las posibilidades en equipo; después las contrastamos con el reto, los recursos y la viabilidad. Separar esos momentos permite explorar sin descartar demasiado pronto y elegir sin convertir una votación o una ocurrencia en evidencia.
- Pregunta de trabajo
- ¿Qué alternativas responden al mismo problema de formas distintas?
- Qué debería quedar
- Opciones comparables y una hipótesis explícita para probar.
04
Construir una versión pequeña
Un guion, un boceto, una señal, una maqueta o un recorrido clicable puede bastar para poner a prueba la hipótesis. Elegimos la representación más sencilla que permita aprender sobre la duda importante, antes de comprometer la producción completa.
- Pregunta de trabajo
- ¿Qué parte necesitamos ver funcionar antes de escalar?
- Qué debería quedar
- Un prototipo acotado y un plan de observación.
05
Probar, aprender y volver a decidir
La prueba involucra a personas del contexto pertinente. Registramos dudas, acciones y diferencias respecto a lo esperado; revisamos también lo que no funcionó. Con esa lectura decidimos qué ajustar, conservar o descartar y qué necesita una nueva prueba.
- Pregunta de trabajo
- ¿Qué cambió en nuestra comprensión después de observar?
- Qué debería quedar
- Hallazgos, límites de la prueba y el siguiente ajuste con responsable.
Ejemplo: de una visita a una interacción comprensible.
Imaginemos una experiencia de marca en la que una persona pasa de largo porque no entiende qué puede hacer. No empezamos agregando pantallas: primero investigamos esa fricción. La gráfica muestra una posible secuencia de trabajo, no una activación realizada ni una promesa de conversión.
Cómo se conecta con los bloques GX.
El mismo criterio puede aplicarse a un espacio físico, una interfaz o una decisión de proyecto. Cambian las preguntas, los prototipos y la evidencia necesaria; no se traslada una solución por defecto de un contexto a otro.
Experiencias de marca
Revisar invitación, participación y salida. Un ensayo de la dinámica o de la señalización puede mostrar qué entiende una persona y dónde necesita ayuda, antes de producir todo el espacio.
Explorar experiencias de marcaProductos y recorridos digitales
Examinar una tarea concreta: encontrar información, entender una opción o completar un recorrido. Bocetos y prototipos permiten contrastar lenguaje y navegación antes de decidir el desarrollo.
Explorar soluciones digitalesSolution Architecture y CORE-A
Aportar necesidades y hallazgos a la definición del problema. Solution Architecture ordena el proyecto; el marco CORE-A relaciona contexto, decisiones y aprendizaje bajo responsabilidad humana. Una guía metodológica no activa captura de datos ni integraciones.
Volver a Solution ArchitectureQué llevar al siguiente bloque.
- El reto y el contexto que lo justifican, con supuestos separados de observaciones.
- La hipótesis elegida, el prototipo utilizado y las condiciones de la prueba.
- Lo aprendido, lo que sigue sin respuesta y la decisión pendiente con su responsable.
No basta con terminar un taller o tener un prototipo atractivo. El valor del ciclo está en hacer explícito qué aprendimos y cómo cambia la siguiente decisión. Alcance, participación y tratamiento de cualquier información se acuerdan para cada proyecto.
Preguntas para aterrizar el método.
¿Se aplica sólo a productos físicos?
No. El original recuperado también contempla servicios y experiencias. Aquí proponemos aplicaciones ilustrativas a interacciones físicas y digitales, que necesitan su propia validación.
¿Hay que seguir las cinco actividades en orden?
Sirven como estructura de trabajo, no como una secuencia irreversible. Si la prueba revela otro problema, volvemos a comprender o a definir el reto.
¿La prueba garantiza que una solución funcionará?
No. Una prueba aporta evidencia bajo ciertas condiciones. La decisión de implementar necesita revisar sus límites, la viabilidad y el contexto de uso.
EN EL MISMO SISTEMA
Volver al contexto o abrir otra guía.
TU SIGUIENTE PASO
Elige cómo continuar
Explora la capacidad relacionada o conversemos sobre el reto que quieres resolver.