Resolución de Problemas: El Método Design Thinking

Si alguna vez pasaste horas intentando arreglar un bug o construir una funcionalidad que al final el cliente no quería usar… seguro sentiste la frustración de perder tiempo y energía. En el mundo de la tecnología, a menudo nos lanzamos a escribir código antes de entender realmente cuál es el problema que estamos resolviendo.

El desarrollo de software no es solo escribir código, configurar bases de datos o desplegar servicios. En el fondo, la programación es un ejercicio continuo de resolución de problemas.

Para no dar palos de ciego, existe una metodología que los diseñadores crearon y que los desarrolladores podemos adoptar con un éxito increíble: el Design Thinking. Este método consiste en un enfoque centrado en las personas para resolver problemas complejos y se basa en observar y actuar de manera estructurada.

mindmap
  root((Design Thinking))
    👁️ Observar
      Empatizar sin juzgar
      Alcance espacial y temporal
      Observación participante o encubierta
    🔍 Analizar
      Investigación profunda
      Datos cualitativos vs cuantitativos
      Objetivos e Insights
    💡 Idear
      Imaginación y Conocimiento
      Actitud proactiva
      Brainstorming estructurado
    🛠️ Prototipar
      Crear un MVP
      Transmitir el cómo y cuándo
      Documentar decisiones
    🔁 Testear e Iterar
      Feedback de usuarios reales
      No guiar al usuario
      Mejora continua

Las Cinco Bases del Método

El proceso de Design Thinking no es una línea recta, sino un ciclo continuo que puedes dividir en cinco fases fundamentales para observar y actuar:

1. Observar (Empatizar): examina tu entorno de manera atenta ¿Qué puedes mejorar? ¿Qué hace falta? ¿Qué problemas enfrentan los usuarios en su día a día?
2. Analizar (Definir): descubre el porqué sucede la situación. Plasma el problema de forma explícita y llega a la raíz profunda del mismo.
3. Diseñar o generar una solución (Idear): sabiendo el cómo y el porqué de la situación, es momento de pensar en cómo solucionarlo sin temor a usar nuevas herramientas o metodologías.
4. Probar o hacer (Prototipar): tu diseño no puede quedarse en papel o en Figma; debes implementarlo en una versión preliminar para probarlo en el campo.
5. Feedback (Testear e Iterar): pon a prueba tu solución, recolecta comentarios y repite el proceso. Si algo no funciona, ¡la perseverancia es clave!

Todos somos artistas y creadores en nuestro trabajo. Lo que más destaca a un programador no es solo su capacidad técnica de escribir código, sino su curiosidad y acción: interesarse por entender cómo funciona el entorno y no temer a probar nuevas ideas o a preguntar. 💡

1. Observar y Empatizar: Entender el Entorno

Antes de escribir una sola línea de código, necesitas empatizar. La empatía en el desarrollo de software comienza con no juzgar. Esto significa que debes tratar de entender por qué los usuarios actúan de la manera en que lo hacen, incluso si a primera vista su flujo de trabajo te parece ineficiente o “incorrecto”.

Para comenzar a observar con efectividad, necesitas trazar un plan claro de observación que responda a esta estructura:

Mi plan de observación se realizará durante X horas, durante X días, en el contexto del proceso Y.

Dimensiones de tu Plan de Observación

Al diseñar este plan, debes definir tres aspectos clave:

• Alcance espacial: ¿Hasta dónde podrás o querrás observar físicamente o dentro del software? (Por ejemplo, un módulo específico, o la oficina de operaciones del cliente).
• Alcance temporal: ¿Cuál es el tiempo límite o el plazo definido que pondrás para esta tarea de investigación?
• Recursos disponibles: ¿Qué herramientas tienes a mano (grabadoras de pantalla, métricas de Analytics, entrevistas) para cumplir el objetivo?

