Metodología
Cómo trabajo
Cinco pasos del diagnóstico al lanzamiento.
Con diseño orientado a hipótesis y benchmarking con SUM como métodos con nombre propio, y lo que veinte años me han enseñado sobre talleres que acaban en compromisos.
Una nota sobre el papel, antes de los métodos
Cada proyecto que he lanzado empezó en papel.
Hay algo mágico en rascar un bolígrafo sobre una hoja y dibujar letras que me ayuda a aclarar lo que está a punto de crearse y a conectar con ello de un modo más profundo del que puedo lograr en una pantalla. Veinte años después, la primera hora de cualquier proyecto sigue siendo boli sobre papel: las preguntas que quiero contestar, las personas para las que creo que estoy diseñando, la forma de lo que estoy a punto de construir. La pantalla viene después.
Lo menciono porque el resto de esta página va sobre métodos y herramientas, y los métodos sin ese paso previo de pensamiento privado son solo frameworks disfrazados de trabajo.
01 · Paso
Diagnosticar el negocio y el sistema de producto
Antes de los píxeles, la pregunta es qué comportamiento importa. El primer mes de cada colaboración lo paso escuchando (al CEO, a ingeniería, a los tickets de soporte y a los usuarios cuando puedo acceder a ellos) y anotando lo que oigo en lenguaje claro. Para la semana cuatro suelo tener un diagnóstico de una página.
El resultado no es una presentación de recomendaciones. Es un mapa compartido. Un equipo que está de acuerdo en el diagnóstico puede discrepar de forma productiva sobre la solución.
Aquí también descubro qué no hacer. Esa parte sale de dos sitios: pensamiento profundo en solitario, normalmente en papel, y contraste con el equipo. Restar scope es más difícil que sumarlo; la mayoría de equipos a los que me he unido tenían un roadmap lleno de cosas que nadie podía decir honestamente que pertenecieran.
En la prácticaRediseño del cashier en GVC02 · Paso
Dar forma a lo más pequeño que nos enseñe algo
Las apuestas grandes salen más baratas cuando la primera iteración se gana el derecho a la siguiente. Trato cada build temprano como un test deliberado de una asunción, no como una entrega.
La forma de cuatro líneas importa porque fuerza un compromiso. “Creemos que X” es más difícil de esquivar que “deberíamos pensar en X”. Cuando la apuesta falla, las cuatro líneas son también el post-mortem más limpio que puedes hacer: ¿qué línea estaba mal?
En la prácticaDiseño orientado a hipótesis03 · Paso
Diseñar el sistema, no solo la pantalla
Bucles, incentivos, pricing, comunidad, datos: la pantalla es el extremo visible del sistema. Si el sistema está roto, ningún oficio de píxel va a arreglar el producto. Si el sistema funciona, hasta una pantalla rugosa puede sostener la experiencia.
Aquí también es donde más empujo de vuelta cuando un stakeholder pide un “rediseño”. A menudo la pantalla está bien. El sistema a su alrededor, no.
En la prácticaSellerCrowd04 · Paso
Prototipar rápido con IA
Claude Code, prompt specs, eval loops. Lanzar producto se ha convertido en una nueva forma de pensar. El coste de averiguar si una idea es buena se ha desplomado.
Prototipar ya no es una fase aparte reservada a lo que ingeniería se puede permitir explorar. “¿Y si tuviese esta pinta?” se contesta ahora en veinte minutos, no en tres sprints.
Lo que no cambia: el criterio sobre cuál prototipo construir. Eso sigue siendo trabajo del IC sénior. Los modelos son rápidos y literales; necesitan a alguien en la sala que sepa qué intenta aprender el equipo de verdad.
En la prácticaConstruyendo en 202605 · Paso
Lanzar, medir, ajustar
El trabajo no se acaba cuando es bonito. Se acaba cuando los números se mueven.
SUM es una herramienta dentro de un hábito más amplio: lanza, observa la métrica y prepárate para revertir. La versión de la que estoy más orgulloso rara vez es la primera que dibujé.
En la prácticaSUM, la métrica única de usabilidadUna nota sobre workshops
El objetivo de cada taller es acabar con compromisos.
Sin alineamientos vagos, sin una presentación bonita y sin un “esto merece una segunda vuelta”. Casi nunca sigo un Sprint al pie de la letra: el taller adecuado es el que diseño a medida para el equipo que tengo en la sala, usando las recetas de Gamestorming como base.
La técnica de facilitación más útil que conozco es equilibrar la participación: dar a todos el mismo tiempo para hablar y controlar las voces más fuertes para que las más calladas compartan primero lo que piensan.
Los tres dieron lugar a compromisos que el equipo mantuvo.