El porqué

Calculo que en el verano (invierno para los que crecimos en Ecuador), la época calurosa, mi padre nos convocó en el salón de casa para explicarnos cómo funcionaba el embrague en los coches. Nuestra fascinación —la de mis dos hermanas mayores y yo— seguramente venía de haber dado un paso más en la loca idea de poder conducir solos el coche de casa. Sí, al parecer, en la cabeza de mi padre, lo más importante para que asumiéramos responsabilidades era entender cómo funciona un motor; el resto de peligros asociados a que unos críos de 13, 15 y 17 años cojan un coche no debía ser relevante… ¡En fin! Otros tiempos.

El caso es que, con la alegría que caracteriza a mi padre, nos contó, con dibujos y explicaciones teóricas, el principio de funcionamiento de un motor de combustión y, sobre todo, cómo funciona el cambio de marchas para que no nos carguemos el embrague.

Empiezo mi reflexión de esa forma para validar mis creencias —diría que es un sesgo de confirmación en toda regla—. Estoy convencido de que, primero, hay que entender el porqué, el contexto, para luego aterrizar en la práctica. Y esto, que parece una obviedad, nos lo saltamos más veces de lo que imaginamos.

Llevando este ejercicio al diseño, en el escenario actual lleno de automatismos —llámense Inteligencia Artificial, catálogos de soluciones con “buenas prácticas”, frameworks o sistemas de diseño estandarizados—, tengo la sensación de que hay un gran riesgo de no entender el porqué de las cosas, de los procesos y de las hojas de ruta que un producto o una solución persigue.

Perder la profundidad en la reflexión inicial nos expone a riesgos de definición conceptual difíciles de corregir. Es importante entender los retos desde la raíz; este ejercicio muchas veces obliga a desaprender, a luchar contra nuestros sesgos y a exprimir un poco el cerebro para formular hipótesis que aporten valor al diseño.

Herramientas

• Design thinking: O, más bien, la reflexión en 3 métodos fáciles de atender y que sirven para arrancar con una buena “foto fija”:

• Business Model Canvas: Sí, es old school, y seguro que hay enfoques más nuevos y efectivos, pero utilizar esta herramienta te permite entender gran parte del contexto de forma muy sencilla.

• Entrevistas: Entrevistas, entrevistas y más entrevistas.

• Personas: Lo más importante es entender que el objetivo no es rellenar un informe interminable. Se trata de una reflexión real, basada en datos —recogidos de forma analítica— y comprendidos a fondo. Este vídeo es interesante para profundizar en este tema:

Actitudes

• Interés en el “idioma”: Seré directo: muestra interés en entender el entorno tecnológico en el que se asienta el proyecto. Es habitual que los equipos de desarrollo no hablen tu mismo idioma. Esto es como viajar a otro país, si te esfuerzas por aprender su lengua o su jerga, te recibirán mejor. Tú decides si solo “chapurrear” o volverte un experto.

• Abrir tu mente al aprendizaje: Te irá mejor si asumes tu rol de experto con humildad, reconociendo que tu cliente —o cualquier stakeholder— sabe mucho sobre el producto, servicio o proyecto que tengas entre manos. No, no lo sabes todo. Posiblemente eres hábil pensando de forma lateral, pero siempre hay sesgos y perspectivas que debes identificar y gestionar. Lo verdaderamente valioso es tu habilidad para hacer que la información fluya, permitiendo que el equipo llegue a la mejor solución.

En Elastic no tenemos una receta universal o un “método” aplicable a todo; tenemos artefactos—herramientas y prototipos clave— y tenemos una actitud. La clave está en conducir con orden la obsesión por entender el porqué.