flowchart TD
    O[🔭 Tipo de Observación] --> P["👥 Participante\nInteractúas directamente con el entorno y los usuarios"]
    O --> NP["🕵️ No Participante\nObservas desde fuera sin intervenir"]
    P --> E["🤫 Encubierta\nLos usuarios no saben que estás evaluando el proceso"]
    P --> NE["📢 No Encubierta\nLos usuarios saben que los estás observando"]

Comprender el Contexto de Raíz

Para obtener una visión completa, es crucial interactuar con todos los actores involucrados. No todos ven el problema de la misma manera: un operador administrativo verá dolores muy diferentes a los de un gerente de ventas.

Debes analizar el contexto desde tres perspectivas:

• En la periferia: observa las situaciones colaterales o indirectas que rodean el problema.
• En directo: analiza las acciones justo en el momento en que ocurren.
• Al margen: detente a mirar los detalles que los usuarios dan por sentados pero que revelan fricción.

2. Analizar y Definir: Llegar al Corazón del Problema

Una vez que has observado, tendrás un mar de notas y datos. El siguiente paso es empaparte del tema a profundidad y estructurar la información.

Investigación 360: Datos y Emociones

Antes de proponer una arquitectura de software o cambiar una base de datos, busca en la red todo lo relacionado con el problema. Revisa foros, documentación oficial de herramientas similares y fuentes confiables:

• Fuentes académicas: busca en herramientas como Google Scholar o bases de datos especializadas para ver si alguien ya ha estudiado el problema y qué soluciones teóricas existen.
• Clasificación de datos: separa la información en cualitativa (emociones de frustración de los usuarios, comentarios, opiniones) y cuantitativa (tiempo de carga de una página, cantidad de clics, tasa de abandono).

La magia del análisis radica en encontrar la relación entre ambas: detrás de una métrica cuantitativa baja siempre hay una emoción cualitativa de frustración oculta.

Definir Objetivos y “Pain Points”

Con la información clasificada, es momento de definir tus objetivos. Estos son los retos y mejoras que quieres lograr en el entorno, y deben cumplir con ser:

• Retos reales: deben empujarte a buscar soluciones creativas.
• Medibles: debes poder medir si tu software mejoró la métrica inicial.
• Claros: cualquier miembro del equipo técnico o de negocio debe entenderlos.
• Pain Points (Puntos de Dolor): deben atacar problemas complejos pero que, al solucionarse, brinden una inmensa mejora al entorno.

flowchart LR
    D[📊 Datos Cualitativos + Cuantitativos] --> A{Análisis}
    A --> O["🎯 Objetivos\n(Retos claros y medibles)"]
    A --> I["🧠 Insights\n(Oraciones breves que invitan al cambio)"]
    O & I --> S[🚀 Solución de Impacto]

El Poder de los Insights

Un insight es una oración corta que resume un descubrimiento profundo y genera movimiento. Sirve como el puente emocional para tu equipo: si el objetivo no es atractivo y claro, tus compañeros de desarrollo no se sentirán emocionados de participar en el proyecto.

3. Idear: ¿De Dónde Vienen las Grandes Ideas?

La creatividad no es un superpoder de unos pocos elegidos. Si eres humano y trabajas en tecnología, ya eres creativo.

Para activar esta capacidad al máximo, debes equilibrar dos dimensiones:

La Dimensión Interna

• Imaginación: es innata en ti. No te cohíbas ni te limites a una sola forma de pensar. Pregúntate siempre: ¿cómo podría hacer esto de forma totalmente distinta?
• Conocimiento: a mayor conocimiento técnico y de negocio, mejores ideas tendrás. Al saber cómo funcionan las herramientas a fondo, sabrás exactamente cómo mejorarlas.
• Actitud: esta es la más importante. De nada sirve tener la imaginación de un genio si no tienes la actitud de proponer, probar y equivocarte sin miedo.

La Dimensión Externa

• Ambiente: el espacio intangible. ¿Cómo es tu relación con tu equipo y con los usuarios? Un ambiente de confianza fomenta que las ideas fluyan.
• Recursos: todo lo físico y disponible. Desde lápices y tableros virtuales (como Miro o Notion) hasta la documentación de APIs de terceros.

Técnicas de Brainstorming (Lluvia de Ideas)

Para calentar el cerebro antes de idear, realiza pequeños ejercicios de 2 a 5 minutos:

• Conectar y combinar: toma dos conceptos totalmente ajenos (por ejemplo, “compresión de archivos” y “jardinería”) e intenta unirlos en una nueva idea.
• Punto de vista ajeno: piensa en el problema técnico actual e imagínate cómo lo resolvería alguien totalmente ajeno a la informática (por ejemplo, un chef o un piloto).

Si he visto más allá es porque estaba sentado en hombros de gigantes. — Isaac Newton

Al realizar una lluvia de ideas formal con tu equipo, sigue estas pautas estrictas:

• Establece un foco pequeño y alcanzable.
• No juzgues ni descartes ninguna idea en la fase de creación.
• Asegúrate de que todos participen y anota absolutamente todo.
• Filtra las ideas con pragmatismo después del ejercicio. Clasifícalas en un eje cartesiano donde el eje X sea la viabilidad de implementación y el eje Y sea el valor o importancia que aporta al usuario.

4. Prototipado: Tu Idea en Acción

Una idea genial sin ejecutar no vale nada. En tecnología, esto se traduce en construir un MVP (Minimum Viable Product).

Al crear tu prototipo, asegúrate de documentar cada proceso: el porqué decidiste un framework sobre otro, qué restricciones asumiste y qué decisiones de diseño tomaste.

Si estás diseñando un producto digital:

• Diseña interfaces claras e interactivas (mockups o prototipos navegables de Figma).
• Asegúrate de transmitir no solo la funcionalidad pura, sino el cómo y cuándo se usaría en el día a día.

5. Testear e Iterar: El Ingrediente Secreto

El testeo es el momento de la verdad. ¿Tu solución realmente funciona o solo era buena en tu cabeza?

flowchart LR
    T[🧪 Testeo en Campo] --> D1[1. Dale el producto al usuario]
    T --> D2[2. NO le digas cómo usarlo]
    T --> D3["3. Pídele que piense en voz alta (análisis cognitivo)"]
    T --> D4[4. Anota cada fricción, duda y comentario]

Reglas de Oro para un Testeo Exitoso

1. No le expliques al usuario cómo usar tu producto: en la vida real, no estarás a su lado para guiarlo.
2. Deja que tome la iniciativa: observa dónde hace clic primero, dónde se confunde y qué caminos toma.
3. Pídele que hable en voz alta: haz que te diga qué piensa y qué cree que pasará antes de presionar un botón.
4. Registra todos los datos: documenta fielmente qué funcionó, qué falló y qué emociones experimentó el usuario.

Iterar para la Excelencia

La iteración es el verdadero motor del Design Thinking. Rara vez una solución funciona de forma impecable en la primera prueba.

Analiza los datos recopilados y decide qué modificaciones necesita el software para cumplir el objetivo inicial. A veces, el testeo demostrará que la idea no es viable, y eso está perfectamente bien. Saber pivotar a tiempo con madurez profesional es parte del éxito de cualquier desarrollador.

Aplicando el Design Thinking en tu Vida Profesional

¿Cómo se conecta este flujo con tu rol diario como programador?

• Antes de programar un feature: sal de tu editor de código y observa cómo los usuarios hacen esa tarea manualmente hoy en día (Empatizar).
• Al diseñar la base de datos: investiga las mejores prácticas y fuentes oficiales, clasificando las restricciones técnicas antes de empezar (Definir).
• En las reuniones de arquitectura: fomenta espacios de lluvia de ideas combinando patrones existentes sin juzgar prematuramente (Idear).
• Durante el ciclo de desarrollo: construye maquetas rápidas antes de comprometerte con una infraestructura compleja (Prototipar).
• En los code reviews y despliegues: analiza el feedback de tus compañeros y usuarios finales de forma objetiva para refinar el código (Testear e Iterar).